Lagent：把 PyTorch 的層思維搬進 LLM 代理

誰會需要一個只有兩層抽象的代理框架

多數代理框架把工具呼叫、規劃、記憶體、追蹤全部包成一套高階 API，用起來快，但要改其中一個環節就得繞過框架。Lagent 走的是相反路線。README 開頭直接說明它受 PyTorch 的設計哲學啟發，希望用神經網路層的類比讓工作流程更清楚，使用者只需要建立層、並用 Python 的方式定義層之間的訊息傳遞。

這個定位決定了它的讀者。適合的對象是已經在用 vLLM 或 HuggingFace 這類推論後端、想把代理行為寫成自己程式碼的人，以及需要控制 few-shot 範例怎麼插進對話歷史、或需要自訂模型輸出解析規則的團隊。不適合的對象同樣清楚：想要現成工具市集、想要內建網頁介面、或想要一個不會在 rc 之間改介面的依賴項的人。README 的示範從頭到尾都在寫 Python 類別，沒有出現任何設定檔或 CLI，這本身就是一個訊號。

AgentMessage 與 Memory：整個框架的資料流

Lagent 的核心不是 prompt 模板，而是兩個結構。AgentMessage 是訊息單位，欄位包含 sender、content、formatted、extra_info、type、receiver 與 stream_state。Memory 則是這些訊息的容器。

README 用一段虛擬碼說明每次 forward 的順序：__call__ 先跑 pre_hooks，把輸入訊息寫進 memory，呼叫 forward，再把輸出訊息寫進 memory，最後跑 post_hooks。作者特別註明這個動作發生在 __call__ 而不是 forward，這個區別有意義：如果你直接覆寫 forward，記憶體不會自動更新，你得自己處理。

檢查記憶體有兩條路徑。agent.memory.get_memory() 回傳 AgentMessage 物件列表，agent.state_dict() 回傳可序列化的 dict，其中 memory 這個鍵對應的是一串純字典。後者適合存檔或送到別的程序。清除單一會話用 agent.reset()，README 說明預設的 session_id 是 0。這個設計把狀態放在 Agent 實例上，而不是外部儲存層，多會話要靠 session_id 區分。

DefaultAggregator：真正決定送給模型什麼的地方

訊息進到模型之前，會先經過 aggregator。README 的 forward 片段顯示，DefaultAggregator 的 aggregate 方法接收 memory、agent 名稱、output_format 與 template 四個參數，回傳 OpenAI 格式的訊息列表，再交給 self.llm.chat 送出。

這個位置是 Lagent 最值得注意的擴充點。README 給了一個 FewshotAggregator 的完整範例，繼承 DefaultAggregator 並覆寫 aggregate：先放入 system instruction，再插入固定的 few_shot 列表，接著逐筆走訪記憶體。規則是 sender 等於 agent 名稱時標成 assistant，否則標成 user；如果前一筆已經是 user，就把內容接在同一筆上，而不是新增一筆。最後一點在實際使用中會產生影響，因為連續的使用者訊息會被合併，模型看到的輪次結構和你寫入的次數不一致。

它同時揭露一個限制：aggregator 的簽章決定了你能拿到什麼。要插入 few-shot，你得自己保存那份列表；框架不會幫你管理。

output_format 與 ToolParser：解析結果放在 formatted 欄位

模型回來的字串要變成可用的結構，靠的是 output_format。README 的 forward 片段顯示，當 self.output_format 存在時，框架會呼叫 parse_response 處理模型輸出，然後建立一個 AgentMessage，content 保留原始字串，formatted 存放解析後的結果。

這個切分很實際。原始輸出永遠留著，除錯時不必回頭重跑模型。formatted 是保留欄位，專門放解析結果，不會和 content 混在一起。

README 在示範工具解析時引入 lagent.prompts.parsers 的 ToolParser，並搭配一段要求模型逐步分析並編寫 Python 程式碼的 system_prompt。提供的材料在這裡被截斷，看不到完整的解析輸出長相，所以無法確認工具呼叫的具體格式與錯誤處理行為。這一點在評估時應該直接翻 docs 或原始碼，不要靠 README 推測。

安裝與最小可跑範例的實際內容

安裝只有一條路徑，從原始碼裝：

git clone https://github.com/InternLM/lagent.git cd lagent pip install -e .

README 沒有提供 pip install lagent 的指令，雖然徽章連到 PyPI 頁面。用 -e 模式安裝意味著你的環境會直接指向本地目錄，之後拉新版要自己 git pull。

最小範例是 Models as Agents 那一段。它從 lagent.llms 引入 VllmModel 與 INTERNLM2_META，用 path='Qwen/Qwen2-7B-Instruct' 指定權重，設定 tp=1、top_k=1、temperature=1.0、stop_words=['<|im_end|>']、max_new_tokens=1024。這些鍵名是範例的一部分，不是框架層級的設定檔。接著用 Agent(llm, system_prompt) 建立代理，送出一則 AgentMessage，得到回覆。

有一個細節容易被忽略：範例把 INTERNLM2_META 這個 meta template 套在 Qwen 模型上。README 沒有解釋這個搭配的後果，實際使用時應該確認你的模型是否有對應的 meta template，否則對話格式可能對不上。

版本節奏與維護成本：rc 標籤透露的訊息

最近的釋出是 agentrl_rc0，時間在 2026 年 5 月。在那之前是 v0.5.0rc3 與 v0.5.0rc2，分別在 2025 年 3 月與 2024 年 11 月。三個版本全部帶 rc 標籤，v0.5.0 從 rc2 走到 rc3 花了約三個月，之後一年多沒有新的 v0.5.0 系列釋出，然後出現一條命名不同的 agentrl_rc0。

對採用者的意義很直接。以 rc 為依賴版本，代表介面在正式版之前仍可能調整，而 DefaultAggregator 的 aggregate 簽章、AgentMessage 的欄位、forward 的參數都是你可能覆寫的對象。升級時要重新檢查這幾個地方，尤其是你自己實作的 aggregator 與 output_format。

授權是 Apache-2.0，允許商業使用與修改，散布時需保留授權與變更聲明。這不是法律意見，實際條款請讀 LICENSE 檔案。維護面上，README 沒有提供版本相容性承諾或棄用政策，這是評估長期依賴時需要自行承擔的風險。

和 LangChain 的路線差異在哪裡

把 Lagent 和 LangChain 放在一起看，差異不在功能多寡，而在抽象放在哪一層。LangChain 提供 Chain、Tool、Retriever、Memory 等一整套預先定義的元件，你組裝它們；Lagent 只給你 Agent、Memory、Aggregator、Parser 這幾個位置，其餘由你寫。

具體到資料流：LangChain 的記憶體有多種後端與策略可選，Lagent 的 Memory 就是一個訊息列表加上 session_id 索引，README 只示範了 get_memory、state_dict 與 reset 三種操作。LangChain 的工具呼叫有既定協定，Lagent 則要你自己用 output_format 定義解析規則，ToolParser 是其中一種現成選擇。

代價與好處是同一件事。Lagent 的程式碼路徑短，出了問題你能一路讀到 llm.chat 那一行；但少了生態系的現成元件，任何非標準需求都要自己補。如果你的需求正好落在它的抽象範圍內，這個交換划算；如果你需要的是檢索、多後端記憶體、現成工具整合，LangChain 那一側的既有元件會省下更多時間。

編輯結論

如果你需要自己決定訊息怎麼聚合、模型輸出怎麼解析，而且願意讀原始碼，Lagent 的 Agent 與 DefaultAggregator 提供了明確的切入點。如果你要的是開箱即用的工具鏈與穩定的 API 承諾，這個專案目前的版本節奏會讓你付出代價：v0.5.0 仍停在 rc2 與 rc3，2026 年 5 月又出現 agentrl_rc0 這條獨立線，介面在正式版之前仍有變動空間。採用前請先確認兩件事：你的模型是否已有對應的 meta_template，以及你的 Python 版本能否通過 pip install -e . 的相依解析。

官方來源

1. InternLM/lagent on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases