Coding Agent 不確定性路由

把高推理能力的模型用在釐清問題，再讓具備工具能力、成本較低的模型執行有界任務，是一種 Coding Agent 工作流設計。真正的路由依據應是任務的不確定性、權限與副作用範圍，而不是把某個模型永久指定成規劃者、另一個指定成執行者。本文以 GPT-6 Astra 與 Gemini 3.8 Flash High 作為當前例子；模型與工具改變時，角色也應重新評估。

這個想法部分來自 Work／Codex 的使用額度限制。依方案而定，Astra 使用可能同時受五小時與每週窗口管理；實際用量還會隨模型、推理設定與任務變動，OpenAI 官方說明也明確指出訊息數不是固定額度。於是問題變成：哪些判斷值得把 Work／Codex 額度用在較高推理能力的模型上？

本文是工作流設計筆記，不是模型對決或實驗報告。我沒有提供可公開重現的單一任務 trace，也沒有用自己的帳單或成功率證明這個搭配比較便宜、比較快或品質相同。下文會把個人設計假設、供應商資料與 DeepSWE 公開結果分開處理。

先說結論：路由不確定性，不固定模型職稱

把模型排成「誰比較強」的單一名次，會漏掉更實際的設計問題：任務中的哪些未知，必須先被釐清；哪些工作可以在明確限制下交給執行模型？

工作角色	本文的當前例子	應留下的成果	需要守住的邊界
規劃層	GPT-6 Astra	目標、非目標、已知證據、待查假設、驗收條件與升級規則	規劃結果是 SPEC v0，不代表 repository 假設已被驗證
執行層	Gemini 3.8 Flash High	現況查核紀錄、受限 diff、測試證據、未解問題	不得自行擴大檔案範圍、資料權限或外部副作用
人類關卡	工程師或任務負責人	確認意圖、審查 diff 與風險、接受或拒絕交付	測試通過不等於獲得部署或交付授權

這些是路由角色，不是模型的永久職稱。兩個模型都可能讀碼或寫程式；簡單、低風險的任務也未必需要多模型規劃。應先看任務的歧義、改動面與失敗代價，再決定是否值得加入規劃與升級關卡。

Astra → Flash 工作流：先查核 SPEC，再開始修改

兩模型之間不能只傳一份看起來完整的規格。規劃模型可能沒有讀到完整 repository，也可能基於錯誤假設；因此，執行者要先查核規格，再開始寫 code。

1. 規劃層產生 SPEC v0

先把任務整理成一份可檢查的契約，至少列出：

• 目標與明確的非目標。
• 支持目前理解的 repository 證據，以及尚未驗證的假設。
• 預期變更面、相容性與資料／權限風險。
• 可觀察的驗收條件、測試命令與回滾方向。
• 什麼情況必須停止、回到規劃層或交由人類決定。

SPEC v0 的用途是指出「要查什麼、怎麼判定」，不是先替執行者宣告答案正確。

2. 執行層先做 repository reconnaissance

Flash High 接手後，先只讀取任務相關的程式碼、設定與測試，核對入口、資料流、既有行為、測試位置及規格列出的變更面。它應把每個關鍵假設標成「已確認」、「與現況衝突」或「尚未確認」，並附上檔案或測試依據；此時先不要修改程式。

這是 plan verification gate。若入口、相依模組、業務行為或權限邊界與 SPEC 不符，執行者應停下來，指出衝突及其影響。規劃層或人類更新 SPEC，確認變更面與驗收條件後，才開始實作。這一步避免把錯誤假設包裝成一份確定的計畫。

3. 在確認後執行有界的測試迴圈

SPEC 查核通過後，執行模型才進入修改循環：

1. 只修改已批准的範圍，不順手重構無關模組。
2. 執行既定測試，依失敗訊息做局部修正。
3. 每輪保留 diff、測試結果、未解問題與被觸及的模組。
4. 以步數、時間或變更面上限控制重試；出現新假設、權限變動或外部副作用時停止並升級。

低成本不代表可以無限重試。每一次迴圈都會增加延遲、工具與 token 用量，也會擴大審查負擔。

4. 人類保留交付決定

交付前由人類檢查實際 diff、測試輸出、例外處理、權限範圍與回滾方式。Agent 說「tests passed」是證據的一部分，不是交付授權。這也呼應 AI Agent 完整指南 強調的原則：可驗證的控制迴圈比單次回答更重要。

為什麼這種拆分可能划算？

Frontier model 的價值是 uncertainty compression

「高階模型」的價值不只在於它能多寫幾行 code，而在於它能把模糊需求轉成較少的可行分支。當問題涉及架構、責任邊界、資料生命週期或安全條件時，先少走幾條錯路，往往比後面多產生幾萬個 token 更有價值。

這是本文的工程推論，不是某一家模型的官方定義。我把它稱為 uncertainty compression：先用較強的模型把「不知道要改什麼」變成「知道要驗證什麼」，再讓執行模型承擔可重複的操作。

Executor 的價值是把長迴圈做得夠穩

coding agent 的實作階段常常不是一個漂亮的一次性回答，而是讀檔、修改、編譯、看錯誤、重試、跑測試、再修改。只要任務邊界清楚、工具環境穩定、測試訊號可靠，executor（執行模型）即使需要更多步驟，也可能換來更低的單任務成本與較少的高階模型額度消耗。

但「更多步驟」不是免費的。它會消耗時間、工具呼叫、token、review 注意力與失敗風險。所以我不把「Flash 更便宜」當成結論，只把它當成要用每個任務的完成結果驗證的假設。

額度與 API 成本不是同一件事

OpenAI 的 Astra 使用窗口屬於 Work／Codex 產品使用規則；Google Gemini API 價格則是另一種計費面向。Google 目前的官方價格頁列出 Gemini 3.8 Flash standard paid tier 的輸入價格為每百萬 token 0.75 美元、輸出（含 thinking token）3.75 美元，至 2026 年 12 月 31 日；2027 年 1 月 1 日起分別為 1.50 與 7.50 美元。這些是 API token 價格，不是 Gemini 訂閱方案的月費，也不是我個人的實際帳單。

若要估算總成本，還要把重試、工具結果回填、快取、審查時間與失敗任務算進去；LLM 推論成本怎麼算 已整理過為什麼 API 價格、公開 benchmark 與成本推導不能混成同一個數字。

官方模型定位與 DeepSWE 榜單告訴了什麼？

Google 將 Gemini 3.8 Flash 描述為面向長程 software engineering、自主 Agent 與複雜企業工作流的 Flash 模型。Gemini API 文件列出 1M token context、64K 最大輸出，以及 low／medium／high 的 thinking level；Google DeepMind 官方模型卡也列出 hallucination、偶發延遲或 timeout，以及較高 thinking effort 可能消耗更多 token 等限制。這些資料支持它成為「執行工作馬」的候選，但不等於它在每個 repository、每種語言或每種產品決策上都可靠。

另一個容易被誤讀的訊號是 DeepSWE v1.1 leaderboard。以下是我在 2026 年 9 月 27 日查閱時，頁面標示於 2026 年 9 月 22 日更新的 113 個任務快照；排行榜會持續變動，引用數值時應一併註明快照日期：

手機可左右滑動，查看完整數值表。

模型設定	完成率	平均任務成本	輸出 token	步數
GPT-6 Astra [xhigh]	74% ± 3%	USD 4.43	30K	29
Gemini 3.8 Flash [high]	74% ± 1%	USD 2.36	143K	166
Claude Opus 5 [max]	74% ± 4%	USD 11.84	118K	99
GPT-5.6 Sol [max]	73% ± 3%	USD 6.46	60K	61

資料來自 DeepSWE v1.1 leaderboard；頁面說明所有模型都使用 mini-swe-agent，以維持執行框架一致。在這組任務與設定裡，Flash High 與 Astra 的完成率點估計都顯示為 74%，±範圍重疊；Flash 平均任務成本較低，但輸出 token 與步數較多。這只提供一項值得測試的訊號：在這個 benchmark harness 中，較低的單次任務費用可能伴隨更多執行迴圈。它不等於總交付成本，也沒有計入團隊的人工審查、重試策略或線上副作用。

它不能支持以下結論：

• Flash High 已經全面勝過 Astra。
• 74% 等於一般專案的成功率；它也代表約四分之一任務沒有被解決。
• 平均任務成本就是所有團隊的真實成本。
• 166 步一定比 29 步差，或一定更可靠。

DeepSWE 論文說明了 SWE-bench 類評測可能受到公開解答被模型預訓練看過、以及原有測試偏向驗證單一修法等問題影響；DeepSWE 以原創任務和手寫行為 verifier 回應這些問題。這讓它成為比單看舊榜單更有參考性的基準，但仍只涵蓋 113 個任務、特定 repository 集合與固定 harness。benchmark 能形成假設，不能代替團隊自己的代表性任務、工具環境與人工審查。

這個工作流在哪些任務上比較適合？

我會優先把它用在以下類型：

• 有清楚驗收條件的 bug fix、測試補強、局部重構與文件同步。
• repository 結構相對穩定，執行模型可以從現有 code 和 tests 得到足夠訊號。
• 需要多輪讀碼、修改和測試，但單一任務的權限與外部副作用可以被限制。
• 規劃階段能明確列出非目標，避免 executor 把「順便改善」變成大規模改寫。

這些條件與 AI 軟體開發環境選型 的方向一致：Vibe Coding 的問題不只是模型會不會寫 code，而是工作流能否把 context、工具、驗收與恢復路徑組成一個可觀測的 harness。

反過來，以下任務不應只因為 Flash 成本低就放寬門檻：

風險訊號	可能發生的事	我的處理方式
SPEC 過早固定錯誤假設	executor 高效率地完成了錯的設計	回到 Astra 或人類重新 framing
測試覆蓋不足	綠燈只代表舊測試沒被破壞	增加驗收測試，人工檢查業務語意
跨服務、資料遷移或權限變更	小 diff 也可能有大範圍副作用	提高審查層級，禁止無人批准交付
多輪修復仍無法收斂	token、時間與 diff 迅速膨脹	設定步數／時間／變更面上限並升級
benchmark 與實際工作不同	榜單結果無法預測團隊的成功率	用自己的代表性任務集重跑

如何驗證這個假設，而不是只憑體感？

本文沒有提供可重現的個人任務案例，因此不能用來證明 Astra → Flash 的實際交付成本或成功率。如果要把這個設計交給團隊評估，應先建立一個小型、可重複的基準：

1. 挑選一組代表性任務，包含小修、小功能、跨模組變更與刻意的高風險案例。
2. 固定 repository 版本、工具權限、測試命令、timeout、上下文提供方式與人工介入規則。
3. 分別記錄 Astra-only、Flash-only，以及 Astra planning → Flash execution 的結果。
4. 以「首次通過」、「修復後通過」、「人工審查分鐘數」、「總 token／步數」、「重試與回滾」和「逃逸缺陷」作為指標。
5. 額外記錄被升級的原因，因為升級本身就是路由設計的資料，不是單純失敗。
6. 先用 canary 任務觀察，再決定是否擴大 Flash 的自主執行範圍。

這樣才能回答真正的問題：在相同品質門檻下，把高推理能力放在規劃關卡，是否能降低這個團隊每個已完成任務的總成本與等待時間？

把模型路由寫進工程契約

如果只把這件事理解成「Astra 寫 SPEC、Flash 寫 code」，模型品牌就會蓋過真正需要控制的條件。可交付的路由契約至少要說清楚：

• 什麼叫做「規劃完成」：非目標、已驗證／未驗證假設、驗收條件、測試與 rollback 是否齊全？
• 什麼叫做「執行完成」：是產生 diff，還是測試和人工 review 都通過？
• 哪些資料和工具可以交給 executor？
• 哪些操作需要 human approval？
• 何時以步數、時間、token 或變更面積觸發 escalation？
• 哪個角色審查原始需求、SPEC、diff 與測試結果？哪些決定必須由人類確認？
• 每次模型升級後，哪些代表性任務必須重跑？

這也是為什麼我會把它視為 Agent harness 的問題，而不只是模型選擇。已有的 GPT-5.6 架構與效率整理提供了另一個角度：模型的能力、每 token 產出與推論成本要放回整個執行系統裡看。模型路由最終服務的是交付結果，不是讓排行榜看起來更漂亮。

最後的判斷

DeepSWE v1.1 的 2026-09-22 快照顯示，Astra 與 Flash High 在這組 113 個任務上的完成率點估計相同，Flash 的平均任務成本較低、輸出 token 與步數較多。這是公開 benchmark 的有限訊號，不是我自己的任務實績，也不能證明 Astra → Flash 在一般專案中更便宜或品質相同。

值得帶走的是一個可測試的路由假設：先依任務不確定性與副作用範圍決定需要哪一層判斷，再讓執行者查核規格、在批准範圍內修改，最後由人類接受交付結果。模型品牌可以改變，規劃查核、受限執行與人類關卡仍是流程的關鍵。

這個設計成立的前提是 SPEC 可檢查、執行者有權限邊界、測試能提供訊號、人類保留交付決定，而且任務成本與結果可被記錄。缺少其中任何一項，模型路由都可能讓錯誤更快、更便宜地擴大。