交流群即将上线
03 · 子智能体与并行
它真正解决的问题
大多数人第一反应是「并行 = 快」。速度只是副作用，主要作用是保护主线程的上下文。
一个长任务里，真正要紧的是需求、约束和决策。但探索记录、测试日志、 堆栈跟踪、命令输出这些中间产物会不断挤进来，把要紧的东西压到边缘。 官方给了两个词：上下文污染（有用信息被杂乱输出淹没）和 上下文腐化（聊天被低相关细节填满，性能逐渐下降）。
子智能体的做法是：脏活外包出去，只把摘要带回来。
- 主智能体：守住需求、决策、最终输出。
- 子智能体：并行去探索、跑测试、翻日志。
- 回来的是结论，不是原始输出。
顺带才是提速——工作能独立并行时，大任务拆成范围明确的小块，确实更快也更好管。
什么时候用，什么时候别用
适合：探索、测试、问题分流、总结——这些以读为主的任务。 比如一份几百万 Token 的文档，拆成若干小问题分头看，各自提炼要点回来。
要小心：以写为主的并行。多个智能体同时改代码会冲突，协调开销也上来了。 官方的建议是先从只读任务开始。
代价：每个子智能体独立使用模型和工具，所以子智能体工作流比同等的单智能体运行更费 Token。
怎么触发
大多数智能级别下要明确要求。ChatGPT Work 的 Ultra 级别可以在并行明显有帮助时主动委派， 其余情况得你开口。本地 Codex 在你直接要求、或适用的 AGENTS.md / 技能指令要求委派时才委派。
一条好的委派提示要说三件事：怎么分工、要不要等全部完成、返回什么。
text
Review this branch with parallel subagents. Spawn one subagent for security risks,
one for test gaps, and one for maintainability. Wait for all three, then summarize
the findings by category with file references.再具体一点的版本：
text
我要审当前 PR（本分支 vs main）的以下几点。每点开一个智能体，等全部跑完，逐点汇总结果。
1. 安全问题
2. 代码质量
3. Bug
4. 竞态
5. 测试不稳定
6. 可维护性多个智能体同时跑时，Codex 会等所有请求的结果就绪，再返回汇总响应。
跑起来之后怎么管
CLI：用 /agent 切换正在运行的智能体线程、看当前有哪些在跑。 想调方向、停掉某个、关掉已完成的线程，直接跟 Codex 说。
桌面应用：从主线程里的活动打开子智能体线程查看它的工作。
IDE 扩展：后台智能体面板可用时展开，能看状态、停止运行中的子智能体、打开线程。
网页侧边栏只显示活动，没有停止或调整方向的控件。
沙盒和审批怎么继承
子智能体继承你当前的沙盒策略。 这句话要记牢—— 你在会话里用 /permissions 改过的设置、甚至 --yolo， 在启动子智能体时会被重新应用，即使自定义智能体文件里设了不同的默认值。
也就是说：想让子智能体更受限，别指望在它的配置文件里写 sandbox_mode = "read-only" 就能兜住一个 --yolo 的父会话。先把父级轮次的权限模式选对，再要求委派。
审批上有两个细节值得知道：
- 交互式 CLI 里，即使你正在看主线程，非活动线程也可能弹审批。 浮层会标出是哪个线程发的，按
o打开那个线程再批准、拒绝或答复。 - 非交互式流程里（或者界面没法显示新审批时），需要新审批的操作会直接失败， Codex 把错误反馈给父级工作流。所以
codex exec里跑子智能体，权限得提前配好。
挑模型
不配的话，子智能体继承父级的模型和推理强度。想按任务分配：
| 场景 | 建议 |
|---|---|
| 承担复杂任务的智能体 | gpt-5.6，最擅长目标不明确、步骤多、需要规划和验证的活 |
| 速度优先的探索、只读扫描、大文件审查 | gpt-5.6-terra，适合并行跑、返回提炼结果 |
| 快速、范围窄、可重复或大批量的活 | gpt-5.6-luna |
自定义智能体
Codex 内置三个：
default：通用后备worker：侧重执行，用于实现和修复explorer：以读取为主的代码库探索
自己定义的话，写独立的 TOML 文件：个人的放 ~/.codex/agents/， 项目级的放 .codex/agents/。每个文件定义一个智能体，必须有 name、description、 developer_instructions 三个字段：
toml
# .codex/agents/pr-explorer.toml
name = "pr_explorer"
description = "Read-only codebase explorer for gathering evidence before changes are proposed."
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
Stay in exploration mode.
Trace the real execution path, cite files and symbols, and avoid proposing fixes unless the parent agent asks for them.
Prefer fast search and targeted file reads over broad scans.
"""Codex 靠 name 字段识别智能体，文件名跟它一致最省事，但以 name 为准。 文件里还能写别的 config.toml 键——sandbox_mode、mcp_servers、skills.config 都行； 没写的从父级继承。
这个格式还会变
官方自己说了：「相比专用的智能体清单，这种方式可能显得更繁琐； 随着编写和共享方式逐渐成熟，这种格式也可能发生变化。」 别在上面盖太重的自动化。
好的自定义智能体职责专一：一项清晰职责、匹配的工具、 以及防止它跑偏去干别的相关工作的指令。
全局设置
toml
[agents]
enabled = true
max_concurrent_threads_per_session = 8
default_subagent_model = "gpt-5.6-terra"
default_subagent_reasoning_effort = "medium"| 字段 | 作用 |
|---|---|
agents.enabled | 开关多智能体工具 |
agents.max_concurrent_threads_per_session | 同时打开的智能体线程上限（不含主线程） |
agents.default_subagent_model | 启动的智能体默认用哪个模型 |
agents.default_subagent_reasoning_effort | 默认推理强度 |
agents.interrupt_message | 智能体轮次被中断时，记一条模型可见的消息 |
max_concurrent_threads_per_session 是最值得先设的一个—— 不设的话一句「并行处理」可能一口气开出十几个线程，Token 消耗很难预估。