★ FEATURED ARTICLE 过去一年我密集参与并旁观了不少 AI Agent 项目听到最多的一个数字是 89%——大概九成的 Agent 试点走不到生产环境直接倒在了“量产关”门口。这个数字第一次看到时我挺震惊但回头复盘自己手里的项目发现一点也不意外。Demo 阶段跑得飞起的智能体一旦面对真实流量、真实权限、真实成本问题会像潮水一样涌出来。这篇文章我想认真拆一拆89% 的试点到底死在哪一步试点和生产之间隔着的为什么是深沟而不是浅坑现在市面上说的“补位”补的又是什么最后我会把自己把一个客服场景 Agent 从 POC 推到生产的实操记录、踩过的坑和改造清单完整写出来。如果你正在带团队做 Agent 试点或者刚被领导指派去评估“我们是不是也上一个 AI Agent”这篇文章应该能帮你少走至少两个月的弯路。1. 89% 的“生产门口”翻车率问题出在 Demo 与产线之间的认知差1.1 演示环节很惊艳生产环节很骨感我参加过很多次 Agent 项目的技术评审会。会上大家会搭一个临时环境输入几个精心设计的测试问题Agent 一步步规划、调用工具、生成结果屏幕前所有人眼睛发光。但等这个 Demo 真正接进生产系统面对真实流量和真实用户输入时画风会立刻变掉。不是模型变笨了而是环境变了。Demo 里的问题数量少、表述规范、意图单一生产里用户的问题千奇百怪有错别字、有口语、有歧义、有多轮跳转。Demo 里工具返回的永远是构造好的干净数据生产里第三方接口动不动超时、返回异常字段、甚至悄悄改了协议。Demo 里跑 20 个问题有一两个表现不佳可以归类为“调参问题”生产里每天跑几千次调用1% 的偶发失败也会变成每天几十次的真实故障。我一直觉得“试点”这个词本身就有点误导。很多团队号称在做试点实际上做的是“技术验证型 Demo”验证了 Agent 能跑通却完全没有定义“生产成功”的标准。没有标准自然无法走向生产项目最后停在某个漂亮的演示版本上团队成员各回各家领导问起来只能说一句“还在试点中”。1.2 团队普遍忽视的三层断层那层让 89% 试点翻车的断层我拆成三层来看每层都很隐蔽。第一层是数据分布断层。Demo 测试集通常是从少量人工构造的问题里选的它们往往集中在一个“合理范围”内。但生产环境的输入是长尾的真实用户不会按你的预期提问。一个客服场景的 Agent我见过测试集里 90% 是“怎么退换货”“订单在哪查”这类标准问题上线后最热的问题却变成“之前那个优惠券为什么用不了”“你们是不是骗人”这种带着历史上下文和负面情绪的输入。这一下就把模型打得措手不及。第二层是系统链路断层。Demo 里 Agent 通常只对接了一两个内部接口甚至直接查数据库。生产环境里至少涉及权限校验、限流控制、审计日志、敏感信息脱敏、多个微服务之间的调用链。其中任何一环没接通Agent 都跑不起来。更麻烦的是这些系统约束在 Demo 阶段根本不会被触发也就没人提前做一些适配。第三层是验收手段断层。Demo 靠的是人眼观察“看起来回答得不错”就算通过。但生产环境需要一套机器可校验的指标体系比如任务完成率、工具调用成功率、平均轮次、人工干预率。没有这套指标你无法判断一次升级是变好了还是变坏了更不用说建立回归测试。这三个断层叠加在一起就等于一个团队花两个月搭了一个精致的“温室花朵”然后直接把它丢到野外。89% 倒在生产门口我觉得不是模型能力不够而是大多数项目根本没有完成从温室到野外的工程化迁移。2. 拦住 Agent 量产的四条深沟评测、稳态、安全、ROI2.1 没有生产级评测基准Agent 就无法被验收第一个深沟是评测。传统软件上线前会有完整的测试用例、单元测试、自动化测试但很多 Agent 项目在试点阶段完全是“人工打分”。这在 Demo 阶段没问题但到生产阶段就是灾难。Agent 的输出和传统函数不一样它有随机性。同一个问题温度调高一点、换一次调用回答可能就完全不同。没有一套稳定的评测集合你连“这次改动到底有没有把效果改差”都判断不了。我在项目里的做法是先把线上真实请求收集起来分场景构造评测集每条评测样本标注好标准答案或关键判定点。然后定一套可量化的指标至少包含这五项指标口径说明任务完成率成功完成任务 / 总任务数核心指标定义口径要写清楚什么算“完成”工具调用成功率工具调用成功次数 / 总调用次数反映 Agent 对工具的操控能力平均轮次总对话轮数 / 任务数轮次过多说明效率低要小心死循环人工干预率转人工次数 / 总任务数生产阶段最重要的兜底信号端到端时长任务开始到结束的时间用户体验的直接体现每项指标背后都有一套口径定义不能含糊。比如“任务完成”到底是指用户确认问题解决还是 Agent 给出了回复就算完成我这里采取的是“以结果为准”客服场景以工单关闭或用户明确结束为准文档场景以输出文件通过格式校验为准。评测集建好之后每次改提示词、换模型、调参数都要把同一套评测集重新跑一遍对照指标变化。这一步在传统软件工程里叫回归测试在 Agent 项目里同样必不可少。2.2 单轮正确不等于长程可靠状态管理是隐形杀手第二个深沟是长程稳定性。很多 Agent 在单轮问答里表现非常出色问题拆解、工具调用、结果整合都很好。但一旦进入多轮任务比如“我要对比这三个方案并且把前两个方案里关于成本的部分重点分析”问题就开始暴露。多轮任务的第一个陷阱是上下文管理。模型有上下文长度限制长对话必然涉及截断或压缩。很多项目直接在早期调试时用最简单的“保留最近 N 轮”结果 N 轮之前的信息被截掉Agent 忘了用户最开始说过“预算不能超过五万”后面推荐方案时给出了超出预算的选项。用户会非常不满因为你看起来“记忆力不行”。还有一种是重试风暴。生产环境的第三方接口不可靠偶尔超时、偶尔返回异常。Agent 的自主性在这种时刻会放大问题——它可能会发起一连串重试甚至把同一个订单提交两次造成业务数据混乱。我在文档处理场景里就亲眼见过 Agent 在一个 OCR 接口超时后循环调用把云账单烧出了一个大坑。解决办法是把传统后端系统的稳定设计引入 Agent 架构给长时间任务加检查点和断点续跑能力状态持久化到数据库而不是放在进程内存里工具调用统一走网关设置超时、熔断、幂等控制对失败分支要设计明确的降级路径不要无限重试。状态管理这件事本质上和做后端服务没有区别只是很多人被 Agent 表层的神奇能力吸引了忽略了底下还是那套分布式系统的老问题。2.3 Agent 一多权限边界就失控第三个深沟是安全。传统软件里是“人点击按钮系统执行命令”人的每一次操作都经过内部的对错判断。但 Agent 是“机器理解意图机器自主调用工具”这意味着模型直接站在了决策链条上权限如果放得太松会出大问题。一个常见事故模型是这样的团队为了让 Agent“能力更强”给它接了一堆工具的写权限。演示时看起来无往不利但生产环境下用户的一句“帮我把这个订单的状态改成已完成”可能就会触发 Agent 真实地修改业务数据。如果用户本身没有这个权限系统又没有在 Agent 调用工具时做二次校验那这就是一起严重的数据安全事件。我在生产项目里坚持三条底线工具权限最小化每个 Agent 只能调用完成任务所必需的工具能读就不给写能只读特定字段就不给全表权限审批闸口涉及资金、合同、订单状态变更等高风险动作Agent 可以生成建议但必须通过人工确认后才能真正执行全量审计日志Agent 的每一次输入、工具调用、输出、转人工记录全部落库出现问题可以完全回放。这套设计会让 Agent 看起来“没那么自动”但从生产角度看它才是真正可用。用户的耐心是有限的权限事故一次就足以让整个项目被叫停。2.4 算不清 ROI业务不会为“技术惊艳”持续买单第四个深沟是 ROI。任何一个 Agent 项目如果不能在账面上讲清楚“省了什么”“花了多少”业务部门的热度撑不过两个季度。很多团队算账的方式太理想化只算“自动化后省了几个人力”不算“开发这个 Agent 花了几个月”“每个月模型调用费多少”“人工兜底的人力和训练成本多少”。真实的投入至少有四项模型 API 成本、开发团队人力、评测和迭代人力、兜底人工成本。反过来说也不是所有场景都适合上 Agent。我用一个简单的公式做前期判断自动化一个任务的年收益 单次任务的人工成本 × 年任务量 × 可自动化比例上 Agent 的年总成本 模型调用成本 开发成本摊销 评测迭代成本 兜底成本两个数一对比低于阈值的场景直接不做。高频、规则相对灵活、错误容忍度可控的场景适合 Agent低频、强合规、错误代价极高的场景我建议你们冷静一下先做传统工作流等 Agent 的生产工具链成熟了再回头评估也不迟。3. 站在这场补位赛里的是一整套工程化角色3.1 补位第一层可观测与运维Agent 不能再是黑盒传统软件上线后有 APM应用性能监控能看到每个接口的耗时、错误率、调用链。Agent 项目在这块长期是空白。模型内部怎么思考的工具调用为什么失败哪一步导致结果出错全凭开发者猜。Agent 的可观测性要从四个层面做记录输入输出、追踪思考过程、记录工具调用链路、记录人工干预。四层数据完整之后才能支撑“回放”能力。我见过一个比较成熟的做法是每次 Agent 运行都会生成一个 trace_id从用户进入开始到最终结束中间所有环节都关联到这一个 ID 上。出问题时直接按 trace_id 查全链路比对着日志猜快得多。可观测体系还有一个作用——产品经理终于能拿着数据去跟业务部门开会了。“这个月 Agent 完成了 3400 个任务人工干预率 9%平均处理时长 4 分钟远远低于人工处理的 12 分钟。”没有数据这类汇报就只能靠嘴讲。3.2 补位第二层确定性编排把 LLM 关进“笼子”很多人一想到 Agent就想到“全自动、完全自主”。但生产环境恰恰需要把不确定性控制在一定范围内这就催生了混合架构确定性的部分交给工作流引擎不确定性的生成和决策部分交给大模型。一个典型设计是流程编排器负责固定的分支逻辑、状态流转和审批节点大模型只负责理解用户意图、生成回复文本、从非结构化文本里抽取关键信息。比如工单分类场景流程是固定的接收工单 → 大模型识别类别和优先级 → 编排器根据结果路由到对应团队 → 涉及退款时先走人工审批。整个过程里模型只是分类器和文本理解器它没有权限直接触发退款操作。这种“编排器 模型节点”的方式会牺牲一定的自由度但换来了可控性。生产环境永远优先考虑可控其次才是智能。还有一个容易被忽略的设计是“守门员节点”。Agent 完成一个高风险动作之前必须经过一个独立校验环节判断权限是否符合、参数是否合法、是否在业务白名单内。守门员本身不属于 Agent 的一部分而是外部系统这样即使 Agent 模型出问题也不会悄悄绕过安全限制。3.3 补位第三层评测与数据回流让 Agent 越用越稳Agent 上线不是终点上线之后评测集要持续更新。最简单有效的数据来源就是线上日志。我一般要求团队每周从生产日志里抽一批句子补充进评测集特别是那些产生人工干预、用户差评、超长轮次的案例。它们就是 Agent 最真实的“错题本”。把这些“错题”不断加进评测集再定期重跑回归你就能清晰地看到 Agent 是在进步还是在退步。这里有一个细节评测集需要防止过拟合。如果只用上线第一周的数据反复调优模型很可能会对那批特定的输入产生记忆性适配之后遇到新的输入又失效。所以评测集要有意识地留出一部分“新样本区”每次都是最新一周的日志生成补充集再混合历史核心集一起跑。数据回流的另一层是用户反馈。客服场景里用户点“有帮助/没帮助”可以进入训练数据内部场景里人工修正后的答案也应该回收到评测集。数据越滚越多评测集就会变成一个越来越难被“刷过”的高质量考卷。3.4 补位第四层人机协同的新岗位兜底不是丢人试点阶段可以全靠工程师盯着生产阶段必须把“人”正式设计进系统。我在多个项目里观察到凡是成功走向量产的 Agent 团队组织里几乎都会出现几个新角色Agent 评测工程师、提示词运营、AI 运营专员、兜底客服/审核员。有一个经验非常有价值不要追求 100% 的自动率。把目标设定在 85% 自动完成、15% 转人工你会发现系统的稳定性大幅提升用户体验反而更好。因为那 15% 的疑难杂症被专业人工接住了用户不会感受到“被 AI 敷衍”。人工兜底不是打补丁它是量产架构里的一等公民。设计转人工时要考虑四个问题什么时候转置信度阈值、怎么转带上下文无缝转接、谁来接专门的兜底人员而不是普通客服、转接后的数据怎么回流人工的结果要能反哺评测集。这套机制做得越扎实Agent 的可用性越高。补位缺口补位角色核心职责评测验收评测工程师 / 评测集体系建评测集跑回归定义生产就绪标准稳定性编排层 / 工作流引擎状态管理、容错重试、断点续跑安全合规权限网关 / 审批闸口最小权限、风险动作拦截、审计日志成本控制模型路由 / 成本分析token 降级、模型选择、用量监控组织兜底AI 运营 / 人工兜底团队转人工、打标签、反馈标注、结果回收4. 把试点推进生产线的实操记录改造清单与真实踩坑4.1 从 POC 到生产这七项架构改造是必修课我在把一个客服场景 Agent 从试点推向生产的过程中整理了一份改造清单。它从左到右基本对应着从“能跑”到“能上线”的每一步维度试点阶段生产改造提示词硬编码在代码里版本化配置支持热更新和回滚模型调用单一模型直连模型路由 降级策略会话状态进程内存存储持久化存储断线可恢复工具访问绕过权限直连接口统一网关权限校验限流熔断评测验证人工抽查评测集 回归流水线日志追踪本地 print全量链路追踪 回放能力人工兜底现场临时盯分级转人工策略自动切换提示词版本化是很多人容易忽略的一步。试点阶段提示词经常改直接改代码也能跑但生产环境里提示词就是规则它会影响每一次调用。不版本化出了问题就没办法快速回滚到“昨天那个好版本”。模型路由这块我的做法是配置一个“主力模型 备用模型”的组合。主力模型效果好但贵、有频率限制备用模型便宜但效果略差。主力模型调用失败或超时自动降级到备用模型保证业务不中断。用户根本感知不到但 SLA 就能稳稳守住。4.2 三个真实踩坑记录每个都是拿钱买来的教训先讲一个评测集造假的坑。我们早期为了赶上线把演示环境构造的 300 条测试用例当评测集跑完指标非常漂亮任务完成率接近 95%。结果一上生产真实任务完成率直接跌到 60% 出头。后来一分析评测集里全是“规范输入”用户真实输入里有大量错别字、口语成分和上下文省略那些测试用例根本没覆盖住。这之后我强制要求评测集必须以真实日志采样为主人工构造为辅比例至少七三开。第二个坑是长对话漂移。客服 Agent 上线三周后有用户反映“聊到后面它好像忘了最开始说过的话”。查下来发现是我们上下文压缩策略做得太粗暴只保留最近 10 轮对话而用户在第 2 轮提过一个关键诉求“必须今天发货”到了第 15 轮 Agent 已经完全不知道这个信息。解决方案是把关键信息做独立持久化槽位比如用户核心诉求、订单号、约束条件单独存储并在每一轮注入提示词而不是全部依赖对话历史压缩。这个改动之后长对话漂移问题基本消失。第三个坑是权限事故。我们有一版 Agent 为了“增强能力”给它接了一个写接口。内测时它表现正常但一次真实调用里用户说“帮我清空购物车里的测试数据”Agent 直接调用了写接口把一批非测试状态的条目也删掉了。幸好我们提前做了审计日志事后能完整回放是哪一个 tool call 出了问题。之后所有写操作全部收回到人工审批闸口再也没发生过类似事故。4.3 算一笔真实的月度成本账很多人对 Agent 的成本没有概念我拿一个真实场景给大家算一笔账。假设一个客服 Agent 每天处理 3000 次会话平均每次会话消耗约 1.5 万输入 token 加 3000 输出 token按当前主流大模型 API 的典型价格估算成本项月估算模型 API 调用含输入输出约 2.5 万元评测集回归跑测每周跑 2 次约 0.4 万元人工兜底按 10% 转人工每人日处理 300 单约 2 名客服成本开发与维护摊销2 名工程师半投入约 2 万元合计月成本约 6 万元上下对比一下如果这 3000 次会话全部由人工客服处理按每人每天处理 120 单计算需要 25 个人左右的团队。按中位数薪资月成本大概是 12 万到 15 万。两者一比Agent 方案在经济账上是划算的但前提是转人工率控制在 10% 左右。如果你的方案转人工率高达 40%那经济账基本就打平甚至亏了。这个计算模型可以套用到你手头的任何场景。先算账再立项别被“技术潮流”四个字冲昏头脑。5. “谁在补位”我的答案以及给打算冲量产团队的三条建议5.1 我的判断补位者不是某个平台而是整套工程化体系行业里现在有很多团队在期待“一个神奇的 Agent 平台”出现装上之后一切自动搞定。我不信这个东西存在。Agent 生产化不像装一个数据库它的难点在于评测、稳定、安全、成本和组织协同五位一体少了任何一块都转不动。所以“谁在补位”这个问题我的答案是补位的不是某一家平台而是一群把自己原来的经验搬到 Agent 领域的人。做可观测的人把 APM 的思路带过来做后端的人把熔断、限流、幂等带过来做测试的人把回归测试带过来做安全的人把权限最小化和审计带过来。这些成熟的工程习惯迁移到 Agent 项目里才是把 89% 慢慢往下降的真实力量。5.2 给正在做 Agent 试点的团队三条建议第一条建议上线之前先定义“生产就绪标准”。不要等领导问“能不能上了”才想这个问题。我的标准很简单——任务完成率不低于某个基线、人工干预率不高于某个阈值、高风险操作 100% 走审批、全链路日志 100% 可回放、评测集回归通过。五条标准写进文档缺一条都不算生产就绪。第二条建议第一版必须包含人工兜底功能。不要想着先把自动率做上去再补兜底那个顺序是错的。兜底设计要一开始就在架构里它是系统的安全带不是后装的选配件。第三条建议试点期就要开始积累评测集。很多团队试点期只顾着调提示词测试用例随手记在文档里丢掉也不心疼。等你跑到第 4.1 节那个阶段再回头建评测集损失的是几个月的历史数据和经验。线上日志是你最便宜、最真实的金矿从第一天开始存。最后再分享一点个人体会。我做完第一个生产级 Agent 之后最大的感受是Agent 本身并不难做难的是让它在一个充满噪音、异常、权限限制和不完美数据的环境里持续稳定地工作。那 89% 不是模型的失败是工程系统成熟度的映射。希望我的这份记录能给正在做试点的团队提供一份可以照着改的清单哪怕只帮你们少踩一个坑这篇内容就值了。
阅读完成 · 觉得有帮助？
