当 Agent 出错时谁会被呼叫：针对非确定性系统的轮值制度

值班轮换制度是建立在一个承诺之上的：故障是可以复现的。警报触发，你重新运行请求，观察 Bug 发生，找到错误的提交 (commit)，然后回滚部署。这个循环的每一个环节都假设了确定性 (determinism)。同样的输入产生同样的输出，而输出要么是对的，要么是错的，其方式一目了然。

Agent 集群悄无声息地打破了这条链条上的每一个环节。故障发生了一次，其采样温度 (sampling temperature) 你无法重现，所处的上下文窗口 (context window) 也早已被垃圾回收。这里没有“错误的提交”，因为代码从未改变 —— 改变的是模型，或者是检索到的文档，再或者是用户措辞的方式超出了所有人的预料。你回滚了部署，但部署从来都不是问题所在。

于是警报发出了，一名工程师接手了。他们发现了在生产环境中运行 Agent 最令人不安的事实：他们拿到手的是一个无法单步执行 (single-step) 的系统，而摆在他们眼前的运行手册 (runbook) 却是为另一种完全不同的机器编写的。

为什么“先复现，再修复”的模式会崩溃

传统的调试是一个搜索过程。你有一个导致失败的输入，你有一个确定性的系统，然后你进行二分查找：缩小代码路径，缩小数据范围，直到缺陷被逼入死角。这个过程之所以能结束，是因为每一步都是可重复的。

Agent 违反了这个前提。同一个提示词 (prompt) 采样两次，可能会遵循两条不同的推理路径，调用不同的工具，并得出不同的答案 —— 一个正确，一个错误。重新运行请求并不能复现故障；它只是从分布中抽取了一个新的样本。你不是在通过二分法定位 Bug，而是在玩一台老虎机，并祈祷它掉出同一个错误的结果。

这比听起来更重要，因为它颠覆了调试的经济学。在确定性系统中，昂贵的部分是寻找故障，而廉价的部分是确认修复。在 Agent 系统中，从总量上看，故障可能很容易观察到 —— 你的仪表盘显示错误结果增加了 3% —— 但单个实例几乎无法按需召唤。你无法修复你无法让它再次发生的事情。

此外，也没有值班工程师传统意义上的“回滚”。回滚 Agent 部署并不能撤回它已经发送的电子邮件、已经发放的退款或已经写入的数据库迁移。在 Agent 调用工具的那一刻，爆炸半径 (blast radius) 就已经逃逸出了系统边界。事故不再是“服务宕机” —— 而是“服务做了七件事，其中三件是错的，而其中两件无法撤销”。

运行手册必须重写

针对确定性系统的运行手册是一系列确定性的动作：检查这个仪表盘、重启这个进程、回滚这个提交。在 Agent 事故面前，这些步骤一个也站不住脚。运行手册需要融入三种新的规范。

故障发生时捕获状态，否则你将一无所获。 因为你以后无法复现故障，唯一的调试凭证就是故障发生时你记录下的内容。这意味着实际组装的完整提示词、检索到的上下文、工具调用参数和响应、模型及其版本字符串，理想情况下还包括采样参数。运行级别的追踪 (run-level trace) —— 每个请求一个追踪，记录每个规划步骤、工具调用和模型调用的跨度 (span) —— 能将不可复现的 Bug 转变为事后可读的具体记录。没有它，事故后的调查就是没有文物的考古。飞行记录仪不再是“可有可无”的配置，它是 Agent 调试的整个基石。

将升级流程设定为“调整提示词或评估集 (eval)”，而非“回滚提交”。 补救的动词变了。当 Agent 出现退化时，修复手段很少是代码回滚。通常是向评估集添加失败案例、优化工具描述、限制 Agent 权限或调整系统提示词。运行手册的升级梯级应该明确命名这些操作，因为一个习惯了“回滚提交”的工程师，在看到干净的 git log 时会感到无从下手。

将模型供应商的退化视为无法打补丁的上游事故。 有时故障根本不在你的系统中。供应商可能会在稳定的 API 版本字符串背后偷偷更新模型权重、重新校准安全过滤器或更改解码默认值。你的代码没变，但行为变了。运行手册需要为此准备一个分支：如何确认它（将当前输出与冻结的参考集进行对比）、如何缓解它（如果存在则固定到较旧的快照，路由到备用模型，加强输出验证），以及接受你可能只能等待的事实。这在运维上相当于一个你无法 fork 的依赖项。

对于 Agent 已经执行的操作，运行手册需要一个按可逆性组织的遏制方案。在供应商支持的情况下，幂等 (idempotent) 的 API 调用可以被撤销。对于不可逆的操作 —— 付款、已发送的消息、已发布的文档 —— 技术上没有撤销键，因此运行手册必须指定替代方案：客户沟通模板、补偿措施、或吸收损失的财务储备。“回滚”被一套关于什么可以撤销、什么不能撤销的分类体系所取代。

加载中…