Codex 長期 Agent 工作流的真正門檻，是把責任寫成可審查的狀態、喚醒條件、驗收標準與停止邊界。
OpenAI 開發者體驗負責人 Jason Liu 在一場公開工作坊中，展示了一條已持續五週、累計調度約 400 個子 Agent 的 Codex 執行緒。這個數字很醒目，但它只說明了運算規模。更值得管理者注意的是：執行緒隔了幾天再次被喚醒，仍能辨識自己的職責、讀取既有狀態，並把工作接回原來的脈絡。
這代表企業導入 Agent 的問題正在改變。試用階段關心模型能不能完成一次任務；營運階段則要回答另一組問題：它如何記住未完成事項、何時重新啟動、誰能批准不可逆操作，以及什麼情況下必須停止。
五週與 400 個子 Agent 證明了什麼
工作坊裡的做法，是把不同責任固定在不同的置頂執行緒，例如幕僚、Agents SDK、命令列工具、開源專案與使用者回饋。每條執行緒擁有自己的歷史、目標與自動化排程，也能在需要時把訊息交給其他執行緒。
真正需要長期管理的單位是可持續的責任邊界；子 Agent 數量只反映活動規模。一條執行緒要長期存在，至少需要四層結構：
| 層次 | 必須保存的內容 | 管理目的 |
|---|---|---|
| 責任 | 單一職責、負責對象、允許處理的範圍 | 避免每次喚醒後重新猜測任務 |
| 狀態 | 已知事實、決策、未結事項、下一步 | 讓工作可以跨天延續並接受差異檢視 |
| 喚醒 | 排程、事件、人工訊息、重試條件 | 控制何時花費資源與重新判斷 |
| 驗收與停止 | 測試、證據、批准點、終止條件 | 防止完成定義漂移或無限循環 |
OpenAI 的實務白皮書也採用相近設計：將置頂執行緒視為工作、脈絡、決策與循環的固定住所；將記憶放在對話之外，確保人可以開啟、編輯、比較差異並重複使用。這種外部化記憶比「模型記得很多」更重要，因為治理需要可見的紀錄。
Agent 規模擴大後，成本結構也會改變
長期執行緒不會免費延續。官方文件明確提醒，長執行緒可能比短任務消耗更多資源；自動化心跳每次喚醒也會重新讀取狀態、檢查環境並做出判斷。企業評估總成本時，至少應拆成四類：
- 推理成本：每次喚醒都要重新載入足夠的脈絡。
- 監控成本：排程過密會產生大量沒有新資訊的檢查。
- 審查成本：草稿、變更與例外需要人判讀，工作量可能轉移到批准佇列。
- 錯誤成本：過時狀態、錯誤目標或權限誤判，會在多次循環中累積。
因此，心跳頻率不應由「越即時越好」決定。更實際的做法，是依訊息到達速度與失誤代價調整：高風險事件採事件觸發與人工批准；低風險監測採較長間隔；沒有狀態變化時，直接記錄並結束本輪。
這也解釋了為什麼 Agent 的規模不能直接等同產能。400 個子 Agent 可以是有效的分工，也可能只是 400 次缺乏驗收的嘗試。管理者應追蹤每個目標的證據、人工接手率、無變化喚醒比例與重做次數，才能知道自動化是否真的降低交付成本。
權限控制不能只看連接器名稱
工作坊最重要的警告，來自工具路徑替代。示範中，Slack 連接器無法上傳檔案時，Agent 可能改用電腦操作完成上傳；Gmail 連接器無法寄信時，Agent 也可能開啟瀏覽器並按下傳送。單一連接器的限制，未必等於整個工作環境的限制。
這屬於權限模型的邊界問題。當 Agent 同時取得檔案、瀏覽器、終端機與外部服務，治理必須依「可能造成的結果」分級；單一工具名稱不足以界定風險。
| 操作類型 | 建議預設 | 驗證證據 |
|---|---|---|
| 讀取、搜尋、整理 | 在限定來源內自動執行 | 來源清單與時間戳記 |
| 建立草稿、修改本機檔案 | 自動執行並保留差異 | 檔案差異、測試結果 |
| 對外傳送、公開發佈 | 明確人工批准 | 收件人、公開網址、內容回讀 |
| 刪除、付款、帳號或權限變更 | 最小權限與雙重確認 | 操作者、核准者、不可竄改稽核紀錄 |
OpenAI 對 Codex App 的公開說明指出，預設環境會限制檔案修改範圍，較高權限命令與網路存取需要額外許可。這是一個必要基礎，但企業仍需盤點瀏覽器、自動登入與其他可替代路徑，確保政策涵蓋最後的結果。
從一條可驗收循環開始
一般團隊不需要先複製 400 個子 Agent。更穩定的起點，是選一項低風險、可重複、結果能被驗證的工作，建立以下五個欄位：
- 固定責任：用一句話界定這條執行緒負責什麼，也寫出不負責什麼。
- 目前狀態：以可版本控制的文字檔保存已知事實、決策、阻塞與下一步。
- 喚醒條件：指定排程、事件或人工訊息，並限制重試次數。
- 可驗證結果：用測試、查詢結果、公開頁面或 API 回讀證明完成。
- 停止邊界：達標、缺少權限、連續失敗或成本超標時結束，交由人處理。
第一個試點可以是每日檢查指定系統狀態、整理新回饋，或在資料變更時產生待審草稿。不要先授權寄信、付款或公開發佈。連續執行兩週後，再查看四個訊號：有多少輪次沒有新資訊、人工修正集中在哪裡、哪些證據可以自動取得，以及哪個步驟最常觸發停止。
若這些紀錄清楚，第二條執行緒才有複製價值。若團隊無法說明第一條執行緒為何在某次喚醒後繼續工作，增加 Agent 只會放大不可見的營運風險。
市場訊號：Agent 正從開發工具進入營運層
OpenAI 在 2026 年 4 月公布 Codex 每週開發者超過 300 萬，並加入可在既有執行緒中保留脈絡、跨數天或數週自動喚醒的功能。5 月的更新把每週使用者數字提高到 400 萬以上；6 月則表示每週使用者超過 500 萬，非開發者約占兩成，且成長速度超過開發者三倍。
這些官方數字無法單獨證明企業投資報酬，但能確認使用情境正在跨出程式開發。當 Agent 開始處理研究、營運、設計與跨工具流程，責任分工、批准政策與稽核證據會成為產品採購的一部分。評估焦點也會從模型排行榜，移到一個組織能否安全地讓工作跨時間延續。
決策清單：導入前先問八個問題
- 這條執行緒只有一個明確責任嗎？
- 狀態是否存放在團隊看得到、能比較差異的位置？
- 每次喚醒的條件、頻率與最大重試次數是否明確？
- 完成後會留下什麼可重現證據？
- 哪些結果必須由人批准？
- 是否存在繞過連接器限制的替代工具路徑？
- 成本或失敗達到什麼門檻時要停止？
- 誰負責定期刪除過時狀態與撤回權限？
只要其中一題沒有答案，試點就應維持小範圍。長期 Agent 的競爭力，最終來自清楚的作業設計與可追溯的控制面。
常見問題
長期 Agent 等於讓模型永遠執行嗎？
兩者並不相等。較安全的設計會讓執行緒長期保存責任與狀態，每次由排程、事件或人工訊息喚醒；單次執行仍需有完成條件、時間上限與停止規則。
400 個子 Agent 是必要的規模嗎？
不需要。這是工作坊中某條長期執行緒的累計數字，不能視為建議配置。大多數團隊應先驗證一條低風險循環，再依證據擴充。
記憶應該放在對話裡，還是外部檔案？
需要長期營運的狀態，應優先放在可開啟、編輯、版本控制與稽核的外部檔案。對話歷史可以保留脈絡，但不適合成為唯一紀錄。
已限制連接器權限，為什麼還要檢查瀏覽器？
因為 Agent 可能透過另一項工具達成相同結果。治理要盤點「寄出、上傳、刪除、付款」等結果能力，並對所有可用路徑套用一致批准規則。
什麼樣的任務適合成為第一個試點？
低風險、頻率固定、輸入來源明確，且能用測試或資料回讀驗證的任務最合適。若工作涉及公開發佈、財務交易或存取敏感資料，應先建立人工批准與稽核機制。
詞彙表
- 置頂執行緒：長期保存特定責任、歷史與自動化的固定工作空間。
- 心跳：依排程或條件重新喚醒 Agent，檢查狀態並決定是否採取行動。
- 外部化記憶：把決策、未結事項與下一步寫入可由人檢查的檔案或系統。
- 工具路徑替代：原工具受限時，Agent 改用瀏覽器、電腦操作或其他工具達成相同結果。
- 停止邊界：達到目標、失敗次數、成本或權限門檻後，結束自動執行的明確規則。
權威引用
- Full Workshop: Setting Yourself Up for Success — Jason Liu, OpenAI Codex：五週執行緒、約 400 個子 Agent、置頂責任、心跳與工具路徑替代的第一手工作坊紀錄。
- Codex Maxxing: From Inbox to Outcome：置頂執行緒、外部化記憶、自動化心跳、驗收與人工決策邊界。
- Codex：Codex 的目前產品定位、跨介面工作方式與背景執行能力。
- Codex for almost everything：長期執行緒自動化、記憶功能與 2026 年 4 月使用數據。
- Introducing the Codex app：獨立執行緒、工作樹、自動化，以及沙箱與權限預設。
- Codex for every role, tool, and workflow：2026 年 6 月跨職能採用數據。
作者觀點
Tenten 在設計內容發佈、資料監測與開發代理流程時，會把「完成」拆成可回讀的證據，例如公開網址、API 狀態、檔案差異與測試結果。常見失誤是把長時間執行誤當成長期責任：缺少狀態檔、批准點與停止規則後，團隊很難判斷 Agent 正在推進工作，還是在重複消耗資源。
若你的團隊正在評估 Codex 長期 Agent 工作流，Tenten 可以協助盤點任務、權限路徑、驗收證據與試點範圍。請透過 Tenten AI 顧問服務 聯絡我們。
