AI Agent框架：白板图解该不该用、何时用

AI Agent 正在从演示走向生产，但很多开发者面对 LangGraph、OpenAI Agents SDK、Claude Agent SDK 和 Google ADK 依然困惑：这些框架到底解决了什么问题？我是否真的需要引入一层抽象？近期一个用白板讲解 AI Agent 框架的视频，把这个问题拆解得相当清晰，值得结合其观点展开聊聊。

框架的本质：替你跑那个循环

视频给出的定义很直接：Agent 框架就是一个替你运行 Agent 循环的代码库。所谓循环，指的是调用模型、执行模型请求的工具、把结果喂回模型、重复直到任务完成。LangChain 的文档也把框架的价值描述为提供「抽象」——可复用的构建块，让起步更容易。

以 OpenAI Agents SDK 为例，创建一个带指令的 Agent，把它交给 Runner 并附上任务，Runner 随后就会跑起这个循环：调用模型，如果模型请求工具就执行工具、把结果加回去，再次循环，直到输出为最终答案。这个循环就是框架的核心。

Agent 循环（Agent Loop） 是理解一切 Agent 框架的起点。它的最小形态是一个 while 循环：把对话历史发给模型 → 检查模型返回的是普通文本还是工具调用请求 → 若是工具调用，则执行对应函数并把返回值以工具结果消息的形式追加进历史 → 再次调用模型。循环的终止条件是模型不再请求工具、直接给出最终回答（或达到最大轮数、token 预算等硬性上限）。裸写这个循环通常只需几十行代码，真正的复杂度来自边界情况：并行工具调用、工具执行失败的重试与错误回传、流式输出与工具调用的交错、上下文超长时的裁剪策略。框架的价值主要不在于写出循环本身，而在于把这些边界情况处理妥当，并让循环过程可被观测。理解这一点，就能判断某个框架是在替你解决真实痛点，还是仅仅增加了一层你不熟悉的间接调用。

盒子里还有什么

除了循环，框架通常还打包了这些能力：

• 工具：Claude Agent SDK 内置读取和编辑文件、运行命令、搜索网页等工具。
• 记忆与状态：LangGraph 提供短期工作记忆与跨会话的长期记忆。
• 交接（Handoffs）：一个 Agent 把任务委派给另一个 Agent。
• 护栏（Guardrails）：校验输入和输出。
• 追踪（Tracing）：可视化并调试一次运行。

这些能力单独实现都不算难，但组合起来就是框架真正的吸引力。视频中展示了两个框架的自我定位截图：

Handoffs（交接） 值得单独说明，因为它是多 Agent 系统中最容易被误解的机制。交接本质上不是“启动一个新进程”，而是在一次会话中把控制权连同对话上下文转交给另一个 Agent——通常实现为一种特殊的工具调用：当前 Agent 调用 transfer_to_xxx 工具，运行时据此切换后续轮次所使用的系统提示词与可用工具集。它与“子 Agent 调用”不同，后者是主 Agent 把子任务作为工具调用出去、拿到结果后继续自己掌控流程，上下文可以是隔离的。交接适合按领域切分职责（如分诊 Agent 转给退款 Agent），子调用适合需要并行或上下文隔离的重活。设计多 Agent 系统时，先想清楚用哪一种，往往比选哪个框架更影响最终架构。

四个框架，各自的说法

视频按字母顺序（非排名）列出了四个框架的自述：Claude Agent SDK 来自 Anthropic，定位是「把 Claude Code 当作库来构建生产级 AI Agent」；Google 将 ADK 描述为构建、调试和部署 AI Agent 的开源框架；LangGraph 自称是面向有状态 Agent 的低层编排框架和运行时；OpenAI Agents SDK 则强调轻量、易用、抽象极少。

从这些定位能看出一个光谱：OpenAI 的 SDK 抽象最少，LangGraph 强调低层编排但提供有状态运行时，Claude 和 Google 的方案更偏向开箱即用的生产化能力。

你需要框架吗？两种立场的交叉验证

这是整段讲解最有价值的部分。Anthropic 一篇被视频引用的文章（发布于 2024 年 12 月，文中也承认工具生态已经变化）建议：先从直接调用模型 API 开始。许多模式只需要几行代码，而框架的额外层次可能隐藏提示词和响应，让调试更困难。如果使用框架，要理解底层的代码。

OpenAI 的文档则把同一个选择摆出来：直接用 API，就是自己拥有循环的控制权；用 SDK，则是让它的运行时管理循环。两边说法不同，但指向一致——这是一个权衡，而不是对错题。

更关键的提醒是：你不需要在全局上二选一。可以在简单任务上直接调 API，在需要记忆、多 Agent 交接、追踪等复杂能力时引入框架；也可以在一个项目里混合使用。选择的标准应该是任务复杂度与你对底层行为的掌控需求，而非框架的流行度。

对于正在构建 Agent 的开发者，务实的路径是：先手写一次循环，理解工具调用和结果回填的机制，再评估框架替你省下的究竟是繁琐还是可观测性。

Anthropic 那篇被引用的文章通常指其工程博客的《Building effective agents》，核心主张是优先使用可组合的工作流模式而非通用框架：把任务拆成提示词链、路由、并行化、编排者-执行者、评估-优化等几种固定拓扑，每种用几十行直接调用 API 的代码即可实现，行为完全透明、易调试。文章同时区分了“工作流”（路径由代码预先确定）与“Agent”（由模型自主决定步骤与工具使用），并建议只在确实需要模型动态决策时才引入自主循环。这一区分的实践意义在于：很多被当作 Agent 来做的需求，其实用一条确定性的工作流就能更稳定、更便宜地完成，此时引入 Agent 框架反而是过度设计。