事實
AI 代理 · 治理 · 軟體工程 · 效能評測 · 研究簡報論文為 2026 年 8 月 20 日 · 套件查驗版本 0.2.72，8 月 28 日
arXiv:2608.20622 · 一份提案，及其所指名的套件
harness 已上架，治理層還沒
2026 年 8 月 20 日，George Salapa 於 arXiv 發表一份 21 頁的架構提案：讓大型企業採用單一的程式碼代理 harness（暫譯：代理外殼），在各種介面之後原封不動地執行，整支解決方案隊伍便可受稽核——因為審查一項解決方案不再是讀程式碼，而是讀一份指示檔。論文指名了自己的參考實作，那是一個實際存在、已發布 83 個版本的 Python 套件。本篇所做的，就是把那個套件讀過一遍。論文所述的 harness 確實在裡面，且細節相符；其治理論證所倚賴的四項服務則不在——而其授權條款禁止 fork（暫譯：分叉複製），偏偏整套部署模式正繫於此。
數據 每一項均取自任何人皆可取得的紀錄：arXiv API、PyPI API，以及套件本身的原始碼發布檔
- 83論文用以揭露的那一個網址，其背後的發布版本數。論文未指名任何一個
- 0
risky出現在已發布套件中的次數——論文整套風險機制正繫於這個旗標 - 8/8可解析的 arXiv 參考文獻，各作者名單皆與紀錄逐一相符且順序無誤——其中一筆長達 42 人
- 0論文中的基準測試數目，論文自陳如此：「這些主張並無基準測試佐證」
紀錄與其確認程度 依成立程度排序，而非依其可觀之處
| 確認程度 | 事項 | 查證方式 |
|---|---|---|
| 已確認 | 一份 21 頁的架構提案於 2026 年 8 月 20 日 23:44 UTC 投稿 arXiv，分類為 cs.AI 與 cs.SE，單一作者，九筆參考文獻、三張圖 | arXiv API 紀錄與摘要頁面均與文件相符 |
| 已確認 | 八筆 arXiv 參考文獻皆存在，參考文獻區的每份作者名單均與紀錄完全相符且順序無誤——包括一筆 42 位作者者 | 各識別碼逐一向 arXiv API 查詢，並逐名比對 |
| 已確認 | 論文指名的參考實作真實且仍在更新：自 2026 年 4 月 5 日至 8 月 28 日共 83 個版本，發布檔內含 Python 原始碼 | 先取 PyPI JSON 紀錄，再下載原始碼發布檔並列出內容 |
| 已確認 | 其授權允許為內部業務用途安裝並執行，但未經書面許可，禁止複製、修改、fork、反編譯、逆向工程或製作衍生著作 | 發布檔內的 LICENSE 檔；PyPI 分類標示為 License :: Other/Proprietary License |
| 已確認 | 論文未指明版本。此前已有 69 個版本，此後又有 14 個，故其所引網址從未兩次指向同一內容 | 全部 83 個版本的上傳時間戳，以論文投稿時間為界切分 |
| 已確認 | 套件中完全未見治理層的名目：risky、gateway、entitlement、config.yaml、live_skills 各出現零次 | 對全部 231 個檔案進行不分大小寫搜尋。registry 的 20 次命中屬模型別名登錄，並非同一回事 |
| 已確認 | 套件實際實作的核可關卡，是依工具名稱觸發，取自一組固定集合——預設為 {"bash_", "edit_", "write_"} | 見於 claude_loop_.py，該關卡即一次名稱是否屬於集合的判斷 |
| 已確認 | 在無人值守模式下——正是論文排程骨幹論證所倚賴的介面——該集合為空，因此完全沒有任何關卡 | 無介面與批次兩個進入點皆傳入空集合，其程式碼註解亦自陳「無核可關卡」 |
| 未公開 | 架構所本的專案。涵蓋汽車、製造、快速消費品與醫療的歐洲企業，並於 Azure 環境中評估 | 任何人皆無從查證。論文明白表示，個別客戶或雇主專案不予具名或描述，並請以架構本身受評 |
| 推測 | 提案與已發布產物之間的落差，恰恰就是治理層 | 本報告的解讀。這只是對某個套件中出現哪些字串的觀察，並未論及未公開者為何 |
| 推測 | 本論文與五日後發表的實證研究，其分歧或許在於模型層級，而非結構定義 | 同樣是本報告的解讀。兩篇論文皆未如此表述，也未各自測試對方的條件 |
時序
先有領域，再有提案，隨後便有對它的檢驗 每一列皆為發表或發布日期，且全數公開可查
- 2026 年 3 月 24 日Anthropic 發表自家的 harness 設計成果，最終採用固定的三代理架構：規劃者、生成者、評估者
- 2026 年 3 月 31 日〈Terminal Agents Suffice for Enterprise Automation〉發表——終端機加檔案系統的代理，以極小的成本達到或勝過更複雜的架構。8 月 5 日修訂至第三版
- 2026 年 4 月 5 日論文日後所指名的 harness，其 0.1.0 版登上 PyPI，早於論文四個半月
- 2026 年 4 月 10 日〈Can Coding Agents Be General Agents?〉以開放核心 ERP 系統測試一個代理：簡單任務可靠，複雜任務則以四種典型方式失敗
- 2026 年 4 月 14 日〈Dive into Claude Code〉比較三套 harness，發現各自對相同的設計問題給出不同答案
- 2026 年 5 月 7 日〈Stop Comparing LLM Agents Without Disclosing the Harness〉以立場論文的形式主張：在能力相當的模型之間、於長程任務上，harness 設定的影響可勝過模型選擇
- 2026 年 5 月 11 日〈Beyond Autonomy〉主張代理框架偏重自主性而輕忽可治理性，並提出依風險分級的審查機制
- 2026 年 5 月 13 日一項關於演算法發現的 harness 研究指出：在固定的 token 預算下，數量較少但思考較深的演算法，得分高於數量多而淺者
- 2026 年 5 月 18 日〈Code as Agent Harness〉為一份 42 位作者的綜述，列出六項開放課題，其中包括安全關鍵行動的人為監督
- 2026 年 6 月 12 日HarnessX 提出相反的結構主張——harness 應由自身的執行軌跡演化，而非保持靜態——並回報在五項基準上平均提升 14.5%
- 2026 年 7 月 28 日SHarD 自安全角度得出相同論旨：應建置並散布的單位，是一個強固化的 harness，集中打造一次，各處原封不動地執行
- 2026 年 8 月 18 日harness 的 0.2.58 版發布。此為第 69 個版本，也是論文發表前的最後一個
- 2026 年 8 月 20 日論文於 23:44 UTC 投稿，指名該套件為其參考實作，並以此指名作為自身的揭露
- 2026 年 8 月 25 日五日後，一項實證研究恰以此類包裹方式進行量測，結果好壞參半——四個模型-任務組合中，一個變好、兩個變差
- 2026 年 8 月 28 日0.2.72 版發布——第 83 個版本，亦即本報告所查驗者
全然無日期可考者 僅一項，而四項機制正是由它論出
那些專案。論文表示，此架構係由歐洲大型企業中的工作所啟發，涵蓋汽車、製造、快速消費品與醫療；並表示個別客戶或雇主專案不予具名或描述。論文舉了三個實例——在營運系統中對某筆紀錄套用政策規則、對照 CRM 分流進件請求，以及某製造業客戶把供應商的符合性證明與材料規範相比對——三者皆無日期、無名稱、無量測結果。對任何撰寫客戶工作的人而言，這是站得住腳的立場，而且它是明說而非藏起的，這一點才是關鍵。但這也意味著：四項機制背後的實地證據，無法放進上面的時序，任何人也都無從查證。
- 3個實例，皆無日期、無客戶名稱、無量測結果
- 4個產業獲點名，皆位於歐洲，且皆於單一雲端的身分與政策原語上評估
論點
主張，及其樞紐所在 先以論文自身的用語陳述，再循其所指方向追下去
論文的貢獻濃縮為一句話，而且是好句子：「當每一項解決方案共用同一份程式碼，稽核 N 項解決方案便簡化為審閱 N 份指示檔。」過去客製程式碼之所以需要事前的核准關卡，是因為回頭審視它的代價高昂；若各團隊出貨的是同一具引擎，差異僅在兩個文字檔，那份代價便消失了，關卡存在的理由也隨之消失。登錄成為推送程式碼的附帶結果，而非團隊苦候的委員會。這是一個真切且陳述得宜的論證。
但它繫於一個論文未曾點名的樞紐。稽核 N 項解決方案之所以能簡化為 N 份文字檔，前提是已有人審閱過那份共用程式碼。整筆節省正是向那次審閱借來的，而論文從未說明由誰執行、多久一次、對照什麼標準。它所引的文獻只會讓這一點更尖銳而非更緩和：它所倚重的那篇立場論文主張，決定行為的是 harness 而非模型——正因如此，一具無人讀過、墊在所有解決方案之下的 harness，是比 N 具讀過者更大的未知數，而非更小。
就其所指名的實作而言，這樣的審閱受到法律限制。其授權允許為內部業務用途安裝並執行套件，但未經書面許可，禁止修改、fork、反編譯、逆向工程或製作衍生著作。Python 原始碼確實隨發布檔一同附上，因此這道障礙屬法律而非技術——但對相依套件做安全審查，通常正是以逆向工程收尾，而此處它被明白列為禁止。這些都不使該架構為錯。論文他處自陳，開源的 harness 實作已然存在且值得直接研讀，故其設計本身並不要求封閉的實作。張力在於產物，不在於構想。
- 83個版本藏在那個作為揭露的網址背後，論文一個也未指名
- 0已發布原始碼中提及
gateway或entitlement的次數
三項發現，及其所引摘要的實際說法 誇大之處出在論文自身對該領域的摘述；其相關研究一節則三項皆陳述無誤
| 摘述所稱 | 所引摘要的說法 | 評斷 |
|---|---|---|
| harness 在任務層級已足夠，且在企業工作上勝過更精巧的架構——引兩篇文獻為據 | 第一篇說終端機代理「達到或勝過」更複雜的架構，且「成本僅為其零頭」。第二篇根本未做任何架構比較：它回報的是簡單任務成功、複雜任務以四種典型方式失敗 | 半數成立。第一筆引用可支撐，但少了「達到或」，也少了成本結果——而成本正是該論文發現中較強的一半。第二筆則無法支撐 |
| harness 的選擇解釋了代理基準測試結果中大部分的變異，超過模型的選擇——相關研究一節更稱該文「確立」了此點 | 該文開篇即為「本立場論文主張」。其主張限於長程任務、且限於能力相當的前沿模型之間，用語則是 harness 造成的變異「可顯著超過」模型造成的變異 | 刪去了兩項限定條件；而立場論文並非能「確立」發現的東西 |
| 該發現與企業採用之間的空缺在於治理——引兩篇文獻為據 | 第一篇正是談可治理性，可資支撐。第二篇則是一份綜述，列出六項開放課題，安全關鍵行動的人為監督僅為其一 | 大致公允，略有延伸。六項清單中的一項，並非該清單所指認的空缺 |
已被描述、卻未隨套件出貨的機制 以及確實出貨的那一個——它正是論文所反對的設計
論文的風險機制精確而少見。每一次工具呼叫都帶有 {params, risky}；模型依其剛構造出的參數來設定 risky；若省略，該呼叫在抵達任何後端之前即遭拒絕。論文一再強調此即重點所在：風險以單次呼叫為範圍、由模型自行宣告，「絕非由上而下附著於某工具或某工具群組的靜態層級」。被標記的呼叫接著會生成同一個 harness 的全新實例來加以裁決，如此構造該呼叫的脈絡便不會是評判它的脈絡；唯有裁決者無法放行時，才會請人介入。
以不分大小寫搜尋，risky 一詞在已發布套件的 231 個檔案中出現零次。gateway、entitlement、config.yaml 與 live_skills 亦然。套件實際實作的，是一道以工具名稱為鍵的核可關卡，比對使用者自行設定的集合，預設為 shell、編輯與寫入——正是一個由上而下附著於工具的靜態層級。而在無介面與批次兩個進入點，也就是論文排程論證所倚賴的無人值守介面，該集合以空集合傳入，程式碼註解亦直言不諱。
這並不構成對論文的反駁，若如此呈現便是不誠實。該架構刻意把授權放在 harness 之外，而該套件所描述的正是 harness。它真正顯示的是界線落在何處：讀者所能安裝並查驗的一切，都屬 harness 那一半，而那一半本非新意所在。治理論證所倚賴的四項服務——閘道、解決方案登錄、權限對應、執行觸發端點——僅以散文與短程式片段的形式存在。論文的討論一節列出五項限制，且每一項都坦率。這一項不在其中。
- 231個檔案受檢，其中 101 個為 Python 原始碼，皆未出現該字
- 5項限制由論文列出並承認。此項不在其中
補充
另外四項研究，及其各自的落點 四者之中有三項不在論文的參考文獻之列；其中一項晚於論文五日
2026 年 8 月 25 日 · 未被引用
五日後發表的對照研究
- 以確定性層包裹代理，在四個模型-任務組合中，一個提升了再現性、兩個反而降低、第四個毫無作用
- 軌跡層級的診斷指出：一旦工具序列與狀態序列已趨一致，無約束的自由文字規劃步驟便成為變異的主要來源
- 其對策是在任何工具執行之前，先依固定結構定義驗證計畫——而這正是本論文所稱的淨負面作法，該文主張參數應保持開放
- 但有個實在的但書：該研究所用為 7B 與 27B 的開放權重模型，任務亦為合成；而本論文整個賭注押在前沿能力上。兩者皆未測試對方的條件，故這或許是關於模型層級而非關於結構定義的分歧——此一解讀兩篇論文皆未提出
2026 年 6 月 12 日 · 未被引用
相反的結構賭注
- 其批評在於：harness「大體上仍是手工打造且靜態的」，而執行所產生的軌跡鮮少被回饋以改進之
- 其回報在五項基準上平均提升 14.5%，最高達 44.0%，且基準線最弱之處增益最大
- 這與本論文的核心作法形成直接取捨。單一 harness、各處一致，正是使整支隊伍可受稽核之所在；而依部署逐一調整，才是換取效能之道
- 兩者可同時成立。只是論文並未點出這項取捨，而衡量此架構的讀者應當點出
2026 年 7 月 28 日 · 已引用
它所認同的安全論文，及其未承接的兩項控制
- 它列出可散布的 harness 所能承載的三項控制：作業系統沙箱、技能掃描、工具限制
- 本論文承接了第三項，且明白說出。其討論一節亦承認：容器所提供的保證，較 SHarD 所測試的沙箱粗糙；而技能掃描則全無對應機制
- 它更進一步，而這是整節討論中最有用的一項承認：每次執行都即時抓取的技能，只會擴大而非縮小那道缺口——因為沒有重建步驟可供插入掃描，也沒有映像檔可與已知良好者比對差異
2026 年 3 月 24 日 · 未被引用
Anthropic 自家的 harness 研究把圖固定下來
- 論文的第二項設計決定是：不存在於設計時即固定的圖；單一實例反覆呼叫模型，並在執行時自行組成其編排
- Anthropic 於 2026 年 3 月發表的 harness 研究得出相反結論：一個事先決定的三代理結構，並將數小時的自主執行歸功於它
- 兩者並非直截了當地對立。論文中的裁決者正是一個評估者，依被標記的呼叫逐次生成；論文亦公開建立於 Anthropic 2025 年的多代理紀錄之上，且引用無誤
- 話雖如此，一篇以「應用某實驗室的原語」為題的論文，所作的結構選擇卻不見於該實驗室自身已發表的 harness 研究
結論
何者成立、何者仍屬提案、何者宜寬鬆看待 沒有基準測試的論文，並非沒有證據的論文——但證據得如實指認其為何物
確實成立之處，且多於一般水準
引用紀錄乾淨。八筆 arXiv 參考文獻全數可解析，每份作者名單皆與紀錄逐一相符且順序無誤，其中一筆長達 42 人——這在單一作者的預印本中並非常態。參考實作真實、仍在更新，且在讀者可查驗的細節上與論文相符：追蹤每個衍生子程序的狀態檔、彼此之間的通訊端或收件匣訊息傳遞、瀏覽器介面、每次執行結尾的結構化狀態行，以及一份模型登錄——其預設模型正是設定範例所指名者。
何者仍屬提案
治理論證所倚賴的四項服務。一個決定權限的閘道、一個記錄部署內容與部署者的登錄、一份納入版本控制的 YAML 權限對應，以及一個執行觸發端點：每一項都被仔細描述，每一項都附有簡短的程式片段，卻沒有一項存在於讀者可安裝之物中。以此方式發表一套架構本無不可——但 harness 那一半本就是走得最熟的路，因此讀者能查驗的，恰恰是不新的那部分。論文坦承未做任何基準測試，並列出五項限制。以下是本報告的解讀，非論文所言：提案與產物之間的落差，是第六項。
最值得仔細掂量的一項主張
「稽核 N 項解決方案簡化為審閱 N 份指示檔」，其可靠程度不會高於它所借據的那一次共用程式碼審閱，而論文從未說明由誰執行該審閱。就其所指名的實作而言，授權允許安裝與執行，但未經書面許可禁止修改、fork 與逆向工程——而對相依套件的認真審查，往往正是以逆向工程收尾。原始碼確有隨附，故障礙屬法律而非技術；架構本身也並不要求封閉的 harness。但採用此模式的企業，等於是在選定一具將墊在其今後所有解決方案之下的 harness，而這個選擇理應受到該模式承諾要在他處變得低廉的同等審視。
以下宜寬鬆看待
此處所有計數，都只是某一個版本的快照，讀取時間在論文投稿八日之後。發布歷程中，沒有跡象顯示治理層曾被移除——所取樣的各版本中皆無此物——但快照終究只是快照，上文各項數字亦因此標註了日期。實地證據依其設計即無從查證：產業有名，客戶無名，而作者是明說而非文飾，這是一個無法驗證之主張的誠實版本。至於一篇在討論一節中如此仔細分級自身把握程度的論文，也值得以一種把「所論」與「所出貨」分開來看的讀法對待。