笔记摘自：黄佳老师的极客。

让每一步的局部噪音被隔离在子上下文里，目标、状态和机械参数不随链式传递漂移。

这就是 Agent 时代的工业界解决进度追踪问题的主流方案，也是编排和链式的分界。如果让子 Agent 把自己的本地消息、重试、中间失败一股脑灌回共享上下文，主 Agent 很快就会被污染。所以进度状态要由一个协调者集中维护，让每一步的局部噪音被隔离在子上下文里，目标、状态和机械参数不随链式传递漂移。

三个调度收敛器：复诵、哨兵、闸门

1、复诵（Recitation）：

一个典型复杂任务平均要调大约五十次工具，这么长的循环，Agent 很容易偏题。Manus 的做法是不断重写 todo.md，把全局计划反复推回上下文的尾部。

2、漂移哨兵（Drift Watchdog）：

光让 Agent 自己写进度还不够，要有一个哨兵定期问：你现在做的事，还跟原目标有关吗？它可以先做得很简单，每隔固定步数或每个里程碑结束，用一个便宜模型或几条规则看几个分数：当前动作和原目标的相关度、当前里程碑有没有推进、关键结论有没有证据、最近错误是不是在累积。信号异常时不一定要终止任务，可以分级处理：相关度下降就触发复诵，里程碑停滞就要求缩小范围，证据变差就禁止汇报完成，错误压力上升就暂停进入诊断。

3、验证闸门（Verification Gate）：

长任务最怕“看起来很努力，结果没验收”。闸门要把每个里程碑的验收条件落成具体检查：快照人数等于员工范围吗，金额波动在可解释范围内吗，异常项都标出了吗，关键 id 都有 Provenance 吗，高风险动作还 blocked 吗，待人审清单生成了吗。不通过就置成 needs_rework，写一条 failed_gate 事件，回到对应里程碑，不许进入下一阶段。

很多企业长程 Agent 失败，就是因为没有闸门，从一个阶段自然滑到下一个，上一阶段的错误也自然跟着传递过去。这就是 Agent 时代的 Saga 补偿思路的具体实现。

断了怎么接上：进度追踪的恢复