如何將複雜 Agent 的有效吞吐量提升 96.3 倍

在相同品質標準與 8 分鐘 SLA 約束下，我們將複雜原型設計 Agent 的單任務平均成本從 21.80 美元降至 0.88 美元，P95 端到端耗時從 55.4 分鐘壓縮至 7.6 分鐘，每 100 美元算力完成的合格交付數提升了 96.3 倍。

這一演進始於一個在生產環境中極為常見的痛點：使用者僅僅修改了一個頁面的元件樣式或互動按鈕，未受控的 Agent 卻在自由探索中引發了全域程式碼重構。原本幾分鐘就能完成的微調，演變成動輒耗時 60 分鐘、消耗 30 多美元的模型計算黑洞。

這一看似偶發的局部重構案例，恰恰折射出複雜 Agent 系統在工程落地時的普遍困境：當任務圖的關聯度隨系統複雜度成倍增加時，缺乏明確邊界的非確定性推理會將整個系統拖入震盪與熵增的泥潭。

最佳化此類複雜 Agent 系統，本質上需要回答三個核心架構問題：

1. 終局邊界：什麼條件定義任務真正的完成；
2. 推理邊界：哪些狀態節點需要大模型的非確定性推理；
3. 控制邊界：已確定的計算與規則工作流應當如何高效執行。

本文梳理該系統在過去數月演進中的架構疊代邏輯：系統從最初依賴模型自由探索的 ReAct 模式，逐步收斂為基於契約解耦、確定性狀態機工作流與上下文拓撲最佳化的高效率架構。

1. 事後審查模式的時延與成本陷阱

在早期架構中，系統採用 ReAct 機制驅動整個生成生命週期。Agent 根據當前狀態推理下一步動作，呼叫工具執行程式碼撰寫或校驗，並依據回饋決定繼續生成、修復還是終止任務。

為了確保交付品質的下限，架構在 ReAct 迴圈中逐漸疊加了多層審查機制：每次頁面生成後強制進入審查環節，若發現缺陷則觸發修復，修復完成後再次校驗。

flowchart LR
    A["頁面實作"] --> B["審查評估"]
    B -->|"發現問題"| C["局部修復"]
    C --> B
    B -->|"透過"| D["交付完成"]

這一階段的架構在品質維度攔截了低品質產物到達交付門禁。但在系統工程維度，過度依賴事後審查產生了顯著的瓶頸：

• 計算鏈路膨脹：每一輪審查都伴隨著完整的上下文裝載、模型推理與工具互動。修復過程可能改寫原本正確的模組，引發連鎖式的二次審查。
• 長尾時延顯著：在複雜場景下，單次任務的模型成本經常超過 20 美元，端到端耗時突破 60 分鐘。
• SLA 不可控：即便簡單任務也可能因模型評估的波動陷入多輪審查，導致服務時延承諾難以保持穩定。

在填補品質漏洞的同時，審查過重的版本展現出非常典型的長尾開銷：

這組數據揭示了一個反直覺的工程現象：事後審查固然抬高了品質下限，但無法提升系統的有效交付能力。 相反，它讓系統用越來越多的算力成本，換取越來越不可控的完成時間。

系統的改進方向由此從單純追求高成功率，轉向在可控成本與時延約束下提供工程可用性。

2. 量化基線：Agent Goodput 的工程定義

為精確衡量架構演進的工程收益，系統借鑑了計算機網路與分散式系統中的吞吐量評估方法，引入有效吞吐量 Agent Goodput 這一核心工程指標。

在計算機網路中：

• Throughput 計算物理鏈路上傳輸的所有資料包，包含重傳包和報頭開銷；
• Goodput 扣除所有開銷與損耗，僅計算應用層最終成功接收的有效負載。

映射到 Agent 系統中：

• Token 或 Request 吞吐量僅代表模型呼叫的原始算力消耗或互動頻次；
• Agent Goodput 則是指剔除無效探索、冗餘審查與逾時重試後，系統在單位算力投入下最終交付的合格產品數。

系統將有效吞吐量顯式定義為：

這一指標直觀回答了一個問題：系統每消耗 100 美元算力，能在承諾的 SLA 時限內交付多少個合格的產品原型？

公式對分子與分母施加了明確約束：

• 分子篩選：僅包含同時滿足產品完整度達標且端到端耗時在 SLA 範圍內的任務；
• 分母核算：包含全量算力開銷，涵蓋模型 Token、工具執行、中間審查、失敗重試及未完成任務消耗的所有資源。

Agent Goodput 明確了架構最佳化的先後順序：在品質達到交付門禁的前提下，首先將時延收斂至 SLA 區間，在此基礎上最小化完成任務的算力成本。

3. 架構解耦：契約驅動與決策前置

舊架構效率低下的根源在於決策密度的離散分佈。在開放的 ReAct 迴圈中，每個頁面生成節點都在獨立嘗試理解整個產品，導致設計決策分散在各個子任務中，極易引發風格偏離與多輪震盪修復。

解決方案是將非確定性的設計推理集中收斂到執行之前，引入顯式的規劃節點。規劃節點在程式碼實作之前凍結三類系統級契約：

1. 任務拆分契約：鎖定產品的頁面樹結構、路由關係與各頁面的職責邊界；
2. 共享約束契約：收斂全域視覺 Token、通用 UI 元件庫與狀態資料流規範；
3. 驗收契約：定義判定任務完成的客觀規則與門禁條件。

flowchart TD
    subgraph NEW["契約解耦與前置規劃架構"]
        N1["規劃節點生成全域契約"] --> N2["頁面 A 邊界內實作"]
        N1 --> N3["頁面 B 邊界內實作"]
        N1 --> N4["頁面 C 邊界內實作"]
        N2 --> N5["確定性門禁校驗"]
        N3 --> N5
        N4 --> N5
    end

透過契約前置，系統實現了全域決策與局部實施的徹底解耦。規劃節點集中承擔了高不確定性的架構推理，下游子任務則被限定在確定性契約的邊界內部。事後審查機制也隨之簡化為針對契約的確定性校驗，大幅削減了不必要的長鏈 LLM 審查。

4. 拓撲重構：並行執行與 Prefix Cache 共享

全域規劃契約的確立，為子任務開闢了獨立推進的空間。然而，在工程落地時，如果直接將子任務並行推進，系統會面臨新的瓶頸：上下文載入膨脹與分支耗時累加。

針對這兩個問題，系統分別做出了針對性重構：

4.1 關鍵路徑解耦與分支並行

在獲得穩定的規劃契約後，頁面級實作任務共享相同的產品事實，端到端耗時的增長模式從序列相加轉變為由最慢關鍵路徑決定：

• 序列耗時：\( T_{\text{serial}} \approx T_{\text{plan}} + \sum T_{\text{page}} + T_{\text{gate}} \)
• 並行耗时：\( T_{\text{parallel}} \approx T_{\text{plan}} + \max(T_{\text{page}}) + T_{\text{gate}} \)

按頁面數量分桶評測，並行化的工程收益非常直觀：

舊架構的耗時隨頁面數量線性增長；新架構中，頁面增加主要擴大併發寬度，而不會拉長關鍵路徑。與此同時，完整交付率保持穩定，說明規劃已將原本由末端審查承擔的品質底線前置到了執行之前。

4.2 樹狀 Prompt 拓撲與 KV Cache 複用

簡單並行雖然縮短了耗時，但如果不加控制，每個併發分支都會重複載入全域需求、產品結構與視覺約束，導致 Token 成本隨併發寬度激增。

解決該瓶頸的核心在於重構輸入的上下文拓撲。新架構將 Prompt 輸入解耦為全域靜態前綴（包含需求全景、契約規範與元件庫）與局部動態任務（僅包含當前分支指令）：

flowchart TB
    P["全域靜態前綴<br/>需求 · 結構 · 視覺約束 · 規範"]
    P -->|"Prefix Cache 共享"| A["頁面 A 局部任務"]
    P -->|"Prefix Cache 共享"| B["頁面 B 局部任務"]
    P -->|"Prefix Cache 共享"| C["頁面 C 局部任務"]

全域靜態前綴利用推理引擎的 Prefix Cache 特性建立 KV 快取，後續並行分支均可無縫複用。首次寫入開銷被多個分支攤薄後，複雜的輸入上下文讀取成本得到了量級壓縮：

這一設計將併發成本的增長曲線從線性相加轉變為單次寫入、多次複用，僅透過上下文拓撲最佳化，就使 5～6 頁複雜原型的完整任務成本下降了 56%。

5. 控制收斂：有界狀態機與確定性門禁

解耦了決策邊界與上下文開銷後，系統需要解決最後一個瓶頸：ReAct 迴圈帶來的執行熵增。

ReAct 機制適合在未知空間中進行開放探索。然而，在任務目標與驗收契約已經明確的階段，繼續允許模型自主決定是否反覆審查和最佳化，極易引發無限迴圈與長尾耗時。

新架構將控制權從 LLM 手中收回，構建了由確定性狀態機主導的工作流：

flowchart LR
    P["規劃階段<br/>Agent 探索"] --> E["分支並行<br/>工作流控制"]
    E --> G["契約門禁<br/>規則校驗"]
    G -->|"透過"| D["交付完成"]
    G -->|"失敗"| R["異常修復<br/>局部 Agent"]
    R --> G

在有界控制流中：

• 狀態機工作流 嚴格掌控分支併發、逾時控制與重試預算；
• 規則門禁 提供客觀、低時延的 Pass/Fail 訊號；
• Agent 作用域 被收窄至規劃階段的開放決策，以及門禁未透過時的局部有界修復。

校驗透過時，工作流立即終止；校驗失敗時，修復上下文限定在報錯模組內部，避免全域重跑。

狀態機控制流為系統建立了極其清晰的執行耗時與成本收斂邊界：

更重要的是，8 分鐘不只是一次較好實驗的觀測值，而是控制流設計出來的工程邊界：併發預算、局部修復與終止條件共同保證了系統不會再次滑入無限審查的極端長尾。

6. 吞吐量對比與拓撲重構範式

在統一評測集上（200 個樣本，覆蓋 2～6 頁面原型，8 分鐘交付 SLA），上述三項範式轉換推動系統實現了 Agent Goodput 的階躍增長：

回顧業界在 AI Agent 效能與成本最佳化上的探索，我們常常能看到不同的視角：

• OpenAI 提倡建立確定性的評估基線（Evals），並利用模型級聯（Model Cascading）將簡單步驟路由給輕量模型；
• Anthropic 在 Agent 最佳實踐中強調控制鏈路極簡，僅在非確定性分支中引入推理；
• EvoRoute 與 AI21 Maestro 等系統分別在執行時模型路由與多 Agent 配置搜尋上展開了深耕。

我們在演進過程中汲取了這些路線的精華，但也發現了最本質的差異：模型路由最佳化解決的是「給定節點由誰推理」，而我們的架構演進解決的是「該推理節點是否需要發生」。

透過規劃前置確定全域契約，我們將不可控的自由探索收斂為有界工作流與確定性門禁。路由策略決定算力載體，而任務圖本身的重構則從源頭上剔除了龐大的冗餘推理。

7. 結語：從在線阻斷到離線品質飛輪

複雜 Agent 系統的工程演進經歷了三個階段：從依賴事後審查保障品質下限的粗放探索期，到透過契約前置壓縮不確定性的結構解耦期，最終收斂至由狀態機控制時延與成本邊界的有界控制期。

這一過程遵循三條基本工程原則：

在這套有界工作流中，同步序列的事後審查已被確定性門禁取代，系統端到端耗時被成功鎖死在 SLA 範圍內。然而，審查過程中捕獲的錯誤分類、互動斷層與修復 Trace，本身卻是極高含金量的診斷資產。

當審查機制從在線主路徑的阻塞式鏈路中徹底解耦後，如何將這些沉澱的診斷訊號下沉至後台異步閉環——用於專用小模型微調、強化學習偏好對齊（DPO/RLHF）或動態門禁演進——便成為了 Agent 系統工程邁向下一個階段的演進方向。

參考與延伸閱讀

1. Anthropic, Building Effective Agents: https://www.anthropic.com/research/building-effective-agents
2. OpenAI, OpenAI Evals Framework: https://github.com/openai/evals
3. EvoRoute Research, Dynamic Model Routing for LLM Agent Workflows
4. AI21 Labs, Maestro: Multi-Agent Orchestration Engine