交流群即將上線
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 消耗很難預估。