Kimi Code的子Agent Fork能力允许从当前Agent会话快照创建新的子任务。与从空白上下文启动相比，子Agent能直接理解已经讨论的需求、约束和已有结论，减少重复交代背景。它也带来新的风险：错误假设会一并复制，多个Agent可能处理重叠文件，最终结果还需要主Agent统一判断。
一、Fork到底复制了什么
Fork的核心是从调用时的会话历史创建上下文快照。子Agent看到主任务此前的重要信息，但之后拥有独立执行路径。它不会自动知道其他子Agent随后做了什么，因此并行任务必须预先划清边界。可以把它理解为从同一项目会议记录出发，让不同成员分别完成研究。
二、怎样开启实验能力
官方文档提供环境变量和配置文件方式开启subagent_fork实验选项。团队应先在测试项目使用，不要直接把实验能力加入生产自动化。配置应进入版本管理的示例文件，敏感信息通过环境变量注入。升级Kimi Code后还要重新查看变更记录，确认开关名称和行为是否改变。
三、适合拆分的任务类型
适合并行的任务包括：一个子Agent查接口契约，一个检查数据库影响，一个审阅前端状态；或者分别调查多个互不依赖的技术方案。不适合并行的是多个Agent同时修改同一核心文件、共同调整数据库迁移，或在前置结论尚未确定时大量写代码。先调查、后决策、再分工，冲突会少很多。
四、给子Agent写清交付边界
每个任务应包含目标、允许读取的范围、禁止修改的区域、输出格式和完成标准。例如：“只分析登录失败原因，不修改代码；列出调用链、证据和建议。”如果允许编辑，则明确文件所有权。不要只说“帮我处理后端”，否则多个子Agent很可能产生平行实现和重复补丁。
五、权限不能因为Fork而扩大
子Agent继承上下文不应等于继承全部系统权限。涉及生产数据库、部署密钥和用户隐私时，仍应使用最小权限与人工审批。主Agent可以把必要的脱敏结果交给子Agent，而不是开放完整凭证。工具调用日志也要区分具体Agent，方便出现问题后追踪来源。
六、设置独立超时
AgentSwarm支持设置独立超时，避免某个研究任务无限运行。超时时间应根据任务类型区分：文档检查可以较短，大型代码分析可以更长。超时后不要立即无限重试，应先读取已有输出，判断是范围过大、工具失败还是需要更多信息。把大任务拆成可在明确时间内完成的小任务更有效。
七、主Agent如何合并结果
子Agent返回后，主Agent应先比较结论是否冲突，再核对证据，而不是简单拼接文本。如果一个建议改接口、另一个建议改前端兜底，应回到接口契约判断根因。合并结果时记录采纳和未采纳理由，并确保只有一个执行方案进入代码。多Agent提升的是调查并行度，不是同时写入的数量。
八、推荐的完整流程
先由主Agent读取项目规则并明确问题；在关键背景稳定后创建会话快照；按互斥范围Fork两到三个子Agent；设置超时和只读优先；收集结论后由主Agent统一决策；最后只执行一套改动并验证。若初始假设被推翻，应重新建立新的快照，而不是让旧子Agent继续在错误背景上工作。这样才能共享上下文，又不让协作变得混乱。
