简介
万字长文分析 10 种流行 Agent 框架设计思路，教你如何构建真正可靠的 Agent 系统？OpenAI 采用更高层次、更具思想领导力的方式来定义 Agent：Agent 是能独立代表你完成任务的技术系统。这种模糊表述无助于真正理解 Agent 本质，在 Anthropic，架构上区分工作流和Agent：工作流是通过预定义代码路径编排大模型和工具的系统；Agent则是大模型动态自主控制流程和工具使用的系统，自主决定任务完成方式。Anthropic 将 Agent 定义为”…本质上只是大模型在循环中基于环境反馈使用工具的系统“。实际生产环境中，几乎所有的Agent 系统都是工作流和Agent的混合体。这正是我反感讨论”某物是否是 Agent”，而更倾向于讨论”系统的 Agent 化程度“的原因。
理念之争：agent vs workflow
OpenAI“Agent万能论”遭打脸！LangChain创始人：Deep Search恰恰证明Workflows不可取代
- LangChain创始人与OpenAI就Agent框架设计理念产生争议，认为不应将Agents和Workflows严格二分，大多数Agentic系统是两者结合；他指出Agent框架核心难点是确保LLM在每步都能获得恰当上下文，而非仅提供封装，框架应支持从结构化工作流到模型驱动的灵活转换；
- 有些人将 Agent 视为完全自主的系统，能够长时间独立运行，灵活使用各种工具来完成复杂任务。 也有些人认为 Agent 是遵循预设规则、按照固定 Workflows 运作的系统。在 Anthropic，我们把所有这些变体都归类为 Agentic 系统，但在架构上，我们明确区分 Workflows 和 Agents：
- Workflows：依靠预先编写好的代码路径，协调 LLM 和工具完成任务；
- Agents：由 LLM 动态推理，自主决定任务流程与工具使用，拥有更大的决策自由度。
- 让 Agents 稳定可靠地工作，依然是个巨大的挑战。LLM 本身能力存在局限性，且在上下文信息传递方面常出现错误或不完整的情况，后者在实践中更为普遍。导致 Agent 效果不佳的常见原因包括：System Message 不完整或过于简短、用户输入模糊不清、未向 LLM 提供正确的工具、工具描述不清晰、缺乏恰当的上下文信息以及工具返回的响应格式不正确。构建可靠 Agents 的关键挑战在于确保大模型接收到正确的上下文信息，而 Workflows 的优势在于它们能够将正确的上下文传递给给 LLMs ，可以精确地决定数据如何流动。
- 许多 Agent 框架提供的 Agent 封装（如包含 prompt、model 和 tools 的类）虽然易于上手，但可能限制对 LLM 输入输出的控制，从而影响可靠性，像 Agents SDK（以及早期的 LangChain， CrewAI 等）这样的框架，既不是声明式的也不是命令式的，它们只是封装。它们提供一个 Agent 封装（一个 Python 类），这个类里面封装了很多用于运行 Agent 的内部逻辑。它们算不上真正的编排框架，仅仅是一种封装。 这些封装最终会让你非常非常难以理解或控制到底在每一步传递给 LLM 的具体内容是什么。这一点非常重要，拥有这种控制能力对于构建可靠的 Agents 至关重要。这就是 Agent 封装的危险之处。
- 在实际应用中，Agentic 系统往往并非由单一 Agent 组成，而是由多个 Agent 协作完成。在多 Agent 系统中，通信机制至关重要。因为构建可靠 Agent 的核心，依然是确保 LLM 能接收到正确、充分的上下文信息。为了实现高效通信，常见的方法包括「Handoffs」（交接）等模式，像 Agents SDK 就提供了这种风格的封装。但有时候，这些 Agents 之间最好的通讯方式是 Workflows。而 Agent 框架则通过提供统一封装、记忆管理、人机协作、流式处理、可观测性和容错机制，大幅降低构建可靠 Agentic 系统的复杂度，但前提是开发者需理解其底层机制。
- 大模型越来越厉害，那么是不是都会变成 Agents？虽然工具调用 Agents 的性能在提升，但“能够控制输入给 LLM 的内容依然会非常重要（垃圾进，垃圾出）”，简单的 Agent 循环并不能覆盖所有应用需求。
- OpenAI 的 Deep Research 项目是 Agent 的一个好例子，这同时也证明了针对特定任务训练的模型可以只用简单 Agent 循环。它的成功前提是：“你能针对你的特定任务训练一个 SOTA 模型”，而当前只有大型模型实验室能够做到这一点。对于大多数初创公司或企业用户来说，这并不现实。
总结来看，简单 Agents 在特定条件下有效，但仅限于数据和任务极为匹配的场景。对绝大多数应用而言，Workflows 仍然不可或缺，且生产环境中的 Agentic 系统将是 Workflows 和 Agents 的结合。生产级框架必须同时支持两者。
什么导致 Agent 有时表现不佳？大模型出错。为什么大模型会出错？两个原因：(a) 模型能力不足，(b) 传入模型的上下文错误或不完整。根据我们的经验，后者更常见。具体诱因包括：
- 不完整或过于简略的系统消息
- 模糊的用户输入
- 缺乏恰当的工具
- 工具描述质量差
- 未传入正确的上下文
- 工具响应格式不当
构建可靠 Agent 系统的核心难点在于确保大模型在每一步都能获得适当的上下文。这既包括严格控制输入大模型的内容，也包括运行必要的步骤来生成相关内容。在讨论 Agent 框架时，请牢记这一点。任何让控制大模型输入内容变得更困难的框架，都是在帮倒忙。
随着模型进步，所有系统都会变成 Agent 而非工作流吗？支持 Agent（相对工作流）的常见论点是：虽然当前效果不佳，但未来会改善，因此你只需要简单的工具调用型 Agent。我认为以下几点可能同时成立：
- 这类工具调用型 Agent 的性能会提升
- 控制大模型输入内容仍然至关重要（垃圾进，垃圾出）
- 对某些应用，这种工具调用循环就足够
- 对其他应用，工作流仍会更简单、经济、快速和优秀
- 对大多数应用，生产级 Agent 系统将是工作流和 Agent 的组合
是否存在简单工具调用循环就足够的场景？我认为只有当使用针对特定用例进行充分训练/微调/强化学习的大模型时才会成立。这有两种实现路径：
- 你的任务具有独特性。你收集大量数据并训练/微调/强化学习自己的模型。一个使用针对特定任务训练模型的简单工具调用型 Agent 案例是：OpenAI 的 Deep Research，这说明确实可行，并能产出卓越的 Agent。如果你能为特定任务训练顶尖模型——那么确实，你可能不需要支持任意工作流的框架，简单工具调用循环就足够。此时 Agent 会比工作流更受青睐。
- 你的任务具有普遍性。大型模型实验室正在训练/微调/强化学习与你的任务相似的数据。编程是个有趣的例子，编码相对通用。
即使对于 Agent 明显优于任何工作流方案的应用，你仍会受益于框架提供的与底层工作流控制无关的功能：短期记忆存储、长期记忆存储、人在回路、人在环上、流式传输、容错性和调试/可观测性。框架应提供的核心价值：可靠的编排层，让开发者能精确控制传入大模型的上下文，同时无缝处理持久化、容错和人机协作等生产环境问题。
框架
现有框架对比
Agentic AI：8个开源框架对比-2025更新 PS：有细节控制需求用langgraph，稍微抽象好一点可以尝试 Agno Agentic AI 主要是围绕着大型语言模型（LLMs）构建系统，让它们能够拥有准确的知识、数据访问能力和行动能力。你可以把它看作是使用自然语言来自动化流程和任务。在自动化中使用自然语言处理并不是什么新鲜事 - 我们已经用 NLP 多年来提取和处理数据了。新的是我们现在能给语言模型的自由度，允许它们处理模糊性并动态做出决策。没错，大模型的优势就是处理模糊性和有一定的规划能力。但仅仅因为 LLMs 能理解语言，并不意味着它们就有代理性 - 甚至理解你想要自动化的任务。这就是为什么构建可靠系统需要大量的工程技术。框架的核心，是帮你进行提示工程化和管理数据在大型语言模型（LLMs）之间的传输——但它们也提供了额外的抽象层，让你更容易上手。
大多数框架都带有相同的核心构建模块：支持不同的模型、工具、内存和RAG。
- 大多数开源框架或多或少都是模型不可知的。这意味着它们被构建为支持各种提供商。
- 所有具有代理性的框架都支持工具化，因为工具对于构建能够采取行动的系统至关重要。它们还使得通过简单的抽象定义自己的自定义工具变得容易。如今，大多数框架都支持MCP，无论是官方的还是通过社区解决方案的。
- 为了使代理能够在LLM调用之间保留短期记忆，所有框架都使用状态。状态帮助LLM记住在早期步骤或对话的部分中说过的内容。
- 大多数框架还提供简单的选项来设置RAG，与不同的数据库结合，为代理提供知识。
- 最后，几乎所有框架都支持异步调用、结构化输出、流式传输以及添加可观察性的能力。
有些框架缺少的东西
- 有些框架有内置的多模态处理解决方案- 也就是文本、图像和声音。只要模型支持，你完全可以自己实现这一点。
- 短期记忆（状态）总是包括在内的 - 没有它，你就无法构建一个使用工具的系统。然而，长期记忆更难实现，这也是框架之间的差异所在。有些提供内置解决方案，而其他的则需要你自己去连接其他解决方案。
- 框架在处理多智能体能力方面也各不相同。多智能体系统允许你构建协作或分层的设置，通过监督者连接智能体团队。
框架在抽象程度、给予Agent的控制权以及你需要编写多少代码才能让事情运行起来方面各不相同。
- 抽象程度。CrewAI 和在某种程度上的 Agno 都是为即插即用而设计的。 LangGraph也有相当的抽象程度，但它使用基于图的系统，你需要手动连接节点。这给了你更多的控制权，但也意味着你必须自己设置和管理每个连接，这带来了更陡峭的学习曲线。
- 另一个区别点是框架假设Agent应该有多少自主权。有些是建立在这样的想法上：LLMs 应该足够聪明，能够自己弄清楚如何完成任务。其他的则倾向于严格控制 - 给代理一个任务，并一步一步指导它们。AutoGen 和 SmolAgents 属于第一种类型。其余的更倾向于控制。
一个 Agent 系统可能会因为其 Agent 循环向用户暴露的方式不同而呈现出不同的 “风格”
- （LangGraph的）Agent 系统可以表示为节点和边。节点代表工作单元，边代表转移关系。节点和边本质上就是普通的 Python/TypeScript 代码——虽然图结构是声明式表达的，但图内部的逻辑仍是常规的命令式代码。边可以是固定或条件的。因此，虽然图结构是声明式的，但图的遍历路径可以完全动态。
- LangGraph 内置持久化层，支持容错、短期记忆和长期记忆。该持久化层还支持”人在回路”和”人在环上”模式，如中断、审批、恢复和时间旅行。
- LangGraph 内置支持流式传输：包括 token 流、节点更新流和任意事件流。
- 大多数 Agent 框架都包含 Agent 抽象。通常始于一个包含提示词、模型和工具的类，然后不断添加参数…最终你会面对一个控制多种行为的冗长参数列表，全部隐藏在类抽象之后。要了解运行机制或修改逻辑，必须深入源代码。这些抽象最终会让你难以理解或控制在每一步传入大模型的具体内容。明确地说，Agent 抽象确实有其价值——能降低入门门槛。但我认为这些抽象还不足以（或许永远不足以）构建可靠的 Agent。我们认为最佳方式是将这些抽象视为类似 Keras 的存在——提供高级抽象来简化入门。但关键是确保它们构建在底层框架之上，避免过早触及天花板。这正是我们在 LangGraph 之上构建 Agent 抽象的原因。这既提供了简单的 Agent 入门方式，又能在需要时轻松切换到底层 LangGraph。
框架的通用价值在于提供有用的抽象，既降低入门门槛，又为工程师提供统一的构建方式，简化项目维护。
- Agent 抽象
- 短期记忆，长期记忆
- 人机协作，获取用户反馈、审批工具调用或编辑工具参数。允许用户实时影响 Agent
- 事后回溯，让用户在事后检查 Agent 运行轨迹
- 流式传输
- 调试/可观测性
- 容错性，LangGraph 通过持久化工作流和可配置重试简化容错实现。
- 优化，相比手动调整提示词，有时定义评估数据集并自动优化 Agent 更高效。
从能力来看框架
Agent 的四大能力，每一环节的能力可大可小，每一环节的角色也可多可少。PS：每谈论一个东西，这个东西就有它固有的脉络，按脉络走就都梳理清楚了。
- 规划，Agent 的规划能力必须要有清晰、详细的指令才能稳定发挥，prompt 工程比想象中重要、执行起来也更琐碎。其次，从打分上看，目前 LLM 的数学、逻辑推理能力在 COT 的基础上也仅能勉强达到及格水平，所以不要让 Agent 一次性做过于复杂的推理性规划工作，而是把复杂任务强行人工拆解，而不是通过提示词让 LLM 自己拆解。PS：指令微调可以节约这部分的提示词，以及提高准确率。
- 记忆
- 短期记忆，存储即时对话上下文、当前任务步骤、临时操作结果等动态信息。
- 长期记忆，用户历史行为、企业知识库、任务经验等数据，支持个性化服务和复杂推理。例如记录用户过去3个月的所有购物偏好，用于精准推荐。
- 行动。Action 能力强烈依赖于基座模型的 function calling 能力，即理解任务并依据 API 描述将自然语言的任务转换为 API request 的能力。由于执行准确率有限，要考虑到 function calling 失败的备选方案，比如：客服案例中，function calling 失败直接对接到人工；API 参数缺失，考虑根据 API 返回的错误信息，转换成用户语言继续追问用户。
- 反省，反思能力依赖于它的记忆能力。PS：传统的软件系统没有反思能力，万一执行失败了咋办？报警喊人来修
如果希望最后能够达到通用 Agent 的目标，要做到通用，需要有如下的核心路径：
- 工具尽可能丰富，让 Agent 有充分的外部工具可以调用。比如给它一个编辑器的接口，它可以写出优雅的代码；给它一个浏览器的接口，它可以获取多元的网页信息。
- 流程尽可能简洁、可复用。如果我们做的 Agent 在完成任务时需要依赖复杂的工作流，那么一定是无法做到通用级别的。流程做的简单和通用，反而有助于解决通用任务，以不变应万变。简而言之，Less Structure, More Intelligence。
从最根本的角度来看，一套 Agent 能够工作的好，并不在于有多少数量的 Agent，而是是否有上述的规划、行动、反思的能力，且有很简单、自然的方式将这些能力串联。接下来的问题就是如何做好这个串联的过程。《思考，快与慢》里面将人脑分为了系统一和系统二，前者适合短期的、即时的、比较简单的工作，而后者适合需要逻辑推理或者大量思考的工作。这是一个很优秀的思考模型，我们可以按照这个思路来做通用 Agent：
- 系统一即 Executor，专门用来根据指令找到工具，并且执行工具，这个场景不需要太多深度推理。
- 系统二即 Awarer，用来做环境感知和下一步的决策。当然，这里的决策不仅仅包括最开始的任务拆解，也包括了后续每个小任务执行完之后的反思和下一个步骤具体行为的决策。PS：其它文章也看到，Agent的技术拆分方式：规划，执行。
举个例子，比如我现在要启动一个获取新能源汽车价格的任务：
- （任务拆解）首先系统二 Awarer 开始规划：
- 第一步搜索网页、第二步查看网页详情、第三步整理 markdown 并输出。
- （选择并执行工具）然后系统一 Executor 拿到每一步指令后调用 Search API 获取搜索结果
- （反思并决策下一步动机）Awarer 看到搜索结果后，决策要进入某一个具体的网址查看详情，告诉 Executor 即将要前往拿到页面详情。
- （选择并执行工具）Executor 判断要调用浏览器工具，并进入某个具体的网页查看详情。
- …
- 结果：产出完善的价格分析报告
加上工程的各个环节之后，涉及的细节相较而言会更复杂。
- 当用户输入消息之后，消息会被推入一个核心的管理对象 EventStream 当中。随后，Awarer、Executor、User 三者的消息互通全部通过 EventStream 完成
- Awarer 最先拿到消息，然后对任务进行拆解，规划出诸多的 Plan Tasks。后续的所有操作，全部基于这些 Tasks 展开。Awarer 的输出结构如下：
{ "plan": [后续的任务规划], "status": [下一步的动作], "step": [下一步到达哪个步骤], "reflection": [基于已有环境的反思] } - 接下来，Executor 获取其 Awarer 的 status 信息，从丰富的工具库中选择工具进行执行。执行完的结果，推入 EventStream 中，被 Awarer 获取。
- Aware 随后进行一次思考，同样返回上面的输出结构，但不同的是，在已有 plan 的情况下，Aware 不会重复输出 plan 的内容了，因此后续的输出也会更加简洁。 就这样，Awarer、Executor 达成了非常默契的持续交互。所有环境相关的信息，都放在 EventStream 中统一进行管理，Awarer、Executor 不需要直接通信，从 EventStream 推入或者拿取上下文即可。在 Aware 架构运行的流程中，无论任何时候，都允许用户的介入，且让用户获得整个 Agent 系统的立即反馈。用户可以将自己发的消息直接推入 EventStream，Agent 运行时系统会自动中断任何正在进行的请求和流程，然后要求 Awarer 根据用户的新输入重新规划下一步的行动，从而实现 Human in the loop 的效果。
多 Agent 系统
OpenAI 在报告中指出：对于复杂工作流，将提示词和工具分配给多个 Agent 可以提高性能和扩展性。当你的 Agent 无法遵循复杂指令或持续选择错误工具时，可能需要进一步拆分系统并引入更多独立 Agent。多 Agent 系统的关键在于通信机制。再次强调，构建 Agent 的难点在于为大模型提供正确上下文。Agent 间的通信方式至关重要。
- 交接(handoffs)是一种方式——这是 Agents SDK 中我相当欣赏的一个 Agent 抽象。
- 但有时最佳通信方式可能是工作流。将其中的大模型调用替换为 Agent。这种工作流与 Agent 的混合往往能提供最佳可靠性。
其它
Windsurf团队关于Agent的认知，相当精彩“有价值的问题” 与 “技术是否已经足够可靠” 之间的交集，协作式 Agent（AI flows） 方法所需的稳健性门槛要远低于完全自主的 Agent 方法。 Agent 系统所面临的普遍挑战：虽然 Agent 系统代表着未来的发展方向，但今天的 LLM 可能还不具备足够的能力，在没有任何人类参与或纠正的情况下，从头到尾完成这些复杂任务。现实促使人们开始采取一种新的 Agent 系统方法，这种方法基于一个共识：在人类与 Agent 之间，应该存在一种合理的任务分配平衡。
- 需要有清晰的方式让人类在流程执行过程中观察它的行为，这样一旦流程偏离预期，人类可以尽早进行纠正。可以被要求批准 AI 的某些操作（例如执行终端命令）。这些流程必须运行在与人类进行实际工作的相同环境中。换句话说，在这个现实中，让人类观察 Agent 在做什么很重要，而让代 Agent 观察人类在做什么也同样重要。PS：与之对应的是 Agent在没有人类参与的情况下在后台运行
我们花这么大篇幅来区分 “自主 Agent” 和 “协作式 Agent”，是因为这两种方式在构建 Agent 系统时，其实是截然不同的路径。它们涉及到完全不同程度的人机协作、不同程度的信任需求、不同的交互方式等等。