Open Interpreter 的 kimi-cli 线束：拆解「Kimi Code CLI」系统提示词模板与其运行时注入机制

2026-09-04 10:26:14作者：邓越浪Henry

本文以 codex-rs/core/src/harness/kimi_cli_prompt.md 这一系统提示词模板为核心，完整解析 Open Interpreter 中 kimi-cli 线束（harness）如何定义模型角色、约束工具调用行为、注入工作环境与 AGENTS.md/技能上下文，并结合 kimi_cli.rs 的源码说明每个模板变量背后的真实填充逻辑与请求组装细节。读完后，你既能读懂这份提示词的每一节设计意图，也能理解它在 Chat Completions 线路上是如何被渲染、缓存和压缩的。

1. kimi-cli 线束在项目中的位置

Open Interpreter 的「线束模式」是一种运行时附加层：它改变面向模型的提示词、工具 schema、消息转换与响应处理，但工具调用仍由原生 Rust 运行时执行，而不是 shell 出去调用外部 Agent 可执行文件。这一机制的总览见 docs/harness.md。

在全部线束中，kimi-cli 的定位是遗留 Python Kimi CLI 的兼容画像：它使用 Chat Completions 兼容请求，附带旧版 Kimi CLI 风格的系统提示词、工作目录列表、AGENTS.md 加载、Kimi 技能发现、prompt 缓存键、推理强度映射与 Kimi 工具 schema。官方文档的建议是：只有当确实需要兼容已退役的 Python CLI 画像时才保留该模式，新的 Kimi 会话应使用 kimi-code。

配置方式（摘自 docs/harness.md）：

harness = "kimi-cli"
harness_guidance = true

单次运行也可以内联指定：

interpreter -c harness='"kimi-cli"' "solve this task"

kimi-cli 的配套工具处理器包括 Shell、ReadFile、WriteFile、StrReplaceFile、Glob、Grep、ReadMediaFile、SearchWeb、FetchUrl、SetTodoList、计划模式控制、后台任务 list/output/stop、AskUserQuestion 和 Agent。

路由是严格的：从 routing.rs 可以看到，wire_api = "chat" 搭配 kimi-cli 会被解析为 ChatHarnessRoute::KimiCli（harness 原生聊天路由），而 wire_api = "messages" 搭配 kimi-cli 会直接报错 wire_api = "messages" is not supported by harness = "kimi-cli"。因此该模式只能跑在 Chat Completions 兼容线路上。

模板本身通过编译期内嵌进入二进制：

// codex-rs/core/src/harness/kimi_cli.rs（第 29-30 行）
const KIMI_CLI_DEFAULT_MAX_TOKENS: u32 = 32_000;
const KIMI_CLI_SYSTEM_PROMPT_TEMPLATE: &str = include_str!("kimi_cli_prompt.md");

2. 模板结构总览：变量与条件块

kimi_cli_prompt.md 不是一段静态文本，而是一个带占位符的模板。运行时的 build_system_prompt 函数（kimi_cli.rs 第 128-185 行）按以下顺序处理它：

先用 render_conditional_block 处理两个条件块（见下表）；
再做 ${VAR} 逐个字符串替换；
最后若会话历史中存在 developer 角色指令，追加一段 # Additional Developer Instructions。

模板变量与填充来源对照：

模板变量	填充来源（源码位置）	说明
`${ROLE_ADDITIONAL}`	`role_additional(session_source)`	子代理会话时插入一段「你是父级 Kimi Code CLI 对话派生的子代理」的限定文本，否则为空串
`${KIMI_OS}`	`current_kimi_os()`	输出 `macOS` / `Windows` / `Linux` 等
`${KIMI_SHELL}`	`kimi_shell()`	Windows 下为 `powershell (\`powershell.exe`)`，其他平台为` bash (`/bin/bash`)`
`${KIMI_NOW}`	`current_kimi_now()`	RFC3339 微秒精度本地时间；若设置了环境变量 `OPENINTERPRETER_TEST_TIME` 则使用该假时间，便于确定性测试
`${KIMI_WORK_DIR}`	`prompt.cwd`	工作目录，缺省为 `.`
`${KIMI_WORK_DIR_LS}`	`cached_work_dir_listing()`	两级目录树形列表，按 `会话ID:目录` 缓存
`${KIMI_AGENTS_MD}`	`load_kimi_agents_md()`	从项目根到工作目录逐级合并的 `AGENTS.md` 内容
`${KIMI_SKILLS}`	`render_kimi_skills()`	按作用域分组渲染的技能清单
`${KIMI_ADDITIONAL_DIRS_INFO}`	当前固定为空串	附加工作区目录信息位（条件块随之被移除）

条件块共两处，均通过 render_conditional_block（第 1299-1330 行）按起始/结束标记匹配并整体保留或删去：

{% if KIMI_OS == "Windows" %}：非 Windows 平台整块删除；
{% if KIMI_ADDITIONAL_DIRS_INFO %}：当前实现恒为 false，整块删除。

3. 提示词正文逐节解析

3.1 角色定义：从「问答者」到「行动者」

模板开头将模型定义为 Kimi Code CLI, an interactive general AI agent running on a user's computer，并确立核心行为准则：通过工具在用户系统上制造真实变更，而不是在文本里描述方案。关键规则包括：

简单问候/不涉及工作目录或网络的提问可以直接回答；其余情况默认走工具；
当一个请求既可以理解为提问也可以理解为任务时，一律按任务处理；
涉及创建、修改、运行代码时必须用 WriteFile、Shell 等工具落盘——「只出现在文本回复中的代码不会被保存到文件系统，也不会生效」；
调用工具时不要附加解释，工具调用应自解释；
回复语言必须与用户语言保持一致。

${ROLE_ADDITIONAL} 注入的子代理限定文本（见 kimi_cli.rs 第 916-925 行）要求子代理聚焦被指派的子任务、保持回复简洁、且不要假设能直接访问人类用户——这对应模板中关于 Agent 工具的委派规则：新建子代理看不到父级上下文，委派时必须携带完整 prompt；若已有子代理握有相关上下文，优先用 agent_id 恢复而不是新建；默认前台执行，仅在「对话需要先继续、且下一步不立即依赖结果」时才设 run_in_background=true。

3.2 工具编排规则：并行调用与系统标签

模板对工具编排有三条强约束：

并行调用：单次响应可输出任意数量的工具调用；若预判多个调用互不干扰，强烈建议并行发出，「这对你的性能非常重要」；
<system> 标签：系统可能把补充上下文包在 <system> 标签里插入用户或工具消息，模型应将其纳入下一步决策——这与运行时对工具输出的包装方式呼应（见第 7 节，失败输出会被包成 <system>ERROR: ...</system>）；
<system-reminder> 标签：与 <system> 不同，这是权威系统指令，必须遵守，可以覆盖或约束正常行为（例如在计划模式下限制为只读操作），且与其所在的那条工具结果/用户消息没有直接语义关系。

3.3 后台 Bash 与任务管理

模板第 23 行是后台任务协议的核心，规定：当 Shell、TaskList、TaskOutput、TaskStop 均可用且自己是根代理时：

通过 Shell 加 run_in_background=true 和一个简短 description 启动后台任务；系统会在任务到达终态时主动通知；
需要时（尤其是上下文压缩之后）用 TaskList 重新枚举活动任务；
TaskOutput 用于非阻塞地取状态/输出快照，只有明确想等待完成时才设 block=true；
启动后台任务后，默认把控制权还给用户，而不是就地空转等待；
TaskStop 仅用于取消；
面向交互用户，任务管理的斜杠命令只有 /task，禁止让用户去跑 /task list、/tasks 等不存在的子命令；
子代理或工具不可用时，不得假设自己能创建/控制后台任务。

另外模板声明：前台工具调用或后台代理的审批请求统一经由「统一审批运行时」协调，并通过根 UI 通道呈现，不能假设审批只发生在某个子代理的回合内。

3.4 编码守则：从 0 到 1 与存量代码库

「General Guidelines for Coding」一节给出两条工作路径：

从零构建：理解需求 → 有疑问就澄清 → 设计架构并制定实施计划 → 以模块化、可维护的方式写代码。并且必须用工具实施变更：WriteFile 创建/覆盖文件、Shell 运行测试、失败则读错误 → 用 WriteFile 或 StrReplaceFile 修复 → 再跑 Shell 验证，形成迭代闭环。

存量代码库（要点逐条）：

动代码之前先用 ReadFile、Glob、Grep 读懂代码库，识别最终目标与最重要的达成判据；
修 bug：查错误日志或失败测试，扫描代码库找根因；用户提到的失败测试在改动后必须通过；
加功能：设计架构、最小侵入地写代码；项目已有测试体系则补新测试；
重构：接口变更时更新所有调用点，不要改动既有逻辑（尤其是测试），只修接口变更引发的错误；
做出达成目标的最小改动；遵循项目既有代码风格；
需要大范围探索或深度调研时，用 Agent 工具加 subagent_type="explore"——这是一个快速、只读、专用于搜索与理解代码库的代理；当任务预计需要超过 3 次搜索查询，或需调查多个文件/模式时启用，且可以并发启动多个 explore 代理调查独立问题。

版本控制方面有一条硬红线：除非用户明确要求，禁止执行 git commit、git push、git reset、git rebase 或其他 git 变更操作；即便早前对话已确认过，每次需要 git 变更时都要重新确认。

3.5 研究与数据处理守则

针对调研、生成/处理多媒体文件的任务，模板要求：

先彻底理解需求，必要时开工前澄清；深度或广度调研前先做计划；
条件允许时上网搜索，精心设计查询词以提升效率与准确率；
用合适的工具、shell 命令或 Python 包处理/生成图片、视频、PDF、文档、表格、演示等；先探测环境里是否已有工具，必须安装第三方依赖时确保装进虚拟/隔离环境；
生成或编辑任何媒体文件后，先读回产物确认内容符合预期再往下走；
避免在当前工作目录之外安装或删除任何东西，确需如此先征得用户同意。

4. 工作环境注入：目录树、OS 与时间

模板「Working Environment」一节声明：运行环境不在沙箱中，任何操作会立即影响用户系统，因此必须极其谨慎；除非被明确要求，不要读写执行工作目录之外的文件。

${KIMI_WORK_DIR_LS} 的目录树由 kimi_cli.rs 第 1342-1410 行的 list_directory 生成，规则很具体：

根目录最多列 30 个条目（KIMI_LIST_DIR_ROOT_WIDTH），每个子目录最多列 10 个条目（KIMI_LIST_DIR_CHILD_WIDTH）；
目录排在文件前面，同级按名称排序；
超出部分折叠为一行 └── ... and N more / ... and N more entries——这正是模板第 93 行提示「tree 只显示前两级，标记了 ... and N more 的条目请用 Glob 或 Shell 进一步探索」的来源；
列表结果按 会话ID:目录 为键缓存在 KIMI_WORK_DIR_LS_CACHE 里，同一会话内不重复枚举。

${KIMI_NOW} 注入 ISO 时间，模板明确其用途是搜索或核对文件修改时间的参考，需要精确时间时应通过 Shell 获取。

5. `AGENTS.md` 的加载与优先级

模板「Project Information」一节解释了为什么单列 AGENTS.md：README.md 面向人类（快速上手、项目描述、贡献指南），而 AGENTS.md 承载编码代理需要的、放进 README 会显得杂乱的细节：构建步骤、测试命令、代码约定。

优先级规则：AGENTS.md 可以出现在目录树任意层级（包括 .kimi/ 目录内），每个文件管辖所在目录及其全部子目录；多个文件同时适用时，深层目录指令优先于父目录；用户对话中的直接指令优先级最高。若修改了 AGENTS.md 中提到的文件/样式/结构/配置/工作流，必须同步更新对应 AGENTS.md。

源码侧的实现（load_kimi_agents_md，kimi_cli.rs 第 944-993 行）与模板描述一一对应：

先用 find_kimi_project_root 向上找含 .git 的目录作为项目根，找不到则退化为工作目录本身；
从根到叶子逐级查找 .kimi/AGENTS.md，以及 AGENTS.md / agents.md（每级取先命中者）；
合并时按从叶子到根的顺序做字节预算分配，总预算 KIMI_AGENTS_MD_MAX_BYTES = 32 * 1024（32 KB）——预算从最深层文件开始扣减，保证深层（优先级更高）的指令优先完整保留，超出部分被截断；
每段内容前标注 ，多段之间以空行分隔。

6. 技能（Skills）体系

模板「Skills」一节定义：技能是可复用的目录化能力，每个技能是一个包含 SKILL.md 的自包含目录，提供领域知识、工作流模式、预配置工具链和参考资料。清单按作用域分组：Project、User、Extra、Built-in；同名技能按 Project 覆盖 User 覆盖 Extra 覆盖 Built-in 的优先级取用。使用策略是「需要时才读 SKILL.md 细节」，以节约上下文窗口。

render_kimi_skills（kimi_cli.rs 第 1082-1107 行）的组装逻辑：

磁盘发现（kimi_skill_roots，第 1113-1148 行）按候选目录取第一个存在者：

作用域	候选路径（按顺序取第一个存在的目录）
Project	`<工作目录>/.kimi/skills` → `.claude/skills` → `.codex/skills`
Project	`<工作目录>/.agents/skills`
User	`<home>/.kimi/skills` → `.claude/skills` → `.codex/skills`
User	`<home>/.config/agents/skills` → `<home>/.agents/skills`
Built-in	`$KIMI_CLI_SOURCE_DIR/src/kimi_cli/skills`

每个技能目录下读取 SKILL.md，用 parse_kimi_skill_frontmatter（第 1221-1262 行）手工解析 --- 包围的 frontmatter 中的 name: 与 description:（description 支持 YAML 块标量 |/|-/|+）；
会话级技能（由上层组装的 <skills_instructions> developer 块解析而来）归入 Extra 作用域追加，按名称小写去重；
渲染格式为 ### <作用域> 下的 - 名称 / Path: / Description: 列表；
磁盘与会话均无技能时，回退到内置清单 builtin_kimi_skill_listing（第 1109-1111 行），固定列出 kimi-cli-help 与 skill-creator 两个内置技能，路径指向 /tmp/kimi-cli/src/kimi_cli/skills/...。

7. 请求组装与消息转换：模板之外的另一半

模板渲染完成后，build_request（第 37-90 行）把系统提示词、历史消息与工具 schema 组装成 Chat Completions 请求：

{
  "model": "<model_info.slug>",
  "messages": [{ "role": "system", "content": "<渲染后的系统提示词>" }, ...],
  "max_tokens": 32000,
  "prompt_cache_key": "<conversation_id>",
  "stream": true,
  "stream_options": { "include_usage": true },
  "tools": [ ... ]
}

几个值得注意的实现事实：

prompt_cache_key 直接取会话 ID（kimi_prompt_cache_key），用于让提供商对同一会话的前缀命中缓存——系统提示词中稳定注入的目录树、AGENTS.md 与技能清单正是缓存友好的大段前缀；
max_tokens 固定 32000；
推理强度映射（apply_reasoning_effort，第 96-126 行）：None 不注入；Minimal/Low → reasoning_effort: "low"；Medium → "medium"；High/XHigh/Max/Ultra → "high"；Custom(v) → 透传自定义值，以上均附带 thinking: { "type": "enabled" }。对「开关型」思考模型（ReasoningControl::ThinkingToggle）：开启思考时注入 thinking.enabled（不强制 effort 档位），未开启则补 thinking.disabled；
工具输出安全包装（kimi_tool_output_content / safe_kimi_tool_text，第 835-879 行）：工具执行失败时输出被包成 <system>ERROR: ...</system>；空输出替换为 <system>Tool output is empty.</system>；含 NUL 字节的输出替换为 <system>Tool returned non-text content.</system>——这些标记正是模板第 19 行 <system> 标签协议的运行时来源，且 is_kimi_system_tool_text 保证这些系统文本不会被二次包装；
消息格式选项：MessageBuildOptions::kimi_cli()（第 216-226 行）保留原始工具调用 ID 格式、不压缩函数参数、裁掉用户消息尾部换行（有专门测试 kimi_user_messages_trim_trailing_newline 验证 "hello\n" → "hello"）、reasoning 内容以 reasoning_content 字段挂到 assistant 消息上。

8. `harness_guidance`：仅对 kimi-cli 生效的附加指导

docs/harness.md 指出：harness_guidance 默认开启，但目前只对 kimi-cli 生效，其他线束忽略它；想要更贴近原始画像的运行可设 harness_guidance = false。源码见 guidance.rs：guidance_for_harness 仅对 Harness::KimiCli 返回 KIMI_CLI_GUIDANCE（第 24-40 行），其内容是一段包在 <extra_instruction> 里的强化编码守则，要点包括：

积极、具体地干活，优先用工具推进而非长篇分析；多步任务尽早用 SetTodoList 并随进度保持更新；
文件系统操作一律用专用工具：检查用 ReadFile/Glob/Grep，新建/替换用 WriteFile，定点编辑用 StrReplaceFile；不要仅为了读写源码而动用 Python 或 shell 脚本；
用户点名的本地文件/脚本/配置/测试/数据路径，只要数量可控，先直接检查再动手做 Shell 实验，不要从任务描述反推实现细节；
提供的数据集、数据库、fixtures、测试输入默认只读；任务要查询/脚本/产物时，写输出文件而不是改输入数据；
构建、测试、快速实验等天然 shell 化的操作用 Shell；长时命令用 run_in_background=true 加简短描述，再用 TaskOutput 查看进度而非无限阻塞；
检查失败时：看具体失败输出 → 做针对性修改 → 重跑最小可用检查，迭代到完成或证实真正的阻塞；
组装 shell 命令时不要用兜底链掩盖失败检查，除非检查了每个分支——兜底成功不证明主检查通过；
同一思路试错两次失败后停止猜变体：重读源码与输出，确认真实验收条件，从证据出发做下一次尝试；
源码或输出已证明某路径走不通时，明确陈述失败假设并排除该类方案，换攻击不同机制的下一步；
收尾前核对产物是否精确满足用户显式约束（路径、格式、长度、前后缀、schema、命令调用方式）；
保持改动最小且聚焦；任务需要改代码/文件时，不能在只做完计划后就停手。

配套测试 current_kimi_code_does_not_receive_legacy_kimi_cli_guidance 明确验证了 kimi-code 不会误收这段遗留指导。

9. 上下文压缩：compaction 提示词

长会话触发上下文压缩时，kimi-cli 线束使用独立的压缩提示词 kimi_cli_compaction_prompt.md，在 compact.rs 第 48-49 行以 include_str! 编译为 KIMI_CLI_COMPACTION_SYSTEM_PROMPT 常量；build_system_prompt 开头会检测「无工具且基础指令正好是该压缩提示词」的场合并直接透传，不再渲染完整系统提示词模板。

该提示词规定压缩的优先级顺序：当前任务状态 > 错误与解法 > 代码演进（只留最终可用版本）> 系统上下文 > 设计决策 > TODO 项；规则上必须保留错误信息、堆栈、可用解法与当前任务，合并相似讨论，删除冗余解释与失败尝试（保留教训），长代码块压缩为签名加关键逻辑（20 行以内的代码保留全文）。输出结构被固定为六个 XML 段：<current_focus>、<environment>、<completed_tasks>、<active_issues>、<code_state>（每个文件含 Summary / Key elements / Latest version）、<important_context>。这与主提示词中「上下文压缩后用 TaskList 重新枚举后台任务」的约定相互配合，保证压缩不丢失活动任务状态。

10. 适用前提与小结

该模板只属于 kimi-cli（遗留画像）线束，且仅兼容 wire_api = "chat"；messages 线路会被 routing.rs 明确拒绝，新 Kimi 会话应优先 kimi-code；
模板中的英文原文是模型的直接输入，${...} 占位符与 {% if %} 条件块均由 kimi_cli.rs 在每次请求前渲染，目录树、AGENTS.md 与技能清单的内容因此随工作区实时变化，而 prompt_cache_key 按会话 ID 保持稳定，使变化部分尽量落在可被提供商缓存前缀之后的位置（从源码结构看）；
模板的设计逻辑可以概括为三层：行为契约（必须用工具落地、并行调用、语言跟随、git 红线）、环境事实注入（OS/shell/时间/目录树/项目指令/技能）、长程可靠性机制（后台任务协议、<system> 标签语义、压缩提示词与 guidance 强化守则）。理解这三层，基本就理解了 Open Interpreter 把一个开源编码 CLI 画像「复刻」进原生运行时所用的全部提示工程手段。