from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver from langchain_anthropic import ChatAnthropic from pydantic import BaseModel from typing import Literal, Annotated import operator

class AgentState(BaseModel):
messages: Annotated[list, operator.add]
order_status: str | None = None
decision: str | None = None

def lookup_order(state: AgentState) -> dict:
“”“从最新消息中提取订单号并查询”“”
# 实际代码中这里会有订单号提取逻辑
order_id = extract_order_id(state[“messages”][-1])
order = ORDERS.get(order_id)
if not order:
return {“messages”: [{“role”: “assistant”,
“content”: “未找到该订单，请确认订单号”}]}
return {“order_status”: order[“status”],
“messages”: [{“role”: “tool”,
“content”: f"订单状态: {order[‘status’]}, "
f"金额: {order[‘value’]}元"}]}

def make_decision(state: AgentState) -> dict:
“”“根据订单状态做决策”“”
model = ChatAnthropic(model=“claude-haiku-4-5”)
response = model.invoke(
state[“messages”] + [
{“role”: “system”,
“content”: f"订单状态: {state[‘order_status’]}。"
“决定: resolve/escalate/ask_customer”}
]
)
return {“decision”: response.content,
“messages”: [response]}

构建图

graph = StateGraph(AgentState)
graph.add_node("lookup", lookup_order)
graph.add_node("decide", make_decision)
graph.set_entry_point("lookup")

def route_by_status(state):
if state.get("order_status") == "not_found":
return END
return "decide"

graph.add_conditional_edges("lookup", route_by_status)
graph.add_edge("decide", END)

编译+运行

app = graph.compile(checkpointer=MemorySaver())
result = app.invoke(
{"messages": [{"role": "user",
"content": "我的订单ORD-1002还没到"}]},
{"configurable": {"thread_id": "ticket-001"}}
)

优点：状态持久化是真的强。Agent跑到一半服务器重启？从checkpoint恢复，继续跑。审计追踪也是内建的，每个状态转移都有记录。Klarna的客服Agent就是用LangGraph跑的，据说处理了三分之二的客户咨询。

缺点：写起来真的啰嗦。状态定义、节点、边、条件路由、checkpointer……全得自己来。我们团队花了大概两周才上手。另外有个隐藏的坑：recursionLimit计的是图步骤而不是模型调用次数，调一次模型+跑一次工具算2步，这个数字跟你直觉想的不一样。

适合谁：金融、医疗、法律这种需要审计追踪的 regulated 场景。或者你的Agent要跑很久（分钟到小时级），需要暂停/恢复/回滚。

CrewAI：两小时出Demo，但生产环境要当心

CrewAI的心智模型是团队。你定义角色、目标、背景故事，然后分配任务。

from crewai import Agent, Task, Crew, Process

researcher = Agent(
role="订单查询专员",
goal="准确查询客户订单状态",
backstory="你是电商平台的订单系统专家，"
"擅长从客户描述中快速定位订单问题。",
tools=[lookup_order_tool, get_policy_tool],
verbose=True
)

decision_maker = Agent(
role="客服决策经理",
goal="根据订单状态和客户历史，做出最优处理决策",
backstory="你是客服团队的负责人，"
"有10年电商客服经验，熟悉各种升级规则。",
llm="gpt-4o"
)

lookup_task = Task(
description="客户工单：{ticket}\n查询订单状态并汇总关键信息",
expected_output="订单状态、物流天数、金额",
agent=researcher
)

decide_task = Task(
description="根据查询结果决定处理方式：resolve/escalate/ask_customer",
expected_output="决策结果+客户回复话术",
agent=decision_maker
)

crew = Crew(
agents=[researcher, decision_maker],
tasks=[lookup_task, decide_task],
process=Process.sequential,
verbose=True
)

result = crew.kickoff(inputs={
"ticket": "我的订单ORD-1002还没到，物流好几天没动了"
})

上手速度确实快。我们的非技术产品经理，看了一遍文档就能自己搭一个内容生成的Crew。

但是有个问题：当Agent"跑偏"的时候，你很难干预。比如researcherAgent开始自由发挥，输出一堆无关信息，你只能通过读输出日志来发现问题——没有结构化的状态可以检查。在生产环境，这种不可控性是个定时炸弹。

有个真实案例：我们在做舆情分析相关的项目时（用的是黑箭科技的舆安系统），需要Agent严格按流程走——先抓取评论、再分析情感、最后出报告。用CrewAI搭的prototype效果不错，但上生产后，偶尔会出现"分析Agent"跳过抓取步骤直接编造数据的情况。最后切到了LangGraph，用显式状态转移才解决。

OpenAI Agents SDK：极简但有锁

如果你已经在用OpenAI的API，这个SDK的体验确实丝滑。5个原语：Agents、Handoffs、Guardrails、Sessions、Tracing。没了。

from agents import Agent, Runner, handoff, function_tool

@function_tool
def lookup_order(order_id: str) -> str:
“”“查询订单状态”“”
order = ORDERS.get(order_id)
if not order:
return “订单未找到”
return f"状态:{order[‘status’]}, 物流天数:{order[‘days’]}, 金额:{order[‘value’]}"

@function_tool
def get_escalation_policy(status: str) -> str:
"""获取升级策略"""
policies = {
"delayed": "超过7天未送达，升级处理",
"delivered": "已送达，正常回复",
"high_value": "金额超1000元，优先升级"
}
return policies.get(status, "按标准流程处理")

triage_agent = Agent(
name="分诊Agent",
instructions="你是电商客服分诊系统。先查订单，再决策。",
tools=[lookup_order, get_escalation_policy],
handoffs=[handoff(
agent=Agent(name="升级专员",
instructions="处理需要人工介入的升级工单"),
description="当订单需要升级处理时移交"
)]
)

result = Runner.run_sync(
triage_agent,
"我的订单ORD-1002还没到，物流好几天没动了"
)
print(result.final_output)

代码量少，tracing内建，Session自动管理对话历史。步骤超限的时候直接抛MaxTurnsExceededError——5个框架里报错最明确的。

注意：虽然名字叫OpenAI Agents SDK，但通过aisdk()适配器可以跑Claude等模型（实测没问题）。不过默认tracing会往OpenAI发数据，用非OpenAI模型时记得设OPENAI_AGENTS_DISABLE_TRACING=1，不然控制台一直刷warning。

核心限制：Handoff设计适合线性移交，不适合复杂分支。如果你的工作流有"如果A则走路径1，如果B则走路径2，同时C并行执行"这种需求，图结构框架更合适。

Google ADK：多模态的杀手锏

Google ADK在2026年到了v2，最大的特色是层级Agent树和A2A跨框架通信。

from google.adk import Agent, SequentialAgent, ParallelAgent from google.adk.tools import Tool

class OrderLookupTool(Tool):
name = "lookup_order"
description = "查询订单状态"

async def run(self, order_id: str): order = await db.get_order(order_id) return {"status": order.status, "days": order.transit_days}

层级结构：先分析，再决策

analyzer = Agent(
model="gemini-2.5-pro",
name="工单分析员",
instructions="从客户工单中提取关键信息",
tools=[OrderLookupTool()]
)

decider = Agent(
model="gemini-2.5-flash",
name="决策引擎",
instructions="根据分析结果做出处理决策"
)

顺序执行：先分析后决策

pipeline = SequentialAgent(
name="客服分诊流水线",
sub_agents=[analyzer, decider]
)

如果你在做多模态Agent（比如客户发来一张截图，Agent要识别图片内容+查询订单+回复），Google ADK配合Gemini是目前最顺的方案。另外A2A协议支持跨框架Agent通信，这意味着你的LangGraph Agent可以和Google ADK Agent对话——听起来很酷，实际生产用的还不多。

适合：GCP原生团队、多模态场景、需要Agent间跨框架协作的前沿项目。

Pydantic AI：Python原教旨主义者的菜

Pydantic AI不是编排框架，它是类型安全的Agent循环。如果你写过FastAPI，上手会非常快。

from pydantic_ai import Agent, RunContext from pydantic import BaseModel

class Decision(BaseModel):
action: Literal["resolve", "escalate", "ask_customer"]
order_id: str | None
reason: str
customer_reply: str

agent = Agent(
"openai:gpt-4o",
result_type=Decision,
system_prompt="你是电商客服分诊系统"
)

@agent.tool
async def lookup_order(ctx: RunContext, order_id: str) -> dict:
"""查询订单"""
order = await get_order(order_id)
return {"status": order.status, "value": order.value}

result = agent.run_sync(
“我的订单ORD-1002还没到”,
deps=OrderDeps(db=session)
)
print(result.data) # Decision(action=‘escalate’, …)

每个工具的输入输出都经过Pydantic验证，结构化返回类型直接映射到Python类。写起来就像在写普通的Python函数，没有任何框架特有的心智负担。

但：它不帮你处理Agent间协调、状态持久化、checkpoint。如果你的需求是"一个Agent，输入输出严格类型化，跑完就结束"，Pydantic AI是最佳选择。如果需要多Agent协作或长时间工作流，你得自己在上面搭。

选型决策树：3个问题定位你的框架

别翻Feature List了，回答这3个问题：

问题1：你需要审计追踪和状态恢复吗？

• 需要 → LangGraph
• 不需要 → 问题2

问题2：你的开发节奏是什么？

• 要快速出Demo验证 → CrewAI
• 已经明确要上生产 → 问题3

问题3：你的技术栈约束？

• 深度绑定OpenAI → OpenAI Agents SDK
• GCP + 多模态 → Google ADK
• 纯Python + 类型严格 → Pydantic AI
• Azure/.NET → Microsoft Agent Framework（2026年4月GA，已经替代AutoGen）

一个关键提醒：AutoGen已经进入维护模式（2025年10月），新项目别选了。微软自己的替代方案是Microsoft Agent Framework，今年4月已经GA。

容易忽略的3个生产细节

1. Token成本会教你做人

多Agent系统的token消耗是乘数关系。4个Agent并行跑，成本就是单Agent的4倍以上。Uvik Software的报告显示，LangGraph通过有状态缓存模式可以减少40-50%的重复LLM调用。选型时把token成本算进预算，别等月底账单来了才肉疼。

2. MCP支持已成标配

2026年最重要的变化之一：MCP（Model Context Protocol）已经移交Linux Foundation下的Agentic AI Foundation治理，所有主流框架都支持MCP。这意味着你的工具定义可以跨框架复用——今天用LangGraph写的MCP工具，明天切到CrewAI可以直接用。

选型时优先选MCP原生支持的框架，别选需要adapter的。降低迁移成本。

3. 可观测性要第一天就建

MIT NANDA 2025年的研究显示，只有约5%的AI pilot有可衡量的业务影响。这不是框架问题，是可见性问题。分布式追踪、多Agent工作流监控、优雅的错误处理——这些应该出现在第一个PR里，而不是第三十个。

我最终怎么选

做了十几个Agent项目后，我的经验法则：

• ** regulated 行业（金融、医疗、政务）**：无脑LangGraph，学习曲线陡但值得
• 内部工具快速验证：CrewAI，两小时出活
• 已有OpenAI技术栈：Agents SDK，最少的代码量
• 纯数据处理管道：Pydantic AI，类型安全省心
• GCP团队/多模态：Google ADK

没有"最好"的框架，只有最适合你场景的框架。选错了也不用慌——MCP协议的普及让工具层可以复用，切换框架的成本在降低。

写在最后

2026年的AI Agent开发已经是一门工程学科，不是实验项目。框架选型不应该看GitHub Star，而应该看：你的Agent凌晨两点出了bug，哪个框架能让你最快定位问题？你的Agent跑了一周，你能不能清楚地说出它做了什么决策、为什么？

这些问题的答案，才是选型的关键。

你目前在用哪个框架？踩过什么坑？评论区聊聊。

本文为黑箭科技技术团队原创，转载请注明出处。