Agent设计模式(五)记忆模式——进度追踪(Progress Tracking)
笔记摘自黄佳老师的极客。让每一步的局部噪音被隔离在子上下文里目标、状态和机械参数不随链式传递漂移。这就是 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 补偿思路的具体实现。断了怎么接上进度追踪的恢复