开头先说个背景我去年接了一个企业AI Agent项目团队里没有人不懂模型——RAG怎么搭、Agent框架怎么选、提示词怎么写都非常熟。当时所有人都觉得最大的风险是模型能力不够怕它回答得不够聪明。结果项目跑到第三个月我们才意识到模型反而是整个项目里最简单、最不容易出问题的一块。真正让我们反复返工、差点翻车的是另外三件事需求入口、组织信任、评测机制。这篇文章就把这一年的教训和调整过程完整拆给你。1. 第一件事业务口中的“智能体需求”一半是伪需求1.1 伪需求的三种典型形态先说结论企业里绝大多数“我想做个AI助手”的需求根本不需要Agent甚至不需要大模型。你把需求拆到底会发现它们只是“用新话术描述旧需求”。我见过最多的三种形态形态一信息编排型。业务方说“帮我们生成周报吧”或者“把知识库变成问答机器人”。这类需求听着很AI但本质是“把分散的信息汇总成固定模板”。你要做的不是Agent而是一个定时脚本加一个模板引擎最多套一层大模型做润色。我们内部管这叫“珍珠翡翠白玉汤”看起来是道菜其实是剩饭剩菜换了个碗。信息编排不产生新信息只是换个呈现方式业务的真实痛点根本不在这。形态二全面赋能型。“给我们所有业务线都配上AI助手”听起来气势很大但你追问一句“哪条业务线的哪个环节最痛”对方通常说不出来。这类需求的背后往往是管理层焦虑——别人都在做AI我们不能落后。这种项目如果直接开工团队会在“所有业务线”四个字里淹死最后什么都做不好。形态三替代决策型。业务方最常说的版本是“让Agent帮我们做库存决策”或“让Agent帮我们审批合同”。这类需求不是伪需求但它是“超纲需求”。因为一旦Agent的决策出错责任无法归属。企业内部没有任何一个部门愿意为一个模型输出的决策签字。你硬做也能做上线后没人敢用最终沦为演示Demo。1.2 怎么把“模糊需求”翻译成“可落地需求”这一年的经验告诉我业务访谈比技术方案重要十倍。技术方案是“怎么做”业务访谈解决的是“到底做什么”。我们需要一套很笨但有效的提问清单每次需求沟通都拿着它逐条追问这个Agent上线后具体想让哪个岗位的人省下哪一类时间现状里这件事是怎么做的现在最耗时的是哪一个子环节如果Agent给出结果业务方敢不敢直接照着执行不敢的话卡点在哪这个需求的成功标准是什么是“回答准确率97%”还是“处理时长下降50%”你能不能给我提供50条真实的、历史发生过的输入数据和对应结果前两个问题负责剔除“伪需求”后两个问题负责逼出“真边界”。举个我们实际的例子某部门提的需求是“做一个财务问答Agent让员工自己查报销规则”。当时听上去很像一个典型知识库问答我们差点就直接开干了。但做完上面这轮追问之后发现真实痛点根本不是“员工查不到规则”而是“财务每天重复回答同一类咨询占用了月底对账的时间”。需求翻译过来就变成把高频、标准化的咨询自动化人工只处理异常和复杂个案。这个翻译改变了整个项目的结构——我们做的不是一个“聪明”的问答机器人而是一条分流管道。Agent解决80%的常规问题剩下的20%带着上下文转给人工。上线后财务的工作量确实降下来了员工也没觉得体验变差。所以第一件事的答案不是什么技术选型而是一切从“哪个岗位的哪个环节最痛”出发而不是从“AI能干什么”出发。是需求牵引模型不是模型牵引需求。2. 第二件事业务部门不信任Agent根子在“责任划界”2.1 为什么业务方看着Demo说好却不愿意真用我们曾经给一个业务团队演示一个自动理赔初审Agent。演示现场业务负责人一边看一边点头说“这个好这正是我们想要的”。结果会后两周人家的真实使用率是零。我后来复盘了很久发现真正的原因不是“不好用”而是“不敢用”。在传统软件里系统给人提供的是“确定性结果”——你提交数据系统告诉你通过还是不通过出了错那是系统的事。但AI Agent不一样它给出的是“概率性答案”而且答案是自然语言生成的即使错了看起来也非常自信。业务方一旦照着执行出了问题责任在谁没有人愿意为一个自己控制不了结果的东西背书。这才是落地最难的一关。2.2 用“人机责任分界”替代“追求更高准确率”我们后来的解决办法不是继续追求把准确率从95%干到98%而是把Agent的职责边界砍到让人敢负责为止。这里的核心动作就是做一张“人机分界表”把流程里的每一个步骤都明确归为三类之一Agent全权处理、Agent建议人决定、人全权处理。我举一个实际的划分示例流程环节归属理由历史信息检索与初筛Agent全权处理检索错了容易追溯影响小标准话术生成Agent建议人决定涉及对外形象需要人把关客户情绪判断Agent建议人决定模型判断不准且责任大最终审批与签字人全权处理法律和财务责任必须落在人身上异常案件碎片信息提醒Agent全权处理多提醒一个不损失什么划完这张表之后我们又做了一件更关键的事为Agent的“全权处理”区域设置兜底机制。你允许Agent自动处理某些环节就要给它配一个“安全带”——比如自动拦截阈值、每N条抽样复核、风险词的强制人工转交。这样业务方心里有底就算Agent偶尔出错也有第二道网不会直接捅出大娄子。责任边界清楚之后业务方使用意愿会明显不一样。之前他们担心“这个AI是不是要替我做决定”现在他们知道“AI只是帮我跑腿决定还是我来做”信任感就慢慢建立了。2.3 让业务方“卷进来”比演示PPT有用得多还有一个经验值得单独说一下责任边界这件事不能由IT团队单方面定完扔给业务方一定要让业务方自己参与设计。我们第二期项目采用了“人肉扮演Agent”工作坊的办法效果出奇地好。具体操作是把业务方核心用户请到会议室给他们一份真实的历史工单列表然后让他们一个一个地去模拟Agent的整个工作流程——读取输入、检索资料、生成回答、给出建议。每个人轮流扮演整个过程走一遍。走完之后问他们三个问题刚才模拟的流程里哪一步你觉得自己做得最没把握哪一步如果让AI替你做你完全放心哪一步即使AI犯了错你也能接受并且有办法补救答案基本就是我们那张“人机分界表”的原型而且是业务方自己画出来的。后面再讨论SLA的时候阻力就小了很多。道理很简单人只会对自己参与设计的东西产生责任感。上线之后我们还定了一个规矩Agent产出的日志每周由业务方轮换review两个小时而不是IT团队自己闷头看。业务方在看日志的过程中会很自然地发现那些模型分数体现不出来的问题——比如话术不够礼貌、语气太生硬、某些隐含逻辑有问题。这比事后投诉要高效得多。3. 第三件事评测体系不是锦上添花是项目能不能迭代的命根子3.1 为什么传统软件的测试方法在Agent上全部失灵但凡做过传统软件测试的人第一次给Agent写验收用例时都会有一瞬间的恍惚到底怎么算“对”传统软件的输出是结构化的、可断言的登录失败就该弹一个特定错误码但Agent的输出是自然语言同一个问题每次生成的句子都不一样内容细节也可能有偏差。这就带来两个很实际的问题第一标准答案怎么定你拿一份人工写好的标准话术去比对AI的输出结果AI说得比标准答案还全面。你说它对还是不对如果算它错怎么评级别第二没有回归测试就没有迭代。传统项目改一行代码跑一遍用例就知道有没有改坏。Agent项目你改一段提示词表面看着没问题实际可能让10%的输入给出完全不同的回答。没有自动评测基线就只能在“不敢改”和“瞎改”之间二选一。第一版上线后我们就被这个问题狠狠坑过一次优化了某个环节的回答逻辑结果一周后用户投诉率反而上升了。原因是我们改动时只验证了20个精心挑选的Demo完全没做批量的回归对比。那之后我才意识到评测不是上线前的最后一道工序它应该和需求分析、责任划分一样放在最前面。3.2 我们最终搭的“三层评测”到底怎么用现在我们的评测体系分三层你可以直接参考这个结构第一层Bad Case回归集。凡是线上被用户投诉、被人工复核抓出错、被业务方明确标记“不能接受”的case都会被收进一个专门的回归集。每次版本迭代前团队必须拿着新老版本同时跑这一批case对比输出差异。如果修复了一个case却在另一个case上出现了退化就不允许发布。这一层解决的问题是“别再犯同样的错”。第二层能力维度层。我们给Agent的输出设置了几个固定的评分维度信息准确率是否包含错误事实、流程完整率该走的步骤有没有走完、话术合规率是否遵守企业表达规范、幻觉率是否编造了上下文里不存在的依据。每个维度独立打分互不抵消。某次回答就算信息准确率100分话术合规率只有60分也不合格。这一层解决的问题是“不只看平均分要看短板”。第三层线上用户反馈层。评分是内部视角用户反馈才是外部视角。我们会从线上日志里每周随机抽100条真实会话做人工打标用户有没有追问、有没有不满意、有没有弃用。这一层解决的是“我们觉得好用VS用户觉得好用”的偏差。3.3 一个评测体系容易踩的深坑被评测集绑架最后说一个比“没有评测”更隐蔽的坑评测集一旦建好就容易变成“只要过了就行了”的应试教育。我们曾经历过一个阶段团队为了把某项准确率指标刷到99%开始针对评测集里的固定题目“打补丁”——给某些特定问题写死最完美的答案。表面上看指标很好实际上模型严重过拟合换个问法立刻露馅用户体验断崖式下跌。后来我们加了两条硬规则一是评测集必须有“保质期”。每个季度至少更新20%的题目新题目来自线上真实日志谁都不知道评测集里现在有什么题。二是发布评审不看单个分数要看“新老case交叉对比报告”。重点观察改了这个case有没有让别的case变差而不是盯着一个数字自嗨。另外还有一个很重要的细节评测集要多放“边界case”和“反例”不要只放正常case。大部分团队建评测集时喜欢挑那些“正常人都会好好问”的问题比如“报销流程是什么”。但线上最暴露问题的是那些问得含糊、带错别字、夹杂着口语化表达、甚至情绪不好的输入。这些反例才是模型的试金石。4. 如果让我重新立项我会按这个顺序来投入复盘已经发生的事永远比预测容易。但踩过坑之后最大的收获其实是能画出一张“第二年再也不会走弯路”的路线图。如果现在让我重新接手一个企业AI Agent项目我不会再按“先写代码、再上线、再补评测”的老路走了我会反过来第一阶段需求翻译期2-3周。花时间做业务访谈不是做技术方案也不是做Demo。核心目标是回答三个问题哪个岗位最痛这个痛值多少钱业务方愿不愿意为Agent的结果负责第一阶段的产出不是一行代码而是一张责任分界表和一份伪需求排除清单。第二阶段责任划定期上线前。把“Agent全权处理”“Agent建议人决定”“人全权处理”这张表和业务方逐条签字确认同时建立兜底机制和异常升级通道。这一步不做完绝不进入开发。因为它决定了后续所有交互设计也决定了业务方愿不愿意真的用。第三阶段评测基座建设期与开发并行。放一个专门的评测工程师选一个对业务敏感、肯抠细节的人不一定是最懂算法的人去收集历史数据搭建Bad Case库和维度评分标准把回归流程嵌入发布门槛。这个环节在我第一年项目里的优先级被排得太低了是我最后悔的地方。第四阶段小步快跑上线期。先选一个最窄、最痛、责任最小的场景上线不铺多条业务线。跑一个月看线上真实日志让业务方来挑刺再迭代。一个场景跑顺跑出组织信任和评测基线再往旁边复制。如果你现在正处于“第0年”——也就是正准备立项、正在写规划书的阶段我有几句很实在的话想跟你说。不要把预算和精力全部压在“选哪个大模型”上。模型层是半年一变、快速贬值的资产真正沉淀下来的是业务方对AI边界的一致认知、一份持续更新的评测资产库、一套稳定的人机协作SLA。这些东西不换换模型分分钟的事这些东西没有换最好的模型也没有用。另外项目团队里一定要放一个懂业务且敢跟业务方吵架的人。技术再强的人如果只会写代码在业务方说出“都听AI的就行”这种话时是拦不住的而一个懂业务的人能在关键时刻提醒大家AI只是生产要素业务方和用户的判断力才是真正的资产。最后分享一个我们自己沉淀下来的小习惯每周五下午让业务方轮换着翻一遍本周Agent处理过的真实日志花一个小时不用写报告只要在有问题的记录上做个标记、写一句原因。这个动作看着简单但它坚持一段时间产生的价值比任何评测指标都大——业务方会主动跟你说“这个问题你的Agent搞不定我可以给你看为什么”然后你就能非常精准地知道下一步该优化模型还是优化流程。这个习惯一直延续到现在也是这一年里我认为最值得坚持的一件事。