AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载计划模式Plan Mode是 Kimi Code 这类 Agent 系统中最关键的“先规划、后执行”约束机制Agent 在进入该模式后只能读取代码、撰写计划禁止修改系统直到用户批准计划后才恢复全部能力。本文以 agent-core-v2 中plan-mode-full-reminder.md这一提示词文档为切入点剖析它在 Kimi Code 中如何被注入到对话上下文、何时被选择为全量full而非稀疏sparse版本以及它背后的计划文件、工具守卫与批准流程。读完本文你将掌握计划模式提示词的完整链路从文档内容 → 源码注入 → 上下文拼接 → 工具拦截并理解其 dedup 与刷新策略的工程考量。一、Full Reminder 文档计划模式的核心行为契约plan-mode-full-reminder.md是一份以“助手指令”形式书写的 Markdown 提示词文档全文共 19 行其作用是当 Agent 刚进入计划模式或长时间未收到提醒时把完整的模式约束与工作流重新注入到对话上下文中。它包含两个层面的内容1.1 模式禁令最高优先级约束文档开篇即声明计划模式下的“不可为”清单并以“This supersedes any other instructions you have received”强调其优先级高于任何其他指令禁止任何编辑除非工具请求被明确批准exception: the current plan file否则不得对系统做任何修改优先使用只读工具Read、Grep、Glob 等Bash 仅在必要时使用且遵循正常权限模式与规则TaskStop、CronCreate、CronDelete 在计划模式下被屏蔽需要先调用ExitPlanMode才能使用。值得注意的是禁令的工程实现在planService.ts的guardToolExecution中得到了硬性落实当plan状态非空即计划模式激活时Write/Edit只有在对当前计划文件本身的写入时才会被event.allow()放行其余一律event.veto()拒绝并返回“Plan mode is active. You may only write to the current plan file… Call ExitPlanMode to exit plan mode before editing other files.”的拒绝消息TaskStop、CronCreate、CronDelete同样被 veto这正是文档中禁令的代码级落地。1.2 五步工作流WorkflowFull Reminder 为 Agent 明确了进入计划模式后的操作次序Understand—— 用 Glob、Grep、Read 探索代码库Design—— 收敛出最佳方案权衡取舍但目标是给出单一推荐Review—— 重读关键文件以验证理解Write Plan—— 用 Write 或 Edit 修改计划文件文件不存在时先用 Write 创建Exit—— 调用ExitPlanMode请求用户批准。其中第 4 步“写计划文件”是计划模式的核心产物第 5 步是唯一合法的“退出通道”。1.3 多方案处理规则Handling multiple approaches文档同时约束了“计划里出现多个方案”时的行为规范最多保留23 个有实质差异的方案不要用微小变体凑数如果某个方案明显更优只提出那一个当最佳方案依赖用户偏好或未知约束时先用AskUserQuestion澄清而不是把所有选项丢给用户把多方案通过options参数传给ExitPlanMode让用户在批准时直接选择要执行哪个方案严禁在计划里罗列多个方案却不传options—— 否则用户只能看到默认批准控件而无法选择具体方案。这条规则的底层约束同样写死在exit-plan-mode.tsoptions数组限制为 13 项label 必须唯一、且不得使用保留的批准标签Approve、Reject、Reject and Exit、Revise。1.4 回合收尾约束文档还规定每一回合必须以AskUserQuestion澄清需求或ExitPlanMode请求批准结束不得以其他方式结束回合且不得用文本或AskUserQuestion询问“计划是否批准”——那是ExitPlanMode的职责。二、提醒家族的完整谱系Full 与 Sparse、Reentry、Exit 的定位Full Reminder 并非孤立存在它与同目录下的其他提醒文档共同构成了一套分级注入体系见injection/目录提醒文档触发场景内容定位plan-mode-full-reminder.md首次进入 / 长时间未提醒 / 用户有新输入完整禁令 五步工作流 多方案规则全文注入plan-mode-sparse-reminder.md已注入过 full、间隔较短精简版只提醒“模式仍激活、优先只读工具、只可写计划文件、用 AskUserQuestion / ExitPlanMode 结束回合”plan-mode-reentry-reminder.md会话恢复时已有旧计划文件强调“先读旧计划文件 → 评估当前请求 → 同任务则更新、不同任务则重写”plan-mode-inline-*-reminder.md三个变体宿主未提供计划文件路径时与上述三种场景一一对应的“无计划文件路径”版本plan-mode-exit-reminder.md计划模式刚结束提示“只读与仅计划文件的限制已解除按已批准计划继续执行”这些变体全部通过planModeInjection.ts以?raw方式作为原始文本导入第 915 行再由PlanModeInjection服务按场景动态挑选。三、注入决策引擎planModeInjection.ts 如何挑选提醒3.1 三种提醒 一个退出提醒的切换逻辑PlanModeInjection以PLAN_MODE_INJECTION_VARIANT plan_mode注册进IAgentReminderService每个回合开始时都会执行注入回调其核心状态机如下计划模式未激活plan.status()返回 null若planWasActive状态为 false从未激活过返回undefined不注入若此前激活过则把状态置回 false 并注入EXIT_REMINDER计划模式已结束恢复常规工具权限。计划模式激活但planWasActive仍为 false首次进入置状态为 true若计划文件已有非空内容返回reentryReminder有旧计划的重新进入场景否则返回fullReminder全新计划场景。计划模式已激活且此前已注入过调用planModeReminderVariant(injectedAt, history)决定本轮注入 full、sparse 还是不注入。3.2 频率控制dedup 与刷新阈值planModeReminderVariant是提醒频率的核心算法其中定义了三个关键常量PLAN_MODE_DEDUP_MIN_TURNS 2距上次注入至少经过2 个助手回合后才允许注入稀疏提醒sparse避免同一上下文里刷屏PLAN_MODE_FULL_REFRESH_TURNS 5距上次注入经过5 个及以上助手回合时重新注入全量提醒full防止长会话中模型遗忘计划模式约束用户新输入user 消息会直接触发 full算法从injectedAt 1开始扫描历史一旦遇到 user 角色消息即返回full。判定逻辑可用伪代码概括injectedAt null → full 本回合首次注入 自 injectedAt 之后 遇到 user 消息 → full 用户发起新请求 assistant 回合数 ≥ 5 → full 长时间未刷新重新注入完整版 assistant 回合数 ≥ 2 → sparse 短间隔只注入精简版 否则 → null 太频繁本轮不注入这一设计体现了典型的“记忆衰减”思想刚注入时约束最新鲜不重复注入随回合推移约束逐渐“褪色”先 sparse 维持存在感达到阈值后再用 full 完整刷新。测试用例plan.test.ts的plan mode injection cadence描述块恰好验证了这套节奏首次注入含Plan mode is active与Plan file:的 full 提醒 → 立即再次注入不重复上下文长度不变→ 追加 2 个助手回合后注入含Plan mode still active的 sparse 提醒 → 退出后只注入一次 exit 提醒。3.3 计划文件路径页脚fullReminder/sparseReminder/reentryReminder三个函数都会调用withPlanFileFooter当存在计划文件路径时在提醒正文后追加一行Plan file: path当计划文件路径为空宿主未提供时则改用对应的PLAN_MODE_INLINE_*_REMINDER内联版本——这也解释了为什么目录里同时存在“带路径”与“inline”两套文档。四、计划文件生命周期从创建、写入到版本快照4.1 计划文件路径约定根据planService.ts的planFilePathFor计划文件固定存放在会话目录下sessionDir/agents/agentId/plans/planId.mdplanId由generateHeroSlug(randomUUID(), new Set())生成见createPlanIdenter()时会先ensurePlanDirectory递归创建目录createFile为 true 时还会用writeEmptyPlanFile预创建一个空文件。4.2 EnterPlanMode / ExitPlanMode 工具PlanFeature注册了两个工具domain 均为planEnterPlanMode参数为空对象z.object({}).strict()见enter-plan-mode.ts执行时若计划模式已激活则报错否则调用planMode.enter()并返回包含工作流指引的结果消息含计划文件路径版本与无路径版本见enterPlanModeTool.ts。ExitPlanMode可选参数options13 个方案label 唯一且禁用保留词执行时从计划文件读取计划内容而非接收参数ExitPlanModeReview在非 auto 权限模式下把计划以plan_review展示交给用户批准批准后输出Plan mode deactivated. All tools are now available.并附上已批准计划与“Selected approach”提示当用户选择了某个 options 方案时。4.3 版本快照 recordRevision每次调用ExitPlanMode前见exitPlanModeTool.tsAgentPlanService.recordRevision()会把当前计划文件内容以plan/id/vversion.md的 key 存入 BlobStore并派发PlanRevision事件记录版本号、sha256 与字节数见planService.ts。这意味着每次提交审批的计划都留有可追溯的不可变快照。4.4 权限模式对流程的影响全链路中权限模式permission mode是关键变量EnterPlanMode在所有权限模式下都是自动进入无需批准提示ExitPlanMode在yolo 与 manual 模式仍会向用户呈现计划等待批准在auto 模式下则直接读取计划文件、退出计划模式而不询问用户见exit-plan-mode.md与exitPlanModeTool.ts的 auto 分支输出中明确标注“auto-approved without user review”。五、审批结果处理ExitPlanModeReview 的分支语义ExitPlanModeReview.approvalResult对用户的审批响应做了精细分流用户操作结果语义approved批准plan.exit()退出计划模式若选了 options 中的方案输出Selected approach: label\nExecute ONLY the selected approach...明确禁止执行未被选中的备选方案cancelled取消/关闭弹窗不退出输出 “Plan approval dismissed. Plan mode remains active.”Reject and Exit退出计划模式并 stopTurn输出 “Plan rejected by user. Plan mode deactivated.”Revise / 附带反馈不退出把用户反馈原样返回给模型“User rejected the plan. Feedback: ...”或提示 “User requested revisions. Plan mode remains active.”Rejected普通拒绝不退出、stopTurn输出 “Plan rejected by user. Plan mode remains active.”所有分支都会记录plan_resolved遥测事件outcome 分别为approved、dismissed、rejected_and_exited、revise、rejected为后续的流程分析提供数据基础。六、从文档到上下文的完整注入链路把全链路串联起来一次完整的“计划模式体验”可以描述为用户在非平凡任务新功能、多方案、架构决策、多文件改动等判定标准见enter-plan-mode.md中让 Agent 调用EnterPlanModeAgentPlanService.enter()创建计划文件目录并派发plan_mode.enter事件下一回合开始时PlanModeInjection回调被触发plan.status()返回激活状态、planWasActive为 false于是把full reminder附Plan file: ...页脚以origin: { kind: injection, variant: plan_mode }的 user 消息形式拼接到上下文测试快照中的plan-mode-reminder即此消息的占位见plan.test.tsAgent 按五步工作流操作只读探索 → 设计 → 写计划文件期间guardToolExecution持续拦截 Write/Edit/TaskStop/Cron* 等违规调用计划就绪后调用ExitPlanMode记录计划版本快照 → 生成plan_review展示options 可选→ 用户批准/拒绝/修订批准后plan_mode.exit事件派发、遥测模式从plan切回agent下一回合planWasActive为 true 且plan.status()为 null注入exit reminder告知 Agent 恢复全部工具权限随后继续执行已批准的计划。七、工程启示提示词注入设计要点从plan-mode-full-reminder.md及其配套实现中可以提炼出几条可复用的工程经验提示词即契约代码即执行文档中的禁令只读、只写计划文件、屏蔽定时任务工具与planService.ts的工具守卫一一对应模型提示与硬性拦截双保险避免模型“忘记规则”分级提醒对抗上下文衰减full / sparse / reentry / exit 四档提醒 2/5 回合阈值兼顾约束可见性与 token 成本避免每回合重复注入完整长文内联变体兜底无路径场景宿主未提供计划文件路径时自动降级为 inline 版本保证不同宿主环境下的行为一致性所有状态变更可追溯plan_mode.enter/exit/cancel、plan.revision均为 durable 事件配合 BlobStore 版本快照让计划流程可回放、可审计。如需深入阅读源码可重点关注以下文件提醒文档全集packages/agent-core-v2/src/features/plan/injection/注入决策引擎planModeInjection.ts计划服务与守卫planService.ts工具定义与批准流exitPlanModeTool.ts、exitPlanModeReview.ts频率与场景测试test/features/plan/plan.test.ts赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐Kimi Code 计划模式Plan Mode重新进入提醒注入机制从 reentry-reminder 到 PlanModeInjection 的完整解析Kimi Code 计划模式Plan Mode重新进入提醒注入机制从 reentry reminder 到 PlanModeInjection 的完整解析AI Agent代码智能体人工智能大模型CLIKimi Code Plan Mode 重新进入提醒Re-entry Reminder机制全解析无计划文件宿主下的上下文恢复与提示词注入原理Kimi Code Plan Mode 重新进入提醒Re entry Reminder机制全解析无计划文件宿主下的上下文恢复与提示词注入原理 Plan MAI Agent代码智能体人工智能大模型CLIKimi Code agent-core-v2 Swarm 模式退出机制exit-reminder 提醒注入原理与 Agent 行为指导Kimi Code agent core v2 Swarm 模式退出机制exit reminder 提醒注入原理与 Agent 行为指导 SwarmAgenAI Agent代码智能体人工智能大模型CLI上一篇vue-vben-admin 组件设计指南5 步用原子组件 组合式 API 搭出业务页面下一篇掌握HTMX hx-valsPOST请求数据处理的终极指南 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kimi Code 计划模式全量提醒机制解析：Plan Mode Full Reminder 注入原理与工程实现
AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载计划模式Plan Mode是 Kimi Code 这类 Agent 系统中最关键的“先规划、后执行”约束机制Agent 在进入该模式后只能读取代码、撰写计划禁止修改系统直到用户批准计划后才恢复全部能力。本文以 agent-core-v2 中plan-mode-full-reminder.md这一提示词文档为切入点剖析它在 Kimi Code 中如何被注入到对话上下文、何时被选择为全量full而非稀疏sparse版本以及它背后的计划文件、工具守卫与批准流程。读完本文你将掌握计划模式提示词的完整链路从文档内容 → 源码注入 → 上下文拼接 → 工具拦截并理解其 dedup 与刷新策略的工程考量。一、Full Reminder 文档计划模式的核心行为契约plan-mode-full-reminder.md是一份以“助手指令”形式书写的 Markdown 提示词文档全文共 19 行其作用是当 Agent 刚进入计划模式或长时间未收到提醒时把完整的模式约束与工作流重新注入到对话上下文中。它包含两个层面的内容1.1 模式禁令最高优先级约束文档开篇即声明计划模式下的“不可为”清单并以“This supersedes any other instructions you have received”强调其优先级高于任何其他指令禁止任何编辑除非工具请求被明确批准exception: the current plan file否则不得对系统做任何修改优先使用只读工具Read、Grep、Glob 等Bash 仅在必要时使用且遵循正常权限模式与规则TaskStop、CronCreate、CronDelete 在计划模式下被屏蔽需要先调用ExitPlanMode才能使用。值得注意的是禁令的工程实现在planService.ts的guardToolExecution中得到了硬性落实当plan状态非空即计划模式激活时Write/Edit只有在对当前计划文件本身的写入时才会被event.allow()放行其余一律event.veto()拒绝并返回“Plan mode is active. You may only write to the current plan file… Call ExitPlanMode to exit plan mode before editing other files.”的拒绝消息TaskStop、CronCreate、CronDelete同样被 veto这正是文档中禁令的代码级落地。1.2 五步工作流WorkflowFull Reminder 为 Agent 明确了进入计划模式后的操作次序Understand—— 用 Glob、Grep、Read 探索代码库Design—— 收敛出最佳方案权衡取舍但目标是给出单一推荐Review—— 重读关键文件以验证理解Write Plan—— 用 Write 或 Edit 修改计划文件文件不存在时先用 Write 创建Exit—— 调用ExitPlanMode请求用户批准。其中第 4 步“写计划文件”是计划模式的核心产物第 5 步是唯一合法的“退出通道”。1.3 多方案处理规则Handling multiple approaches文档同时约束了“计划里出现多个方案”时的行为规范最多保留23 个有实质差异的方案不要用微小变体凑数如果某个方案明显更优只提出那一个当最佳方案依赖用户偏好或未知约束时先用AskUserQuestion澄清而不是把所有选项丢给用户把多方案通过options参数传给ExitPlanMode让用户在批准时直接选择要执行哪个方案严禁在计划里罗列多个方案却不传options—— 否则用户只能看到默认批准控件而无法选择具体方案。这条规则的底层约束同样写死在exit-plan-mode.tsoptions数组限制为 13 项label 必须唯一、且不得使用保留的批准标签Approve、Reject、Reject and Exit、Revise。1.4 回合收尾约束文档还规定每一回合必须以AskUserQuestion澄清需求或ExitPlanMode请求批准结束不得以其他方式结束回合且不得用文本或AskUserQuestion询问“计划是否批准”——那是ExitPlanMode的职责。二、提醒家族的完整谱系Full 与 Sparse、Reentry、Exit 的定位Full Reminder 并非孤立存在它与同目录下的其他提醒文档共同构成了一套分级注入体系见injection/目录提醒文档触发场景内容定位plan-mode-full-reminder.md首次进入 / 长时间未提醒 / 用户有新输入完整禁令 五步工作流 多方案规则全文注入plan-mode-sparse-reminder.md已注入过 full、间隔较短精简版只提醒“模式仍激活、优先只读工具、只可写计划文件、用 AskUserQuestion / ExitPlanMode 结束回合”plan-mode-reentry-reminder.md会话恢复时已有旧计划文件强调“先读旧计划文件 → 评估当前请求 → 同任务则更新、不同任务则重写”plan-mode-inline-*-reminder.md三个变体宿主未提供计划文件路径时与上述三种场景一一对应的“无计划文件路径”版本plan-mode-exit-reminder.md计划模式刚结束提示“只读与仅计划文件的限制已解除按已批准计划继续执行”这些变体全部通过planModeInjection.ts以?raw方式作为原始文本导入第 915 行再由PlanModeInjection服务按场景动态挑选。三、注入决策引擎planModeInjection.ts 如何挑选提醒3.1 三种提醒 一个退出提醒的切换逻辑PlanModeInjection以PLAN_MODE_INJECTION_VARIANT plan_mode注册进IAgentReminderService每个回合开始时都会执行注入回调其核心状态机如下计划模式未激活plan.status()返回 null若planWasActive状态为 false从未激活过返回undefined不注入若此前激活过则把状态置回 false 并注入EXIT_REMINDER计划模式已结束恢复常规工具权限。计划模式激活但planWasActive仍为 false首次进入置状态为 true若计划文件已有非空内容返回reentryReminder有旧计划的重新进入场景否则返回fullReminder全新计划场景。计划模式已激活且此前已注入过调用planModeReminderVariant(injectedAt, history)决定本轮注入 full、sparse 还是不注入。3.2 频率控制dedup 与刷新阈值planModeReminderVariant是提醒频率的核心算法其中定义了三个关键常量PLAN_MODE_DEDUP_MIN_TURNS 2距上次注入至少经过2 个助手回合后才允许注入稀疏提醒sparse避免同一上下文里刷屏PLAN_MODE_FULL_REFRESH_TURNS 5距上次注入经过5 个及以上助手回合时重新注入全量提醒full防止长会话中模型遗忘计划模式约束用户新输入user 消息会直接触发 full算法从injectedAt 1开始扫描历史一旦遇到 user 角色消息即返回full。判定逻辑可用伪代码概括injectedAt null → full 本回合首次注入 自 injectedAt 之后 遇到 user 消息 → full 用户发起新请求 assistant 回合数 ≥ 5 → full 长时间未刷新重新注入完整版 assistant 回合数 ≥ 2 → sparse 短间隔只注入精简版 否则 → null 太频繁本轮不注入这一设计体现了典型的“记忆衰减”思想刚注入时约束最新鲜不重复注入随回合推移约束逐渐“褪色”先 sparse 维持存在感达到阈值后再用 full 完整刷新。测试用例plan.test.ts的plan mode injection cadence描述块恰好验证了这套节奏首次注入含Plan mode is active与Plan file:的 full 提醒 → 立即再次注入不重复上下文长度不变→ 追加 2 个助手回合后注入含Plan mode still active的 sparse 提醒 → 退出后只注入一次 exit 提醒。3.3 计划文件路径页脚fullReminder/sparseReminder/reentryReminder三个函数都会调用withPlanFileFooter当存在计划文件路径时在提醒正文后追加一行Plan file: path当计划文件路径为空宿主未提供时则改用对应的PLAN_MODE_INLINE_*_REMINDER内联版本——这也解释了为什么目录里同时存在“带路径”与“inline”两套文档。四、计划文件生命周期从创建、写入到版本快照4.1 计划文件路径约定根据planService.ts的planFilePathFor计划文件固定存放在会话目录下sessionDir/agents/agentId/plans/planId.mdplanId由generateHeroSlug(randomUUID(), new Set())生成见createPlanIdenter()时会先ensurePlanDirectory递归创建目录createFile为 true 时还会用writeEmptyPlanFile预创建一个空文件。4.2 EnterPlanMode / ExitPlanMode 工具PlanFeature注册了两个工具domain 均为planEnterPlanMode参数为空对象z.object({}).strict()见enter-plan-mode.ts执行时若计划模式已激活则报错否则调用planMode.enter()并返回包含工作流指引的结果消息含计划文件路径版本与无路径版本见enterPlanModeTool.ts。ExitPlanMode可选参数options13 个方案label 唯一且禁用保留词执行时从计划文件读取计划内容而非接收参数ExitPlanModeReview在非 auto 权限模式下把计划以plan_review展示交给用户批准批准后输出Plan mode deactivated. All tools are now available.并附上已批准计划与“Selected approach”提示当用户选择了某个 options 方案时。4.3 版本快照 recordRevision每次调用ExitPlanMode前见exitPlanModeTool.tsAgentPlanService.recordRevision()会把当前计划文件内容以plan/id/vversion.md的 key 存入 BlobStore并派发PlanRevision事件记录版本号、sha256 与字节数见planService.ts。这意味着每次提交审批的计划都留有可追溯的不可变快照。4.4 权限模式对流程的影响全链路中权限模式permission mode是关键变量EnterPlanMode在所有权限模式下都是自动进入无需批准提示ExitPlanMode在yolo 与 manual 模式仍会向用户呈现计划等待批准在auto 模式下则直接读取计划文件、退出计划模式而不询问用户见exit-plan-mode.md与exitPlanModeTool.ts的 auto 分支输出中明确标注“auto-approved without user review”。五、审批结果处理ExitPlanModeReview 的分支语义ExitPlanModeReview.approvalResult对用户的审批响应做了精细分流用户操作结果语义approved批准plan.exit()退出计划模式若选了 options 中的方案输出Selected approach: label\nExecute ONLY the selected approach...明确禁止执行未被选中的备选方案cancelled取消/关闭弹窗不退出输出 “Plan approval dismissed. Plan mode remains active.”Reject and Exit退出计划模式并 stopTurn输出 “Plan rejected by user. Plan mode deactivated.”Revise / 附带反馈不退出把用户反馈原样返回给模型“User rejected the plan. Feedback: ...”或提示 “User requested revisions. Plan mode remains active.”Rejected普通拒绝不退出、stopTurn输出 “Plan rejected by user. Plan mode remains active.”所有分支都会记录plan_resolved遥测事件outcome 分别为approved、dismissed、rejected_and_exited、revise、rejected为后续的流程分析提供数据基础。六、从文档到上下文的完整注入链路把全链路串联起来一次完整的“计划模式体验”可以描述为用户在非平凡任务新功能、多方案、架构决策、多文件改动等判定标准见enter-plan-mode.md中让 Agent 调用EnterPlanModeAgentPlanService.enter()创建计划文件目录并派发plan_mode.enter事件下一回合开始时PlanModeInjection回调被触发plan.status()返回激活状态、planWasActive为 false于是把full reminder附Plan file: ...页脚以origin: { kind: injection, variant: plan_mode }的 user 消息形式拼接到上下文测试快照中的plan-mode-reminder即此消息的占位见plan.test.tsAgent 按五步工作流操作只读探索 → 设计 → 写计划文件期间guardToolExecution持续拦截 Write/Edit/TaskStop/Cron* 等违规调用计划就绪后调用ExitPlanMode记录计划版本快照 → 生成plan_review展示options 可选→ 用户批准/拒绝/修订批准后plan_mode.exit事件派发、遥测模式从plan切回agent下一回合planWasActive为 true 且plan.status()为 null注入exit reminder告知 Agent 恢复全部工具权限随后继续执行已批准的计划。七、工程启示提示词注入设计要点从plan-mode-full-reminder.md及其配套实现中可以提炼出几条可复用的工程经验提示词即契约代码即执行文档中的禁令只读、只写计划文件、屏蔽定时任务工具与planService.ts的工具守卫一一对应模型提示与硬性拦截双保险避免模型“忘记规则”分级提醒对抗上下文衰减full / sparse / reentry / exit 四档提醒 2/5 回合阈值兼顾约束可见性与 token 成本避免每回合重复注入完整长文内联变体兜底无路径场景宿主未提供计划文件路径时自动降级为 inline 版本保证不同宿主环境下的行为一致性所有状态变更可追溯plan_mode.enter/exit/cancel、plan.revision均为 durable 事件配合 BlobStore 版本快照让计划流程可回放、可审计。如需深入阅读源码可重点关注以下文件提醒文档全集packages/agent-core-v2/src/features/plan/injection/注入决策引擎planModeInjection.ts计划服务与守卫planService.ts工具定义与批准流exitPlanModeTool.ts、exitPlanModeReview.ts频率与场景测试test/features/plan/plan.test.ts赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐Kimi Code 计划模式Plan Mode重新进入提醒注入机制从 reentry-reminder 到 PlanModeInjection 的完整解析Kimi Code 计划模式Plan Mode重新进入提醒注入机制从 reentry reminder 到 PlanModeInjection 的完整解析AI Agent代码智能体人工智能大模型CLIKimi Code Plan Mode 重新进入提醒Re-entry Reminder机制全解析无计划文件宿主下的上下文恢复与提示词注入原理Kimi Code Plan Mode 重新进入提醒Re entry Reminder机制全解析无计划文件宿主下的上下文恢复与提示词注入原理 Plan MAI Agent代码智能体人工智能大模型CLIKimi Code agent-core-v2 Swarm 模式退出机制exit-reminder 提醒注入原理与 Agent 行为指导Kimi Code agent core v2 Swarm 模式退出机制exit reminder 提醒注入原理与 Agent 行为指导 SwarmAgenAI Agent代码智能体人工智能大模型CLI上一篇vue-vben-admin 组件设计指南5 步用原子组件 组合式 API 搭出业务页面下一篇掌握HTMX hx-valsPOST请求数据处理的终极指南 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考