Agent 与子 Agent

Kimi Code CLI 中的 Agent 是驱动会话的核心。一次会话始终由一个主 Agent 主持，主 Agent 在执行任务过程中可以根据需要派发子 Agent 来处理更聚焦的子任务。

主 Agent 负责理解用户的整体意图、规划步骤、与用户对话、调用工具，并最终汇总结果。它的上下文贯穿整个会话，是用户在终端中直接交互的对象。

子 Agent 则是主 Agent 临时派生出来的"助手"。它接受一份明确的任务描述，在自己的上下文里独立完成工作，再把结论返回给主 Agent。子 Agent 不会与用户直接对话，也不会混入主 Agent 的上下文历史。这种分工特别适合"探索代码库"、"审阅大段实现"、"规划复杂改动"这类边界清晰、需要大量阅读但产物较短的工作。

内置子 Agent

Kimi Code CLI 内置了三种子 Agent，分别面向不同的任务形态，开箱即用：

• coder：默认子 Agent，通用的软件工程助手，可以读写文件、执行命令、搜索代码并落地具体改动。
• explore：代码库探索专用，只做只读操作，不会修改任何文件。适合在不修改文件的前提下快速搜索、阅读和总结仓库。
• plan：实现规划与架构设计专用，工具集进一步收窄，连 Shell 命令都不提供，专注于"想清楚怎么做"而不是"动手做"。

调用方式

子 Agent 由主 Agent 自动调度。主 Agent 会根据任务复杂度、上下文消耗以及子任务的独立性，在需要时自动派发，无需用户手动指定。

每次派发都会在终端中以审批请求的形式呈现（除非命中已有的 allow 规则或处于 YOLO 模式），方便你审视任务描述。你可以在与主 Agent 的对话中直接指定子 Agent 类型，例如"先用 explore 把相关文件梳理一遍再动手"。

子 Agent 也可以放在后台运行，完成后结果会自动回到主 Agent，无需手动轮询。也可以唤回已有的子 Agent 实例继续推进同一任务。

上下文隔离与资源开销

每个子 Agent 都拥有完全独立的上下文窗口。它看不到主 Agent 的对话历史，只能看到主 Agent 显式传入的任务描述。子 Agent 自己的中间思考和工具调用记录不会回流到主 Agent，只有最终结果会出现在主 Agent 的上下文里。

这种隔离带来两个好处：一是主 Agent 的上下文保持精炼，长会话中不会被大量探索性日志撑满；二是多个子 Agent 可以并行运行，互不干扰。

需要注意的是，每个子 Agent 都会独立消耗模型 token，因此简单任务上没有必要派发子 Agent，主 Agent 直接处理反而更经济。子 Agent 也不支持继续嵌套调度。

权限继承

子 Agent 的权限规则继承自主 Agent：主 Agent 通过 /permission 或在审批中接受的"始终允许"规则，会自动覆盖到它派发出的所有子 Agent，子 Agent 不需要重新审批同一类工具调用。Agent 工具本身默认放行，因此主 Agent 可以在不打断用户的前提下完成多次委派。

如果你希望某一类工具在子 Agent 中始终不可用，应该收紧主 Agent 的权限规则。

会话目录中的存储位置

子 Agent 的运行状态会持久化到当前会话目录的 agents/ 子目录下，每个子 Agent 实例对应一个独立的子目录，其中包含按时间顺序记录提示词、消息历史与最终状态的 wire.jsonl 文件。后台子 Agent 还会通过 tasks/ 子目录暴露生命周期状态。

注意

会话目录、wire 文件和任务记录都属于本地调试材料，可能包含用户 prompt、命令输出、仓库路径、工具返回内容或凭证痕迹。不要把这些文件直接提交到公开仓库、issue 或聊天记录里；确实需要分享时，请先脱敏。