很多 AI agent 系统在生成计划那一刻看起来都很聪明，真正的问题出在后面：任务还没执行完，世界已经变了。用户改目标、依赖返回空结果、证据过期、权限范围调整、人工审批意见改变，这些都会让原计划逐步失效。
如果系统没有 drift 检测和再规划触发，最常见的结果不是彻底失败，而是拿着一份已经不适用的旧计划继续往下做，最后把本来可以及时收口的问题变成更大返工。
建议先结合 AI Agent 状态机设计指南、AI agent Checkpoint 与断点恢复、AI agent Artifact 设计 和 AI agent 证据来源与可信度分层 一起看。
先给结论：发现 drift 后先分三类，不要一律重做计划
| 漂移类型 | 典型例子 | 推荐动作 |
|---|---|---|
| 轻微 drift | 某条 evidence 失效，但主目标不变 | 局部替换证据 |
| 结构 drift | 某个关键步骤不再可行 | 局部再规划 |
| 目标 drift | 用户目标或业务约束已变 | 整链重做计划 |
只要系统把所有 drift 都当成“重新规划一下”，计划成本会失控；反过来如果从不重规划，旧计划又会持续污染执行链。
一、先定义哪些信号属于 drift，而不是普通噪音
更有用的 drift signal 通常包括：
- 关键 evidence 过期或冲突
- 某一步工具结果和原计划前提不一致
- 用户明确修改目标或约束
- 权限、预算、deadline 明显变化
而不是所有小误差都算 drift。否则系统会频繁重规划，执行效率比人工还差。
二、再规划触发最好显式记录原因，不要只跳回 PLAN
更稳的做法，是把 replan request 写成结构化事件：
{
"runId": "run_123",
"currentPlanVersion": 3,
"trigger": "evidence_conflict",
"scope": "partial",
"affectedSteps": ["validate_vendor_policy"]
}
这样系统和人工都能知道：为什么重规划、重规划打算影响哪一段，而不是只看到状态突然回到 PLAN。
如果要让再规划可复盘，这份 request 最好还带信号强度和预期动作：
{
"signalStrength": "hard",
"continueAllowed": false,
"replanBudgetMs": 4000,
"requiredOutcome": "new_plan_version"
}
这样系统不是只会说“该 replan 了”，而是明确说明为什么当前链路不能继续，以及这次再规划允许消耗多少额外预算。
三、局部再规划比整链重算更常见，但必须先知道影响范围
一个简单但有效的判断法是：
| 问题 | 如果答案是“是” |
|---|---|
| 原目标变了吗 | 倾向整链重做 |
| 只是某个前提失效了吗 | 倾向局部再规划 |
| 已完成步骤还能复用吗 | 尽量保留已有 artifact |
| 副作用已经发生了吗 | 不能简单回滚重来 |
这也是为什么 drift 判断一定要和 artifact、ledger 一起看，而不是只靠当前 prompt 内容。
四、计划版本要显式化，否则再规划后很难复盘
如果系统会多次调整计划，就应该明确记录：
- plan version
- replan trigger
- replaced steps
- still valid artifacts
例如：
{
"planVersion": 4,
"supersedes": 3,
"reason": "deadline_budget_changed",
"retainedArtifacts": ["evidence_011", "draft_004"]
}
没有 plan version，团队后面只会知道“系统改过计划”，却不知道到底改了几次、每次为什么改。
在工程上，新的计划版本最好还带一份 plan diff，明确哪些东西保留、哪些东西被替换：
{
"planDiff": {
"replacedSteps": ["vendor_lookup"],
"retainedSteps": ["policy_validate"],
"retainedArtifacts": ["evidence_011"]
}
}
这会让 replan 之后的执行者不必重新猜“旧链路里还有哪些东西能继续用”。
五、drift 检测也要防止系统过度敏感
另一类常见问题是：系统太容易触发 replan，最后每走一步都在回到 PLAN。避免这一点的关键通常有两个：
- 先定义硬触发信号和软触发信号
- 对软触发信号设置阈值，例如连续两次证据不一致才重规划
系统不是越敏感越好，而是越能稳定判断“现在真的有必要改路”越好。
一个更实用的分层通常长这样：
| 触发级别 | 典型信号 | 推荐动作 |
|---|---|---|
| hard trigger | 目标改变、权限失效、副作用冲突 | 立即停止旧计划 |
| medium trigger | 关键证据冲突、关键步骤失败 | 局部再规划 |
| soft trigger | 非关键证据波动、轻微预算变化 | 继续观察或阈值累计 |
只有把这层写清楚，系统才不会因为一点小波动就进入 replan loop。
六、上线后要看 drift 对 accepted run 的真实影响
建议至少记录：
| 指标 | 用途 |
|---|---|
| replan trigger rate | 看系统是否经常遇到计划漂移 |
| partial vs full replan ratio | 看计划粒度是否合理 |
| accepted run after replan | 看重规划是否真的挽回结果 |
| artifact reuse after replan | 看再规划是否有效复用了已有产物 |
| replan loop count | 看系统是否在短时间内反复重规划 |
| false-positive drift rate | 看系统是否过度敏感 |
如果 replan rate 很高，但 accepted run 没提高，说明 drift 检测可能只是引入了额外复杂度。
七、失败案例：用户目标已经改了，Agent 还在执行旧计划
某个内容 agent 先生成“官网首页方案”，用户随后补充要求改成“招聘页 + 表单收集”。系统虽然记录了新消息，但原计划没有被判为目标 drift，后续继续基于旧计划生成首页模块，最后整条链都要返工。
修复后，团队把“目标字段改变”和“输出类型改变”列为硬触发信号，只要命中就停止旧计划并重建 plan version，返工量明显下降。
八、Plan Drift 与再规划 Checklist
- 是否定义了明确的 drift signal，而不是所有误差都算漂移
- 再规划触发是否被结构化记录，而不是简单回到 PLAN
- 是否区分 hard / medium / soft trigger 级别
- 是否区分局部再规划和整链重做
- 计划版本是否显式可追溯
- 新计划是否带 supersedes、planDiff 和 retainedArtifacts
- 是否保留可复用 artifact，而不是每次都从零开始
- replan 是否有独立预算，避免无限重算
- 是否为软触发信号设置阈值，避免过度敏感
- 是否监控 replan 后 accepted run 的真实改善
结语
AI agent 的计划不是一份生成后永远有效的文档，而是一条会随着证据、约束和外部状态持续漂移的执行协议。真正成熟的系统，不是从不重规划，而是知道什么时候该继续、什么时候该局部修补、什么时候必须果断停下重来。
延伸阅读：
