<!-- title: 启动即负重：六栈冷启动税实测 -->

# 启动即负重：六栈冷启动税实测

## 概述

本文实测当下六个主流智能体框架从 `pip install` 到第一个可用 Agent 的真实成本。实测数据显示，框架之间的"能力差距"远小于"启动税差距"：同样跑一个"问一句、答一句"的最小智能体，CrewAI 默认拉入 **31 个核心依赖**（含 ChromaDB、Lancedb 两个向量库），Google ADK 自带一整套 **FastAPI+Uvicorn+Starlette Web 服务器**，而 OpenAI Agents SDK 仅 **7 个依赖**、Pydantic AI 用 slim 包把多模型支持做成可选 extras。把这些隐式负担量化出来，是判断"该不该上某个框架"的第一道闸门——因为冷启动税不会随项目长大而摊薄，它只会在每次重装、每次 Docker 构建、每次依赖冲突时被反复征收。

## 冷启动税的四维拆解

"冷启动税"不是单一指标，而是四类负担的叠加：

- **依赖税**：核心依赖数量、传递依赖树深度、安装体积与耗时。
- **样板税**：从零到第一个能跑的 Agent 需要写多少行代码。
- **抽象税**：必须先学会的领域概念数量（State/Node/Edge、Agent/Task/Crew、Runner/Session 等）。
- **锁定税**：是否绑死某一家模型厂商的私有协议（如 OpenAI Responses API）。

这四项税合并，才是一个框架的"真实入场费"。下表是 2026 年 7 月 9 日实测的六栈数据。

## 六栈冷启动税对比表

| 框架 | 版本(07-09) | GitHub Stars | 核心依赖数 | 隐式重负担 | 首个Agent样板 | 模型耦合 |
|------|------------|-------------|-----------|-----------|--------------|---------|
| OpenAI Agents | 0.18.0 | 27,756 | **7** | 无 | ~8 行 | 强(OpenAI) |
| Pydantic AI | 2.7.0 | 18,288 | 8(slim) | 无,provider可选 | ~5 行 | 弱 |
| LangGraph | 1.2.8 | 36,891 | 6 | 拉入 langchain-core | ~40 行(原生) | 弱 |
| AutoGen | 0.7.5 | 59,604 | agentchat→core | 模块化拆分 | ~10 行 | 弱 |
| Google ADK | 2.4.0 | 20,535 | 24 | **内建Web服务器** | ~15 行 | 强(Gemini) |
| CrewAI | 1.15.2 | 55,224 | 31 | **双向量库+OTel×3** | ~6 行 | 弱 |

> 注：Star 数为 GitHub API 实时拉取，依赖数为 PyPI `requires_dist` 中去除 `extra` 后的核心依赖计数；传递依赖（如 langchain-core 自带的 pydantic/tenacity/jsonschema 等）不计入但会真实落盘。

## 一、OpenAI Agents SDK：最薄的一层，代价是绑死 Responses API

OpenAI 的 Agents SDK（0.18.0，27.7k Star）走的是"薄到极致"的路线：核心依赖只有 `openai`、`mcp`、`pydantic`、`requests`、`websockets`、`griffelib`、`typing-extensions` 共 7 个，没有任何向量库、没有任何 Web 服务器。它的设计哲学被官方文档一句话点破——quickstart 里"最短的第一个例子"用的就是 Handoffs（智能体交接）。

```python
from agents import Agent, Runner

agent = Agent(name="助手", instructions="用中文简洁回答")
result = Runner.run_sync(agent, "什么是冷启动税")
print(result.final_output)
```

8 行以内就能跑通。优点显而易见：Docker 镜像小、装得快、依赖冲突概率低、心智负担最轻。但它的锁定税也最重——`agents` 包深度依赖 OpenAI 的 Responses API，换到 Anthropic 或开源模型需要走 LiteLLM 这类适配层，相当于把省下的依赖税转成了迁移税。**适合谁**：纯 OpenAI 技术栈、追求快速验证、做训练营 Demo 的团队。变现上它最适合做"30 分钟上手智能体"的入门课，因为门槛最低。

## 二、Pydantic AI：用类型系统当护城河，slim 把多模型做成可选

Pydantic AI（2.7.0，18.3k Star）是 2025 年崛起最快的一匹黑马。它的巧思在于**双层包结构**：`pydantic-ai` 是个 meta 包，默认带一堆 extras（anthropic/google/openai/mcp/evals/logfire/retries/web），而真正精简的运行时是 `pydantic-ai-slim`，核心依赖只有 8 个（httpx、opentelemetry-api、pydantic-graph 等）。这意味着你既可以 `pip install pydantic-ai` 一把梭，也可以只装 slim + 单个 provider 来控制体积。

```python
from pydantic_ai import Agent

agent = Agent("openai:gpt-4o-mini", system_prompt="用中文简洁回答")
result = agent.run_sync("什么是冷启动税")
print(result.output)
```

它是六栈里样板最短的（约 5 行），而且把"结构化输出"做成了头等公民——用 Pydantic 模型直接约束 Agent 的返回类型，这点对需要确定性输出的企业场景是杀手锏。缺点是生态比 LangChain 系薄，第三方工具集成少。**适合谁**：需要严格结构化输出、想保持模型无关、对类型安全有洁癖的工程师。变现潜力在于"确定性智能体"——能把"LLM 返回不可控"这个老痛点做成卖点。

## 三、LangGraph：能力天花板最高，但原生 API 是样板税之王

LangGraph（1.2.8，36.9k Star）的核心依赖数表面只有 6 个，但它会传递拉入 `langchain-core`，而 langchain-core 本身又带 pydantic、tenacity、jsonschema、langsmith 等一整套生态。真正的样板税体现在它的图编程模型上——原生 API 要求你定义 State、写 Node 函数、连 Edge、再 compile。

```python
# 原生 LangGraph：从零搭一个最简循环约需 40 行
from langgraph.graph import StateGraph, START, END
from typing_extensions import TypedDict

class State(TypedDict):
    messages: list

def chatbot(state: State): return {"messages": [("ai", "hi")]}
g = StateGraph(State)
g.add_node("chatbot", chatbot)
g.add_edge(START, "chatbot")
g.add_edge("chatbot", END)
app = g.compile()
print(app.invoke({"messages": [("user", "你好")]}))
```

好在官方提供了 `create_react_agent` 这类预置函数，能把样板压到 3 行——但代价是你又退回到了"黑盒"模式，失去了 LangGraph 最值钱的显式状态控制力。这种"要么写很多、要么放弃控制力"的两难，正是它的抽象税。**适合谁**：需要复杂工作流、人机协作循环、生产级可观测与断点恢复的团队。它的天花板是六栈里最高的，但学习曲线也最陡，不适合做入门训练营。

## 四、AutoGen：对话式编排鼻祖，v0.4 后终于把臃肿拆开了

AutoGen（59.6k Star，Star 数六栈最高）的口碑长期被"臃肿"拖累。但 0.7.5 版本的 `autogen-agentchat` 核心依赖只剩 1 个（meta 指向 autogen-core），印证了 v0.4 重构后"模块化拆分"的方向——agentchat、core、ext 分包，需要什么装什么。Victor Dibia 在横评里专门提到："你可以在 AutoGen 里用约 50 行代码复刻 OpenAI 的 Operator 智能体"，说明它的表达力并不弱。

```python
import asyncio
from autogen_agentchat.agents import AssistantAgent
from autogen_ext.models.openai import OpenAIChatCompletionClient

agent = AssistantAgent(
    "helper",
    model_client=OpenAIChatCompletionClient(model="gpt-4o-mini"),
)
asyncio.run(agent.run(task="什么是冷启动税"))
```

AutoGen 的强项是**多智能体对话**——把 Agent 当作会话参与者，天然适合辩论、代码评审、人在环路（human-in-the-loop）这类场景。短板是文档与生态在 0.2→0.4 迁移期一度混乱，且社区注意到其主线仓库自 4 月后活跃度下降（实测最后推送为 2026-04-15，而其他五栈均为 07-09 当天仍在推送）。**适合谁**：研究型、对话驱动、需要人在环路的项目。变现方向是"多智能体辩论/评审"场景的垂直产品。

## 五、Google ADK：唯一自带 Web 服务器的框架，隐式负担最反直觉

Google ADK（2.4.0，20.5k Star）是最"反直觉"的一个。一个"智能体开发框架"的核心依赖里，竟然躺着 `fastapi`、`uvicorn`、`starlette`、`python-multipart`——这是一整套 ASGI Web 服务器。原因在于 ADK 的设计假设是"智能体即服务"：它内置了 dev server、session 管理、Web UI，你装完就能 `adk run` / `adk web` 直接起服务。

```python
from google.adk.agents import LlmAgent

agent = LlmAgent(name="helper", model="gemini-2.0-flash",
                 instruction="用中文简洁回答")
# 要真正跑起来还需 SessionService + Runner + Content 组装
```

24 个核心依赖里，一大半是为"开箱即用的部署体验"服务的。它的锁定税也很高——原生模型即 Gemini，且与 Google Cloud 的 Vertex AI / Agent Engine 深度绑定。**适合谁**：已在 Google Cloud 生态、需要快速把智能体暴露成 HTTP 服务、不想自己写网关的团队。它最大价值是省掉了"Agent 上线还得自己搭 FastAPI"这步，但如果你只是想要一个库而非一个平台，这 24 个依赖就是纯负担。

## 六、CrewAI：样板最短的"角色编排"，代价是最重的依赖树

CrewAI（1.15.2，55.2k Star）用 6 行代码就能定义一个"船员+任务+出航"，样板税几乎是最低的：

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

agent = Agent(role="分析师", goal="总结主题", backstory="资深分析师",
              llm="gpt-4o-mini")
task = Task(description="总结冷启动税", expected_output="200字", agent=agent)
Crew(agents=[agent], tasks=[task]).kickoff()
```

但它的依赖税是六栈里最重的——**31 个核心依赖**，其中 `chromadb` 和 `lancedb` 是两个独立的向量数据库（仅用于可选的记忆功能），`opentelemetry-api/exporter-sdk/exporter-otlp` 一整套可观测栈，外加 `pdfplumber`、`tokenizers`、`pyjwt`、`json5`、`jsonref`、`json-repair`。换句话说，你只想跑一个"问一句答一句"的 Agent，却被强行装了两套向量库。它的优势是"角色+任务+团队"的心智模型极度贴合非技术用户，做业务流编排时几乎零学习成本。**适合谁**：业务人员主导、内容生产、研究助理类应用。变现上它最适合做"零代码/低代码智能体"训练营，因为 Demo 效果最唬人。

## 冷启动税决策流程

```mermaid
flowchart TD
    A[新智能体项目] --> B{模型是否锁定单一厂商?}
    B -- 是 OpenAI --> C[OpenAI Agents SDK<br/>7依赖,样板最短]
    B -- 是 Gemini/Google Cloud --> D[Google ADK<br/>自带Web服务器]
    B -- 否,需模型无关 --> E{核心诉求是什么?}
    E -- 严格结构化输出 --> F[Pydantic AI<br/>类型驱动,5行起步]
    E -- 多智能体对话/评审 --> G[AutoGen<br/>对话式编排]
    E -- 业务角色编排/非技术团队 --> H[CrewAI<br/>31依赖,Demo最快]
    E -- 复杂工作流/生产级控制 --> I[LangGraph<br/>天花板最高,样板最重]
    C --> J{是否在意镜像体积?}
    D --> J
    H --> J
    J -- 极度在意 --> K[退回 Pydantic AI<br/>或 OpenAI Agents]
    J -- 不在意 --> L[接受隐式依赖,按上表落地]
```

## 同题实测：三栈跑同一任务的样板差异

为消除"各框架文档示例不同"带来的偏差，实测用同一任务——"调用一个搜索工具、回答一句话"——在三栈间对比。结果显示一个反直觉结论：**框架宣称的"易用性"和真实样板长度经常错位**。CrewAI 宣传最容易上手，但它的样板短是因为把工具/记忆/流程全部封装成了默认值；一旦你想关掉默认拉入的向量库或换模型，代码量立刻反超。OpenAI Agents 宣传"轻量"，但轻量来自绑死 Responses API，去掉这层锁定，样板也得加长。LangGraph 的 `create_react_agent` 能把样板压到 3 行，却恰好抹掉了它最值钱的图控制力——这就是抽象税的本质：**省下来的每一行代码，都是在别处预支的复杂度。**

## 冷启动税随项目规模的演化

冷启动税真正的杀伤力在于它**不会摊薄，反而会放大**。项目早期，31 个依赖只是"装得慢一点"；到了中期，它变成每次 `pip install` 的版本冲突风险、每次 Docker 构建的缓存失效、每次 CI 的拉取超时；到了后期，它演变成安全审计面（依赖越多 CVE 越多）和供应链风险。madebyagents 的 Agent Cost Calculator 把"框架开销"明确列为成本变量之一，与工作流形状（线性/多智能体/循环）、重试次数并列——这说明业界已经把框架自身的运行时开销当成可量化的生产成本。

反过来，样板税和抽象税会随团队规模放大：一个框架如果有 5 个必须先学的核心概念，10 人团队就是 50 人次的认知成本。这也是为什么大厂倾向 LangGraph——它抽象税高但显式，能让团队对状态流转有共同语言；而 CrewAI 虽然入门快，但"黑盒魔法"在多人协作时反而成了理解负担。

## 推荐方案

**场景一：快速验证 / 训练营 Demo。** 选 OpenAI Agents SDK 或 Pydantic AI。7-8 个依赖、5-8 行样板、装完即跑，Docker 镜像可以压到 200MB 以内。训练营用这两个能把"30 分钟跑通第一个 Agent"的承诺兑现，且不背技术债。

**场景二：需要严格结构化输出（金融、医疗、法务）。** 选 Pydantic AI。它的类型驱动输出约束是六栈里最成熟的，能把"LLM 返回不可控"这个合规痛点直接解决，适合做成行业垂直产品。

**场景三：复杂工作流 / 生产级智能体。** 选 LangGraph。接受它的样板税和抽象税，换回显式状态控制、断点恢复、可观测性——这些在生产环境里价值远超多写的几行代码。

**场景四：业务人员主导 / 内容生产。** 选 CrewAI。角色+任务的心智模型最贴近业务语言，但要提前在 Dockerfile 里用 `--no-deps` 或拆分 requirements 来控制它那 31 个依赖的爆炸半径。

**场景五：已在 Google Cloud 生态。** 选 Google ADK。它的内建 Web 服务器和 dev 工具能省掉一整条网关开发线，但要接受 Gemini 锁定和 24 依赖的体积。

**场景六：多智能体对话 / 人在环路。** 选 AutoGen。但需关注其主线仓库活跃度，必要时锁定具体版本避免 0.2/0.4 API 断裂风险。

一个跨场景的通用法则：**先用依赖最薄的两栈（OpenAI Agents / Pydantic AI）验证想法，确认需要更重编排能力时再迁移到 LangGraph 或 CrewAI**——因为从轻量栈迁出，永远比从 31 依赖的重栈迁出便宜。

## 参考来源

1. [AutoGen vs CrewAI vs LangGraph vs PydanticAI vs Google ADK vs OpenAI Agents — Victor Dibia](https://newsletter.victordibia.com/p/autogen-vs-crewai-vs-langgraph-vs) — 六框架横评，含"AutoGen 50 行复刻 Operator 智能体"的样板对比论断
2. [OpenAI Agents SDK vs LangGraph vs Autogen vs CrewAI — Composio](https://composio.dev/content/openai-agents-sdk-vs-langgraph-vs-autogen-vs-crewai) — 四框架定位与 quickstart 对比，OpenAI Agents SDK 定位为"轻量、代码驱动"
3. [Agent Cost Calculator: LangGraph vs CrewAI vs Mastra — Made by Agents](https://www.madebyagents.com/agents/cost-calculator) — 把工作流形状、重试、框架开销建模为可量化成本的工具
4. [LangGraph vs CrewAI vs OpenAI Agents 2026 — TECHSY](https://techsy.io/en/blog/langgraph-vs-crewai-vs-openai-agents-sdk) — 同一 Agent 在三栈实跑的 Ship Test，"哲学押注"视角
5. [PyPI 包元数据](https://pypi.org/project/langgraph/) — langgraph / crewai / openai-agents / google-adk / pydantic-ai-slim 的版本与 requires_dist 实测来源

---

*本文由「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)