我读完这篇 Codex Subagent 指南的第一反应是：OpenAI 终于把"多代理架构"从概念做成了基础设施。
之前的 multi-agent 讨论大多是学术性的——AutoGPT、MetaGPT、CAMEL，论文很精彩，落地很骨感。Codex Subagent 不一样，它是你敲一行命令就能用的东西。
第一，关于"什么时候别开"
这部分特别重要。很多开发者拿到新工具的第一反应是"哪里都试试"，结果 token 账单爆炸。官方文档明确说"subagent workflows consume more tokens"，这不是免责声明，是成本警告。
我同意文章里的决策树：简单任务别开，快速迭代别开，敏感代码别开。Subagent 的 overhead 是 5-50K tokens 起步（codex-subagent-skill 文档的数据），一个小修复不值得。
但并行审查这个场景，开就是对的。时间从 9 分钟降到 3 分钟，质量因为上下文隔离反而更高。这是 positive ROI。
第二，关于模型分级（Tiered Inference）
GPT-5.4-mini 做探索，GPT-5.4 做判断，这个架构的 cost 差是 3.3 倍。但我要补充一个经常被忽略的点：mini 模型不仅便宜，还更快。在并行审查场景里，qa-coverage-agent 和 architecture-agent 用 mini，runtime-risk-agent 用 full，总时间由最慢的 full 代理决定（约 3-4 分钟），而不是三个 full 代理串行的 9-12 分钟。
所以分级不仅省钱，还缩短了关键路径。
第三，关于 ShipReady 案例的深层含义
这个虚构但典型的案例展示了一个完整的工作流： 1. 专业化分工：每个代理有专门的 developer_instructions，不是泛泛的"请审查代码" 2. 并行执行：三个维度同时跑，时间重叠 3. 结构化输出：每个代理返回带 severity 的发现，便于主代理排序 4. 汇总策略：去重 → 排序 → 分类 → 分配 5. 落地闭环：worker 代理修复 → 测试验证 → 回归审查
这不是"三个代理各自输出三段文字"，这是一个工程化的审查流水线。从发现问题到分配修复到验证关闭，全部自动化。
第四，关于 CollabAgent 协议的工程细节
Codex 的子代理不是简单的"新开进程"，它有完整的生命周期管理：spawn → sendInput → resume → wait → close。agentsStates 映射让 UI 能实时显示"Atlas 完成 2/3 任务"。
这比 Claude Code 的 TaskList 更结构化。Claude 的 Subagent 更像"启动一个后台任务，等它完成"，Codex 的更像"管理一个分布式作业队列"。
第五，关于 CSV 批处理
spawn_agents_on_csv 是这篇文章没展开但我特别想提的实验性功能。想象一下：你有 50 个微服务，每个需要安全审查。写一个 CSV（path, owner, criticality），一行一个任务，Codex 自动 fan-out 到最多 6 个并行代理，完成后导出结果 CSV。
这不是"代码审查"，这是代码审计流水线。对于大型组织，这个能力的价值远超单个 PR 审查。
最后，关于"Subagent 是不是未来"
我的判断：不是"未来"，是"现在"。但有一个前提——你需要配置。TOML 文件里的 developer_instructions 决定了子代理的质量。如果你的 instructions 是"请审查代码"，子代理输出也是泛泛的。如果你的 instructions 是"审计竞态条件，重点关注 sync.Mutex 的 Unlock 路径"，输出就是专业的。
Subagent 放大了 prompt engineering 的重要性。一个精心配置的子代理比三个敷衍的子代理有用得多。
值得跟踪，值得实践，值得在你的下一个 PR 审查里试试。