編排決定 Token 經濟效益

資料來源#

• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI
• The price is wrong: AI cost calculation has to consider task completion rates, not just token costs

摘要#

這是語料中首度在模型固定下，受控比較兩種 harness 的測量。Writer, Inc. 在六個基礎模型上執行 22 項鎖定的評估任務，採用兩種編排層——一種凍結於 2026-06-07 的傳統生產代理迴圈，以及 Writer 自家的 Agent Harness——並讓任務、提示、模型識別碼、LLM 評審小組和價格表在兩組間完全相同。唯一變數是編排程式碼。

跨模型合併後：每項任務成本降低 41%（$0.21 → $0.12）、tokens 減少 38%（14.2k → 8.8k）、實際耗時中位數縮短 44%（48 s → 27 s），品質則持平（0.78 → 0.81；研究明確指出在 n = 22 下可視為無差異）。六個模型全都變便宜，降幅介於 33% 到 61%。最重要的結論是：在這組工作負載中，編排層對帳單的影響大於整個模型選單的價格差距——在基準組中，從最貴的模型換成最便宜的模型可省 36%；保留任何模型、只換 harness 則可省 33–61%。

證據說明——解讀每個數字時都要記住這一點。 這屬於 empirical 等級，而且利益衝突無所不在：33 位作者全是 Writer 員工，末位作者是共同創辦人兼 CTO，而論文用 Writer 自家的 harness 對比 Writer 自己凍結的基準組，模型中也包含 Writer 自家的 Palmyra X6。論文自行揭露了這點；以供應商進行的評測來說，其設計也異常容易稽核（基準已凍結、鎖定提示事前依通過／失敗條件審核、評審與價格表一致、候選模型的失敗照樣計分而未排除，並附有產出物發布清單）。但基準組也是供應商自行選定的，而且其描述是一個每回合都重播 49 KB 單體系統提示、以 regex 解析 XML 工具呼叫，並會破壞性地截去中段內容的迴圈。這裡沒有任何測量是拿它和競爭對手的 harness 比較。應把趨勢方向與不受模型影響視為較穩固的發現，而把幅度視為這一組比較特有的結果。

實驗#

	基準組	Harness 組
編排方式	傳統生產代理迴圈，凍結於 2026-06-07	Writer Agent Harness，採預定 GA 設定
系統提示	約 49 KB 單體提示，每回合重播	位元組穩定的前綴 + 易變尾部（如下）
工具呼叫	文字串流中的 XML，以 regex 解析	僅使用原生工具呼叫
上下文溢位	破壞性中段截斷	非破壞性結構化壓縮
等待	輪詢回合	以零 token 成本持久暫停
委派	沒有	限定範圍的子代理並合併結果
依模型調校	有	六個模型共用一條執行路徑

22 個鎖定提示涵蓋九種能力領域（身分／拒絕、依據資料與檢索、內容生成、多步驟 Playbooks、MCP 工具使用、簡報、語音、影像，以及僅 harness 組包含的子代理），並包括多回合與長期任務案例。六個模型來自五家供應商、三種權重類別：兩個前沿通用模型、一個快速層模型、兩個開放權重候選模型，以及 Writer 平台原生的 Palmyra X6。成本是在產出報告時，依每回合記錄的 token 數套用固定的 OpenRouter 價格表計算，兩組方式相同——因此美元數字是根據 token 測量推導而來，並非帳單資料。

拆解帳單#

這種拆解方式讓結果顯得可預期，而非令人意外。每回合輸入 tokens 可拆成 harness 建構的幾個項目：

T_in(i) = S(i) + H(i) + G(i) + R(i) + U(i)
 system history tool retrieval user
 schemas

五項中有四項由程式碼決定，而非模型；重試與走不通的分支也一樣，且它們會放大整體成本。天真的迴圈會重播完整逐字稿，因此總輸入 tokens 會隨回合數以二次方成長；能壓縮歷史、快取不變前綴、將大型工具輸出移出上下文並截短檢索內容的 harness，則能把二次項轉成近似線性。模型完全沒變，變的是帳單。

兩個事實讓這點更清楚：

• 代理工作負載主要由輸入構成。 由於每回合都會重新提交逐字稿，生產代理的輸入：輸出比例接近 100:1（引述 Manus），所以輸入項幾乎就是整張帳單。
• 輸入 token 的價格並非單一數字。 若有比例為 h 的輸入 tokens 以快取讀取方式提供，價格倍率為 κ ≈ 0.1，則有效輸入價格為 p_eff = p_in · (1 − h(1 − κ))。而 h「既不是模型屬性，也不是供應商給的優惠；它取決於不同回合間提示的位元組穩定性，完全由編排層如何組裝上下文決定。」因此 harness 同時控制兩個因素——提交多少 tokens，以及佔主要部分的 tokens 以什麼價格計費。獨立第三方對快取實際效果的測量，請見 Prompt-Cache Economics。

Token maxing#

論文提出的命名診斷，將其描述為可證偽的軌跡，而非模糊感受。若開發路徑 {(Q_t, τ_t)} 呈現 token 強度上升，同時每 token 的邊際品質下降——每次發布換得品質所付出的 token 成本，都比系統目前平均的交換率更差——便稱為 token maxing。對以基準品質評量的團隊而言，這樣做個別來看合乎理性；但對按 token 付費的人而言，整體成本高昂。當價格下降時，這種行為還會自我強化：這是典型的 Jevons 動態，token 變便宜後促使消耗增加，總支出反而仍然上升。

脫離這種狀況的方式不是降低 token 價格，而是提高 CPM（每百萬 tokens 完成的任務數）：用更少 tokens 做同樣的工作。論文提出的管理修正方法是改進測量——每次代理發布審核都要把 CPM 和品質並列，「理由就和晶片設計把每瓦效能與效能並列一樣。」這次替換讓 CPM 從 54.9 升至 92.0（+68%），每美元品質從 3.71 升至 6.75（+82%）。

哪些數值有變化#

面向	基準組	Harness 組	Δ	解讀（論文原文）
品質（任務完成率）	0.78	0.81	+0.03	n = 22 下無差異
每項任務成本	$0.21	$0.12	−41%	明確差異
每項任務實際耗時（中位數）	48 s	27 s	−44%	明確差異
每項任務 tokens	14.2k	8.8k	−38%	明確差異
每美元品質	3.71	6.75	+82%	推導值
每百萬 tokens 完成數	54.9	92.0	+68%	推導值

各模型每項任務成本：Claude Sonnet 4.6 $0.24 → $0.15（−39%）、Gemini 3.1 $0.19 → $0.13（−33%）、Gemini Flash 3.5 $0.18 → $0.07（−61%）、Qwen 3.6 $0.16 → $0.09（−44%）、GLM 5.1 $0.21 → $0.11（−47%）、Palmyra X6 $0.25 → $0.12（−52%）。六個模型、五家供應商、三種權重類別，沒有一個例外——這正是層級效應，而非模型特定行為的特徵。相對收益最大的是快速層（Flash 3.5，成本 −61%、延遲 −55%），符合前述拆解：小型且便宜的模型，其總帳單中 harness 開銷佔比更高，因此移除這些開銷會帶來較大的比例降幅。

論文誠實說明統計上的證據力，這點值得保留：n = 22 時，品質差異只有趨勢，未達顯著；成本、token 數與延遲的差異幅度大，且在全部 22 個提示與六個模型中方向一致，因此在這個樣本數下足以明確判斷；品質差異則不然。論文自己的發布建議拒絕把 +0.03 當作標題——「站得住腳的標題是品質持平時 tokens 減少 38%。」

Harness 槓桿：效率無條件提升，品質則取決於能力#

這是最具可移植性的發現，也與 Harness Shrinkage as Models Improve 最直觀的解讀相反。將各模型在八種評分能力上的平均增益合併後：Palmyra X6 +0.079、Sonnet 4.6 +0.073、Gemini 3.1 +0.050、GLM 5.1 +0.028、Flash 3.5 +0.010、Qwen 3.6 −0.031。以各模型的基準能力繪圖，關係幾乎呈線性，r = 0.99——論文將斜率命名為 harness 槓桿：模型把編排結構轉化為品質的速率。

因此，兩種效益清楚分開。**弱模型搭配 harness，仍可省下 44–61% 成本；但它不會因此變得更好。**效率收益無條件且不受模型影響；品質收益則取決於能力。單一層級帶來兩種作用——harness 單獨決定工作的價格，而它與模型共同決定工作的上限。

回歸案例呈現的是同一發現，只是方向相反。在 48 個「能力 × 模型」組合中：30 個進步、11 個持平、7 個退步——而且七個全都落在三個較小的模型上，其中六個集中在最考驗編排能力的項目（MCP 工具使用：Qwen −0.15、GLM −0.06、Flash −0.04；另外還有 Playbooks 和簡報）。前沿模型與 Palmyra 在同一批類別中進步最多（MCP：Sonnet +0.10、Palmyra +0.10；依據資料能力：Sonnet +0.10、Palmyra +0.12）。強模型能把更豐富的 harness 轉化為品質，弱模型卻會把它感受為負擔。

論文未提及的一項限制。 依照圖表的雙重檢視規則查看 Figure 6，確認了幾乎完美的擬合，但擬合的 x 軸只涵蓋基準能力平均值 0.710 到 0.789——幅度只有八個百分點，涵蓋範圍寬六個百分點。在這段範圍內 r = 0.99 是強烈的局部模式，但不能說明槓桿在範圍外會如何變化；論文承認「六個資料點只能作為提示，不能定論」，卻未指出能力範圍有多窄。

能力門檻#

子代理委派是 harness 唯一真正新增的能力（基準組沒有對應項目）。委派任務的完成率：**Palmyra X6 0.86、Sonnet 4.6 0.85、Gemini 3.1 0.70、GLM 5.1 0.58、Flash 3.5 0.45、Qwen 3.6 0.42。**只有最強的兩個模型達到可用的可靠度門檻。

一般化的結論是：**編排功能有能力門檻，低於門檻時開放功能帶來的是失敗，而非作用。**論文提出兩項可執行的後果：

1. Harness 功能應依模型層級逐步降級——縮小工具目錄、在低於門檻時停用委派——而不是讓所有模型使用同一個介面。
2. 路由應依據功能需求，而非只看提示難度：會用到子代理的要求，無論文字看起來多簡單，都應交給強模型；有資料依據的問答則可交給便宜 61% 的快速層，品質不受影響（所有模型的依據資料能力都有進步）。這是對 Client-Side Agent Optimization 路由脈絡的具體深化。

平均值掩蓋的真實取捨#

以下引用四個代表性提示的正文描述（附錄表格解析有誤，詳見 Sources）：

• Medicare 依據資料，三回合對話：0.60 → 0.90——整組中品質提升最大，歸因於調整檢索方式，只傳送較少且篩選得更好的證據。節省 token 與提升品質的機制是同一個。
• **身分／拒絕：0.90 → 0.90，而成本減半，$0.04 → $0.02。**安全行為的成本減半。
• 合約問答：0.75 → 0.82。
• 多步驟研究綜整——整組最昂貴的任務——成本從 $0.61 降至 $0.33（−46%），但品質從 0.80 降至 0.60。這是一次退步，不是進步。論文稱之為「平均持平掩蓋真實取捨的唯一案例」，歸因於較小的模型，並以此決定發布建議（暫緩開放權重候選模型，待修正後再發布，而非直接推出退步版本）。請記住這個案例：−41%／−38% 的標題數字至少包含一組用品質換便宜的結果。

次要評審的趨勢與主要結果一致（連貫性 0.85 → 0.88、溝通 0.79 → 0.80，兩組的幻覺都沒有變化）。

六種機制#

用一句話說明設計目標：提高 tokens 中快取命中、與決策相關，以及用於已提交且可復原工作的比例——透過結構強制執行，而非依賴模型行為。這是把 Agent Harness Engineering 的「強制不變條件，而非強制實作方式」原則用在帳單上。

1. 快取形狀管理：雙區提示。 位元組穩定的前綴（完整工具結構描述目錄、穩定系統提示、只增不改的持久逐字稿），後接每回合重建的易變尾部（時鐘、檔案清單、計畫狀態、單次提醒、自訂指令）。這項分隔以正確性規則強制執行：每回合會變動的內容在結構上不得放進前綴；快取標記邏輯也會拒絕在第一則易變訊息或其後設定斷點。最多四個供應商斷點，並在每個工作階段鎖定一小時的保留政策，避免執行途中切換政策。在 harness 的程式碼庫中以完全相同的前綴呼叫進行測量：7,886 個提示 tokens 中有 7,876 個（99.9%）以快取讀取方式提供。
2. 結構化、增量式、快取感知壓縮。 當輸入預算達 80% 時，較舊的歷史內容會折疊成具型別的檢查點（記錄決策／限制條件／已拒絕方法的持久記憶；為了可恢復執行而撰寫的八節執行摘要；逐字保留的使用者需求；技能參照）。最近 4–12 則訊息構成的即時尾部（不超過預算的 30%）永遠逐字保留；每個檢查點都會把前一個向前合併，因此壓縮成本保持增量；摘要交由較便宜的輔助模型在付費迴圈之外執行；若摘要為空或品質退化，就會中止壓縮而不予保存。壓縮與快取共同設計——「若每回合都重寫歷史，摘要器便會破壞快取定價所依賴的前綴穩定性。」
3. 移出上下文——模型完全不必支付的 tokens。 把子代理當成上下文防火牆（子代理使用自己的上下文探索，回傳最多 8 KB 的摘要，引用放在父代理不會讀取的中繼資料側車，委派深度有限且在重試時具冪等性）。技能採漸進式揭露（提示中放名稱與描述表；只有呼叫時才從沙箱讀取技能本文）。大型工具輸出會寫入檔案（shell 輸出超過 20K 字元時，在標示禁止模型從預覽推斷成功與否的橫幅下顯示首尾摘要；過大的讀取會被拒絕並附上指引，不會默默截斷）。計畫／畫布狀態採事件來源方式記錄，每回合重新投影一次，也可重新陳述目標以避免目標漂移。媒體有上限（最多 4 張圖片或 2 MB）。檔案系統是無上限的記憶；上下文只保留指標。
4. 零 token 等待。 等待是延續執行，不是迴圈：若執行需要人類回答、核准或長時間背景工作，便會以零 token 成本持久暫停，並在收到觸發事件後恢復。同一持久化層也限制災難性支出——每個事件都會在串流前寫入預寫式日誌；崩潰的執行會透過生成 fencing，從下一個序號恢復。「若崩潰導致一個 40 回合工作遺失，就得再買一次 40 回合的 tokens。」
5. 失敗支出治理。 任何決策之前，先將每種失敗歸類（速率限制、停滯、逾時、串流格式錯誤、供應商中斷、永久性失敗）；只有列入白名單的類別才會轉交下一個供應商。串流中途失敗會成為丟棄的嘗試——清除部分草稿，且不得由遭丟棄的嘗試引發副作用。若模型連續三次重送位元組完全相同且失敗的工具呼叫，斷路器便會停止該模型，並依失敗原因引導修正；迴圈上限為 50 次，工具平行度上限為四。重試、死路與厄運迴圈會放大帳單，單靠 token 折扣無法解決。
6. 模型無關的能力下限。 路由計畫以具型別資料提供——迴圈不會依模型名稱分支——所有供應商串流都會正規化成同一種 chunk 契約，只使用原生工具呼叫路徑，並為較弱模型清理結構描述（內嵌 $ref、修復雙重編碼的 JSON 引數、拆分過載的結構描述）。這也從結構上解釋了為何效果不受模型影響：harness 設定下限，模型決定上限。

貫穿全文的核心是：**token 經濟效益與輸出品質，是一次拉動同一槓桿的兩種結果。**長上下文中若充斥干擾資訊，所有受測前沿模型都會退化；因此，移除過時或龐大的 tokens，既降低帳單，也整理了模型的工作集合——Medicare 依據資料的結果正是這種作用的縮影。

自建還是租用，以及與 OpenHands 的分歧#

harness 效率為何是特殊資產，背後的經濟論點是：模型端最佳化可降低單一模型的成本；路由政策可改善模型組合；**harness 改進能同時降低所有模型的成本，而且只要模型組合改變就能持續發揮作用，因為它建置在模型 API 之上。**它可移植到不同模型，效益隨使用量線性累積，並且可與每 token 價格下降、路由及提示壓縮疊加，而非取代它們。以實測的合併費率計算，每月一百萬項代理任務在基準組要花 $210k，使用 harness 則為 $120k；只靠編排變更，每年就省下 $1.08M。

Writer 由此得出採購結論：「把編排層租來的組織，等於外包自己最能掌控的變數。」

這與 Harness Build-vs-Buy 的建議直接矛盾，這個矛盾值得保留並明確呈現，而不是平均掉：

	Writer（本文，empirical + 完全利益衝突）	OpenHands（Shah，case-study，對供應商有利害關係）
主張	自行掌控編排層；它左右盈虧	租用執行環境，只擁有自己的介面層
證據	受控的 token／成本測量	十二個月的合併 PR 與程式碼行數統計
計算的成本	優良 harness 帶來的收益	維護 harness 的成本
供應商利益	銷售編排平台	銷售有維護服務的代理執行環境

兩者不算完全互斥：Writer 衡量的是優良 harness 能帶來什麼，OpenHands 衡量的是維護它要花多少（每年 5,679–7,736 個合併 PR；維護一年前完整表層分支需處理約 4,600 個 PR 的差異）。兩者都沒有計算自己帳簿的另一面，而且**兩家供應商都在銷售自己得出的結論。**較誠實的綜合解讀是：編排槓桿很大，自己維護也很昂貴；這支持採用客製化階梯，而非走向任何一種極端。

與其他系統的比較，以及這項比較不代表什麼#

論文對其他系統提出的較狹義主張是：*在廣泛使用的代理系統中，沒有任何一個把 token 經濟效益當成一級公開契約。*比較表評估 Claude Code、Claude Cowork、LangGraph、CrewAI、AutoGen/AG2、Hermes Agent 與 Writer 自家 harness 是否支援模型可移植性、結構化快取政策、壓縮契約、隔離式委派、零 token 等待與逐任務核算。逐任務核算是唯一只有 Writer 自家那列打勾的欄位——「若編排層沒有內建逐任務 token 核算，就無從觀測 token maxing；無法觀測的事，就無法管理。」

以下是值得參考的系統描述：

• Claude Code 和 Cowork 被稱為「廣泛部署中最精密的 harness 之一」。Writer 表示，自身設計期間採用了或以它們驗證了數項模式——快取斷點鎖定、位元組穩定前綴、子代理任務拆分。論文明示的差異在部署類型與契約：單一使用者、用戶端、綁定單一模型供應商，而且 token 管理並未以逐任務核算介面的形式公開。「它們替個人最佳化單一工作階段；企業執行環境則必須為整個代理群計量。」
• 編排函式庫（LangGraph）提供基本元件，並刻意把快取政策、壓縮、移出上下文與失敗支出治理留給應用程式處理——因此 token 經濟效益成了應用團隊未編列預算的責任。
• 共用逐字稿的多代理架構（CrewAI、AutoGen 系列）被稱為「天生就是 token 放大器」：每個參與的代理都會重新讀取不斷增長的對話，並帶有自己的角色前置提示。引述的測量來自 Anthropic 自家研究——代理約消耗聊天情境 4 倍 tokens，多代理系統約 15 倍；在其研究評估中，token 量約能解釋 80% 的效能變異。這是把 token maxing 寫進架構；花這筆成本可能值得，但這些框架都不會逐項任務計量放大倍數。請見 Parallel Agent Orchestration。
• Hermes Agent 獲肯定為真正不受模型限制，且具備隔離子代理；但設計階段的來源研究發現，它沒有將工具結構描述放進快取前綴，因此在輸入占主導的工作負載中，放棄了最大的一項折扣。

論文自己說明的認知證據狀態，值得再次大聲提醒：此表比較的是公開設計與文件，以及設計階段來源研究。它沒有跨 harness 測量。這是設計比較，不是基準測試，而且是供應商對競爭對手文件所作的解讀。

生產環境的對照案例：三種已推出的 harness，由外部進行測量#

前一節指出的資料缺口，首次獲得部分補足；執行研究的一方沒有自己的 harness 參與測試。Databricks 的報告透過 The Register 發布（Thomas Claburn，2026-07-13，case-study，二手報導，內容來自 Databricks 自家的基準測試部落格與 CTO Matei Zaharia 的社群貼文）。這項內部程式設計基準測試取材自員工在數百萬行程式碼庫上實際執行過的工程任務，橫跨多個模型，並比較三種當代生產 harness——Claude Code、OpenAI Codex，以及 Pi coding agent；後者「以系統提示精簡著稱」。

本文拆解中，逐項任務的上下文是關鍵輸入項；以下是不同 harness 的比較：

組別	Harness	每項任務上下文	比例
Opus 4.8	Claude Code	742,000 tokens	Pi 的 3.13 倍（文章說「約 3.2 倍」）
Opus 4.8	Pi	236,999 tokens	—
（未說明模型）	Codex	1,235,000 tokens	Pi 的 1.86 倍
（相同組別）	Pi	665,000 tokens	—

Zaharia 的總結是：*「Harness 對成本效益影響很大。非常精簡的 Pi harness 用 Opus 和 GPT 5.5，成功率和 LLM 供應商的 harness 相同，但成本低了兩倍！」*他明確將差異歸因於「每回合傳給模型的輸入量——上下文」。

這些結果佐證了什麼，又沒有佐證什麼。它們佐證了趨勢方向與作用機制，並非具體幅度。只改變編排層便能以一半成本達到相同成功率，正是論文標題結論由獨立研究重現；而且測試是在面對數百萬行真實程式碼庫的長期程式設計工作負載上進行，這正是論文在效度威脅清單中不納入的範圍（「長期程式設計基準的結果可能不同」）。關鍵是，三種 harness 都不是由測量方刻意淘汰的舊基準，因此下文所述的稻草人基準威脅不適用於此。但這不是受控測量：沒有任務數、變異程度、逐組品質表或快取命中率，而且 wiki 讀到的是 The Register，而非 Databricks 報告。

有三點值得在佐證結果之外繼續追蹤：

• 上下文差距大於成本差距（3.13 倍相較於「兩倍」）。文章沒有解釋差異，兩個主張也來自不同組別；不過，這正是本頁 p_eff = p_in(1 − h(1 − κ)) 所預測的差距：快取輸入的帳單約為一般輸入的十分之一，因此若 harness 增加的 tokens 位於位元組穩定的前綴，其實際付費遠低於原始 token 數所暗示的金額。Databricks 和 The Register 都沒有報告 h，所以現有數字看不出這項因素。在如此精確的比較下，token 數和帳單不能互換——請見 Prompt-Cache Economics。
• **「每項任務的 harness 上下文」是「模型 × harness」的量，而非 harness 固定值。**在 Opus 4.8 比較中，Pi 使用 236,999 tokens；在 Codex 比較中則為 665,000——同一個精簡 harness，相差約 2.8 倍，因為驅動它的模型變了。這與本頁在品質軸上發現的交互作用（harness 槓桿）相呼應，在 token 軸上也出現了。因此，不指出模型，就無法比較 harness 的成本。
• **利益關係也應揭露。**Zaharia 表示，這些結果促使 Databricks 開發 Omnigent，「一款用來整合及切換多個程式設計代理的包裝器」。所以，宣稱 harness 選擇能讓成本相差兩倍的一方，也推出了一款產品，其核心主張正是 harness 選擇會影響成本，而且應該可以切換。這項利益衝突明顯弱於 Writer 的情況——比較中沒有 Databricks 自家的 harness，勝出者是第三方的精簡代理——但也不能說完全沒有利害關係。

該相信多少#

論文自行列出的效度威脅異常完整，而且每一項都會影響結論：

• n = 22 足以觀察到方向一致且幅度大的效率差異，卻不足以推論品質差異。
• 基準組只以凍結設定執行一次——執行於 2026-06-07；未測量基準組在不同執行間的變異。
• 依賴評審——任務完成率由 LLM 評審，鎖定的評分條件與次要評審降低了偏差，但無法消除。
• 依賴價格表——美元數字來自固定的一份公開價格表；token 數與延遲結果不受價格影響，且呈現相同趨勢，這才是正確的解讀方式。
• 工作負載形態——這是企業助理工作負載（依據資料、工作流程、工具、內容）；長期程式設計基準的結果可能不同。
• 六個資料點用來估算 harness 槓桿相關性，且能力範圍狹窄（見上文）。
• 只有一組比較——單一供應商提供的一個基準迴圈和一個 harness。架構主張具有一般性，實測幅度則不然。

再加上論文未列出的限制：**無法由外部排除基準組是稻草人的風險。**每回合重播 49 KB 系統提示、用 regex 解析 XML 工具呼叫並破壞性截斷，確實是團隊會推出的做法；Writer 也說這是自家的生產迴圈。但「打敗我們早已決定要替換的東西」，比「打敗現今水準合格的 harness」弱得多；本研究只證明了前者。

延伸閱讀#

• Cost-per-Task Over Cost-per-Token——本文最直接重新詮釋的頁面。該文討論該選擇哪個模型；本文衡量模型之上的層級，並發現影響更大：harness 替換讓每個模型省下 33–61%，而整個模型選單的價差是 36%。本文也同時為六個模型補上欠缺的 token 軸資料——固定價格表下各模型的成本、tokens 與延遲；與各模型的品質平均值對照後，也指出在這項工作負載中，最先求穩的預設方向應當相反。上文 Databricks 基準測試中的模型面向資料也收錄於該頁——Sonnet 5 的每項任務成本高於 Opus 4.8，儘管 tokens 便宜；GLM 5.2 則以 $1.28 達到相同品質——其每美元品質排序又與 Writer 的結論相反，形成兩項基準測試目前的直接矛盾
• Agent Harness Engineering——機制清單就是該頁模式的成本版本；六種機制家族是把「強制不變條件，而非強制實作方式」用在 token 帳單，而非程式碼結構
• Agent-Authored Harness Optimization——手工打造與機器演化的區別，也說明為何本文不能推論為「讓代理建構 harness」。本文測量的都是由團隊設計的編排層；若改由元代理依基準回饋推導 harness，預算匹配的基準測試（Wang 等人，arXiv 2607.12227，empirical）發現，這種方法在 Terminal-Bench 2.1 上輸給單純平行取樣，但在保留任務上提升 +0.6pp。槓桿很大，自動搜尋卻無法回本其所耗的運算資源——兩個主張可以並存，不應混為一談
• Harness-Induced Belief Divergence——語料中的第三次受控 harness 替換，也是第三種結果變數。設計形式相同（模型固定，只改變上層）；本文改變的是帳單，Measuring Beyond Accuracy Saturation 改變的是準確率，Yi 與 Song 衡量的則是代理的信念——在動作受阻、修復內容壓縮、選擇性驗證及成本感知裁剪下，對失敗歸因、風險狀態與下一步行動建議都出現可測量的差異。值得注意的是，其中的成本感知 harness 把本文機制推向相反方向：預算吃緊時略過昂貴檢查，正是 token 經濟效益論點所建議的效率作法；但它是五種受測介面中，會改變代理信念的其中一種。各方面證據都較弱——8 項自行設計的任務、3 個隨機種子、未具名基礎模型，而且「終端成功率維持不變」的說法從未測量——但研究者沒有利害關係；相較之下，本文由供應商撰寫且存在完整利益衝突
• Prompt-Cache Economics——同一套有效輸入價格計算，由獨立第三方測量，而非 harness 供應商自行提出。Writer 的 p_eff = p_in(1 − h(1−κ)) 假設快取如價格卡所述運作；CAPC 測量真實快取，發現 ρ ≈ 0.83–0.89，且在約 3,500 tokens 處有一道門檻，並指出即使是位元組完全相同的小型前綴也可能沒有命中。99.9% 快取讀取率是 Writer 自家程式碼庫中的單次相同前綴呼叫；這是最佳案例，不是穩態表現
• Harness Build-vs-Buy——上文直接指出的分歧：自行掌控編排（Writer 衡量收益）或租用執行環境（OpenHands 衡量維護成本）。雙方都與供應商利益相關，也都只衡量自己帳簿的一面
• Harness Shrinkage as Models Improve——與本文相反的趨勢。harness 槓桿表示，模型越強，越能從更豐富的 harness 提取品質（r = 0.99，最弱模型的淨效益為負）；子代理能力門檻則表示，先進編排功能必須搭配夠強的模型才值得開放。這和「模型愈進步，harness 愈消失」的論點不符，方向更接近相反。兩者可以相容——前者測量的是補償弱點的提示鷹架是否縮減；本文測量的是模型無法自行完成的結構性機制（快取、壓縮、移出上下文、失敗分類）——但這項區別是縮減論點先前不必釐清的實質差異
• Client-Side Agent Optimization——讓路由更精細：依據功能需求路由，而不只看提示難度，因為編排功能有能力門檻。也清楚陳述了兩者的互補關係——「路由決定由哪個模型支付帳單；harness 決定無論選了哪個模型，帳單有多大」
• Production-Sourced Evaluation——說明上述生產實例何以能比較harness：Databricks 以自家工程師在自家程式碼庫上的工作作為任務，因此評估得以改變編排層，而公開程式設計基準無法做到。由買方自行建立評估，是跨 harness 成本測量的先決條件，不只是避免基準調校的防線
• Measuring Beyond Accuracy Saturation——經濟面向的對偶，也是方法上最接近的研究：該研究固定模型、替換鷹架，發現準確率約有 44 個百分點的變化；本文固定模型、替換編排，發現成本變化 41%。兩者由不同團隊測量不同結果變數，共同呈現「harness 並非中立底層」的兩個面向
• Context Lifecycle Management——把壓縮契約作為已推出的產品，而非研究系統：具型別檢查點、受保護的逐字即時尾部、增量向前合併、摘要退化時中止，以及與前綴快取明確共同設計。Self-GC 為上下文編輯在何時值得犧牲快取命中定價；本文則描述一種 harness，透過提示結構讓這個問題很少出現。該頁也包含本文只提出主張、未推導的二次項公式：Maximem 的 ACM 論文（arXiv 2607.21503，empirical，單一作者，且與 Writer 一樣有完全供應商利益衝突）推導出 C_append = t·n(n+1)/2，成本倍數 t(n+1)/2W 隨 n 線性成長；100 回合時為 6.3 倍，500 回合時為 31.3 倍。它也補上雙區／向前合併設計暗中依賴、卻未明說的部分：每次壓縮都處理已有限定大小的上下文，所以壓縮次數線性成長，總成本為 N·W·(1 + c/p)，是固定開銷比例，不會隨對話長度增加而加重。兩篇供應商論文獨立推導出相同算式，且都沒有拿對方的基準做測量
• Parallel Agent Orchestration——子代理有兩種定價方式：代理共用逐字稿時，會成為 token 放大器（依 Anthropic 自家數字約 15 倍）；子代理上下文範圍受限、只回傳上限摘要時，則成為上下文防火牆。本文的委派契約——摘要上限 8 KB、引用放在父代理不會讀取的側車、深度限制、重試時具冪等性——具體落實了「委派探索不應增加父迴圈負擔」
• Tool-Output Pruning——在模型呼叫內部採取同一目標，而非在呼叫周圍處理。該論文主張跨呼叫結構能帶來更大節省：在「模型和提示都不變」的情況下減少 38% tokens
• Claude Code、Cowork、Hermes Agent——景觀比較中列出的 harness，根據公開文件與設計階段來源研究整理，並無實測
• Anthropic——兩度作為論文的外部證據來源：代理與多代理約 4 倍／15 倍的 token 放大，以及有效輸入價格模型所依據的提示快取價目表
• GLM (Z.AI)——兩個開放權重候選模型之一，也是三個出現退步的模型之一
• Standardize the Infrastructure, Not the Tools——組織針對此發現的結構性回應：若帳單由 harness 而非模型決定，就應標準化 gateway，讓模型可替換、工具選擇保有彈性

尚待解答的問題#

• 對比能力合格的第三方基準時，效果是否仍然成立，而不是只勝過供應商自家凍結的迴圈？此處所有幅度都來自同一家公司的一個 harness 與一個刻意淘汰的前代版本。論文指出，按設定比較不同 harness 的 token 面向是自然的後續研究；這能區分「優良 harness」和「不佳基準」。**部分解答（2026-08-04）：**Databricks 內部程式設計基準比較三種已推出的第三方 harness——Claude Code、Codex、Pi——並固定模型，報告精簡 harness 在 Opus 4.8 上以「成本低兩倍」達到相同成功率，逐項任務上下文量相差 3.13 倍。沒有任何一組是遭淘汰的舊基準，因此不存在稻草人風險。但它是二手報導，沒有任務數、變異程度或逐組品質表；harness 比較測量的是上下文而非帳單成本。因此，第三方測試支持了相同方向，按設定比較不同 harness 的 token 測量在語料中仍不存在。
• harness 槓桿在擬合所用的狹窄範圍外是否仍成立？六個模型的基準能力平均值介於 0.710–0.789，r = 0.99；有趣的問題是，在前沿能力上，斜率會趨平、變陡還是反轉？此時 harness 面對的模型愈來愈能自行執行編排工作。
• 在長期程式設計工作負載上，「編排比選模型更能影響成本」的排序是否仍成立？任務集仿照企業助理（依據資料、工作流程、工具、內容），論文也承認在 SWE-bench 級別的工作上結果可能不同；那裡的回合數高得多，理論上二次歷史項應讓 harness 更有利，而非更不利。**部分解答（2026-08-04）：**Databricks 基準測試涵蓋這類工作——在數百萬行程式碼庫上執行真實工程任務——趨勢方向一致：成功率相同時，harness 選擇讓成本約差兩倍；同一篇報導中的模型選單則顯示每項任務成本介於 $1.28–$2.09（約 1.6 倍）。兩個差距並非在相同條件下測量：The Register 未說明每項任務的美元數據採用了哪個 harness；而每項任務上下文數據來自與兩倍成本主張不同的兩組比較。這是佐證，而非重現。

資料來源#

• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI — Muayad Sayed Ali、Aliaksandra Novik、Anji Boddupally 等人（33 位作者全來自 Writer, Inc.；末位作者 Waseem AlShikh 是共同創辦人兼 CTO），The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI，arXiv 2607.06906，2026-07-08，empirical。§3（逐項任務成本拆解、二次重播項、快取下的有效輸入價格模型、token maxing 定義 1、複利論證）；§4.1–4.2（harness 負責的範圍；凍結基準的五項設計決策）；§4.3（六類機制、7,876/7,886 快取讀取測量、壓縮門檻、移出上下文上限、失敗分類與斷路器限制）；§4.4 + Table 1（代理系統設計比較，明確說明不是基準測試）；§5（成對替換設計、22 個鎖定提示任務集、六個模型、指標定義、n = 22 的統計證據力）；§6 + Tables 3–6（持平計分卡、各模型效率、子代理委派、完整的「能力 × 模型」矩陣）；§6.6 正文（四個代表性提示，包括多步驟研究退步案例）；§7（harness 作為定價者、整體經濟效益、把 CPM 納入發布審核的提案、依功能需求路由、發布立場）；§8（效度威脅）；Disclosure。依照圖表的雙重檢視規則查看 Figure 6——確認 harness 槓桿近似線性擬合，並揭示 x 軸的基準能力僅介於 0.710–0.789，正文未提及此事。 **解析警告。**由 Docling 解析，21 頁／7 個表格。Table 2（受評模型）儲存格合併錯誤——供應商、類別與角色欄各把六個值串接在同一儲存格；Table 7（附錄 B 代表性提示）列位錯移，將「增益最大；調整檢索方式」與「持平；成本 $0.04 → $0.02（−50%）」說明合併在同一儲存格，其他說明則往下錯置一列。自動合併／錯移檢查都未發現這兩個問題。本文未引用兩表的任何列：模型名單來自摘要與 §5.3 正文，所有代表性提示數值來自 §6.6 正文。Tables 1、3、4、5、6 已與正文核對，沒有問題。另 arXiv 摘要頁作者中繼資料漏掉 Brock Perry；以 PDF 署名（33 位作者）為準。
• The price is wrong: AI cost calculation has to consider task completion rates, not just token costs — Thomas Claburn，「The price is wrong」，The Register，2026-07-13，case-study，且屬於二手報導：Databricks 內部程式設計基準測試由新聞文章轉述，並引用公司部落格文章及 CTO Matei Zaharia 的社群貼文。wiki 尚未閱讀原始來源（databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase）。本文只用它比較 harness——Claude Code 742,000／Pi 236,999，以及 Codex 1,235,000／Pi 665,000 的逐項任務上下文數值、「成功率相同……成本低兩倍」引言、將差異歸因於每回合輸入量，以及 Omnigent 利益揭露。正文 644 字且沒有表格，因此不受表格解析問題影響；需注意的是，WebFetch 擷取時漏掉兩個數字，後續以 curl 下載的 HTML 重建正文（被漏掉的數字已在 Cost-per-Task Over Cost-per-Token 引用，此處未引用）。