本文实测当下六个主流智能体框架从 pip install 到第一个可用 Agent 的真实成本。实测数据显示，框架之间的"能力差距"远小于"启动税差距"：同样跑一个"问一句、答一句"的最小智能体，CrewAI 默认拉入 31 个核心依赖（含 ChromaDB、Lancedb 两个向量库），Google ADK 自带一整套 FastAPI+Uvicorn+Starlette Web 服务器，而 OpenAI Agents SDK 仅 7 个依赖、Pydantic AI 用 slim 包把多模型支持做成可选 extras。把这些隐式负担量化出来，是判断"该不该上某个框架"的第一道闸门——因为冷启动税不会随项目长大而摊薄，它只会在每次重装、每次 Docker 构建、每次依赖冲突时被反复征收。
"冷启动税"不是单一指标，而是四类负担的叠加：
这四项税合并，才是一个框架的"真实入场费"。下表是 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（0.18.0，27.7k Star）走的是"薄到极致"的路线：核心依赖只有 openai、mcp、pydantic、requests、websockets、griffelib、typing-extensions 共 7 个，没有任何向量库、没有任何 Web 服务器。它的设计哲学被官方文档一句话点破——quickstart 里"最短的第一个例子"用的就是 Handoffs（智能体交接）。
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（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 来控制体积。
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（1.2.8，36.9k Star）的核心依赖数表面只有 6 个，但它会传递拉入 langchain-core，而 langchain-core 本身又带 pydantic、tenacity、jsonschema、langsmith 等一整套生态。真正的样板税体现在它的图编程模型上——原生 API 要求你定义 State、写 Node 函数、连 Edge、再 compile。
# 原生 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（59.6k Star，Star 数六栈最高）的口碑长期被"臃肿"拖累。但 0.7.5 版本的 autogen-agentchat 核心依赖只剩 1 个（meta 指向 autogen-core），印证了 v0.4 重构后"模块化拆分"的方向——agentchat、core、ext 分包，需要什么装什么。Victor Dibia 在横评里专门提到："你可以在 AutoGen 里用约 50 行代码复刻 OpenAI 的 Operator 智能体"，说明它的表达力并不弱。
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（2.4.0，20.5k Star）是最"反直觉"的一个。一个"智能体开发框架"的核心依赖里，竟然躺着 fastapi、uvicorn、starlette、python-multipart——这是一整套 ASGI Web 服务器。原因在于 ADK 的设计假设是"智能体即服务"：它内置了 dev server、session 管理、Web UI，你装完就能 adk run / adk web 直接起服务。
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（1.15.2，55.2k Star）用 6 行代码就能定义一个"船员+任务+出航"，样板税几乎是最低的：
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 效果最唬人。
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 依赖的重栈迁出便宜。
本文由「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 等场景全覆盖。