代理沒有變聰明——是專案變了

六個月前，一項程式設計任務需要整個工作階段來說明。上週，同類型的任務只需要一句話。在這兩個工作階段之間，模型並沒有改變。Claude Opus 4.6 服務了這兩次工作階段。相同的權重、相同的架構、相同的上下文視窗、相同的能力。

AI 代理在第 1 次到第 500 次工作階段之間並沒有變聰明；是專案基礎設施改變了。 這是AI 工程領域的核心論點：模型是常數，變數是您圍繞它所建構的一切。在長期運行的專案中，模型大約貢獻工作階段品質的 30%，而累積的上下文提供另外 70%：慣例文件、決策記憶、交接成果、hooks、技能與測試覆蓋率。較差的模型在豐富的專案上，往往勝過較好的模型在貧乏的專案上。

是專案改變了。

錯誤的對話

AI 生產力的討論幾乎完全聚焦於模型能力。哪個模型最快。哪個模型寫出最好的程式碼。哪個模型處理最長的上下文。其隱含的假設是：模型是變數——升級模型，輸出就會改善。

對於長期運行的專案而言，這個假設是錯的。在一個我投入六個月、累積超過 500 次代理工作階段的專案上，模型大概只貢獻工作階段品質的 30%。另外 70% 來自累積的專案基礎設施：慣例文件、決策記憶、交接成果、行為 hooks、成文化的技能與測試覆蓋率。

較好的模型在貧乏的專案上，會比較差的模型在貧乏的專案上產出更好的結果。但較差的模型在擁有 500 次工作階段累積上下文的專案上，往往會比較好的模型在貧乏的專案上產出更好的結果。基礎設施凌駕於模型之上。這正是為何上下文即架構——累積的專案知識並非輔助資訊，而是承重結構。

證據

市場頁面效能修復的案例印證了這個論點。一句話：「修復市場頁面的效能。」代理：

讀取前次工作階段的交接文件，其中已診斷出瓶頸
識別出正確的程式碼路徑（market_hub()，而非 _fetch_market_data()）
實作了帶有聚合 RPC 的分頁資料庫查詢
撰寫測試
部署

Austin 從 14 秒降到 108 毫秒。單一提示帶來 132 倍的改善。¹

這並非因為模型聰明而發生。這是因為交接文件存在。那份交接文件捕捉了一份診斷，這份診斷歷經三次程式碼審查修正與兩次優先順序重新排序，在四天內存活下來。若沒有交接文件，代理會從零開始。它會調查錯誤的程式碼路徑（就像交接文件的初稿那樣）。它會提議不必要的 HTMX partials（就像原始計畫那樣）。交接文件包含了已經犯下並修正的錯誤。代理繼承了修正後的理解。

模型的貢獻在於閱讀交接文件並實作修復。基礎設施的貢獻則在於擁有正確的交接文件可供閱讀。

什麼會改變，什麼不會

在同一個專案的第 1 次與第 500 次工作階段之間，只有一件事保持不變：模型。其他一切都在改變。

改變的事物：

CLAUDE.md 從空白成長到完整。慣例相關的問題消失了。AGENTS.md patterns 這篇文章描述了讓這些檔案發揮效用的具體模式。
記憶檔案累積。決策被快取。權衡被記錄。專案停止重新爭論已經定案的問題。
Hooks 累積。每一個都預防了先前工作階段中發生的某一類失敗。84 個 hooks 攔截 Claude Code 所暴露的 26 種生命週期事件類型中的 15 種，每一個都是過往事故留下的疤痕。
技能累積。重複性的工作流程變成單一指令操作。曾經需要整個工作階段才能設計的 nightcheck，如今 2 分鐘就能執行完畢。
測試累積。代理能做出更大膽的變更，因為它能立即驗證。
交接文件累積。複雜的調查跨越工作階段邊界持續存在。

保持不變的事物：

模型。相同的權重。相同的能力。相同的傾向——偏離任務、幻覺驗證測試結果（請參閱證據門檻）、以及提議不必要的抽象層。

模型的失效模式是恆定的。基礎設施捕捉這些失效模式的能力則隨著每一次工作階段成長。第 500 次工作階段優於第 1 次，並非因為模型進步了，而是因為基礎設施學會了彌補模型恆定的弱點。

投資視角

如果模型不是變數，那麼模型選擇就不是主要的投資決策。主要的投資在於上下文基礎設施。

一個每月花費 200 美元購買 Claude Max（預設執行 Opus 4.7）並大力投資於 CLAUDE.md 檔案、記憶系統、hooks、技能與測試覆蓋率的團隊，會勝過另一個同樣每月花費 200 美元購買相同方案，但完全未投資基礎設施的團隊。模型成本相同。輸出品質之所以分化，是因為基礎設施分化了。

這重新定義了生產力的問題。問題不在於「我們應該使用哪個模型？」而在於「我們在模型周圍建構了什麼，讓每一次工作階段都比上一次更好？」

我所見到在 AI 生產力上掙扎的組織，並不是使用了錯誤的模型。他們是每一次工作階段都從零開始。沒有慣例文件。沒有記憶系統。沒有 hooks。沒有技能。沒有累積的上下文。無論之前有過多少次工作階段，每一次都是第 1 次。

模型會進步

模型會持續進步。Claude Opus 4.7 優於 Claude Opus 4.6，Opus 5 會更好。進步是真實且有價值的。但進步是加法的，而非乘法的。

在程式碼生成上好 20% 的模型，在貧乏的專案上會產出好 20% 的結果。但同一個模型搭配 500 次工作階段累積的上下文，產出的結果在質上截然不同，而不僅僅是量上更好。上下文基礎設施並不是在模型的能力上加 20%。它提供了診斷、限制、驗證標準與操作歷史——這些是模型無論多有能力，都無法獨自產生的。

沒有任何模型，無論多麼強大，能夠知道 market_hub() 會載入所有 company_markets 列並在 Python 中進行分頁——除非有東西告訴它。交接文件告訴它。模型讀取並行動。智慧分散於模型（閱讀、推理、實作）與基礎設施（知曉、約束、驗證）之間。

第 500 次工作階段

第 500 次工作階段是這樣的：我用一句話陳述我想要什麼。Ralph agent architecture 就是讓這一切成為可能的系統。代理讀取 CLAUDE.md 並了解慣例。它讀取記憶檔案並知曉決策。它讀取交接文件並掌握診斷。它遇到一個 hook，該 hook 預防了另一個代理三個月前犯過的同樣錯誤。它對照測試套件檢查自己的工作。它以證據支持每一項主張，並回報完成。

第 1 次工作階段則是這樣的：我說明資料庫結構、路由慣例、模板繼承、快取層、部署流程與測試模式。代理提出釐清的問題。它提議一個違反三項慣例的方法。我修正它。它實作修復。它回報「測試通過」，卻沒有實際執行 pytest。

兩次工作階段中，模型是相同的。專案則不同。

常見問答

模型品質不是仍然重要嗎？

重要。更強的模型能更有效地閱讀上下文、更精準地推理權衡、更俐落地實作解決方案。模型品質設定了下限。基礎設施抬高了上限。在成熟的專案上，上限比下限更重要。

這是否僅限於程式設計代理？

並非如此。任何在跨工作階段重複出現相同任務領域的 AI 工作流程，都能從累積的上下文中獲益。寫作、研究、分析、客戶支援皆然。具體的基礎設施有所不同（以風格指南取代 CLAUDE.md、以知識庫取代 hooks），但動態是一致的：專案會變得更好，因為環繞模型的上下文持續累積。

那多模態模型或推理模型呢？

原則相同。一個能花 10 分鐘思考問題的推理模型，仍然需要知道該思考什麼問題。交接文件、慣例檔案與記憶系統提供問題的定義。模型提供推理。較佳的推理施加於定義良好的問題上，會產生優於劣等推理的結果；但較佳的推理施加於未定義的問題上，只會產生聽起來更有說服力的混亂。

如果我完全沒有上下文基礎設施，該從何開始？

撰寫一份描述您專案慣例的 CLAUDE.md 檔案。那一份檔案就是影響力最高的投資。其他一切都會從那裡開始複利成長。²

來源

Blake Crosley, “Compound Context: Why AI Projects Get Better the Longer You Stay With Them,” blakecrosley.com, March 2026. ↩
Anthropic, “Manage Claude’s memory,” Anthropic Documentation, 2026. ↩