隨模型進步而縮減的代理程式 harness

資料來源#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Beyond RAG: Building Agentic Document Workflows with LlamaIndex
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Claude Fable 5 and Claude Mythos 5
• Coding Agents and Technical Debt
• DarwinX: Evolving Agent Harnesses Through Natural Selection
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• Fable's judgement
• Garry Tan: Own Your Intelligence
• HarnessTax: How Much Does the Harness Matter for Coding Agents?
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• How We Migrated 11 Million Users to Cline's Biggest Harness Upgrade
• Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models
• Prompting Claude Opus 5
• Recursive Self Improvement for Coding Agents
• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI
• The new rules of context engineering for Claude 5 models

摘要#

harness——提示詞、技能、鷹架、機械式驗證——的存在，是為了補足底層模型尚做不到的事。模型進步後，harness 應該縮減，而不是擴大。Boris Cherny 明確預測，Claude Code「一年後可能只剩 100 行程式碼」。Cat Wu 表示，團隊在每次模型發布時都會通讀整份系統提示詞，刪除新模型已能原生處理的內容。這個原則有兩個方向：harness 過去注入的能力移入模型；harness 過去提供的拐杖則會成為拖累。

待辦清單是典型案例#

Cat Wu 的案例研究：

• 早期 Claude Code：要求它重構 20 個呼叫點時，模型會改 5 個就停下。團隊加入明確的待辦清單工具（「我們團隊的 Sid 當時說，人會怎麼做？列張清單，一項項處理。」）。透過積極提示使用這個工具，模型完成了全部 20 個。
• 從 Opus 4 開始：模型會自發使用待辦清單，不再需要積極提示。
• 現在：待辦清單已「降低重要性」——模型可能會用，也可能不會；不需要提醒，主要是為了讓使用者看得到而保留。

那根拐杖（強制使用待辦清單的提示詞段落）被移除了；工具則因另一個理由（介面價值）留了下來。

Boris 的說法：100 行#

「我認為 Claude Code 本身一年後可能只會有 100 行程式碼。」

若照字面理解，這是誇張說法，但方向確實如此：

• Anthropic 現在內部使用的模型，與對外發布的相同，因此內部 harness 的經驗可以轉移
• 每次模型發布都讓團隊能刪除提示詞段落、縮減備援邏輯、移除安全包裝（依 Cat Wu 所言：「如今所有安全機制——提示詞注入防護、命令的靜態驗證、權限模式、人類介入——都會變得較不重要，因為模型會直接做出正確選擇」）
• 產品介面不再是「harness 做什麼」，而是「模型在哪裡執行」——CLI、行動裝置、網頁、IDE 都共用同一套模型邏輯

反過來看：能力遷入模型#

Boris 表示，Opus 4.7 會自發開始執行迴圈：

「我會跟它說『拉取這個資料查詢』。它會說『我注意到資料正在變動——我會啟動一個迴圈，每 30 分鐘回報一次。』」

/loop 原語（見 Agent Loop Pattern）原本是 harness 功能；在 4.7 中，它正逐漸成為模型原生行為。harness 原語不會消失——但使用者不再需要呼叫它。

這可以推廣到更多情況：凡是 harness 透過提示詞段落教模型如何做的事，都可能遷移到下一代模型的訓練資料中。

最清楚的示範：Fable 5 不靠 harness 玩 Pokémon#

2026 年 6 月 Fable 5 發布，提供了整套論點最清晰易懂的版本。較早期的 Claude 模型「即使有提供額外實用工具的 harness 協助，玩 Pokémon FireRed 仍然很吃力」——包括地圖、導航輔助和遊戲狀態讀取。Fable 5 只靠極簡、純視覺 harness 就打敗了 FireRed：原始遊戲截圖，除此之外什麼也沒有。補償空間與視覺推理不足的鷹架沒有被改進——它被刪除了，因為這項能力已進入模型。同樣的模式也出現在 Fable 的記憶結果中：以檔案為基礎的持久記憶，讓 Fable 玩 Slay the Spire 的表現提升幅度，是 Opus 4.8 的3 倍——模型更擅長使用 harness 提供的功能，因此不再需要那麼多手把手引導。視覺能力和長期記憶正是 2025 年代理程式最需要鷹架的面向；如今它們已是最先消融的能力之一。

錯誤方向：harness 膨脹#

另一種失敗模式比沒有 harness 更糟——它會直接降低模型表現：

• Cat Wu：「在[一個月]的時間軸上，模型能做到什麼」是 PM 最難預測的事；替舊模型過度指定 harness，會浪費 tokens，而新模型在沒有監督時能更妥善地運用這些 tokens。
• Matt Pocock：25 萬 token 的系統提示詞，會在模型開始做事前就把它推進愚鈍區（見 Context Window Smart Zone）。
• 反覆注入能力會逐漸形成矛盾：案例 A 遵守規則 X，案例 B 遵守規則 Y，最後模型無法判斷該套用哪個規則。

天花板的獨立測量（2026-08-04）。 本文所有支持縮短提示詞的論點都來自 Anthropic，且著眼於tokens——Pocock 的愚鈍區、Cherny 的消融、Thariq 所說逾 80% 的刪除。Eliav 2026（arXiv 2607.19257，empirical，唯一作者，涵蓋五個模型，包括 Sonnet 5 和 Haiku 4.5）提供了第一個外部測量，所約束的是另一個量：提示詞中每一條指令都被遵守的比例，在40 條同時存在且可驗證的規則時大幅下降，到 80 條時降至零，並在 160 條時維持為零；無論以 markdown／純文字／散文／表格呈現，或放在兩個提示詞位置中的哪一處，結果都相同。規則彼此不同且個別都可滿足，因此這不是指令複利，逐行消融也找不出問題——這表示 Cherny 逐行加回的方法雖然正確，卻無法察覺這種情況：一份每行都有個別理由的提示詞，整體仍然可能行數太多。「每 6 個月刪一次你的 CLAUDE.md」如今有了可參照的數字，而且衡量的是條目數，不是長度。

供應商將其明確寫成指令（Opus 5，2026 年 7 月）#

以上都是從團隊工作方式推論而來。Anthropic 的 Opus 5 提示詞指南（vendor-claim）是供應商首次在公開文件中以祈使句寫出精簡規則——而且對這個論點做了兩項延伸：

1. 有些鷹架不只是多餘，還會造成傷害。「如果你的提示詞包含明確的驗證指示……請移除：這類指示會讓 Claude Opus 5 過度驗證，移除後可減少浪費的 tokens，品質也不會下降。加入獨立驗證步驟的舊式 harness 鷹架也是如此。」Cat Wu 的紀律是刪除模型不再需要的提醒，以節省 tokens；這裡則是刪除會讓輸出變差的行，因為它們加強了模型如今已能自行執行的行為。若團隊因為「留著也沒壞處」而保留過時指令，那就錯了；如此一來，每次發布都進行精簡便不再只是整理，而是正確性上的義務。詳見指令複利；同一份指南也要求重新驗證提示詞側的視覺權宜做法，因為它們「可能已不再需要」——這正是 Fable 5 玩 Pokémon 的結果改寫成遷移建議。

**2. 這項檢視有兩個方向。**同一份文件也新增提示詞：Opus 5 的對話式回覆、代理程式敘述和書面檔案預設都更長，而且 effort 不會控制這些長度，因此需要長度校準提示詞；這項需求在上一個版本還不存在（Output Length Calibration）。能力鷹架移除，溝通鷹架加入。下文所述的模型端／人類端不對稱（HTML as the New Markdown），如今不是出現在兩個產品之間，而是同一份系統提示詞裡。

實際刪除量：系統提示詞逾 80%（Claude 5，2026 年 7 月）#

Thariq Shihipar 的脈絡工程文章（2026 年 7 月）提供了本文最具體的數字：「我們為 Claude Opus 5 和 Claude Fable 5 等模型移除了 Claude Code 系統提示詞中超過 80% 的內容，在我們的程式碼評估中沒有可測得的損失」（由 Anthropic 測量，但未公布資料）。他的說法是**「解除束縛」**——團隊發現自己對模型的限制過多；閱讀內部使用逐字稿便能看出原因：單一請求中出現互相衝突的指令（「適時保留文件」與「不要新增註解」），系統提示詞、技能和使用者要求彼此牴觸。模型通常能解決衝突，但必須花費思考來仲裁；更乾淨的脈絡便不需要這樣做——這就是指令複利所述逐漸走向矛盾的現象，在供應商自己的逐字稿中得到印證。

最典型的新舊對照是註解規則。舊系統提示詞：「預設不寫註解。絕不要寫多段落的文件字串……最多一行短句。」新系統提示詞：「撰寫程式碼時，讓風格貼近周遭程式碼：配合其註解密度、命名方式和慣用寫法。」原本對部分提示詞並不適用的硬性規則（例如使用者有文件偏好、複雜程式碼需要真正的註解區塊），改成委派判斷——這項護欄是為了補償舊模型較弱的判斷能力而接受的取捨，如今因為判斷力已移入模型而刪除。

這套精簡紀律現在也產品化提供給使用者：claude doctor／/doctor 指令會用同樣方法調整你自己的 CLAUDE.md 檔案和技能——Cat Wu 每次發布都通讀整份提示詞的流程，現在成了任何人都能執行的工具。

同樣的做法，也推薦給使用者（Willison，2026 年 7 月）#

上文的註解規則改寫，是 Anthropic 對自家系統提示詞所做的調整。Simon Willison（2026-07-03，practitioner-opinion）記錄了 Cat Wu 和 Thariq Shihipar 在他主持的 AI Engineer World's Fair 爐邊對談中，也向使用者提出相同建議：讓 Fable「自行判斷怎麼做，而不是規定它該如何工作」。他們舉的實例也涉及註解規則，只是換了領域——你可以告訴 Fable「只有大型功能才使用自動化測試；小型文案或設計變更不要更新並執行測試」，但「告訴 Fable 在決定是否寫測試時自行判斷，會更好」。

這帶來兩點。精簡義務轉移到使用者的提示詞上，而本文描述的機制都無法觸及那裡——某人 CLAUDE.md 中的一條硬性規則，和 Anthropic 每次發布都會消融的內容屬於同一類產物，但沒有人會對它執行 SIMPLE=1。而且替代方案是委派，不是刪除：刪掉規則會讓模型自行依預設處理；「自行判斷」則是交付一項它如今知道該由自己負責的決定。本文所有測量都針對刪除形式；委派形式是否勝過明確規則或完全不說，在本文和其他任何語料中都尚未測量。

Willison 自己的測試，是把委派用於模型路由：「所有程式設計任務都自行判斷適合的較小型模型，並在子代理程式中執行。」 這就是上文 Nathan 對模型決定使用介面的觀察，只是換了目標——由使用者透過提示詞，把模型選擇交給模型，而不必等供應商來處理。證據力不高：只有一位開發者，沒有測量，這項建議本身還是轉述（來自 Jesse Vincent），回報的結果只是「看起來運作得不錯」，以及 Fable 的額度「消耗速度似乎比以前慢了」。

外部佐證與一種機制（DHH，2026 年 8 月）#

上文的 80% 刪減，是 Anthropic 對自家產品的說法。DHH 在外部也引用同一數字（Lex Fridman #501，2026-08-26，practitioner-opinion）；他補充的不是證據，而是一種機制——它把發現重新詮釋為「模型已不需要這項指令」，而是「這項指令正在積極傷害模型」：

「他們發布的 Opus 5 系統提示詞……縮短了 80%，因為代理程式不只需要少得多的人類指示，過度規定的指示甚至會傷害它。任何遇過自以為是的老闆的程式設計師，都知道那是什麼感覺。老闆走進房間，什麼都不懂，卻開始告訴你該怎麼寫程式、怎麼編碼。你會怎麼做？你會鬧彆扭。如果有人強迫你做違背自己判斷的事，你就會寫出更糟的程式碼。為什麼代理程式會不一樣？」

這是對上文 SIMPLE=1 結果的人格化解讀——消融發現模型沒有提示詞時稍微更聰明；以刪除為框架，只能說移除了不起作用的指令；以這種框架來看，移除的則是干擾。從測量結果無法區分兩者，而自以為是的老闆這個故事只是事後解釋，並非真正的說明。可將它記為實務工作者中涵蓋面最廣、支持度卻最低的解讀。

他也提出一個值得並列記錄的當下反例：他仍在自己的 AGENTS.md 中保留一條常設規則，禁止在 Bash 中使用提早退出的前置條件；「每次抓到代理程式這麼做，我都得敲敲它的後腦勺。」模型無法逐漸遵守的風格限制，正是消融紀律所說應加回的殘餘規則。

以及對下文 harness 程式碼庫反向數據的預測。 談到所有自行打造代理程式協調層的人，他說：「每個人都在打造自己的小型 gas town、自家的代理程式協調和設定。**這些問題都會被解決。**我們不必人人都打造自己的協調 harness……我有點驚訝這種狀況持續這麼久，也驚訝主要實驗室還沒有吸收更多這類工作。」他認為這種快速變動來自新典範，而不是持久需求——他以每週冒出一種 JavaScript 框架的年代作比喻；這是把縮減論點往上延伸一層，從提示詞延伸到編排層。截至本文彙編時，這個說法無論正反都尚未被證偽。

來源方法：消融，以及沒有提示詞時的提升#

Cherny 在 YC 訪談（2026 年 7 月）中首次說明逾 80% 刪除的方法，並從三個方面加強了標題所述的論點：

1. 這項刪除是消融，而且每次模型發布都會執行。「刪掉整份系統提示詞，再逐行加回去，找出每一行各自造成什麼影響」——這種評估透過刪除來測量每一行的貢獻。同樣的紀律也適用於工具（「我們一直在取消發布工具」）。加回規則完全以經驗為準：別猜模型需要哪項指令——實際執行產品，觀察它是否反覆在同一件事上跌跤，只有這時才加回那一行，「因為模型每次都會讀到這項指令」。
2. 結果比「評估沒有損失」更強。未公開記錄的環境變數 SIMPLE=1 會移除所有提示詞，包括工具的提示詞——這是團隊一直使用的消融開關——而「有趣的是，沒有這些提示詞時，模型其實稍微更聰明一些」。留下的提示詞是為了產品行為（幫助模型以產品使用者期望的方式行動），而不是為了能力。這使 Thariq 上文所說的「沒有可測得的損失」進一步成為輕微的測得增益，也為使用者提供同樣的實驗方式：--system-prompt 可接受完整替代內容。
3. harness 剩下的部分根本不是提示詞。「看看如今 Claude Code harness 裡的程式碼，幾乎全部都與安全性、權限、靜態分析有關，還有一大堆介面程式碼」——留下來的 harness 正是下方「已解答問題」所預測的邊界執行殘餘，而且這是由 harness 所有者親自說明。

如今對使用者的推論也成了明確建議，而非推測：「每 6 個月刪掉你的 Claude MD。刪掉你的技能。刪掉你的 hooks。看看模型會怎麼做」——精簡成了人人都該遵循的行事曆紀律，而不只是供應商的工作。

非 Anthropic 的檢驗：OpenAI 推出的架構預設了這個論點#

以上內容都來自 Anthropic——Cherny、Cat Wu、Thariq、Opus 5 文件、Fable 5 發布。在 OpenAI 於 2026 年 7 月合併 ChatGPT Work 之前，這個論點一直沒有獨立的供應商佐證；相關內容由 Akshay Nathan 在 Latent Space 撰文介紹（Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI，practitioner-opinion）。它沒有重述這個論點——Nathan 從未談到提示詞精簡——但在兩個方面以此為前提：

1. 介面差異化後留下的部分，與 Cherny 所說的 harness 殘餘相符。OpenAI 以同一個共用 harness 執行 Codex 和 ChatGPT Work，只在三處做出差異：git 狀態可見性、以差異為主的思維鏈顯示，以及沙箱預設值。這些都是權限與介面——恰好是 Cherny 列出的 Claude Code 消融後所留項目（「安全性、權限、靜態分析……還有介面程式碼」），只是從反方向得出（將同一介面分成兩種，而不是一路刪到不能再刪）。若能力仍存在各介面專屬的提示詞鷹架中，「同一個 harness，服務截然不同的使用者」便無法發布。見 Shared Harness, Differentiated Surfaces。
2. **路由成了模型行為。**有人問 ChatGPT 切換到 Work 模式是否由路由器決定，Nathan 回答：「這是模型做出的判斷……它看得出你想做的事更適合在 Work 模式下處理。」原本應是 harness 邏輯的派發規則，如今成了模型判斷——與自發迴圈觀察到的遷移相同，只是發生在產品介面層。

**同一來源中的反向趨勢。**OpenAI 同時也在擴增面向使用者的控制項：「有 32 種選項」，涵蓋模型類別和推理層級，還有滑桿、Ultra 和子代理程式控制項；Nathan 也承認「有人可能會說現在的選項太多了，我們正在努力簡化。」這與本文論點並不矛盾；它再次呈現模型端／人類端不對稱，而人類端明顯超出所需。OpenAI 正在精簡的是人類的設定介面，而不是模型的提示詞。

第二個非 Anthropic 的檢驗：四工具 harness 抵達 Pareto 前緣（Arena.ai，2026-09）#

HarnessTax（HarnessTax: How Much Does the Harness Matter for Coding Agents?，empirical）是第三方基準測試，而非供應商說法；它直接佐證了本文論點的反面命題：只有四種工具（讀取／寫入／編輯／bash）、schema 長 2,873 個字元的 harness Pi，在 SWE-bench Lite 和 Terminal-Bench 2.0 上都抵達 Pareto 前緣，而 Claude Code 有 23 種工具，schema 長 77,000 個字元。涵蓋七個模型與兩項基準測試時，Claude Code 首次呼叫的平均脈絡長度是 Pi 的 約 13.7 倍，但成功率差異僅在 ±2–5% 以內，成本最高卻達兩倍。這是整份語料中最清楚的證據，顯示精簡的 harness 並不會比專有 harness 少了能力；評估方對任何一方都沒有利益關係。它沒有提供下文程式碼庫規模反向數據的資訊——Pi 的提示詞很精簡，但研究沒有測量 Pi 的程式碼庫大小——因此它佐證的是提示詞鷹架的主張，而非程式碼庫的主張。

流程：每次發布時都通讀系統提示詞#

Cat Wu 的紀律：

「我們會通讀整份系統提示詞，逐一檢視每個段落：模型真的還需要這個提醒嗎？若不需要，我們就會移除。」

這是一種反向做法——大多數團隊只會不斷新增提示詞，不會刪減。按照模型發布節奏定期執行，才能避免 harness 不斷堆積。

為下一個模型打造，而不是為眼前這個#

Boris 提出的反直覺推論：

「我們當時想打造一個還沒找到產品市場契合度的東西，也知道因為我們是為下一個模型打造，所以 6 個月內都不會有產品市場契合度。」

大多數產品是為發布時搭配的模型打造。Anthropic 則為六個月後的模型打造 Claude Code——接受它現在還不太能用，押注下一次發布會補上差距。這改變了「harness 工作」的意義：不再是「讓目前的模型能用」，而是「打造一個模型到來時就能運作的產品介面」。

Cat Wu 的說法是：「打造目前未必能運作的產品其實很重要，這樣你才知道產品要能運作還缺什麼，等最新模型推出時，就能直接換上去。」

Dan Carey 提供了最清楚的回顧案例：Claude Design 早期原型的缺口，不是靠巧妙工程填補，而是靠 Opus 4.7 發布來補上（「模型發布就像推動所有船隻的潮汐」）。下一代模型與 AGI 稻草人論點的校準，另有專文：Build for the Next Model。

從檢索端提出相同主張——以及它止步之處#

本文所有測量都是在程式碼 harness 上進行。Doulcet 對 2024→2026 年 RAG 的回顧（AI Engineer Singapore 2026，practitioner-opinion，LlamaIndex 供應商 COI，沒有測量）指出檢索堆疊也有相同趨勢；Jerry Liu 發布文章時的摘要，正是以檢索領域的用語表達本文論點：「隨模型進步，我們將更多邏輯卸載到代理迴圈中——而檢索層也因此能變得更簡單。」

具體案例完整展現了這條演進路徑：

• **刪除手寫查詢轉換。**HyDE（草擬假設答案，再將答案嵌入）以及多重查詢加 Reciprocal Rank Fusion，是 2024 年在一次檢索呼叫內彌合使用者語言與文件語言落差的做法。2026 年的結論是刪除，而非調校：「兩者都被代理迴圈吸收了——能評分和改寫的代理程式會動態執行這些工作，而且若第一次嘗試未命中，也能恢復。」只保留為閱讀 2024 年代碼的基本知識。
• **迴圈本身也被吸收到權重中。**Search-R1／R1-Searcher（2025）透過 RL 訓練推理模型在思考途中呼叫 search()，使團隊過去手寫的檢索迴圈「最後直接烘焙進模型本身」。Adaptive-RAG 從另一端著手，透過路由讓大多數查詢完全不進入任何迴圈。這是本文論點在另一個領域中最精準的表述：「工作流程的形狀會保留下來；每個步驟內執行的內容則持續變化。」

它止步之處才是更有用的部分，而且本文此前還沒有這項適用範圍條件。簡報指出沒有變簡單、反而更困難的層是解析：將頁面上的位元組轉成結構。這一層是對模型看不到的輸入進行操作的確定性軟體，其失敗發生在位元組層級，而不是判斷層級，這恰好對應Layerwise Omission Attribution中確定性／行為性的區分。值得提煉的一般結論是：**縮減的是替代模型判斷的鷹架；持續存在的是會改變哪些內容能送達模型的機制。**這與下文 Pocock 反方觀點中相同的界線（機械式驗證是基礎設施，不是指令），也與將代理程式工作凝結為工作流程中的權限與指令區分相同；如今又多了一個來自第四個領域的案例。

目前唯一的張力在於，簡報也在推銷解析器。它自己的成本與準確率圖表顯示，一般前沿 VLM 在高設定下與專用解析器的差距約為 9 分——比搭配圖表的文字所聲稱的差距小，也正是本文論點會預測的方向。該處將此列為待解問題，而非在此定論。

反方觀點：harness 仍然重要#

並非人人都同意。Matt Pocock 認為 harness——回饋迴圈、深模組、機械式驗證——就是天花板：

「如果你的程式碼庫沒有回饋迴圈，你就永遠永遠永遠無法從 AI 得到像樣的 AI 輸出。回饋迴圈的品質，基本上會決定你的 AI 寫程式能有多好。那就是天花板。」

綜合來看：**提示詞鷹架會隨模型進步而縮減；機械式驗證仍不可或缺。**測試、型別、linter、隔離的審查脈絡——這些都是 harness 提供的基礎設施，不會像能力一樣遷移到模型中。

反向數據：harness 程式碼庫並未縮減#

以上所有測量都是針對系統提示詞。OpenHands 2026 年 7 月的 GitHub 分析（Coding Agents and Technical Debt，case-study）是整份語料中首個檢視程式碼庫的研究，結果卻指向相反方向：四種程式碼代理程式 harness——OpenHands、Codex、OpenCode、Hermes——各有 105 萬至 175 萬行，並在 12 個月內吸收 5,679 至 7,736 個合併的 PR；Codex 的月合併 PR 數量也從 2025 年年中約 124 個，加速到一年後約 1,000 個。完整分析與供應商利益關係的注意事項，見 Harness Build-vs-Buy。

仔細檢視後，大部分表面上的衝突可分三步消解：提示詞不等於程式碼庫（刪除提示詞的 80%，不會刪除應用程式伺服器或介面的任何程式碼）；Cherny 自己列出的殘餘正好說明百萬行程式碼包含什麼——「安全性、權限、靜態分析……還有一大堆介面程式碼」並非小程式，而 OpenHands 的介面層就有 313,000 行（Agent Canvas 246,000 行 + CLI 67,000 行），還沒算上伺服器或執行環境；而且精簡紀律本身也會帶來 PR 數量——Cat Wu 每次發布都通讀提示詞、Cherny 逐行進行消融，都是合併的 PR，因此模型發布速度變快會增加維護流量，同時降低提示詞的穩定狀態大小。變動量和規模是不同變數，而本文一直只測量其中一個。

調和之後仍留下「100 行」預測的一個方向性問題：這是對 harness 程式碼庫的預測；目前唯一有人測量的該變數趨勢是上升，而且這是一項case-study公開資料，對照的是明確標示為誇飾性prediction的預測。這還不算證偽——預測特指 Claude Code，而 Claude Code 是閉源的，不在比較之列——但它是針對該參照類別的第一項反向證據。

反向數據最尖銳的版本：搜尋程序在原理上就無法精簡 harness（2026-08-13）。在語料中所有由代理程式最佳化自身 harness 的案例裡，結果都是擴增——Cline 加入重試邏輯和 PID 追蹤；Ouroboros 發布了 175,755 行程式碼，在 161 天裡只有一個月出現淨刪除。DarwinX（Salesforce，arXiv 2608.07545，empirical）證明這是結構特性，而非偶然：它的選擇規則要求每個子代解出的題目集合都必須是親代集合的超集，並明確說明：「因為編輯只會往上疊加，分支會逐步累積能力，而不會以一換一。」放棄任何能力的變體都不具備繼承資格；只有涵蓋兩個親代勝出題目聯集的合併才會保留。因此，這種機制的適應度函數完全沒有計入規模，而產出也符合預期：Terminal-Bench 2.1 新增七種技能；WebArena-Infinity 新增四種瀏覽器技能，並改寫一條提示詞規則；各處都沒有回報刪除。兩點提醒可避免將此視為推翻論點。其一，這是由機器撰寫的 harness，而本文整套紀律都建立在人類閱讀提示詞並判斷模型還需要什麼——目前基準測試上的任何適應度訊號都無法表達這種判斷，因為多一條冗餘規則只會多花幾個 tokens，卻不會讓任務失敗。其二，DarwinX 唯一回報的刪除反而支持本文一方：它演化出的系統提示詞將絕對禁令（「只能透過 UI 互動……不得直接寫入應用程式狀態」）改為有界限的委派——正是上文註解規則案例研究所述從硬性規則改寫為判斷，只是這次靠選擇而非品味得出。

第四種調和：以全面改寫而非精簡提示詞進一步釐清（2026-09-24）。Cline 說明其 VS Code 擴充功能的遷移過程（How We Migrated 11 Million Users to Cline's Biggest Harness Upgrade，2026-09-02，empirical，供應商說法）並不是本文定義下的縮減測量——2024 年式 harness 的修正方式（從 XML 文字中解析工具呼叫，這是適用於 2024 年模型的可靠機制），是替換呼叫機制，不是精簡提示詞；各介面的 VS Code 轉接層變小（舊版約 76,000 行，縮至 21,000 至 42,000 行，來源中的兩個數字尚未調和），只是因為大部分邏輯移入跨產品共用的 SDK（@cline/core 91k + @cline/llms 178k + @cline/agents 2.2k + @cline/shared 17k），其總和比被取代的整體程式還大（見 Shared Harness, Differentiated Surfaces）。與下文 OpenHands 的反向數據一起閱讀，兩者從相反方向說明同一件事：各介面看似變小的 harness，總體規模可能反而增加；而真正改善的指標——task.mistake_limit_reached，6.34%→0.62%——來自一種本文沒有概念可用以精簡掉的機制替換。

反向數據的第一個反向證據，而且完全來自另一條軸線（2026-09-21）。以上所有程式碼庫測量，都是針對程式碼代理程式 harness。OpenAI 的 GPT-Live-1 發布文章（2026-09-10，vendor-claim）所附的客戶推薦，則在互動 harness 上指向相反方向：將串接式 STT→LLM→TTS 語音系統改為單一全雙工模型，「讓我們的程式碼庫簡化了 80%，並移除了23,000 行程式碼」（共同創辦人暨 CTO Tony Stoyanov；原始頁面所載資訊沒有公司名稱）。請按照它應有的證據層級看待——它是發布文章中的客戶推薦，沒有描述基準架構、「程式碼庫」也未定義，而且供應商有充分理由選用能公布的最大數字。儘管如此，它仍值得記錄，因為這是整份語料中唯一朝程式碼庫規模縮小方向的數字，而且所述機制正是本文已有的概念，而不是新概念：刪除的是協調層——VAD、輪次邊界預測、對話狀態、三個模型間的交接順序——這正是被模型吸收的Turn-Based Interface Bottleneck中「智慧程度遠低於模型本身」的部分。因此，調和結論成立且更精確：**提示詞會縮減，程式碼代理程式的程式碼庫會擴大，而被整項能力取代的 harness 則會一次消失。**第三種情況很罕見，因為它要求模型接手整套架構，而非單一行為。

斜率相反的逆流：harness 槓桿效應#

上面的反向資料談的是規模。Writer 的 harness 互換論文（The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI，arXiv 2607.06906，2026-07-08，empirical，且有整體供應商利益衝突 — 見 Orchestration Sets Token Economics）則提出關於方向的資料，也是本頁迄今面臨最尖銳的挑戰。

固定 22 項任務與六個模型，只替換協調層後，每個模型的效率都提升了（成本 −33% 至 −61%，無一例外），但品質提升幾乎完美地隨基準模型強度而變化：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。48 個能力 × 模型組合中，退步的七格全屬於三個較小的模型，且集中在最考驗協調能力的項目（MCP 工具使用、Playbooks、簡報）。論文如此描述：「同一個豐富的 harness，強模型能將之轉化為品質，弱模型卻會感受到它帶來的負荷。」 而它唯一新增的能力，也就是子代理委派，只有在最強的兩個模型上超過實用可靠度門檻（0.85–0.86；快速級模型則為 0.42–0.45）— 這是一種設有能力下限的協調功能；低於門檻時，開放這項功能帶來的是失敗，而非功能。

若照字面解讀，這就顛倒了本頁的說法：harness 越豐富，模型越強，回報反而越大。調和方式正是 wiki 的「已解答問題」早已指出的區別，如今還有了測量結果佐證：

• 會縮減的是補償弱點的鷹架 — 行為要求、提醒、驗證提示、視覺處理替代方案。本頁的每一項測量，恰好都針對這些內容：能力更強的模型不再需要的系統提示行，以及過期後反而會造成妨礙的內容。
• 能發揮槓桿作用的是模型無法自行完成的結構性機制 — 前綴快取形狀、壓縮契約、將上下文卸載至檔案系統、具型別的失敗分類、零 Token 的持久化暫停、逐任務 Token 計費。模型能力再強，也無法讓模型快取自己的提示前綴、以零成本在執行途中暫停，或免除已丟棄嘗試的計費。這就是「推論／部署結構」這類倖存者，而這是第一個指出它不只會留下來，還會隨模型越強而帶來越大回報的來源。

有兩個細節說明這不只是定義上的迴避。第一，實驗中表現較差的那一方，正是本頁所稱的 harness 臃腫：一份 49 KB 的單體系統提示，每一輪都重播，工具呼叫以正規表示式解析 XML，並採用具破壞性的中段截斷。勝出的 harness 並非更小，而是更有結構，Token 節省也來自結構。第二，能力下限的方向與 Instruction Compounding 相同，只是正負號相反 — 過時指令會傷害強模型，豐富的協調功能則會傷害弱模型。兩者都指出，harness 表層必須配合模型重新調整，而不是一味增加或一味刪除。

沒有消解的是：本頁隱含的預測是 harness 的貢獻會隨時間下降；而 harness 槓桿效應指出，在測量範圍內，貢獻中的品質部分會隨模型強度上升（基準能力平均值為 0.710–0.789 — 六個模型只涵蓋狹窄的八個百分點，因此這個斜率只能視為局部趨勢）。若這個趨勢在前沿能力範圍仍成立，「harness 會縮減」就只適用於提示，而 harness 的結構部分是能力的互補因素，不是替代品。

權限上的反向立場：自主權來自實績，而非版本發布#

以上逆流承認了規模與方向，但仍保留本頁的指示：每次發布時都重讀提示，刪除模型已不再需要的內容。Crystallizing Agent Work into Workflows（Malik、Azure Networking、case-study）直接反駁了 harness 中與權限相關的部分：

「自主權取決於特定 Playbook 類別與動作類型的實證，而不是底層模型的能力。更有能力的模型不會自動取得更大的自主權；實績才會。」

在這套設計中，工作流程可在無人監督下執行哪些動作，取決於它本身展現出的可靠度 — 至少 10 次乾淨執行，且動作序列一致率達 90%，才能進入混合模式；再增加至少 50 次，分類一致率達 99%，並經人工審查，才能進入決定性模式 — 而且模型升級不會轉移任何這類實證。本頁認為發布時應刪除鷹架；結晶化的主張則是發布時不會改變已取得的權限。更好的模型會改善探索，而節省要等到探索成果結晶化後才會出現。

可能的調和方式是：兩者討論的對象不同 — 本頁測量的始終是指令鷹架（系統提示行），而 Malik 描述的是權限鷹架（由實證門檻控制的權限）— 修剪原則原本就不打算套用到後者。但這仍只是可能的解釋，並非定論：語料中沒有任何內容能確定團隊升級模型時應由哪一方主導，而兩種主張都在同一時點提出。已列為另一頁的待解問題。

情感上的反向立場：把同一趨勢視為投資理由#

以上來源都把縮減解讀為一項刪除指示。Garry Tan 在 2026 年 Startup School 主題演講中（Owning Your Externalized Cognition，practitioner-opinion）是語料中第一個採取完全相同前提 — 模型是租來的商品，能力持續向內移轉 — 卻得出相反主張的人：建立更多上下文，因為這是發布週期不會商品化的唯一輸入。他對「模型會進步，讓 harness 過時」的回答是：

「當每個人的引擎都有一千匹馬力，勝負就取決於駕駛和地圖。」

依照這種看法，更聰明的模型能從同一座圖書館擷取更多內容，因此每次發布都是「免費升級我已經擁有的勞動力」。

這兩種說法沒有聽起來那麼矛盾，本頁自己的「已解答問題」正好說明了原因。 倖存者分類已區分行為要求（會移轉）與組織特有紀錄 — 更聰明的模型無法推斷沒有人記錄下來的決策。Tan 的個人圖書館正是移至個人層級的這類倖存者；他的反駁不動聲色地把主體從可能確實會縮減的harness，換成分類預測不會消失的圖書館。兩者可以同時成立；他的措辭把兩者混為一談。

真正的新意在於情感，而非機制：使本頁主張「每次發布都修剪」的同一斜率，也讓 Tan 主張「多記錄下來，並保留程式碼庫」。這個觀點的證據缺口在於測量 — 本頁的每個數字都來自補償弱點的鷹架，而語料中沒有任何測量能說明上下文優勢會在不同模型世代間擴大還是縮小。最接近的反向證據是 Agentic Work Systematization 的遙測資料（53% 重複使用的技能從未修改，維護的新增與修改比為 2.7:1），描述的是被複製而非持續累積的圖書館。雙方都尚未測量，而且發言者經營的加速器，其利益方向與這套主張一致。問題已列在另一頁。

相關連結#

• Owning Your Externalized Cognition — 情感上的反向立場：把模型商品化的同一前提，解讀為累積上下文而非修剪鷹架的理由。本頁自己的倖存者分類已調和兩者 — 個人上下文就是個人規模的組織特有紀錄 — 但趨勢中的圖書館部分仍未經測量
• Crystallizing Agent Work into Workflows — 權限上的反向立場：縮減論認為每次發布都會淘汰鷹架；結晶化論則認為工作流程的權限由自身實績取得，升級後仍維持不變。尚未調和；可能的區分是指令鷹架與權限鷹架
• Orchestration Sets Token Economics — 上述逆流：豐富 harness 帶來的效率提升不因模型而異，品質提升則隨模型強度而增加（r = 0.99），而進階協調功能設有能力下限。調和方式是區分提示鷹架與結構性機制，這是本頁倖存者分類首次獲得測量支持
• Boris Cherny — 「100 lines」的主張與自發迴圈的觀察
• Shared Harness, Differentiated Surfaces — 語料中唯一非 Anthropic 的佐證：OpenAI 的 Codex／ChatGPT Work 合併，恰好根據 Cherny 所說的安全／權限／UI 剩餘差異化介面，並將介面路由交由模型決定
• Harness Build-vs-Buy — 反向資料及其調和方式：四個 harness 程式碼庫有 1.05M–1.75M 行，每年合併 5,679–7,736 個 PR，因為本頁測量的是提示而非儲存庫 — 也因為每次模型發布都修剪本身就是一種變動
• Claude Fable 5 — 最明確的示範：僅使用視覺的 Pokémon harness，以及比 Opus 4.8 高出 3 倍的記憶體運用率
• Cat Wu — 每次發布都修剪提示的實務原則
• Instruction Compounding — 關鍵界線：鷹架可能變得有害，而不只是無用；因此修剪流程是必要義務，而非單純有利可圖
• Output Length Calibration — 逆流：同一份 Opus 5 指南新增了控制輸出長度的提示，因此發布時必須一邊刪除能力鷹架，一邊新增溝通鷹架
• Matt Pocock — 反方觀點：機械式驗證仍是承重部分
• Agent Loop Pattern — 基礎機制從 harness 移轉至模型的例子
• Context Window Smart Zone — 為何提示臃腫是一種成本，而不只是膨脹
• Claude Character as Product — 角色設定是少數可能不會縮減的 harness 資產
• Agent Harness Engineering — 將「強制執行不變條件，而非實作方式」的原則推廣至 harness 與模型的分工
• Claude Code Auto Mode — Cat Wu 預測其必要性會逐漸消失的 harness 功能
• AI Brain Fry — harness 縮減能部分緩解此問題（需要監督的內容變少），但迴圈的輸出量又會讓它再度出現
• Human-AI Accountability Redesign — 不會縮減的是邊界上的人類；這篇論文指出邊界工作會變成什麼（監督品質、決策權、升級處理、後果）
• Model Spec Midtraining (MSM) — 對齊從 harness 透過提示注入價值，轉為模型內化價值；這是 harness 縮減在對齊方面的表現
• Interaction Models — 同樣的轉變發生在互動軸線上：VAD／回合偵測／對話管理 harness 逐漸融入模型（Thinking Machines Lab，2026 年 5 月）
• The Bitter Lesson — 背後的原則：手工打造的鷹架會被擴展後的通用能力超越
• Build for the Next Model — 衍生出的產品策略推論，另成一頁：先做出「幾乎能運作的東西」，讓下一版補上差距（Dan Carey／Claude Design／Opus 4.7）
• HTML as the New Markdown — 關鍵區別：本頁描述的是面向模型的 harness 縮減，而 Thariq Shihipar 的 HTML 成品（計畫、微型應用程式）則是面向人類的 harness，並會隨模型進步而擴大（限制從「模型能不能做到」轉為「人類能不能持續參與」）
• Compute Allocator — 指出面向模型的 harness 縮減時，擴大的會是人類角色；約 99% 的 Token 用於面向人類的鷹架
• Founder as Agent Orchestrator — harness 縮減時，協調本身提供的功能也會改變；創辦人若圍繞 2026 年 Claude 介面的功能打造永久工作流程，就應預期需要改寫
• Agentic Technical Debt — CLAUDE.md 作為架構上下文，是 harness 的一種形式；模型或許最終能自行推斷，但目前仍不可或缺
• Compounding Data Moat — 垂直領域的邊緣案例測試套件是一種不會向模型內部移轉的 harness（針對小眾產業邊緣案例，沒有通用訓練訊號）
• AI-Native Startup Lifecycle — 創辦人若圍繞 2026 年 Claude 介面的功能打造永久工作流程，就應預期它們會隨 harness 縮減而改變
• Zero-Friction Scope Creep — 書面範圍管理是人類流程工作，harness 縮減時不會向模型內部移轉
• MCP and Computer Use — 與 harness 縮減形成互補：連接器不會縮減；隨著模型決定每項任務該使用哪種基礎環境（MCP／API／電腦操作），連接器反而會增加
• Evals as Product Spec — PM 端不會縮減的部分：evals 是耐久資產，能在周遭 harness 消融時重新驗證產品
• Agentic Loops Overtake Bespoke Systems — 形式數學中的相同動態：DeepMind 專門打造的證明搜尋鷹架（AlphaProof 加演進機制），隨 LLM 改善，從提升能力轉為只節省成本
• Verification as the New Bottleneck — Fiona Fung 提出的組織層級推論：當生成 harness 縮減，驗證便成為主要瓶頸
• Recursive Self-Improvement — harness 縮減推演至終點：harness 融入模型，與應用於 AI 開發本身並閉合自我改善迴圈的趨勢相同
• AI Accelerating AI Development — 部署端的測量結果：能力向內移轉時，內部工程產能提升（每位工程師的程式碼產量約為 8 倍；超過 80% 由 Claude 撰寫）
• Research Taste as the Human Bottleneck — 人類端的對照：面向模型的 harness 縮減後，留下的是品味、審查與方向設定
• Vibe Coding vs. Agentic Engineering — Karpathy 所說「超過 10 倍且差距持續擴大」的槓桿曲線，是從業者角度呈現 harness 縮減／能力增長
• Loop Engineering — 部署端的證據：Osmani 說「一年前，迴圈還是你得永遠維護的一堆私人 Bash 指令；現在，這些功能已內建在產品裡」，這是從迴圈層面觀察 harness 縮減 — 能力被工具吸收為具名基礎功能（自動化、worktrees、skills、連接器、子代理）
• Agentic Work Systematization — 衡量同一種吸收過程：skills／plugins 是以具名、可共用產品功能推出的 harness 能力，並附有 OpenAI 研究的採用曲線（每週活躍 Codex 使用者中，使用率從 5.4% 升至 26.6%）
• Conversation-to-Delegation Shift — 委派增加（依使用者群體區分的 Codex Token 占比）是 harness 縮減在使用面帶來的成果：每項任務所需引導變少，交辦的工作更多
• Agent-Authored Harness Optimization — 人類角色縮減延伸至 harness-撰寫層（撰寫簡報、審查 PR）；但有個與縮減論相悖的轉折：代理程式因 harness 太薄而非太厚，新增了鷹架 — 重試邏輯、依輸出判定的迴圈偵測、PID 追蹤。DarwinX 將這個轉折化為方法特性：只增不減的選擇規則，以涵蓋範圍超集為驗收標準，因此無法產生更小的 harness，迴圈中的任何環節都無法扮演 Cat Wu 的角色
• Continuous Self-Modification Under Review — 上述反向資料的極限案例，也是唯一可能在論點成立時自行縮減的 harness：連續 161 天自我修改，產生了1,085 次提交與 175,755 行已發布程式碼，淨刪除只出現在最後一個月。與 OpenHands 比較相同的限制（程式碼庫而非提示；自我回報；case-study），方向也相同 — 語料中的每個代理程式撰寫案例都讓 harness 擴大
• DHH (David Heinemeier Hansson) — 外部佐證支持削減 80% 的主張與觸及最廣的機制主張（過度規定會損害代理程式），並預測協調層接下來也會縮減
• Cline — 2026 年 9 月的遷移：過時的工具呼叫機制（以 XML 解析呼叫）會拖累有能力的模型；透過替換機制而非修剪提示解決，而各介面的行數減少，則由底層共用 SDK 的增長抵銷
• Harness Tax: Coding-Agent Cost Multiplies Across Harnesses While Success Barely Moves — 第二項非 Anthropic 佐證：一個由 4 種工具、約 2,900 個字元構成的 harness，在兩項獨立基準測試中達到 Pareto 前沿，表現不輸 Claude Code 的 23 種工具、77,000 個字元版本，成功成本最高可低 2 倍，成功率差距在 ±2–5% 以內

待解決的問題#

• Boris 關於「100 lines」的預測距離 2026 年 5 月還有一年 — 可在 2027 年驗證。部分解答：Harness Build-vs-Buy 首次測量了 harness 程式碼庫的大小與趨勢 — 四個可比較的 harness 有 1.05M–1.75M 行，合併 PR 的速度仍在上升（Codex 在十二個月內從每月約 124 個增至約 1,000 個）。這是關於參照類別的證據，並非關於閉源且未經測量的 Claude Code；2027 年的驗證仍待進行。
• 如果 harness 工作縮減，什麼新工作會增加來填補空缺？Cat Wu 的押注是：PM／產品品味、撰寫 evals、角色設定工作。

已解答問題#

• 所有提示鷹架最終都會移轉到模型中，還是有些會留下來 — 例如組織特有風格、安全規則、品牌語氣？已解答：What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — 不會：只有行為要求會移轉（並依照 Instruction Compounding 所述，過期後會造成傷害）。五類鷹架會留下來，依照苦澀教訓的豁免規則排序（編碼任務先驗的結構會移轉；編碼邊界、紀錄、身分或服務算術的結構則不會）：邊界執行（安全規則以限制條件的形式留下來，這類指令仍會持續有效）、組織特有紀錄（更聰明的模型無法推斷未記錄的決策 — 組織風格作為任意慣例屬於此類）、刻意塑造的身分（品牌語氣／角色會刻意在能力躍升期間保持穩定）、推論／部署結構，以及面向人類的可理解性（會擴大）。溝通校準則朝相反方向發展 — 預設輸出變長時，校準內容會新增而非刪除。「harness 縮減」實際上是要求縮減；提示最後會收斂為限制、紀錄、身分與校準的殘留內容。

衍生文章#

• What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — 回答本頁移轉問題的倖存者分類，另加上累積效應的偵測特徵，以及 Build for the Next Model 的停滯分析
• Learning to Co-Work with AI: A Software Engineer's Field Guide — 將每次發布都修剪的做法轉化為日常實踐；把「為下一個模型打造」視為職涯策略的時間跨度
• Opinions on Using AI Tools & the Future of the Software Engineering Role — harness 縮減與 harness 就是天花板之間的張力，是四種立場辯論圖譜中的一個軸向
• Does the Human-Facing Harness (HTML Artifacts) Hit Its Own Bloat Ceiling? — 將面向模型與面向人類的不對稱性推至結論：面向人類的 harness 無法縮減至零，且模型改善時面臨更大的膨脹壓力
• Where Does Agent Harness Work Remain Durable as Models Improve? — 區分會縮減的能力鷹架與持久邊界工作：驗證、儲存庫內的事實、上下文預算、隔離、工具與人類決策介面
• Authority and Audit Survive Abundance — 確認並推廣指令與權限的可能區分（本頁的結晶化張力）：倖存者分類中的邊界／紀錄類別，加上安全語料的循環性原則，說明為何模型升級會修剪指令，卻不會授予權限 — 也說明為何同一規則能讓檢索層在上下文免費時仍保持存在

資料來源#

• How We Migrated 11 Million Users to Cline's Biggest Harness Upgrade — Saoud Rizwan，Cline 部落格，2026-09-02（empirical，供應商觀點）：XML 工具呼叫與原生機制的成本、錯誤上限 A/B 測試，以及套件層級的行數，顯示共用 SDK 的總量大於取代它的單體程式。完整說明見 Cline

• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH，Lex Fridman #501（2026-08-26，practitioner-opinion）：用自以為是的主管機制解釋削減 80%；以仍然保留的 Bash 風格規則作為反例；並談到「這一切都會解決」的協調 harness

• Beyond RAG: Building Agentic Document Workflows with LlamaIndex — Pierre-Loic Doulcet，AI Engineer Singapore 2026（practitioner-opinion，LlamaIndex 供應商利益衝突）：從檢索端陳述本論點（HyDE／多重查詢被代理迴圈取代；Search-R1 將迴圈吸收至權重中；Adaptive-RAG 以路由避開迴圈），並指出適用範圍 — 解析是沒有縮減的層。完整說明見 Document Parsing as the Retrieval Bottleneck

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next

• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)

• Full Walkthrough: Workflow for AI Coding — Matt Pocock（反方觀點）

• Claude Fable 5 and Claude Mythos 5 — 僅使用視覺的 Pokémon FireRed harness；記憶體使用率提升

• Prompting Claude Opus 5 — Anthropic 平台文件（檢索於 2026-07-25，vendor-claim）：以供應商指引形式說明修剪原則，包括如今會降低輸出品質而不只是浪費 Token 的 harness 鷹架

• The new rules of context engineering for Claude 5 models — Thariq Shihipar，2026-07-25（practitioner-opinion）：系統提示刪除超過 80% 而 eval 成績不變、「解除限制」的說法、互相衝突的指令逐字稿，以及產品化修剪工具 claude doctor

• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI — Latent Space，2026-07-28（practitioner-opinion）：非 Anthropic 的查證 — Codex 與 ChatGPT Work 共用同一個 harness，只依權限和 UI 區別；介面路由由模型決定；另有使用者介面旋鈕增加的逆流（「有 32 個選項」）

• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny，YC 訪談（2026-07-27，practitioner-opinion）：消融方法、SIMPLE=1、「少了這些提示後，聰明了一點」、安全／權限／靜態分析／UI 殘留，以及每六個月刪除 CLAUDE.md 的建議

• The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI — Sayed Ali 等人（33 位作者，皆來自 Writer, Inc.；arXiv 2607.06906，2026-07-08，empirical，整體供應商利益衝突）：§6.4 harness 槓桿效應（各模型的 Δq̄，r = 0.99）、§6.3 七項退步全發生在較小模型、§6.5 子代理能力下限、§4.2 凍結基準中的 49 KB 重播系統提示。已檢視圖 6 — 擬合結果明確，但基準能力範圍僅為 0.710–0.789。原始解析中的表 2 儲存格合併，表 7 列位移；兩者皆未引用

• Prompt Design at Scale: How Format, Instruction Count, and Context Length Shape Instruction Adherence and Hallucination in Large Language Models — Netanel Eliav，arXiv 2607.19257，2026-07-21（empirical，唯一作者、單一實驗室、未經同儕審查）：§4.2 與表 4 說明指令數量的下限；§8 提供「40 條指令是重新設計的起點」指引 — 本頁首個非 Anthropic、非供應商的提示大小硬上限證據，也是唯一以指令數而非 Token 數量作為單位的來源。原始 Markdown 中表 1 的模型清單儲存格合併，因此未引用；見 Instruction Compounding 的來源註記

• Coding Agents and Technical Debt — Rajiv Shah，OpenHands，2026-07-28（case-study，有供應商利益）：反向資料 — 四個 harness 程式碼庫有 1.05M–1.75M 行、每年合併 5,679–7,736 個 PR，且 PR 數量持續增加

• DarwinX: Evolving Agent Harnesses Through Natural Selection — Zhang、Dai、Tan、Yang 等人（Salesforce AI Research／Agentforce，arXiv 2608.07545，2026-07-31，empirical）：此處只引用機器撰寫的 harness 編輯方向 — §2.2 的新增式編輯規則與 §2.3 的聯集涵蓋範圍合併準則（機制中沒有規模參數）、表 6 新增的七項 TB2.1 技能、表 13–14 新增的四項瀏覽器技能，以及一項提示改寫：將絕對禁止僅使用 UI 操作，改為有界限的委派。Salesforce 評估自家專有代理程式；解析結果乾淨（表 1–5 逐格驗證，canary-recall 20/20）。完整說明見 Agent-Authored Harness Optimization

• Garry Tan: Own Your Intelligence — Garry Tan，「Own Your Intelligence」，YC Startup School 2026（2026-08-06，practitioner-opinion，無測量，加速器主席利益衝突）：反對意見段落 — 對「模型會進步，讓 harness 過時」的回應是駕駛與地圖的論點，以及「免費升級我已經擁有的勞動力」。這是語料中唯一將本頁前提解讀為應累積上下文，而非修剪鷹架的來源

• Fable's judgement — Simon Willison，〈Fable's judgement〉，2026-07-03（practitioner-opinion，460 字）：Cat Wu 與 Thariq Shihipar 在 AI Engineer World's Fair 提出的建議：讓模型運用自身判斷，而非指示它如何工作；自動化測試的例子；以及 Willison 自行委派模型路由的提示。團隊建議為二手資訊（Willison 主持座談；語料中沒有逐字稿），提示本身則是一手資訊；結果未經測量

• Build more natural voice experiences with GPT‑Live‑1 in the API — OpenAI，2026-09-10（vendor-claim）：未具名客戶聲稱，相較於串接式語音建置方案，「程式碼庫的 80%／刪除了 23K 行」；這是語料中唯一一筆 harness 程式碼庫數量下降的數字，但屬於客戶推薦語，而非測量結果

• HarnessTax: How Much Does the Harness Matter for Coding Agents? — Pan、Yang、Arabzadeh、Chiang、Stoica 與 Zaharia，Arena.ai 部落格，2026-09-16/18（empirical）：第三方基準佐證 — Pi 的 4 種工具、約 2,900 個字元的 harness，在 Pareto 前沿上可媲美 Claude Code 的 23 種工具版本。完整說明見 Harness Tax: Coding-Agent Cost Multiplies Across Harnesses While Success Barely Moves