升级规则：唯一的配置更改让我们的代理真正有用

Source: Dev.to

没有升级规则会怎样

每当代理遇到它不确定的情形——模糊的数据、冲突的指令、超出其范围的边缘案例——它都会尽力而为并继续前进。

“尽力而为”意味着猜测。而这些猜测会悄悄累积。

代理看起来很健康。日志显示有活动。任务在完成。但输出在十几个细小的方面悄然出错，我们直到它们叠加后才发现。

解决办法：一行代码

If uncertain about how to proceed, stop. Write current context, the uncertainty, and attempted approaches to outbox.json. Do not continue until reviewed.

就这么简单。向代理的 SOUL.md 中添加了一条规则。

发生了什么变化

加入升级规则后：

• 静默错误下降约 80%
• 代理的“错误”变得可见、可审查、可修复
• 我们捕获了三类之前未设计的边缘案例
• 调试时间下降，因为我们准确知道代理卡在哪儿

之前： 代理产生错误输出，我们只能从下游影响或用户投诉中发现。
之后： 代理在不确定的节点停下来，写入上下文，我们审查并修复该边缘案例。

outbox.json 的模式

当代理升级时，它会写入 outbox.json：

{
  "timestamp": "2026-03-09T10:30:00Z",
  "task": "process Q1 revenue summary",
  "uncertainty": "found two conflicting totals in input files",
  "attempted_approaches": [
    "checked both files — different values for same line item",
    "checked timestamps — both recent, no clear winner"
  ],
  "context_snapshot": "state/current-task.json",
  "awaiting_review": true
}

该 outbox 文件在不破坏代理当前上下文的情况下暴露问题。你可以审查、修正输入并干净地重新启动。

为什么有效

代理会静默失败，因为它们没有处理不确定性的协议。它们的设计目标是完成任务，所以即使不该完成也会完成。

升级规则为代理提供了除“完成”和“错误”之外的第三种选择：停下来并暴露。

响亮且结构化的停顿总好过静默的错误完成。

SOUL.md 规则模板

ESCALATION RULE:
If uncertain about how to proceed and confidence is below threshold:
  1. Stop current task execution
  2. Write to outbox.json: task, uncertainty, attempted approaches, context snapshot path
  3. Set awaiting_review: true
  4. Do not continue until outbox is cleared

Confidence threshold: cannot determine correct action from available context

还有一点

升级规则通常会配合断路器使用。如果你的代理不断碰到同一边缘案例，断路器会终止循环。升级规则则说明了原因。

二者结合，能够把静默失败转化为可见、可修复的问题。

完整模式（含置信阈值和多代理升级链）：askpatrick.co/library/18