子智能體

ChatGPT Work 和 Codex 可以生成多個專用智能體並行執行任務， 然後將它們的結果彙總到一個響應中，從而執行子智能體工作流程。這對於 高度並行的複雜任務尤其有用，例如探索程式碼庫或實施多步驟功能計劃。

在本機 Codex 客戶端中，你還可以針對不同任務定義具有不同模型 設定和指令的自定義智能體。

可用性

網頁版 ChatGPT Work

ChatGPT Work 向符合條件的帳戶開放子智能體工作流程及其活動資訊。

本機 Codex 客戶端

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

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

網頁版 ChatGPT Work

在 ChatGPT Work 中，請 ChatGPT 將相互獨立的工作委派給子智能體。 這些智能體在 ChatGPT 的託管環境中執行，聊天中會顯示它們的活動 和結果。在大多數智慧級別下，需要明確要求委派。使用 Ultra 時，如果並行智能體能夠顯著提高速度或質量，ChatGPT 可以主動委派工作。

ChatGPT 桌面應用

在應用聊天中，請 Codex 將相互獨立的工作部分委派給 子智能體。當前本機 Codex 版本會在你直接提出要求，或適用的 AGENTS.md 或技能指令要求委派時執行委派。應用會顯示每個 子智能體執行緒，方便你檢查其工作以及傳回給主聊天的摘要。

Codex CLI

在互動式 CLI 會話中，請 Codex 使用子智能體。Codex 也可以遵循 要求委派的適用 AGENTS.md 或技能指令。子智能體執行期間，使用 /agent 檢查並切換智能體執行緒。主 執行緒會將子智能體的結果彙總到最終響應中。

IDE 擴充套件

在 IDE 聊天中，請 Codex 將相互獨立的工作部分委派給子智能體。 Codex 也可以遵循要求委派的適用 AGENTS.md 或技能指令。 後臺智能體 UI 可用時，活躍的子智能體會顯示在 輸入框上方。展開面板即可檢視其狀態、停止所有活躍的 子智能體，或開啟單個子智能體執行緒。

子智能體工作流程為何有用

即使上下文視窗很大，模型仍有其限制。如果你讓主聊天（你在其中定義需求、約束和決策）充斥探索筆記、測試日誌、堆疊跟蹤和命令輸出等嘈雜的中間輸出，會話的可靠性可能會隨時間推移而下降。

這種現象通常稱為：

• 上下文汙染：有用資訊被淹沒在嘈雜的中間輸出中。
• 上下文腐化：隨著聊天中不太相關的細節不斷增多，效能逐漸下降。

有關背景資訊，請參閱 Chroma 關於上下文腐化的文章。

子智能體工作流程通過將嘈雜的工作移出主執行緒來提供幫助：

• 讓主智能體 專注於需求、決策和最終輸出。
• 並行執行專用子智能體，用於探索、測試或日誌分析。
• 讓子智能體傳回摘要，而不是原始中間輸出。

當工作可以相互獨立地並行執行時，它們還能節省時間；通過將 規模更大的任務拆分成邊界明確的部分，也能使其更易處理。 例如，Codex 可以將對數百萬 token 文件的分析拆分成 多個較小的問題，並向主執行緒傳回提煉後的要點。

作為起點，可將並行智能體用於以讀取為主的任務，例如 探索、測試、問題分類和總結。對於以寫入為主的並行 工作流程則應更加謹慎，因為多個智能體同時編輯程式碼可能會產生 衝突並增加協調開銷。

核心術語

Codex 在子智能體工作流程中使用以下幾個相關術語：

• 子智能體工作流程：Codex 執行多個並行智能體並合並其結果的工作流程。
• 子智能體：Codex 啟動並委派其處理特定任務的智能體。
• 智能體執行緒：子智能體執行工作的執行緒。受支援的客戶端允許你開啟這些執行緒以檢查進度或結果。

觸發子智能體工作流程

網頁版 ChatGPT Work

在大多數智慧級別下，直接要求使用子智能體或並行智能體工作。 Ultra 支援主動委派，因此 ChatGPT 無需單獨請求， 即可委派適合的獨立工作。

本機 Codex 客戶端

直接要求使用子智能體或並行智能體工作。當適用的專案或技能指令 要求委派時，Codex 也可以執行委派。

在實踐中，手動觸發是指使用直接指令，例如 “生成兩個智能體”、“並行委派這項工作”或“每個要點使用一個智能體”。 子智能體工作流程比同類單智能體執行消耗更多 token， 因為每個子智能體都會獨立執行模型和工具相關工作。

一條好的子智能體提示詞應說明如何劃分工作、Codex 是否應 等待所有智能體完成後再繼續，以及需要傳回什麼摘要或輸出。

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.

選擇模型和推理級別

不同的智能體需要不同的模型和推理設定。

網頁版 ChatGPT Work

在 ChatGPT Work 中，從輸入框選擇模型和智慧級別。 根據所選模型，可用的智慧級別可能包括 Light、Medium、High、 Extra High 和 Max。Ultra 僅向符合條件的帳戶和受支援的模型開放。它使用最高推理級別，並允許 ChatGPT 主動將合適的工作委派給子智能體。

在其他智慧級別下，如果希望並行委派工作，請明確要求使用子智能體。

本機 Codex 客戶端

如果未設定子智能體模型或 model_reasoning_effort， 子智能體將繼承父智能體的模型和推理力度。如果顯式 生成請求或 [agents] 預設值選擇了模型，卻未顯式指定或 設定推理力度，子智能體將使用該模型的預設推理 力度。要針對每項任務平衡智慧、速度和價格，可以在提示詞中請求 特定模型或推理力度，在 config.toml 中設定 [agents] 預設值， 或直接在自定義智能體檔案中設定 model 和 model_reasoning_effort。 例如，使用 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：當智能體需要跟蹤複雜邏輯、檢查假設或處理邊界情況時使用（例如審查或注重安全的智能體）。
• medium：適用於大多數智能體的均衡預設值。
• low：當任務簡單直接且速度最重要時使用。

更高的推理力度會增加響應時間和 token 用量，但可以提高複雜工作的質量。有關詳細資訊，請參閱模型、設定基礎和設定參考。

編排和執行緒控制

ChatGPT 或 Codex 負責跨智能體編排，包括生成新的 子智能體、轉發後續指令、等待結果以及關閉 智能體執行緒。

當多個智能體正在執行時，Codex 會等待所有請求的結果 就緒，然後傳回合並後的響應。

網頁版 ChatGPT Work

在大多數智慧級別下，ChatGPT 會在收到直接請求後生成智能體。使用 Ultra 時，如果並行工作有用，ChatGPT 也可以主動委派。

本機 Codex 客戶端

當前本機 Codex 版本會在收到直接請求或適用的 專案或技能指令後生成智能體。

要檢視實際效果，請在你的專案中嘗試以下提示詞：

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

管理子智能體

網頁版 ChatGPT Work

開啟 Subagents 可檢視只讀的 Active 和 Done 列表。選擇一個 已完成的子智能體即可檢查其詳細資訊和結果。網頁側邊欄會報告 子智能體活動，但不提供停止或引導單個 子智能體的控制項。

ChatGPT 桌面應用

• 從主執行緒中顯示的活動開啟子智能體執行緒，以檢查 其工作。
• 直接要求 Codex 引導正在執行的子智能體、停止它，或關閉已完成的 子智能體執行緒。

報告檢查清單簡報檢查清單已開始工作

執行中沒有執行中的子智能體

已完成 · 3

模型 API 審查審查完成；未發現端點相容性問題。

2 分鐘

軟體包審查最穩妥的工作流程是有針對性地更新依賴項。

3 分鐘

落地頁審查審查完成；最終佈局已無阻礙問題。

4 分鐘

Codex CLI

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

IDE 擴充套件

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

審批和沙箱控制

本機 Codex 客戶端

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

網頁版 ChatGPT Work

ChatGPT Work 在其託管環境中執行子智能體，不提供 本機 Codex 沙箱或審批模式控制項。子智能體使用父聊天可用的工具。 網站和連接器權限仍由具體工具決定。

ChatGPT 桌面應用

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

Codex CLI

在互動式 CLI 會話中，即使你正在檢視主執行緒，審批請求也可能 從非活躍的智能體執行緒中彈出。審批浮層 會顯示來源執行緒的標籤，你可以按 o 開啟該執行緒，然後再 核准、拒絕或回應請求。

在非互動式流程中，或在執行無法顯示新的審批請求時， 需要新審批的操作會失敗，Codex 會將錯誤傳回給 父工作流程。

Codex 在生成子智能體時，還會重新應用父輪次的即時執行時覆蓋項。 這包括你在會話期間以互動方式設定的沙箱和審批選擇， 例如 /permissions 更改或 --yolo，即使所選 自定義智能體檔案設定了不同的預設值也是如此。

IDE 擴充套件

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

你還可以覆蓋單個自定義智能體的沙箱設定，例如明確將某個智能體標記為只讀模式。

自定義智能體

Codex 隨附以下內建智能體：

• default：通用後備智能體。
• worker：面向實施和修復、專注執行的智能體。
• explorer：以讀取為主的程式碼庫探索智能體。

要定義自己的自定義智能體，請將獨立 TOML 檔案新增到 ~/.codex/agents/（個人智能體）或 .codex/agents/（專案範圍的 智能體）下。

每個檔案定義一個自定義智能體。Codex 會將這些檔案作為生成會話的設定 層載入，因此自定義智能體可以覆蓋與普通 Codex 會話設定相同的 設定。相比專用的智能體清單，這可能顯得較為繁重；隨著創作和共享機制日趨成熟， 其格式也可能發生變化。

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

• name
• description
• developer_instructions

如果自定義智能體檔案設定了 model 或 model_reasoning_effort，則以檔案中的值為準。 應用該檔案之前，Codex 會依次從顯式生成值、對應的 [agents] 預設值、 再到父智能體的值來解析每項設定。如果顯式生成請求或 [agents] 預設值 選擇了模型，而兩者均未提供推理力度，Codex 將使用該模型的 預設力度。僅設定 model 的自定義智能體檔案會保留此前 解析出的力度。如果所選模型不支援該力度，或者你希望使用其他力度， 請同時在檔案中設定 model_reasoning_effort。自定義智能體檔案省略其他 會話設定（例如 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 可從智能體上下文中省略模型可見的中斷訊息。
• 如果自定義智能體名稱與 explorer 等內建智能體相同，則以自定義智能體為準。

自定義智能體檔案架構

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

Codex 通過自定義智能體的 name 欄位識別它。讓檔名與 智能體名稱保持一致是最簡單的約定，但 name 欄位才是最終 依據。

自定義智能體範例

最優秀的自定義智能體應當範圍明確且有鮮明傾向。為每個智能體分配清晰的職責， 提供與該職責匹配的工具範圍，並通過指令避免其 偏離到相鄰工作。

範例 1：PR 審查

此模式將審查工作拆分給三個各有側重的自定義智能體：

• pr_explorer 梳理程式碼庫並收集證據。
• reviewer 查詢正確性、安全性和測試風險。
• docs_researcher 通過專用 MCP 伺服器檢查框架或 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.6-luna"
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.6-luna"
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.