18. 框架世界观对比:Claude Agent SDK、LangGraph、CrewAI、Pydantic AI

写到最后一篇,该认真聊聊框架了。

前面 17 篇里我们手写了不少 Agent,大多数没用框架。那是为了让你看清"Agent 到底是什么"——一个 messages 循环、一组 tools、一些状态。看清楚之后,选不选框架就是有依据的工程决策,而不是"听说大家都用 LangChain 就跟着用"。

这一篇对比当下四个主流 Agent 框架,讲清各自的世界观、适用场景、坑。最后回到那个永恒的老问题:到底要不要用框架。

一、LangGraph:状态机 + 图

LangGraph 是 LangChain 团队 2024 年推出的 Agent 框架,定位是"低层、可控的状态机"。

世界观:Agent 是一个图,节点是操作,边是流转,共享一个 State。

from langgraph.graph import StateGraph, END
from typing import TypedDict

class State(TypedDict):
    messages: list
    next_step: str

def planner(state: State):
    plan = llm("制定计划...", state["messages"])
    return {"messages": state["messages"] + [plan], "next_step": "executor"}

def executor(state: State):
    result = llm("执行下一步...", state["messages"])
    return {"messages": state["messages"] + [result]}

def should_continue(state: State) -> str:
    if "DONE" in state["messages"][-1]:
        return END
    return "executor"

graph = StateGraph(State)
graph.add_node("planner", planner)
graph.add_node("executor", executor)
graph.set_entry_point("planner")
graph.add_edge("planner", "executor")
graph.add_conditional_edges("executor", should_continue)

app = graph.compile()
result = app.invoke({"messages": [HumanMessage("...")], "next_step": ""})

LangGraph 的优势:

显式控制流——你写的就是状态机,不是 prompt 的玄学控制。每个节点是一个 Python 函数,边是逻辑判断。调试时可视化展示路径,出错能精准定位。

Checkpointer——状态可持久化(SQLite、Postgres、Redis)。Agent 跑一半挂了,从上次保存的状态恢复继续,不丢工作。HITL(第 15 篇)的"暂停-恢复"模式天然支持。

Streaming + 并行——节点级 streaming(看每个节点的中间输出)、节点并行(独立节点并发执行)。

生态——和 LangChain 工具、LangSmith trace、众多 vendor integration 直接打通。

弱点:学习曲线陡(理解状态机 + LangChain 的 Runnable 抽象);抽象偏厚(简单 Agent 写起来代码量比手写多);性能不是强项(Python 对象层层嵌套)。

适合:复杂多 Agent 工作流、需要可视化和持久化的场景、已经在用 LangChain 栈。

二、Claude Agent SDK:Anthropic 的极简主义

Claude Agent SDK 是 Anthropic 2025 年推出的 Agent 工具,TypeScript 优先(Python 版略晚)。

世界观:Agent 应该是一段简单的代码,框架不要把它包得看不见。

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function runAgent(task: string) {
  const messages: any[] = [{ role: "user", content: task }];
  const tools = [
    { name: "search", description: "...", input_schema: {...} },
  ];

  while (true) {
    const resp = await client.messages.create({
      model: "claude-opus-4",
      max_tokens: 4096,
      tools,
      messages,
    });
    messages.push({ role: "assistant", content: resp.content });

    if (resp.stop_reason === "end_turn") {
      return resp.content;
    }

    const toolResults = [];
    for (const block of resp.content) {
      if (block.type === "tool_use") {
        const result = await runTool(block.name, block.input);
        toolResults.push({ type: "tool_result", tool_use_id: block.id, content: result });
      }
    }
    messages.push({ role: "user", content: toolResults });
  }
}

Anthropic 没有把"Agent"做成一个独立的抽象。它就是 messages API + tools 在一个循环里。SDK 的"Agent" 部分主要提供的是Session(会话持久化)、Computer Use(桌面操作工具)、Skills(预定义工具集)。

优势:

接近原始 API——你写的代码几乎就是直接调 API,没有黑盒抽象。换框架时迁移成本极低。

和 Anthropic 模型深度集成——extended thinking、prompt caching、Computer Use 这些 Claude 独有的能力第一时间支持。

TypeScript 友好——类型完整、IDE 体验好。前端/全栈团队特别顺手。

弱点:功能薄——多 Agent、复杂状态机、跨 vendor 兼容这些要自己写或加层;生态小——比 LangChain 起步晚,集成数量有限。

适合:只用 Claude、想要轻量代码、TypeScript 全栈、Computer Use 场景。

三、CrewAI:多 Agent 第一类公民

CrewAI 是把"团队"当核心抽象的框架。

世界观:Agent 是有角色的"员工",任务是分配给他们的"工作",Crew 是组织"团队"。

from crewai import Agent, Task, Crew

researcher = Agent(
    role="资深市场研究员",
    goal="找到关于 X 行业的最新趋势",
    backstory="你是一个有 10 年经验的市场分析师...",
    tools=[search_tool, browse_tool],
)

writer = Agent(
    role="商业作家",
    goal="把研究结果写成清晰的报告",
    backstory="...",
)

research_task = Task(
    description="研究 2026 AI Agent 市场",
    agent=researcher,
)

write_task = Task(
    description="基于研究结果写一份 2000 字报告",
    agent=writer,
    context=[research_task],
)

crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task])
result = crew.kickoff()

CrewAI 的拥抱多 Agent:roles + goals + backstory 把每个 Agent 人格化、专业化。任务有显式依赖,自动按 DAG 执行。

优势:

直觉化——产品经理、非技术人员看代码也能理解大致逻辑("找一个 researcher 做研究,再让 writer 写报告")。 多 Agent 模式开箱即用——sequential、hierarchical 模式直接选。

弱点:多 Agent 的所有陷阱都还在(第 12 篇讲过的上下文碎片化、错误放大);抽象层次高导致细节失控时难调;生产就绪程度比 LangGraph 弱一档。

适合:MVP 验证多 Agent 想法、运营/创意类工作流、团队需要非技术人员理解 Agent 结构。但要警惕第 12 篇的提醒——多 Agent 在生产里经常翻车。

四、Pydantic AI:类型优先

Pydantic AI 是 Pydantic 团队 2024 年底推出的 Agent 框架,定位是"类型安全的 LLM 应用框架"。

世界观:所有 LLM 输入输出都应该是 Pydantic 模型,不应该有任何字符串原始数据。

from pydantic_ai import Agent
from pydantic import BaseModel

class CityInfo(BaseModel):
    name: str
    population: int
    timezone: str

agent = Agent(
    "openai:gpt-4o",
    result_type=CityInfo,
    system_prompt="你是一个城市信息助手。",
)

@agent.tool
async def get_population(ctx, city: str) -> int:
    """获取城市人口"""
    return await db.query_population(city)

result = agent.run_sync("北京的信息")
print(result.data)  # CityInfo 实例,有完整类型

整个框架围绕 Pydantic 类型展开。tools 用装饰器定义,参数类型自动转 schema;结果用 result_type 强约束;错误处理用 typed exception。

优势:

类型安全——所有输入输出都是结构化的,IDE 补全和重构友好。Python 后端开发者会觉得非常顺手。 轻量——核心代码量小,没有 LangChain 那种厚抽象。 Vendor 中立——支持 OpenAI、Anthropic、Gemini、Ollama 等,统一接口。

弱点:多 Agent 和复杂 workflow 不是强项(更适合 single-Agent 场景);生态相对新——比 LangChain / LangGraph 集成数少。

适合:Python 后端 Agent、需要严格类型保证、单 Agent 工具调用场景。

一张对比表

每个框架都有真实的适用场景,没有一个是"最优"。选框架本质是选世界观——你怎么看待 Agent,就用哪个。

到底要不要用框架

这是 Agent 工程社区从 2023 年争到现在的问题。两派观点:

用框架派:框架封装了大量边角细节(消息格式、错误处理、persistence、trace),你专注业务逻辑;社区积累的最佳实践(memory、Plan-Execute、HITL)开箱即用;团队协作时框架是共同语言。

手写派:框架的抽象不一定贴你的场景,经常需要"在框架上打补丁";LLM API 在快速演化,框架的封装可能滞后或限制你用最新能力;手写代码量没那么大(参考前面所有篇),但调试和维护透明得多;不被某家框架绑死。

我的实务判断:

初学和原型阶段——手写。对应本系列前 11 篇的代码风格。这能让你真正理解 Agent,出问题知道怎么改。

中等复杂度的生产 Agent(单 Agent + 5~10 工具)——手写或极简框架(Pydantic AI / Claude Agent SDK)。框架的价值还覆盖不了它带来的复杂度。

复杂多 Agent + workflow + 多人协作——LangGraph。这种规模下"显式状态机 + 持久化 + 可视化"能省很多事,框架的抽象成本是值得付的。

如果团队完全是 Anthropic 栈 + TypeScript——Claude Agent SDK。无脑选,生态匹配最好。

如果是产品验证、给非技术人员看的 demo——CrewAI。但记住生产化前要重新审视架构。

一条更朴素的建议

不论选哪个框架,把第 1 篇的 60 行最小 Agent 印在脑子里。所有框架本质上都在做这件事:messages 循环 + tools + 状态。框架增加的所有抽象,都是为了管理这件事的复杂度。

当框架把你的代码包到看不懂时,回到这 60 行——你的 Agent 在循环里到底做了什么、messages 长什么样、tool_call 怎么传的。理清楚了再回去看框架,你会发现它的抽象是合理的还是过度的。

整个系列收尾

写到这里,18 篇的"Agent 模式手册"完整了。回看整个内容地图:

基础(01-02)——Agent 的定义、ReAct 循环 核心模式(03-06)——工具设计、Plan-Execute、Reflection、Tree of Thoughts 记忆与上下文(07-08)——Agent 工程最难的两个话题 开源生态(09-11)——协议分裂、Hermes 实战、全本地 RAG-Agent 复杂形态(12-14)——多 Agent、Code Execution、Browser Use 工程化(15-17)——HITL、可观测性、生产化 收尾(18)——框架选型

整个系列想留下一个核心观点:Agent 是工程问题,不是 AI 问题。LLM 给了你"会推理的零件",剩下所有让它真正能用的工作——工具设计、上下文管理、记忆系统、可观测性、生产稳定性——都是软件工程师该做的事。

理解了这个,你就不会被某一篇论文、某一个新框架、某一种新模式带偏。Agent 这件事在未来 2~5 年会快速演化,但底层的工程原则——清晰的状态、可观测的执行、最小权限的安全边界、HITL 的护栏——这些不会变。

学完动手做。做一个会被人用的东西,比读 100 篇文章更让你成长。

相关阅读

• LangGraph Docs
• Claude Agent SDK GitHub
• CrewAI Docs
• Pydantic AI Docs
• Building Effective Agents (Anthropic) — 系列开头引用过,值得再读一遍