一个大任务卡住时，“再开几个子代理”听起来很合理。可如果四个 Agent 同时改同一份配置、依赖同一个尚未确定的接口，结果通常不是四倍速度，而是四份互相矛盾的答案。
Codex Subagents 真正擅长的，是边界清楚、能独立完成、最后容易验收的工作。官方文档也提醒，多代理会比可比的单代理任务消耗更多 token。它是一种用更多计算换并行时间的方式，不是免费的加速按钮。
先问：这个任务真的能并行吗
适合拆开的任务通常具备三个条件：输入已经确定；执行期间不依赖另一个任务的中间结论；交付物能单独验收。
比如一个 Agent 查官方文档，一个跑只读测试，一个检查测试覆盖，主 Agent 同时整理实现方案。它们可以共享目标，但不争抢同一个文件。
不适合的情况也很明显：先要决定数据结构，后面三个模块才能写；所有人都要修改同一个配置；任务彼此反复引用，任何一处变化都会推翻其他结果。这样的链路应该串行推进。
给子代理一份交付契约
“帮我研究一下”几乎等于没有边界。更好的任务描述要写明：只处理什么、不处理什么；允许读取和修改哪些路径；必须返回哪些证据；遇到什么情况停止；最终由谁合并。
如果允许修改文件，还要分配所有权。一个文件只给一个写入者，其他 Agent 只读。共享工作区里，这条规则比“大家小心一点”可靠得多。
[真实截图待补：Codex 的 agent 列表、两个独立子任务的状态、各自交付结果及主 Agent 验收记录]
并发数量要由瓶颈决定
任务被网络、付费 API 或同一测试环境限制时，多开 Agent 只会一起排队。仓库很大、工具输出多时，并发还会放大上下文和日志噪声。
可以从两个子任务开始。确认它们没有抢文件、没有重复查同一来源、输出格式一致，再增加并发。官方当前版本在 App、CLI 和 IDE 中默认启用 Subagents，CLI 可用 /agent 检查和切换；本机 codex-cli 0.147.0 的 features 也显示 multi_agent 为 stable/enabled。但这只证明入口存在，不等于你的任务已经拆对。
主代理不能只做转发
子代理交回来的不是天然正确的拼图。主 Agent 要核对来源、解决冲突、运行整体测试，还要判断有没有遗漏跨模块影响。
我更愿意把交付分成三类：事实发现附来源；代码变化附测试；未完成项明确写 blocker。这样主 Agent 能判断下一步，不需要从一段“已经处理好了”的总结里猜现场。
AI Code With 出现在资源管理，不是任务编排
多代理同时调用模型时，API Key、渠道和用量更容易散在不同环境。AI Code With 已核实的控制台能力包括 API Key/渠道管理、统一余额和使用记录。它可以减少每个子任务各管一套凭证、事后到处查用量的操作。
但它不会自动拆任务，也不会降低多代理天然增加的 token，更不能解决同文件写冲突。把作用说到这里，已经够具体。
验收标准比代理数量重要
一次健康的并行任务，应该能回答：节省了哪段等待；有没有重复工作；有没有冲突；总成本是否可接受；主 Agent 用什么证据完成合并。
本稿没有执行多代理实验，保留 TEST_REQUIRED。发布前应补一个真实案例，对比单代理与两个独立子任务的耗时、token 和冲突情况。没有这组证据，就别写“效率提升几倍”。
Subagents 的核心不是把一个人变成一支队伍。是让每个并行分支都知道自己该做什么，也知道什么时候必须停下来交给主线。
