同一個 agent，single-shot 的 pass rate 看起來很漂亮——0.9。但把它放進需要連跑 30 步才完成的任務，要求每一步都對，成功率掉到 0.04。模型沒變，題目也沒變，只是「跑得久了一點」。問題出在哪？
從 model scaling 到 system scaling——agentic AI 的瓶頸搬到 harness
這篇追的是一個讓人不舒服的觀察：foundation model 一代比一代強，single-turn benchmark 一路刷高，但部署出去的 agent 在 long-horizon 任務上——多步調查、跨工具編排、長對話——依然頻繁搞砸。
Shangding Gu 的 position paper（arXiv 2605.26112，標題《From Model Scaling to System Scaling》）把這件事當成一個謎題來拆：如果模型真的在變強，為什麼 agent 的長程可靠性沒有同步變好？
論文的結論是一句反直覺的話——「future progress in agentic AI will depend as much on system design as on stronger foundation models」。下一個瓶頸不在模型，在模型外面那層 harness。
論文對 harness 的定義很乾脆：它是「the structured execution layer around a foundation model」，要被當成「a first-class object of design, evaluation, and optimization」。
換句話說，過去被當成 glue code、被當成「把 model 接到工具上的那堆膠水」的東西，要被正式提升成一個有結構、可以被設計、被評測、被最佳化的對象。
論文用一個詞概括這個轉向——scaling the harness。
這不是一篇「agent 很難、要小心」的勸世文。
它的價值在於那個明確的分解：agent 的表現是六個元件交互的結果，而其中只有一個元件靠 model scaling 改善，其餘五個只能靠 system scaling。
下面我們按偵探的方式走一遍。
先把謎題擺清楚——為什麼模型在變強、長程卻沒變可靠。再逐一排除三個直覺候選：「換大模型」「塞更多 tool」「給更長 context」。
最後收斂到 harness 的三個真正瓶頸，並看論文怎麼把它們翻成一套新的評測 agenda。
模型越來越強，agent 卻還是搞砸 long-horizon 任務
先把謎題的形狀講精確。論文引了一個現在 agent 評測圈越來越常用的指標——pass^k。
它跟大家熟悉的 pass@k 是相反的東西。
pass@k 問的是「k 次嘗試裡至少有一次成功」——這是樂觀指標，常被拿來做宣傳數字，因為只要試夠多次總會中一次。
pass^k 問的是「連續 k 次 rollout 全部成功」——這是悲觀指標，量的是可靠性，因為它要求每一次都不能失手。
一個是「能不能做到」，一個是「能不能反覆做到」，差別就在這裡。
論文的觀察是——「agents that look strong under single-shot pass rates can collapse」under pass^k。single-shot 看起來很強的 agent，一旦要求重複可靠，會直接崩掉，暴露出「a reliability gap that endpoint accuracy hides」：一個被 endpoint accuracy 藏起來的可靠性缺口。
這個缺口在 demo 裡看不到。
因為 demo 通常只跑一次、而且是挑過的那一次。
它在生產環境才現形——當同一個 agent 被叫了一萬次、而你需要其中九千九百次都對。
為什麼會崩？因為 long-horizon 任務的成功，是每一步都不能錯的連乘。
假設一個 agent 每一步的成功率是 p，而任務需要連續 k 步都正確才算完成，那整體成功率就是 p 的 k 次方。
這不是論文捏造的曲線，這是一個再簡單不過的機率乘積——但它的形狀殘酷得驚人。
p = 0.95 聽起來很可靠了吧？連跑 20 步，0.95 的 20 次方只剩 0.36。
p = 0.99 呢？跑 50 步，0.99 的 50 次方是 0.61。
把 p 從 0.95 拉到 0.99 確實有用，但要靠「把模型每一步都做得更準」來補一個指數衰減的洞，回報是遞減的——而且 horizon 越長，遞減越快。
下面這個 widget 讓你直接玩這條曲線。
拖 horizon（任務需要的步數 k），看整體成功率怎麼隨著步數加長往下掉；拖 per-step reliability（每一步的成功率 p），看「把每步做得更可靠」這件事對長程的槓桿有多大。
這裡的曲線是 p 的 k 次方這個純數學關係，不是 hand-picked 的示意數據。
但它揭示的東西很實在：long-horizon 的失敗，本質上是一個 reliability 的指數問題，而不是一個 capability 的線性問題。
縱軸是 pass^k（連續 k 步全對的整體成功率），等於 per-step p 的 k 次方
單步成功率 0.95、連跑 20 步，整體成功率僅剩 0.36，指數衰減讓 horizon 遠比每步精準度更傷 agent。
玩過這條曲線之後，謎題的形狀就清楚了。
long-horizon 失敗不是某一步特別難，而是「步數」這個 horizon 把任何小於 1 的每步成功率放大成指數衰減。
論文點出的幾個具體失敗模式，都坐落在這條曲線上。
agent 對著 stale 的事實自信行動——calling deleted symbols、reintroducing fixed regressions。specialized subagent 回傳「plausible-sounding output that no downstream layer validates」。multi-agent 之間出現「coordination failures that single-agent metrics miss」。
論文還補了一句反直覺的觀察。
multi-agent 系統「can outperform single agents on breadth-first tasks」。
在需要鋪開廣度的任務上多 agent 確實贏單 agent，但代價是引入了單 agent metric 量不到的協調失敗。換句話說，加 agent 換來廣度，卻在 trajectory 上挖了新的扣分點。
每一個都是讓 p 在某些步驟悄悄掉下來的源頭。
而它們的共同特徵是——在當下都不會報錯，因為輸出看起來都合理。
舉一個具體的 trajectory 來感受這件事。
設想一個 coding agent 接到「把這個 repo 的 data loader 換成 streaming 版本」的任務，這需要連跑大約 25 步：讀檔、定位 loader、改實作、跑測試、修 import、再跑測試……
第 3 步，它從 memory 撈到一條 CLAUDE.md 裡寫的「the data loader is defined in utils/loader.py」——但這個檔案上週被 refactor 移走了，這條記憶已經 stale。
retrieval 不會擋它，因為這條記憶字面上仍然高度相關。agent 自信地往 utils/loader.py 寫東西。
第 11 步，它叫了一個 specialized「test-runner」subagent，回傳「all tests pass」——但這個 subagent 其實只跑了被它誤判為相關的那三個 test，沒人驗證它的覆蓋範圍。
輸出 plausible，於是進入後續推理。
第 19 步，agent 根據「測試都過了」這個假前提，把改動標記為完成。整條 trajectory 在 endpoint 上「成功」了——直到 CI 在十分鐘後紅給你看。
25 步裡只要這兩步的 p 各掉到 0.9，連乘就已經把整體成功率拖到危險區。
這就是 pass^k 衰減的真實長相：不是某一步難，而是分散在 trajectory 裡的幾個沒被治理的點，各自悄悄扣掉一點 p。
把這條 25 步的 trajectory 攤平來看會更清楚——大多數步驟 p 都接近 1，真正漏分的只有兩個點，而且它們各自坐落在不同的 harness 元件上。點任一個漏分點，看它是哪個元件失守、以及為什麼當下不會報錯。
點兩個紅色漏分點，讀它失守的 harness 元件 · 25 步 trajectory
點上面任一紅點
第 3 步 · ℳ memory 失守
failure mode：stale-but-confident
agent 從 CLAUDE.md 撈到「the data loader is defined in utils/loader.py」，但這個檔案上週已被 refactor 移走。retrieval 不會擋它——這條記憶字面上仍然高度相關。錯不在撈不到，而在撈到的是過時卻被當成事實的東西。換更強的 model 只會讓它更有條理地往錯的檔案寫。
第 11 步 · 𝒮 skill router 失守
failure mode：confident-but-unchecked
agent 叫了一個 test-runner subagent，回傳「all tests pass」——但它只跑了被誤判為相關的三個 test，沒人驗證它的覆蓋範圍。輸出 plausible，於是堂而皇之進入後續推理。失敗從「缺一個能力」變成「有一個沒被驗證的能力」，要等到 CI 紅給你看才現形。
互動圖表
stale memory 在第 3 步讓 agent 自信寫錯誤路徑，第 11 步的 subagent 輸出未驗證，endpoint 卻顯示「成功」。
那麼，要把曲線抬高，槓桿在哪？我們先試最直覺的兩個候選。
候選解一：換更大的 foundation model
最直覺的回答是：模型還不夠強，等下一代。這個候選在邏輯上對應到——把每步成功率 p 往上推。
它確實有用，從上面的 widget 也能看到 p 從 0.90 到 0.99 對尾端的提升。
但論文的論點是，這條路的回報結構決定了它不可能是主線。
論文把 agent 的表現寫成一個函數：P_H = Φ(ℛ, ℳ, 𝒞, 𝒮, 𝒪, 𝒢)。
其中 ℛ（Reasoning）是 base reasoning quality——也就是 foundation model 本身的能力。
關鍵的一句話是：「Model scaling primarily improves ℛ; system scaling improves ℳ, 𝒞, 𝒮, 𝒪, and 𝒢。」
換更大的模型，只動了這六項裡的一項。剩下五項——memory、context、skill routing、orchestration、governance——無論模型多強，都不會因為參數變多而自動變好。
這在 pass^k 的框架下尤其要命。
一個 long-horizon 任務的每步成功率 p，是六個元件共同決定的。
如果失敗的主因是「agent 讀到了一條 stale 的記憶、然後自信地對它行動」，那這個錯誤的根源在 ℳ（memory）而不在 ℛ。
換一個推理更強的模型，它只會「更有條理地」根據那條錯誤的事實往下走——論文的原話是 stale memory「regularly leads the agent to act confidently on invalidated assumptions」。
更強的 reasoning 在這裡甚至是反效果：它讓錯誤的行動更 coherent、更難被事後發現。
一個推理平庸的 model 可能會在錯誤路徑上絆倒、暴露問題；一個推理強的 model 會把錯誤一路推到底，包裝得無懈可擊。
所以候選一被否決：不是沒用，是動錯了變數。
它能把 p 抬高一點，但長程崩潰的主因往往落在另外五個元件上，而 model scaling 碰不到它們。
那六個元件到底各管什麼？論文把 harness 拆成下面這個結構——這是整篇的核心分解，值得停下來逐項看。
每個元件除了名字，論文還給了它的設計軸（axes），那些軸才是 system scaling 真正在優化的東西。
一個元件做得好不好，不是看它「有沒有」，而是看它在這些軸上的表現。
點任一格，讀它的職責與軸。
下面的對照圖在桌面顯示為一張堆疊圖，在手機上自動換成可點的卡片。
點任一元件讀它的職責與設計軸 · 6 個 harness 元件
P_H = Φ(ℛ, ℳ, 𝒞, 𝒮, 𝒪, 𝒢) —— harness 的六個元件
點上面任一元件
ℛ · Reasoning
base reasoning quality，也就是 foundation model 本身。這是六個元件裡唯一靠 model scaling 改善的一項。論文的整篇論點就是：把資源全押在這一格，邊際回報遞減，而長程失敗的主因往往落在另外五格。
ℳ · Memory substrate
持久化的儲存層，論文給的四個設計軸是 precision、durability、retrievability、verifiability。注意 verifiability——記憶不只要存得久、撈得回，還要能被驗證是否仍然成立。這是後面「trustworthy memory」瓶頸的根。
𝒞 · Context constructor
從 memory 與 task 組裝送進模型的 context。設計軸：relevance、compactness、traceability、refresh policy。論文把它定義成一個 selection policy 的輸出，而不是一個固定 buffer——這個視角是「context governance」瓶頸的核心。
𝒮 · Skill router
「dispatches tools and subagents」。設計軸：specificity、selectivity、composability、verifiability。論文把它類比成作業系統的 scheduling——在對的時間把對的 subtask 派給對的專用路徑。
𝒪 · Orchestration loop
跨 turn 把整個 flow 包起來的 control loop。它決定 agent 在多輪之間怎麼推進、何時停、何時 escalate。單看一輪的 metric 量不到 orchestration 的好壞——這正是 multi-agent coordination failure 藏身之處。
𝒢 · Verification & governance
論文原話：「gates both intermediate reasoning and external action before any verified result is written back to memory」。它是整條鏈的把關層——確保「confident-but-unchecked」的輸出不會被當成事實寫回去。
互動圖表
model scaling 只動六元件中的 ℛ（推理），長程可靠性的瓶頸在另外五個系統元件：ℳ、𝒞、𝒮、𝒪、𝒢。
這張分解圖裡有一個容易被略過、但很關鍵的細節。
verifiability 這個軸，同時出現在 memory（ℳ）和 skill router（𝒮）兩個元件上。
這不是巧合。論文反覆強調的一件事是——agent 的可靠性，本質上是「能不能驗證自己手上的東西」的問題。
memory 的 verifiability 問的是「這條記憶現在還成立嗎」，skill router 的 verifiability 問的是「這個 subagent 的輸出我驗過了嗎」。
兩個都是 ℛ（reasoning）碰不到的軸——再強的推理，也驗證不了它從來不知道是錯的前提。
context constructor 的四個軸也值得拆開看。
relevance 是「相不相關」，compactness 是「夠不夠精簡」，traceability 是「追不追得回來源」，refresh policy 是「多久該重新拉一次」。
注意後兩個——traceability 與 refresh policy——根本不是「把資料塞進 prompt」這個動作能涵蓋的。
它們要求 context 是一個有來源、會過期、需要被主動刷新的東西，而不是一坨一次性灌進去的文字。這個視角差異，正是「給更長 context」這個候選會撞牆的原因。
候選解二：塞更多 tool、給更長 context
否決了「換大模型」，下一個直覺候選是：給 agent 更多工具、更長的 context window，讓它「看得更多、能做的更多」。
這個候選同樣有部分道理，但論文用兩個具體的失敗模式把它擋了下來。
先說 context。直覺是 context window 越大越好——把所有相關資料都塞進去，模型自然能找到答案。
論文反駁的關鍵詞是「exposure without access」：暴露了，但不等於拿得到。
原話是「larger context windows do not guarantee effective information access, because attention dilutes over long inputs」——attention 在長輸入上會稀釋，模型傾向關注 document 邊界而不是中段。
這就是「lost in the middle」現象的根：證據放在 100K token 的正中間，名義上 model 看得到，實際上 attention 給它的權重低到等於沒看到。
更尖銳的一句：「tokens added without governance often degrade performance rather than improve it」——沒有治理地往 context 裡加 token，往往讓表現變差而不是變好。
所以「塞更長 context」不只回報遞減，甚至會反向傷害。relevant 的證據跟低價值的 padding 在同一個 window 裡競爭 attention，加得越多、訊號被稀釋得越嚴重。
真正的解法不是更大的 buffer，而是把 context 當成一個 selection policy 的輸出，而不是一個固定塞滿的 buffer。
論文給的 policy 形狀是：按語意相關性加權、對 verbosity 在 token budget 下扣分、偏好近期被驗證過的內容、記錄 provenance。每一個 token 進 context 之前都要先回答「你憑什麼佔這個位置」。
再說 tool。
直覺是工具越多、subagent 越專精越好。
論文反駁的是「confident-but-unchecked」失敗模式：當專用 skill 越來越多，「the failure mode shifts from a missing capability to a present-but-unverified one」——失敗從「缺一個能力」變成「有一個沒被驗證的能力」。
一個 specialized subagent 回傳一段聽起來很合理、但沒有任何下游層去驗證的輸出，這段輸出就堂而皇之地進入了後續推理。
在 pass^k 的框架下，這正是讓某些步驟的 p 悄悄掉下來的元兇——而且因為輸出「plausible-sounding」，它不會在當下觸發任何警報。
錯誤要等到很多步之後、當它導致一個看得見的失敗時才被發現，而那時根因已經埋在十幾個 tool call 之前。
所以候選二也被否決：更多 tool、更長 context 都動到了正確的元件（𝒮 和 𝒞），但「塞更多」這個動作本身缺了治理。
沒有 selection policy 的 context 是 dilution；沒有 post-condition check 的 tool 是 unverified risk。
問題的形狀於是浮現——真正缺的不是更多資源，而是管理這些資源的機制。
這就把我們帶到了 resolution。
真正的瓶頸在 harness 的三個治理機制
把兩個候選排除後，論文收斂到一個明確的論斷。
scaling the harness 的核心是三個瓶頸——context governance、trustworthy memory、dynamic skill routing——「together with the orchestration and governance mechanisms that coordinate and constrain them」。
注意這三個瓶頸不是新元件，而是前面六元件裡 𝒞、ℳ、𝒮 各自的「治理問題」。
memory 元件存不存得住是一回事，存的東西該不該被信任是另一回事；context 元件能不能組裝是一回事，組裝出來的東西該不該佔位是另一回事。三個瓶頸問的都是後者。
每一個都對應一個具體的 failure mode，而每一個的 system move 都長得出奇地像——把控制權從「靜態結構」交給「runtime 決策」。
下面這個 widget 把三者並排，切 tab 看 failure mode → system move 的對照。
切 tab 比對三個瓶頸的 failure mode 與 system move · 3 個 tab
context governance
failure mode：exposure without access
更大的 context 製造 signal dilution——相關證據跟低價值 padding 在同一個 window 裡競爭 attention。
論文：「tokens added without governance often degrade performance rather than improve it」。加得越多，訊號被稀釋得越嚴重。
system move：把 context 當成 selection policy 的輸出，不是固定 buffer。policy 該按語意相關性加權、對 verbosity 在 token budget 下扣分、偏好近期被驗證過的內容、記錄 provenance。
trustworthy memory
failure mode：stale-but-confident
過時的事實導致破壞性行動——calling deleted symbols、reintroducing fixed regressions。
論文：「stale memory rarely prevents retrieval, but regularly leads the agent to act confidently on invalidated assumptions」。問題不在撈不到，而在撈到的是過時的、卻被當成事實。
system move：把信任變成 runtime 決策。retrieval 要加上 staleness penalty（對照最後驗證時間）與 confidence-gated risk term。論文舉 Claude Code 為例——persistent CLAUDE.md 搭配 just-in-time 的 glob／grep，讓 agent 可以 on-demand 重新驗證 environment-dependent 的事實，而不是信任一個 static index。
dynamic skill routing
failure mode：confident-but-unchecked
specialized subagent 回傳 plausible 但沒被下游驗證的輸出。
論文：「as specialized skills multiply, the failure mode shifts from a missing capability to a present-but-unverified one」。能力越多，「缺能力」的問題反而被「有能力但沒驗證」取代。
system move：把 routing 當成一個 learned policy，搭配明確的 post-condition check。論文的類比：「Dynamic skill routing is the analogue of scheduling in operating systems」——online 估計 subtask type、confidence-aware escalation、mixture-style composition。
三個瓶頸的共同形狀很清楚：每一個都是把「靜態的、信任預設成立的結構」換成「runtime 的、信任要被持續驗證的決策」。
context 不再是固定 buffer 而是 selection policy 的輸出；memory 的信任不再是「撈得到就用」而是按 staleness 與 confidence 動態 gate；skill 的輸出不再是「回傳即採信」而是要過 post-condition check。
論文對 dynamic skill routing 的那個作業系統類比，值得多想一層。「Dynamic skill routing is the analogue of scheduling in operating systems」——在對的時間把對的 subtask 派給對的專用路徑，靠的是 online 估計 subtask type、confidence-aware escalation、mixture-style composition。
這跟 OS scheduler 在對的時間把 CPU 派給對的 process 是同一類問題：不是「有沒有那個 resource」，而是「有沒有一個好的 policy 去分配它」。
當 agent 的工具與 subagent 多到一定程度，routing policy 的品質就會直接決定 pass^k 的尾端——就像一個沒有好 scheduler 的多核機器，核再多也跑不快。
把治理翻成評測——harness-level benchmark 的研究 agenda
找到瓶頸只是一半。
論文的另一半論點是：現有的 benchmark 量不出這些瓶頸，因為它們只看 one-shot task success——任務最後有沒有完成。
而 harness 的好壞藏在過程裡，不在 endpoint。兩個 agent 可以都把任務做完，但一個用了 5K token、零次 hallucination，另一個用了 80K token、靠運氣繞過三個 stale 記憶——endpoint accuracy 給它們一樣的分數。
把這兩條 trajectory 並排畫出來，就能看到 endpoint accuracy 的盲點長什麼樣——兩條路最後都點到同一個綠色的「任務完成 ✓」，但中間的過程一條乾淨、一條髒得驚人，而 one-shot 指標對這段差異完全失明。
兩個 agent，同一個 endpoint「✓」，截然不同的過程
-
Agent A · 乾淨endpoint ✓
context：5K token · hallucination：0 · stale 記憶：0 · verification：每步皆驗
直線抵達。每一步的 p 都接近 1，process metrics 全綠。這是 harness 治理良好的長相。
-
Agent B · 髒endpoint ✓
context：80K token · hallucination：2 · stale 記憶：3（靠運氣繞過） · verification：缺
繞了一大圈、踩過三個 stale 記憶、靠運氣才沒翻車。process 髒得驚人，但 endpoint 一樣是「✓」。
endpoint accuracy 的盲點：兩條 trajectory 最後都落在同一個「✓」，但 Agent B 的…
endpoint accuracy 讓零 hallucination 的 5K token 路徑與靠運氣繞三個 stale 記憶的 80K token 得同分。
論文呼籲改量 process metrics——量過程，不只量結果。
原話列了四件要量的事：「how much context and computation were used, how the trajectory unfolded, what was retrieved and verified, and how risk was incurred」——用了多少 context 與計算、trajectory 怎麼展開、retrieve 了什麼又驗證了什麼、過程承擔了多少風險。
對應到一組新的評測維度：trajectory quality、memory hygiene、context efficiency、communication fidelity、verification cost、以及 safe evolution over time。
每一個都對應前面某個瓶頸。
context efficiency 量的是 context governance 做得好不好——同樣的任務，用了多少 token 達成。
一個會把無關內容塞滿 window 的 harness，efficiency 很差，即使它最後完成了任務。
memory hygiene 量的是 trustworthy memory——記憶裡有多少 stale、矛盾、未驗證的條目。
一個記憶越跑越髒的 agent，hygiene 分數會隨時間下滑，而這是 endpoint accuracy 完全看不到的。
communication fidelity 量的是 multi-agent 之間的訊息有沒有失真——這正是前面那個「breadth-first 贏、但有 coordination failure」觀察的可測版本。
verification cost 則量「為了確保正確，付出了多少額外計算」。
驗證不是免費的，論文把它當成一個要被明確計入的成本，而不是隱形的好習慣。
論文的 Table 4 把這些維度跟現狀對照，盤點得很誠實。
one-shot completion 是 common，這是現有 benchmark 的 baseline。
但其餘幾乎全是缺口——memory retrieval precision、memory hygiene、minimal-context efficiency、communication fidelity、long-session／trajectory drift 都標成 rare（罕見、需要補）；verification-aware recovery 與 safety under tool access 標成 partial（部分有、仍不足）。
把 Table 4 的盤點攤成一張表會更刺眼——每一列是一個評測維度，標著它量的是哪個 harness 瓶頸、以及現有 benchmark 的覆蓋程度。點 column header 可以按覆蓋程度排序，common 的就那一格，rare 與 partial 佔了整張表。
點 column header 按覆蓋程度排序 · 論文 Table 4 · 8 個維度
| 評測維度 | 量的是哪個瓶頸 | 現有 benchmark 覆蓋 |
|---|---|---|
| one-shot task completion | endpoint accuracy | common |
| verification-aware recovery | 𝒢 governance | partial |
| safety under tool access | 𝒢 governance | partial |
| memory retrieval precision | ℳ trustworthy memory | rare |
| memory hygiene over time | ℳ trustworthy memory | rare |
| minimal-context efficiency | 𝒞 context governance | rare |
| communication fidelity | 𝒪 orchestration | rare |
| long-session / trajectory drift | 𝒪 orchestration | rare |
論文 Table 4 的 benchmark-coverage 盤點
現有 benchmark 只量 one-shot endpoint；memory hygiene 等長程指標幾乎全是 rare 或 partial。
這份盤點本身就是論文的貢獻之一：它把「我們對 agent 的評測還停在 endpoint accuracy」這件事攤開，並指出 safe evolution over time——agent 隨時間演化（學新 skill、改 memory）時的安全性——是現在幾乎沒人量、卻對生產部署最要命的維度。
一個會自己更新 memory 的 agent，如果沒有 memory hygiene 的評測，你根本不知道它的記憶在三個月後是變好還是變髒。
為了讓抽象的論點落地，論文做了一個 Python-native 的 reference harness——CheetahClaws——並把它跟 Claude Code、OpenClaw 並排比較。
重點不是哪個比較好，而是論文的這句話：「comparable agent primitives can be governed differently under different deployment priorities」——同一組 agent primitive，在不同的部署優先級下會被治理成不同的樣子。
三者都在解同一組 system 問題（context governance、memory trust、skill routing），但選擇不同。下面這張表是論文 Table 1 的對照，可以點 column header 排序。
點 column header 排序 · 4 欄 × 6 列
| 屬性 | Claude Code | OpenClaw | CheetahClaws |
|---|---|---|---|
| language | TypeScript | TypeScript | Python |
| setting | vendor coding agent | personal assistant | research reference |
| interaction | terminal CLI / IDE | messaging（Discord, Slack） | terminal CLI |
| context governance | user, project, session | user, channel-peer, session | user, project, session |
| memory | persistent text + auto-extraction | conversation history + vector retrieval | structured entries（confidence, recency） |
| availability | closed-source | open-source | open-source |
論文 Table 1 的 system design pattern 對照
context governance、memory trust、skill routing 三問題在三個系統裡殊途同歸，是 agent 的固有設計難題。
三個系統的對照之所以有說服力，正因為一件事——它們的 deployment priority 截然不同，卻在 system 分解上殊途同歸。
Claude Code 為了可靠的 vendor 部署，用 hybrid 做法——「persistent project guidance up front while retrieving information just in time through glob/grep-style tools」，前面給穩定的專案指引，需要時才用 glob／grep 即時撈。
這正是 trustworthy memory 那個 system move 的實作：與其信任一個 static index，不如讓 agent on-demand 重新驗證 environment-dependent 的事實。
OpenClaw 作為多通道的 personal assistant，是個 messaging gateway（Discord、Slack），記憶走 conversation history + vector retrieval。
它的 context governance 軸是 user、channel-peer、session——因為它要在多人多通道的場景裡分清楚「誰對誰說的」。
CheetahClaws 則強調透明度，把信任做成 runtime 決策——「per-entry confidence and recency as first-class fields, used directly in retrieval ranking and conflict resolution」。
每一條記憶都帶著 confidence 與 recency 兩個欄位，直接參與 retrieval 排序與衝突解決。這是把 staleness penalty 與 confidence-gated risk 從論文裡的公式變成資料結構裡的欄位。
三條路，同一組問題。
論文據此下結論：context governance、memory management、skill routing 是 agentic AI 的 intrinsic design problem，不是某個產品的 incidental feature。
它們不是某家廠商的設計品味，而是任何想跑 long-horizon agent 的人遲早都要正面回答的問題。
回到最初的謎題。
模型越來越強、agent 卻還在搞砸 long-horizon——不是因為模型不夠強，而是因為 P_H = Φ(ℛ, ℳ, 𝒞, 𝒮, 𝒪, 𝒢) 裡，model scaling 只動了 ℛ 一格，而長程崩潰的 pass^k 衰減主要由另外五格決定。
換大模型、塞更多 tool、給更長 context，三個直覺候選各自動到了部分變數，卻都漏掉了那層治理機制——沒有 selection policy 的 context 會 dilution，沒有 staleness gate 的 memory 會 stale-but-confident，沒有 post-condition check 的 tool 會 confident-but-unchecked。
瓶頸從模型搬到了 harness。
這對正在做 agent 的人有一個很具體的含意：你下一個 quarter 的工程投入，可能不該全押在「等更好的 model」或「接更多 tool」，而該分一大塊給那層過去被當成膠水的執行層——它的 memory 怎麼驗證、它的 context 怎麼選、它的 tool 輸出怎麼把關。
把它翻成三個可以下週就開始動手的問題——不必等任何新模型，今天就能查。
第一，你的 memory 有沒有 staleness 的概念？
如果你的 agent 從一個 static index 或一份從不過期的 doc 撈事實，它遲早會 stale-but-confident。最小的修法是給每條記憶一個「最後驗證時間」，並讓 retrieval 對舊條目扣分——CheetahClaws 把 recency 當 first-class field 就是這個意思。
第二，你的 context 是 selection policy 還是固定 buffer？
如果你的做法是「把所有可能相關的東西都塞進 prompt」，你正在製造 dilution。試著給 context 一個 token budget，並讓進 budget 的每段內容回答「你憑什麼佔位」——相關性、精簡度、來源、新鮮度。
第三，你的 subagent 輸出有沒有 post-condition check？
如果一個 specialized tool 回傳「done」你就採信，你正在累積 confident-but-unchecked 的風險。給每個 skill 配一個明確的驗證步驟，哪怕只是一個便宜的 sanity check，都能把那一步的 p 拉回來。
三個問題的共同點是：它們都不需要更大的模型。
它們需要的是把信任從「預設成立」改成「持續驗證」——這正是 scaling the harness 的全部內容。
Take-away：下次 agent 在 long-horizon 任務上崩了，先別急著等下一代模型——把 pass^k 的衰減攤開，問問是哪一步的 p 掉了，再去看那一步是 context 沒被治理、memory 過時被信任、還是 tool 輸出沒被驗證。瓶頸多半不在 ℛ，在它外面那五格 harness。