记录我重写了 Agent 的 Plan 系统：为什么 Replan 是可进化 Agent 的关键

摘要Agent 项目都在讲自主规划但落到工程上往往是开场列一份 Todo或者让模型临场改主意。我最近在维护SkillLite的时候遇到一个在更底层的事把重新规划做成一个可观测、可度量、可沉淀为进化信号的系统事件。本文结合真实的 Rust 代码聊聊为什么我最终选择了显式 replan而不是更自然但难以计量的隐式再决策。先说选型各家 Agent 的 Replan 到底长什么样在展开实现之前我觉得更重要的是先把几条路线摆出来比较否则很容易读了半天代码却不知道这些取舍是在对抗什么。如果只聚焦在replan 机制本身我会把主流方案分成这五类系统Replan 的典型形态一句话理解最适合的场景CursorPlan Mode执行前生成可编辑 Markdown 计划用户确认后执行执行中无自动 replan先规划再执行replan 靠用户发起IDE 内编码任务、人工审核计划、改动有限的单次任务Claude Code模型调用TodoWrite持续更新 todo 列表更新任务板长任务推进、人机共视、状态可见OpenClaw观察结果后自然再决策必要时借助 Plan Skill 重新分解下一轮重新判断怎么做灵活协同、复杂任务、可变规划深度Manusplanner 在外部工作区如task_plan.md持续修订路线图持续改写任务路线图多 agent 编排、长上下文任务、强 context engineeringSkillLite模型显式调用update_task_plan替换待执行计划一次正式的计划替换事件单 Agent、自进化、可度量、可复盘结论重视人工审核计划、确保每步可控→CursorPlan Mode 路线很强重视任务可见性和进度维护→Claude Code那类 Todo 路线很强重视灵活推理和自然再决策→OpenClaw这种路线很强重视多 agent 编排、大任务上下文管理→Manus这类路线很强重视 replan 可计数、可统计、可沉淀为 evolution 信号→SkillLite当前这套更合适SkillLite选择的不是最智能的方案而是当前目标下追求可衡量的工程化的方案。一、问题从哪里来隐式 Replan 的三个死角Agent 的replan 是一个比较常见的模块但很多系统里的 replan 本质上是隐式发生的这轮执行失败了模型下一轮换了个思路你感觉它好像重新规划了一下但系统里没有任何正式的 replan 记录这种方式做 demo 够用但真正想做自进化系统三个缺点会很快暴露出来。一没法定义到底有没有 replan失败后重试一次算不算 replan整套计划重写算不算系统里没有明确事件这些边界都是模糊的。二没法统计失败原因是任务拆错了工具选错了还是最初规划就偏了如果 replan 只是模型临场换了个说法你之后分析不出任何稳定规律。三没法复现今天第 5 轮改主意明天第 3 轮就换了。对 demo 来说无所谓对工程系统来说这种行为根本没法复盘也不可能进化。所以SkillLite从一开始就定下一条设计原则replan 不能只是模型脑子里的临时改主意必须是系统中的正式且可记录事件。二、SkillLite 的做法让 Replan 变成工具调用SkillLite的 planning 结构比较直接对话开始前Agent 先生成一份任务列表每个任务包含四个字段{ id: u32, description: String, tool_hint: OptionString, // 建议用哪个工具/skill 执行 completed: bool, }tool_hint是和 Claude Code Todo 最大的区别。普通 Todo 只知道要做什么而tool_hint额外带了原本打算怎么做。这一点对 evolution 信号很关键后面会展开。执行过程中如果发现当前计划不适用模型不是换个说法继续答而是显式调用一个工具update_task_plan调用之后系统会把这次 replan 记录为一个离散事件replan_count加一新计划替换待执行部分。从这一刻起replan 就是一个可计数、可追踪、可回放的事件不再是模糊的它好像改过主意。三、核心代码解读3.1handle_update_task_planreplan 不是口头建议而是状态修改代码位于crates/skilllite-agent/src/agent_loop/helpers.rspub(super) fn handle_update_task_plan( arguments: str, planner: mut TaskPlanner, skills: [LoadedSkill], event_sink: mut dyn EventSink, ) - ToolResult { // 1. 解析 LLM 提交的新任务列表 // 2. 校验tasks 不能为空 // 关键新计划要先过和初始 planning 一样的清洗 增强 planner.sanitize_and_enhance_tasks(mut new_tasks, skills); // 保留已完成任务只替换待执行部分 let completed_tasks: VecTask planner .task_list .iter() .filter(|t| t.completed) .cloned() .collect(); let next_id completed_tasks.iter().map(|t| t.id).max().unwrap_or(0) 1; for (i, t) in new_tasks.iter_mut().enumerate() { t.id next_id i as u32; t.completed false; // 新计划里的 completed 一律重置 } let mut merged completed_tasks; merged.extend(new_tasks.clone()); planner.task_list merged; // 通知事件系统replan 成为可记录的离散事件 event_sink.on_task_plan(planner.task_list); ToolResult { content: format!(Task plan updated ({} tasks). Continue with the new plan., new_tasks.len()), is_error: false, ..Default::default() } }这段代码背后有三个设计决策值得注意第一replan 是状态修改不是文字风格变化。系统里planner.task_list真实改变了不是模型只是说了一段不一样的话。第二已完成任务被保留。新计划不会覆盖历史只替换还没做的部分避免replan 一次之前努力清零。第三新计划不是直接执行的要先被系统接住。sanitize_and_enhance_tasks这层防御非常关键。3.2sanitize_and_enhance_tasks模型可以提建议系统负责接住这是一个很容易被忽视但非常关键的实现在crates/skilllite-agent/src/task_planner.rsfn sanitize_task_hints(tasks: mut [Task], skills: [LoadedSkill]) { for task in tasks.iter_mut() { if let Some(ref hint) task.tool_hint { if !Self::is_hint_available(hint, skills) { tracing::info!( Stripped unavailable tool_hint {} from task {}: {}, hint, task.id, task.description ); // 把幻觉出来的 hint 直接清掉不让它进执行链路 task.tool_hint None; } } } } pub fn sanitize_and_enhance_tasks(self, tasks: mut VecTask, skills: [LoadedSkill]) { Self::sanitize_task_hints(tasks, skills); self.auto_enhance_tasks(tasks); // 检测缺失步骤并自动补齐 }做这层的原因模型在 replan 时同样会幻觉。常见的问题有写出根本不存在的tool_hint、漏掉关键步骤、把没完成的任务标成completed。如果不做清洗replan 看起来像纠错实际上只是重新生成了一份新的错误计划。最终原则只有一句话replan 和初始 planning必须走同一套清洗和增强逻辑。3.3 软上限允许反思但不允许无限犹豫把 replan 做成显式事件之后很快会遇到一个新问题模型有时候会陷入不停改计划但不执行的循环。SkillLite在crates/skilllite-agent/src/agent_loop/execution.rs里做了软上限const MAX_REPLANS_PER_SESSION: usize 3; if is_replan { state.replan_count 1; let mut r handle_update_task_plan(arguments, planner, skills, event_sink); if !r.is_error state.replan_count MAX_REPLANS_PER_SESSION { r.content.push_str( \n\n⚠️ You have now replanned 3 time(s). \ Please STOP replanning and EXECUTE the current plan step by step. ); } r }同时在单任务工具调用过深时系统也会明确给出两个出口而不是只鼓励硬试pub fn build_depth_limit_message(self, max_calls: usize) - String { let current_id self.current_task().map(|t| t.id).unwrap_or(0); format!( You have used {} tool calls for the current task. \ Call complete_task(task_id{}) to record completion. \ If the current approach is clearly wrong, \ you may call update_task_plan with a revised task list instead., max_calls, current_id ) }这两段代码体现同一个工程判断不硬拦保留模型自救空间但也不放任防止系统陷入假忙状态。四、为什么没有选其他方案为什么不像 Cursor 那样做 Plan ModeCursor 的 Plan Mode 是目前编辑器 Agent 里做得比较有特色的一套用户按 ShiftTab 进入规划模式Cursor 先研究代码库、提问、生成一份带文件路径和代码引用的可编辑 Markdown 计划用户确认后再正式执行。这个设计有它的优势人机协作感很强用户能在执行前看到完整的执行路线可以直接改掉不对的步骤适合编码改动场景计划里直接标注要改哪些文件执行后有 diff 视图可回滚降低大改动的风险高风险任务先规划、人确认再执行但这套方案有一个局限replan 是人发起的不是 Agent 自主触发的。一旦进入执行阶段Cursor 的 Agent 模式就是纯 ReAct 循环每轮最多 25 次工具调用没有任何任务结构也没有 mid-execution 的自动 replan 机制。如果执行中发现计划不对只能用户重新输入重走一遍。这对提升编码体验来说已经够了。但对SkillLite想做的事完全不够用系统没法自主识别当前路径不对并触发 replanreplan 不计入任何指标没有replan_count没有 per-task 工具绑定没有tool_hint不产生 evolution 所需的工具模式信号无人值守跑批时一旦卡住就只能超时没有自救路径Cursor Plan Mode 的核心价值是人类把关编码计划而不是让 Agent 在执行中自主纠偏。两者要解决的问题根本不在同一个层面。4.1 为什么不直接照搬 Claude Code 的 TodoClaude Code的 Todo 路线有很明显的优点显式、可见、用户和模型都能实时感知任务进度。但它的核心强项是进度维护不是执行策略学习。Claude Code的 todo 项只有content、status、activeForm没有 per-task 的工具绑定。这意味着你知道哪些任务做完了但你不知道这类任务原本打算用什么工具做。而SkillLite的 evolution 引擎需要这一层信息哪类任务经常和哪个工具绑定哪些tool_hint频繁导致失败或 replan任务类型和工具模式之间有没有可学习的稳定映射所以SkillLite不能丢掉tool_hint。没有这个字段evolution 信号就弱了一层。如果说 Claude Code 的 Todo 更像执行进度结构那SkillLite的 plan/replan 更像可进化的执行信号载体。4.2 为什么不选 OpenClaw 的隐式再决策OpenClaw的规划体系我很欣赏按任务复杂度动态决定规划深度L0 到 L4执行中根据观察结果自然再决策Task Router 还支持并行波次和依赖图。但灵活恰恰是它对我的最大障碍。如果 replan 是模型下一轮自然改主意那你很难定义这次是否发生了 replan。一旦这个定义不清晰后面这些事都做不了统计首次成功率计算平均 replan 次数比较无 replan 成功和多次 replan 成功案例的差异从失败轨迹里提炼可复用规则SkillLite的 evolution 引擎强依赖这些可计数的信号。如果 replan 不是离散事件整条进化链路的数据基础就不稳了。4.3 为什么 Manus 的路线也不是当前的参考系从公开资料来看Manus是一个强 planner 强 context engineering 多 agent 协作的体系任务路线写进task_plan.md结合notes.md、context.md等外部工作区持续推进。这套方案对复杂开放任务非常适合planner 可以随时改写路线上下文外化也解决了长任务的信息压缩问题。但SkillLite当前的目标不是做一个超级总控 agent而是做一个可复制、可进化、可度量的单 Agent 最小闭环。Manus的启发对SkillLite更多是间接的外部工作区有价值、planner 和 executor 分层有价值、context 工程化很关键。但在replan 的离散可计数性这件事上它没有提供直接参考。五、为什么 Replan 是进化系统的入口不只是执行辅助做完这轮分析我越来越确信一件事SkillLite里的 planning/replanning已经不是执行层的小功能而是进化系统的入口。Agent 想真正变好靠的不是抽象意义上的更聪明而是这些更具体的能力把任务拆对给当前任务配上合适的执行策略在失败时及时换路不死磕把这些经验沉淀成下一次更好的决策这些能力必须依赖结构化信号才能沉淀下来。而结构化信号的前提就是 replan 要是一个明确发生过的事件可以被记录、被统计、被分析、被学习。从这个角度看planning 不再只是让对话更有条理而是让系统知道它到底是怎么变好的。六、后续还想继续打磨的几个点这轮把 replan 做成离散事件的设计完成后我觉得还有几个地方值得继续优化空计划时更早退出。如果 planning 结果是[]说明任务可能根本不需要工具这时继续给满额迭代预算会浪费轮数。规划解析失败要更可观测。当前 fallback 到单任务是合理的但系统最好明确打日志便于后续分析 prompt 质量。在更多卡住场景提示 replan。连续失败、无工具调用、深度用尽这些情况应该更一致地引导模型考虑改计划而不只是反复重试。七、总结系统里的 replan到底是模型偷偷改主意还是一个能被记录、度量、复用的正式事件这两者的差别比模型用哪个版本或者prompt 怎么写都要更根本。因为 replan 不只是让 Agent 能纠错它是系统能不能从每一次执行里学习的前提。SkillLite当前的选择是显式 planning 显式 replan tool_hint 绑定 软限制约束。它可能不够像人但在单细胞、可复制、可进化这个目标下应该是目前探索下来比较稳的工程解法。