編碼智慧體的組成部分

在本文中，作者旨在全面介紹編碼智慧體及智慧體框架的整體設計：它們是什麼、如何工作，以及各個部分如何在實踐中相互配合。作者經常收到其著作《從零構建大型語言模型》和《從零構建大型推理模型》讀者關於智慧體的提問，因此認為撰寫一篇可供參考的文章會非常有用。

更廣泛地說，智慧體已成為一個重要話題，因為近期實用LLM系統的許多進展不僅僅來自更好的模型，更來自我們如何使用它們。在許多實際應用中，周圍系統（如工具使用、上下文管理和記憶）所起的作用與模型本身同樣重要。這也解釋了為什麼像Claude Code或Codex這樣的系統在使用相同模型時，會比普通的聊天介面感覺強大得多。

文章首先闡述了LLM、推理模型和智慧體之間的區別。LLM是核心的下一個詞元預測模型，推理模型是經過訓練或提示以在推理時花費更多計算進行中間推理、驗證或搜尋候選答案的LLM，而智慧體則是封裝在環境中的控制迴圈，能夠呼叫工具、管理記憶並更新狀態。智慧體框架是圍繞智慧體的軟體腳手架，管理上下文、工具使用、提示、狀態和控制流；編碼框架則是針對軟體工程的特定框架，專門管理程式碼上下文、工具、執行和迭代反饋。

接下來，文章詳細介紹了編碼智慧體的六個主要構建模組：

1. 即時倉庫上下文：這是最明顯也最重要的元件之一。當使用者說“修復測試”或“實現xyz”時，模型應該知道它是否在Git倉庫內、當前分支是什麼、哪些專案文件可能包含說明等。編碼智慧體會在開始工作前先收集資訊（作為工作空間摘要），確保每次提示不是從零開始。例如，如果智慧體看到AGENTS.md或專案的README，它就能瞭解要執行的測試命令等。Git分支、狀態和提交資訊也能幫助提供關於當前正在進行的更改以及關注重點的更多上下文。

2. 提示形狀與快取重用：一旦智慧體有了倉庫檢視，下一個問題是如何將這些資訊高效地輸入模型。智慧的執行時不會在每次互動時都從零構建整個提示，而是保持穩定的提示字首（包含通用指令、工具描述和工作空間摘要），只更新變化的部分（如最新的使用者請求、最近的對話記錄等）。這種快取機制極大地減少了計算浪費，因為會話中大部分資訊是重複的。

3. 工具訪問與使用：工具訪問讓編碼智慧體顯得更像智慧體而非聊天機器人。智慧體不能隨意生成任意語法，而是從預定義的允許工具列表中選擇，並提供清晰引數。執行時可以驗證工具名稱、引數有效性，並在執行前請求使用者批准。這種約束既提高了安全性，也提高了可靠性。例如，在Mini Coding Agent中，模型必須選擇類似列出檔案、讀取檔案、搜尋、執行Shell命令、寫入檔案等工具，並提供正確格式的引數。執行時會在執行前進行多項檢查，如工具是否已知、引數是否有效、是否需要使用者批准、請求的路徑是否在工作空間內等。

4. 最小化上下文膨脹：編碼智慧體特別容易受到上下文膨脹的影響，因為重複讀取檔案、冗長的工具輸出和日誌會迅速消耗上下文令牌。好的框架會採用裁剪、摘要和去重等策略。關鍵技巧是保持近期事件更豐富，而更積極地壓縮舊事件，因為它們可能相關性較低。此外，還會對舊的檔案讀取進行去重，防止模型反覆看到相同的內容。作者指出，許多表面上的“模型質量”實際上是上下文質量。

5. 結構化會話記憶：編碼智慧體將狀態分為至少兩層：工作記憶（小型、精煉的狀態）和完整對話記錄（所有使用者請求、工具輸出和LLM響應的完整歷史）。工作記憶用於任務連續性，保持當前任務、重要檔案和近期筆記的摘要；完整對話記錄支援會話恢復，儲存為JSON檔案。緊湊的轉錄用於提示重建，給模型一個壓縮的近期歷史檢視，而工作記憶則用於維護跨回合的關鍵資訊。

6. 委派子智慧體：一旦智慧體擁有工具和狀態，委派就成為有用能力。主智慧體可以將子任務委派給受限的子智慧體（例如只讀或限制遞迴深度），從而實現並行化並提高速度。設計挑戰不僅在於如何生成子智慧體，還在於如何繫結它們以防止重複工作。Claude Code長期支援子智慧體，Codex最近也增加了此功能。子智慧體通常會繼承主智慧體的沙盒和審批設定，但邊界更多在於任務範圍、上下文和深度。

文章還對比了編碼智慧體與OpenClaw。OpenClaw更像一個通用的本地智慧體平臺，也能處理編碼任務，但最佳化方向不同。編碼智慧體針對個人在倉庫中工作並請求編碼助手檢查檔案、編輯程式碼和高效執行本地工具進行了最佳化，而OpenClaw更最佳化於跨聊天、頻道和工作空間執行多個長期存在的本地智慧體。

最後，作者宣佈其新書《從零構建推理模型》已完成，目前處於早期訪問階段，預計夏季正式出版。這本書涵蓋了評估推理模型、推理時擴充套件、自我改進、強化學習和蒸餾等主題，是作者迄今為止最雄心勃勃的作品。作者認為，理解LLM中“推理”的最佳方式是從零實現一個推理模型。