和 Agent 多轮协作久了，会遇到一种安静的失败：它一直很忙，工具也在调，中间步骤看起来都“合理”，可收工时你发现——干的已经不是你起初要的那件事。 我把这叫目标漂移（goal drift）。不是偶发幻觉那么简单，更像是上下文变长后，约束被一步步冲淡。
这篇文章记我怎么发现漂移、怎么在过程中拉回，以及设计 Agent 时能做哪些防漂。
漂移长什么样
常见几种面孔：
- 范围膨胀：你要修一个空指针，它开始顺手重构邻近模块
- 目标替换：你要“调查原因”，它直接“提交修复”
- 成功标准偷换：你要“测试通过”，它变成“代码看起来更干净”
- 用户口头补充被遗忘：第三轮你说“别动数据库”，第十轮它写了迁移脚本
每一步单独看都有道理：重构有益、修复积极、干净也好。合起来却违背委托。危险在于局部合理、全局偏航。
图：目标漂移四种脸：膨胀、替换、偷换、遗忘（原创示意图）
为什么多轮特别容易漂
我的个人理解（含推测）：
- 近期上下文权重更高：模型更贴最近几步的“惯性”，早期约束变淡
- 工具反馈会改写议题：搜到一个有趣文件，注意力就被吸走
- 你的含糊鼓励了发挥：说“顺便看看”，等于打开膨胀阀门
- 缺少显式的目标寄存器：目标只活在对话散文里，没有被反复对准的数据结构
所以漂移不完全是“模型不听话”，也是交互方式与系统设计的结果。
我怎么尽早发现：过程检查点
不要等到最终交付。我会在多轮中安插检查点，问它（或问自己）：
- 当前目标一句话复述是什么？和最初是否同一句？
- 正在做的步骤如何服务该目标？
- 哪些事明确不在范围内？
- 若现在停止，已完成的验收是什么？
Agent 若复述漂移了，立刻纠正，比事后推翻更便宜。我甚至会要求每隔 N 步强制输出“目标对齐卡”，格式固定，减少散文发挥。
图：过程对齐卡：目标、范围外、本步如何服务、验收（原创示意图）
拉回漂移的几句人话
发现苗头时，我常用短指令，而不是长篇说教：
- 「停。复述最初目标，只复述，不继续干活。」
- 「范围锁定：只允许改文件 A/B；其他一切列成建议，不要实施。」
- 「成功标准只有：某某测试绿。干净与否不计入。」
- 「撤销上一轮超出范围的改动，回到对齐点。」
关键是先停再对齐。很多人继续在漂的轨道上“微调”，结果偏得更远。
设计侧：给目标一个不会被冲走的位置
若你在做 Agent 产品或自己的编排，我对防漂的工程偏好是：
1. 显式目标对象
把 goal、constraints、done_when、out_of_scope 做成结构化字段，每轮注入，不只依赖聊天历史里的某句人话。
2. 变更预算与范围闸
允许修改的路径、工具、环境分层；越权要额外确认。漂移常借“顺手”发生，闸门能挡住顺手。
3. 定期对齐，而不是只在结尾验收
步数或时间触发对齐卡；对齐失败则暂停。
4. 总结时对照原目标
最终报告强制包含“相对原目标的完成度与偏差说明”，让漂移至少可见。
这些不保证消灭漂移，但能把“安静偏航”变成“显式告警”。
用户侧也可以少制造漂移
不全是系统的锅。我自己会注意：
- 开口把目标写成可验收的一句话
- “顺便”单独开任务，不塞进当前 run
- 中途改需求时，明确说“目标更新为……，旧目标作废”
- 避免同时塞五个成功标准且互相打架
含糊是漂移的温床。Agent 越能干，含糊被执行的速度越快。
图：防漂三层：结构化目标、范围闸、过程对齐（原创示意图）
和“主动性和创造性”的张力
防漂抓太死，Agent 会变呆，只会逐步执行清单；放太松，又容易帮倒忙。我的折中是：
- 探索阶段允许宽，但只读，输出的是选项与建议
- 执行阶段收窄，写入受范围闸约束
- 从探索切到执行，必须有一次显式确认
这样创造性发生在安全区，执行发生在对齐区。很多漂移，其实是探索态和执行态没切干净。
一次我被漂走的复盘
我让 Agent “查清某接口偶发超时的原因，先不要改代码”。查着查着，它在日志里看到连接池配置“可以优化”，便直接提了 PR。局部看 PR 还不差，但违背“先不要改”。根因有三：我的“先不要”只出现在首轮；中间我夸了它“分析得细”，被当成继续发挥的许可；系统没有 out_of_scope 的硬闸。
复盘后我改了自己的口令：禁止项每次对齐卡都要回显。 夸归夸，范围归范围。
漂移和“任务分解过细”的关系
有时漂移不是模型野，而是分解把目标切丢了。你说“做完登录改造”，Agent 拆成十个小任务后，第 7 个小任务的局部最优开始主导全局，最初的验收标准不再被提起。
缓解办法是：分解树的根节点始终挂着原目标与 done_when；子任务完成时要回答“对根目标的贡献是什么”。若答不上来，这个子任务就该删或降级。我让 Agent 自己拆任务时，会要求输出里必须带回根目标的回声，否则不准开工。
多 Agent 时漂移会传染
主 Agent 漂了，子 Agent 会在错误目标上非常勤奋。隔离上下文能减少噪声，但也会减少“总目标”的可见性。我的偏好是：子 Agent 的 brief 必须包含浓缩的 goal/constraints/out_of_scope，而不是只给当前文件路径。收回来时先做目标符合性检查，再合并 diff。
曾经有一次，调研子 Agent 的 brief 写成“找一下优化点”，它很尽责地找了十几处，主 Agent 又很尽责地全改了——用户要的只是一份原因报告。传染链上每一环都“合理”，结果却离谱。从那以后，brief 里的动词我写得很死：调查、列出、禁止修改。
如何在回顾里度量漂移（很粗糙的个人法）
我不追求学术指标，只做很土的回顾：
- 原目标一句话
- 实际交付一句话
- 是否需要改名才能对齐
- 中途纠正次数
- 超出范围的文件数
若经常要改名，或超出范围文件数很多，说明对齐卡密度不够，或范围闸太松。这比只看“任务成功/失败”二元结果更能指导改系统。
收尾：忙不等于朝着目标
目标漂移最迷惑的地方，是每个人（包括你）都可能被“进展感”安抚。工具在响，文件在改，diff 在涨——可方向错了，进度只是偏航里程。
给自己的检查句：如果现在强制结束，交付物是否还叫最初那件事？ 若要改名才能交卷，多半已经漂了。早停、对齐、再走，比安静地到达错误终点便宜得多。
说到底，目标漂移提醒我们：Agent 的生产力放大器属性是中性的——对准时放大产出，偏航时放大浪费。多轮对话越长，越要假定漂移会发生，然后用结构化目标、范围闸和对齐卡去降低频率与伤害。我不再问“它会不会漂”，只问“漂了能不能很快被看见、被打断”。把这个问题当成默认设计约束，多轮 Agent 才会从“看起来很勤快”变成“真的在帮你到达原定终点”。
2026-10-14鱼鱼