子智能體

ChatGPT Work 和 Codex 可以並行啟動多個專用智能體，再把結果彙總到一份回覆中。這種方式尤其適合並行度高的複雜任務，例如程式碼庫探索或多步驟功能實現。

在本機 Codex 客戶端中，你還可以按任務類型定義自定義智能體，併為它們設定不同的模型設定和開發者指令。

可用性

Web 端 ChatGPT Work

符合條件的賬號可以在 ChatGPT Work 中使用子智能體工作流程並檢視相關活動。

本機 Codex 客戶端

當前 Codex 版本預設啟用子智能體工作流程。ChatGPT 桌面 App、Codex CLI 和 IDE 擴充套件都會顯示子智能體活動。

由於每個子智能體都會獨立進行模型呼叫和工具呼叫，子智能體工作流程會比同類單智能體任務消耗更多 token。

Web 端 ChatGPT Work

在 ChatGPT Work 中，可以要求 ChatGPT 把互不依賴的工作委派給子智能體。子智能體在 ChatGPT 託管的環境中執行，聊天會顯示它們的活動與結果。在大多數智慧水平下，需要明確提出委派要求；使用 Ultra 時，如果並行智能體能顯著提升速度或質量，ChatGPT 可以主動委派工作。

ChatGPT 桌面 App

你可以在 App 聊天中直接要求 Codex 把互不依賴的工作委派給子智能體。當前本機 Codex 版本會在你明確提出要求，或適用的 AGENTS.md、skill 指令要求委派時啟動子智能體。App 會展示每個子智能體對話執行緒，方便你檢查其工作以及返回主聊天的摘要。

Codex CLI

在互動式 CLI 會話中，可以要求 Codex 使用子智能體；適用的 AGENTS.md 或 skill 指令也可以要求委派。子智能體執行期間，使用 /agent 檢查不同智能體對話執行緒並在它們之間切換。主對話執行緒會把子智能體結果彙總到最終回覆中。

IDE 擴充套件

在 IDE 聊天中，可以要求 Codex 把互不依賴的工作委派給子智能體；適用的 AGENTS.md 或 skill 指令也可以要求委派。當 background-agent panel（後臺智能體面板）可用時，活躍的子智能體會顯示在輸入框上方。展開面板後，可以檢視狀態、停止所有活躍子智能體，或開啟某個子智能體對話執行緒。

子智能體工作流程為何有幫助

即使上下文視窗很大，模型仍然有極限。如果把探索筆記、測試日誌、堆疊追蹤和命令輸出等帶噪中間結果全部放進正在定義需求、約束與決策的主聊天，會話會逐漸變得不可靠。

這通常稱為：

• 上下文汙染（Context pollution）： 有用資訊被帶噪的中間輸出淹沒。
• 上下文腐化（Context rot）： 隨著對話充滿低相關細節，整體表現下降。

背景資料可參閱 Chroma 關於 context rot 的文章。

子智能體工作流程把帶噪工作移出主對話執行緒：

• 讓主智能體聚焦需求、決策與最終輸出。
• 讓專用子智能體並行處理探索、測試或日誌分析。
• 讓子智能體返回摘要，而不是原始中間輸出。

當工作可以獨立並行時，這種方式還能縮短時間，並把大任務拆成邊界清晰的小塊。例如，Codex 可以把數百萬 token 的文件分析拆成多個較小問題，再把提煉結果交還主對話執行緒。

建議先把並行智能體用於探索、測試、分診和總結等讀操作較重的任務。並行寫操作更容易產生程式碼衝突和協調開銷，應謹慎使用。

核心術語

• 子智能體工作流程： Codex 執行並行智能體並彙總結果的工作流程。
• 子智能體： Codex 為特定任務啟動的委派智能體。
• 智能體對話執行緒（Agent thread）： 子智能體執行工作的對話執行緒；受支援的客戶端允許你開啟它檢視進度和結果。

觸發子智能體工作流程

Web 端 ChatGPT Work

在大多數智慧水平下，需要直接要求使用子智能體或並行智能體。Ultra 支援主動委派，因此當獨立並行工作適合當前任務時，ChatGPT 無需額外請求也可以啟動子智能體。

本機 Codex 客戶端

可以直接要求 Codex 使用子智能體或並行智能體。適用的專案指令或 skill 指令也可以要求委派。

手動觸發時，應使用明確指令，例如 “spawn two agents,” “delegate this work in parallel,” 或 “use one agent per point.” 好的提示詞要說明如何拆分工作、是否等待全部智能體完成，以及最終需要返回什麼摘要或產物。

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.

選擇模型與推理強度

不同智能體適合不同的模型和推理設定。

Web 端 ChatGPT Work

在 ChatGPT Work 中，可以從輸入框選擇模型和智慧水平（intelligence level）。根據所選模型，可用級別包括 Light、Medium、High、Extra High 和 Max。只有符合條件的賬號和受支援的模型可以使用 Ultra；它會採用最高推理強度，並允許 ChatGPT 主動把適合的工作委派給子智能體。

使用其他智慧水平時，如果希望並行委派工作，應明確要求使用子智能體。

本機 Codex 客戶端

如果沒有固定 model 或 model_reasoning_effort，Codex 會選擇兼顧能力、速度與價格的設定。快速掃描可能使用 gpt-5.6-terra，複雜推理則可能使用更高推理強度的 gpt-5.6。需要精細控制時，可在提示詞中引導選擇，或在智能體檔案中直接設定這兩個欄位。

模型選擇

• gpt-5.6： 適合含糊、多步驟、需要規劃、工具呼叫、驗證與跨大上下文持續推進的高要求任務。
• gpt-5.6-terra： 適合更看重速度和效率的探索、讀操作密集型掃描、大檔案審查與輔助材料處理。
• gpt-5.6-luna： 適合範圍清晰、可重複或高吞吐的快速窄範圍任務。

推理強度（model_reasoning_effort）

• ultra： 所選模型支援時，用於最深層推理。
• max、xhigh： 所選模型支援時，用於特別困難的推理任務。
• high： 用於追蹤複雜邏輯、檢查假設或處理邊界情況，例如 reviewer 或安全智能體。
• medium： 大多數智能體的平衡預設值。
• low： 適合任務直接且速度優先的場景。

更高推理強度會增加響應時間和 token 用量，但可能提升複雜任務質量。詳情見模型、設定基礎和設定參考。

編排與對話執行緒控制

ChatGPT 或 Codex 負責所有編排工作，包括：

• 生成新的子智能體
• 給不同智能體路由後續指令
• 等待結果
• 關閉子智能體對話執行緒

當多個智能體並行執行時，ChatGPT 或 Codex 會等待所有要求的結果都返回後，再給出一份彙總答覆。

Web 端 ChatGPT Work

在大多數智慧水平下，ChatGPT 會在收到直接請求後啟動智能體。使用 Ultra 時，只要並行工作適合當前任務，ChatGPT 也可以主動委派。

本機 Codex 客戶端

當前本機 Codex 版本會在直接請求，或適用的專案與 skill 指令要求時啟動智能體。

例如，你可以在當前專案中嘗試下面這段提示詞：

I would like to review the following points on the current PR (this branch vs main). Spawn one agent per point, wait for all of them, and summarize the result for each point.
1. Security issue
2. Code quality
3. Bugs
4. Race
5. Test flakiness
6. Maintainability of the code

管理子智能體

Web 端 ChatGPT Work

開啟 Subagents（子智能體），可以檢視只讀的 Active（活躍） 和 Done（已完成） 列表。選擇已完成的子智能體，可以檢查詳情與結果。Web 側邊欄會報告子智能體活動，但不能在其中停止或引導某個子智能體。

ChatGPT 桌面 App

• 從主對話執行緒中的活動記錄開啟子智能體對話執行緒，檢查其工作。
• 你也可以直接要求 Codex 去引導某個正在執行的子智能體、停止它，或關閉已經完成的智能體對話執行緒。

Codex CLI

• 使用 /agent 在活躍的智能體對話執行緒之間切換，並檢查正在執行的對話執行緒。
• 直接要求 Codex 引導或停止正在執行的子智能體，或關閉已完成的智能體對話執行緒。

IDE 擴充套件

• 當後臺智能體面板可用時，展開它可以檢查狀態、停止活躍子智能體，或開啟某個子智能體對話執行緒。
• 直接要求 Codex 引導或停止正在執行的子智能體，或關閉已完成的智能體對話執行緒。

審批與沙箱控制

本機 Codex 客戶端

子智能體會繼承當前會話的沙箱策略。

Web 端 ChatGPT Work

ChatGPT Work 的子智能體在託管環境中執行，不提供本機 Codex 沙箱或審批模式控制。子智能體使用父聊天可用的工具；網站和連接器仍各自遵循相應的權限規則。

ChatGPT 桌面 App

子智能體會繼承輸入框下方為父會話輪次選擇的權限模式。應先選擇權限模式，再要求 Codex 委派工作。

Codex CLI

在互動式 CLI 中，即使你當前停留在主對話執行緒裡，審批請求也可能來自一個暫時不在前臺的智能體對話執行緒。審批浮層會顯示來源對話執行緒標籤；如果你想先切過去再決定是否核准，可以按 o 開啟對應對話執行緒。

在非互動流程中，或者任何“無法彈出新的審批”的執行環境裡，只要某個動作需要新的核准，這個動作就會失敗，錯誤會被拋回父工作流程。

Codex 在生成子智能體時，也會重新應用父級會話輪次的即時執行時覆蓋項，包括你在當前會話裡通過 /permissions 改的設定，或者類似 --yolo 這樣的全域開關。即使選中的自定義智能體檔案裡寫了不同的預設值，這些父級即時覆蓋也仍然優先。

IDE 擴充套件

子智能體會繼承輸入框下方為父會話輪次選擇的權限模式。應先選擇權限模式，再要求 Codex 委派工作。

你也可以為單個自定義智能體單獨覆蓋沙箱設定，例如強制把某個智能體限定在只讀模式。

自定義智能體

Codex 自帶三種內建智能體：

• default：通用回退智能體。
• worker：偏執行，適合實現和修復類任務。
• explorer：偏只讀，適合程式碼庫探索類任務。

如果你要定義自己的智能體，可以在下面兩個目錄之一中放置獨立的 TOML 檔案：

• 個人級：~/.codex/agents/
• 專案級：.codex/agents/

每個檔案定義一個自定義智能體。Codex 會把它作為一個“額外設定層”應用到生成的會話中，所以自定義智能體能覆蓋的鍵，基本與普通 config.toml 可覆蓋項一致。

每個自定義智能體檔案都必須定義：

• name
• description
• developer_instructions

如果自定義智能體檔案設定了 model 或 model_reasoning_effort，檔案中的值優先。否則，Codex 會分別解析這兩個設定：先看生成智能體時顯式傳入的值，再看對應的 [agents] 預設值，最後繼承父會話。若生成時選擇了另一模型，但既沒有顯式推理強度，也沒有設定預設推理強度，Codex 會使用該模型的預設推理強度。sandbox_mode、mcp_servers、skills.config 等其它會話設定，在自定義智能體檔案省略時仍繼承父會話。

全域設定

全域子智能體設定仍然寫在主設定的 [agents] 下，詳見設定優先順序。

補充說明：

• agents.enabled 預設為 true；設為 false 可停用多智能體工具。
• 未設定 agents.max_concurrent_threads_per_session 時，由 Codex 選擇預設值。已有設定可以繼續使用 agents.max_threads 這一舊別名。
• 生成智能體時顯式提供的值優先於 agents.default_subagent_model 和 agents.default_subagent_reasoning_effort。
• agents.interrupt_message 預設為 true。設為 false 可不把中斷說明寫入智能體上下文。
• 如果某個自定義智能體的 name 與內建智能體重名，例如 explorer，則你的自定義智能體會優先生效。

自定義智能體檔案結構

你也可以在自定義智能體檔案中加入其他 config.toml 支援的鍵，例如 model、model_reasoning_effort、sandbox_mode、mcp_servers 和 skills.config。

Codex 識別自定義智能體依賴的是 name 欄位，而不是檔名。通常讓檔名和 name 一致是最省事的做法，但最終還是以 name 為準。

自定義智能體範例

好的自定義智能體應當足夠聚焦、足夠明確。每個智能體都應該有清晰職責、與職責匹配的工具範圍，以及避免它偏離到相鄰工作的開發者指令。

範例 1：PR 審查

這種模式會把 PR 審查拆分給三個各自聚焦的自定義智能體：

• pr_explorer：負責梳理程式碼庫並收集證據。
• reviewer：負責檢查正確性、安全性和測試風險。
• docs_researcher：通過專用 MCP server 核對框架或 API 文件。

專案設定（.codex/config.toml）：

[agents]
max_concurrent_threads_per_session = 8

.codex/agents/pr-explorer.toml：

name = "pr_explorer"
description = "Read-only codebase explorer for gathering evidence before changes are proposed."
model = "gpt-5.3-codex-spark"
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/agents/reviewer.toml：

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
Lead with concrete findings, include reproduction steps when possible, and avoid style-only comments unless they hide a real bug.
"""

.codex/agents/docs-researcher.toml：

name = "docs_researcher"
description = "Documentation specialist that uses the docs MCP server to verify APIs and framework behavior."
model = "gpt-5.6-luna"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
Use the docs MCP server to confirm APIs, options, and version-specific behavior.
Return concise answers with links or exact references when available.
Do not make code changes.
"""

[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

這套設定適合如下提示詞：

Review this branch against main. Have pr_explorer map the affected code paths, reviewer find real risks, and docs_researcher verify the framework APIs that the patch relies on.

範例 2：前端整合除錯

這個模式特別適合 UI 迴歸、瀏覽器流程不穩定，或橫跨應用程式碼與執行中產品的整合問題。

專案設定（.codex/config.toml）：

[agents]
max_concurrent_threads_per_session = 6

.codex/agents/code-mapper.toml：

name = "code_mapper"
description = "Read-only codebase explorer for locating the relevant frontend and backend code paths."
model = "gpt-5.6-luna"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
Map the code that owns the failing UI flow.
Identify entry points, state transitions, and likely files before the worker starts editing.
"""

.codex/agents/browser-debugger.toml：

name = "browser_debugger"
description = "UI debugger that uses browser tooling to reproduce issues and capture evidence."
model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "workspace-write"
developer_instructions = """
Reproduce the issue in the browser, capture exact steps, and report what the UI actually does.
Use browser tooling for screenshots, console output, and network evidence.
Do not edit application code.
"""

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
startup_timeout_sec = 20

.codex/agents/ui-fixer.toml：

name = "ui_fixer"
description = "Implementation-focused agent for small, targeted fixes after the issue is understood."
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "medium"
developer_instructions = """
Own the fix once the issue is reproduced.
Make the smallest defensible change, keep unrelated files untouched, and validate only the behavior you changed.
"""

[[skills.config]]
path = "/Users/me/.agents/skills/docs-editor/SKILL.md"
enabled = false

這套設定適合如下提示詞：

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.