跳转到主要内容

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

阅读需 1 分钟Tian PanTian Pan

值班轮换制度是建立在一个承诺之上的:故障是可以复现的。警报触发,你重新运行请求,观察 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 调用可以被撤销。对于不可逆的操作 —— 付款、已发送的消息、已发布的文档 —— 技术上没有撤销键,因此运行手册必须指定替代方案:客户沟通模板、补偿措施、或吸收损失的财务储备。“回滚”被一套关于什么可以撤销、什么不能撤销的分类体系所取代。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

随机系统的值班响应:为何你的 AI 运行手册需要重写

传统故障响应假设故障是可复现的,但 LLM 驱动的系统并非如此。以下是如何针对非确定性 AI 重写告警方案、分类决策树和事后分析模板。

insider
ai-engineering
阅读需 10 分钟

没人会写的 AI 系统 On-Call 运维手册

当故障模式是概率性的模型行为而非服务崩溃时,传统的 SRE 运维手册就会失效。本文将探讨 LLM 驱动系统的事故响应究竟是怎样的,以及哪些信号值得告警。

insider
ai-engineering
阅读需 8 分钟

让 Agent 先接警:AI 故障响应的信任阶梯

故障发生的最初 15 分钟通常是机械化的,Agent 可以在你解锁笔记本电脑前就完成这些工作。这套由叙述者、建议者、受控执行者、受限自动修复者组成的四层信任阶梯,配合基于证据的晋升和有范围的降级机制,比在经历一个糟糕的夜晚后彻底禁用自动化要明智得多。

insider
incident-response
阅读需 9 分钟

你的故障指挥官无法执行的智能体运行手册

大多数智能体运行手册在白天读起来很顺畅,但在凌晨 2:17 运行时却会被阻塞,因为作者拥有值班 SRE 所不具备的访问权限。联邦化、声明式范围、紧急访问端点和演练才是解决之道。

ai-agents
sre
阅读需 10 分钟

一次导致所有运行中 Agent 任务失效的 Prompt 热重载故障

在晚上 11:46 进行了一次正常的 Prompt 推送,一分钟后却出现了由于幻觉导致的退款 —— 深度解析为什么在 Agent 运行期间,Prompt 注册表需要将会话视为契约而非缓存。

insider
ai-agents