spawn 新线程、fork_context 默认不带全文、文件未必隔离、wait/close/深度名额，以及主 Agent 如何对照工作区验收。
前面讲了单 Agent 调工具、持续工作、整理上下文。现在让它多找几个帮手——多 Agent 时真正要设计的是：任务怎么交代清楚、子任务该看到哪些材料、做到哪一步怎么知道。第四章沿任务拆分、上下文交接与结果核验拆解。
一个小案例：并行取证，主 Agent 改与验
测试报错：空字符串走旧接口返回不符合预期。主 Agent 可保留修改权，把两件互不依赖的调查拆出去：一个只读定位「输入经过哪些函数」；另一个分析失败测试与已有兼容性用例。各自要说清：查什么、能操作什么、最后返回什么以便核对。若两项都必须马上改同一函数，就不宜并行写入——可先并行收集证据，再由主 Agent 集中修改。这是任务分配方法，不是系统自动识别了所有依赖。
创建子 Agent：新线程，不是同会话里多插一个角色
创建前会准备相关配置、检查是否允许创建，再建立新线程，把任务作为初始输入交给它。线程有自己的历史与运行状态；程序记录派生层级与来源关系，后续按编号补充输入或等待结果。创建工具返回的 agent id 是后续操作的地址——只说明创建与提交走到了一步，不能当子任务的最终答案。主 Agent 可先做别的事，稍后再收结果。
上下文交接：默认不自动带上父线程全文
相关接口里，类似 fork_context 的选项默认常为 false：不会因为叫「子 Agent」就自动带上父线程整段对话。目标、文件位置、约束与交付要求仍要写清楚。若启用 fork，程序会分岔交接父线程可用历史并做整理——不是共享同一份不断变化的对话；分出去后两边各自继续，父线程随后新增的要求也不会凭空变成子线程已读材料。约束场景下：直接写在任务里并附上要看的文件；继承历史能减少重复说明，但不代替明确交接。
文件隔离是误解
创建路径会继续相关环境与执行配置，但未必给每个子 Agent 默认建独立工作区——多个线程仍可能面对同一套文件。一个在读函数时，另一个可能正在改；两人同时改同一文件，也不会因为都说「完成」就自然正确。独立的是各自对话与执行状态；文件是否隔离看实际执行环境。案例里两个子任务宜先做只读调查；真正权利限制靠工具策略与沙箱。并行写入时要明确划分文件。
中途改要求：发给对应线程
测试分析已开始，用户补充「旧接口对空字符串也必须保持原样」——主 Agent 要把这条发给负责测试的线程，而不是只在自己最终回复里记一句。按目标编号提交新输入；默认往往不先中断，底层会按目标线程是否在忙决定开新一轮或并入正在运行的轮次。工具返回的是提交编号，不是「对方已理解并完成修改」的证明。方向已不合适时可显式中断再交新输入；中断也不会撤回已写在磁盘上的变化——转向后仍要确认最终状态。
等待结果 ≠ 工作验收通过
wait_agent 一类接口可同时观察几个目标：有人已到最终状态就直接返回，否则订阅变化，等到某个结束或等待超时。不要求所有目标一起完成才返回。完成状态描述的是工作轮次，并不替你判断代码是否符合要求。timeout=true 只说明这次等待没拿到最终状态，不会因此自动取消子任务——主 Agent 可稍后再等，避免把「还在分析」误当成失败并重复创建。
深度与名额限制
创建子线程前会算下一层深度，超过配置允许的层级就拒绝继续派生。线程名额路径里，常需关闭并移除线程后再释放名额——子任务返回「完成」≠ 线程已关、名额一定可用。深度管层数，名额管可保留线程数；默认数字也不是所有环境的固定上限。实用做法：先确认任务能否独立，再决定开几个；不需要的线程及时走明确关闭（如 close），必要时按编号 resume；恢复线程 ≠ 复活所有外部进程。
主 Agent 的汇总核验
定位 Agent 说问题在空字符串分支；测试分析 Agent 建议补旧接口兼容用例。主 Agent 要把判断与工作区实际匹配：报告指向的文件/函数是否对应当前版本；修改是否只改变目标行为；跑相关测试确认空字符串修好且旧接口其他行为未破坏。报告里只有「应该没问题」却缺证据，就不能结案。多 Agent 能并行获线索，也能并行产生误判——主 Agent 要决定采纳哪一结论、补哪些检查，并把最终结果讲清楚。分工收益要到汇总核验这一步才落实。
协作闭环自检
- 任务是谁负责的？
- 上下文从哪里来？
- 文件谁能改？
- 结果怎么验收？
下一期看 AGENTS.md：项目规则从哪被发现、如何进入请求、写了却没生效时查哪里。