AI 寫程式，關鍵不只模型而是上下文
AI coding agent 現在比的不只是模型聰不聰明，也包括外層 harness 怎麼提供工具與程式碼脈絡。Augment Code 的做法是預先替 repository 建立索引，透過 embedding、retrieval model 與 vector database 找出語意相關的程式碼，而非每次接任務才靠 grep 逐步探索。它主要想解決大型私有 codebase 缺乏模型既有知識的問題，讓 agent 更快找到跨檔案、跨模組的關聯，再依規格修改、重構或補齊功能。
現實應用
這套思路最適合 monorepo、企業內部平台、歷史系統，以及文件不完整的大型專案。新進工程師可用它追查功能入口與相依關係；資深工程師則可把明確規格交給 agent 執行批次修改、技術債整理或重複性開發。
小型開源專案未必同樣受益：模型可能早已看過公開程式碼，而且 grep、LSP 與一般搜尋就足夠。真正有感的使用者，會是程式碼量大、模組分散，又在意 token 成本的團隊。
期望評估
我認為低標期望是縮短 agent 尋找相關程式碼的時間，少讀一些無關檔案，並降低每項任務的 token 消耗。Augment Code 表示，在相同模型的 Terminal-Bench 測試中，完成準確度相近，但 token 效率高出 33%；這是廠商測試，不能直接當成所有專案都會得到的結果。
我猜高標情境是企業能建立模型分流：最難的架構判斷交給 frontier model，規格清楚的實作交給便宜或內部部署的 open-weight model，再由同一套 context engine 補足私有知識。不過人仍要負責規格、審查與驗證，因為 agent 會複製既有程式碼，也可能更快堆出技術債。
商業策略分析
我認為這場競爭的核心是「lean harness」與「context-rich harness」兩條路線。Anthropic 傾向少放預設工具，押注模型能力持續進步；Augment Code 則押注模型再強也不會自然知道企業私有程式碼，因此 retrieval 與系統工程仍有付費價值。
這會影響 Cursor、Codex、Claude Code、IDE 廠商與企業開發平台。值得跟進，但採購前應用自家私有 repository 測試任務成功率、token、延遲及技術債，不能只看公開 benchmark。若團隊主要維護小型專案，我猜額外索引成本與治理負擔可能不划算。
實作細節
原文僅說明 Augment Code 會預先索引 repository，以 embedding 與 retrieval model 配合 vector database，並宣稱可在次毫秒級取回相關內容；沒有提供可重現的安裝步驟。已知問題是 agent 不擅長獨立寫出高品質規格，也容易產生重複程式碼，因此仍需人工確認 spec、code review，並安排技術債清理。