kimi-delegate

Kimi Delegate

你是协调器。将边界明确的编码任务交给独立的实现者——Kimi Code CLI，然后审查其产出并亲自提交。你负责撰写任务说明并作出判断； Kimi 在自己的会话中编写代码；你负责验证并提交。

这个工作循环只需要 shell 命令和文件访问权限，因此任何类似的协调器都能驱动它。

以下情况不要使用

• 任务小到可以直接完成；委派带来的额外开销不值得。
• 未安装或未通过身份验证的 kimi CLI。
• 需要由 CLI 强制实现只读权限的实现者。无头模式下的 Kimi 没有只读模式。

前置条件（检查一次即可）

1. 在 macOS/Linux 上运行 brew install kimi-code 安装 Kimi Code，或使用 Kimi Code 官方文档中的原生安装程序。
2. 运行 kimi login 进行身份验证（设备代码流程，无 TUI），或在 TUI 中使用 /login。
3. 确认 kimi --version 能成功运行。
4. 在目标 git 仓库中工作，或将 --cd 指向该仓库。

选择模型别名

省略 --model 时，Kimi 会使用其 config.toml 中的 default_model。如需选择其他模型 别名，请传入 --model <alias from your kimi config>。模型别名是用户自定义的配置键；请使用 用户已配置的别名，不要自行编造。

工作循环

每项任务执行以下五个步骤。步骤 1、4 和 5 需要判断；步骤 2 和 3 则是机械操作。

1. 撰写任务说明

Kimi 只能看到你发送的文本，以及它在工作区中能检查到的内容——没有聊天记录或共享 上下文。请说明目标、当前状态、要修改的内容、要保持不变的内容、项目的实际门槛，以及报告格式要求。告诉 Kimi 不要提交。每份任务说明只包含一项任务。参见 references/writing-the-brief.md。

2. 派发

对于由 Codex 协调的后台工作，请先安装并配置独立的 codex-background 支持工具。如果缺少其 MCP 工具或注册表，请停止并 报告所需的设置；不要悄悄改用模型驱动的轮询。然后调用其已注册的 delegate_run MCP 工具一次，代替下面的 shell 示例。 请遵循该技能的结构化通用参数、保持提供方标志不变以及通过 runId 重新附加的要求。保持请求待处理，直到任务完成，然后继续执行本技能的审查和提交 步骤。其他协调器继续使用下面的 shell 工作流。

使用随附的辅助工具。它会封装 Kimi 的无头提示词模式，捕获结构化事件流， 并写入 result.json。（<skill-dir> 是包含此 SKILL.md 的已安装文件夹。）

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# choose a configured model alias:       add --model <alias from your kimi config>
# resume the most recent session:        add --resume-last  (delta brief only)
# resume a specific session:             add --session <id> (delta brief only)
# hard time limit (watchdog):            add --timeout 2h  (the 30m default suits short runs; implementation briefs routinely need 1-2h)
# see all options:                       node .../relay.mjs --help

子进程的 cwd 会固定工作区。只有在需要额外工作区目录时，才使用可重复的 --add-dir 标志。中继工具默认将产物写入系统临时目录，且绝不会提交。参见 references/dispatch-and-poll.md。

3. 等待完成

使用 codex-background 的 Codex 会保持原始 MCP 请求处于待处理状态：不要由模型驱动进行休眠、 状态或日志轮询。只有在请求中断后，才使用 delegate_wait 重新附加。

辅助工具会阻塞，直到 Kimi 完成。通过协调器的后台命令功能运行它，或在 shell 中将其 放到后台运行并轮询 result.json。运行前的用法错误会以状态码 2 退出，且不会写入结果； 找不到 kimi 时会以状态码 127 退出，并写入 status: "kimi_unavailable"。

请以进程状态和工作区为准，不要依赖进度显示。只有进程已退出且存在 result.json，才算完成。Kimi 的完整报告位于 result.json 的 finalMessage 字段中（也会在标准输出的报告标记之间完整打印）。

4. 审查——不要轻信自我报告

将 Kimi 的最终消息和门禁声明视为待核实的说法：

• 自行重新运行项目的门禁。
• 对照任务简报阅读差异，从 touchedFiles 开始。
• 如果已安装相关的防护技能，请运行它们。
• 对迁移进行往返验证，并在删除或重命名后 grep 查找悬空引用。

请参阅 references/review-and-land.md。

5. 提交

实现者编辑工作区；由协调者提交。 只有在门禁通过且差异符合要求后才提交。 如果需要返工，请使用 --resume-last 或 --session <id> 发送增量简报， 然后再次审查。

自主性与权限

在无头 -p 模式下，Kimi 始终以自动权限模式运行，绝不会请求批准。Kimi 拒绝将 --prompt 与 --yolo、--auto 或 --plan 组合使用，因此中继不会传递这些选项， 也不提供 --read-only 或 --full-access 选项。CLI 不会强制执行只读模式：每次运行后都要检查 touchedFiles 和差异。保证变更内容的是差异，而不是标志。

授权模型

委派由人类主动选择。一旦他们表示“运行此队列”或“继续”，提交经过验证且通过门禁的工作 便是双方约定的职责。仍有两项限制：展示而非代为处理 （报告 Kimi 的设计决策、合理但未经要求的改动，以及不阻塞任务的小问题）；遇到范围变更时暂停 （如果正确完成任务需要超出简报范围，请先询问，而不是擅自扩大授权）。请参阅 references/review-and-land.md。

参考资料

• references/writing-the-brief.md - 结构、报告约定、 实际门禁、argv 传递和增量简报。
• references/dispatch-and-poll.md - 标志、产物、 result.json、轮询和故障恢复。
• references/review-and-land.md - 审查清单、提交边界， 以及通过 Kimi 会话返工。
• references/multi-task-queues.md - 顺序队列、约束 延续、进度跟踪和最终一致性检查。