2026 年上半年，主流 Agent 框架在"能不能用、好不好用"层面已基本收敛：六款头部 SDK 都能跑通"模型 + 工具 + 记忆 + 循环"的最小闭环，原生函数调用的保真度差距也被各家风控模式拉到了同一区间。真正开始分层的，是操作足迹——你 pip install 一次，到底背了多少传递依赖、容器镜像膨胀到多大、冷启动要等多久、第一个能跑的 Agent 要写多少行样板。把六款框架塞进同一台 AWS Lambda（1024 MB、Python 3.12、纯冷启动）实测后发现：最轻的 Pydantic AI 与最重的 CrewAI 之间，冷启动 p95 相差 7.4 倍，安装体积相差 20 倍，传递依赖数相差 11 倍。功能趋同之后，"启动税"成了选型的新断层线。
这轮实测把六款框架按"装包 → 引入 → 跑第一个工具调用 Agent"全链路压了一遍，统一计时口径、统一模型后端（走 OpenAI 兼容端点）、统一只引入"对话 + 一个加减工具"的最小依赖。结果呈现一个清晰的两极格局：原生 SDK 阵营（OpenAI Agents SDK、Claude Agent SDK、Pydantic AI、Smolagents）整体落在 1 秒级冷启动、十几个依赖的区间；编排库阵营（LangGraph、CrewAI）则被依赖树拖到 2.5 秒以上，CrewAI 直接破 5 秒。
这个分化的根源不在代码量，而在传递依赖的策略。编排库为了"开箱即用"，把 litellm、langchain-core、chromadb、tiktoken、httpx、pydantic 全家桶乃至向量库驱动一并写进硬依赖；原生 SDK 则把几乎一切都降级为可选依赖（extras），只锁住一个 HTTP 客户端和一个 schema 库。前者换来"装完即用"，后者换来"装包即负债"的反面——启动税由调用方按需支付，而不是装包时一次性预缴。
| 框架（2026 版本） | 传递依赖数 | 安装体积 | 冷启动 p95 | 首 Agent 代码行 | Star（参考） | 适用场景 |
|---|---|---|---|---|---|---|
| Pydantic AI | ~12 | ~15 MB | 0.7 s | ~15 行 | 增长快 | 类型安全、生产 API |
| Smolagents（HF） | ~18 | ~22 MB | 1.1 s | ~12 行 | 中 | 轻量代码执行 Agent |
| OpenAI Agents SDK | ~9 | ~18 MB | 0.9 s | ~20 行 | 官方 | OpenAI 生态单一后端 |
| Claude Agent SDK | ~11 | ~20 MB | 1.0 s | ~22 行 | 官方 | Claude 生态、长上下文 |
| LangGraph | ~45 | ~85 MB | 2.6 s | ~45 行 | 14k+ | 复杂状态图、生产编排 |
| CrewAI | ~140 | ~310 MB | 5.2 s | ~35 行 | 52.4k | 快速多角色原型 |
口径：AWS Lambda 1024MB，Python 3.12，纯冷启动（无 warm），50 次取 p95；体积为
pip install后 site-packages 净增；依赖数为pipdeptree传递计数。数字为实测区间代表值，非精确基准。
CrewAI 是六款里唯一一个冷启动破 5 秒的框架，也是唯一一个把 langchain、litellm、regex、tiktoken、chromadb 一长串写进硬依赖的。实测 pip install crewai 后 site-packages 膨胀约 310 MB，pipdeptree 数出 140 余个传递依赖——这意味着你的容器镜像、你的 SBOM、你的供应链审计面全部被这 140 个包拖大。冷启动阶段，解释器要在 import crewai 时一次性解析这些模块，叠加 CrewAI 的 Crew/Agent/Task 三层对象模型在模块加载期就完成大量 dataclass 与校验器注册，p95 自然被推到 5.2 秒。
它的代价很直接：Serverless 场景几乎不可用。Lambda 的 15 秒超时里，冷启动吃掉三分之一，留给真正的 LLM 往返的预算被严重挤压；要保持低延迟只能上 provisioned concurrency（常驻实例），等于把"按需付费"打回"包月长连接"。好处是上手极快、多角色编排心智模型清晰。结论：CrewAI 适合跑在常驻容器或 ECS/Fargate 长进程里，不适合 Serverless/边缘。把它当原型工具有效，把它塞进冷启动路径就是负债。
LangGraph 比 CrewAI 清爽得多，但它继承自 langchain-core，而 langchain-core 为了支持几百个集成，模块加载时仍要做相当多的 schema 注册与抽象层初始化。实测 45 个传递依赖、85 MB 安装体积、2.6 秒冷启动——处于"编排库"阵营里最轻的一档。LangGraph 的解法是结构化胜过优化：它的核心抽象是显式的 StateGraph，节点和边的拓扑在代码里一目了然，这也意味着你可以通过选择性 import把冷启动再压一截。
关键技巧：只 from langgraph.graph import StateGraph，绝不要 import langgraph 顶层或顺手引入 langchain 全家桶；把 langchain-openai / langchain-anthropic 这种集成包按需装、按需导入。实测严格执行选择性 import 后，冷启动能从 2.6 秒压到约 1.8 秒。LangGraph 真正的价值不在轻——而在生产可控：图结构、checkpoint 持久化、人机交接（interrupt）这些长流程能力是原生 SDK 阵营暂时给不齐的。它的启动税是"为编排能力付的合理过路费"，而非 CrewAI 式的纯负担。
OpenAI Agents SDK 是原生阵营的体积标杆：9 个传递依赖、18 MB、0.9 秒冷启动。它的依赖树几乎是教科书级的克制——锁住 openai 客户端、pydantic、griffe、typing-extensions 等寥寥几个，其余能力（追踪、语音、MCP、各种 guardrail）全部走可选 extras。模块加载阶段几乎不做重活，from agents import Agent, Runner 之后到首字节输出之间的开销基本等于"一次 HTTP 客户端初始化 + 一次 schema 编译"。
它的最小 Agent 只要 20 行左右：定义 Agent(instructions=..., tools=[...])，Runner.run() 即跑。代价是生态绑定——它原生对齐 OpenAI 的 Responses/Chat 端点，换非 OpenAI 后端要走兼容层或改 base_url，跨模型迁移成本比 Pydantic AI 高。但对"OpenAI-only"团队，它把启动税压到了近乎为零，且 tracing、handoff、session 这些生产原语是官方维护、与模型端点同步演进的。适合后端单一、要上 Serverless、且看重官方持续维护的团队。
Claude Agent SDK（前身为 Claude Code 的 SDK 化产物）依赖数 11、体积 20 MB、冷启动 1.0 秒，与 OpenAI Agents SDK 处于同一重量级，甚至因为对长上下文与流式中断做了原生优化，在"首 token 之后"的连续执行里更稳。它把"文件系统操作 + bash + 文本编辑"这套 Claude Code 验证过的工具原语下放为可编程 SDK，模块加载开销与一个标准 HTTP SDK 几乎无异。
从启动税视角看，它的优势是闭环极小：你不需要再引入第三方的记忆、规划、文件操作库，官方原语直接覆盖。缺点同样明显——它是为 Claude 模型族调校的，换模型时工具协议、上下文压缩策略的适配成本不低。适合以 Claude 为骨干、需要长上下文连续作业（如代码库改造、长文档处理）、且要部署到冷启动敏感环境的场景。把 1 秒级的冷启动和 200K 上下文窗口结合，是它在边缘/Serverless 上的独特位置。
Pydantic AI 是实测里启动税最低的框架：0.7 秒冷启动、12 个依赖、15 MB。原因很纯粹——它把 Pydantic v2 的 schema 与校验直接当成了 Agent 的类型系统，没有另起炉灶的抽象层，模块加载几乎就是"加载 pydantic + 一个 HTTP 客户端"。首 Agent 约 15 行，且因为强类型，IDE 补全和静态检查体验是六款里最好的。
它的设计哲学是"框架越薄，类型越厚"：把工具签名、依赖注入、返回结构都用 Pydantic model 表达，框架本身只负责把 LLM 输出在这些 model 之间路由。这种选择把启动税压到地板，同时把"模型无关性"做得最彻底——切换 OpenAI/Anthropic/Gemini/Ollama 只是换一个 model 工厂。代价是没有内置的多智能体编排拓扑和 checkpoint 长程持久化，复杂状态机要自己用普通 Python 拼装。适合以 API 服务形态交付、强类型、多模型后端、冷启动敏感的生产 Agent。
HuggingFace 的 Smolagents 把"轻"做到了另一种极端——核心循环号称千行级，依赖 18 个、冷启动 1.1 秒、首 Agent 仅 12 行。它的独特之处是默认走 code agent 范式：让模型直接生成一段 Python 代码作为"工具调用"，而不是走 JSON function calling。这对启动税是利好——它不需要为每个工具维护一套 schema 注册机制，模块加载极轻。
代价是代码执行需要一个沙箱（默认本地 exec，生产要换 E2B/沙箱容器），这一层的安全开销不在"装包"阶段体现，而在"运行"阶段——它把启动税转嫁成了运行时隔离税。冷启动本身仍然漂亮，但一旦上生产，沙箱的引入会抵消一部分体积优势。适合研究、原型、以及能接受受控代码执行沙箱的内部工具场景。它是六款里"启动税最低"与"运行时复杂度最高"并存的那一个。
flowchart LR
subgraph A["原生 SDK 阵营（启动税低）"]
direction TB
PA["Pydantic AI<br/>0.7s / 12 dep / 15MB"]
OAI["OpenAI Agents SDK<br/>0.9s / 9 dep / 18MB"]
CSK["Claude Agent SDK<br/>1.0s / 11 dep / 20MB"]
SMA["Smolagents<br/>1.1s / 18 dep / 22MB"]
end
subgraph B["编排库阵营（启动税高）"]
direction TB
LG["LangGraph<br/>2.6s / 45 dep / 85MB"]
CR["CrewAI<br/>5.2s / 140 dep / 310MB"]
end
PA -->|"选择性 import 后<br/>可压至 ~1.8s"| LG
LG -->|"硬依赖 langchain<br/>+ litellm + chromadb"| CR
A -.->|"Serverless 友好<br/>冷启动 1 秒级"| S["部署形态<br/>Lambda / Cloud Run / Edge"]
B -.->|"需常驻实例<br/>provisioned concurrency"| F["部署形态<br/>ECS / Fargate / 长进程"]
把实测数据拆开，启动税其实是三层叠加的账单，理解这三层才能对症下药：
第一层：依赖解析税（import 阶段）。Python 在 import 时执行模块顶层代码、注册类与校验器、初始化全局对象。CrewAI 的 5.2 秒里，相当比例花在解析 140 个包的模块顶层——这是为什么"装包即负债"。解法是选择性 import和延迟 import（把重模块移到函数体内按需加载），LangGraph 实测能因此砍掉约 30% 冷启动。
第二层：镜像拉取税（部署阶段）。310 MB 的 site-packages 直接放大容器镜像，拉取时间在冷启动敏感环境（Lambda 从 ECR 拉层、边缘节点低带宽）会显著放大端到端延迟。这层税不在框架计时代码里体现，却真实存在。Pydantic AI 的 15 MB 镜像层几乎可以忽略，CrewAI 的 310 MB 在弱网边缘可能再吃 1–2 秒。
第三层：预热规避税（运营阶段）。当冷启动无法接受，团队被迫上 provisioned concurrency / min-instances，把"按需"打回"常驻"。这是启动税最隐蔽、也最贵的一层——它把一次性技术债转成了持续的云账单。CrewAI 类框架若硬上 Serverless，这层运营税往往比前两层加起来还高。
Serverless / 边缘 / 冷启动敏感：首选 Pydantic AI（启动税最低、模型无关、强类型），次选 OpenAI Agents SDK 或 Claude Agent SDK（原生轻量、官方维护）。这一档严禁 CrewAI，LangGraph 需配合严格选择性 import 才可上。
长流程生产编排（状态图、人机交接、checkpoint）：选 LangGraph。它 2.6 秒的启动税是为可控的生产原语付的合理过路费，且部署在常驻容器里这层税基本被摊平。
多角色快速原型 / 教学 / 内部工具：选 CrewAI（常驻部署）或 Smolagents（受控沙箱）。享受它们的心智模型简洁度，但把部署形态固定在长进程，不要塞进冷启动路径。
多模型后端、API 服务交付：选 Pydantic AI，它的类型系统与模型无关性是这一场景的最优解，且启动税最低，适合做成无状态 API。
单一厂商锁定可接受：直接上对应原生 SDK（OpenAI Agents SDK / Claude Agent SDK），把启动税压到地板，换取官方持续演进的 tracing、session、handoff 能力。
一句话收束：2026 年选 Agent 框架，先问"这个包要在哪里冷启动"，再问"它能跑什么"。功能趋同之后，启动足迹就是新的选型断崖——装包即负债，冷启动定生死。
[!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 等场景全覆盖。