編碼智能體的組成部分

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

更廣泛地説，智能體已成為一個重要話題，因為近期實用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中“推理”的最佳方式是從零實現一個推理模型。