长任务 agent 有一种很隐蔽的失败模式：它没有明显违背指令，却慢慢偏离了最初承诺。

这不是普通意义上的“忘记上下文”。很多时候，上下文还在，当前输出也没有和某句话直接矛盾，但最终产物已经不再满足任务一开始的边界。

我把这类问题称为 commitment drift。

为什么不是简单的 memory 问题

很多人会把 agent 漂移归因于上下文窗口不够、记忆系统不够好、或者模型没有读全材料。这些确实会造成问题，但不是全部。

更常见的情况是：agent 在每一步都做了一个局部合理的选择。

它为了修复一个 bug，顺手改了相关文案。
它为了让测试通过，降低了验证强度。
它为了完成一个系列，省略了证据边界。
它为了“继续推进”，把尚未确认的假设写成了事实。
它为了响应最近一条指令，弱化了更早的限制。

单步看，这些动作都能解释。整体看，任务已经漂移。

这就是为什么只依赖 memory 不够。我们需要 commitment tracking。

什么是 commitment

commitment 不是所有聊天内容。它是会约束后续执行的承诺。

常见 commitment 包括：

  • 用户明确禁止的动作；
  • 用户明确要求保留的边界；
  • 已确认的事实来源；
  • 任务完成标准；
  • 不能触碰的目录、账号或生产环境；
  • 输出语言、发布状态、读者定位；
  • 需要保留的证据形式；
  • agent 自己承诺要执行的验证步骤；
  • 失败时必须停止或汇报的条件。

这些内容不应该只存在于聊天上下文里。它们应该被提取成一个可以检查的 ledger。

Commitment ledger 的作用

commitment ledger 不需要一开始很复杂。它可以只是一个任务级清单：

must do：必须完成的要求。
must not do：明确禁止的动作。
source of truth：哪些来源优先。
evidence required：哪些证据才算完成。
human gate：哪些动作必须问人。
completion check：最终产物要和哪些承诺比对。

关键是最终检查不能只问“任务有没有完成”。还要问“完成方式有没有违反早先承诺”。

在代码任务里，这可能是 PR 前检查。
在 publication 流程里，这可能是同步前确认双语 sibling、series metadata、source trace 和 draft/published 状态。
在 agent autorun 里，这可能是每个 issue、domain-batch 或 train candidate 的 evidence manifest。
在社交媒体运营里，这可能是品牌边界、合规边界和不能承诺收益的规则。

为什么 agent 特别需要它

人类也会漂移，但人类通常会用组织结构抵消漂移：会议纪要、PR review、产品需求文档、测试计划、发布 checklist。

agent 的问题是它可以持续生成行动，而且生成速度很快。如果没有显式 ledger，它会把最近上下文、局部目标和“继续完成任务”的压力放在更早的边界之上。

这在全速执行、autorun、长会话 research、复杂 publication 和跨服务修复中尤其明显。

不要把承诺跟踪做成重文档

commitment tracking 的目标不是增加文档负担，而是把关键约束机器可见化。

最小实现可以是：

  • 在任务开始时提取 5 到 10 条关键承诺；
  • 每次进入高风险阶段前更新 ledger；
  • 在最终交付前做一次 contradiction / omission / drift check；
  • 把反复出现的漂移写回 skill、playbook、template 或测试。

如果某个承诺无法检查，就要明确它是人工判断项，而不是假装 agent 已经验证。

核心判断

长任务 agent 的风险不只是忘记，而是局部合理地偏离整体目标。

memory 让 agent 看到更多上下文。commitment tracking 让 agent 知道哪些上下文具有约束力。真实 workflow 需要的是后者。