数据、SOP、工具齐备，Agent 却总在关键时刻掉链子？本文直击 Agent 稳定交付的隐形杀手：评估缺失、状态丢失、约束软化。从失败率复利到审计轨迹，拆解从“能跑”到“稳交付”的工程鸿沟，为 AI 产品经理提供一份避坑指南。

我见过不少团队拿着一套”数据+SOP+工具”的口诀去造 Agent，造完上线，然后悄悄下线，对外的说法是”产品迭代节奏调整”。

真实原因很少被说出口：Agent 跑起来了，但不稳。今天对，明天错，没人说得清为什么。

我自己也犯过这个错误。早期做一个内容审核 Agent，数据有，流程文档有，工具接好了，自测 demo 跑得很漂亮。推给真实流量两周后，有个同事来问我：”这个 Agent 昨天把一篇没问题的稿子拒了，今天又把同一篇放过了——它到底在审什么？”

我盯着日志看了一下午。模型没有出错，工具没有故障，数据没有问题。就是稳不住。

那是我第一次意识到，”能跑”和”稳定交付”之间，有一条沟。

一、三样东西让你造出 Agent，但不能让你稳定交付

数据、SOP、工具——这三样是必要条件，不是充分条件。它们解决的是”能不能做出来”的问题。但”稳定交付”是另一个问题，是关于失败行为的问题。

先把”稳定”这两个字拆开。它不是”这次做对了”，是”每次都能做对，做错的时候还能安全地失败”。这两件事，前三样东西一样都不保证。

我用过一个很直观的算法算给自己看：一个多步工作流，每一步的失败率是 1%，跑到 100 步，端到端成功率只剩 36.6%。这还是理想情况，假设每一步独立失败。实际生产里步骤会互相污染——前一步的坏输出是后一步的坏输入，误差不是独立累积的，是复利式叠加的。

所以经常出现一种让人很沮丧的现象：你的模型没坏，工具没坏，数据没坏，系统就是崩了。

这不是在说那三样没用。它们是入场券。有了才能继续谈，但有了进不去门。

二、”我觉得还行”不是稳定，评估才是

这是最容易被跳过的一步，因为它的价值不直接可见，而且建起来真的很烦。大多数团队的”评估”是这样的：让几个同事试用一下，感觉 OK，就上线了。这不是评估，这是抽签。

更隐蔽的版本是每次出问题就改 prompt，改完自己跑几条看着顺眼了，再上线，如此循环，系统 prompt 越来越长，没有人知道哪句话在起作用，哪句话又在悄悄制造副作用。

真正的评估要先回答一个问题：什么叫对？这个问题比听起来难。Agent 不是函数，不能用”输入 A 必须返回 B”来断言。它是一连串自主决策，正确的最终答案可能建立在完全错误的推理链上。调错了工具，检索到无关文档，最后靠运气给出了合理答案——你把这个当成能力上线了，下次遇到同类问题，它大概率会失手。更难受的是，你不知道它会在哪条路上失手，因为你从来没有检查过它走的是哪条路。

所以评估集要评的不是最终输出，是完整轨迹：选对工具了吗？顺序对吗？工具调用参数对吗？处理工具失败了吗？越权了吗？多步任务里状态保持了吗？

我认识一个做企业 AI 的朋友，她们团队在正式上线前花了整整两个月建评估集，案例只有二三十个，但每个案例都非常具体——写清了什么叫做对、什么叫做错、边界情况怎么算。上线后稳定性比之前提升了三倍不止。她说那两个月是最不像”做产品”的两个月：没有新功能，没有用户增长，没有任何能写进周报的成果。但也是回报最高的两个月。

不过我也见过反例，让我没法把这话说满。另一个团队学她的方法，吭哧吭哧建了评估集，上线后照样出事。后来我帮他们排查，发现评估集里全是理想的请求样本，真实流量里那些脏话、碎句、错别字、一句话带三代人关系的问题，根本没进到评估集里。所以评估集这件事，光有”建”这个动作不够，还得知道它最该收集的是那些让你不舒服的输入。

还有一件事很多人没意识到的：评估集会随时间漂移。PoC 阶段建的测试集不再反映真实输入分布，分数虚高而生产在退化。真正让你心里有数的不是那个好看的分数，是你隔段时间就拿新数据回去测一遍的动作。这个认知本身就不容易接受——产品经理已经习惯”上线就交付了”，但 Agent 的交付是个持续过程。

三、状态丢失，是最容易被甩锅给模型的那个 Bug

我见过一个团队，Agent 在跑数据同步任务，同步到一半，Pod 被驱逐了。Agent 重启后从头跑，把已经同步过的记录重复写了一遍。没有报错，没有告警，一切看起来正常。直到下游系统的人来投诉，说数据对不上了。前后排查了三天。

这件事背后的根因，是我们习惯把 Agent 当无状态的微服务来部署——请求进来，响应出去，Pod 随时可以杀。但 Agent 不是这样工作的。它是有状态的、长时运行的工作流，资源消耗不确定，状态跨调用，延迟分布极不均匀。Pod 随便杀的代价，在传统服务上是”一次请求失败，重试就好”；在 Agent 上是”不知道做了什么、做到哪里、有没有副作用”。

我自己的第一个项目也是在这上面栽的跟头，出了事才补的持久化。当时我第一反应是甩锅给模型幻觉——开日志一看，模型从头到尾都正常，问题出在我压根没让它记住自己做到哪儿了。

成熟的做法是每一步都持久化：系统要知道已完成什么、在做什么、下一步必须做什么。崩溃了能从断点恢复，而不是从头开始，也不是留一个烂摊子在那里。实现上最简单的版本，就是把 Agent 每次工具调用的结果和中间状态写到外部存储，在 Agent 初始化时先读这个”进度表”。不复杂，但就是没人在 demo 里展示，所以没人在 PoC 阶段做，等进了生产才发现。

还有一个更难处理的问题：失败不能都触发重试。超时可以重试，但”API key 无效”重试几百次也没用——而且每次重试都可能产生副作用。真正要做的是一个受控的恢复流程，区分”暂时性错误”和”永久性错误”，给出不同的处理路径，而不是无脑重试。

四、兜底不能靠提示词

每次看到有人在系统 prompt 里写”操作前请务必确认””不要删除重要数据”这样的句子，我都替他们捏把汗。这是用建议代替约束。Agent 是概率系统，你用文字”建议”一个概率系统，它会在大多数情况下照做，在某些情况下不照做——而那些不照做的情况，往往是最关键的时候。

有个故事在业界流传了很久，我听到的版本是：一个好心 Agent 在凌晨 3 点重启了错误的 Pod。系统 prompt 里白纸黑字写着”操作前确认”，但在那次执行链里，它判断不需要确认。模型没有坏，逻辑没有坏，就是那个”请确认”的约束是软的。我后来注意到，几乎所有 AI 系统的权限都是给大了的——从”先给全权限，之后再收”开始走，而往往没有”之后”。

正确的做法是把兜底做成结构性的约束，不是提示词里的一句建议。三层：工具级访问控制，这个工具只能读，那个工具只能写特定字段；运行时沙箱，时间和内存有上限，系统调用受限；操作分类强制执行，查询放行，写入确认，删除默认拒绝——不是让模型去判断，是代码层面直接拦截。

而且 Agent 要有自己的身份。不是跑在某个员工凭据下的脚本——那会让 Agent 的所有操作都归到那个员工名下，出事了没人分得清是人操作的还是 Agent 操作的。成熟的做法是 Agent 是一等公民，有自己的主体、最小权限范围、可撤销的凭据、完整审计轨迹，每一次 prompt、每一次决策、每一个工具参数都链接到一个不可篡改的身份记录上。

审计轨迹事后无法补建。等出了事才去想”我们得知道 Agent 做了什么”，已经来不及了。

五、真正的壁垒，不是 SOP

很多人认为 SOP 是壁垒，因为 SOP 最难写，最难标准化。我之前也这么说，但这个判断我改了。

SOP 是有价值的，但它不是最终壁垒，因为它是一张会过期的流程图。没有配套的评估和可观测性，你根本不知道 SOP 还有没有在被执行，还准不准确，还适不适用于现在的真实流量。一张三个月没更新的 SOP，配上一个已经飘移的评估集，会给你一个完全虚假的”稳定”信号。

分界就在这：传统监控回答的是”系统还活着吗”——日志在不在、服务有没有响应、CPU 是不是正常。但 AI 系统还得回答另一个问题：”系统做得怎么样”。模型为什么这样回答、同样输入再来一遍会不会变、这个版本比上个版本好在哪里、这批请求的平均质量是多少——这些问题，传统体系一个都答不了。

真正不可迁移的是三样工程能力：基于真实生产数据建起来、随业务一起演进的评估集；撑得住崩溃和部署滚动的状态持久化工程；以及能回答”系统做得怎么样”的可观测性，不是 CPU 图，是执行轨迹记录。

这三样东西，每一样都要花时间，都看不见直接产出，都很容易在排期里被砍掉，因为它们不产出新功能。这才是真正卡住大多数 Agent 的地方——不是数据不够，不是工具不行，是这玩意儿的价值不知道算在哪个指标里，所以没人抢着去做。

还有一道文化坎。软件工程师看到失败，第一反应是”这是个 bug，要修”。ML 的人跑实验，接受一部分失败，继续往前。两种心态都没错，但放在 Agent 身上混用，会造出一种很有破坏力的模式：Agent 出错了，反应是加 prompt，加完自测一下感觉好了，上线；生产里又出错，再加 prompt；再出错，再加。几个月后，系统 prompt 比实际业务逻辑还长，没人知道哪句话在起作用，也没人敢改。这不是 Agent 的问题，是团队没有建起评估的验证机制，用”感觉”代替了”验证”。

最后

造出来是 demo 的问题，稳定交付是生产的问题。让这两件事连起来的，不是更好的模型，也不是更多的数据——是一个能回答”什么叫对”的评估体系、一个崩溃了也知道自己在哪里的执行层、一个从结构上约束高风险操作的兜底机制，还有一套能告诉你质量在不在退化的可观测性。

这几样都不产出新功能。上线前两周没人发现它们，出事之后所有人都意识到它们一直缺着。

Agent 失败的方式和传统软件不一样——它不报错，它悄悄地、看起来很合理地、做了一件错误的事。

我也不一定全对，欢迎来评论区拍。