AI Agent工程化实录 · 第十一章
GitHub上搜"AI Agent framework"，出来几百个仓库。每个README都写着"简单、强大、生产就绪"。但README是营销材料，不是技术文档。
选框架不是选"哪个最火"，而是选"哪个最适合你的场景"。本章从架构师视角，拆解主流框架的真实设计取舍。
01 框架的本质：抽象层
所有Agent框架做的是同一件事：把LLM调用+工具调用+状态管理的复杂性封装起来。区别在于抽象的层次和方式。
抽象越高级，上手越快，但灵活性越低。抽象越低级，控制力越强，但开发成本越高。
02 框架格局：6大主流框架的真实对比
框架格局有了显著变化：OpenAI Agents SDK入场、LangChain拆分出LangGraph独立定位、CrewAI推出Enterprise版、MCP和A2A协议重塑了工具层和Agent间通信。同时，"自研"不再是从零开始——有了MCP、A2A、LiteLLM等基础设施组件，自研的成本大幅下降。
| 维度 | OpenAI Agents SDK | LangGraph | CrewAI | AutoGen | Google ADK | 自研+MCP |
|---|---|---|---|---|---|---|
| 抽象层级 | 低（Handoff为主） | 中高（图节点+边） | 中（角色+任务） | 中（对话式） | 中（A2A原生） | 无 |
| 编排方式 | LLM自主Handoff | 开发者定义图 | 开发者定义流程 | LLM自主对话 | A2A Task协商 | 全自定义 |
| MCP支持 | ✅ 原生 | ⚠️ 需适配 | ⚠️ 需适配 | ❌ 无 | ✅ 原生 | ✅ 原生 |
| A2A支持 | ❌ 无 | ⚠️ 规划中 | ⚠️ 规划中 | ❌ 无 | ✅ 原生 | ✅ 可实现 |
| 推理模型 | ✅ o4/o4原生 | ✅ 通用 | ✅ 通用 | ✅ 通用 | ✅ Gemini原生 | ✅ LiteLLM代理 |
| 可观测性 | ✅ 内置Tracing | ✅ LangSmith | ⚠️ 基础 | ⚠️ 基础 | ✅ 内置 | ⚠️ 自己搭 |
| 成本透明 | ✅ reasoning token可见 | ✅ LangSmith | ❌ 隐式 | ❌ 隐式 | ✅ 可追踪 | ✅ 完全可控 |
| 学习曲线 | 低 | 高 | 低 | 中 | 中 | 高 |
| 生产就绪 | ✅ 是 | ✅ 是 | ⚠️ Enterprise版是 | ❌ 不够 | ⚠️ 新发布 | ✅ 自己保证 |
| 适合场景 | OpenAI用户、快速上线 | 复杂流程、生产级 | 多Agent原型 | 研究/教学 | Google生态 | 精细控制、成本敏感 |
⚠️ 选型的关键变化：框架的"功能"不再是主要区分维度——MCP统一了工具层，A2A正在统一Agent间通信。选框架更多看编排方式（Handoff vs 图 vs 对话）和生态绑定（OpenAI vs Google vs 独立）。
OpenAI Agents SDK
定位：OpenAI官方Agent框架，轻量级、生产就绪。
真实优势：官方支持、与OpenAI模型深度集成、内置handoff机制、支持MCP协议。代码简洁，没有过度抽象。
真实问题：只支持OpenAI模型（虽然可以扩展）。生态还在建设中，第三方集成不如LangChain丰富。
适合：使用OpenAI模型的生产环境、需要快速上线、团队规模不大。
不适合：需要多模型切换、需要大量第三方工具集成。
LangChain / LangGraph
定位：全家桶。从LLM调用到RAG到Agent到多Agent，一站式解决。
真实优势：生态最大、集成最多、LangGraph的状态机设计确实优雅。
真实问题：抽象层太多。你想调一个API，得穿过3层封装。报错信息是框架内部的堆栈，不是你代码的问题。升级经常breaking change。
适合：快速原型、需要大量第三方集成、团队里没有资深工程师。
不适合：需要精细控制、对性能敏感、讨厌"魔法代码"。
CrewAI
定位：多Agent协作框架。定义"船员"和"任务"，框架负责调度。
真实优势：多Agent场景上手最快。角色定义直觉，5分钟跑起来。
真实问题：黑盒太多。Agent之间怎么通信？任务怎么分配？你控制不了。出了问题，debug非常痛苦。而且多Agent的token消耗是隐式的——你以为跑了3步，实际消耗了30K token。
适合：多Agent概念验证、不需要精细控制。
不适合：生产环境、成本敏感、需要可观测性。
AutoGen (Microsoft)
定位：多Agent对话框架。Agent之间通过"对话"协作。
真实优势：对话式协作最自然。人可以随时加入对话。微软背书，学术圈认可。
真实问题：对话式协作的效率低——Agent之间用自然语言通信，信息密度低、解析成本高。而且对话轮数不可控，可能无限聊下去。
适合：研究场景、需要人参与的多Agent协作。
不适合：高吞吐生产环境、成本敏感。
自研 / 轻量封装
定位：不用框架，自己写。或者只用最轻量的封装（如OpenAI SDK + 几个工具函数）。
真实优势：完全控制、没有黑盒、debug直接看代码、性能最优。
真实问题：开发成本高。状态管理、重试逻辑、工具注册——这些框架帮你做的事，你得自己写。
适合：有经验的团队、需要精细控制、对成本/性能敏感。
不适合：快速验证、团队经验不足。
两个不可忽视的协议标准：MCP与A2A
框架选型之外，有两个协议标准正在重塑Agent生态，架构师必须了解：
MCP（Model Context Protocol）：Anthropic推出的开放协议，解决"Agent如何连接工具和数据"的标准化问题。之前每个框架都有自己的工具注册方式——LangChain用Tool类，CrewAI用装饰器，OpenAI用function calling格式。MCP统一了这一切：任何MCP兼容的工具，可以被任何MCP兼容的Agent使用。MCP的核心价值不是技术，是生态——工具开发者只需实现一次MCP接口，就能接入所有框架。OpenAI、Google等主要厂商都已宣布支持MCP，它正在成为Agent工具层的"HTTP协议"。
A2A（Agent-to-Agent）：Google推出的Agent间通信协议，解决"Agent之间如何发现彼此、协商任务、交换结果"的问题。如果说MCP是Agent与工具的协议，A2A就是Agent与Agent的协议。A2A定义了Agent Card（能力描述）、Task（任务协商）、Message（消息传递）等核心概念。A2A的意义：让不同框架、不同厂商的Agent能够互操作——一个LangGraph的Agent可以调用一个CrewAI的Agent，只要双方都支持A2A。
⚠️ 协议选型建议：如果你的Agent需要连接外部工具，MCP是首选标准；如果你的系统涉及多Agent跨框架协作，关注A2A的成熟度。但两者都还在快速演进中，架构设计要预留协议切换的空间。
03 选框架的5个维度
1. 控制粒度：你能控制Agent的每一步吗？还是框架替你决定？
2. 可观测性：框架内置了trace/log吗？还是你得自己加？
3. 成本透明：你能看到每步的token消耗吗？还是只有总数？
4. 调试体验：出了问题，你能快速定位吗？报错信息有用吗？
5. 生态锁定：换框架的成本有多高？你的代码能脱离框架独立运行吗？
04 框架选型决策树
简单粗暴的决策指南：
· 快速验证想法 → CrewAI或LangChain，5分钟跑起来 · 单Agent生产服务 → LangGraph或自研，需要状态管理和可观测性 · 多Agent生产服务 → LangGraph或自研，CrewAI/AutoGen的可控性不够 · 研究/教学 → AutoGen，对话式协作最直观 · 成本敏感/性能敏感 → 自研，框架的抽象层有性能开销
⚠️ ⚠️ 最大的陷阱：先用框架快速验证，然后"将就"着上生产。框架的快速原型能力≠生产就绪。验证通过后，认真评估是否需要重写核心逻辑。
05 我的建议：渐进式架构
不要一开始就选框架。按阶段来：
阶段1（0-2周）：用任何框架快速验证。证明Agent能完成任务。
阶段2（2-6周）：评估框架是否满足生产需求。如果不满足，开始替换关键模块。
阶段3（6周+）：核心逻辑自研，框架只用于非核心部分（如工具注册、LLM调用封装）。
渐进式架构的核心原则
框架是脚手架，不是地基。 脚手架可以拆，地基不能换。 核心逻辑（状态机、决策逻辑、工具编排）应该是你自己的代码。 非核心部分（LLM调用、日志、重试）可以用框架。
06 选型决策树
你要做Agent吗？
├─ 不，我要做Chatbot → 不需要框架，直接API调用
├─ 不，我要做Workflow → 用n8n/Tempora，不是Agent框架
└─ 是的
├─ 你的Agent需要几个角色？
│ ├─ 1个 → 单Agent + 好工具就够了
│ │ ├─ 用OpenAI？→ Agents SDK（最简单，MCP原生）
│ │ ├─ 用Google？→ ADK（A2A原生）
│ │ └─ 不绑定？→ 自研+MCP（精细控制）
│ └─ 多个
│ ├─ 流程确定？
│ │ ├─ 是 → LangGraph（图定义，最可控）
│ │ └─ 否 → Agents SDK（Handoff，LLM自主）
│ └─ 跨框架/跨组织？
│ ├─ 是 → A2A协议 + 任意框架
│ └─ 否 → 单框架内协作
├─ 成本敏感？
│ ├─ 是 → 自研+LiteLLM（多模型路由，reasoning模型按需）
│ └─ 否 → 全用推理模型（最简单）
└─ 需要推理模型？
├─ GPT-5.5 Thinking → Agents SDK/LangGraph
├─ DeepSeek R3 → 自研+LiteLLM（性价比最优）
└─ Gemini → ADK
下一篇：第12章——下一个架构挑战，Agent的未竟之业
