<!-- title: 心智模型即锁：框架选错亏一季 -->

# 心智模型即锁：框架选错亏一季

## 概述

截至 2026 年中，AI Agent 框架市场已从 2023 年末至 2024 年初的"百框大战"冷却为三条主线：以命令式交接为核心的 OpenAI Agents SDK、以显式状态机为核心的 LangGraph、以角色协作（Crew）为核心的 CrewAI，外加 TypeScript 阵营的"黑马"Vercel AI SDK 与 PydanticAI、Mastra 等新势力。本文的核心发现是：到 2026 年，框架之争不再是功能之争，而是**心智模型之争**——三种哲学分别回答"什么是 Agent"，而你的回答会沿着工具模型、记忆、可观测性、部署、迁移成本一路传染下去。一份 Q2 2026 的 30 维评测矩阵给出的最锋利结论是：选错抽象 = **一位工程师损失一个季度**的迁移税。这意味着选型的真正成本不在运行时，而在迁移时。

## 框架总览对比表

| 维度 | OpenAI Agents SDK | LangGraph | CrewAI | Vercel AI SDK（黑马） | PydanticAI |
|------|-------------------|-----------|--------|----------------------|------------|
| 心智模型 | 命令式交接链（imperative handoff） | 显式状态机/有向图（graph state machine） | 角色协作组（role-based crew） | 流式工具循环（streaming tool loop） | 类型安全 Agent（typed agent） |
| 核心原语 | Agent + Runner + Handoff | Node + Edge + Checkpointer | Agent + Task + Crew + Process | generateText/streamText + tool | Agent + output_type + deps |
| 内置持久化 | 无（需自建队列/存储） | 内置（内存/SQLite/Postgres/Redis） | 较弱，需手动拼装 | 需自建状态助手 | 无内置，依赖 MCP/外部 |
| 可观测性 | 第一方 Tracing，开箱即用 | 最强（LangSmith + 时间旅行） | 偏薄 | 原生流式 + 轻量 | Logfire/Pydantic 生态 |
| 跨厂商支持 | 存在但弱于框架优先派 | 强，多厂商广覆盖 | 中等 | 极强，provider-agnostic | 模型无关，多 provider |
| 学习曲线 | 最低（≤50 行可用 Agent） | 明显偏高 | 业务友好、技术略重 | TS 优先，最低心智 | 中等，FastAPI 风格 |
| 变现/训练营潜力 | 高（最快交付话术） | 高（企业长流程卖点） | 极高（业务方看得懂） | 中（嵌入型产品） | 中高（质量/合规卖点） |
| 最适合场景 | OpenAI 优先、单/多专家交接 | 长周期、人在回路、需持久化 | 内容/研究/分析型业务流 | TS 产品内嵌 Copilot | 强结构化输出与校验 |

## 深度分析

### 一、OpenAI Agents SDK：命令式交接，最快上车的"心智最小集"

OpenAI Agents SDK 是官方一等公民，构建在 Responses API 之上。核心原语极小：一个带指令与工具的 `Agent`、一个驱动循环的 `Runner`、一个把控制权在 Agent 间传递的 `Handoff`。运行时是一个明确的 Agent 循环：模型生成响应→SDK 执行工具调用→结果追加进消息列表→迭代直到产出最终输出或触发停止条件。这里没有图、没有显式状态机，**状态就是消息列表加上你挂载的东西**。

```python
from agents import Agent, Runner

researcher = Agent(name="研究员", instructions="负责检索与信息整理",
                   tools=[web_search, file_search])
writer = Agent(name="撰稿人", instructions="把研究结果写成报告",
               handoffs=[researcher])          # 命令式交接
result = Runner.run_sync(writer, "写一篇6G安全综述")
```

**优点**：从零到可用 Agent 路径最短（少于 50 行即可产出有用的工具型 Agent）；第一方 Tracing 无需额外集成；与 Responses API 的结构化输出、托管工具、推理控制对齐度最高；Handoff 原语在"多专家分工"场景下天然适配，无需图的开销。**缺点**：没有内置持久化层，长流程要自建队列与存储；条件分支与路由在"无图"模型下显得别扭；跨厂商支持存在但弱于框架优先派；人在回路审批需围绕 Runner 手动拼装。2026 年 4 月，OpenAI 发布了 SDK 的"下一代演进"，新增 harness、沙箱 provider，以及即将到来的 code mode 与 subagents——这是它正面挑战 LangGraph 与 CrewAI 的信号。

**变现/训练营评估**：极适合做"30 分钟跑通第一个 Agent"的入门训练营，话术是"官方原生、最快交付"。但天花板在于企业长流程，训练营需明确告知"分支/持久化要外挂"，避免学员过度承诺。

### 二、LangGraph：显式状态机，长周期与持久化的"默认赢家"

LangGraph 是 LangChain 旗下面向**有状态、多步 Agent 工作流**的图框架。核心隐喻是"有向图"：节点变换一个共享状态，边在节点间路由，Checkpointer 在节点执行之间持久化状态——这把"可恢复的工作流"从项目级变成默认级。在 2026 年初，LangChain 还以 LangGraph 为底座重注押了 **Deep Agents** 这一套自带原生规划的 harness。

```python
from langgraph.graph import StateGraph, START, END
from typing_extensions import TypedDict

class State(TypedDict):
    query: str; docs: list[str]; answer: str

def retrieve(s):  return {"docs": search(s["query"])}
def synthesize(s):return {"answer": llm(s["docs"])}

g = StateGraph(State)
g.add_node("retrieve", retrieve)
g.add_node("synthesize", synthesize)
g.add_edge(START, "retrieve")
g.add_edge("retrieve", "synthesize")
g.add_edge("synthesize", END)
app = g.compile(checkpointer=postgres)   # 状态机 + 开箱持久化
```

**优点**：状态与控制流显式——没有隐藏循环，每一次转移都可见；内置 checkpoint、resume 与基于 LangSmith 的"时间旅行"调试；人在回路审批是一等原语而非补丁；并行节点、子图、流式状态更新让复杂流程变得可控。**缺点**：学习曲线明显高于命令式框架；对"简单工具调用 Agent"显得笨重——为一个 loop 形状都要摆图架子；最佳可观测性绑定 LangSmith，部分组织无法采用；TypeScript 版本在特性上明显落后 Python。

**变现/训练营评估**：企业级长流程（工单、合规审批、数小时级任务）的护城河卖点最强，适合做"高客单价企业级 Agent"训练营与咨询。卖点关键词："可恢复、可回放、可审计"。

### 三、CrewAI：角色协作组，业务方"看得懂"的工作流

CrewAI 把多智能体系统抽象为 **crew（班组）**——一组角色扮演的 Agent 执行声明式任务。每个 Agent 带 role、goal、backstory 和工具集；Task 定义工作单元与期望输出；Crew 按 sequential 或 hierarchical 的 process 模式编排。对非工程背景的利益相关者而言，这套抽象异常友好。

```python
from crewai import Agent, Task, Crew

analyst = Agent(role="高级研究分析师", goal="产出结构化洞察",
                backstory="十年行业研究", tools=[search])
strategist = Agent(role="内容策略师", goal="把洞察写成方案",
                   backstory="资深商业写手")
tasks = [
  Task(description="调研X赛道现状", agent=analyst, expected_output="要点清单"),
  Task(description="产出进入策略", agent=strategist, expected_output="方案文档"),
]
Crew(agents=[analyst, strategist], tasks=tasks, process="sequential").kickoff()
```

**优点**：角色隐喻与业务流程高度同构，非工程师可评审与微调；声明式任务在研究/分析/内容类工作流中显著减少样板；社区活跃、工具适配广；较新的 **Flows** 层提供图式控制流，给"crew 不够用"的场景留了逃生舱（双模设计：简单场景保持简单，复杂场景有退路）。**缺点**：当 Agent 需要中途重新规划时，抽象会遮蔽控制流；Python 优先，TS 支持明显弱于竞品；持久化与人在回路需比 LangGraph 更多手动拼装；开箱可观测性比 LangSmith / OpenAI 平台更薄。

**变现/训练营评估**：变现潜力极高——因为业务方"看得懂"是采购与续费的临门一脚。最适合包装成"业务流程 Agent 化"训练营，把"研究/分析/内容"三条流水线做成可复用模板转售。

### 四、PydanticAI：类型安全的"校验优先"挑战者

PydanticAI 来自 Pydantic 团队，把 FastAPI 式的人体工学搬进 Agent：类型安全的 Python、FastAPI 风格的依赖注入、结构化输出（`output_type`）、原生 MCP 客户端/服务端、模型无关。截至 2026 年 2 月已到 1.88.0 版本，GitHub Star 超 16.5k。它的主张是"用类型契约取代脆弱的提示工程"。

```python
from pydantic_ai import Agent
from pydantic import BaseModel

class Report(BaseModel):
    title: str; risk: float; points: list[str]

agent = Agent("openai:gpt-4.1", output_type=Report, deps_type=DB)

@agent.tool
def lookup(ctx, keyword: str) -> str:
    return ctx.deps.query(keyword)   # 类型安全 + 依赖注入

r = await agent.run("分析A公司风险", deps=DB(...))
print(r.output.risk)   # 结构化输出，IDE 全程补全
```

**优点**：类型契约让 Agent 的输入/输出/工具签名全程可校验、可补全，显著降低生产事故；依赖注入便于测试与换 provider；原生 MCP 让它能即插即用跨框架工具生态。**缺点**：没有内置持久化与长流程编排，属"轻框架"；可观测性依赖外部（Logfire 等）；面对图式复杂编排力不从心。

**变现/训练营评估**：适合"质量/合规优先"的高客单价场景（金融、医疗、法律的结构化抽取），训练营卖点："把 prompt bug 关进类型系统的笼子"。

### 五、Vercel AI SDK：TypeScript 阵营的"黑马"

Vercel AI SDK 并不自我标榜为 Agent 框架，它是 TypeScript 优先的流式/工具调用/结构化生成工具包。但 `generateText`/`streamText` 配合 `stopWhen`、`prepareStep` 与类型化工具，覆盖了相当大比例的真实 Agent 工作负载——而且没有专用框架的概念负担。

```ts
import { generateText, tool } from 'ai';
import { z } from 'zod';

const { text } = await generateText({
  model: openai('gpt-4.1'),
  tools: { search: tool({ description: '搜索',
    parameters: z.object({ q: z.string() }),
    execute: async ({q}) => (await fetch(`/?q=${q}`)).text() }) },
  maxSteps: 8,          // stopWhen / prepareStep 控制循环
  messages: [{ role: 'user', content: '...' }],
});
```

**优点**：对 TS 团队构建"产品内嵌 Agent"（聊天界面、Copilot、工具型助手）往往在人体工学与维护负担上胜出；provider-agnostic 让跨厂商路由轻而易举；流式原语是一等公民；工具模型产出类型化参数而无需装饰器元数据。**缺点**：它不是图框架——长周期工作流、持久化、时间旅行调试、深度多智能体协调都超出范围；若你需要其中任何一项作为第一性原理，应转向 LangGraph。

**变现/训练营评估**：适合"前端/全栈产品型 Agent"训练营，卖点："用最小表面积覆盖 80% 生产场景"。和 LangGraph 形成清晰的"按需升级"叙事。

### 六、Mastra 与 MCP：跨框架收敛的两个支点

当六大框架各自为政时，两个支点正在悄悄收敛生态。**MCP（Model Context Protocol）** 已成为事实上的"工具接口标准"——OpenAI、LangChain、PydanticAI、Mastra 等都在 2025–2026 陆续原生支持 MCP 客户端/服务端。这意味着"工具定义"开始从框架私域走向跨框架公地：一个 MCP server 可被任意框架消费，工具迁移成本因此被压平。**Mastra** 则是 TypeScript 全栈 Agent 框架的代表，主打"工作流 + 记忆 + 评估 + RAG"一体化，定位介于 Vercel AI SDK（更轻）与 LangGraph（更重）之间，给 TS 团队一个"想要更多但不想要图"的中间选项。

这两个支点共同改变了选型逻辑：过去是"框架锁定工具"，现在是"工具用 MCP 解耦、框架只管编排"。这也解释了为什么 2026 年的迁移税主要来自**编排层**（状态/记忆/可观测性/控制流），而非工具层。

### 七、可观测性：被评测忽视的"隐形决胜局"

30 维评测矩阵给出的最反常识结论是：**可观测性是被厂商基准忽视的隐形决胜局**。框架横评极少像生产环境那样给 Tracing、Eval、成本归因足够权重，但代理机构跑客户负载时，应把可观测性权重压到与"核心表达力"几乎持平。原因很现实：Agent 是"会自己改主意"的系统，没有细粒度 trace 就无法回答"它为什么这么干""这步花了多少 token""这次失败该归因哪个工具"。LangSmith（LangGraph）、OpenAI 平台 Tracing（Agents SDK）、Logfire（PydanticAI）构成了三条可观测性护城河，而 CrewAI、Vercel AI SDK 的开箱可观测性偏薄——这在生产支撑工作流里是真实风险。

## Agent 框架选型决策架构图

```mermaid
flowchart TD
    Q[要构建什么?]
    Q --> R1{长周期/持久化/审批?}
    R1 -- 是 --> LG[LangGraph<br/>显式状态机+检查点<br/>迁移税最低的'保险']
    R1 -- 否 --> R2{业务方要看懂流程?}
    R2 -- 是 --> CR[CrewAI<br/>角色协作+Flows<br/>可复用模板转售]
    R2 -- 否 --> R3{OpenAI 一等公民优先?}
    R3 -- 是 --> OA[OpenAI Agents SDK<br/>命令式交接+原生Tracing<br/>≤50行起跑]
    R3 -- 否 --> R4{强类型/合规校验?}
    R4 -- 是 --> PA[PydanticAI<br/>output_type+DI+MCP<br/>把bug关进类型]
    R4 -- 否 --> R5{TypeScript产品内嵌?}
    R5 -- 是 --> VS[Vercel AI SDK<br/>流式+stopWhen<br/>表面积最小]
    R5 -- 否 --> MA[Mastra<br/>工作流+记忆+评估一体化]

    OA -.升级.-> LG
    VS -.升级.-> LG
    CR -.补可观测性.-> LG

    MCP[(MCP 工具公地)] -.被消费.-> OA
    MCP -.被消费.-> LG
    MCP -.被消费.-> PA
    MCP -.被消费.-> MA

    style LG fill:#dbeafe
    style CR fill:#fef3c7
    style OA fill:#dcfce7
    style MCP fill:#f3e8ff
```

## 推荐方案（按场景）

**场景一：企业级长流程（工单、合规审批、数小时级任务）** → 选 LangGraph。可恢复、可回放、可审计是硬需求，时间旅行调试与人在回路一等原语无可替代。

**场景二：业务流程 Agent 化（研究/分析/内容流水线）** → 选 CrewAI。角色隐喻让业务方成为评审者而非旁观者，Flows 层兜底复杂控制流。

**场景三：OpenAI 优先、追求最快交付** → 选 OpenAI Agents SDK。心智最小集 + 第一方 Tracing，单/多专家交接开箱即用，但长流程要外挂持久化。

**场景四：质量/合规优先（金融、医疗、法律的结构化抽取）** → 选 PydanticAI。用类型契约与依赖注入把 prompt bug 关进笼子，原生 MCP 即插即用。

**场景五：TypeScript 产品内嵌 Copilot** → 默认 Vercel AI SDK，需要持久化/长流程再升级到 LangGraph；想要中间档选 Mastra。

**一条通用迁移建议**：把工具层全部走 MCP，让框架只承担编排。这样未来从"命令式"换到"图式"时，迁移税会从"一位工程师一个季度"压缩到"重写编排层"——这正是 2026 年选型最该前置的工程决策。

## 参考来源

1. [AI Agent Frameworks 2026 Deep Dive — LangChain, LangGraph, LlamaIndex, CrewAI, AutoGen, PydanticAI, Mastra, DSPy, MCP](https://www.youngju.dev/blog/culture/2026-05-16-ai-agent-frameworks-langchain-langgraph-llamaindex-crewai-autogen-pydanticai-mastra-dspy-mcp-2026-deep-dive.en) — 2026年5月市场全景深度综述，提出"三股主流收敛"与 LangChain 仍居份额首位
2. [OpenAI Agents SDK vs LangGraph vs CrewAI: 2026 Matrix — Digital Applied](https://www.digitalapplied.com/blog/openai-agents-sdk-vs-langgraph-vs-crewai-matrix-2026) — Q2 2026 的 30 维评测矩阵，"三种哲学""选错亏一季""可观测性隐形决胜局"的核心来源
3. [OpenAI Agents SDK vs LangGraph vs CrewAI: April 2026 — andrew.ooo](https://andrew.ooo/answers/openai-agents-sdk-vs-langgraph-vs-crewai-april-2026/) — 记录 OpenAI 2026年4月 SDK 演进（harness、沙箱、code mode、subagents）
4. [Pydantic AI: Type-Safe Python Framework for AI Agents & LLM Applications](https://pydantic.dev/pydantic-ai) — PydanticAI 官方站点，类型安全/依赖注入/原生 MCP 的官方说明
5. [AI Agent Framework Comparison 2026 — 8 Frameworks Side-by-Side](https://www.theproductionline.ai/tools/agent-framework-comparison) — 8 框架 6 维并排对比工具，跨厂商选型参考

---

*本文由「51学通信」出品，站长爱卫生（微信：gprshome201101）持续追踪 AI 智能体实战与通信技术前沿。*

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)