多Agent看起来是Codex最容易让人兴奋的能力之一。一个Agent太慢那就开三个。Agent A找问题。Agent B修改代码。Agent C负责测试。理论上1个Agent ↓ 3个Agent ↓ 效率×3但真正放进项目以后很容易出现完全相反的情况三个Agent重复读取同一批文件两个Agent给出互相冲突的Root Cause一个Agent正在改代码另一个还基于旧代码分析测试Agent验证的是修改前状态多个Agent同时写文件最后Diff越来越乱主Agent收到大量结果反而不知道该相信谁。于是多Agent从Parallel Execution变成Parallel Confusion。OpenAI目前的Codex已经支持Subagent Workflow主Agent可以启动多个专门Subagent并行完成独立工作再把结果汇总回主线程。官方也明确建议Subagent最适合处理边界清晰、能够独立完成的工作尤其是代码探索、测试、日志分析和总结对于多个Agent同时进行大量写操作则需要更加谨慎因为代码冲突和协调成本会明显增加。所以真正值得讨论的问题不是怎么开更多Subagents而是什么工作值得拆拆出去以后怎样避免互相干扰一、Subagent真正解决的不是“人手不够”而是上下文隔离先看一个复杂Bug。用户告诉Codex支付接口偶发超时帮我定位并修复。单Agent可能依次做读取支付代码 ↓ 分析调用链 ↓ 查看日志 ↓ 搜索数据库逻辑 ↓ 分析重试机制 ↓ 修改代码 ↓ 运行测试问题在于探索阶段会产生大量临时信息。例如20段日志十几个可能相关文件5个Root Cause假设几条已经排除的路径。这些信息全部堆在主线程以后真正重要的当前目标 任务约束 最终Root Cause 最终Diff反而越来越容易被淹没。OpenAI当前对Subagents的一个核心解释就是把高噪声中间工作移出主线程让主Agent更多保留需求、关键决策和最终结果Subagent返回总结而不是把所有探索日志全部塞回主上下文。所以Subagent真正第一个价值不是Parallelism。而是Context Isolation。可以把它理解成Main Agent 只保存 目标 约束 关键决策 最终状态而Explorer 保存探索噪声Tester 保存测试日志Reviewer 保存Review过程最后只把Distilled Result返回主Agent。这比单纯“多开几个Agent”重要得多。二、什么任务适合拆成Subagents并不是任务越大越应该多Agent。真正适合Subagent的任务通常有三个特点。第一可以独立完成例如Agent A 分析前端登录流程 Agent B 分析后端认证逻辑 Agent C 检查相关测试三个任务即使并行执行也不会相互依赖。这类任务非常适合。第二结果可以明确汇总例如每个Agent最终统一返回Finding Evidence Files Risk Recommendation主Agent很容易比较。OpenAI给出的Subagent建议同样强调每个Subagent最好拥有bounded job clear return format也就是明确边界和明确返回格式。第三工作本身Read-heavy例如代码探索日志分析安全Review测试覆盖检查文档分析。官方也建议从这类Read-heavy任务开始使用并行Agent因为它们天然比多个Agent同时写代码更容易隔离。所以一个非常简单的判断是如果任务主要是“看、找、分析、比较”非常适合并行。如果任务主要是“同时修改同一批状态”就要谨慎。三、最稳定的结构不是“三个Agent一起写”而是 Explorer → Implementer → Verifier我认为开发任务里最值得复用的一种Subagent结构是Explorer ↓ Implementer ↓ Verifier三个角色职责完全不同。Explorer只负责找到真相Explorer负责读取代码搜索调用链查看日志建立Root Cause假设排除错误方向返回证据。它最重要的规则应该是不要修改代码。为什么因为探索阶段最大的问题就是Root Cause还没有确定。如果Agent一边探索一边修改就很容易发生猜测A ↓ 修改 ↓ 发现猜错 ↓ 继续修改 ↓ 产生更多状态最终“调查”和“实施”混在一起。一个更干净的Explorer输出应该类似Root Cause 请求超时来自paymentClient重复Retry。 Evidence payment/client.ts:84 retry.ts:31 相关日志显示同一request被重复发送3次。 Affected Scope payment client retry policy Recommended Fix 限制特定异常的Retry条件。 Uncertainty 尚未验证生产网关行为。Explorer只负责回答问题到底是什么而不是我顺便已经帮你改好了。四、Implementer不要重新调查整个项目第二个角色是Implementer。很多多Agent流程有一个常见浪费Explorer已经分析完了。Implementer启动以后又从头搜索Repository分析代码重新猜Root Cause。这实际上把前面的工作重复了一遍。所以主Agent交给Implementer的应该不是原始问题支付超时帮我修。而应该是已经压缩后的任务包Confirmed Root Cause paymentClient错误地Retry不可重试异常。 Evidence payment/client.ts:84 retry.ts:31 Allowed Scope payment/client.ts retry.ts 相关测试 Constraints 不要修改公共API。 不要升级依赖。 不要修改其他模块。 Done 相关测试通过。这就是Subagent真正有效的地方不同角色之间传递State而不是重复传递Question。于是Explorer 产生Knowledge ↓ Main Agent 确认 ↓ Implementer 消费Knowledge整个系统的信息流会干净很多。五、Verifier为什么最好不要顺手修代码第三个角色Verifier。它最容易被错误设计成测试一下如果有问题顺便修掉。听起来非常高效。但这会破坏角色边界。假设Implementer提交了一个修改。Verifier发现测试失败。然后自己修改代码。再次测试。最后告诉主Agent全部通过。问题来了最终代码到底是谁写的主Agent原本需要验证的是Implementation A现在实际验证的是Implementation A Verifier临时修改B证据链已经变化。所以更可靠的Verifier职责应该是读取Diff ↓ 运行测试 ↓ 检查行为 ↓ 寻找Regression ↓ 返回Evidence如果发现问题Fail ↓ 返回Implementer而不是Fail ↓ Verifier自己偷偷修这实际上类似软件工程里的Separation of Duties。实现和验收不是同一个角色。六、什么时候真正应该并行Explorer → Implementer → Verifier看起来是串行。那Subagent的并行价值体现在哪里最适合并行的是同一个阶段内部。例如复杂Bug的Explorer阶段Explorer A 分析代码调用链 Explorer B 分析日志 Explorer C 检查测试历史三者可以并行。完成以后主Agent汇总Evidence A Evidence B Evidence C ↓ Root Cause然后进入Implement。Code Review也很适合Agent A Security Agent B Test Gaps Agent C MaintainabilityOpenAI当前Subagent文档给出的直接示例就是让多个Agent分别审查安全风险、测试缺口和可维护性然后主Agent等待所有Agent完成再按照类别汇总结果。所以真正合理的原则是同阶段的独立分析可以并行。存在因果依赖的阶段应该串行。也就是Explore A ─┐ Explore B ─┼→ Root Cause Explore C ─┘ ↓ Implement ↓ Verify A ─┐ Verify B ─┼→ Final Evidence Verify C ─┘这比A改代码 B改代码 C也改代码稳定得多。七、多Agent最危险的是“共享可变状态”真正需要小心的不是多个Agent本身。而是多个Agent同时修改同一个State。例如Agent A 修改auth.ts Agent B 同时修改auth.ts这时候无论两个Agent多聪明都可能产生Merge Conflict基于旧代码修改覆盖彼此变化测试状态不一致。官方Subagent文档也明确提示多个Agent同时进行Write-heavy工作会增加冲突和协调开销推荐先从探索、测试、Triage和总结等并行读任务开始。所以多Agent写代码至少需要保证Different Scope或者Isolated Workspace例如Agent A frontend/ Agent B backend/如果确实需要同时修改同一个Repository更成熟的方式通常是结合独立Thread、Branch或Worktree进行状态隔离而不是让多个执行者抢同一个Workspace。Codex本身也把多Agent工作建立在独立线程和并行工作环境之上。八、Subagent Prompt真正重要的是“任务合同”给Subagent一句帮我看看这里有没有问题。几乎没有意义。一个稳定Subagent应该至少收到五项内容Role Task Scope Constraint Return Format例如ExplorerRole 你是只读代码探索Agent。 Task 定位登录接口偶发401的Root Cause。 Scope src/auth src/api 相关测试与日志。 Constraint 不要修改文件。 不要提出无关重构。 Return 1. Root Cause 2. Evidence 3. Related Files 4. Alternative Hypotheses 5. Uncertainty这已经形成了一份Agent Contract。OpenAI的建议同样强调好的Subagent指令应该说明工作如何拆分、主Agent是否需要等待全部结果以及最终应该返回什么摘要或格式。任务越清楚主Agent后续协调成本越低。九、自定义Subagent的价值是把“角色”固定下来如果团队经常重复使用同一类Agent可以进一步把角色配置固定。当前Codex支持Multi-agent配置和自定义角色声明可以为不同Agent角色设置描述、单独配置文件也可以设置默认Subagent模型、Reasoning Effort以及单Session并发线程限制。这意味着以后不必每次重新描述你是安全Reviewer。可以逐渐沉淀成security-reviewer test-reviewer explorer implementer verifier不同角色可以拥有不同InstructionsModelReasoningSandbox权限边界。这时候Subagent已经不再是临时多开一个Chat。而开始变成Agent Role System。十、不同角色甚至不需要使用完全相同的计算配置这也是多Agent很容易忽略的一点。Explorer做大量快速代码搜索与Architecture Reviewer做复杂判断对模型能力的需求并不相同。Codex当前允许为Subagent配置默认模型与Reasoning Effort也允许自定义不同Agent角色的配置官方建议不同Agent根据任务难度选择不同模型和推理设置。所以未来更合理的结构可能不是所有任务 ↓ 最强模型而是Fast Explorer ↓ 快速扫描Deep Reviewer ↓ 复杂判断Verifier ↓ 测试与证据这是Model Routing。当Agent数量真正增加以后这会直接影响速度成本吞吐量。十一、Subagents并不会天然节省Token还有一个非常现实的问题并行不等于更省。每个Subagent都需要单独完成模型推理工具调用上下文处理。所以官方明确提醒Subagent Workflow通常会比相同任务的单Agent执行消耗更多Token。这意味着不要为了看起来高级。把所有任务拆成5个Agent。如果一个任务只需要读取2个文件 改1行代码 跑1个测试一个Agent最快。真正值得拆分的是并行收益 协调成本 额外计算所以Subagent的核心指标不是Agent Count。而应该是Useful Parallelism。十二、什么情况下不应该用Subagents至少有四类。1. 非常小的任务例如修复一个明确的类型错误。一个Agent就够。2. 强串行依赖例如必须先知道A 才能判断B 再决定C强行并行只会让B和C基于猜测工作。3. 多个Agent必须修改同一文件如果没有状态隔离不建议。4. 主任务本身都没有定义清楚如果连Goal Scope Done都不清楚拆出5个Subagent只是把一个模糊任务复制5份。Agent数量不会自动创造清晰度。十三、一个更稳定的Codex Subagent任务模板例如需要处理登录偶发401。可以这样组织【Root Goal】 定位并修复登录偶发401。 【Phase 1Explore】 Spawn 3 read-only subagents Explorer A 分析auth代码调用链。 Explorer B 分析失败日志。 Explorer C 分析相关测试和历史Regression。 所有Explorer统一返回 - Finding - Evidence - File / Log Reference - Confidence - Uncertainty 等待全部完成。 【Main Agent】 比较三个结果 确认Root Cause。 【Phase 2Implement】 Spawn / assign Implementer 仅按照已确认Root Cause修改。 禁止 无关重构 依赖升级 扩大模块范围。 【Phase 3Verify】 Verifier A 运行相关测试。 Verifier B Review Diff与Regression风险。 Verifier不要修改代码。 【Final】 Main Agent汇总 Root Cause Changes Test Evidence Review Evidence Remaining Risk这种工作流最重要的不是用了多少Agent。而是每个Agent都知道自己只负责哪一段。十四、Skills、MCP和Subagents到这里才真正连起来今天三篇文章其实可以组成一套完整结构。第一篇Skills解决重复流程怎么沉淀第二篇MCP解决Agent怎么获得外部工具第三篇Subagents解决复杂任务怎么委派给不同执行单元OpenAI目前对Codex定制体系本身也是把AGENTS.md、Skills、MCP和Subagents视为互补能力项目规则负责长期行为Skills负责可复用流程MCP负责外部系统能力而Subagents负责把工作委派给专门Agent。于是一个真正成熟的任务可以变成AGENTS.md ↓ 定义项目规则 Skill ↓ 定义Bug排查流程 MCP ↓ 读取日志 / Issue / 文档 Subagents ↓ Explorer / Implementer / Verifier Main Agent ↓ 汇总和决策 Verification ↓ 证明完成这已经不是AI帮我写代码。而是在逐渐形成Agent Engineering System。十五、真正值得追求的不是“多Agent”而是“角色清晰”多Agent最容易让人陷入一个数量思维1个不够就3个。3个不够就10个。但真正成熟以后判断系统好坏的问题应该变成谁负责探索谁负责决策谁负责修改谁负责验证哪些事情可以并行哪些状态必须隔离最后谁对Done负责如果这些问题没有答案10 Agents可能只是10个同时产生信息的人而不是一个团队。只有角色、边界、信息流和完成标准都明确以后Explorer Implementer Verifier Main Agent才真正开始形成Agent Team。最后Subagents真正能够提效的条件从来不是能不能同时启动更多Agent。而是任务能否独立拆分 Agent角色是否清楚 写操作是否隔离 返回格式是否统一 主Agent能否汇总决策 最终结果有没有验证所以最值得先尝试的并不是三个Agent一起修改代码。而是多个Explorer并行找证据 ↓ Main Agent确认Root Cause ↓ 一个Implementer负责修改 ↓ 多个Verifier独立验证这种结构既利用了并行能力又避免了多个Agent争夺同一个可变状态。从这个角度看Subagents真正代表的并不是“一个Codex变成很多Codex”。而是Agent工作方式开始从Single Intelligence进入Division of Labor。当探索、实现、验证不再全部塞给同一个Agent以后真正需要设计的就不只是Prompt。而是Agent之间应该怎样分工、怎样传递状态以及怎样形成一条可信的完成链。这才是Subagents真正进入工程工作流之后最值得掌握的能力。
多Agent看起来是Codex最容易让人兴奋的能力之一。一个Agent太慢那就开三个。Agent A找问题。Agent B修改代码。Agent C负责测试。理论上1个Agent ↓ 3个Agent ↓ 效率×3但真正放进项目以后很容易出现完全相反的情况三个Agent重复读取同一批文件两个Agent给出互相冲突的Root Cause一个Agent正在改代码另一个还基于旧代码分析测试Agent验证的是修改前状态多个Agent同时写文件最后Diff越来越乱主Agent收到大量结果反而不知道该相信谁。于是多Agent从Parallel Execution变成Parallel Confusion。OpenAI目前的Codex已经支持Subagent Workflow主Agent可以启动多个专门Subagent并行完成独立工作再把结果汇总回主线程。官方也明确建议Subagent最适合处理边界清晰、能够独立完成的工作尤其是代码探索、测试、日志分析和总结对于多个Agent同时进行大量写操作则需要更加谨慎因为代码冲突和协调成本会明显增加。所以真正值得讨论的问题不是怎么开更多Subagents而是什么工作值得拆拆出去以后怎样避免互相干扰一、Subagent真正解决的不是“人手不够”而是上下文隔离先看一个复杂Bug。用户告诉Codex支付接口偶发超时帮我定位并修复。单Agent可能依次做读取支付代码 ↓ 分析调用链 ↓ 查看日志 ↓ 搜索数据库逻辑 ↓ 分析重试机制 ↓ 修改代码 ↓ 运行测试问题在于探索阶段会产生大量临时信息。例如20段日志十几个可能相关文件5个Root Cause假设几条已经排除的路径。这些信息全部堆在主线程以后真正重要的当前目标 任务约束 最终Root Cause 最终Diff反而越来越容易被淹没。OpenAI当前对Subagents的一个核心解释就是把高噪声中间工作移出主线程让主Agent更多保留需求、关键决策和最终结果Subagent返回总结而不是把所有探索日志全部塞回主上下文。所以Subagent真正第一个价值不是Parallelism。而是Context Isolation。可以把它理解成Main Agent 只保存 目标 约束 关键决策 最终状态而Explorer 保存探索噪声Tester 保存测试日志Reviewer 保存Review过程最后只把Distilled Result返回主Agent。这比单纯“多开几个Agent”重要得多。二、什么任务适合拆成Subagents并不是任务越大越应该多Agent。真正适合Subagent的任务通常有三个特点。第一可以独立完成例如Agent A 分析前端登录流程 Agent B 分析后端认证逻辑 Agent C 检查相关测试三个任务即使并行执行也不会相互依赖。这类任务非常适合。第二结果可以明确汇总例如每个Agent最终统一返回Finding Evidence Files Risk Recommendation主Agent很容易比较。OpenAI给出的Subagent建议同样强调每个Subagent最好拥有bounded job clear return format也就是明确边界和明确返回格式。第三工作本身Read-heavy例如代码探索日志分析安全Review测试覆盖检查文档分析。官方也建议从这类Read-heavy任务开始使用并行Agent因为它们天然比多个Agent同时写代码更容易隔离。所以一个非常简单的判断是如果任务主要是“看、找、分析、比较”非常适合并行。如果任务主要是“同时修改同一批状态”就要谨慎。三、最稳定的结构不是“三个Agent一起写”而是 Explorer → Implementer → Verifier我认为开发任务里最值得复用的一种Subagent结构是Explorer ↓ Implementer ↓ Verifier三个角色职责完全不同。Explorer只负责找到真相Explorer负责读取代码搜索调用链查看日志建立Root Cause假设排除错误方向返回证据。它最重要的规则应该是不要修改代码。为什么因为探索阶段最大的问题就是Root Cause还没有确定。如果Agent一边探索一边修改就很容易发生猜测A ↓ 修改 ↓ 发现猜错 ↓ 继续修改 ↓ 产生更多状态最终“调查”和“实施”混在一起。一个更干净的Explorer输出应该类似Root Cause 请求超时来自paymentClient重复Retry。 Evidence payment/client.ts:84 retry.ts:31 相关日志显示同一request被重复发送3次。 Affected Scope payment client retry policy Recommended Fix 限制特定异常的Retry条件。 Uncertainty 尚未验证生产网关行为。Explorer只负责回答问题到底是什么而不是我顺便已经帮你改好了。四、Implementer不要重新调查整个项目第二个角色是Implementer。很多多Agent流程有一个常见浪费Explorer已经分析完了。Implementer启动以后又从头搜索Repository分析代码重新猜Root Cause。这实际上把前面的工作重复了一遍。所以主Agent交给Implementer的应该不是原始问题支付超时帮我修。而应该是已经压缩后的任务包Confirmed Root Cause paymentClient错误地Retry不可重试异常。 Evidence payment/client.ts:84 retry.ts:31 Allowed Scope payment/client.ts retry.ts 相关测试 Constraints 不要修改公共API。 不要升级依赖。 不要修改其他模块。 Done 相关测试通过。这就是Subagent真正有效的地方不同角色之间传递State而不是重复传递Question。于是Explorer 产生Knowledge ↓ Main Agent 确认 ↓ Implementer 消费Knowledge整个系统的信息流会干净很多。五、Verifier为什么最好不要顺手修代码第三个角色Verifier。它最容易被错误设计成测试一下如果有问题顺便修掉。听起来非常高效。但这会破坏角色边界。假设Implementer提交了一个修改。Verifier发现测试失败。然后自己修改代码。再次测试。最后告诉主Agent全部通过。问题来了最终代码到底是谁写的主Agent原本需要验证的是Implementation A现在实际验证的是Implementation A Verifier临时修改B证据链已经变化。所以更可靠的Verifier职责应该是读取Diff ↓ 运行测试 ↓ 检查行为 ↓ 寻找Regression ↓ 返回Evidence如果发现问题Fail ↓ 返回Implementer而不是Fail ↓ Verifier自己偷偷修这实际上类似软件工程里的Separation of Duties。实现和验收不是同一个角色。六、什么时候真正应该并行Explorer → Implementer → Verifier看起来是串行。那Subagent的并行价值体现在哪里最适合并行的是同一个阶段内部。例如复杂Bug的Explorer阶段Explorer A 分析代码调用链 Explorer B 分析日志 Explorer C 检查测试历史三者可以并行。完成以后主Agent汇总Evidence A Evidence B Evidence C ↓ Root Cause然后进入Implement。Code Review也很适合Agent A Security Agent B Test Gaps Agent C MaintainabilityOpenAI当前Subagent文档给出的直接示例就是让多个Agent分别审查安全风险、测试缺口和可维护性然后主Agent等待所有Agent完成再按照类别汇总结果。所以真正合理的原则是同阶段的独立分析可以并行。存在因果依赖的阶段应该串行。也就是Explore A ─┐ Explore B ─┼→ Root Cause Explore C ─┘ ↓ Implement ↓ Verify A ─┐ Verify B ─┼→ Final Evidence Verify C ─┘这比A改代码 B改代码 C也改代码稳定得多。七、多Agent最危险的是“共享可变状态”真正需要小心的不是多个Agent本身。而是多个Agent同时修改同一个State。例如Agent A 修改auth.ts Agent B 同时修改auth.ts这时候无论两个Agent多聪明都可能产生Merge Conflict基于旧代码修改覆盖彼此变化测试状态不一致。官方Subagent文档也明确提示多个Agent同时进行Write-heavy工作会增加冲突和协调开销推荐先从探索、测试、Triage和总结等并行读任务开始。所以多Agent写代码至少需要保证Different Scope或者Isolated Workspace例如Agent A frontend/ Agent B backend/如果确实需要同时修改同一个Repository更成熟的方式通常是结合独立Thread、Branch或Worktree进行状态隔离而不是让多个执行者抢同一个Workspace。Codex本身也把多Agent工作建立在独立线程和并行工作环境之上。八、Subagent Prompt真正重要的是“任务合同”给Subagent一句帮我看看这里有没有问题。几乎没有意义。一个稳定Subagent应该至少收到五项内容Role Task Scope Constraint Return Format例如ExplorerRole 你是只读代码探索Agent。 Task 定位登录接口偶发401的Root Cause。 Scope src/auth src/api 相关测试与日志。 Constraint 不要修改文件。 不要提出无关重构。 Return 1. Root Cause 2. Evidence 3. Related Files 4. Alternative Hypotheses 5. Uncertainty这已经形成了一份Agent Contract。OpenAI的建议同样强调好的Subagent指令应该说明工作如何拆分、主Agent是否需要等待全部结果以及最终应该返回什么摘要或格式。任务越清楚主Agent后续协调成本越低。九、自定义Subagent的价值是把“角色”固定下来如果团队经常重复使用同一类Agent可以进一步把角色配置固定。当前Codex支持Multi-agent配置和自定义角色声明可以为不同Agent角色设置描述、单独配置文件也可以设置默认Subagent模型、Reasoning Effort以及单Session并发线程限制。这意味着以后不必每次重新描述你是安全Reviewer。可以逐渐沉淀成security-reviewer test-reviewer explorer implementer verifier不同角色可以拥有不同InstructionsModelReasoningSandbox权限边界。这时候Subagent已经不再是临时多开一个Chat。而开始变成Agent Role System。十、不同角色甚至不需要使用完全相同的计算配置这也是多Agent很容易忽略的一点。Explorer做大量快速代码搜索与Architecture Reviewer做复杂判断对模型能力的需求并不相同。Codex当前允许为Subagent配置默认模型与Reasoning Effort也允许自定义不同Agent角色的配置官方建议不同Agent根据任务难度选择不同模型和推理设置。所以未来更合理的结构可能不是所有任务 ↓ 最强模型而是Fast Explorer ↓ 快速扫描Deep Reviewer ↓ 复杂判断Verifier ↓ 测试与证据这是Model Routing。当Agent数量真正增加以后这会直接影响速度成本吞吐量。十一、Subagents并不会天然节省Token还有一个非常现实的问题并行不等于更省。每个Subagent都需要单独完成模型推理工具调用上下文处理。所以官方明确提醒Subagent Workflow通常会比相同任务的单Agent执行消耗更多Token。这意味着不要为了看起来高级。把所有任务拆成5个Agent。如果一个任务只需要读取2个文件 改1行代码 跑1个测试一个Agent最快。真正值得拆分的是并行收益 协调成本 额外计算所以Subagent的核心指标不是Agent Count。而应该是Useful Parallelism。十二、什么情况下不应该用Subagents至少有四类。1. 非常小的任务例如修复一个明确的类型错误。一个Agent就够。2. 强串行依赖例如必须先知道A 才能判断B 再决定C强行并行只会让B和C基于猜测工作。3. 多个Agent必须修改同一文件如果没有状态隔离不建议。4. 主任务本身都没有定义清楚如果连Goal Scope Done都不清楚拆出5个Subagent只是把一个模糊任务复制5份。Agent数量不会自动创造清晰度。十三、一个更稳定的Codex Subagent任务模板例如需要处理登录偶发401。可以这样组织【Root Goal】 定位并修复登录偶发401。 【Phase 1Explore】 Spawn 3 read-only subagents Explorer A 分析auth代码调用链。 Explorer B 分析失败日志。 Explorer C 分析相关测试和历史Regression。 所有Explorer统一返回 - Finding - Evidence - File / Log Reference - Confidence - Uncertainty 等待全部完成。 【Main Agent】 比较三个结果 确认Root Cause。 【Phase 2Implement】 Spawn / assign Implementer 仅按照已确认Root Cause修改。 禁止 无关重构 依赖升级 扩大模块范围。 【Phase 3Verify】 Verifier A 运行相关测试。 Verifier B Review Diff与Regression风险。 Verifier不要修改代码。 【Final】 Main Agent汇总 Root Cause Changes Test Evidence Review Evidence Remaining Risk这种工作流最重要的不是用了多少Agent。而是每个Agent都知道自己只负责哪一段。十四、Skills、MCP和Subagents到这里才真正连起来今天三篇文章其实可以组成一套完整结构。第一篇Skills解决重复流程怎么沉淀第二篇MCP解决Agent怎么获得外部工具第三篇Subagents解决复杂任务怎么委派给不同执行单元OpenAI目前对Codex定制体系本身也是把AGENTS.md、Skills、MCP和Subagents视为互补能力项目规则负责长期行为Skills负责可复用流程MCP负责外部系统能力而Subagents负责把工作委派给专门Agent。于是一个真正成熟的任务可以变成AGENTS.md ↓ 定义项目规则 Skill ↓ 定义Bug排查流程 MCP ↓ 读取日志 / Issue / 文档 Subagents ↓ Explorer / Implementer / Verifier Main Agent ↓ 汇总和决策 Verification ↓ 证明完成这已经不是AI帮我写代码。而是在逐渐形成Agent Engineering System。十五、真正值得追求的不是“多Agent”而是“角色清晰”多Agent最容易让人陷入一个数量思维1个不够就3个。3个不够就10个。但真正成熟以后判断系统好坏的问题应该变成谁负责探索谁负责决策谁负责修改谁负责验证哪些事情可以并行哪些状态必须隔离最后谁对Done负责如果这些问题没有答案10 Agents可能只是10个同时产生信息的人而不是一个团队。只有角色、边界、信息流和完成标准都明确以后Explorer Implementer Verifier Main Agent才真正开始形成Agent Team。最后Subagents真正能够提效的条件从来不是能不能同时启动更多Agent。而是任务能否独立拆分 Agent角色是否清楚 写操作是否隔离 返回格式是否统一 主Agent能否汇总决策 最终结果有没有验证所以最值得先尝试的并不是三个Agent一起修改代码。而是多个Explorer并行找证据 ↓ Main Agent确认Root Cause ↓ 一个Implementer负责修改 ↓ 多个Verifier独立验证这种结构既利用了并行能力又避免了多个Agent争夺同一个可变状态。从这个角度看Subagents真正代表的并不是“一个Codex变成很多Codex”。而是Agent工作方式开始从Single Intelligence进入Division of Labor。当探索、实现、验证不再全部塞给同一个Agent以后真正需要设计的就不只是Prompt。而是Agent之间应该怎样分工、怎样传递状态以及怎样形成一条可信的完成链。这才是Subagents真正进入工程工作流之后最值得掌握的能力。
