Agent 与子 Agent

Kimi Code CLI 创新性地采用主从 Agent 架构，彻底解决了传统AI编码助手长会话上下文溢出、并行任务互相干扰、敏感信息易泄露的行业痛点。主 Agent 负责全局任务调度、用户意图理解与最终结果整合，子 Agent 负责处理高内聚、低耦合的独立子任务，二者配合DeepSeek大模型的百万级上下文能力与强推理特性，既可以处理覆盖全项目的复杂开发需求，又能通过上下文隔离大幅降低token消耗、提升任务执行效率。 通过阅读本文，你将全面掌握子 Agent 的核心原理、内置类型、调度逻辑、权限配置、调试方法，能够根据业务场景灵活运用主从Agent架构提升开发效率。

Kimi Code CLI 中的每次会话都由一个主 Agent 驱动。主 Agent 理解用户意图、规划步骤、调用工具，并在需要时向外派发子 Agent 处理更聚焦的子任务——例如探索一个陌生代码库、并行审阅多处实现、或在不触碰主上下文的情况下规划一次大型重构。 子 Agent 接受主 Agent 给出的任务描述，在自己的独立上下文里工作，最后把结论返回。它不会与用户直接对话，中间的思考和工具调用记录也不会混入主 Agent 的历史，既保证了主会话的上下文简洁性，也避免了子任务的中间信息干扰主 Agent 的判断。

内置子 Agent

Kimi Code CLI 内置三种子 Agent，均经过大量业务场景验证，开箱即用，分别面向不同任务形态，可覆盖90%以上的日常开发需求：

• coder：默认子 Agent，通用软件工程助手，可以读写文件、执行命令、搜索代码并落地具体改动。适用于需求落地、bug修复、脚本编写、依赖升级等需要修改文件、执行命令的场景，例如当你提出"修复用户登录接口的空指针异常并验证"的需求时，主 Agent 会自动派发给coder子 Agent，由它完成代码修改、单元测试执行、服务重启验证的全流程。
• explore：代码库探索专用，只做只读操作，不修改任何文件。适合在不改动文件的前提下快速搜索、阅读和总结仓库，例如刚接手陌生项目需要梳理架构、排查问题前需要定位相关文件、生成项目技术文档等场景，不会对现有代码产生任何风险。
• plan：实现规划与架构设计专用，连 Shell 命令都不提供，专注于"想清楚怎么做"而不是"动手做"。适用于大型功能重构前的方案设计、技术选型评估、多模块联调方案制定等不需要实际操作的场景，避免无效的工具调用浪费token，确保方案输出的专业性与完整性。

调用方式

子 Agent 由主 Agent 自动调度——根据任务复杂度（需超过3个工具调用、涉及超过10个文件修改）、上下文剩余容量（当前主上下文已使用超过70%的token配额）、子任务独立性（子任务不需要依赖主会话历史上下文）三个维度综合判断，在适当时机自动派发，无需用户手动指定。 每次派发都会在终端以审批请求的形式呈现（除非命中 allow 规则或处于 YOLO 模式），审批请求会清晰展示子 Agent 类型、任务描述、预估token消耗，你可选择Approve（同意）、Deny（拒绝）、Modify（修改任务描述后派发），方便你审视任务合理性。你也可以在对话中直接指示主 Agent 使用特定子 Agent，例如"先用 explore 把相关文件梳理一遍再动手"，主 Agent 会严格遵循你的指令执行。 子 Agent 支持在后台运行：完成后结果自动回到主 Agent，无需手动轮询，你可在子 Agent 运行期间继续和主 Agent 对话处理其他任务，大幅提升并行处理效率。也可以通过/agents list命令查看所有运行中的子 Agent，使用/agents recall <id>唤回已有的子 Agent 实例继续推进同一任务。

上下文隔离与资源开销

每个子 Agent 拥有完全独立的上下文窗口，与主 Agent 上下文物理隔离，只能看到主 Agent 显式传入的任务描述，看不到主 Agent 的对话历史，主会话中的敏感信息（如数据库密码、API密钥）不会自动传递给子 Agent，可实现敏感任务的安全隔离。子 Agent 自己的中间思考和工具调用记录不会回流，只有最终结果会出现在主 Agent 的上下文里。 这种隔离带来三个核心好处：

• 主 Agent 上下文保持精炼，长会话中不会被大量探索性日志撑满，大幅降低上下文溢出概率，减少token浪费。
• 多个子 Agent 可以并行运行，互不干扰，可同时处理多个独立子任务，提升任务处理效率。
• 敏感任务安全隔离，处理包含敏感数据的子任务时，仅返回最终结果，不会将敏感数据留在主会话历史中，降低信息泄露风险。

需要注意的是，每个子 Agent 都会独立消耗模型 token。简单任务（如修改单个文件的一行代码）主 Agent 直接处理仅需消耗1k左右token，派发给子 Agent 则可能额外消耗2k的基础提示词token，因此简单任务没有必要派发子 Agent，主 Agent 直接处理更经济。子 Agent 也不支持继续嵌套调度，避免出现子 Agent 无限嵌套导致的token爆炸、任务链路不可控问题。

权限继承

子 Agent 的权限规则继承自主 Agent：主 Agent 通过 /permission 或在审批中接受的"始终允许"规则，会自动覆盖到它派发出的所有子 Agent，子 Agent 不需要重新审批同类工具调用，可避免重复审批提升效率。例如你在主会话中审批了"始终允许执行pnpm test命令"，所有派生出的子 Agent 执行pnpm test时都不会再弹出审批。Agent 工具本身默认放行，因此主 Agent 可以在不打断用户的前提下完成多次委派。 如果需要某类工具在子 Agent 中始终不可用，应收紧主 Agent 的权限规则，例如不允许子 Agent 执行rm相关命令，只需在主 Agent 的权限规则中添加deny规则匹配rm命令即可，子 Agent 会自动继承该规则，无法执行对应命令。

指令文件

你可以通过指令文件为 Agent 注入全局或项目级的规则，无需每次手动输入提示词。全局 Kimi 专属指令可放在 $KIMI_CODE_HOME/AGENTS.md（默认：~/.kimi-code/AGENTS.md），当你用 KIMI_CODE_HOME 移动数据根时，这份全局指令文件也会一起移动。跨工具通用指令仍可放在真实 OS home 下的 ~/.agents/AGENTS.md，适合存放所有AI助手通用的规则（如"所有代码必须带TSDoc注释"）。项目级指令仍放在项目目录中，例如 .kimi-code/AGENTS.md 或 AGENTS.md，适合存放当前项目专属的规则（如"本项目禁止直接修改main分支，所有改动必须提PR到dev分支"）。 三类指令文件的优先级为：项目级 > 全局Kimi专属 > 跨工具通用，优先级高的会覆盖优先级低的相同配置。修改指令文件后，运行/reload命令即可生效，无需重启会话。

会话目录中的存储位置

子 Agent 的运行状态持久化到当前会话目录的 agents/ 子目录下，每个子 Agent 实例对应一个独立目录，其中包含按时间顺序记录提示词、消息历史与最终状态的 wire.jsonl 文件，你可直接用文本编辑器打开该文件查看子 Agent 的完整交互过程，方便调试问题。后台子 Agent 还会通过 tasks/ 子目录暴露生命周期状态。 你可通过/session info命令查看当前会话的存储路径，默认存放在~/.kimi-code/sessions/<会话ID>/下。

常见问题（FAQ）

1. 子 Agent 运行失败了怎么办？ 你可运行/agents logs <子Agent ID>查看完整的运行日志，定位失败原因。如果是任务描述不清晰，可重新派发子 Agent 并补充更详细的任务信息。
2. 可以手动终止运行中的子 Agent 吗？ 可以，运行/agents stop <子Agent ID>即可终止，终止后的子 Agent 的部分结果仍然可以通过/agents recall命令获取。
3. 子 Agent 的结果可以修改吗？ 可以，子 Agent 返回结果后，你可直接要求主 Agent 基于结果进行修改，或者重新派生子 Agent 调整任务要求。