廚房裡多了一個只看鍋、不動鏟的人：Codex 的 Agent 配置，其實是一套排班表

2026 年 9 月 23 日，掘金上出現一篇實戰文章，作者「楊楊楊大俠」整理了 OpenAI Codex 在本地自訂 Agent 時最容易搞混的三件事：角色寫在哪裡、模型由誰決定、檔案寫好了為什麼 Agent 沒有自己跑起來。這些問題聽起來很工程，但換到廚房裡，其實是你家辦一桌菜時天天在處理的事。

一間運轉順的廚房，從來不是靠一個人。有人掌勺，有人備料，也有人只負責站在旁邊看火、聞味道、提醒你湯快燒乾了。那個只看不動手的角色，在 Codex 裡叫 code_explorer，sandbox_mode 設成 read-only，職責寫得清清楚楚：追蹤呼叫路徑，引用具體證據，只做分析，不修改檔案。像極了一位只試喫、只給意見、絕不伸手搶鏟子的老師傅。

三層結構，就是食材庫、食譜卡和排班表

原文把本地配置分成三層。第一層是 ~/.codex/config.toml，管的是入口 Agent 的預設模型和推理強度，順帶限制一個 session 裡最多同時開幾條子 Agent 線程。這是廚房的基礎設備層：爐子幾口、預設火力多大、最多容許幾鍋同時燉。文章裡那個 max_concurrent_threads_per_session = 3，作者也說了只是入門示例，實際要看任務量和資源調整。你家爐臺就那麼大，同時開五鍋高湯，火一定不夠分配。

第二層是 ~/.codex/agents/ 底下的角色檔。每個檔案至少要有 name、description、developer_instructions 三個欄位，等同於一張食譜卡：這道菜叫什麼、做什麼用、步驟怎麼走。放在 ~/.codex/agents/ 是全家通用，放在專案自己的 .codex/agents/ 就只服務那一桌客人。這跟備料做得好不好，決定了上菜順不順是同一個道理，看不見的準備功夫，才是配置的本體。

第三層 AGENTS.md，原文一句話講得漂亮：TOML 定義角色，AGENTS.md 定義調度。排班表上寫的是何時用誰、用什麼等級的火。

固定火候的菜，和看情況調火的菜

文章裡給了兩種角色配置方式，對應廚房裡兩種菜。

reviewer 這個角色，職責穩定，永遠做同一件事：檢查正確性、回歸與安全風險。所以直接在 TOML 裡把 model 和 model_reasoning_effort 一起寫死。作者特別提醒，只固定模型、漏掉推理強度，後者可能沿用其他配置層解析出來的值，兩者未必匹配。這就像一鍋老滷，火候和配方要一起傳下來，只抄一半譜，味道就走了。

另一種是 code_explorer 這種任務難易落差大的角色。有時只需定位一個函數，有時要追跨模組的呼叫鏈。此時不在 TOML 鎖模型，改在 AGENTS.md 裡寫選擇規則：簡單低風險的調查用輕量模型配低推理強度，普通分析用中等，跨系統高風險才動用最重的那組。同一張食譜卡，炒一把青蒜和辦一桌宴席，火力當然不同。

還有一個容易被誤會的重點：寫好角色檔，並不等於有了一個常駐的 Agent。食譜卡放進抽屜，菜不會自己下鍋。要出菜，得給一個明確任務，直接在任務描述裡說出用哪個角色、做什麼範圍，最清楚。

誰說了算，廚房裡也常吵架

多處都配了模型時誰生效？原文指出 Codex 對每個設置項按解析順序決定，自訂的設定優先。這在廚房裡是老問題：食譜卡上寫小火，排班表上寫大火，最後聽現場那一張當次的明確指示。規則層層疊疊沒關係，重要的是誰覆蓋誰要搞得清楚，不然一鍋湯會被三個人各自加一次鹽。

至於文章後半提到的具體模型名稱與帳號支援的組合，作者也提醒要以當前帳號和客戶端實際支援為準，這部分不是每個人都通用，就像市場裡今天有沒有那條魚，去了才知道。

回家可以想想你自己的廚房：哪些菜該寫死火候，哪些菜該留一張看情況調火的排班表。把這件事想清楚，比多買任何一口鍋都劃算。