智能体执行长任务时常见一种故障：开头几步都对，越往后越偏离原始目标，最后交出一份看起来完整、实则答非所问的结果。这种现象叫状态漂移，根源不在单步能力，而在状态的累积误差。

漂移有三个主要来源。第一是目标稀释：多轮工具结果把原始指令越推越远，智能体开始为中间结果服务，忘了最终交付标准。第二是假设固化：某一步对不确定信息做了猜测，后续步骤把猜测当事实继续推导，错误被层层放大。第三是上下文污染：失败尝试、过时中间态、无关工具输出混在历史里，干扰后续判断。

对付漂移，靠事后通读全文是不够的，需要在执行中设置检查点。做法是把长任务拆成若干阶段，每个阶段结束时强制做三件事：对照原始目标复述本阶段产出，列出本阶段依赖的关键假设，标出尚未验证的信息。任何一项对不上，就地修正，不把问题带到下一阶段。

检查点的密度要和任务风险匹配。只读查询类任务可以阶段少一些；涉及写库、发消息、改配置等不可逆操作的任务，检查点必须设在动作之前，而不是之后。不可逆动作执行前，校验的应该是动作参数本身，而非执行意图。

还有一个容易被忽视的点：检查点本身也会漂移。如果校验标准写得含糊，智能体会在校验时自我说服。解决办法是把校验写成可判定项，例如交付物是否包含指定字段、数值是否来自指定来源、关键结论是否有对应证据，而不是笼统地问做得对不对。

落地时建议先做两件事：一是给长任务模板预置阶段划分与检查点清单，而不是每次临时发挥；二是把漂移案例记下来，复盘时只看一个问题，即哪一步第一次偏离了原始目标。多数情况下，修好那一步的校验，就能挡住整类漂移。

检查点还要配套回滚能力。发现漂移时，系统应当能回到上一个通过校验的状态重新出发，而不是在错误状态上继续打补丁。回滚粒度与检查点粒度应当一致，粒度太粗会丢掉大量有效工作，粒度太细则管理成本过高。实践中可以按不可逆动作划分回滚段，段内可重做，段间需确认。