本文原載於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年的開源智能體工具包已相當成熟，但選擇的關鍵在於理解各層約束與權衡。