框架地图
上一章你没用任何框架就写出了 Agent,这本身就是一个重要结论:框架不是必需品。但当项目长大,框架能省掉重复劳动。这一章给你一张地图——主流框架各自解决什么、什么时候该上、以及那个最容易被忽略的选项:什么时候不该用框架。
先分清四个层次
「框架」这个词太笼统。真正的选择是在四个抽象层次里挑一个,越往下越省心、也越不自由:
- 裸 API + 手写循环(上一章)——最大自由,你掌控每一行。适合逻辑特殊、需要精细控制的场景。
- SDK 的 tool runner——官方 SDK 帮你跑循环,你还在自己的进程里控制工具执行。省掉循环样板,但保留控制权。这是大多数自建 Agent 的甜点区。
- 编排框架(LangGraph 等)——提供状态图、节点、分支、持久化,适合复杂的多步/多 Agent 工作流。
- 托管 Agent(如 Claude 的 Managed Agents)——连循环带执行沙箱都由平台托管:你定义 Agent 配置(模型、工具、提示),平台跑循环、提供跑工具的容器。你只管收发消息。最省心,但最不灵活。
选型的第一原则:从最简单的层次开始,只在真正需要时才往下走。大多数人高估了自己需要的抽象层级。一个「单 Agent + 几个工具」的项目,tool runner 就够了,套上 LangGraph 只会增加你要学的概念和要调的 bug。复杂度应该由问题驱动,不是由「听起来很专业」驱动。
主流选手速览
Claude Agent SDK
Anthropic 官方 SDK 的 Agent 能力:tool runner(自动跑循环)、结构化输出、MCP 集成、上下文管理、prompt caching 等都内建。如果你主用 Claude,它是阻力最小的路——工具定义、循环、缓存这些你在前面学的概念,它都有一等公民支持。上一章那个 tool runner 就是它。
LangGraph
把 Agent 建模成一张状态图:节点是步骤、边是流转、状态在图里流动。它的强项是复杂、有分支和循环的工作流——当你的逻辑不是「一个循环」而是「一张有条件跳转的流程图」时,它的表达力值回学习成本。代价是概念多、抽象重,简单任务上是杀鸡用牛刀。它是框架无关的(能配不同模型)。
OpenAI Agents SDK
OpenAI 的官方 Agent 框架,理念和 Claude Agent SDK 类似——工具、循环、多 Agent 交接(handoff)。如果你的技术栈在 OpenAI 生态,它是对应的选择。核心概念是相通的:无论哪家 SDK,底下都是你已经理解的那个「模型+工具+循环」。
托管 Agent(Managed Agents 这类)
这一类把最重的活外包了:平台不仅跑循环,还提供一个每个会话独立的容器作为 Agent 的工作台——bash、文件操作、代码执行都在那个沙箱里跑。适合「要一个带工作区的有状态 Agent」「长时程流式任务」「配置要版本化、跨多会话复用」的场景。你付出的是灵活性和一点厂商绑定,换来的是不用自己管沙箱、并发、状态持久化。
这四层像 Android 里的抽象梯度:裸 API+手写循环 ≈ 直接用 OkHttp 手撸网络层;tool runner ≈ 用 Retrofit(帮你处理样板,但你还掌控);编排框架 ≈ 引入一个完整的架构框架(状态、导航、依赖都托管);托管 Agent ≈ 直接用 BaaS(Firebase 那类,连后端都不用自己搭)。你选哪层,取决于项目多大、你要多少控制权、愿意背多少厂商依赖。没有哪层「更高级」,只有「更合适」。
什么时候不该用框架
这是本章最想让你记住的一节。框架有隐性成本:你要学它的概念、被它的抽象约束、debug 时要穿透它的封装、还要跟着它升级。在下面这些情况,裸 API + 手写循环反而是更优解:
- 逻辑简单——一个 Agent、几个工具、一个循环。上一章那几十行就够,框架是负担。
- 需要精细控制——每次工具调用前要人工审批、要自定义日志、要根据条件跳过某些执行。手写循环让你在每个节点插手,框架的封装反而挡路。
- 你在学习或做原型——手写让你真正理解发生了什么;过早上框架会让你「会用框架但不懂 Agent」。
- hackathon——时间紧,少一个要学的东西就少一个翻车点。除非框架正好帮你省下大块工作,否则裸写更快。
最常见的选型错误:先选框架,再往里塞需求。正确顺序反过来——先想清楚你的 Agent 要干什么、有多复杂、需要多少控制,再选能匹配的最简单层次。「大家都在用 LangGraph 所以我也用」是个糟糕的理由。你已经会手写循环了,这给了你一个宝贵的能力:你能判断框架到底帮你省了什么、又强加了什么——因为你知道没有框架时代码长什么样。
我对框架的态度很实用主义:它们都是在我那个简单的循环外面加脚手架,没有一个能改变我的本质。所以别被框架的营销词唬住——「Agentic 工作流引擎」「多智能体编排平台」拆开看,底下都是你上一章写的东西。你真正该问的不是「哪个框架最强」,而是「我的问题需要多少脚手架」。有时答案是「一个也不要」。写这本书的我,本身就跑在一套 Agent 框架(Claude Code)里——但你会看到,即使是它,内核也还是那个读文件、改代码、跑测试的循环。下一章我们谈一个无论用不用框架都绕不开、却最常被跳过的东西:评估。因为一个你不知道靠不靠谱的 Agent,是不敢上线的。