讓 coding agent 能日常用的，是一堆你覺得無聊的 plumbing
前陣子做一個跨幾個 service 的 refactor，用 Claude Code，大概到第三輪對話的時候出事了。agent 開始重複讀同一個 config 檔，每次都把整個 yaml 塞進 context，沒有任何壓縮，沒有只讀 diff，整個丟進去。到後來 context 強制截斷，它開始遺忘我前面告訴過它的事，然後開始往錯誤的方向走。那次 session 的 token 消耗是平時的三倍，有效輸出大概一半。
Sebastian Raschka 最近把 coding agent 拆成六個元件來分析，包含 live repo context、prompt/cache、tool 設計、context reduction、session memory、delegation/subagents，讀完我的第一反應是：對，這才是真正造成體感差異的地方，不是模型版本。
回到那個 context 爆掉的場景，問題跟模型能力有什麼關係嗎？幾乎沒有。如果有個「只讀 diff，不讀全檔」的工具，如果 context 超過某個閾值時 harness 會自動摘要，問題根本不會發生。但我用的那個環境沒有，所以它爆了。
Context compaction 聽起來很技術，但對日常使用的影響比你想的直接。我試過幾個不同的框架，有些是到達 limit 才開始截，有些是滑動窗口但會把重要的 function 定義截掉，有些完全不管。體感差很多，但這跟你選哪個底層模型完全無關。
Repo context 是另一個讓我花時間才搞清楚的東西。一開始我以為給 agent 更多檔案就對了，後來發現完全不是。重要的不是「給多少」，是「給什麼、什麼時候給」。我現在的做法是在 project 根目錄放一個 AGENTS.md，裡面寫架構決策、禁止動的地方、幾個常見的 gotcha。這個比把整個 codebase 丟進去有用多了，大概減少了 30% 到 40% 的「它走錯方向我要花時間導回來」的對話輪次。
Memory 的問題大多數人低估了。一個 session 結束之後，下一個 session 它完全不知道你上次做了什麼決定，除非你明確把 summary 傳進去。我見過有工程師每次開新對話都要花十分鐘重新解釋背景，這很正常，但這是 tooling 的問題，不是模型的問題。如果 harness 有 session memory，或者有自動產 context summary 的機制，這十分鐘可以省掉。
Subagent 的邊界問題是最近才踩到的坑。讓一個 parent agent 把任務拆給幾個 child agent 做，結果兩個 child 撞了同一個檔案，衝突沒被好好 merge，最後花了比自己做還多的時間收拾。問題不是模型不夠聰明，是 delegation 設計沒有 lock 機制，沒讓 agent 知道哪個範圍是自己的領地。這種事發生一次你就會開始認真看 harness 的設計，而不是只看模型排行榜。
講白話就是：你換一個更強的模型，這些問題都還在。你把 harness 設計好，用舊一點的模型一樣能日常跑。
我不是說模型不重要，能力邊界確實存在，複雜的多步驟推理新模型就是比較可靠。但在日常開發的情境裡，大多數讓你覺得「這個 agent 好爛」的瞬間，其實是 token 爆了、工具讀了不該讀的東西、context 裡少了最關鍵的那段資訊、或者上一個決定沒被帶進這個 session。這些都是 harness 的責任。
所以現在每次有人問我「你覺得 X 還是 Y 模型比較好用」，我的第一個反問都是：你的 harness 是什麼，tool 有沒有 validation，context 怎麼管，session 跑完之後記憶體怎麼傳。因為很多時候，那個問題問錯方向了。
作者：咖啡驅動開發