本文原載於Paolo Perrone的Substack專欄《AI工程師》，經授權轉載。
你花了三週時間交付一個智慧體。它在演示中執行良好。但一進入生產環境，你發現所選框架沒有檢查點功能，記憶層只是扁平向量轉儲，缺乏時間推理能力，瀏覽器工具在遇到Canvas元素時崩潰，評估套件只是某個Notion文件，別人總忘記更新。
2026年，用於構建智慧體的開源工具包已解決了大部分這些問題。但問題在於，每個問題的解決方案都有十多種互不相容的方式。在長對話記憶基準測試LoCoMo中獲勝的記憶框架，每條對話的開銷是亞軍的340倍，而這一差異在基準測試結果中並未體現。同樣的差距在每一層都存在。
因此，最佳方法是先確定系統在負載下最先遇到的約束：延遲預算、審計追蹤、模型可移植性還是語言棧。選錯的話，第三週就得重寫狀態模式。
各層選擇策略
選擇工具時，需回答三個問題：主要約束是什麼？選錯後的重寫成本有多高？是開源還是開源核心？
第一層：編排與執行時控制
LangGraph是Python生產環境的預設選擇。基於圖的狀態機，透過PostgresSaver實現持久化執行，支援時間旅行除錯，擁有最大的已驗證企業客戶名單。但程式碼冗長，對簡單任務過度設計。
CrewAI設定開銷最低，宣告角色後即可執行。但生產永續性不足，無法恢復崩潰的執行，錯誤處理粗粒度。
Pydantic AI將每個智慧體輸出視為型別化Pydantic模型，驗證和重試即開即用，但多智慧體原語較弱。
Mastra是TypeScript解決方案，適合全棧TypeScript團隊，但生態系統較小。
第二層：記憶與狀態
上下文視窗不是記憶。生產智慧體在專用記憶層中儲存資訊。Mem0將記憶作用域劃分為使用者、會話或智慧體，結合向量和圖儲存，在LoCoMo基準上延遲比全上下文低92%，令牌少93%，但缺乏時間推理。
Zep/Graphiti是時間圖選項，處理實體解析和關係變化，但記憶體佔用大，檢索延遲高。
Letta將記憶視為作業系統，主上下文為RAM，存檔記憶為磁碟，智慧體自行決定遷移內容，但部署和除錯較複雜。
工程教訓：執行時狀態和知識記憶是兩回事，不可混用。
第三層：協議與工具
2026年，MCP（模型上下文協議）成為標準。編寫工具即編寫MCP伺服器。FastMCP是快速編寫Python MCP伺服器的框架，mcp-agent則圍繞MCP構建編排。
第四層：瀏覽器與計算機使用
分為DOM驅動和視覺驅動兩種方案。Browser Use是Python預設選擇，但每一步都需LLM呼叫，成本高。Stagehand是TypeScript方案，允許混合使用AI和指令碼化Playwright。Skyvern是視覺優先方案，在WebVoyager 2.0上得分85.85%，但比DOM驅動慢且昂貴。
生產模式通常結合兩者：DOM驅動為主，視覺方案作為逃生通道。
第五層：編碼智慧體與沙箱
編碼智慧體現在自成品類，包含寫程式碼、執行、除錯和讀取文件的能力。這一層需要沙箱和工具，具體細節可參考相關深度文章。
2026年的開源智慧體工具包已相當成熟，但選擇的關鍵在於理解各層約束與權衡。