什么叫做意图飘移

原生的ReAct循环：Though（思考）->Action（动作）->Observation（观察）

它没有全局导航锚点：模型永远在做「局部最优决策」，没有一份Plan/Todo清单约束主干路线。

飘移产生的四个核心原因：

1. 工具返回结果带出岔路信息：工具Observation里面附带额外信息，吸引模型注意力，开启一条支线任务，支线越走越深，主线被遗忘。
2. 原始用户目标被上下文稀释：多轮循环后，大量工具返回日志堆满上下文，最开头用户原始需求被淹没；
3. 会话压缩把早期目标信息删掉：长会话摘要压缩的时候，有损丢失原始意图细节，后续推理沿着被篡改后的摘要走。
4. 没有“进度核对”自检步骤：没有Plan/Todo-list，每一轮不会执行校验「我当前行动是否服务于最初目标」。

先规划再执行

总结：

OpenClaw的todo-list

整体流程

1. 收到用户请求，Agent生成一份todo列表；
2. 这份todo被存进外置的TaskState对象，框架永久持有；
3. 每一轮ReAct循环，框架把最新的todo列表注入上下文；
4. Agent挑选一条未完成的todo，执行工具；执行完框架把这条勾选【X】
5. 中途可以追加新todo，删除无效todo。

Todo-list本质：扁平化任务清单。原生todo列表本身不强表达依赖，并行关系。

todo列表勾选逻辑

• TaskState/todo-list：唯一真相源，保存在框架内存，LLM只读，不能直接修改。
• LLM想变更todo状态：就必须在Function Call的过程中，调用专门的工具函数（updateTodoList）。
• 工具收到请求：执行校验，然后修改外置的task_state状态，打上完成标记

模型强制生成todo列表

1. 【规划阶段强制调用工具】在面对多步骤复杂任务时，必须先调用todo_ensure_list，产生结构化任务清单，在Todo列表生成成功之前，禁止调用任何业务工具。

注意：不是仅写一段文字计划，而是强制发起一次todo-call来创建todo列表。框架网关可以拦截：如果首轮回复直接调用业务工具，框架直接拒绝执行，并且返回一条纠错反馈给到LLM。

2. 【系统提示词强制约束】系统提示词写入硬性工作流程顺序：

# 工作流程
1. 收到用户复杂任务，第一步动作：调用 todo_ensure_list() 拆解任务，生成结构化待办清单。
2. 框架返回生成好的todo列表。
3. 之后每一轮循环：读取当前Todo状态，挑选一条未完成任务执行。
4. 工具执行完毕 → 调用 todo_set_status 更新任务状态。
5. 如果任务发生变化：调用 todo_replace_plan() 修改、重生成清单。

提示词仅仅是软约束，需要依赖网关拦截。

3. 【每轮对话临时注入】不会因为上下文过长、上下文压缩忘记计划

框架每一轮请求都会把最新的Todo-list临时注入上下文副本。模型永远可以看到当前任务清单；不会因为上下文过长，压缩之后忘记计划。

4. 【失败兜底重试循环】模型不肯生成todo

网关拒绝之后，如果模型第二次、第三次还是绕过todo，框架开启重试闭环：

1. 拒绝工具执行；
2. 返回明确纠错文本；
3. 保留全部上下文不变，重新发起LLM请求，让模型做规划；
4. 设置重试上限（例如最多3次）；超过阈值判定规划失败，任务终止告警

Cluade Code的Plan

主要流程

1. 模型调用EnterPlanMode；框架切换全局permission_mode=plan；
2. 框架网关强制拦截所有副作用工具：禁止文件写入，bash执行（工程约束）
3. Agent在只读模式下探索，产出一份md计划，计划会写入磁盘，同时「对话文本」写入对话assistant消息。
4. 完成规划后调ExitPlanMode，提交计划，等待用户审批。

如何防控上下文压缩、上下文稀释

1. Plan写入磁盘进行持久化。
2. 提示词软约束：对抗上下文稀释，上下文压缩。
3. 提示词软约束：期望在压缩之后，重新读取plan。