智能体框架：直接构建还是采用框架？
框架是一套现成的代码工具包，你在它之上搭建。LangGraph、OpenAI Agents SDK 这类智能体框架把循环、状态保存和智能体之间的交接都做好了——但它们也在你和模型之间加了一层。通行的建议是：先直接调用模型 API，等你的智能体超出直接调用的能力时再采用框架。
智能体的核心是一个小循环——几百行代码而已。框架卖的是围绕它的一切。它们也在你和模型真正看到的内容之间加了一层。
先说这个词本身。框架是一套现成的代码工具包， 你在它之上搭建，不必一切从零写起。那些成熟的框架给你什么？ LangGraph 是一个知名的智能体框架，它让你把多步骤流程画成一张 图（graph）、中途暂停等人介入、在会话之间保留状态，并在结果 产生时流式返回 [1]。 OpenAI Agents SDK 是 OpenAI 自家的框架，由三块积木组成—— 智能体、交接（handoff，一个智能体把工作交给另一个）和护栏 （guardrail，安全检查）——外加会话和追踪（tracing，智能体 行为的记录） [2]。 这些都是实打实的功能。自己把它们做好，要花实打实的时间。
代价就是这一层本身。这正是抽象的含义：框架把 细节藏起来，让事情变简单，而这种隐藏也可能碍你的事。Anthropic 的工程指南说得很直白：框架让起步容易，但可能藏起真正的提示词 和响应，让问题更难找到。所以先直接调用模型 API——许多模式只 需几行代码。如果你确实要采用框架，请务必弄清它在底层做了什么 [3]。
等你的智能体超出几百行代码，再采用框架——不要提前。
框架何时才值得采用
当你的需求正好对上框架自带的能力时，它才开始回本： 多个智能体协同工作并需要真正的路由 （指南 07）、跨会话 持续的记忆、长工作流中的人工批准停靠点， 或者一个团队想要一套共同的构建方式。挑选的检验很简单：选能 覆盖这些需求的最小工具包，并确认你仍能读到模型最终收到的 提示词。当智能体出错时， 调试就从那条提示词开始。
资料来源
- LangChain — LangGraph (langchain.com/langgraph)
- OpenAI — Agents SDK documentation (openai.github.io/openai-agents-python)
- Anthropic — Building effective agents, 19 Dec 2024（框架与抽象）
常见问题
我需要框架才能构建 AI 智能体吗？
不需要。核心循环——一个模型、若干工具、行动—观察—重复——只是针对模型 API 的几百行代码，Anthropic 的建议正是从这里开始。等到保存的状态、人工介入检查和多个智能体之间的协调超出手写代码的能力时，框架才值得引入。
智能体框架到底提供什么？
现成的“管道”：在智能体之间分派工作的机制、跨会话保存的状态、护栏（安全检查）挂钩、等待人工批准的暂停点、流式输出和追踪。LangGraph 和 OpenAI Agents SDK 就是两个例子——形态不同，但提供的是同一类管道。
我该选哪个智能体框架？
选能覆盖你真实需求、且支持你所用编程语言的最小框架，并确保你仍能读到模型最终收到的提示词。看不到模型看到了什么，你就修不好这个智能体——这比一长串功能列表更重要。