开头先说个背景：我去年接了一个企业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搞不定，我可以给你看为什么”，然后你就能非常精准地知道下一步该优化模型还是优化流程。这个习惯一直延续到现在，也是这一年里我认为最值得坚持的一件事。
