代理程式系統與 Harness 工程

agent-systems 領域的內容地圖——53 個概念。涵蓋 Harness 工程、代理程式迴圈與協調、脈絡管理、協定與工具基礎設施（MCP、應用程式伺服器），以及子代理程式。精選入口；所有領域請見 Home。

• Agent-Authored Harness Optimization — 代理程式在自己的 Harness 上獨立執行整個 eval-fix 迴圈——讀取軌跡、提出假設、修補、重新執行。七個案例結論不一：Cline 不受控的廠商宣傳活動、HarnessBank 在封存切分上取得的歸功增益、Ouroboros 未經測量的 161 天部署、Wang 等人預算匹配的測試中 Harness 演進不敵單純平行取樣、DarwinX 在相同基準測試上採用類別預算而非匹配預算得出的相反結果、Shopify 的正式環境迴圈——唯一報告增益會耗盡的案例——以及 Bridgewater 的 PAT；該案例沒有提供效能數字，但提出由代理程式撰寫、修補前必須失敗的基準測試，以及 PR 審查時的人工作業關卡。這些差異可由起始 Harness 的脆弱程度調和；Lin 等人的原始研究發表後，又增加了種子研究無法解釋的第二個軸線：解題代理程式是否會啟用產物，並依循其指引。第八個案例（Salesforce）增加第三個軸線：Harness 即使能向上轉移、使用率增加，仍可能因權重更新而失去全部增益——專家軌跡上的完整軌跡 SFT 會破壞模型與 Harness 的規劃配合度；只修正自身失敗的回合則能保留這種配合度。第九個案例（RRSI）增加第四個軸線：對搜尋本身施加正則化——退火式編輯預算、考量證據的信用分配、洩漏評論器、依雜訊調整的下限、成本門檻式接受、結構修剪——將本文一直診斷的「演進到轉移」落差轉化為可控的取捨。在相同預算下，它於分布外表現勝過四個未正則化基準，並能轉移至未參與搜尋的較小政策模型。
• Agent Context Files — 跨廠商的「以 Markdown 作為控制平面」模式：以儲存庫版本管理的純文字（CLAUDE.md / AGENTS.md / SOUL.md / WORKFLOW.md / SPEC.md /.cursorrules）設定代理程式行為，依角色分為專案／個性／工作流程／規格層；而自 Genkit 在四種語言 SDK 中實作 SKILL.md 載入以來，這套慣例也有了另一家廠商的執行階段支援，不再只有撰寫慣例
• Agent Documentation Behavior — 首次追蹤程式碼代理程式實際如何使用文件（Gao & Chen, arXiv 2608.20195）：在 557 個 SWE-chat 工作階段（94,813 個事件、3,033 次文件互動）與 33,097 個 AIDev 代理程式 PR 中，面向代理程式的產物——指示檔占 35.4%、代理程式工作筆記占 25.1%——合計占文件互動的 60.5%；API 參考占 1.3%，疑難排解占 0.4%。查閱多為自主發起（70.2%），而非由失敗觸發（7.5%）；研究領域所假設的「讀取→編輯程式碼」連結僅有 0.002 的相鄰率，且在三個事件內無法確認（提升幅度 1.05，調整後 OR 為 1.33）；未觀察到任何驗證事件，查閱後的測試反而減少（提升幅度 0.23）；正式環境的查閱率為 0.87×，而程式碼先於文件出現的比例是 4.7×。結果呈現雙葉循環——反覆查閱與撰寫的葉節點和程式碼鬆散耦合——而非線性的讀取→應用→驗證歷程
• Agent Harness Engineering — 建構長時間執行 LLM 代理程式的模式：環境設計、逐步揭露脈絡、機械式架構執行、代理程式程式碼審查
• Agent Loop Pattern — /loop（由 cron 排程）與 Ralph Wiggum（清空待辦清單）迴圈，是新一代代理程式基本元件；支援 AFK 執行、平行擴展，以及「迴圈就是未來」的理念
• Agent-Native Infrastructure — 世界仍是為人類打造的，必須為代理程式重寫；「我要複製貼上什麼給代理程式？」；感測器／致動器；代理程式對代理程式的表示法
• Agent Quality Flywheel — Google 的 eval-fix 迴圈包裝成由程式碼代理程式驅動的技能：建置與測試 → 發布與監控 → 學習與改進，擴展為五個階段（準備資料／執行推論／評分／分析失敗／最佳化）；以白話描述的疑慮輸入，輸出指標選擇及前後差異；合成 User Simulator 負責引導，正式環境 OTel 軌跡則提升精準度。Shopify 的 Sidekick 飛輪採用相同迴圈，但移動了終點——先持續修改指示與 Harness，直到成效趨於平緩，再從正式環境失敗中擷取 SFT+GRPO 訓練訊號，讓每個循環都從更好的權重起步，而非更長的提示。其蒸餾曲線在 26k 到 30k 條軌跡之間超越正式環境基準；96% 的服務成本削減則是預測值，不是帳單數字
• Tree Search over Agent Trajectories (LATS) — LATS（ICML 2024）：對代理程式的動作軌跡執行 Monte Carlo Tree Search，而非只選定單一路徑——從一個節點取樣 k 個動作，在環境中各自執行，使用 LLM 評判器加上自我一致性頻率項為結果狀態評分，以 UCT 選擇，展開至終止狀態，再把回報作為移動平均值向上回傳，並附上模型自己撰寫、說明分支成功或失敗原因的反思。CS329A 第 5 講將其教作 ReAct 加規劃。這堂課承認的兩個限制正是關鍵：從未分析成本，且整個方法假設動作都可逆
• Agentic Code Generation as Compilation — Bridgewater 的 PAT 將程式碼代理程式視為編譯器，而非代理程式：計畫是具型別的 IR（以「自然語言 Python 專案」呈現任務，每項任務宣告必須產生的資料框架結構），而不是待辦清單；由於每個消費端都已知道生產端的結構，任務可透過平行 LLM 生成編譯成 Python；驗證代理程式在 DAG 層級執行，並由一般 Python 強制執行，因此代理程式無法略過；靜態分析會注入快取註記，讓一字之差的編輯重新執行幾乎即時。數字皆為自行回報：約為 Claude Code 程式碼生成延遲的 4 倍、20 項任務計畫的耗時與 3 項任務相同、兩個代理程式有 95% 的機率產生相同程式碼——方法未公開；確定性數據是在一個反覆編輯程式碼直到符合任務的迴圈之後測得
• Automated Failure Attribution — WHO&WHEN PRO（Liu 等人，12,326 條注入錯誤的軌跡）：LLM 大多無法歸因多代理程式失敗——責任代理程式識別率 48–58%，錯誤模式 macro-F1 為 10.8–22.2，三項全對率 16–25%，人類評審小組則超過 90%；準確率會隨軌跡長度下降，協調相關失敗則被歸為「推理錯誤」。資料集中唯一以蒐集而非注入方式取得的失敗集合（多語言規劃與落地，80 條軌跡，透過「英文成功／非英文失敗」篩選）證明自然發生的來源可行，也顯示這個領域透過指示評判器標記單一主要原因，迴避了多重故障情形
• Build for the Next Model — 原型化幾乎可行的東西，而不是已經可行的東西：押注下一次具體的模型發布（不是遙遠未來的 AGI）能修復工程手段無法解決的問題；Claude Design 的 Opus 4.7 回報，以及 OpenAI 的「二月的 Codex 應用程式在十一月會無法通過」是最清楚的案例——同一種產品形態，不同智慧水準的版本，結果不同
• Claude Code Auto Mode — Claude Code 的權限模式，使用分類器自動核准安全的工具呼叫並封鎖有風險的呼叫；介於預設模式和 --dangerously-skip-permissions 之間
• Claude Code Best Practices (總覽) — Anthropic 有效使用 Claude Code 的指南：脈絡管理、以驗證為導向的開發、探索→規劃→編碼工作流程、環境設定
• Client-Side Agent Optimization — AgentOpt 將由開發者控制的代理程式最佳化（依角色配置模型、預算、路由）視為有別於伺服器端服務；組合抽象；最佳與最差組合之間成本差距達 13–32×。Cursor 在正式環境中的四種規劃器／工作器組合重現此結果，跨角色耦合反映在帳單上，而「最強模型卻是最差的規劃器」最後證明是 Harness 特性
• Codex App Server Protocol — 無人值守 Codex 工作階段的 JSON-RPC stdio 協定：initialize/initialized/thread-start/turn-start 握手；延續回合重用 thread_id；動態工具呼叫可注入與 token 隔離的工具——而自 MCP 規格於 2026-07-28 完全刪除工作階段與 initialize 握手後，這一對協定在狀態性上已分道揚鑣：MCP 放棄工作階段語意，工作階段語意卻是此協定的核心主題
• Context Lifecycle Management — 將代理程式的作用中脈絡視為具有生命週期的索引執行階段物件（折疊／遮罩／修剪、可復原的側邊檔案、具快取感知的提交），而非需要裁切的 token 緩衝區——小紅書的 Self-GC 是經測量的處理方式（約修剪 44% 前綴，約 85% 無影響），另含五種基本操作分類、O(n²) 完整附加成本案例，以及 RCWT 的協調占比斷崖。
• Context Window Smart Zone (總覽) — 聰明區與遲鈍區（Dex Horthy / Matt Pocock）：注意力呈二次方擴展；不受宣稱的脈絡長度影響，約 100K 處有標記；清除並重新開始勝過壓縮；在狀態列計算 token 是必要紀律；Robert C. Martin 從指示面提出佐證，透過資訊遺失在中間——這是位置主張，不是占用量主張——並據此提出生來即短暫、完成任務便消失的角色代理程式
• Cost-per-Task Over Cost-per-Token — Anthropic 顛倒了模型選擇預設方式：從能力最強的模型開始，再逐步降低投入——較強的模型回合數較少，因此即使每 token 價格上升，每項任務的成本仍會下降；另有 Cursor 四種組合的正式環境測量、Writer 的 Harness 替換測試（協調方式比模型選單影響更大），以及 Databricks 的基準測試：開放權重模型在品質相同時最便宜；加上本文先前尚未計價的第三種計費單位——OpenAI 的 GPT-Live-1 語音層，每分鐘 $0.05，代理程式前半段按呈現時間購買，後半段則按完成工作購買；以及 Uber 自行提出的六項成本方程式，以正式環境流量端到端計價（低點時成本減少 34%/52%、每次審查 $0.47 的指定 Pareto 正式環境點，以及讓子代理程式預設使用較弱模型的調整槓桿）。
• Crystallizing Agent Work into Workflows — Malik 在 Azure Networking 的正式環境生命週期：將代理程式探索視為發現機制，而非執行模式——根據累積證據，將反覆驗證過的代理程式行為沿著三種類型的光譜逐步升級（代理程式協調 → 混合 → 零 token 的確定性），回歸時則自動降級；確定性占比在八個月內由 0 增至 45%，事故成本下降 70% 而處理量翻倍，自主權依據作業手冊的實績取得，而非模型能力
• Deep Modules for Agents — 將 Ousterhout 的深層與淺層模組概念用於方便代理程式使用的程式碼庫；推送與拉取式指示傳遞；在全新脈絡中進行審查；Sandcastle 三代理程式模式
• Deep Research Agents — 將複雜查詢拆解、反覆搜尋多元來源，並彙整成附有引用的結構化報告之代理系統——不同於單次問答；DRACO 顯示，Perplexity 的協調勝過僅配備工具的基礎模型，而事實準確度是弱項。MisKnow-Agent 從輸入面量化這項弱點：一份看似可信但內容錯誤的文件，不需任何指示注入，就會使採納錯誤結論的比例從 0% 升至 54.7%——而同一批在工作流程中認可這些文件的模型，單獨看到文件時卻會指出問題。第三種攻擊面位於樹的根節點，具型別的規劃前表示法在凍結模型上帶來 +3.6 至 +10 點提升。成本方面：未修剪執行的 94.41% token 用於結果處理；提早剪除分支可減少三分之二的 token，同時保留基準品質的 97.9%；39 組設定網格中，沒有一組能保留基準的關鍵要點涵蓋率
• Deterministic Engineering for Agent Code Review — OpenCodeReview（Alibaba / Nanjing / Peking，arXiv 2608.09290）：對審查代理程式進行三種確定性注入——規則驅動的檔案派發、六工具有界輸出集合，以及只能篩選、可見內容比代理程式還少的反思器——在 AACR-Bench 上以少 14.7 倍 token、少 9.5 倍耗時，達到 25.10% SEM-F1，勝過 Claude Code 的 /code-review 的 11.57%。這項主要結果是精確率與召回率互換，並非免費午餐：精確率為 33.90% 對 7.23%，但召回率下降，為 20.00% 對 28.90%；因此勝出者找到 1,505 個專家驗證問題中的 301 個，基準系統則找到 435 個。沒有消融測試——唯一比較對象是兩個分開打造的產品，其中一個比論文發表前推出的多代理程式 /code-review 版本落後約 33 次發布——因此三種注入中哪一種帶來增益尚未測試；資料集中第二項「確定性勝過自主性」主張，也仍缺少關卡對指示的比較組
• Deterministic Pre-Execution Gates — Reddy 等人：允許政策的工具上發生無聲違規，是一種不同的失敗類別（τ²-bench airline 的失敗中，有 78% 是工具沒有錯誤、但最終狀態錯誤）；在預定呼叫上加上四種確定性的唯讀關卡，任務成功率提升 +12.4pp——動作邊界執行不只能限制安全成本，也能提高成功率，但每個關卡的精確率仍須稽核。
• Document Parsing as the Retrieval Bottleneck — Doulcet 對 2024→2026 RAG 的回顧：瓶頸從模型移至檢索，再從檢索移至解析——Glantz 的 12 個痛點沿著解析→檢索→彙整擴散，單一解析失敗就會引發其他 11 項中的 7 項；重排與修正迴圈讓大多數痛點成為例行工程問題；長脈絡沒有消滅 RAG（成本、治理、稽核都仍重要）；留下來的是輸入時的結構流失，可用空間文字、Markdown、依結構對齊的區塊，以及 ParseBench 解決
• Dynamic Workflows: An Algebra for Agents — Claude Code 的沙盒化協調基本元件：Claude 撰寫並執行程式，在 Bun VM 中依序或平行組合代理程式——Cherny 將其描述為擴展測試時運算的新方法；Jarred Sumner 第一手公開的 Bun Zig→Rust 移植方法則提供實作細節（11 天移植 535,496 行、約 50 個工作流程、6,502 次提交、最高同時執行 64 個 Claudes、約 $165k token、以超過 1M 個測試斷言為判定基準）——外部稽核指出，約 $165k 帶來的是從成本到綠燈，而非從成本到發布；出貨產品的預設值（v2.1.219）將工作流程控制在 15 個代理程式以內
• Failures That Look Like Success — 安靜的代理程式失敗類別：一切看起來都正常——答案有自信、計畫合理，甚至內部狀態正確——但使用者看到的結果有誤。Google 飛輪示範中，代理程式在正確呼叫記憶功能後仍回報過時數值，並無聲略過自我回報指示；在一個政策允許工具的基準測試中，這類情況占失敗的 78%；與之對應的讀取面失敗是遺漏，也就是某項事實從未出現，可由九層管線分類法歸因至特定位置。應以軌跡層級評分規準偵測，而非略看輸出；至於確定性層，位元差異比對完全不需要評分器
• Harness Activation and Adherence — Harness 產物和其效益之間，有兩道消費端關卡——代理程式是否將產物帶入脈絡（啟用），以及帶入後是否依循產物（遵循）——Lin 等人首次依模型分開測量（arXiv 2605.30621）：SkillsBench 的技能載入率介於 0.251（Qwen3-32B）和 0.961（Qwen3-235B），Harness 遵循率則介於 0.142 和 0.757，兩者並不互相連動；Qwen3-235B 的載入可靠度與 Opus 4.6 相同，遵循率卻只有一半。遵循率也會在單一軌跡內衰退：弱勢級從 0.52 降到 0.13，強勢級則從 0.89 降到 0.80，因此端到端分數無法區分產物不佳，還是優質產物根本沒被啟用
• Harness Build-vs-Buy — 自有程式碼代理程式的實際代價：四種 Harness（OpenHands、Codex、OpenCode、Hermes）過去 12 個月的公開 GitHub 活動顯示，每年合併 5,679–7,736 個 PR、各自修改 1.05M–1.75M 行程式碼，因此凍結一年的分支落後上游約 4,600 個 PR（約每日 13 個）——OpenHands（廠商，具有商業利益）主張應在可行的最高層自訂：提示／設定 → MCP → 技能／外掛 → SDK
• Harness-Induced Belief Divergence — Yi & Song：固定任務、環境與基礎 LLM，只變更 Harness，就會使代理程式引出的信念軌跡產生分歧——介面地板帶來初始差異，加上影響行為的增長項（動作分歧從 0.28 升至 0.60，UnsafeRetryRate 為 0.700）；論文宣稱「保留終端成功率」，卻從未測量。
• Harness Shrinkage as Models Improve (總覽) — 每次模型發布都會縮減提示腳手架；Cat Wu 的修剪紀律；Boris Cherny「一年後只要 100 行程式碼」的主張；Anthropic 為 Claude 5 模型刪除超過 80% 的 Claude Code 系統提示——Cherny 回報即使沒有提示，模型仍稍微更聰明（以 SIMPLE=1 執行消融）；使用者端的做法是委派而非刪除（「自行判斷」）；機械式驗證仍不可或缺
• Harness Tax: Coding-Agent Cost Multiplies Across Harnesses While Success Barely Moves — Arena.ai 的 21 組組合研究（7 個模型 × Claude Code / Codex CLI / Pi，SWE-bench Lite + Terminal-Bench 2.0）：Harness 選擇讓成功率變動 ±2–5%，成本卻最高相差 5 倍，幾何平均為 2.0 倍（Claude Code 對 Pi，SWE-bench Lite）；由 4 種工具組成的開源 Harness（Pi）在兩個基準測試上都達到 Pareto 前緣；另一個 Harness 在 12 次正面比較中有 9 次勝過模型供應商自家的 Harness
• Instruction Compounding — 當模型原本就會某種行為時，要求它執行該行為的指示不再只是多餘，而會產生疊加效果，讓行為超出實用範圍——因此 Anthropic 的 Opus 5 提示指南建議刪除驗證、重新檢查及不要思考等指示，而非重新措辭；其下方還有測得的容量下限：測試的五個模型在約 80 項同時存在的指示時，遵守所有規則的比例都降至零，且與格式無關
• Knowledge-Centric Self-Improvement — Caltech 對自我改進代理程式的反轉做法：讓代理程式維持通用、無狀態、可替換，只讓精選知識庫成為持續存在的物件——先建構任務層級論壇，再建構跨任務論壇，最後蒸餾成具型別的組合包。在五個基準測試中，以較低金額成本勝過以代理程式為中心（DGM、HyperAgents）及提示最佳化（GEPA、OpenEvolve）的基準；凍結的組合包能以零樣本方式轉移至保留任務，也能在每一種捐贈者與接收者配對中跨 LLM 家族轉移——這與移植演進後的 Harness 時發生的情況正好相反。此處也是知識庫中「哪些內容應持續存在」分類法的首頁：代理程式、Harness、知識、提示，以及（某一則正式環境案例研究中的）權重；權重位於 Harness 的下游，而非與其並列
• Latent vs. Deterministic Space — Garry Tan 診斷代理程式系統錯誤的方法：運算發生在兩處——潛在空間（LLM：品味、判斷、模糊意圖詮釋，由 Markdown 引導）與確定性空間（生成的程式碼、外部狀態）——大多數 AI 工程失敗都是運算發生在錯誤的一側；如今有一個經測量的案例：將四條政策規則從提示文件移至以 Python 判斷式檢查資料庫狀態，代理任務成功率便提高 +12.4pp；Robert C. Martin 補充實務上的衰減論點——隨工作階段增長，提示規則會逐漸失效，檢查器則不會
• Layerwise Omission Attribution — Rajan：遺漏——答案中悄然缺少會影響決策的事實——屬於管線特性，可透過 canary 檢查點抽頭歸因至九層之一（確定性的 L0-L3 可精確計數，行為層 L4-L8 則以對照方式計數）；刻意注入的瀑布測試無法呈現正式環境盛行率，但分類法、抽頭方法，以及三種會提高遺漏率的操作旋鈕仍成立。九層止於一個邊界之前：若請求轉成計畫時失去承諾，所有位元仍完整無缺；多語言規劃來源中的具型別任務表示法，就是本文用來預先防範的 canary，但無成本測量從未執行。
• LLM-as-Compiler Knowledge Base — Karpathy 的架構：LLM 將原始文件逐步編譯為持續保存且互相連結的 Wiki，以四階段的匯入→編譯→查詢→檢查管線取代 RAG——到 2026 年 7 月已發展成「代理程式 Wiki」（Cognition DeepWiki、Factory AutoWiki、LangChain OpenWiki、GBrain），採用相同的三層結構，維護資訊的新舊程度則各異；Muscle Memory（Google Cloud，2026 年 8 月）是首個外部來源，自成一套立場，主張個人化記憶應採編譯而非檢索，焦點不在文件；Open Knowledge Format（Google Cloud，2026 年 6 月）是首個將此模式正式化以利互通的規格，標準化容器——Markdown、frontmatter、保留的 index.md/log.md——但來源脈絡、矛盾與修剪完全交由生產者處理
• Long-Horizon Agent Failure Signature — Rahman 等人（Google Research/DeepMind + UCLA/NYU，arXiv 2609.17930）：涵蓋 SWE-bench、TerminalBench 與 BixBench 的 2,518 條長時程軌跡，以及整理成 10 個家族、78 種失誤的 6,967 個錯誤；第一次犯錯後，代理程式只有 30.5% 的執行成功復原、38.5% 從未偵測到錯誤、72.6% 繼續採取行動；失敗執行中有 84.1% 結束在讀起來仍正確的一步。六個前沿評判器找到自然發生失敗的第一個錯誤比例不到三分之一（精確比對率 7.2–32.3%，遠低於 WHO&WHEN PRO 在注入錯誤上的 73.9%）；Scout 是經訓練的 4B 驗證器，表現勝過這些評判器、能轉移至未見領域，也能在不重新訓練代理程式的情況下提高 best-of-N 任務成功率。安全稽核發現，已解決的執行曾採取未經確認、且多半不可逆的破壞性動作，regex 掃描有 77% 的機率漏掉這些動作。
• Loop Engineering — 不再由自己充當代理程式的提示者，改為設計負責提示它的系統：以五種產品原生基本元件（自動化、工作樹、技能、連接器、子代理程式）加外部記憶，建構遞迴目標迴圈；可跨 Codex 與 Claude Code 使用，不受工具限制；槓桿點從撰寫提示移至設計迴圈；Anthropic 每個程式碼庫每日執行 20–30 次自我維護例行工作，是已部署的最終形態
• MCP and Computer Use — Anthropic 兩種互補的連接器機制：MCP 提供結構化程式存取（Salesforce/Drive/Gmail/Slack/Figma 加上小眾產業系統）；沒有 MCP 時，computer use 可作為驅動 GUI 的通用解法；Boris Cherny 說「對模型來說，這只是 token」——另外還有知識庫對 MCP 線路協定的日期化紀錄簿，現為 2026-07-28 版：移除工作階段與 initialize 握手、在 _meta 中逐次請求協商版本、強制使用伺服器／discover RPC、由 MRTR 取代所有伺服器發起的請求、必填的 ttlMs/cacheScope 快取欄位，以及功能生命週期政策——含 12 個月淘汰期限和已淘汰功能登錄檔（Roots/Sampling/Logging、HTTP+SSE、OAuth DCR→Client ID Metadata Documents）
• Open-Ended Discovery Harnesses — 用於沒有已知最佳解、需執行數小時的代理程式任務之 Harness 設計；反覆出現的失敗是想法崩塌——太早認定單一方法，然後無止盡地微調；SwarmResearch 的兩項做法（以全域脈絡 Shepherd 引導彼此隔離分支的 Search Agents，每個代理程式一個工作樹）在 15 項任務中有 13 項追平或勝過 EvoX/CORAL，但所有方法在競賽啟發式上的表現都遠低於人類 SOTA。
• Optimizer–Evaluator Decoupling — eval-fix 迴圈的架構原則：提出修正的一方（程式碼代理程式、自動最佳化器或人類）絕不可評分；結果應由獨立評估服務評分，因為替自己工作評分的最佳化器會學會鑽指標漏洞，而不是改進代理程式
• Orchestration Sets Token Economics — Writer 的受控 Harness 替換測試——相同的 22 項任務、六個模型、評審與價格表，只變更協調層——在品質相同下讓每項任務成本下降 41%、token 下降 38%，實際耗時下降 44%，每個模型的成本都降低 33–61%；效率提升與模型無關，品質提升則幾乎完全隨基準能力擴展（Harness 槓桿，r = 0.99）；一項全新功能設有能力下限，能力低於門檻時，開放該功能反而導致失敗；另有稱為「token maxing」的軌跡、考量快取的有效輸入價格模型、限制上述結論適用範圍的「廠商衡量自家產品」注意事項，以及 Databricks 在數百萬行程式碼庫上的正式環境對照案例——三種已發布的第三方 Harness 在成功率相同下成本少一半，每項任務的脈絡量約相差 3.1 倍
• Output Length Calibration — Opus 5 在四種不同的輸出管道中預設都會寫得更長——對話回覆、代理程式敘述、寫入磁碟的檔案，以及更正敘述——投入程度參數無法控制其中任何一項：投入程度增加的是思考，不是說話，因此每個管道都需要各自明確的長度指示
• Parallel Agent Orchestration — 一位人類監督同時執行的代理程式團隊：OpenAI Codex 遙測的首批確切數據（28.6% 員工的同時代理程式數量最高達 5+；p99 約每日 71 代理程式小時）；代理程式彼此協作時會出現的問題（Bun 的 64-Claude 限制集合、Cursor 的協調失敗及 Harness 重建）、RCWT 固定預算下的協調稅斷崖，以及 Anthropic 五代代理程式參與的 12 小時群集實驗：固定 Harness，只更動模型——合併比例與程式碼共享互相取捨，直到 Sonnet 5；提示層級的組織圖毫無影響，而孤島化這項協調失敗，評分反而很好。
• Prompt-Cache Economics — 提示快取與提示壓縮是共同最佳化的兩個面向，不是獨立槓桿——CAPC 測得 Anthropic Sonnet 4.6 的快取 ρ ≈ 0.83，而不是壓縮文獻假設的 1.0；在約 3,500 個快取 token 附近發現階躍變化；根據三個定價常數推導出廠商無關的交叉點；並在公開基準上顯示，查詢感知壓縮比完全不壓縮就傳送昂貴 40.1%；資料集中首個對正式環境快取 API 進行端到端計費成本稽核（總計 $98.96，與 Anthropic 帳單核對後差距在 1% 以內）
• Reasoning–Acting Interleaving (ReAct) — 2022 年讓語言模型化身代理程式的提示抽象：每次交替進行自由文字思考、工具動作及其觀察結果，每次一組，使思考能依據環境剛回傳的資訊調整。CS329A 第 4 講將其教作工具呼叫的起源——它在各處都勝過純動作提示，在事實查核上勝過思維鏈，但在多跳 QA 上不一定；它把思維鏈的幻覺失敗換成檢索失敗。其後續發展更值得關注：交錯方式如今已蒸餾進思考模型，Harness 不再提供這種能力
• Repository Exploration Subagent — FastContext 主張，應將儲存庫探索（讀取／搜尋／定位）從解題工作中拆開，交由專責唯讀子代理程式執行；該代理程式平行呼叫工具，回傳精簡的檔案行號引用，讓解題者的脈絡保持乾淨——可減少主代理程式最多 60% token，並將 SWE-bench 解題率最高提高 5.5%
• Retrieval Inside the Reasoning Chain — CS329A 第 7 講教導的三階段階梯，是深度研究的前身：RAG 在思考開始前只檢索一次；代理式 RAG 允許模型在推理鏈中途，於特殊 token 之間發出搜尋，再將文件接回脈絡；Search-o1 新增文件推理模組，依據目前查詢逐份閱讀檢索文件，只附加擷取出的區塊。關鍵結果是文件數量曲線——增加文件時，直接推理與 RAG 會持平或下降，Search-o1 則會上升——因為要解決的失敗是對檢索噪音進行長脈絡推理，而非檢索本身。觸發訊號是模型自己的遲疑 token（「perhaps」、「alternatively」、「wait」）；Search-R1 則是透過 RL 將相同迴圈移進權重中
• Shared Harness, Differentiated Surfaces — OpenAI 將 Codex 和 ChatGPT Work 整合至同一套代理程式 Harness，只在 UX 層區分兩者——Git 狀態可見性、以差異為主的顯示方式、沙盒預設值——這正是 Boris Cherny 認為 Claude Code 的 Harness 最後只剩下的部分；Anthropic 則採取相反做法，依輸出類型拆分為 Claude Code 和 Cowork
• Stopping Under a Noisy Verifier — Wu 等人：驗證器與修復器都有雜訊時，驗證—修復迴圈的真實品質會先達高峰再下滑，但回報的接受率仍持續上升；停止邊界 b* = α/(α+β) 是修復器的特性——驗證器的辨識能力（Youden's J）只會判定你相對於該邊界的位置——VRR-Stop 依據真實邊際增益運作，並在 J ≈ 0 時採用保留最佳結果的備援方式。
• Task-Specific Organizational Hierarchies — ORCH（Ji、Hyun & Chen，Duke）：以人類組織理論中的整體／序列相依性建模橫向／垂直經理，再組合成依任務打造、而非預先固定的階層——在擴充版 CREW-Wildfire 基準（25 個任務、最多 50 個異質代理程式、8 個 LLM）上，最終分數／效率勝過四個具代表性的固定結構基準：人類設計者版本高出 63.97%/74.29%，評論器監督生成的 LLM 版本高出 43.63%/52.53%；此優勢不受執行它的 LLM 影響，整體表現也不會隨模型規模單調上升
• Ticket-Driven Agent Orchestration — 讓 Symphony 可行的反轉做法：將票單視為工作單位（不是工作階段／PR），採用 DAG 相依關係、可由代理程式擴展的工作圖，以及「目標而非轉換」
• Tool-Output Pruning — 在工具輸出進入歷史紀錄前，於代理程式與環境的邊界加以壓縮——SWE-Pruner Pro 顯示，取捨訊號原已存在於程式碼代理程式本身的骨幹網路中（線性探測 AUC 0.83），因此只要在現有預填執行上加掛一個 18M 參數的頭，就能取代獨立評分模型：在品質維持下，端到端 token 最多減少 39%；七種修剪器中，只有它從未增加 token，額外耗時約 15%——但在 SWE-Bench Verified 上，每種修剪器都讓其中一個骨幹網路的輸入 token 增加，也讓另一個骨幹網路的解題數減少。第二種於深度研究管線測量的修剪器補上放置位置的結果：切在哪裡比剪掉什麼更重要；僅在後期修剪會帶來測得的淨損失，而且兩篇論文都未報告金額成本。

衍生項目#

• Agent Control Plane Patterns: Tickets, Loops, Specs, and Memory Files — 分層代理程式控制平面綜論：票單是持久工作圖、迴圈是執行基本元件、規格／脈絡檔案是政策、記憶是有限召回、應用程式協定是執行階段邊界
• App Server vs MCP, and the Claude-Side Equivalent: Three Boundaries for Driving Agents — 代理程式整合邊界的兩個問題綜論。(1) App Server 和 MCP 並非競爭關係，而是位於不同平面：MCP 是模型↔世界的工具平面（一個連接器可撰寫一次、供所有介面使用，並由工具供應商負責營運與驗證），App Server 則是協調器↔執行階段的工作階段平面（執行緒生命週期、回合、結構化事件、逾時——這些都不屬於 MCP）。唯一重疊處是動態工具呼叫，此時應依作業需求判斷：可重用、跨介面、第三方的功能由 MCP 勝出；限於工作階段、涉及敏感認證的功能則由協調器注入動態工具勝出（linear_graphql 模式——token 不會到達子代理程式容器，將已記錄的 MCP 攻擊面中惡意中繼資料及惡意抽換，縮減為第一方程式碼；代價是穩定性仍屬實驗階段，且無法重用生態系統）。兩者可搭配使用：「對模型來說，這只是 token。」(2) Claude 沒有文件記載的公開 App Server 協定同等產品；它的方案從兩側包夾——claude -p（驅動產品 CLI，承接累積完整的 Harness：權限分類器、技能、脈絡檔案、MCP 連線；自動模式會中止而不會在無人值守時掛起）和 Agent SDK（在原始執行階段上打造不同產品——Claude Design 的週末原型）。判斷方式：若產品 Harness 是價值所在，且協調形態是批次／擴展，便驅動 CLI；若代理程式是需要自有工具、事件與 UX 的不同產品，便基於 SDK 建置；App Server 居中的位置——在產品 Harness 上提供結構化工作階段控制——正是 Symphony 從 tmux 演進至協定所顯示的需求層，也是 Claude 端協調器目前從任一側近似實作的層
• Authority and Audit Survive Abundance — 回答兩個 #oq/now 問題的綜論。(1) 模型升級時，兩種主張互不支配：縮減原則適用於指示腳手架（請求形式的行，透過消融測試後刪除）；結晶原則適用於權限腳手架（以證據為門檻的權限，能力提升無法取得，而且禁止循環授權給模型）——依每行編碼內容分類（請求或限制／紀錄），而非看其位置；降級斷路器讓權限端的升級時機不必經過判斷。(2) 檢索層在長脈絡近乎免費後仍然存在，因為只有成本這一面以 token 計價：逐區塊治理不能放進它所監管的脈絡視窗中（「模型答應會忽略」不是邊界），視窗內的歸因是模型證詞，而稽核需要可核對的紀錄——選擇過程讓引用紀錄不再只是表面形式，而這項要求也適用於編譯過的 Wiki。成本會隨價格消解；治理與稽核則只會在不再需要它們時消解。
• When Knowledge Layers Disagree: Context Files vs Memory, and Conflicting Sources at Compile Time — 代理程式知識基底衝突處理的雙問題綜論，共享一項核心原則：以來源脈絡與通道權威解決分歧，絕不靠內容可信度或新舊程度；分歧本身是第一級訊號，應送進維護迴圈。(1) 脈絡檔案與記憶：依分歧類型區分——政策方面一律以脈絡檔案為準（這是人類撰寫、經 Git 審查、完整性高的通道；代理程式撰寫的記憶只是供參考的回憶，無法因為較新而取得權威性，依據 TMA-NM 洗白定理）；事實方面則兩者都不優先（兩者都是現實的快取；儲存庫／即時狀態才是事實來源，因此應先驗證，再修正過時的快取）；每種情況都要將衝突記錄下來，供 lint／修剪處理，而非悄悄破壞其中一方——記憶絕不覆蓋政策，脈絡檔案也只會透過自身經審查的通道更新。(2) 編譯時的衝突來源：從知識庫自身實務及三個實例萃取出五步驟協定——先對齊概念再宣告衝突（多數矛盾其實無法直接比較，差別可能在指標、族群、時間軸、單位）；附上來源脈絡與證據等級，依方法與誘因衡量（絕不取平均）；在每個受影響頁面明確記錄實質衝突並建立雙向連結；將其轉為受追蹤的開放問題；並將衝突解決視為編譯／lint 時的圖書管理工作，讓查詢繼承結論，而非重新裁定
• Where Does Agent Harness Work Remain Durable as Models Improve? — 模型能力提升時仍持久的 Harness 工作，位於外部現實邊界：儲存庫本地的事實來源、機械式驗證、脈絡預算、隔離、工具契約，以及人類決策介面；能力腳手架則會縮減
• The Future of Agent Interfaces — 介面的未來將分層發展：人機協作採用原生互動模型；結構化動作採用 MCP/API；代理程式執行階段採用應用程式協定；舊式 GUI 則以 computer use 作為備援
• Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework — 三種在小規模時有效、部署時卻會彎曲的控制機制：ReAct 的列舉動作保證可從提示移至失效時封鎖的執行階段（此時限制項目不再是脈絡大小，而是政策涵蓋範圍）；自行修改關卡若要判定可接受性，需要外生的效果測試，知識庫列出正式理由與三種可行設計；Zero Trust 電子書的原則、控制領域及階段雖不依賴廠商，其 21 則 Pro-tips 中卻有 17 則提到 Claude Code——耦合發生在操作範例，而非要求本身，且與 IETF 軌道的目標狀態僅有一項實質差異
• Harness Value Is a Product, Not a Score — Why the Artifact-Payoff Questions Keep Returning Partially Answered — 三項 #oq/now 議題的綜論，三者共享同一障礙。所有回報 Harness 或指示產物價值的測量結果，都是端到端分數；而分數是至少四項因素的乘積——啟用（產物是否進入脈絡）、遵循（是否依循，並在整條軌跡中維持遵循）、產物品質、任務餘裕——三個問題都試圖在不介入的情況下，從乘積取回其中一項，因此無法識別。Lin 等人首度分開測量啟用與遵循，兩者差距顯著（Qwen3-235B 載入率為 0.961，遵循率為 0.350；Opus 4.6 則為 0.957/0.757）；evolver 端的控制實驗也顯示，寫作者能力相差三個數量級時，產物品質幾乎持平——變數在消費者，而非產物。知識庫中真正解決其中一項問題的方法，都透過介入打破乘積（消融非劣性、投入程度掃描、有技能／無技能組別、執行端的動作紀錄）；所有試圖使用較低成本觀察性代理指標的方法，都可預測地失敗：模型自我檢視提示會造成實際傷害，因為指出失敗會讓失敗浮現；未驗證的 LLM 評判器經機率校正後會扣減 33–41pp，只有排序結果仍可信；甚至由紀錄推導的技能載入率，也混淆了「從未嘗試」和「嘗試了，但格式遭拒」。新增交叉連結：指示遵循能力會沿著兩個獨立軸線耗盡，相關測量出自彼此未引用的頁面——寬度（Eliav 同時約 80 條規則的下限，不受格式影響）與深度（Lin 等人測得的軌跡內漂移；弱勢級由 0.52 降至 0.13），因此 Harness 作者需要兩種預算，而不是一種。同時採用弱模型與豐富 Harness 的配置會在兩個軸線上一起失敗
• Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling? — 是——HTML 能提高並重塑人類注意力的上限，卻無法移除上限；膨脹從文件長度移至產物過度擴散／照單全收；模型能力提升後，這項上限的約束反而更強（與面向模型的 Harness 縮減正好相反）
• Single General Agent vs. Multi-Agent Coding Architecture — 重新劃定界線，回答 agent-harness-engineering 的開放問題：模型能力提升後，單一通用代理程式勝過特製、手工設計的多代理程式系統（苦澀教訓）；但單一整塊脈絡的代理程式確實不敵角色分離的脈絡隔離與獨立評分器——這些做法能在模型改進後繼續有效，因為它們解決的是結構限制（二次方注意力、Goodhart），而非模型弱點
• What Are AI Tools? — AI 工具版圖及類別總覽
• What Makes a Self-Improvement Artifact Transfer? — 回答 HarnessBank／Caltech 矛盾所留下的產物轉移問題：產物的轉移範圍與其編碼的規律所適用範圍相同——配合解題者打造的產物（Harness 修補、驗證指示、依角色配置模型組合）只適用於具有相同病灶的解題者，且每次發布都會貶值；配合領域打造的產物（蒸餾知識、儲存庫慣例、技能）則能跨越解題者汰換而留存，因為重用時領域固定不變。跨模型移植失敗和跨版本貶值其實是同一現象；可以在撰寫時選擇可轉移性（Caltech 的結構描述）；產物不會轉移時，能轉移的是程序
• What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — Harness 演進群集的三個問題綜論。(1) 並非所有腳手架都會移入模型：行為請求會消失（逾期的請求甚至會造成傷害），但有五種類別會留存——邊界執行（驗證、隔離、安全規則等限制）、組織專屬紀錄（沒有模型能推知的儲存庫本地事實與決策）、刻意設計的身分（角色／品牌語氣，依設計在能力提升時保持穩定）、推論／部署結構（沒有「移入模型」的可能），以及面向人類的易理解性（隨模型進步而增加）；另有一種會朝相反方向流動的類別（溝通調整，隨預設輸出變長而新增）。苦澀教訓的例外原則可分類：編碼任務先驗的結構會移入模型；編碼邊界、紀錄、身分或服務算術的結構則不會。(2) 疊加指示有可偵測的特徵——消融非劣性（移除指示後品質不變、token 減少），以及反向劑量反應（措辭越強，結果越差，即投入程度反轉的特徵）；以模型原生行為作基準，便宜又適合作為前置篩選；知識庫中尚無工具能將此流程自動化。(3) 如果模型改進停滯，為下一個模型打造仍能平順退化：它是在發布週期上的低成本選擇權——停滯付出的只是權利金（等待中的原型過期），而非公司本身；潛在能力餘裕讓有效能力在停滯後持續上升；Harness 再累積又會成為正確的工程做法；耐久層則成為競爭焦點