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 在动手实现前先与用户对齐方案的核心工作流而“重新进入”re-entry场景——即 Agent 曾处于 Plan Mode、随后退出又因任务恢复或会话继续而再次进入——是其中最容易被忽略、也最容易造成上下文混乱的环节。本文以 plan-mode-inline-reentry-reminder.md 这一注入模板为切入点结合 planModeInjection.ts 的源码实现与配套测试用例完整讲解 re-entry 提醒的内容结构、触发条件、与 full/sparse 提醒的调度差异以及它在无计划文件宿主如远程/受限环境下的退化策略。读完本文你将能理解这份提示词模板在 Plan Mode 状态机中的确切位置掌握 Agent 如何在“恢复旧规划会话”时重新评估需求、澄清约束并安全请求退出 Plan Mode并能在自己的 Agent 或插件实现中复刻这一提示词注入模式。什么是 Plan Mode 与 re-entry 提醒在 Kimi Code 的 Agent 核心实现中Plan Mode 是一种受控执行状态Agent 只能读取、探索与规划禁止直接修改系统直到用户批准其计划。这一机制由plan特性Feature统一承载见 planFeature.ts它注册了AgentPlanService作为规划服务并暴露EnterPlanMode与ExitPlanMode两个工具域均为plan。当 Agent 从一次规划会话中退出、又在后续任务中再次进入 Plan Mode 时就发生了“重新进入”re-entry。此时 Agent 需要区分两种子场景首次进入此前没有规划记录需要走完整的 explore → design → review → write plan → ExitPlanMode 工作流重新进入磁盘上已有或宿主提供历史计划文件Agent 必须决定是沿用旧计划还是重写新计划否则极易把新旧任务的上下文混在一起。为了覆盖这两类场景仓库在 injection 目录 下维护了 7 份提示词模板其中与本主题直接相关的两组是带计划文件路径的完整版plan-mode-reentry-reminder.md场景已有历史计划文件需要读取并评估无计划文件路径的内联版plan-mode-inline-reentry-reminder.md场景本宿主没有提供计划文件路径即本文主角。内联 re-entry 提醒的完整内容解析plan-mode-inline-reentry-reminder.md 全文只有 11 行却精确地规定了 Agent 在“无计划文件宿主下重新进入 Plan Mode”时必须遵守的行为边界。逐段拆解如下。1. 强制只读约束最高优先级Plan mode is active. You MUST NOT make any edits or otherwise make changes to the system unless a tool request is explicitly approved. Prefer read-only tools. Use Bash only when needed; Bash follows the normal permission mode and rules. This supersedes any other instructions you have received.这一段与 full 提醒plan-mode-full-reminder.md共享同一套硬约束任何编辑或系统变更都必须先获得工具级审批优先只读工具Bash仅在有需要时使用且仍遵循常规权限模式。最后一句 “This supersedes any other instructions you have received” 是注入模板通用的“防越权”声明——它确保即使对话历史中存在相互矛盾的高层指令Plan Mode 的只读约束依然优先。值得注意的是full 提醒在此基础上还额外屏蔽了TaskStop、CronCreate、CronDelete三个工具必须先ExitPlanMode才能调用而内联 re-entry 提醒并未重复这一清单因为它面向的宿主通常连计划文件路径都无法提供约束以最小必要集合为主。2. 声明无计划文件路径的事实## Re-entering Plan Mode No plan file path is available in this host.这是内联版与完整 re-entry 版最关键的分野。完整版plan-mode-reentry-reminder.md会告诉你“A plan file from a previous planning session already exists”并要求读取既有计划文件而内联版明确承认当前宿主没有计划文件路径。这意味着 Agent 无法通过“读旧计划文件”来恢复上次的规划上下文只能依靠对话历史本身。3. 三步恢复流程Before proceeding: 1. Re-evaluate the user request and any existing conversation context. 2. Use AskUserQuestion to clarify missing requirements or user preferences that affect the plan. 3. Wait for the host to provide a plan file path, write the revised plan there, then call ExitPlanMode.第一步重新评估用户请求与既有会话上下文。由于没有计划文件可供回读Agent 必须从消息历史中重建“上次规划到哪了、结论是什么”第二步用AskUserQuestion澄清影响计划的需求缺口或用户偏好。这一点与完整版第 5 步一致强调“宁可先问清楚也不要基于残缺上下文瞎猜”第三步等待宿主提供计划文件路径在该路径写入修订后的计划然后调用ExitPlanMode请求批准。4. 回合终止约束Your turn must end with either AskUserQuestion (to clarify requirements) or ExitPlanMode (to request plan approval).这是所有 Plan Mode 提醒模板的公共“硬性回合规则”Agent 的每一轮都必须以AskUserQuestion澄清需求或ExitPlanMode请求批准收尾不允许以其他方式结束回合从而确保规划会话始终在向“产出计划并获批”收敛而不是无限探索。源码视角re-entry 提醒是如何被选中和注入的模板本身只是一段静态文本真正决定“什么时候注入哪份模板”的是 planModeInjection.ts 中的PlanModeInjection服务。它以PLAN_MODE_INJECTION_VARIANT plan_mode的变体名向提醒服务IAgentReminderService注册在每次 agent 步骤开始前被动态调用。触发判定状态翻转 计划内容非空re-entry 提醒的注入核心逻辑位于构造函数注册的回调中其判定路径如下调用this.plan.status()获取当前 Plan Mode 状态若状态为null已退出若此前plan.wasActive状态为true则置为false并注入退出提醒 plan-mode-exit-reminder.md否则不注入任何内容若状态非nullPlan Mode 活跃且plan.wasActive此前为false即刚刚进入将plan.wasActive置为true然后检查计划文件内容——若已有非空白内容返回reentryReminder(planFilePath)若为空则返回fullReminder(planFilePath)若状态非null且此前已处于活跃持续驻留场景则走planModeReminderVariant的节奏调度full / sparse本文不展开。也就是说re-entry 提醒专用于“恢复的 Plan Mode 已经带有一份既有计划内容”的场景——这正是“重新进入”语义的精确实现不是从零开始规划而是恢复一份已经存在的规划。内联版 vs 完整版的二选一reentryReminder与fullReminder、sparseReminder一样都遵循同一套“退化策略”function reentryReminder(planFilePath: PlanFilePath): string { if (planFilePath null || planFilePath.length 0) { return PLAN_MODE_INLINE_REENTRY_REMINDER; } return withPlanFileFooter(PLAN_MODE_REENTRY_REMINDER, planFilePath); }当planFilePath为空当前宿主无法提供计划文件路径时注入内联版 plan-mode-inline-reentry-reminder.md即本文主题当存在计划文件路径时注入完整版 plan-mode-reentry-reminder.md并追加Plan file: path页脚由withPlanFileFooter拼接见 planModeInjection.ts。这种“内联版/完整版”双轨结构同样存在于 full 与 sparse 提醒中形成一套整齐的 6 份模板矩阵full/sparse/reentry×inline/with-file外加一份退出提醒。内联版的存在正是为了在没有文件系统路径语义的宿主例如某些远端执行环境、受限沙箱中依然能向模型传达完整的 Plan Mode 行为约束而不依赖“读文件”这一动作。测试验证re-entry 提醒的注入行为仓库用两组测试锁定该行为可作为复现与验证的依据。单元测试恢复会话触发 re-entry 提醒planModeInjection.test.ts 中的用例injects a reentry reminder when restored plan mode already has plan content第 119-129 行精确复现了该场景it(injects a reentry reminder when restored plan mode already has plan content, async () { readText vi.fn(async () # Existing Plan\n\n- Keep this context); await ctx.dispatch({ type: plan_mode.enter, id: restored-plan, }); await injectDynamic(ctx); expect(lastPlanReminder(context)).toContain(Re-entering Plan Mode); });测试要点先用readTextmock 出非空的既有计划内容# Existing Plan再派发plan_mode.enter事件恢复一个已存在的规划会话随后通过runWillBeginStepHooks触发动态注入最终断言注入的消息包含Re-entering Plan Mode标题。这从行为上确认了只要恢复的 Plan Mode 已带内容就会走 re-entry 分支。同一文件中的辅助函数也很有参考价值planReminderMessages过滤出origin.kind injection origin.variant plan_mode的消息lastPlanReminder取最后一条注入提醒的纯文本内容——这解释了为什么模板里的段落顺序、标题措辞会被测试严格断言。集成测试完整 re-entry 工作流plan.test.ts 第 863 行附近的用例emits a reentry reminder when restored plan mode already has plan content从端到端视角验证同一行为覆盖了从会话恢复、状态注入到提醒产出的完整链路。结合两处测试可确认re-entry 提醒是“恢复型 Plan Mode”的默认提示而非异常分支。与其他 Plan Mode 模板的对比把 7 份模板放在一起横向对比能更清晰地定位 re-entry 提醒的位置模板触发场景计划文件核心指令plan-mode-full-reminder.md首次进入或超过刷新阈值有路径5 步工作流 多方案处理 工具屏蔽plan-mode-inline-full-reminder.md同上但宿主无文件路径无简化 4 步工作流 AskUserQuestion 澄清plan-mode-sparse-reminder.md持续驻留的稀疏提醒有路径只读 可改计划文件 回合规则plan-mode-inline-sparse-reminder.md同上但宿主无文件路径无只读 等待文件路径 回合规则plan-mode-reentry-reminder.md重新进入且已有计划内容有路径读旧计划 → 评估 → 更新/重写 → ExitPlanModeplan-mode-inline-reentry-reminder.md本文重新进入但宿主无文件路径无重新评估 → AskUserQuestion → 等路径 → ExitPlanModeplan-mode-exit-reminder.mdPlan Mode 刚被关闭—解除只读限制按已批准计划执行两个关键差异值得注意re-entry 与 full 的分工full 面向“空白计划”的从零规划re-entry 面向“已有计划内容”的恢复。判定依据是data.content.trim().length 0planModeInjection.ts——内容非空即走 re-entryre-entry 与 sparse 的分工sparse 是在同一轮持续规划中的轻量提醒防止模型遗忘约束re-entry 则是跨会话/跨回合重新进入时的完整恢复提醒。前者属于频率调度PLAN_MODE_DEDUP_MIN_TURNS 2、PLAN_MODE_FULL_REFRESH_TURNS 5后者属于状态翻转检测。无计划文件宿主的退化设计启示从这份内联模板可以提炼出一个可复用的提示词注入设计模式显式声明环境限制模板开头直接说明 “No plan file path is available in this host”让模型明确知道自己缺少哪个上下文来源避免它去幻想一个不存在的文件路径或做无效的文件读取尝试提供降级恢复路径没有计划文件就要求模型“重新评估用户请求 会话上下文”用对话历史替代文件作为规划依据强制澄清动作用AskUserQuestion把“需求缺口”显式化为模型必须执行的动作而不是可选的建议保留出口即使环境受限ExitPlanMode仍是回合的合法收尾确保规划流程永远不会死锁在“等文件路径”上——如果宿主始终不给路径模型仍会以AskUserQuestion维持对话并等待下一步输入。这套思路在 Kimi Code 中被inline系列模板完整实践无论宿主能否提供计划文件模型收到的指令语义始终等价只是把“读写文件”替换成了“等待宿主提供路径”。对于在远端服务器、容器或受限权限环境中运行 Agent 的开发者而言这正是值得直接借鉴的实现范式。小结plan-mode-inline-reentry-reminder.md 虽是一份 11 行的提示词模板却是理解 Kimi Code Plan Mode 状态机的关键切片它定义了 Agent 在“无计划文件宿主上重新进入规划会话”时的全部行为边界——强制只读、重新评估上下文、用AskUserQuestion澄清、等待宿主提供计划文件路径后再ExitPlanMode。结合 planModeInjection.ts 中plan.wasActive状态翻转与content.trim().length 0的内容判定以及 planModeInjection.test.ts 中restored-plan用例的验证你可以完整复刻这套“恢复型规划会话”的提示词注入机制也可以直接参考inline系列模板为自己的 Agent 在受限宿主上设计同样健壮的上下文降级策略。赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐如何实现Universal Android Debloater的跨平台自更新系统技术架构深度解析如何实现Universal Android Debloater的跨平台自更新系统技术架构深度解析 Universal Android DebloaterUAAI Agent代码智能体人工智能大模型CLIAnarlog 桌面版本发布全流程从 Nightly 候选验证到 Stable 稳定版发布与多平台分发Anarlog 桌面版本发布全流程从 Nightly 候选验证到 Stable 稳定版发布与多平台分发 本文以 Anarlog 仓库中的发布技能清单 .cuAI Agent代码智能体人工智能大模型CLIOpen Interpreter 的 kimi-cli 线束拆解「Kimi Code CLI」系统提示词模板与其运行时注入机制Open Interpreter 的 kimi cli 线束拆解「Kimi Code CLI」系统提示词模板与其运行时注入机制 本文以 codex rs/co人工智能大模型AI Agent代码智能体AI 应用CLI上一篇aspnetboilerplate 集成消息队列RabbitMQ 与 Kafka 应用场景下一篇pytest 7.2.2 发布说明Bug 修复版详解与升级指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考