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

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

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

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

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

如果任務節點清楚，例如「查資料 → 產報告 → 人審 → 寄出」或「SQL agent → RAG agent → supervisor → human interrupt」，graph 會讓架構更可讀，也方便新人接手。

如果你不想讓 agent 自由度太高，或反過來需要非常細地控制自由度，SDK 自建反而更直接：哪些 tool 可用、何時可用、如何 retry、何時問人，都可以寫成產品規則。

作者提到 LangGraph / LangChain 的好處之一是 JD 好寫、比較容易找到人。這不是玩笑：標準框架能讓團隊快速建立共同語言，降低 onboarding 成本。

Latent Space 文章把爭議描述成「Big Model take the wheel」與「Big Workflows」之間的張力。模型能力快速變強時，過度手工調的 workflow 可能被下一代模型能力打掉；但完全交給模型也會犧牲可預測性。