在用户使用Codex 的 Codex CLI 终端工具和 Codex App 里，“多智能体”对用户不是一组需要专门学习的命令，而是三样东西：
- 你说话的方式（显式要求并行/委派）；
- 仓库里预置的指令（AGENTS.md、skills）；
- 客户端里为“管理多个智能体”专门设计的界面（CLI 的 /agent、App 的多线程 + worktree）。 当前版本默认开启 subagent 工作流，也就是说：你正常提一个需求，背后可能已经跑着多个智能体。
一、对Codex多智能体的初步理解
Codex 里和你对话的界面叫主线程（main thread） 。当 Codex 判断一件事适合并行时，会派生出子智能体（subagent） ——每条子智能体是独立线程，有自己的上下文窗口，子智能体干完活后只把摘要回传主线程。所以你感知到的“多智能体”= 一个主线程 + 若干条可检视的子线程。
这么设计的动机很直接：如果主线程里堆满探索笔记、测试日志、堆栈跟踪等中间处理过程数据，上下文会被污染（context pollution）、性能会退化（context rot）。用子智能体把噪音工作挪出主线程，只返回结论。这个动机是理解整套机制的钥匙。
下图是两个客户端里用户能直接触碰到的多智能体触点，以及它们共用的底座：
二、触点明细：哪些功能“直接”用上了多智能体
Codex CLI（终端）
| 使用入口 | 你的操作 | 多智能体角色 |
|---|---|---|
| 交互会话 | 直接说“spawn 两个 agent”“并行审查这个 PR” | 触发派生，最直接的入口 |
| /agent | 运行中查看、切换智能体线程 | 多线程管理界面 |
| ~/.codex/config.toml | [agents] 定义角色、max_threads、max_depth | 角色供给层（默认最多 6 线程、深度 1） |
| AGENTS.md / skills | 仓库里预置“要求委派”的指令 | 隐式触发，执行任务时自动生效 |
| codex exec / GitHub Actions | PR 评论 /codex … 无头执行 | 同一套编排的无人值守形态 |
| spawn_agents_on_csv | 按 CSV 行批量派发任务（实验性） | 结构化扇出 |
Codex App（桌面客户端，2026 年 3 月起覆盖 Windows）
| 使用入口 | 你的操作 | 多智能体角色 |
|---|---|---|
| 多线程工作区 | 按项目组织多条智能体线程，并行推进 | 最核心的多智能体界面 |
| worktree | 每个智能体在隔离代码副本上工作 | 并行写不冲突的基础 |
| diff 审阅 | 线程内看改动、写评论、打开编辑器手改 | 监督多智能体的产出 |
| skills 面板 | 创建/管理技能；显式指定或让 Codex 自动选用 | 技能说明里可内含委派指令 |
| 子智能体活动可见性 | App 与 IDE 展示各 subagent 状态，可停止、可打开单条线程 | 观测层 |
一个极端案例值得记住：官方发布 App 时只用一个初始 prompt 让 Codex 做赛车游戏，背后跑了 700 多万 token，Codex 自主承担了设计师、开发者、QA 测试员多重角色，并组合使用图像生成和网页游戏开发两个技能。用户视角的启示是：你说了一句话，不代表背后只有一个智能体在工作。
三、哪些“用户信息”会触发多智能体执行
触发不靠神秘命令，核心就是四类输入，全部汇入主线程智能体做判断：
对照上图，四类触发的具体形态：
- 显式自然语言指令——最直接的触发。句式关键词是 spawn / delegate / parallel / "one agent per…"。一条合格的触发句包含三要素：怎么分工、是否等全部完成、要什么格式的汇总。官方示例：“Review this branch with parallel subagents. Spawn one for security risks, one for test gaps, one for maintainability. Wait for all three, then summarize by category with file references.”
- 仓库预置指令——AGENTS.md 或某个 skill 的说明里写了委派要求，Codex 执行任务时会自动遵循。用户往往意识不到这一刻正在跑多智能体。
- 任务形状 + 模型自主判断——任务天然可并行的独立子任务（读密集型：探索、测试、triage、摘要）时，Codex 自行决定派生；ChatGPT Ultra 档位可以在用户没要求时主动委派，其余档位需要显式要求。
- 云端/CI 入口——ChatGPT Work 中委托独立工作（在托管环境运行，聊天里展示各智能体活动与结果）；GitHub Actions 中通过 /codex 评论无人值守触发。
四、用户能观察和控制的部分
- /agent 查看/切换线程；App 与 IDE 里每条 subagent 线程可打开检视（IDE 中活跃子智能体显示在输入框上方，可展开看状态、一键停止、单开线程）
- 审批：非活跃线程的批准请求带来源标签，按
o先检视线程再批准；运行时的 /approvals 变更会传播到子智能体 - 可直接命令 Codex 停止或关闭某个子智能体；monitor 角色专用于长时等待（轮询窗口最长 1 小时）
- 成本与风险：token 消耗随子智能体数量线性增长；官方建议并行用于读密集型任务，并行写有冲突风险，靠 worktree 隔离兜底
五、这份使用印象如何接上实现机制
带着上面的现象去读后续更详细的多智能体实现机制分析的文章，每个疑问都有了落点：
- “谁决定派生？” —— 派生决策是模型在推理中做出的（模型决策），CLI 只负责执行派生、路由、等待、合并（程序执行）。读报告时请守住这个区分。
- “谁在执行编排？” —— 两层：客户端编排（CLI 本地起线程、[agents] 角色配置、worktree 隔离）与服务端编排（2026 年 7 月随 GPT-5.6 推出的 Responses API Multi-Agent Beta：模型在服务端发出 spawn_agent / followup_task / send_message / wait / close_agent，CLI 只收到合成后的单一回复）。
- “上下文怎么隔离？” —— 每个 subagent 子Agent采用独立的 context window，只把最终结果传回传主线程。这既是 context 污染的解决办法，也能解决无用的上下文过多导致的Token花费大的问题。
- “结果怎么汇总？” —— 主智能体在全部子智能体完成后进行合并。
- “界面为什么长这样？” —— App 的多线程 + worktree + diff 评论，本质是把“监督多个并行智能体”做成一等公民，这正是 OpenAI 说“现有 IDE 和终端工具不是为这种工作方式设计的”所指。
一句话总结使用侧印象：用户只跟主线程说话；多智能体对你表现为三种东西——你说的并行指令、仓库里预置的委派规则、以及客户端里专门管理多线程的界面。 有了这个印象，后续文章里“谁来派生、谁来执行、上下文怎么隔离、结果怎么汇总”四个问题就不再抽象了。
