Agent 框架選型：LangGraph、原生 SDK、Pydantic AI，不是誰取代誰

Threads 討論 LangChain/LangGraph、Anthropic/OpenAI SDK、Pydantic AI 與自建 agent harness 的選型。真正的判斷軸不是流行度，而是流程固定度、客製化程度、可觀測性、團隊招募、模型升級速度與產品控制權。

2026年6月8日4 分鐘閱讀👁 8

Agent Engineering · Framework Selection

Agent 框架選型的核心：先判斷你要的是「可預測 workflow」還是「模型驅動 harness」

Threads 討論 LangChain / LangGraph、Anthropic / OpenAI SDK、Pydantic AI 與自建 agent harness 的選型。可重用的結論不是「LangGraph 好或壞」，而是：框架越重，越適合固定流程、團隊交接與生態整合；SDK / 自建 harness 越適合高客製化、產品內核、低層優化與快速跟上模型能力。

LangChain / LangGraph 適合什麼

當 flow 已經相對固定、需要節點式 orchestration、human-in-the-loop、狀態圖、可視化、團隊共同語言與招募辨識度時，LangGraph 仍有優勢。它把「工作流」明確化，降低從零設計 runtime 的成本。

原生 SDK / 自建 harness 適合什麼

當產品本身就是 agent runtime、需要精細控制 context、tool calling、重試、快取、權限、sandbox、成本、觀測與模型差異時，直接用 OpenAI / Anthropic SDK 或自建 harness 通常更乾淨。Hermes 這類 agentic system 更接近這一路線。

Pydantic AI 適合什麼

Pydantic AI 是較輕的中間層：保留 typed output、dependency injection、toolsets、evals、Logfire 等工程化能力，但不強迫所有流程都進入大型 graph framework。適合 Python 團隊、資料型產品與需要 schema-first 的 agent 原型。

AI 引擎作核心大腦

留言提到下一代可能直接用 pi / opencode 類 AI engine 作核心，透過配置、技能、腳本、代理完成任務；資源存取則做成 API 給核心調度。這是「框架」之外的第三條路：把 agent runtime 當產品內核，而不是只嵌一個 library。

關鍵分歧：Anthropic 的「Building Effective Agents」明確區分 workflows 與 agents：workflows 是 LLM / tools 依照預先定義的 code path 被 orchestration；agents 則是 LLM 動態決定流程與工具使用。選型前如果沒有先回答「我要 workflow 還是 agent」，很容易把框架辯論變成宗教戰。

選型	優勢	風險	最適合場景
LangChain / LangGraph	graph / workflow 表達清楚、生態完整、教學與人力市場可辨識、適合固定流程。	抽象層可能限制底層優化；遇到模型/SDK 新能力時可能被框架節奏卡住。	企業流程、研究 demo、RAG pipeline、審核節點、固定多步驟任務。
OpenAI / Anthropic SDK	最貼近模型能力；容易控制 prompt、tools、streaming、state、guardrails、成本。	需要自己做 runtime、觀測、錯誤處理、權限、測試與狀態管理。	產品核心 agent、長期維護系統、高度客製化任務、需要快速跟模型更新。
Pydantic AI	typed schema、工具、依賴、eval、Logfire 觀測與 Python 生態整合佳。	仍是框架；超複雜 orchestration 或跨語言 runtime 可能要外接/自建。	Python 後端、資料/商務流程、schema-first agent、輕量多 agent pattern。
自建 AI engine / harness	控制權最高，可把工具、技能、sandbox、記憶、權限、排程與 UI 協定做成產品能力。