市面上有許多 AI 程式開發應用程式，儘管大型語言模型及其支援的代理程式已令人印象深刻，但近期 AI 輔助開發的許多進展，都發生在管理這些模型的軟體上，而不僅僅是模型本身。

今年夏天稍早，我與 Anthropic 旗下 Claude Code 的產品負責人 Cat Wu 進行了訪談，討論該公司建構這類軟體的方法。Wu 在我們的對話中反覆強調同一點：Anthropic 的模型（及其直接競爭對手的模型）改進速度非常快，因此過度超前規劃，或圍繞它們建構過於主觀或限制性的功能，意義不大。

相反地，Claude Code 產品團隊試圖維持他們所謂的「精簡輔助系統」（lean harness）。

輔助系統（harness）是圍繞一個或多個 AI 模型所建構的軟體，它決定了模型如何被使用。它決定了模型看到什麼、可以採取什麼行動，以及如何與程式碼庫互動。你可以將它想像成模型與開發者實際專案之間的一個層次。

這並非表示 Claude Code 作為一個應用程式和輔助系統，沒有任何主觀功能或設計選擇，但其產品團隊確實傾向於相信模型在未來一年將會帶領他們走向何方。

除了 Claude Code 之外，還有其他輔助系統，例如 OpenAI 的 Codex、Google 的 Antigravity、OpenCode 等開源替代方案，以及 Cursor 或 Augment Code 等新創公司的選項。每個系統可能具有不同的功能、重點或對於模型在代理工作流程中如何或應該如何被利用的觀點。

Claude Code 的一個關鍵選擇是預設避免預先為程式碼庫建構結構化上下文的方法。她談到這些方法時表示：「根據評估結果，我們沒有看到可衡量的變化。」「我認為我們通常更傾向於推出一個更精簡的輔助系統，包含較少主觀工具，並讓開發者如果需要，可以自行添加。」

Augment Code 則做出了截然不同的選擇，儘管兩家公司測試的介入措施或優化的結果不一定相同；其產品透過嵌入（embeddings）、檢索模型和向量資料庫預先索引儲存庫，然後檢索概念上相關的程式碼。因此，為了聽取討論的另一方觀點，我採訪了 Augment Code 的工程副總裁 Vinay Perneti。

Perneti 簡要描述了 Augment Code 的不同方法，提供了他團隊對其優勢的評估，回應了一些支持精簡輔助系統的論點，並分享了他對開發者普遍擔憂 AI 工具和代理工作流程的看法。

Ars Technica：您能解釋一下 Augment Code 的上下文引擎是如何運作的嗎？

Vinay Perneti：如果我退一步來看，開發者究竟想達成什麼？他們希望完成一項特定任務，並將其交給一個代理程式。而當今代理程式的有趣之處在於，它們的上下文視窗（context window）有限，每次都需要獲取所有必要的上下文才能進行工作。

處理上下文有兩種方法。一種是基於 grep 的方法。Claude Code 和 Codex 以及其他代理程式都採用了這種方式。第二種是語義檢索（semantic retrieval）。對於 Augment 而言，我們始終採用語義路徑，我將描述其構成要素。

我會說有兩個核心部分。一個是，我們系統中有一個嵌入和檢索模型對在運作，然後你有一個向量資料庫和一個完整的、高度優化的後端系統，使得在亞毫秒級別內進行檢索成為可能。

Ars：它在某種程式碼庫中是否比另一種更有優勢？

Perneti：是的，事實證明，優勢體現在大型私有程式碼庫中。這就是我這麼說的原因。對於所有公開的開源儲存庫，大多數基準測試都在這些儲存庫上運行，每個模型基本上都已經記住了這些儲存庫。這些模型足夠大，實際上能夠記住整個儲存庫。因此，當你試圖完成某件事時，模型已經知道要去哪裡尋找，所以它們可以很快地得出結果。

然而，當你在私有儲存庫中執行此操作時，模型從未見過該儲存庫。此時，尋找結果的迭代循環會長得多，對吧？如果你對整個私有儲存庫有語義理解，你可以提出一個問題，並且更快地得到結果。

Ars：人們擔心代幣效率。這種語義方法有幫助嗎？

Perneti：我們在某些情況下確實看到了這一點。事實上，我們發表了一篇部落格文章，我們使用 Claude Code 和 Augment Code 運行了 Terminal-Bench，模型相同。我們以相似的準確度完成，但我們比 Claude Code 效率高出 33%。因此，我確實看到這在更好地利用代幣方面有所體現，因為你沒有花費那麼多時間在探索上。

Ars：Anthropic 告訴我，Claude Code 從包含更多語義程式碼導航工具中沒有看到可衡量的評估收益。但當我查看您的部落格時，我看到您發布了基準測試和其他聲明，表明這確實有幫助。你們在說這話時測量的是不同的東西嗎，或者他們的評估遺漏了什麼？

Perneti：好問題。我不知道他們使用了什麼特定的檢索引擎，而且我認為人們經常混淆的另一個錯誤是，並非所有檢索系統都是平等的，就像並非所有資料庫都是平等的，對吧？我的意思是，模型和協同工作的系統，也就是上下文引擎，在結果品質方面會產生很大的差異。

舉例來說，在 Augment，我們在公司於 2022 年成立之初，也就是 ChatGPT 之前，花了大約 18 個月的時間，主要研究大型程式碼庫的檢索和嵌入模型。因此，當你試圖達成特定結果時，如何在嵌入空間中獲取正確的程式碼片段，這方面投入了大量的研究。所有這些都編碼在我們的檢索模型中。

我們圍繞它建構的系統，就是以非常非常快速的方式完成這項工作。所以當有人說：「嘿，我嘗試了帶有 RAG 實作的 Claude Code，但我沒有看到好處」，那是因為實作和上下文引擎非常非常不同，如果這說得通的話。

Ars：對於模型改進如此之快，以至於任何帶有假設的建構都毫無意義的觀點，您怎麼看？這就是支持超級精簡輔助系統或不這樣做的論點，因為隨著指數級增長，你不知道六個月或十二個月後會變成什麼樣。

Perneti：這其中有很多道理，但我認為你必須從幾個不同的角度來思考。在 Augment，我們一直以來都是這樣思考的：要獲得更高品質的結果，你需要兩種要素，即智慧（intelligence）和上下文（context）。當模型變得非常出色時，智慧將會呈指數級增長，這點毫無疑問。但僅僅因為它們更聰明，並不意味著它們擁有上下文。

現在，一個人可以透過花費代幣來獲取他們想要的上下文。這就引出了第二個維度，也就是所有工程主管現在都在問的問題：成本。你的代幣預算中有多少用於上下文收集和產生正確的結果？你是否以正確的方式使用模型來獲得最高品質的結果？

這就是我認為輔助系統設計和上下文很重要的原因。所以對我來說，這是智慧和上下文的結合，然後這就變成了一個系統工程問題：你如何將適當的精力投入到這些垂直領域中的每一個，以便以最低的成本獲得最優化的結果？

Ars：我們有相當多的讀者對軟體開發中的 AI 持懷疑態度。我看到兩種特別常見的反對意見。其中之一是他們仍然覺得無法充分信任這些系統，認為它們會產生不值得的技術債。另一個是這些代理工作流程太昂貴了。您怎麼看？

Perneti：我會同時談到這兩點。讓我先為這兩點做個鋪墊。我認為每個人都希望同意的基本事實是，模型正在以指數級的速度持續改進。所以無論你做什麼，你都希望順應這種指數級增長，以便了解事物的發展方向，並調整自己以從中受益。

回到你關於信任、驗證和技術債的問題，如果你將這個問題視為「我將任務交給代理程式然後走開」，那確實會產生問題。但這不是它的運作方式，這就是為什麼我指出這是人類團隊與代理程式團隊協同工作，在許多方面，人類仍然更適合判斷，對吧？規格審查就是一個例子。

我們發現代理程式實際上不擅長撰寫規格。所以你必須真正與代理程式合作，引導它撰寫一份良好、高品質的規格。但一旦你有了規格，我們就處於一個它們非常擅長執行的階段。所以不利用這一點是沒有道理的。

第二件事……順帶一提，技術債確實非常真實。我們在 Augment 內部注意到的一種模式，我們顯然非常重視代理程式，是代理程式非常擅長複製程式碼……所以我們發現我們必須進行專注的衝刺，利用代理程式來減少技術債。這樣做的好處是，你可以提出一個關於如何減少技術債的規格，而它們非常擅長執行。所以我認為這是解決這部分問題的方法。

第二部分，你談到了成本。我認為這裡有一個有趣的觀點。如果你相信這是未來的工作方式，那麼你如何為你的代幣獲得最佳結果？這就是我認為像上下文引擎這樣的東西會產生影響的地方。對我來說，為正確的任務選擇正確的模型會產生巨大的差異。

第二件事，這更像是一個哲學性的、前瞻性的觀點，是，隨著這些模型能力繼續呈指數級改進，並且開源模型將會跟上，將會出現一個轉折點，我認為用於前沿實驗室和開源模型的代幣比例將開始傾斜，你最困難的問題仍然會交給前沿模型，但我描述的程式碼編寫步驟，比如我確切知道需要做什麼，並且我已經在規格中描述了，開源模型可能能夠為你完成。

到那時，你的成本會大幅下降，對吧？所以你需要一個允許你這樣工作的系統，我認為成本會自行解決，這就是我的看法。

Ars：謝謝您。我很感謝。