你的 coding agent 不是變笨，是 harness 漂移了：一份官方驗屍報告、35 個版本的實測，與你今天就能做的歸因流程

瀏覽次數: 2

本文大綱

這篇文章適合你，如果你是…

每天用 coding agent 的工程師：你有過「這禮拜它明顯變笨了」的體感，但講不出證據，也不知道下一步該查什麼。
技術主管 / 架構師：你要對「我們的 agent 效果不穩」給出解釋，而「模型可能被降級了」不是一個能寫進報告的答案。
負責 AI 成本的人：你的 token 帳單在解決率沒變的情況下漲了，你需要知道錢花在哪一層。

1. 前言：問題場景（約 550 字）

Hook 開場

「這禮拜它明顯變笨了。」

過去一年我大概講過這句話二十次。每次都是同一套流程：先懷疑自己 prompt 寫壞了，重寫一遍；沒好轉，開始懷疑 context 太長，開新 session；再沒好轉，就下結論——「應該是被降級了吧」，然後去 Reddit 找同溫層取暖。

這套流程有一個致命問題：它從頭到尾沒有產生任何可以查證的東西。 我的抱怨沒有 baseline、沒有指標、沒有時間戳。它只是一種情緒。

⚠️ 撰稿註記：此段可依作者實際經驗替換為更具體的一次事件（哪個專案、哪個版本、什麼症狀）。目前保留通用敘述以確保不虛構具體數字。

從系統架構的角度，這個誤判其實非常好預測。一次 coding agent 請求要穿過至少五層決策——runtime 預設值、context 管理、system prompt、工具編排、擴充層——其中沒有任何一層是模型權重。但使用者能看見的只有最後的輸出。當一個系統只暴露一個觀測點，人類必然會把所有變異歸因到那個觀測點上。

我們把系統問題，誤判成了零件問題。

數據佐證

**** 2026 年 4 月 23 日，Anthropic 發表工程驗屍報告，確認 Claude Code 的品質下滑真實存在，並指出三個變更——全部都在 harness 層，模型權重一行沒動。三個月後，Queen's University 團隊發表第一篇「固定模型、只變 harness」的受控縱向研究：同一個 LLM 跑 Qwen Code CLI 的 35 個連續版本，SWE-bench Verified 解決率在 23.0% 到 39.0% 之間震盪。

解決方案預告

這篇文章要做三件事：把三份互相獨立的證據串成一條完整的因果鏈；誠實標示這些證據各自的限制（包含反駁我自己引用的資料）；然後給你一套當天就能執行的歸因流程。

文章承諾

完整重建 2026 年 3–4 月那次品質事件的時間軸（含官方一手數據）
35 個 harness 版本的實測數據：解決率、token、工具呼叫、對話回合
三個 harness × 兩個模型 × 300 trials 的成本對照：為什麼換 harness 比換模型影響大 40 倍
一份六步歸因流程 + 五個你今天就能從 session log 算出來的指標
一次事實查核：英文圈流傳的「好 scaffold 提升 20% 效能」根本不存在

讀者收穫

讀完這篇文章，你將能夠：

在 agent 品質下滑時，按正確順序排查，而不是直接跳到「模型變笨了」。
用你自己的 session log 算出五個行為指標，把體感變成可查證的數據。
在評估 coding agent 時，把基本單位從「模型」換成「harness–model pair」，並用 tokens per solved task 取代單看解決率。

1.5 TL;DR（約 110 字）

Anthropic 官方承認：2026 年 3–4 月 Claude Code 的品質下滑是真的，三個原因全在 harness，模型權重沒動，內部 eval 太窄抓不到 3% 的下滑。
學術實證：同一個模型跑 35 個連續 harness 版本，解決率 23%–39%；越新的版本沒有越準，但穩定越貴（token +70%）。
對照實驗：換 harness 造成 40 倍 token 成本差距，通過率差距卻只有 0–8pp（統計雜訊內）。換模型只省 1.0–1.3 倍。
失敗模式是 harness 的屬性，不是模型的屬性——換模型救不了。
沒有 instrumentation 的抱怨沒有力量：推動廠商調查的不是六週論壇聲量，是一個附了 6,852 個 session 檔的 GitHub issue。

2. 核心概念：harness 到底是什麼，為什麼你一直忽略它（約 700 字）

2.1 一句話定義

Agent harness（中介層 / 外殼，也叫 agentic scaffolding）：介於開發者與 LLM 之間的中介軟體層，負責編排 system prompt、工具執行、context 管理與迭代推理迴圈。

比喻：模型是引擎，harness 是整台車。 你踩油門的體感來自整台車——變速箱、輪胎、電控、懸吊——不只來自引擎。當車子開起來變鈍，你第一個懷疑引擎，是因為引擎是唯一有型錄規格的零件。

2.2 五層決策，沒有一層是權重

層	決定什麼	一旦改動的症狀
Lifecycle / runtime defaults	reasoning effort 檔位、turn 上限、逾時	複雜任務突然變淺、提前收工
Context management	哪些歷史留著、哪些裁掉、快取何時失效	健忘、重複、鬼打牆
System prompt	行為約束、輸出長度、工具使用規範	回覆變短、跳過驗證、少解釋
Tool orchestration	可用工具、工具描述、失敗重試	工具用錯、無效重試、空轉
Extensibility	plugins / skills / MCP / hooks	行為在不同專案間不一致

**** 注意這張表的一個結構特徵：症狀全部是「行為」層級的，而不是「知識」層級的。 模型真的退步時，你會看到它答錯事實、寫錯 API；harness 出問題時，你看到的是它「不夠認真」——少讀檔、提前放棄、重複同一招。如果你的抱怨句型是「它變懶了」而不是「它答錯了」，那從第一秒起，你就該去查 harness。

2.3 關鍵術語表

術語	英文	說明
中介層 / 外殼	Agent harness / scaffolding	編排 prompt、工具、context、推理迴圈的軟體層
推理力度	Reasoning effort	分配給思考的預算檔位（high / medium / low）
版本漂移	Harness drift	harness 快速改版導致行為在使用者無感知下改變
解決率	Resolve rate	benchmark 上任務被成功解決的比例
每解一題的 token	Tokens per solved task	把成本與成功率綁在一起看的效率指標
空轉回合	No-action turns	產生了一輪輸出但沒有推進任務
思考遮蔽	Thinking redaction	UI 層隱藏思考內容（不等於思考預算被砍）

需要視覺素材 #1：五層 harness 堆疊示意圖，標示「模型權重」在最底層且不在這五層之內。

3. 深度剖析：三份獨立證據（約 2,300 字，文章核心）

3.0 為什麼要三份？

單一證據都可以被推翻：廠商的說法可能是公關；學術研究可能不適用你的工具；個人取證可能是倖存者偏差。但當廠商驗屍、受控實驗、個人取證三種完全不同來源指向同一個結論時，這個結論才站得住。

證據	類型	證據強度	回答什麼問題
Anthropic April 23 Postmortem	廠商一手驗屍	高（自認）	真的發生過嗎？→ 是，權重沒動
arXiv 2607.03691	受控縱向研究	高（可複現）	是特例還是通則？→ 通則
GitHub issue #42796	單人大規模取證	中（單一使用者）	一般人抓得到嗎？→ 抓得到
arXiv 2607.22585	對照實驗	中高（n=50）	選 harness 差多少？→ 成本差 40 倍
arXiv 2608.28497	生態系採礦	中	只有廠商有問題嗎？→ 你自己的也在漂移

3.1 證據一：廠商自己承認了

原理簡述：Anthropic 在六週的社群抱怨後公布驗屍報告，確認 Claude Code / Claude Agent SDK / Claude Cowork 品質下滑真實存在，肇因是三個互相重疊的產品變更。

時間軸（一手數據）

#	變更	上線	修復 / 回退	影響對象	機制
1	預設 reasoning effort `high` → `medium`	3/4	4/7 回退	Sonnet 4.6、Opus 4.6	為降低延遲、避免 UI 看起來「凍住」
2	快取清理邏輯 bug	3/26	4/10 修復（v2.1.101）	Sonnet 4.6、Opus 4.6	原本只想對閒置 session 清一次舊思考，變成每一輪都清
3	system prompt 加入簡潔指令	4/16	4/20 回退	Opus 4.6、4.7	「工具呼叫間文字 ≤25 字、最終回覆 ≤100 字」

Anthropic 的原句：

「We never intentionally degrade our models」
「our API and inference layer were unaffected」
底層模型權重沒有退步

唯一的量化數字：第 3 項的 ablation 顯示 Opus 4.6 與 4.7 的 coding eval 各掉約 3%。

Before / After 的真正意義（Tier 3 + Tier 2）

三個 bug 分別落在 harness 的三個不同器官——一個 runtime 預設值、一個 session 狀態原語、一個 system prompt 指令。它們沒有任何一個需要碰到權重，但合起來能讓一個產品劣化六週。

內部 eval 為什麼沒抓到（InfoQ 整理）：

內部員工用的是與公開版不同的 build
快取 bug 只在特定條件（stale session）觸發
eval 套組太窄，偵測不到 3% 的下滑

**** 第 3 點是這整段最值得你抄走的一句。3% 是什麼概念？它遠低於多數團隊 eval 的雜訊水準，卻足以讓每天跑 50 次 agent 的人明確感覺到「不對勁」。你的體感解析度，可能比你的 eval 還高。 這不是說體感可靠，而是說：如果你只用 eval 當守門，你會在使用者抱怨了六週之後才發現問題。

Anthropic 的承諾：影響智能的變更需 soak period、更廣的 per-model eval、漸進 rollout、內部員工使用與公開版完全相同的 build、system prompt 變更版本化。

⚠️ 版本號校正：多篇二手報導寫「快取 bug 修於 v2.1.116」，官方 postmortem 寫的是 v2.1.101。以官方為準。

需要視覺素材 #2：3/4 → 3/26 → 4/2（issue）→ 4/7 → 4/10 → 4/16 → 4/20 → 4/23（postmortem）事件時間軸。

3.2 證據二：這不是特例，是通則

論文：《Don't Blame the Large Language Model: How Agent Harness Evolution Shapes Coding Agent Quality》（arXiv:2607.03691，Queen's University，2026-07-04，v2 07-20）

方法論的關鍵反轉：過去所有研究都是「固定 harness、變模型」。這篇第一次固定模型、只變 harness。

先看改版速度（RQ0）

專案	釋出頻率	補充
Qwen Code CLI	10.0 releases/週（間隔中位數 0.59 天）	201 天 3,990 commits（19.9/天）、288 個 release
VS Code	0.8 releases/週	慢 13 倍
GitHub CLI	0.6 releases/週	慢 17 倍

Issue 面：Qwen Code 累計 1,029 issues、關閉率 56.9%、444 未關閉、中位處理 6.21 天。對照 GitHub CLI 關閉率 82.1%、Gemini CLI 81.8%。

說白了：你每天要吃到兩次以上的改版，而這些改版的品質守門機制，比傳統開發者工具鬆得多。 你不會讓生產環境的相依套件每天自動升兩次，但你的 coding agent 就是這樣在跑。

再看 35 個版本的實測（RQ1）

固定同一個 LLM，跑 35 個連續 release × 50 題 SWE-bench Verified 分層抽樣：

指標	數值
Resolve rate 區間	23.0% ~ 39.0%（平均 30.5%）
有「越新越好」的趨勢嗎？	沒有（Spearman ρ=0.208, p=0.231，不顯著）
最高分版本	早期的 v0.0.14（39.0%）
每題 token	~217K ~ 668K
早期 → 最新平均 token	391K → 668K（+70%，ρ=0.743, p<0.0001）
標準化偏差	最新 +19.6% vs 早期 −24.2%
每題工具呼叫	6.9 ~ 14.3
成功任務	7.2 次呼叫 / 258.7K token
失敗任務	12.95 次呼叫 / 697.7K token（2.7 倍）
LLM 對話回合	新版多 18%（與 token 相關 ρ=0.941）
System prompt 長度	膨脹約 8%

三個必須講清楚的解讀：

同一個模型，光是換 harness 版本，解決率可以從 23% 到 39%。 16 個百分點——比多數模型世代升級的幅度還大。你上週和這週用的「同一個模型」，可能不在同一個效能檔次。
越新的版本沒有越準，但穩定越貴。 效果沒有趨勢（p=0.231），成本有明確上升趨勢（p<0.0001）。這是被所有人忽略的一半。
失敗比成功貴 2.7 倍。 這解釋了為什麼「agent 變差」和「帳單變高」總是同時發生——它們是同一件事的兩面。你的成本曲線，其實是一條偽裝的品質曲線。

哪些元件最容易搞砸（RQ3）

風險	元件	結論
🔴 高	LLM Provider layer、Context Management	修改經常伴隨品質退步
🟢 低	Extensibility、Security	變更幾乎都安全或中性

其他發現：feature/issue 活動與 resolve rate 正相關（ρ=0.438）但以效率為代價（Finding 10）；context management 的擴張伴隨較低的 token 效率（Finding 15）。

這裡有一個漂亮的對照：學術研究說 Context Management 是最高風險區，而 Anthropic 三個 bug 裡最嚴重的那個（快取反覆清理）正好就在 context management。兩個完全獨立的來源，指到同一個元件。

需要視覺素材 #3：35 個版本的解決率（左軸）與每題 token（右軸）雙軸折線示意——一條平的、一條往上。

3.3 證據三：換 harness 的代價是 40 倍成本

論文：《The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation》（arXiv:2607.22585，Sentient Labs）

設計：2 模型（Qwen 3.6 Plus、MiniMax M2.5 [228.7B/10B active]）× 3 harness（Goose、OpenCode、OpenHands-SDK）× Terminal-Bench Pro 50 題分層子集（8 領域）= 300 trials。

每解一題花的 token

組合	Tokens / solved task	倍數
Goose + Qwen	28K	1×（基準）
Goose + MiniMax	37K	1.3×
OpenHands + Qwen	841K	29.9×
OpenHands + MiniMax	843K	22.8×
OpenCode + Qwen	1.15M	40.8×
OpenCode + MiniMax	1.55M	41.9×

通過率呢？幾乎沒差

變異來源	通過率差距
換 harness	0–8 個百分點（n=50 下屬統計雜訊）
換模型	4–10 個百分點

各 harness 通過率區間（依領域）：Goose 38–62%、OpenCode 30–75%、OpenHands-SDK 40–69%。

三個結論

失敗模式是 harness 的屬性，不是模型的屬性。 失敗指紋在兩個模型間 100% 複製：Goose → REASON、OpenHands → VERIFY/MAX_TURNS、OpenCode → TIME/idle。換模型救不了你的失敗模式。
空轉回合是一種「監督稅」。 OpenCode 的 no-action turns 是 Goose 的 10 倍——燒 token、拉延遲、增加人類審查負擔，卻不影響解題率。所以它不會出現在任何 leaderboard 上，只會出現在你的帳單和你的耐心上。
升級模型省 1.0–1.3 倍成本，換 harness 差 40 倍。 換句話說，harness 選擇對帳單的影響，遠大於商業模型之間的定價差異。 你花三個月談模型折扣，可能不如花三天換個 harness。

作者主張評測的基本單位應該是 harness–model pair，並要求 leaderboard 同時公布 tokens per solved task、平均空轉回合、完整失敗分類向量與 harness 規格。

⚠️ 事實查核：多篇英文二手部落格宣稱這篇證明「好的 scaffold 能提升最多 20% 效能」或「同一模型 62.3% → 70.2% 純粹來自 scaffold 選擇」。論文沒有這些數字。 它的通過率結論恰恰相反（0–8pp，統計上難以區分），真正的巨大差距在成本。這件事本身很說明問題：連討論「大家引用錯對象」的文章，都在引用錯的數字。

需要視覺素材 #4：tokens per solved task 的 6 組長條圖（對數軸），旁邊放通過率的窄幅區間對比。

4. 一般開發者是怎麼抓到的：一份可以抄的取證方法（約 800 字）

來源：GitHub issue anthropics/claude-code#42796，@stellaraccident（Stella Laurenzo，AMD AI 部門 Senior Director），2026-04-02——比官方 postmortem 早 21 天。

4.1 方法

6,852 個 Claude Code session JSONL 檔，4 個專案，2026-01-30 ~ 04-01
17,871 個 thinking block、234,760 次工具呼叫、18,000+ 條使用者 prompt

4.2 行為指標（證據力最強，因為不受 UI 變更影響）

指標	良好期（1/30–2/12）	劣化期（3/8–3/23）	變化
Read:Edit 比	6.6	2.0	改動前的研究量掉 70%
沒讀檔就直接改	72 次（6.2%）	5,028 次（33.7%）	每三次改動一次盲改
Stop hook 違規	0	173（約 10 次/天）	從零到有
每千次工具呼叫的推理迴圈	8.2	21.0	+156%
每千次工具呼叫的使用者打斷	0.9	5.9（後期 11.4）	最高 12 倍
使用者 prompt 的挫折訊號	5.8%	9.8%	+68%
每 session 的 prompt 數	35.9	27.9	−22%（更早放棄）
Write 佔 mutation 比例	4.9%	10.0%（後期 11.1%）	從「改」變成「重寫」

**** 這張表最厲害的地方是它繞開了廠商。她不需要知道 reasoning effort 被改成 medium，也不需要 Anthropic 承認任何事。她只是把「認真程度」翻譯成幾個可數的行為：讀了幾個檔、改了幾次沒先讀、被打斷幾次。「認真」是抽象的；「改動前讀了 6.6 個檔還是 2.0 個檔」是可查證的。

4.3 最生動的一個數字

使用者用詞頻率（每千條 prompt）：simplest 從 0.01 → 0.09，+642%。使用者開始反覆糾正 agent「不要只挑最簡單的修法」。其他：lazy +93%、stop +87%、great −47%、please −49%。正負情緒比 4.4:1 → 3.0:1。

4.4 成本：同樣的人類輸入，暴增的機器工作量

指標	2 月	3 月	倍數
使用者 prompt 數	5,608	5,701	~1×（幾乎不變）
去重後 API requests	1,498	119,341	80×
輸入 token	120.4M	20,508.8M	170×
估算成本	$345	$42,121	122×

4.5 ⚠️ 必須誠實揭露的四個限制

thinking 長度那個數字，被 UI 變更污染了。 Anthropic 的 @bcherny 在 4/6 於該 issue 回應：redact-thinking-2026-02-12 是純 UI 變更，隱藏思考內容但不影響 thinking 本身、thinking 預算或 extended reasoning（可用 showThinkingSummaries: true 退出）。所以廣為流傳的「思考中位數 2,200 → 600 字元（−73%）」是透過簽章長度估算（作者自陳 Pearson 相關 0.971），不能當成思考預算被砍的直接證據。
單一使用者、單一團隊、非受控環境。 專案內容與任務難度可能在期間內改變。
成本表的 1 月資料不完整（缺 8 天），API request 暴增部分可能與計量/路由方式變更有關。
提報人有立場：她在 The Register 訪問中表示團隊已改用別家（因 NDA 未具名）。

但這四點動不了 4.2 那張表。 「沒讀檔就改」從 6.2% 到 33.7%、stop hook 違規從 0 到 173——這些是純行為紀錄，與 UI 是否顯示思考完全無關。

**** 這正是我認為這份資料值得學的原因：她的強指標和弱指標混在同一篇裡，而網路上轉載的幾乎都只抄了弱的那個（−73%），因為它最聳動。 你在引用任何「AI 變笨」的數據時，第一件事是問：這個指標會不會被 UI 或計量方式影響？

5. 反方觀點：不要用這篇文章合理化你所有的抱怨（約 450 字）

平衡地說，「模型變笨了」這個抱怨在絕大多數時候仍然是錯的：

多數抱怨確實是知覺，不是回歸。 早期「回覆變短」「開始 hedge」的說法被社群當成安慰劑與確認偏誤而駁回——在當時那是合理的預設立場。一個沒有 baseline 的抱怨，本來就該被駁回。
陰謀論被證偽了。 社群主流敘事曾是「廠商偷偷用算力節流」（所謂 AI shrinkflation）。Claude Code 負責人 Boris Cherny 公開否認偷偷降級，同事 Thariq Shihipar 也否認為管理需求而降級模型。驗屍報告支持的是工程失誤，不是刻意降級。這兩者的差別很重要：前者靠更好的流程可以修，後者只能換供應商。
學術研究本身有邊界。 2607.03691 只深度測了 Qwen Code 一個 harness、50 題子集；2607.22585 作者自陳 n=50 統計力不足，通過率差異落在雜訊內；兩篇都沒有測 Claude Code 或 Codex 的閉源版本。它們證明的是機制普遍存在，不是任何特定產品的絕對數值。
真正改變局面的不是抱怨的音量，是資料。 六週的論壇聲量沒有推動什麼；一個附了 6,852 個 session 檔與 234,760 次工具呼叫的 GitHub issue 推動了。

這是全篇最重要的一句：沒有 instrumentation 的抱怨，沒有力量。

6. 決策框架：品質變差時，照這個順序查（約 700 字）

6.1 六步歸因流程

順序	檢查什麼	怎麼查	為什麼排這個順序
1	你自己的 harness 變了嗎	`git log` 你的 CLAUDE.md / AGENTS.md / skills / hooks	最常見、最好查、你自己就能回退
2	CLI 自動更新了嗎	版本號 + changelog diff	>2 releases/day 的節奏，你昨天和今天不是同一個工具
3	runtime 預設值變了嗎	reasoning effort、turn 上限、context 策略	Anthropic 第 1、2 個 bug 都在這層
4	system prompt 變了嗎	官方 prompt 若公開則 diff；否則看輸出長度／格式是否突變	第 3 個 bug 在這層；3% 靠感覺察覺不到，但輸出長度會露餡
5	你的任務變難了嗎	對照近期 commit 規模、涉及檔案數	排除自身變因，避免歸因錯誤
6	才輪到懷疑模型	用固定 canary 任務跑 API 直連	API 層與產品層必須分開驗——Anthropic 明說「API was not impacted」

**** 第 6 步的設計是整個流程的關鍵：用 API 直連跑同一組任務，是唯一能把 harness 和模型分離的動作。 如果 API 直連正常、CLI 不正常，你就在 30 分鐘內完成了 Anthropic 花六週才做完的歸因。

需要視覺素材 #5：六步歸因決策樹流程圖。

6.2 三個場景

場景 A：個人開發者，用 CLI agent 做副專案

症狀：這禮拜開始老是「改了但沒讀」
推薦：先做第 1、2 步。把 CLI 釘在上一個版本跑一天對照。
理由：成本最低、資訊量最大。個人使用的 harness 變更頻率遠低於官方 CLI 的改版頻率，所以嫌疑最大的是自動更新。

場景 B：10 人團隊，agent 進了 CI

症狀：解決率沒明顯掉，但 token 帳單月增 60%
推薦：直接看 tokens per solved task 與失敗任務佔比（記得：失敗比成功貴 2.7 倍）。
理由：解決率是滯後指標，成本是領先指標。2607.03691 的數據就是這個形狀——效果沒趨勢、成本有趨勢。

場景 C：要在多個 harness 之間選型

症狀：三個 harness 的 benchmark 分數看起來差不多
推薦：不要看通過率選（0–8pp 在雜訊內），改看 tokens per solved task 與失敗指紋。
理由：40 倍的成本差距不會出現在 leaderboard 上，但會出現在你的月結帳單上。

7. 實戰最佳實踐：三個防禦動作（約 550 字）

7.1 釘住版本，不要盲目自動更新

常見錯誤：讓 coding agent CLI 自動更新，理由是「保持最新」。
正確做法：釘在已驗證的版本，排定固定的升級窗口，升級後跑 canary。

對照組：VS Code 一週 0.8 個 release，Qwen Code 一週 10 個。你不會讓生產環境的相依套件每天自動升兩次。

7.2 養一組 regression canary

5–10 題你自己領域的固定任務，每次 CLI 大版本更新後跑一次，只記錄三個數字：

解決率  |  每題平均 token  |  你打斷它的次數

**** 為什麼是這三個？因為它們剛好對應 2607.03691 的三個結論：效果、成本、以及成本裡最貴的那部分（失敗）。而 Stella Laurenzo 能贏，靠的就是她手上有一條 baseline——她不是比別人更敏銳，她是比別人更早開始記錄。

7.3 把量測指標從「有沒有解出來」換成「每解一題花多少」

常見錯誤：只看解決率 / pass rate。
正確做法：tokens per solved task = 總 token ÷ 成功任務數。

這一個指標同時吃進了「解不出來」和「解得很貴」兩種劣化。只看解決率，你會完全錯過品質下滑最早的訊號。

7.4 記住：你自己的擴充層也在漂移

《On the Maintenance and Co-evolution of Agent Plugins》（arXiv:2608.28497，2026-08-28）分析 1,926 個 repo、8,351 個 plugin、77,773 個 commit、2,018 個 marketplace：

2025-10 上線後六個月內，plugin 相關 commit 成長 8.8×
軟體工程類任務佔全部 plugin 61.3%
feature commit 佔 39.6%（傳統開源軟體僅 17.2%）→ 生態系還在瘋狂加功能，不是在維護
Claude 自己 co-author 了 34.9% 的 commit
skills 目錄中，instruction 檔與實作 script 以高於隨機的機率共同演化，78% 的 co-change 具備功能耦合

這代表什麼：你的 CLAUDE.md、skills、hooks、plugins、MCP servers 也是 harness 的一部分，改版速度同樣沒有守門機制。那個 78% 功能耦合，說的是一種新型態的維護債——改了 instruction 檔卻沒同步改 script，而沒有任何 linter 會警告你。

8. 效能調優：五個你今天就能從 session log 算出來的指標（約 350 字）

不需要廠商配合，你的 session log 裡已經有這些資料：

指標	怎麼算	掉了代表什麼
Read:Edit 比	讀檔工具呼叫數 ÷ 編輯工具呼叫數	改動前的研究變淺（6.6 → 2.0 是劣化訊號）
沒讀檔就改的比例	目標檔未曾出現在先前 Read 的編輯次數 ÷ 總編輯數	盲改（6.2% → 33.7%）
每千次工具呼叫的打斷次數	使用者中斷數 ÷ 工具呼叫數 × 1000	你糾正它的頻率（0.9 → 11.4）
每千次工具呼叫的推理迴圈	重複狀態轉移偵測	鬼打牆程度（8.2 → 21.0）
每 session 的 prompt 數	總 prompt ÷ session 數	掉了通常代表你更早放棄（35.9 → 27.9）

現成工具：lucemia/claude-session-analyzer 明確標示複現 anthropics/claude-code#42796 的方法論，可直接跑在你的 session log 上。

**** 建議的做法：現在就跑一次，即使你現在沒感覺有問題。 這五個數字的價值 100% 來自於有沒有 baseline——事後才開始量，你只會得到一組沒有對照的數字。

9. 工具與資源（約 200 字）

工具 / 資源	連結	一句話
claude-session-analyzer	github.com/lucemia/claude-session-analyzer	複現 #42796 方法論的 session log 量化分析工具
Anthropic April 23 Postmortem	anthropic.com/engineering/april-23-postmortem	業界少見的 harness 層品質事件一手驗屍報告
arXiv:2607.03691	arxiv.org/abs/2607.03691	第一篇固定模型、只變 harness 的受控縱向研究
arXiv:2607.22585	arxiv.org/html/2607.22585	harness–model pair 應成為評測基本單位的實證
arXiv:2608.28497	arxiv.org/abs/2608.28497	plugin 生態系的維護與共同演化實證
SWE-bench Verified / Terminal-Bench Pro	官方 repo	上述研究使用的兩個 benchmark

10. 總結與展望（約 400 字）

一表看完

證據	核心數字	對你的意義
Anthropic postmortem	3 個 bug、全在 harness、eval 掉 3%、權重沒動	品質可以在沒人碰權重的情況下劣化六週
arXiv 2607.03691	解決率 23%→39%、token +70%、失敗貴 2.7×	越新沒越準，但穩定越貴
arXiv 2607.22585	成本 40×、通過率 0–8pp	選 harness 比選模型更影響帳單
GitHub #42796	Read:Edit 6.6→2.0、盲改 6.2%→33.7%	你自己就能取證
arXiv 2608.28497	8,351 plugins、78% co-change 耦合	你自己的擴充層也在漂移

按讀者類型的建議

個人開發者：今天做兩件事——釘住 CLI 版本、跑一次 session analyzer 建 baseline。
技術主管：把團隊的成功指標從 pass rate 換成 tokens per solved task，並要求 harness 升級走版本控管流程。
選型中的架構師：評估單位改成 harness–model pair，把失敗指紋和空轉回合列入評估表。

未來趨勢

評測典範轉移：從模型排行榜走向 harness–model pair + 成本指標。leaderboard 只報準確率的時代快結束了。
harness 會出現版本治理：Anthropic 承諾的 soak period / 漸進 rollout / prompt 版本化，會逐步成為這類產品的基本要求。
「agent 可觀測性」會變成一個獨立的工具品類：因為使用者的體感解析度目前高於廠商的 eval。

今天就能開始的四步

查一下你的 coding agent CLI 這禮拜更新過幾次。
把版本釘住。
選 5 題你領域的固定任務，跑一次，記下解決率 / 每題 token / 打斷次數。
把這三個數字存進一個檔案，加上日期。這就是 baseline。

金句

「我們把系統問題，誤判成了零件問題——因為零件是唯一有型錄規格的東西。」

「越新的 harness 版本沒有越準，但穩定越貴。你的成本曲線，其實是一條偽裝的品質曲線。」

「沒有 instrumentation 的抱怨，沒有力量。推動廠商調查的不是六週論壇聲量，是一個附了 6,852 個 session 檔的 GitHub issue。」

「如果你的抱怨句型是『它變懶了』而不是『它答錯了』，那從第一秒起，你就該去查 harness。」

延伸思考

你手上有沒有一條 baseline？如果你的 agent 明天突然變差，你能用什麼數字證明它變差了——還是只能說「感覺上」？
你團隊的 agent 成功指標是「解決率」還是「每解一題花多少」？如果只有前者，你上一次成本上升是什麼時候發現的、又是誰發現的？
你自己寫的 CLAUDE.md / skills / hooks 有版本控管與回歸測試嗎？如果沒有，你和你在抱怨的那個廠商，用的是同一套流程。

FAQ

Q1: harness 和 scaffolding 是同一件事嗎？
是。2026 上半年兩個詞混用，Anthropic 的 postmortem 用了 harness 之後逐漸統一——arXiv 2607.03691 的 v2 標題就從 Scaffolding 改成 Agent Harness。

Q2: 所以「模型變笨」都是假的？
不是。多數抱怨仍是知覺與確認偏誤，而且 4 月那次是工程失誤不是刻意降級。這篇文章主張的是排查順序：harness 的嫌疑遠大於權重，但要有數據才能下結論。

Q3: 那次事件影響 API 直連嗎？
不影響。Anthropic 明確表示「our API and inference layer were unaffected」，三個 bug 都在 Claude Code / Agent SDK / Cowork 的產品層。

Q4: 「思考長度掉 73%」這個數字可以引用嗎？
不建議直接引用。它是透過簽章長度估算的，且期間有 UI 遮蔽變更（Anthropic 表示該變更不影響 thinking 預算）。要引用請改用行為指標，例如 Read:Edit 從 6.6 掉到 2.0。

Q5: 那些「好 scaffold 提升 20% 效能」的說法呢？
論文裡沒有。arXiv 2607.22585 的通過率結論是 harness 間差距 0–8pp（統計雜訊內），真正的差距在成本（40 倍）。這是英文圈廣泛流傳的錯誤轉述。

Q6: 那我到底該選哪個 harness？
論文沒有給出「最好」的答案，而是給出評估方式：看 tokens per solved task、空轉回合、失敗指紋。Goose 最省 token 但有 REASON 類失敗；OpenCode 最貴但某些領域通過率最高。取捨依你的任務類型。

Q7: 換模型能修好 harness 造成的失敗嗎？
不能。arXiv 2607.22585 最強的發現之一是失敗指紋在兩個模型間 100% 複製——失敗模式是 harness 屬性。

Q8: 我該把 CLI 釘在哪個版本？
沒有通用答案，要靠你自己的 canary。注意 35 個版本的實測裡，最高分是早期的 v0.0.14——「最新」不等於「最好」。

Q9: 這些研究測的是開源 harness，適用 Claude Code / Codex 嗎？
研究本身沒測閉源產品，它們證明的是機制普遍存在。但 Anthropic 的 postmortem 剛好從閉源這一側補上了同一個結論。

Q10: 我沒有時間做這些量測怎麼辦？
最低成本的版本是：釘住版本號 + 每次升級後跑 5 題固定任務、記三個數字。大約 20 分鐘。

Q11: 我自己的 CLAUDE.md 改動也算 harness 漂移嗎？
算，而且是排查順序的第一步。arXiv 2608.28497 顯示 skills 目錄裡 instruction 檔與 script 有 78% 的 co-change 功能耦合——改一邊沒改另一邊，行為就會漂。

Q12: 有辦法提前知道哪次改版會出事嗎？
研究給了風險地圖：LLM Provider layer 與 Context Management 是高風險區，Extensibility 與 Security 幾乎都安全。看到 changelog 動到前兩者，就該跑 canary。

參考資料

一手來源

二手報導
7. InfoQ — Anthropic Traces Six Weeks of Claude Code Quality Complaints to Three Overlapping Product Changes
8. VentureBeat — Mystery solved: Anthropic reveals changes to Claude's harnesses
9. VentureBeat — Is Anthropic 'nerfing' Claude?
10. The Register — Claude Code has become dumber, lazier: AMD director

工具
11. lucemia/claude-session-analyzer