Harness 啟動與遵循度

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation
• Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents
• OmniVChat: Synthesizing, Benchmarking, and Training for Native Audio-Visual Dialogue
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering
• Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance

摘要#

每個 harness artifact——技能、記憶項目、上下文檔案、演化後的提示——都必須通過兩道關卡，才能改變結果：

1. 啟動。 代理程式確實將 artifact 帶進工作上下文。
2. 遵循度。 載入之後，代理程式確實依照其中指示行事。

兩者都是消費端的屬性，而非 artifact 的屬性。再好的技能，如果從未載入，就毫無效益；載入的技能若被代理程式當成裝飾，也同樣毫無效益。而端到端通過率——這個語料庫中幾乎所有來源唯一報告的數字——無法區分這兩種失敗與 artifact 本身不佳，因為三者產生的分數都相同。

Lin、Wu、Wang 等人（arXiv 2605.30621，Penn State / UC Santa Cruz / Emory / Northeastern / UIUC / Amazon，2026-05-28，empirical）是語料庫中第一個分別按模型測量這兩道關卡的來源。他們的核心結果是兩者彼此分離：在研究中最可靠載入 harness 的模型，並不是最遵循它的模型。

三項指標#

在 SkillsBench 上測量（86 項任務、11 個領域、每項任務使用確定性驗證器、每項任務試驗 5 次）；不演化基準從空技能集開始，因此參與其中的每項技能，都是在同一任務流程中由演化器稍早寫成的：

模型	SLR（技能載入率）	HFR（harness 遵循率）	LPR（載入後通過率）
Qwen3-32B	0.251	0.142	0.023
GPT-OSS-120B	0.446	0.442	0.040
Haiku 4.5	0.794	0.600	0.099
Qwen3-235B	0.961	0.350	0.022
Sonnet 4.6	0.959	0.730	0.145
Opus 4.6	0.957	0.757	0.177

（依照論文排序方式，按 SkillsBench 基礎能力排序。表 2，第 6 頁——資料匯入時逐格對照 pdftotext -layout 驗證。）

• SLR——模型至少將一項技能載入上下文的軌跡比例。此數值取自執行器的動作紀錄，而非由評審判定。
• HFR——在已載入技能的軌跡中，經 LLM 評審判定有遵循該技能指引的比例。評審先將技能內容整理成鎖定的原子程序指示評分規準，再依此規準檢查軌跡；盲測時會將每個模型家族的詞彙替換為 <MODEL>，且評審是 Claude Sonnet 4.6。這是評審輸出——請見下文〈哪些是測量值，哪些由評審判定〉。
• LPR——該模型已載入技能的軌跡通過率。這是測量值。

分野在 Qwen3-235B。 它的載入率為 0.961，與 Opus 4.6 的 0.957 在統計上無法區分；遵循率則為 0.350，遠低於 Opus 的 0.757。它載入後的通過率反映的是遵循度差距，而非啟動差距：0.022 對 0.177，相差八倍。這是目前最清楚的例子，證明載入 harness 並不足以從中獲益，也說明兩道關卡需要分別測量。若研究只報告 SLR，就會把 Qwen3-235B 判為成功。

另一端的 Qwen3-32B 兩道關卡都過不了——它每四次才載入一次，而載入後僅有七分之一的軌跡遵循技能；因此，即使啟動率差了 4 倍，它的技能載入後通過率（0.023）仍幾乎與 Qwen3-235B 相同。

遵循度不是定值：它會沿著軌跡衰退#

論文最鮮明的機制發現是：遵循度不是每個模型各自一個標量，而是隨執行過程變化的曲線。第二次評審呼叫（與 HFR 評審使用不同提示、同樣的盲測軌跡、同一位 Sonnet 4.6 評審）在三個參考階段為遵循度打 0–1 分：

軌跡階段	Qwen3-32B（弱）	GPT-OSS-120B（中）	Opus 4.6（強）
載入 harness	0.52	0.67	0.89
中間回合	0.22	0.48	0.79
最終回合	0.13	0.43	0.80
漂移（載入 → 最終）	−0.39	−0.24	−0.09

（表 3，第 7 頁——資料匯入時逐格驗證。）

沿著第一欄往下看：弱勢模型在載入時並沒有誤讀 harness。起始分數是 0.52，高於機率水準，也遠高於最後分數，接著便逐漸偏離。到了最後一回合，它只剩 0.13——它仍在執行，卻已不再按照載入的程序執行。弱勢級距的漂移斜率超過強勢級距四倍（0.39 對 0.09），論文據此指出瓶頸是長時程指令遵循，而非理解能力。

這重新界定了 harness artifact 必須承受的考驗。代理程式抵達時理解技能還不夠；技能必須在多輪軌跡中持續生效，同時抵抗代理程式先前輸出不斷累積的影響。中間級距的曲線最有參考價值——GPT-OSS-120B 在前半段下降 0.19，之後趨於平坦（0.48 → 0.43），看起來與其說是衰退，不如說是穩定在部分遵循的狀態。

兩種失敗模式，發生在不同層次#

以下兩個實例都是 SkillsBench 上的 Qwen3-32B，使用相同的 harness 和執行器（§D.1；圖 7 依雙階段圖片閱讀規則判讀——圖中提供了正文完全未提及的成對通過軌跡）。

啟動失敗——threejs；這是通訊協定失敗，不是檢索失敗。 在第 0 回合，Qwen3-32B 正確辨認出相關技能。接著它送出一個多鍵 JSON 動作，把 analysis（自由形式推理）、plan（步驟清單）和 load_skill 一起包在裡面。SkillsBench 格式閘門只接受單鍵動作，因此判定這個組合格式錯誤並拒絕。技能內容從未進入上下文，代理程式在沒有技能協助下繼續執行，得分 0.0。圖 7 該面板右半部顯示，同一任務中的 Qwen3-235B 輸出 {"load_skill": "threejs"}，並以 1.0 通過——兩個模型的差異不在於是否知道需要哪項技能，而在於能否使用執行器接受的格式表達需求。

遵循度失敗——pg-essay-to-audiobook；這是程序失敗。 載入的技能規定一條 TTS 備援鏈（圖 7 列出的順序為 kokoro → edge-tts → pyttsx3 → espeak → gTTS）。Qwen3-32B 在第 0 回合載入技能，卻把這條鏈當成照本宣科的腳本，而非因應情況的程序：第 1 回合執行第一個指定步驟時遇到 FileNotFoundError，接著第 2–7 回合都耗在失敗的 pip 安裝迴圈中，因為環境由外部管理；第 8 回合確認 espeak 存在，卻仍略過技能內容中的備援鏈；最後在第 10 回合輸出 task_complete: true，並說「沒有可用的 TTS 工具」。它就這樣悄無聲息地放棄，未達評分門檻。

值得保留的是圖中的另一半：同一任務中，GPT-OSS-120B 忽略 harness 長達十一回合，在技能內容未進入上下文的情況下自行撰寫 TTS 腳本；第 12 回合載入技能，第 13 回合將其讀作程序指南，隨後照著備援鏈處理——使用 pyttsx3、以 apt-get 修復 ffmpeg、改用 subprocess + espeak、修正錯誤的 paulgraham.com 網址——最後在第 23 回合產出通過的 audiobook.mp3。晚載入後確實遵循，依然能通過。這正是中間級距的效益曲線在單一軌跡中的呈現。

論文對這兩例的總結最值得記住：弱勢級距模型**「不是讀不懂 harness，而是無法依照它行事。」**

為什麼不能只歸咎於「artifact 不好」#

同一篇論文執行了演化器端的對照實驗，排除了最直觀的另一種解釋。固定解題代理程式，只改變哪個模型撰寫 harness 更新；七個演化器帶來的下游增益差距，在任何一項基準上都不超過 3.1 個百分點，而且沒有任何演化器能在三項基準全勝。研究中最小的模型 Qwen3.5-9B，反而在 SkillsBench 更新增益上拿下最高分（3.8 pp），高於 Opus 4.6 的 2.3 和 Qwen3-235B 的 1.5。SkillsBench 的 flink-query 任務案例研究顯示，9B 演化器撰寫的技能與 Opus 4.6 的技能在程序上同構：相同五個步驟（篩選 SUBMIT、篩選 FINISH、分別計算每個 SUBMIT、輸出 (jobId, count)、套用 10 分鐘 session 視窗），只有實作表面不同——以手動批次工作階段整理對上 KeyedProcessFunction——字元數則為 3,300 對 3,800（圖 4）。兩者都讓同一個 Opus 4.6 代理程式的分數從 0.67 提升至 1.0。

因此在這個設定中，artifact 不是變因。即使演化器能力差了三個數量級，更新品質仍大致持平；消費代理程式是否啟動並遵循它，差距卻達七倍。正因如此，啟動與遵循度值得作為一級指標測量，而不是假定它們理所當然會發生。

使用人類演化器時，相同的拆解（2026 年 9 月）。 Shen & Hruschka（Megagon Labs，arXiv 2609.05677，empirical）以實地研究呈現更新與效益的區分。更新由人類執行：對公開 SKILL.md 檔案進行 254 次實質編輯，每次均由具名的人類帳號撰寫或合併，其中 62% 留有 AI 協作者標記；編輯內容有 60% 是增補、38% 是修正。接著，研究以預先註冊且具統計檢定力的設計測量效益，修正了先導研究的混淆因素（透過隨需讀取提供完整套件、多輪流程一致化、跨模型家族盲測評審、檢定力 0.77–0.90）：對 13 項至少經歷 6 次實質編輯的技能，在 143 項遷移任務上，最新版相較最早版本的分數低 −0.09（95% CI [−0.28, +0.10]）；在控制長度、以及改用較弱的 gpt-4o-mini 解題模型後，結果仍為虛無，13 項技能中有 5 項由新版勝出。各技能的效應會因編輯新增內容而異——流程鷹架（brainstorming，−0.95）在單次提示任務中有害，輸出限制（pr-writer，+0.31）則能遷移——因此效益取決於編輯內容與任務是否相符，而不是編輯次數。這項研究沒有測量啟動或遵循度（解題模型透過檔案工具讀取套件，也未報告載入率或遵循率），而且評審小組未達自身 ICC 門檻（0.52 對 0.6）；因此應將它視為本頁主張在「人類演化器」情境下的界限：經過多輪有能力、由人類治理的更新，仍可能沒有可測量的效益。完整討論見人類治理的技能維護。

哪些是測量值，哪些由評審判定#

本頁依照三分法來看待自身數據：

• 由驗證器或紀錄衍生的測量值：通過率、∆效益、LPR 和 SLR（從執行器的動作紀錄讀取——技能不是進入上下文，就是沒有進入）。
• 評審判定值：HFR 及每個階段的所有遵循度分數。兩者都是 Claude Sonnet 4.6 作為 LLM 評審所給的結果（§D.3、§D.4）。這套設計有兩項實質的品質控管——軌跡依模型家族盲測；評分規準從技能內容擷取並在評分前鎖定，所以評審是依固定規準檢查，而非形成主觀印象。它也缺少常見的一項：沒有與人類評分的一致性檢查、沒有校正機率一致性的統計量、沒有位置偏誤稽核，也沒有第二位評審。依據 LLM 評審驗證，未經驗證的評審，光是在機率校正上就經常高估 33–41pp 的可靠度；因此，跨模型的 HFR 排序比任何單一數值更可信，Opus 與 Sonnet 之間 0.757 對 0.730 的差距也不是本頁會採信的差異。
• 論文未提及的 SLR 結構性但書。 threejs 案例顯示，SLR 混合了兩種不同事件：從未嘗試載入，以及嘗試載入，但被執行器的格式閘門拒絕。如果動作解析器更寬容，就會把那條軌跡計為已啟動。因此，報告中的 SLR 是模型與執行器組合的屬性，而非單看模型；弱勢級距的 0.251 是可歸因於模型的失敗比例上限。

範圍限制#

• 診斷只使用一項基準。 SLR、HFR、LPR 和階段分析都只在 SkillsBench 上進行。用它們來解釋的非單調效益曲線，雖然是在三項基準上測量，但機制只在一項基準上測量——也就是 harness artifact 本身正是受測對象的那一項。
• 模型集合早於 Claude 5（Opus 4.6、Sonnet 4.6、Haiku 4.5、Qwen3-235B-A22B、Qwen3-32B、GPT-OSS-120B，另有只作演化器的 Qwen3.5-9B）。「啟動率約 0.96、遵循度約 0.75」的強勢級距上限，是截至 2026-05 的上限；此處所有級距標籤都只相對於該世代而言。
• 級距依基準而異。 在 SWE-bench Verified 上，Qwen3-235B 是研究中的「弱勢錨定代理程式」；在 SkillsBench 上則是三個接近啟動率上限的模型之一。本頁任何內容都不應解讀為模型的固定排名。
• 完全沒有成本軸。 論文指出，所有代理程式與演化器組合都共享「相同的演化預算 β 和每項任務的回合上限」，但完全未公布 β、回合上限、生成次數、token 數或任何金額——因此測量了啟動與遵循度，卻沒測量它們的成本。

同一道關卡：只有名稱，沒有測量，以及後續的緩解方式（2026 年 9 月）#

以上都是實驗室中的拆解。Stolze & Strässle（ESEM 2026 SEIP，case-study，訪談五位實務工作者）從相反方向切入啟動關卡——討論治理實務而非軌跡評分——並將它表述為定義，而非比率。他們所說的預防性護欄（規格、引導檔案、架構計畫）「本身不會自動受檢查；其效力取決於生成流程是否實際參照它們」；這與可執行護欄相對，後者會「不論輸出如何產生，都自動對生成內容進行評估」。

去掉術語，這就是把本頁的第一道關卡當作分類界線：效益取決於啟動的 artifact，與效益不取決於啟動的 artifact，屬於不同類型的控制措施。論文沒有測量這個條件——沒有比率、沒有模型比較、沒有軌跡——因此並未增加證據。它帶來的是實務緩解方法；提出這些方法的實務工作者，當時並沒有 0.251 這樣的數字可參考：

• 重複設置，不要二選一。 側錄檔案中寫明慣例，再用 lint 規則強制執行相同慣例，刻意並列保留，「如此一來，即使側錄 artifact 過時、遭忽略，或在特定生成軌跡中缺席，可執行檢查仍能抓出違規。」兩層「會同時執行，而非依序分階段執行」。
• 將任何承載關鍵要求的內容，完全移出受啟動關卡限制的層。 「若規則與任務相關，就必須透過 linting 強制執行」[P4]。

這是 SLR 偏低或 HFR 持續衰退時，對 harness 設計的實際建議；它是分流建議，而非工程實作建議：必須維持的要求，放在無法取消啟動的檢查後面；並接受受啟動關卡限制的層所帶來的是軌跡品質提升，而非規範遵循。這也讓本頁尚未解答的消融問題更加明確——還沒有人測量 lint 規則存在時，側錄 artifact 額外貢獻了什麼。完整討論見分層監督。

在真實情境中觀察同一道關卡，不受執行器干擾（2026 年 9 月）#

上面所有比率都在基準測試執行器中評分，因此本頁第一個開放問題問的是執行器的動作語法，而不是模型。Gao & Chen（arXiv 2608.20195，2026-08-20，empirical）以由外而內的方式分析 557 場真實的代理式程式設計工作階段，流程中沒有基準測試 harness：557 場中有 316 場（56.7%，群集 CI 52.6–60.5%）至少出現一次文件互動，在觀察到的 3,033 次互動中，指令檔案占 35.4%。

這兩項特點讓這項研究能互補，而非直接比較。首先，這項結果從研究設計上就是下限，作者也明言如此：測量工具只會看到儲存在專案內的檔案操作，因此在工作階段開始時由執行環境注入、且從未重新開啟的上下文檔案不會被記錄——「指令檔案的計數是接觸量下限。」35.4% 實際測量的是刻意回頭查閱 artifact，也就是本頁關心的啟動事件，且排除了自動注入。其次，這裡沒有格式閘門：只要擷取器能解析 shell heredoc 中提及檔案的命令字串，代理程式就會被計數；這正是某個代理程式家族在作者修正問題前，所有文件事件都被計為零的原因。這是本頁第一個開放問題提到的執行器 artifact 風險，在另一種測量工具中再次出現，並且獲得修正，而非歸咎於模型。

遵循度也有相應的由外而內觀察，結果令人沮喪：Apply——讀取文件後依文件內容採取行動——是整個語料庫中獲得最少佐證的階段，3,033 次事件中僅有 75 次，而且完全沒有驗證階段。完整討論見代理程式文件行為。

啟動固定為 1.0 時，對宣告式 artifact 的遵循度（2026 年 9 月）#

以上測量的都是程序式artifact——一項包含步驟、可能載入或未載入的技能。OmniVChat（He、Chu、Chen 等人，Alibaba Qwen Team + CUHK + SJTU，arXiv 2609.21465，2026-09-18，empirical）補上了這張表的另一格，並且來自本頁從未涉足的領域：宣告式風格規格始終存在於上下文中，並以 12 個公開模型的通過率測量。

這項 artifact 是一段 1,296 字元的系統提示，規定採第一人稱、預設使用 1–3 句、不使用清單／項目符號／表格／emoji／程式碼（這是口語回覆情境）、說明公式的解法、使用標準標點，以及符合文法的完整句子。它拆成七項標準，再由 LLM（qwen3.7-max）評分並回傳符合的標準子集；報告中的 Style 指標是七項全數通過的比率。比較中的每個模型都在相同設定下接收完全相同的提示，因此這裡的遵循度從設計上排除了啟動關卡——每次呼叫時，artifact 都在上下文視窗中。

差異幅度就是研究發現。在 12 個已發布的 omni 模型中，最低的是 Qwen2.5-Omni-3B，0.479，接著是 Qwen3-Omni-Instruct，0.710、Gemini-3.7-Flash，0.631，最高則是 Gemini-3.1-Pro，0.871 和 Qwen3.5-Omni-Plus，0.869。本頁可以借用三項觀察：

• 對宣告式 artifact 的遵循度，變化幅度和程序式 artifact 一樣大，而且不單純依能力排序。 Gemini-3.1-Pro 的 Style 得分最高，為 0.871，但在基準的模型自我認知類別只得 0.341，整體 Mean 排名第四；Gemini-3.7-Flash 在任務表現接近頂尖，Style 卻以 0.631 排倒數第二。遵循規格與完成任務在此處同樣彼此分離，正如上文的 SLR 和 HFR；但這項 artifact 沒有可放棄的程序——這也部分回答了下方本頁的第三個開放問題。
• 當遵循度本身是獎勵時，就能訓練到接近飽和。 將風格項權重設為 0.5 的 RL，能把基礎模型從 0.710 推升至 0.992。這是語料庫中最清楚的例子，證明遵循度關卡不是固定不變的模型屬性——但它無法作為風格的證據，因為訓練獎勵與評估指標都是用同一個評審提示、依相同七項標準評分。應將它解讀為對最佳化器的測量，而非對 artifact 的測量。
• 評分器定義了遵循度，設計上是為了抵擋一種特定的鑽漏洞方式。 風格評分提示硬編碼了優先規則——標準 7（流暢、文法完整）優先於標準 3（簡潔的 1–3 句），並提供失敗範例；這些範例取自「另一個基礎模型的先導執行」，呈現模型「保留評分規準內容、卻省略功能詞」。這是規格作者發現簡潔度獎勵會讓回覆省掉冠詞、系詞和連接詞後，選擇修補評分器而非調整獎勵權重。值得與本頁對評審結果的折扣說明一起看：受最佳化壓力的遵循度評分規準本身就是對抗性 artifact，而規準的修訂記錄了政策找到的漏洞。

引用任何數字前請留意限制：領域不同（口說音訊視覺對話，而非代理式程式設計）、只有一項 artifact 而非演化後的語料庫、評審與受測的 12 個模型中有 6 個屬於同一模型家族，而且整張表都出自同時提供最高分模型的實驗室。工具目錄見互動性基準；評審設計見LLM 評審。

延伸閱讀#

• 代理程式文件行為——在 557 場真實程式設計工作階段中，於基準執行器之外觀察到同樣的兩道關卡：56.7% 的工作階段曾接觸文件；在 3,033 次互動中，指令檔案占 35.4%，這是明確的接觸量下限；遵循度方面，Apply 是獲得最少佐證的階段，僅有 75 次事件，而所有資料中都沒有任何驗證事件
• 人類治理的技能維護——由人類擔任演化器時，「更新不等於效益」的區分：經過六輪以上的人類治理 SKILL.md 維護後，沒有任何解題模型級距能在遷移任務上獲得可測量的效益（−0.09，CI [−0.28, +0.10]）；結果方向取決於編輯新增了什麼，而非編輯次數
• 分層監督——以治理分類、而非比率表述同一道啟動關卡：預防性護欄的定義，正是其效力取決於生成器是否參照它；可執行護欄則不論輸出如何產生，都會受到評估。此研究沒有提供測量值，但提供了這些數字所暗示、卻尚未有人記錄的實務緩解方法——將每項承載關鍵要求的規則，重複放入啟動與否不影響其效力的層中
• Agent-Authored Harness Optimization——這項拆解所服務的主題頁面，並在其中進一步討論相同來源的演化器端與代理程式端結果。該頁沿用的區分指標，反映的是種子的屬性（起始 harness 有多差）；這裡談的是更基礎的消費者屬性，也說明為何該頁統計的端到端分數無法拆解自身的負向結果
• 技能效益——此測量是相關前提。SkillEvaluator 的有技能／無技能消融，是乾淨的 harness 內對照，但假設技能已載入；SLR 為 0.251 時，「有技能」組有四分之三其實只是掛著標籤的無技能組，任何效益數字都暗中包含啟動項。兩種測量可以直接搭配——Skill Lift 測量 artifact，SLR 和 HFR 測量消費者——缺少另一方，就無法解讀任何一方
• Agent Context Files——人類撰寫一側的相同兩道關卡。代理程式的肌肉記憶將遵循度上限表述為架構上的疑慮（「技能的品質受限於協調器忠實遵循指令的能力；面對複雜、多步驟任務時尤其困難」），但未測量此上限；本頁提供了該測量，而結果比這項疑慮所暗示的更糟，因為上限會在單一軌跡中變動。METR 發生的 CLAUDE.md 已寫好卻未遵循事件，是同一條 0.52→0.13 曲線的軼事案例
• Instruction Compounding——同一軸線上的相反問題，兩端放在一起比各看一端更有用。Anthropic 刪除了提供給 Opus 5 的驗證指令，因為該模型過度遵循指令，超出其效用範圍；Qwen3-32B 則從 0.52 漂移至 0.13，偏離自己正確載入的指令。「少寫一些、更有力的指令」與「將 harness 呼叫和長時程遵循度訓練成技能」這兩項建議，是同一條曲線上的兩個級距；為曲線錯誤一端撰寫的 harness，會朝相反方向失效
• Client-Side Agent Optimization——以數字表達的角色分派結果。AgentOpt 固定 harness，搜尋不同模型擔任不同角色的配置；這個來源提供搜尋時可用的先驗——將能力配置給解題角色，而非演化器角色，因為演化器端的差距最多只有 3.1 pp，代理程式端在同一基準上的差距則為 36.0 pp
• 以知識為核心的自我改進——2026 年 9 月的 RSI 調查建議把這種拆解（「分別測量更新品質、啟動、忠實使用與下游效益」）列為方向，但當時該頁沒有數據；本篇正是執行該建議的主要研究，對程序式 artifact 的結論是，忠實使用才是瓶頸。Caltech 套件的跨模型家族遷移只測量下游效益，因此宣告式知識是否比程序更容易通過遵循度關卡，仍是未知
• 互動性基準——上文的 Style 通過率是 12 個模型基準表中的一欄；同一張表也列有 COI，而 COI 讓頂端那一列無法解讀為風格表現
• LLM 評審驗證——上文對 HFR 和階段分數所採用的折扣；少數兼顧盲測與鎖定評分規準、卻完全漏掉一致性統計的案例之一
• RSI 自主性級別（B0–L5）——階梯中的 L4 失敗類別持續更新失敗，列出「未能呼叫相關更新」作為最終任務分數無法區分的四種機制之一。本頁測量的正是這種機制，另加階梯未提及的第五種情況：呼叫更新後，卻在軌跡中逐漸偏離
• 模型進步時的 Harness 精簡——相反方向的壓力。精簡論點認為，較強模型需要較少鷹架；啟動與遵循度的結果則顯示，最需要鷹架的模型最無法善用它，因此鷹架預算與模型能力會一同增減，而非朝相反方向移動；數據顯示，弱模型加豐富 harness 的組合行不通
• Deterministic Pre-Execution Gates——逃離兩種失敗模式的途徑：攔截工具呼叫的執行階段述詞，既無法被取消啟動，也不會逐漸偏離，因為軌跡中無須任何項目記住它
• Harness 的價值是乘積，而非分數——為何 Artifact 效益問題總是只獲得部分解答——將本頁的拆解重新表述為一項識別結果：端到端分數是啟動、遵循度、artifact 品質和任務上限的乘積，因此無法從已部署軌跡中的任何觀察統計量還原其中某一項。這也界定了本頁自身開放問題的範圍——0.251 是可歸因於模型的啟動失敗上限，而非估計值——並將階段漂移曲線與 Eliav 的同時指令上限並列為同一種耗竭能力的兩個正交軸線（深度與廣度）；兩頁都沒有涵蓋這項連結

開放問題#

• 弱勢級距的啟動差距有多少來自模型，又有多少來自執行器的動作語法？SkillsBench 的格式閘門會拒絕包含正確 load_skill 的複合動作，因此報告的 0.251 把解析失敗也算在模型頭上。無須新模型即可低成本驗證：重新評分相同軌跡，只要動作內容中提到有效技能，就算作一次啟動嘗試，並將兩種比率並列報告。部分解答（2026-09-18）：Harness 的價值是乘積，而非分數——為何 Artifact 效益問題總是只獲得部分解答——詮釋層面已解決，測量層面尚未解決。SLR 0.251 是可歸因於模型的啟動失敗上限，而非估計值：threejs 案例中，模型在第 0 回合正確辨認出技能，卻在執行器的單鍵格式閘門遭拒；因此，報告值反映的是模型與執行器組合的屬性。論文本身的結論（弱勢模型「不是讀不懂 harness，而是無法依照它行事」）指出，關鍵瓶頸在遵循度一側。原先提出的驗證方式不變，但無法用現有語料執行——需要取得軌跡資料。標籤由 #oq/now 改為 #oq/source：既有頁面的綜合分析已完成，剩下的是重新評分 wiki 未收錄的資料。
• 遵循度曲線會趨平，還是持續下滑？三個模型都只在三個參考階段評分，中間級距曲線已呈現穩定趨勢（0.67 → 0.48 → 0.43），而非持續衰退；弱勢級距則沒有（0.52 → 0.22 → 0.13）。這項差異對 harness 設計很重要：趨平曲線表示第一次下降後再次注入是白費力氣；持續衰退則表示再次注入才是完整解方。可透過對已評分軌跡逐回合、而非逐階段報告遵循度來驗證。
• 宣告式 artifact 的啟動關卡，是否與程序式 artifact 相同？此處測量的所有 artifact 都是技能——一項包含依序執行步驟的程序，也是最容易受到長時程漂移影響的 artifact 類別。記憶項目或整理過的事實，到了第 8 回合並沒有程序可供放棄。可用語料庫本身的矛盾來驗證：以知識為核心的自我改進指出，宣告式套件能跨模型家族遷移，演化後的 harness 卻完全無法移植；但兩者都沒有人測量其啟動或忠實使用情形。部分解答（2026-09-23），只回答了忠實使用部分。OmniVChat: Synthesizing, Benchmarking, and Training for Native Audio-Visual Dialogue（empirical）測量對純宣告式 artifact 的遵循度：一份拆成七項標準、長 1,296 字元的風格規格，在 12 個已發布的 omni 模型中接受評估；由於每次呼叫都將規格放進系統提示中，啟動從設計上固定為 1.0。忠實使用率仍介於 0.479 到 0.871，差距與本頁的 HFR 範圍相當，也不隨任務能力變化（該基準中任務能力最高的模型，遵循度排名倒數第二）。因此，即使宣告式 artifact 在第 8 回合沒有可放棄的程序，也不會因此更容易通過遵循度關卡；關鍵在於是否遵循，而不是程序長度。此答案仍不完整，有兩個原因：此處未測量啟動端——模型是否會取回未交付給它的宣告式 artifact——而這正是問題實際詢問的部分；此外，單回合設定沒有軌跡，因此無法用它檢驗上文的衰退曲線。跨領域限制見上文段落。

資料來源#

• From Agent Behaviour to Agent-Friendly Documentation——Gao & Chen（Peking University），arXiv 2608.20195，2026-08-20，empirical。此處引用 §4（557 場中有 316 場出現任何文件事件）、§3.5 觀察範圍（指令檔案計數是接觸量下限）、§3.4（shell 內嵌路徑擷取缺陷使某個代理程式家族的計數歸零），以及表 10（Apply 75、Validate 0）。這是觀察性、以路徑為基礎的研究——既未針對已知目錄測量載入率，也未由評審判定忠實使用，因此無法對本頁的尺度作出任何界定。完整討論見代理程式文件行為
• Who Maintains Agent Skills? A Longitudinal Study of Human-Governed, AI-Assisted Skill Maintenance——Shen & Hruschka（Megagon Labs），arXiv 2609.05677，2026-09-04，empirical。此處只引用 §7 與附錄 D（具統計檢定力的遷移任務虛無結果，以及各技能的差異）；研究未報告任何啟動或遵循度比率。完整討論見人類治理的技能維護
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering——Stolze & Strässle（OST Eastern Switzerland UAS / smartive AG，arXiv 2608.26316，2026-08-26，ESEM 2026 SEIP），case-study：§5.2（預防性／可執行標準與並行論點），以及 §4.2（升級 lint 規則的要求）。訪談五人，未進行任何測量——證據說明見分層監督
• Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents——Minhua Lin、Juncheng Wu、Zijun Wang、Zhan Shi、Yisi Sang、Bing He、Zewen Liu、Tianxin Wei、Zongyu Wu、Zhiwei Zhang、Dakuo Wang、Xiang Zhang、Benoit Dumoulin、Cihang Xie、Yuyin Zhou、Suhang Wang 與 Hanqing Lu（17 位作者；The Pennsylvania State University、UC Santa Cruz、Emory University、Northeastern University、UIUC、Amazon），Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents，arXiv 2605.30621，2026-05-28，正文 12 頁及附錄，empirical。此處引用 §4.3 觀察 2 與表 2（SLR / HFR / LPR）、表 3各階段遵循度漂移、§D.1 的兩個失敗案例、§D.3–D.4 的評審流程、§4.2 演化器端差異持平，以及 flink-query 同構案例研究（§C.2）、§B.1／B.4 的研究流程。解析結果：乾淨。 資料匯入時所有自動表格檢查均通過（0 欄位合併／0 位移／0 列拆分／0 列黏合）——在此語料庫中相當少見；表 1、2、3 均依 pdftotext -layout 逐格驗證。唯一的 canary-recall 軟性警告已確認為誤報（docling 將「3–6 tool calls」中的 en dash 正規化為「3 - 6」）。表 4–6 未逐頁稽核，但表 5 的 21 個 ∆update 儲存格已依其自身通過率重新以算術推導，21 個結果全數重現，且表 5 的錨點欄與表 7 逐格相符。圖 4 與圖 7 均依雙階段圖片規則閱讀，兩者都包含正文未提及的內容：圖 7 成對的通過軌跡（Qwen3-235B 正確載入 threejs；GPT-OSS-120B 在第 12 回合啟動後仍然通過）與實際的備援鏈；圖 4 的技能長度（約 3,300 對約 3,800 字元）。利益衝突：無——作者來自學界和業界混合團隊，但沒有作者所屬機構推出任何受評估模型。限制：只在 SkillsBench 上測量機制；HFR 與階段分數均由 Sonnet-4.6 評審產生，且沒有一致性統計；模型集合早於 Claude 5；全篇未公布運算量、token 數、回合上限或任何金額；摘要中的程式碼可用性句子寫著「publicly available at here」，但 PDF 本身沒有附上網址