上周帮老大调一个前端 bug，症状是"设置弹窗保存按钮点了没反应"。我花了半小时：先在浏览器开发者工具里复现问题，然后翻代码找事件绑定逻辑，最后发现是一个状态更新时机的问题。
今天看到 OpenAI Codex 的 Subagents 功能正式开放，文档里有个示例 prompt 让我愣了一下：
"Investigate why the settings modal fails to save. Have browser_debugger reproduce it, code_mapper trace the responsible code path, and ui_fixer implement the smallest fix once the failure mode is clear."
一句话，三个专项 Agent 自动协作。 浏览器调试员负责复现、代码追踪器负责定位、UI 修复工负责改代码。我上周手动做的事，现在可以丢给三个 Agent 并行处理。
这不是概念演示。Subagents 今天从预览版转正式 GA，Claude Code、Cursor、Gemini CLI 都已经支持类似机制。多 Agent 并行工作从"实验室功能"变成了"标配"。
Subagents 解决了什么问题？
之前用 Coding Agent 最痛苦的是什么？你得把任务拆得很细，然后一个个喂给它。
比如刚才那个弹窗保存的 bug。你不能直接说"帮我修一下设置弹窗保存失败的问题"——Agent 会懵，因为它不知道从哪下手。你得先让它在浏览器里复现问题，看报错信息；然后让它去代码里找对应的事件处理函数；最后才能让它改代码。三轮对话，每轮等它跑完再继续。
Subagents 的逻辑是：你说目标，它自己决定要调几个专项 Agent、按什么顺序调、什么时候并行。
OpenAI Codex 默认提供三个 Subagent：
| Subagent | 职责 | 适合场景 |
|---|---|---|
| explorer | 探索代码库结构、理解项目架构 | 不熟悉的代码库、需要全局视角的任务 |
| worker | 执行大量小任务，支持并行 | 批量重构、多文件修改、数据处理 |
| default | 通用任务处理 | 单一功能实现、简单 bug 修复 |
文档里没明说 worker 和 default 的区别，但从 CSV 处理的示例来看，worker 是为"跑 100 个小任务"这种场景设计的——它会自动并行执行，而 default 是串行的。
更关键的是，你可以自己定义 Subagent。
自定义 Subagent：给 Agent 配专项技能
Codex 允许你在 ~/.codex/agents/ 目录下创建 TOML 配置文件，定义自己的专项 Agent。每个 Agent 可以有：
- 自定义指令（告诉它专注做什么、怎么做）
- 指定模型（比如用
gpt-5.3-codex-spark追求速度，或用gpt-5.4处理复杂推理） - 工具权限（限制它只能用特定工具，避免乱跑命令）
举个例子，你可以定义一个 browser_debugger Agent，专门负责在浏览器里复现 bug 和抓错误日志：
toml[agent]
name = "browser_debugger"
model = "gpt-5.3-codex-spark"
instructions = """
你是浏览器调试专家。当用户描述一个前端 bug 时：
1. 在浏览器开发者工具中复现问题
2. 记录控制台错误、网络请求失败、DOM 状态异常
3. 截图或录屏关键步骤
4. 输出一份结构化的 bug 报告，包含复现路径和错误信息
不要尝试修改代码，只负责定位问题。
"""
tools = ["browser", "screenshot"]
然后在主 prompt 里直接 @ 它：
"设置弹窗保存失败，@browser_debugger 先复现一下，@code_mapper 找到对应代码，@ui_fixer 改最小改动量的修复。"
三个 Agent 会按依赖关系自动协作：browser_debugger 跑完输出 bug 报告 → code_mapper 根据报告定位代码 → ui_fixer 拿到代码位置后实施修复。你不需要手动传递上下文，Codex 会自动把前一个 Agent 的输出喂给下一个。
Subagents 现在是标配了
Subagents 不是 OpenAI 独有的。过去两个月，主流 Coding Agent 平台都上线了类似功能：
Claude Code — 有 explorer、worker、default 三个默认 Subagent，和 Codex 几乎一样。可以在 .claude/agents/ 目录下定义自定义 Agent。
Cursor — 支持 Subagents，但文档里没明确说默认有哪几个。从社区反馈看，Cursor 的 Subagent 更偏向"按文件类型分工"（前端 Agent、后端 Agent、测试 Agent）。
Gemini CLI — 实验性支持 Subagents，需要在配置里手动开启。Google 的实现更激进，允许 Subagent 调用外部 API 和云服务。
OpenCode — 开源方案，Subagent 机制完全自定义。你可以写 Python 脚本定义 Agent 的行为逻辑，不受平台限制。
VS Code Copilot 和 Mistral Vibe 也都有文档提到 Subagents，但我还没实际用过。
这个趋势很明显：单一 Agent 处理所有任务的时代结束了。 现在的 Coding Agent 更像一个"项目经理"，它会根据任务类型调度不同的专项 Agent，而不是自己从头干到尾。
什么时候该用 Subagents？
不是所有任务都需要 Subagents。如果你只是让 Agent 写一个函数、改一行代码，直接用默认 Agent 就行。Subagents 的价值在于复杂任务的自动拆解和并行执行。
适合用 Subagents 的场景：
跨多个文件的 bug 修复 — 比如一个功能涉及前端组件、后端 API、数据库查询三层。你可以让 explorer 先梳理调用链，worker 并行修改三个文件，最后让 default 跑测试验证。
大规模重构 — 比如把项目里所有 var 改成 const、统一代码风格、批量重命名函数。worker 可以并行处理几十个文件，比单 Agent 串行快很多。
不熟悉的代码库 — 接手别人的项目，不知道从哪看起。让 explorer 先生成一份架构文档，标注核心模块和依赖关系，然后再开始改代码。
需要多工具协作的任务 — 比如"优化这个页面的加载速度"。需要浏览器性能分析工具、代码静态分析、打包工具配置调整。不同 Subagent 各自负责一个工具，最后汇总结果。
不适合用 Subagents 的场景：
- 简单的单文件修改（调一个 Subagent 的开销比直接改还大）
- 需要频繁人工介入的任务（Subagents 之间的协作是自动的，你插不进去）
- 对成本敏感的场景（多 Agent 并行意味着多倍 token 消耗）
怎么开始用？
如果你已经在用 OpenAI Codex 或 Claude Code，Subagents 功能今天就能用，不需要额外配置。
第一步：试试默认 Subagent
直接在 prompt 里描述任务，让 Codex 自己决定要不要调 Subagent。比如：
"这个项目的登录流程是怎么实现的？帮我梳理一下从前端表单提交到后端验证的完整链路。"
Codex 会自动调用 explorer 去扫描代码库，找到相关文件，然后生成一份调用链路图。
第二步：手动指定 Subagent
如果你知道任务适合哪个 Subagent，可以直接 @ 它：
"@worker 把 src/ 目录下所有 .js 文件的 var 改成 const，保持代码逻辑不变。"
worker 会并行处理所有文件，比让默认 Agent 一个个改快得多。
第三步：定义自己的 Subagent
在 ~/.codex/agents/ 目录下创建一个 TOML 文件，比如 api_tester.toml：
toml[agent]
name = "api_tester"
model = "gpt-5.3-codex-spark"
instructions = """
你是 API 测试专家。当用户要求测试一个接口时：
1. 读取接口文档或代码注释，理解参数和返回值
2. 构造多组测试用例（正常情况、边界情况、异常情况）
3. 用 curl 或 Postman 发送请求，记录响应
4. 输出测试报告，标注通过/失败的用例
不要修改接口代码，只负责测试。
"""
tools = ["curl", "http_client"]
然后在 prompt 里调用：
"@api_tester 测试一下 /api/users/login 接口，看看参数校验和错误处理是否正常。"
一个实际案例
前两天有个读者在 Discord 里问："我接手了一个 React 项目，代码写得很乱,想重构但不知道从哪下手。"
我让他试试这个 prompt：
"@explorer 扫描整个项目，生成一份架构文档，标注：1) 核心组件和它们的依赖关系；2) 重复代码最多的地方；3) 最复杂的函数（超过 50 行或嵌套层级超过 3 层）。然后 @worker 把重复代码提取成公共函数，@default 把复杂函数拆成小函数。"
他跑完之后发了个截图过来。explorer 生成的架构文档里标出了 7 个重复的表单验证逻辑、3 个超过 100 行的组件、还有一个被 15 个文件依赖的工具函数。worker 自动提取了公共逻辑，default 把那 3 个大组件拆成了更小的子组件。
整个过程他只输入了一次 prompt，剩下的都是 Subagents 自己协作完成的。他说"感觉像是雇了三个实习生帮我干活"。
话说回来，Subagents 也不是万能的。它解决的是"任务拆解和并行执行"的问题，但什么任务值得拆、怎么拆、拆成几个步骤——这些判断还是得你自己做。
如果你的 prompt 本身就很模糊（比如"帮我优化一下这个项目"），Subagents 也不知道该调哪几个 Agent。它需要的是清晰的目标和可拆解的步骤。
还有一个事：多 Agent 并行意味着多倍 token 消耗。如果你在用按 token 计费的服务，成本会比单 Agent 高不少。OpenAI 和 Anthropic 都没有针对 Subagents 推出优惠定价，所以在用之前最好算一下成本。
但如果任务本身就需要多轮对话、多次工具调用，Subagents 的并行执行反而能省时间——时间成本和 token 成本之间，你得自己权衡。