2026 Agent 框架大比拼：Kimi vs Claude vs LangGraph vs MiniMax
2026 年初，AI Agent 框架的版圖已經從「概念驗證」進入「工程落地」階段。不同廠商、不同團隊基於各自的技術背景與產品定位，走出了截然不同的架構路線。本文深入比較四個具有代表性的 Agent 框架：Kimi Agent SDK、Claude Agent SDK、LangGraph 以及 MiniMax Mini-Agent，從架構設計、工具系統、記憶管理到程式碼規模與品質，逐一剖析它們的技術細節與設計哲學。
四大框架一覽
在進入細節之前，先用一張表格建立整體印象：
| 維度 | Kimi Agent SDK | Claude Agent SDK | LangGraph | MiniMax Mini-Agent |
|---|---|---|---|---|
| 開發商 | MoonshotAI | Anthropic | LangChain | MiniMax |
| 授權 | Apache-2.0 | MIT (Python) | MIT | MIT |
| 核心定位 | CLI-as-Engine SDK wrapper | CLI-as-Engine SDK wrapper | 圖狀態機編排框架 | 最小化參考實作 + CLI 工具 |
| 架構模式 | 薄客戶端 + CLI 子進程 | 薄客戶端 + CLI 子進程 | Pregel 計算引擎 | 直接 Agent Loop |
| 支援語言 | Go, Node.js, Python | TypeScript, Python | Python, JS/TS (SDK) | Python |
| 綁定模型 | Moonshot / 多供應商 | Claude (Anthropic) | 任意 LLM | MiniMax M2.5 / 多供應商 |
| 程式碼規模（原始碼） | ~15,000 行（三語言合計） | ~3,500 行（Python SDK） | ~20,000 行 | ~5,200 行（核心）/ ~22,000 行（含 Skills） |
| 測試程式碼 | ~8,400 行 | ~6,000 行 | ~36,500 行 | ~3,500 行 |
架構比較：三種截然不同的路線
四個框架在架構層面呈現出三種明確的設計路線，這是理解它們差異的關鍵切入點。
CLI-as-Engine 路線（Kimi 與 Claude）
Kimi Agent SDK 和 Claude Agent SDK 不約而同地選擇了同一種架構模式：SDK 本身不實作 Agent 邏輯，而是作為薄客戶端包裝已有的 CLI 工具。
應用程式碼
|
Agent SDK（薄客戶端）
|
CLI 子進程（真正的 Agent 引擎）
|
LLM API兩者的 SDK 角色極為相似——啟動並管理 CLI 子進程、透過 stdin/stdout 的 JSON 協議雙向通訊、處理串流事件、管理 Session 生命週期。真正的 Agent Loop、工具執行、記憶管理全都發生在 CLI 內部。
這種架構的核心優勢在於一致性：SDK 使用者獲得的能力與直接使用 CLI 完全相同，包括所有內建工具、安全沙箱、權限管理。CLI 版本升級時，SDK 自動受益，大幅降低維護成本。
然而，代價也很明顯——必須安裝對應的 CLI，除錯時需要理解跨進程通訊，SDK 的功能天花板受限於 CLI 的能力邊界。
Graph-based 路線（LangGraph）
LangGraph 走了一條完全不同的路。它受 Google Pregel 論文啟發，將 Agent 的執行過程建模為有向圖上的狀態流動，採用 Bulk Synchronous Parallel（BSP）計算模型：
StateGraph 定義 → 編譯為 Pregel 引擎
|
每一步（Step）：
1. Plan：決定要執行的節點
2. Execute：並行執行所有選中節點
3. Update：將寫入套用到 Channel
|
重複直到完成或達到步數上限LangGraph 不直接與任何 LLM 通訊——它是一個純粹的編排框架。開發者需要自行定義節點函式、狀態 Schema、邊的邏輯，LangGraph 負責狀態管理、持久化、中斷/恢復等基礎設施。
Direct Loop 路線（Mini-Agent）
MiniMax Mini-Agent 採用了最直觀的架構——經典的 ReAct 迴圈：
while step < max_steps:
呼叫 LLM → 有 tool_calls? → 執行工具 → 將結果加入歷史 → 繼續
沒有 → 返回回應沒有圖、沒有子進程、沒有中間層。整個 Agent Loop 就是一個 while 迴圈，訊息歷史就是核心狀態。這種設計的好處是極易理解和修改，但在複雜場景下的擴展性有限。
架構模式對比表
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| Agent Loop 位置 | CLI 內部 | CLI 內部 | Pregel 引擎 | agent.py 直接實作 |
| 通訊方式 | JSON-RPC 2.0 / stdio | JSON stream / stdio | 函式呼叫（in-process） | 函式呼叫（in-process） |
| 狀態管理 | CLI 管理 | CLI 管理 | Channel + Checkpoint | messages list |
| 並行能力 | CLI 決定 | CLI 決定 | BSP 步內自動並行 | 無（循序執行） |
| 可擴展性 | 透過外部工具 | 透過 Hook + MCP | 自訂節點 + 子圖 | 繼承 Tool 基底類 |
Agent Loop 設計比較
Agent Loop 是框架的心臟，四個框架在這一層的設計差異深刻地影響了使用體驗。
Kimi：Session / Turn / Step 三層抽象
Kimi 的 Agent Loop 由 CLI 內部驅動，SDK 側接收串流事件。核心抽象為三層：Session（連線生命週期）、Turn（一次對話來回）、Step（推理/工具步驟）。SDK 端必須依序發送 Prompt、必須消耗完所有事件、必須回應 ApprovalRequest，否則 Session 會阻塞。
特別值得一提的是 Ralph Loop 模式——一種「迭代驗證」機制。Agent 執行完畢後，用外部命令驗證結果，若驗證失敗則帶著結果重新提交，直到通過或達到上限。這體現了「永遠不信任 Agent 輸出」的工程哲學。
Claude：基於回合的控制協議
Claude Agent SDK 同樣是 CLI 驅動，但其控制協議設計更為豐富。除了基本的訊息串流外，SDK 與 CLI 之間還有雙向控制請求——工具權限查詢（can_use_tool）、Hook 回呼觸發（hook_callback）、MCP 工具呼叫（mcp_message）。每個控制請求都有唯一 ID 和超時機制，形成了一套完整的雙向協商系統。
Claude 還提供兩個使用介面：query() 用於一次性查詢（無狀態、適合自動化），ClaudeSDKClient 用於互動式對話（有狀態、支援中斷和動態控制）。
LangGraph：圖上的狀態流動
LangGraph 的「Agent Loop」本質上是圖的遍歷。每一步中，Pregel 引擎根據 Channel 的版本追蹤機制決定哪些節點需要執行，並行執行後將輸出套用到 Channel。這種設計帶來了獨特的能力——條件分支、多源等待、Map-Reduce 並行——但也意味著開發者需要用「圖」的思維來設計 Agent 邏輯。
LangGraph 提供了 create_react_agent 作為快速建立 ReAct Agent 的捷徑，內部結構為 agent → should_continue → tools → agent 的循環圖。但更複雜的場景（如多輪審核、分支決策）才是 LangGraph 真正發揮優勢的地方。
Mini-Agent：純粹的 while 迴圈
Mini-Agent 的 Agent Loop 是四者中最直接的——一個 while 迴圈，每次迭代呼叫 LLM、檢查 tool_calls、執行工具、更新歷史。取消機制透過 asyncio.Event 在三個檢查點（步驟開始、工具執行前、工具執行後）中斷。取消後會清理最後一個不完整的 assistant message。
工具系統比較
工具系統是 Agent 框架的手腳，決定了 Agent 能做什麼、怎麼做。
內建工具比較
| 工具類別 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| Shell 執行 | Shell | Bash | 無（自行實作） | BashTool（含背景程序管理） |
| 檔案讀取 | ReadFile | Read | 無 | ReadTool（帶 token 截斷） |
| 檔案寫入 | WriteFile | Write | 無 | WriteTool |
| 檔案編輯 | StrReplaceFile | Edit / MultiEdit | 無 | EditTool |
| 檔案搜尋 | Glob + Grep | Glob + Grep | 無 | 無 |
| 網路功能 | SearchWeb + FetchURL | WebFetch + WebSearch | 無 | 透過 MCP |
| 子 Agent | Task（SubagentEvent） | 子代理系統 | 子圖（Subgraph） | 無 |
| 筆記/記憶 | 無 | TodoWrite | 無 | SessionNoteTool |
| Notebook | 無 | NotebookEdit | 無 | 無 |
一個明顯的差異是：Kimi、Claude 和 Mini-Agent 都提供了「開箱即用」的內建工具集，因為它們本質上是 coding agent；而 LangGraph 作為通用編排框架，不綁定任何特定工具，開發者需要自行定義或使用 prebuilt 的 ToolNode。
自訂工具機制
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| 定義方式 | Go: 泛型 + struct tag Node.js: Zod schema Python: Pydantic + agent YAML | Python: @tool 裝飾器 TS: tool() helper | @tool 裝飾器（LangChain） | 繼承 Tool 基底類 |
| Schema 生成 | 自動（反射/Zod/Pydantic） | 手動指定參數字典 | 自動（from docstring） | 手動定義 JSON Schema |
| 執行位置 | SDK 側（外部工具）或 CLI 側（內建） | SDK 進程內或 CLI 側 | 圖節點內 | Agent 進程內 |
| 工具權限 | 核准流程（approve/reject） | can_use_tool 回呼 + Hook | 無內建 | 無 |
MCP 支援
Model Context Protocol（MCP）已成為 Agent 工具擴展的事實標準。四個框架的支援程度如下：
| MCP 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| MCP 支援 | 原生（mcp.json） | 原生（三種類型） | 透過整合 | 原生（mcp.json） |
| Stdio 傳輸 | 支援 | 支援 | 支援 | 支援 |
| HTTP/SSE 傳輸 | 支援 | 支援 | 支援 | 支援 |
| 進程內 MCP | 無 | Python SDK 獨有 | 無 | 無 |
| OAuth 認證 | 支援 | 支援 | 不明 | 無 |
Claude Agent SDK 的 Python 版本有一個獨特設計：進程內 SDK MCP 伺服器。透過 @tool 裝飾器定義工具，create_sdk_mcp_server() 建立伺服器實例，工具直接在 Python 進程中執行，無需子進程管理。這對需要存取應用程式狀態的場景尤其實用。
記憶與狀態管理比較
記憶管理是 Agent 從「一次性對話」進化為「持續協作」的關鍵能力。
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| 對話歷史 | CLI 管理（JSONL 檔案） | CLI 管理 | Channel + Checkpoint | messages list（記憶體） |
| Session 持久化 | 本地檔案系統 | 本地（session_id） | Checkpoint Saver（記憶體/SQLite/PostgreSQL） | 無（僅 SessionNote 持久化） |
| Session 恢復 | resume() / WithSession() | resume / continue_conversation / fork | 指定 checkpoint_id | 無 |
| Context 壓縮 | CLI 自動觸發 | CLI 處理 | 開發者自行實作（pre_model_hook） | LLM 驅動的摘要機制 |
| Token 追蹤 | StatusUpdate 事件 | ResultMessage.usage | 開發者自行實作 | API 回報 + tiktoken 估算 |
| 跨 Session 記憶 | 無明確機制 | 無明確機制 | BaseStore（長期記憶） | SessionNote（JSON 檔案） |
LangGraph 在狀態管理方面的設計最為精密。其 Checkpoint 系統支援完整的 Time-Travel Debugging——可以遍歷圖的所有歷史快照，回到任意一步重新執行。每個 Checkpoint 包含 Channel 值、版本號、每個節點的「已見版本」，形成了一套精確的版本追蹤機制。
Mini-Agent 的上下文摘要機制則頗有巧思：當 token 數超過閾值時，保留所有 user messages（代表使用者意圖），將每輪 assistant/tool 訊息用 LLM 摘要為一條簡短記錄，結構化地替換歷史，避免粗暴截斷導致上下文斷裂。
Human-in-the-loop 比較
在生產環境中，Agent 的自主行為需要受到人類監督。四個框架提供了不同程度的人機協作支援。
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| 核准機制 | ApprovalRequest（approve / approve_for_session / reject） | can_use_tool 回呼 + PermissionMode | interrupt() / interrupt_before / interrupt_after | 無內建（CLI 的 Esc 取消） |
| 粒度 | 工具級別 | 工具級別 + 輸入修改 + 規則更新 | 任意節點級別 | 無 |
| 自動核准 | yolo 模式 | bypassPermissions 模式 | 無 interrupt 即全自動 | 預設全自動 |
| 恢復機制 | 繼續 Turn | 繼續對話 | Command(resume=value) | 無 |
| 結構化協議 | 三選一回應 | Allow（可修改輸入）/ Deny | HumanInterrupt + HumanResponse（accept/ignore/response/edit） | 無 |
LangGraph 在這方面的設計最為靈活。interrupt() 函式可以在任何節點內呼叫，中斷圖的執行並將值序列化到 Checkpoint。客戶端收到中斷後，透過 Command(resume=value) 恢復，節點會從頭重新執行，interrupt() 這次返回恢復值繼續。這種機制結合 Checkpoint 的持久化能力，可以實現跨天甚至跨週的長時間工作流。
Claude Agent SDK 的權限系統則更偏向安全控制。can_use_tool 回呼不僅能批准或拒絕，還能修改工具輸入（例如自動加上安全限制）和更新權限規則（例如「批准後同類操作自動放行」），適合需要細粒度安全管控的企業場景。
語言與 SDK 支援比較
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| Python | 支援（asyncio, >= 3.12） | 支援（anyio, >= 3.10） | 核心語言 | 核心語言（>= 3.10） |
| TypeScript/Node.js | 支援（ES2022+） | 支援（Node.js 18+） | SDK 客戶端 | 無 |
| Go | 支援（>= 1.22） | 無 | 無 | 無 |
| Schema 工具 | reflect / Zod / Pydantic | TypedDict + dataclass / Zod | Pydantic / TypedDict | Pydantic |
| 非同步模型 | channel (Go) / AsyncIterator (Node) / asyncio (Python) | anyio（asyncio + trio） | asyncio | asyncio |
Kimi Agent SDK 是唯一支援三種語言的框架，且各語言的實作特色鮮明：Go 版本用泛型自動生成 JSON Schema，技術上最優雅；Node.js 版本功能最豐富，附帶完整的 VSCode Extension；Python 版本則直接 import CLI 的 Python 套件（不走子進程通訊），耦合度最高但性能最好。
Claude Agent SDK 的 Python 版本有一個值得注意的設計選擇：使用 anyio 作為非同步基礎，同時相容 asyncio 和 trio 兩種非同步框架，這在追求跨框架相容性的場景下很實用。
串流與即時輸出比較
串流能力直接影響使用者體驗，特別是在長時間執行的 Agent 任務中。
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| 文字串流 | ContentPart 事件（逐塊） | StreamEvent（原始 API 串流事件） | stream_mode=“messages”（逐 token） | 無（一次性返回） |
| 思考過程 | ContentPartTypeThink 事件 | ThinkingBlock | 開發者自行處理 | Interleaved Thinking（雙協議） |
| 工具呼叫串流 | ToolCall / ToolCallPart / ToolResult | ToolUseBlock / ToolResultBlock | stream_mode=“updates” | CLI 印出（非串流） |
| 自訂串流 | 無 | 無 | StreamWriter（stream_mode=“custom”） | 無 |
| 多模式串流 | 單一模式 | 部分訊息串流 | 可同時多種 stream_mode | 無 |
LangGraph 提供了最豐富的串流選項，共七種 StreamMode：values（完整狀態）、updates（增量變更）、checkpoints（快照建立）、tasks（任務開始/結束）、debug（包含前兩者）、messages（LLM token）、custom（自訂資料）。這些模式可以組合使用，滿足從 UI 渲染到除錯日誌的各種需求。
Mini-Agent 的 Interleaved Thinking 支援是其獨特亮點。在 Anthropic 模式下透過 thinking block、OpenAI 模式下透過 reasoning_details，完整保留模型在多輪 tool-use 中的思維鏈。這對使用 MiniMax M2.5 模型的推理場景至關重要。
權限與安全模型比較
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| 權限模式 | 核准流程（approve / reject / approve_for_session） | 四級（default / acceptEdits / plan / bypassPermissions） | 無內建 | 無 |
| 沙箱支援 | KAOS 沙箱後端（BoxLite / E2B / Sprites） | Sandbox 配置（網路限制、命令排除） | 無 | 無 |
| 工具白名單 | CLI 設定 | tools / allowed_tools / disallowed_tools | 開發者自行控制 | 設定檔開關 |
| Settings 隔離 | CLI 設定 | setting_sources（預設完全隔離） | 無（無 settings 概念） | 設定檔搜尋優先級 |
| 費用控制 | LoopControl（max_steps） | max_budget_usd + max_turns | recursion_limit | max_steps |
| Hook 系統 | 無 | 10 種 Hook 事件（PreToolUse / PostToolUse / Stop / …） | 無（透過節點函式實作） | 無 |
Claude Agent SDK 在安全模型方面的設計明顯最為完善，反映了 Anthropic 對 AI 安全的一貫重視。其 Hook 系統提供了十種事件類型，可以在工具執行前後、使用者提示提交時、Agent 停止時等關鍵節點插入自訂邏輯。PreToolUse Hook 不僅能阻止工具呼叫，還能修改工具輸入和提供額外上下文給模型——這是一種「軟性 guardrail」設計。
Settings 預設隔離是另一個重要的安全設計：SDK 預設不載入任何 settings（包括 CLAUDE.md、斜線命令、子代理），確保在 CI/CD 和生產環境中行為完全可預測。
程式碼規模與結構比較
衡量一個框架的「重量」不能只看原始碼行數——測試程式碼的規模同樣能反映工程成熟度。以下是四個框架的實際量測結果：
| 維度 | Kimi Agent SDK | Claude Agent SDK | LangGraph | Mini-Agent |
|---|---|---|---|---|
| 主要語言 | Go + TypeScript + Python | Python | Python | Python |
| 原始碼行數 | ~15,000（三語言合計） | ~3,500 | ~19,700 | ~5,200（核心）/ ~22,400（含 Skills） |
| 原始碼檔案數 | 102 | 13 | 64 | 25（核心） |
| 測試行數 | ~8,400 | ~6,000 | ~36,500 | ~3,500 |
| 測試檔案數 | 20 | 20 | 22 | 16 |
| 測試 / 原始碼比 | 0.56x | 1.71x | 1.86x | 0.68x（對核心） |
幾個值得注意的觀察：
Claude Agent SDK 是最精煉的框架。僅 3,500 行原始碼、13 個檔案，卻擁有 6,000 行測試（1.71x 比率）。這種「小而精」的特質源於其設計哲學——SDK 只是薄客戶端，複雜邏輯全在閉源的 CLI 中。從使用者視角來看，這意味著 SDK 本身的可讀性極高，掌握全貌的門檻最低。
LangGraph 的測試投資最為驚人。36,500 行測試程式碼是原始碼的 1.86 倍，這在開源 Agent 框架中極為罕見。如此高的測試密度反映了 Pregel 計算模型的複雜性——狀態流動、Channel 更新、Checkpoint 一致性等都需要大量邊界條件測試。這也是 LangGraph 能在生產環境中提供 durable execution 保證的基礎。
Kimi Agent SDK 的多語言策略帶來維護成本。三種語言 15,000 行程式碼、102 個檔案，但各語言的測試覆蓋差異明顯：Go 的測試比率達 1.15x，TypeScript 僅 0.42x，Python 最低只有 0.14x。這暗示了多語言 SDK 的現實困境——很難對每種語言都投入同等的品質保障資源。
Mini-Agent 的數字需要拆解來看。表面上的 22,400 行中有 15,900 行是 Skills 插件（多數來自 Anthropic 的 submodule），核心框架僅 5,200 行。以核心計算，測試比率為 0.68x，屬於中等水準。這印證了其「最小化參考實作」的定位——核心足夠簡單，不需要像 LangGraph 那樣的海量測試。
程式碼品質評估
原始碼行數只是量的指標，程式碼品質還需要從型別安全、靜態分析、CI/CD 成熟度等面向來評估。
型別安全與靜態分析
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| 型別系統 | Go：編譯時強型別 TS：TypeScript 靜態型別 Python：無 mypy | Python：mypy strict 模式 | Python：mypy（moderate） | Python：無 mypy |
| mypy 嚴格度 | N/A（Python 部分未啟用） | 最嚴格（strict=true, disallow_untyped_defs） | 中等（disallow_untyped_defs, 部分 error code 豁免） | 未配置 |
| Linter | Go：golangci-lint（CI） TS/Python：無 | ruff（廣泛規則集：E, W, F, I, N, UP, B, C4） | ruff（E, F, I, TID251, UP） | pylint（僅禁用 arguments-differ） |
| 型別提示覆蓋率 | Go/TS 天然 100% | Python 17%（但 strict mypy 補償） | Python 37% | Python 15% |
Claude Agent SDK 在型別安全方面的投入最為突出。雖然函式級型別提示的表面覆蓋率只有 17%，但其 mypy strict 配置是四者中最嚴格的——disallow_untyped_defs、disallow_incomplete_defs、no_implicit_optional、warn_unreachable 全部開啟。這意味著每一個公開介面都必須有完整的型別標註，漏標會直接報錯。配合 ruff 的廣泛規則集（涵蓋命名規範、程式碼升級、bugbear 等），形成了雙重防護網。
LangGraph 的 mypy 配置相對寬鬆——允許某些 typeddict-item、return-value、override 錯誤豁免。這可能是大型程式碼庫的務實妥協，但也意味著某些型別不一致可能被掩蓋。
Kimi Agent SDK 的情況比較特殊。Go 和 TypeScript 兩種語言天生具備靜態型別系統，不需要額外的型別檢查工具。但其 Python SDK 完全沒有配置 mypy 或 ruff，品質保障的一致性存在落差。
Mini-Agent 僅配置了最基本的 pylint，且只禁用了一條規則（arguments-differ），沒有 ruff 也沒有 mypy。對於一個「參考實作」來說，這尚可接受；但若要在生產環境中使用，型別安全方面的投入明顯不足。
CI/CD 與工程流程
| 面向 | Kimi | Claude | LangGraph | Mini-Agent |
|---|---|---|---|---|
| CI 工作流數量 | 6 | 9 | 14 | 0 |
| 自動化測試 | 分語言獨立跑（go.yml, node.yml, python.yml） | test.yml + lint.yml | ci.yml + _lint.yml + _test.yml + _integration_test.yml | 無 |
| 效能基準測試 | 無 | 無 | bench.yml | 無 |
| AI 程式碼審查 | kimi-review.yml | claude-code-review.yml | 無 | 無 |
| AI Issue 分類 | 無 | claude-issue-triage.yml | 無 | 無 |
| 建構自動化 | Makefile：無 | Makefile：無 | Makefile：完整（lint, format, test, lock） | Makefile：無 |
| 發布流程 | 分語言發布 | build-and-publish.yml | release.yml | 無 |
LangGraph 的 CI/CD 管線最為完善——14 個工作流涵蓋了 lint、單元測試、整合測試、效能基準測試和發布，配合根目錄的 Makefile 統一管理。這是大型 monorepo 的工程最佳實踐。
一個有趣的趨勢是 Kimi 和 Claude 都在 CI 中引入了自家 AI 模型做程式碼審查（kimi-review.yml 和 claude-code-review.yml），Claude 甚至還有 AI 驅動的 Issue 分類（claude-issue-triage.yml）。這是「AI for AI development」的直接體現——用 Agent 來維護 Agent 框架。
Mini-Agent 完全沒有 CI/CD 設施。結合其無 mypy、無 ruff 的狀態，可以判斷這是一個以「快速迭代、概念驗證」為主的專案，尚未進入生產級的工程管理階段。
程式碼品質總評
| 框架 | 品質等級 | 一句話評價 |
|---|---|---|
| Claude Agent SDK | 最高 | 最小的程式碼量、最嚴格的型別檢查、優秀的測試比率——小而精的典範 |
| LangGraph | 高 | 最完善的 CI/CD、最大的測試投資——大型開源專案的工程標竿 |
| Kimi Agent SDK | 中等 | Go/TS 受益於語言本身的型別系統，但 Python 品質保障明顯薄弱 |
| Mini-Agent | 基礎 | 符合「參考實作」定位，但缺乏型別檢查和 CI 意味著生產使用需額外投資 |
適用場景與建議
根據以上分析，不同的框架適合不同的使用情境：
選擇 Kimi Agent SDK 的情境
- 已經是 Kimi Code CLI 的使用者，希望將 CLI 能力整合到應用程式中
- 需要多語言（Go / Node.js / Python）的 SDK 支援
- CI/CD 自動化場景，特別是需要 Ralph Loop 迭代驗證的情境
- 希望復用 CLI 已有的設定、工具和 MCP 伺服器
- 需要沙箱隔離執行（KAOS 後端）
選擇 Claude Agent SDK 的情境
- 基於 Claude 模型建構企業級 Agent 應用
- 需要細粒度的權限控制和安全審計（Hook 系統 + 沙箱）
- 需要進程內 MCP 工具（Python SDK 的 @tool 裝飾器）
- CI/CD 整合，重視環境隔離和行為可預測性
- 需要結構化輸出（JSON Schema）或思考配置（Extended Thinking）
選擇 LangGraph 的情境
- 建構複雜的多步驟工作流（條件分支、平行處理、Map-Reduce）
- 需要持久化執行和 Time-Travel Debugging
- 需要精密的 Human-in-the-loop 流程（跨天的審核工作流）
- 希望使用不同 LLM 供應商而不被鎖定
- 團隊已熟悉 LangChain 生態系統
- 需要自訂所有細節，而非使用預設的 coding agent 工具集
選擇 MiniMax Mini-Agent 的情境
- 使用 MiniMax M2.5 模型，需要完整的 Interleaved Thinking 支援
- 學習 Agent 架構的教學用途（核心僅約 2000 行程式碼）
- 需要快速搭建一個 CLI Agent 原型
- 重視 Skill 系統的 Progressive Disclosure 設計
- 需要整合 ACP 協議（如 Zed 編輯器）
設計哲學總結
回顧四個框架，最令人印象深刻的不是功能差異，而是設計哲學的分野。
Kimi 與 Claude 的「CLI-as-Engine」哲學源自一個務實的洞察：CLI 已經是一個久經考驗的 Agent 引擎，SDK 不應該重新發明輪子，而是專注於提供友好的程式化介面。這種「薄客戶端」模式犧牲了一定的靈活性，換來了一致性和可維護性。兩者的差異在於 Claude 更重視安全控制（Hook、權限、隔離），而 Kimi 更重視多語言覆蓋和工程效率（Ralph Loop）。
LangGraph 的「圖即程式」哲學將 Agent 執行抽象為圖計算問題。這是一個高風險、高回報的設計選擇——學習曲線陡峭，但一旦掌握，就能表達出其他框架難以實現的複雜工作流。Pregel 計算模型帶來的確定性、可重放性和原生並行能力，在需要 durable execution 的生產場景中具有不可替代的價值。
Mini-Agent 的「極簡主義」哲學則代表了另一種態度：不需要所有場景都用「大框架」解決。一個精心設計的 while 迴圈、一套完整的內建工具、一個巧妙的 Skill 載入機制，就足以建構出實用的 Agent 系統。Mini-Agent 證明了小團隊同樣可以產出高品質的 Agent 實作，特別是當你能充分利用模型本身的推理能力（Interleaved Thinking）時。
最終，選擇哪個框架取決於你的具體需求：如果你需要的是一個「coding agent 即服務」的 SDK，Kimi 或 Claude 是最直接的選擇；如果你需要建構複雜的自訂工作流，LangGraph 提供了最強大的基礎設施；如果你需要的是一個輕量、可理解、可修改的起點，Mini-Agent 是最好的學習素材和原型工具。
在 Agent 框架這個快速演進的領域中，沒有「最好的」框架，只有「最適合的」框架。理解每個框架背後的設計哲學，比記住它們的功能清單更重要——因為功能會更新，但設計哲學決定了框架的演進方向。