針對程式代理的 harness 設計之實證研究

執行摘要

程式代理的表現並非僅由底層的大語言模型（LLM）決定，而是由模型與其「harness」（即包裝模型的規劃、動作空間與情境管理系統）之間的互動所決定。研究顯示，並不存在普遍適用的「最佳」harness；相反地，最佳配置取決於模型的原生能力、特定任務類型以及可用的資源預算。

情境管理的角色

當情境視窗預算緊繃時，情境管理尤為關鍵。其主要價值在於防止情境溢出失敗，使代理能在不根本改變行為的情況下維持更長的執行軌跡。

關於情境管理的重要發現包括：

• 預算敏感性： 當情境視窗較小時，情境管理的效益最為顯著。例如，在 32k 視窗下，已管理與未管理情境之間的成功率差距可高達 35.7 點，但在 128k 視窗下則降至 2.7 點。
• 最佳策略： 在 LLM 基於的摘要之前，先以規則式方式剔除（elision）不必要的內容，能提供最高的整體效率。
• 可恢復性： 增加使被剔除內容可恢復的機制，並未帶來準確性提升，因為模型很少使用這些功能。

規劃作為支撐結構 vs. 成本節省工具

隨著模型能力的提升，規劃組件的效用會發生變化。對於較弱的模型，規劃作為提升準確性的支撐結構，可防止其過早放棄任務。對於較強的模型，規劃主要作為成本節省工具，透過減少重複驗證步驟來降低開銷，對最終準確性影響極小。

此趨勢在產業實務中亦有體現；例如，部分新興的前沿模型已移除內建的任務追蹤工具（如 TaskCreate 或 TodoWrite），因為模型的原生推理能力已大幅降低對明確會話中規劃工具的需求。

動作空間與工具使用熟練度

在預設結構化工具與純 bash 接口之間的選擇，取決於模型對 shell 命令的熟練程度。

• 具備 bash 能力的模型： 擁有高 bash 熟練度的模型，使用純 bash 接口時運作更有效率且成本更低。這在以命令列為中心的任務中尤為明顯，因為它允許模型將多個程式碼修改合併為單一工具呼叫。
• 較弱的模型： 對於缺乏強大 bash 控制能力的模型，預設工具能提升成功率，提供必要的結構以彌補模型在 shell 熟練度上的不足。

結論：harness 設計為條件性系統問題

本研究結論認為，harness 設計應視為條件性系統問題。開發者不應採用預設的一組組件，而應根據目標模型、任務類型與資源預算來選擇組件。

社群見解的整合

產業實務者與研究人員強調了這些發現的若干細節：

"如果車輛 A 表現較佳……這不一定是因為引擎。也可能是因為更好的輪胎、更好的變速箱、更輕的車身……你的 harness 可以適應底層模型的原生能力，或彌補其缺失。"

部分批評者指出，研究聚焦於 Nemotron 和 Mistral 模型，而非 Claude、GPT 或 DeepSeek 等供應商的當前前沿模型。然而，其他人則認為，關於情境視窗與管理策略之間關係的發現，仍高度適用於實際使用模式，例如透過檢查點（checkpointing）會話來降低 API 成本。