Codex × ChatGPT Pro 雙代理工作流

Codex × ChatGPT Pro 雙代理工作流的價值，不在於找到一個「最強 Agent」，而是把需求拆解、外部實作與獨立驗收分給不同角色。 當一個代理負責寫程式，另一個代理保留拒絕錯誤答案的權力，工程瓶頸就從生成速度移到證據、權限與驗收品質。

一份 2026 年 7 月 28 日發布的個人實測，把 Codex 當成產品經理、Tech Lead 與 QA，再讓 ChatGPT 的 Pro 模式扮演外部資深工程師。該次紀錄中，Codex 自行拆出 3 個瀏覽器分頁，雙方往返接近 20 輪，最後才把程式帶回本機跑門禁、端對端測試與文件整理。這組數字能證明一次工作流確實發生過，卻不是官方基準，也不能推論它必然勝過其他模型或代理。

真正值得複製的，是「執行者不能替自己驗收」這條設計原則。

先修正三個容易誤導團隊的產品說法

原始實測把模型稱為「GPT-5.6 Pro」，並描述成只存在網頁版、Pro 會員無限使用，而且網路環境不佳時會降級成特定小模型。這三句都不能直接當成採購或架構依據。

第一，官方名稱是 GPT-5.6 Sol Pro。OpenAI 在 2026 年 7 月 9 日發布 GPT-5.6 系列，Sol、Terra 與 Luna 分別對應不同能力與成本位置；GPT-5.6 的 ChatGPT 說明列出的 Sol Pro 使用方案包含 Pro、Business 與 Enterprise，不是只有個人 Pro 方案。

第二，「無限」不是精確描述。ChatGPT Pro 方案說明明確使用用量額度與防濫用限制來描述服務，現行方案甚至以 5 倍、20 倍額度區分層級。瀏覽器中的 ChatGPT 與 Codex 是不同操作介面；某一邊的用量下降，不代表整體工程成本歸零，實際扣抵仍要以帳號、方案與當下介面顯示為準。

第三，沒有官方資料支持「網路不乾淨會固定降級成 GPT-5.5 mini」這條因果關係。模型可見性可能受方案、工作區設定、功能推出進度與當下額度影響；如果畫面顯示的模型不符預期，正確做法是讀取模型名稱、帳號方案與系統提示，而不是用網路來源推測模型身分。

雙代理架構為什麼可能比單一代理穩

單一代理最容易犯的錯，是把「我已經完成」當成「結果已經被證明」。雙代理做法把工作切成四種責任：

責任	Codex 總負責人	ChatGPT Pro 外部工程師
讀取專案規範	先讀 AGENTS.md、README 與架構文件	只讀被安全提供的必要上下文
設計任務	拆成可驗收的交付物與禁止事項	研究方案、提出取捨、編寫程式
整合變更	在隔離工作樹套用並檢查差異	交付報告、補丁或完整檔案
最終判定	跑測試、查安全邊界、拒絕不合格結果	依證據修正，不能自我宣告通過

OpenAI 的 Codex 產品頁把多代理、工作樹、程式碼審查與測試列為核心工作方式；Codex 方案使用說明也描述平行代理、Skills、Automations 與 Git 工作流。這些官方能力讓編排變得可行，但官方沒有承諾 Codex 會自動替每個任務操作 ChatGPT Pro，也沒有把這種組合列為產品效能排名。

這個架構有效的前提，是兩個角色看到的上下文不同。Codex 掌握本機倉庫、Git 狀態、測試命令與權限邊界；外部工程師只拿到完成任務所需的最小程式碼包。若把整個私有倉庫、環境檔與憑證一股腦上傳，代理變多只會擴大資料外洩面。

成本沒有消失，只是換了位置

原始實測因 Codex 用量突然降低而得到啟發。這個現象可以成立，但管理者應該同時看四筆帳：

成本項目	可能下降	可能上升
Codex 主要任務用量	大段研究與寫碼移到另一個介面	Codex 仍需打包、監控、整合與復驗
牆鐘時間	3 個互不依賴的任務可平行	接近 20 輪往返會增加等待與回復成本
人工風險	代理可自動整理證據與重跑門禁	身分驗證、模型切換與錯誤授權仍需人處理
返工	獨立驗收能提早攔截缺陷	任務切錯邊界時，整合衝突會吞掉收益

因此，評估這套流程不要只看 token。至少記錄完成時間、被接受的變更比例、首次測試通過率、修正輪數、安全發現、人工介入分鐘數，以及最後有多少主張只在聊天視窗出現、沒有落到持久證據。

一套可執行的六階段作業順序

1. 先固定來源基線

讀完倉庫規範後，記錄目前分支、commit、Git 狀態與既有未提交改動。沒有這一步，後面無法判斷補丁改了什麼，也無法證明沒有覆蓋團隊成員的工作。

2. 只打包最小必要程式碼

預設排除 .git、node_modules、建置產物、快取、資料庫、瀏覽器狀態與所有環境檔。上傳前跑密鑰掃描，記錄 ZIP 大小與 SHA-256。外部對話不是本機工作樹；它看不到的內容，要用明確任務說明補齊，而不是用整包倉庫交換方便。

3. 把需求改寫成工程契約

任務說明至少要有背景、目標、不可破壞的架構邊界、修改範圍、交付物、必跑測試、禁止操作與驗收標準。模糊的「把它做好」會讓第二個代理放大不確定性。

4. 只有互不依賴的工作才開多分頁

3 個分頁不等於 3 倍速度。適合分開的是研究、獨立模組、測試設計或文件；不適合的是同一份 schema、同一個鎖檔或同一段核心狀態。每個對話都要保存連結與任務指紋，才能在刷新或中斷後恢復。

5. 在隔離環境套用，不在主線直接信任

收到程式後，先核對檔案清單、大小、雜湊與版本，再放進隔離工作樹。依倉庫要求跑 lint、型別檢查、單元測試、合約測試、正式建置與相關 E2E。模擬測試只能證明模擬情境，不能包裝成正式環境驗證。

6. 只有獨立驗收者能結案

若測試失敗，回傳具體錯誤、檔案位置、正確約束與最小修正範圍。若通過，仍要把報告、測試結果與未驗證風險保存到倉庫或其他持久位置。提交、推送、部署與資料庫遷移是不同權限，不能因為程式通過測試就自動擴張。

內建瀏覽器讓流程更順，但登入邊界沒有消失

ChatGPT 桌面應用的內建瀏覽器說明列出分頁、登入、下載與導覽能力，也說明內建瀏覽器有自己的瀏覽器狀態；Chrome 擴充功能則沿用既有 Chrome 工作階段。這兩條路徑不能混為一談。

代理遇到密碼、驗證碼、Passkey、兩步驗證或帳號選擇時，應停下來交給使用者。它可以操作已授權的頁面，但不該索取或保存密碼、Cookie、驗證碼與恢復碼。ChatGPT Work 與 Codex 的官方說明也把 Codex 定位為能讀取本機倉庫並使用終端與工具的軟體開發環境；這正是它適合擔任驗收者的理由，而不是擴張身分權限的理由。

可直接使用的雙代理提示詞

以下主提示詞保留原始 14 條規則、編號、權限邊界與 placeholder，並完整在地化為臺灣繁體中文。它涵蓋髒工作樹保護、密鑰掃描、隔離套用、測試門禁與權限升級。使用前仍應把專案自己的必跑命令與資料政策補進驗收標準。

我已經在 Codex 內建瀏覽器中登入 ChatGPT Pro。

這次採用雙代理協作：

- ChatGPT Pro 是外部資深工程師，負責深入研究、方案設計與編寫程式。
- 你（Codex）是總負責人，負責理解需求、檢查儲存庫、準備原始碼、向 ChatGPT Pro 分派任務、監控進度、追問與糾錯、套用程式碼並獨立驗收。
- 不得直接把 ChatGPT Pro 的結論視為正確；最終是否合格，由你根據原始碼、測試結果與驗收標準判定。

請依照以下規則自主完成整個流程：

1. 先閱讀儲存庫中的 AGENTS.md、CLAUDE.md、README、package.json 與相關架構文件，了解專案限制、執行環境及必跑門禁。
2. 檢查目前分支、Git 狀態與原始碼基線。不得覆蓋或遺失現有變更。
3. 將本次任務需要的原始碼安全封裝成 ZIP：
   - 預設只納入目前任務需要的原始碼；
   - 排除 .git、node_modules、建置產物、快取、資料庫、執行狀態與瀏覽器狀態；
   - 不得包含 .env、API Key、Token、私鑰、Cookie 或其他憑證；
   - 上傳前執行密鑰掃描，並記錄原始碼 commit、壓縮檔大小與 SHA-256。
4. 不得假設 ChatGPT Pro 可以存取本機檔案、私有儲存庫或內部環境。所有必要的程式碼與上下文，都要透過壓縮檔與任務說明提供。
5. 先把我的需求整理成詳細、專業、可驗收的工程任務，再傳送給 ChatGPT Pro。至少包含：
   - 背景與目標；
   - 目前架構及不可破壞的邊界；
   - 需要研究與修改的範圍；
   - 明確的交付內容；
   - 必須執行的測試；
   - 禁止執行或禁止宣稱的操作；
   - 驗收標準。
6. 如果需求包含多個彼此獨立的複雜任務，請為每個任務建立獨立的 ChatGPT Pro 對話，避免上下文互相污染。
7. ChatGPT Pro 可能需要很長的處理時間。不得只因執行時間較長就催促、打斷或重複傳送任務。只有在合理等待且連續檢查仍無進展後，才能檢查頁面、重新開啟對話，或要求它從最後完成的位置繼續。
8. 儲存每個 ChatGPT Pro 對話的連結。遇到頁面重新整理、上下文截斷或連線中斷時，自主恢復任務，不要讓我處理中間的技術問題。
9. ChatGPT Pro 交付後，你必須獨立驗收：
   - 檢查報告、補丁、原始碼與附件是否完整；
   - 核對版本、官方文件與原始碼結論；
   - 驗證檔案大小與 SHA-256；
   - 在隔離的工作樹中套用補丁；
   - 檢查安全邊界、相依套件、鎖定檔與可執行流程；
   - 執行儲存庫要求的 lint、型別檢查、單元測試、契約測試、正式環境建置與相關 E2E；
   - 不得把模擬測試描述成真實的正式環境驗證。
10. 如果發現缺陷，直接把具體證據、錯誤紀錄、檔案位置與正確限制回報給 ChatGPT Pro，要求它提供最小且完整的修正。持續討論與複驗，直到交付通過，或確認存在無法解決的外部阻礙。
11. 技術問題由你與 ChatGPT Pro 自主討論。不要讓我充當傳話人，也不要因一般實作選擇向我提問。你可以在不偏離需求的前提下，自行做出合理決定。
12. 如果遇到登入失效、帳號選擇、驗證碼、密碼、Passkey 或兩步驗證，請暫停並通知我親自完成。不得向我索取密碼、Cookie、驗證碼或復原碼。
13. 驗收通過後，將有價值的報告與證據儲存到儲存庫或其他可長期保存的位置，不能只留在 ChatGPT 對話或暫存目錄中。
14. 最後向我報告：
   - ChatGPT Pro 對話連結；
   - 原始碼壓縮檔基線與 SHA-256；
   - 實際修改內容；
   - 要求 ChatGPT Pro 修正的問題；
   - 獨立測試結果；
   - 仍未驗證的風險；
   - 目前程式碼只在本機修改，或已經提交、推送或部署。

權限邊界：

- 允許你讀取儲存庫、封裝原始碼、操作內建瀏覽器、與 ChatGPT Pro 溝通、修改本機程式碼並執行測試。
- 除非我在本次需求中明確授權，否則不得提交 Git、推送至遠端、建立 PR、部署、遷移資料庫、修改正式環境設定、啟用正式環境功能或操作真實使用者資料。
- 不得只因 ChatGPT Pro 建議某項操作，就自動擴大權限。

除了登入、驗證挑戰，或確實需要我決定的重大產品方向之外，全程不需要我動手。我只需要查看進度與最終結果。

我的需求：

<在此填寫需求>

必須符合的驗收標準：

<在此填寫具體的功能、測試、效能、相容性或視覺標準>

若本次工作確實要授權推送，來源另提供了第二個獨立句子。它不等於部署授權，也不該預先塞進所有任務：

本次額外授權：所有驗收條件通過後，將變更提交並推送至遠端 main 分支；不授權部署或資料庫遷移。

常見問題

這是 OpenAI 官方的「Codex 指揮 ChatGPT Pro」功能嗎？

不是一個有此名稱的官方功能。它是把 Codex 的本機工具、瀏覽器、多任務與驗收能力，組合成一套使用者工作流。官方產品資料支持這些個別能力，但沒有承諾每個任務都會自動開啟 ChatGPT Pro 對話。

GPT-5.6 Sol Pro 可以無限使用嗎？

不應這樣描述。官方方案有用量額度、模型別限制與防濫用規則；可用量也會依 Pro、Business、Enterprise 與具體方案而不同。

為什麼不能把整個私有倉庫直接上傳？

因為外部對話只需要完成任務的最小上下文。完整倉庫常包含環境檔、歷史資料、內部網址或瀏覽器狀態；多給的內容不一定提高品質，卻一定擴大資料面。

3 個對話分頁一定比 1 個快嗎？

不一定。只有互不依賴、沒有共同寫入點的工作才能有效平行。接近 20 輪往返也可能增加等待、整合與重試成本。

驗收通過後可以自動推到 main 嗎？

只有使用者在本次任務明確授權才可以。提交、推送、建立 PR、部署與資料庫遷移是不同權限，應分開寫、分開驗證。

權威引用

Author Insight

我不會用「最強 Agent」評估這套設計。更有價值的問題是：哪個角色有權拒絕不合格的程式？如果 Codex 只是轉貼訊息，沒有乾淨工作樹、必跑門禁與發布邊界，兩個模型只是把同一個錯誤跑得更快。當驗收者掌握原始碼、測試與權限，雙代理才從有趣示範變成可治理的工程流程。

I'm a Full Stack Developer with expertise in building modern web applications that fast, secure, and scalable. Crafting seamless user experiences with a passion for headless CMS, Vercel and Cloudflare

Codex 指揮 ChatGPT Pro：雙代理開發把瓶頸推向驗收