大模型厂商视角的AI Agent综述，Anthropic图文并茂多个案例教你构建有效智能体

• 如何建立有效的智能体？来自anthropic的官方AI Agent构建指南
• 一文了解大模型厂商眼中的智能体，来自anthropic的AI Agent年度性总结
• 到底什么是智能体？一篇anthropic官方AI Agent综述看明白
• 工作流和Agent有何区别？应该什么时候用工作流和Agent？Anthropic官方指南来了
• 构建AI Agent用框架还是用工作流？Anthropic年度综述智能体构建指北
• 大模型厂商视角的AI Agent综述，Anthropic图文并茂多个案例教你构建有效智能体

最近两个月，全球大语言模型厂商都在关注和学习的OpenAI和anthropic，都迭代了最新产品和解决方案。

OpenAI的12场直播前11场平平无奇，倒是最后一场压轴的高性能AI推理模型o3又让人眼前一亮。是的，最新发布的o系列模型不叫o2而是取名o3，不知道是不是为了应景OpenAI处于其AGI五级量化表中的第三阶段。当然，还有个说法是o2这个名字被抢注了。

名字不过是一个代号，关键是o3的能力还是给了大家很多震撼。其在一项推理基准测试ARC AGI 中表现优异，得分从之前模型的32% 跃升至87%，在解决复杂逻辑和数学问题上的能力有了显著提升。

随之而来的便是“AI取代程序员”的声量再次被放大，也让更多人又开始相信大模型是实现AGI的曙光。

虽然o3成功引起了热议，但GPT-5还是被曝光研发受阻。在为期18个月的开发过程中，OpenAI 已完成至少两轮大规模训练。只是初始训练速度低于预期，导致后续大规模训练既耗时又成本高昂，该项目正面临重大挑战。

所以对于“AGI桥梁”这样的愿景词汇，大家已经越来越不感冒了。

OpenAI用12场直播让大家记住了o3模型与AGI愿景，却带有一些未来主义宏大叙事色彩。倒是anthropic在11月发布的可操控电脑的模型Claude 3.5 sonnet升级版 ，到现在还为大家所津津乐道。

Claude3.5 sonnet升级版实则已是一个AI Agent，而能够操控电脑也就意味着能够执行复杂业务。Anthropic发布这个模型，也意味着全球大语言模型的Agent化已经彻底开启。甚至，它还在二级市场催生了类似“电脑使用（Computer Use）”这样的概念股。

不只如此，Anthropic还推出了一种模型上下文协议和架构（MCP Architecture），用于为语言模型提供从外部系统获取的必要上下文。顾名思义，模型上下文协议定义了如何将现有数据源（如文件系统、关系数据库、代码存储库和几乎所有其他内容）连接到 LLM 和Agent。

相关介绍：https://www.anthropic.com/news/model-context-protocol

                                               ANTHROPIC MCP架构

模型上下文协议代表了AI集成向前迈出的重要一步，提供了一个通用标准，简化了AI系统和各种数据源之间的连接。这种开源协议解决了碎片化数据访问的挑战，允许更高效和上下文感知的 AI 应用程序。通过更轻松地与不同的数据源进行交互而不会出现任何问题，MCP 提高了 AI 生成的响应的相关性和准确性。

所以，它被认为是AI Agent或者AI能力发展的重要一步。

从Computer Use到MCP再到改进的工具使用，Anthropic所做这些都是在推进AI Agent的落地与应用。这个时间不到2个月，却让其AI Agent已经大放异彩。能够这么快速地推出AI Agent应用生态，可以见得Anthropic对于智能体这一领域的深度探索与积累。

在这些产品与解决方案的背后，是在过去一年里，Anthropic与数十个团队的合作、交流以及构建的数十个跨行业大型语言模型Agent。

正是基于这些探索与经验，12月20日Anthropic发布了一篇名为《Building effective agents（构建有效智能体）》的年度总结性文章。

原文链接：https://www.anthropic.com/research/building-effective-agents

这是一篇对智能体的总结性文章，也是一篇大语言模型厂商视角的AI Agent综述。它介绍了如何构建高效的基于大型语言模型(LLM)的智能体，比较了工作流和智能体两种系统架构，详细阐述了多种工作流模式（如提示链、路由、并行化等），并强调了构建简单、透明、易于测试的智能体的重要性，以客户支持和编码智能体为例说明了实际应用。还提供了工具提示工程的建议，以提高智能体与工具交互的效率。

重点讲述了Agent和工作流的定义、何时使用Agent、何时使用框架、构建Agent的基块和工作流模式，以及Agent的实践应用。

这篇综述，对于理清一些AI Agent相关的概念有很大的帮助。对于一些似是而非的概念，比如当前大家很容易把工作流和Agent混淆，这篇文章也有相应的叙述。

文章讲了不少，当然重点还是告诉大家如何构建有效的智能体。毕竟当前市面上很多平台都存在大量智能体，但对用户个性化需求而言真正可用的可能并不多。所以，从体验通用智能体到尝试构建适应自己的个性化智能体才是最佳选择。

文章建议从简单的LLM API开始，并在必要时增加复杂性，以构建有效且可靠的Agent系统。这一点很重要，对于大家在什么需求应该怎样构建一个面向自身业务需求的Agent有很强的指导意义。

这篇综述有助于大家更简单地搞懂当前阶段的AI Agent形态，这里贴上原文供大家研读。

在过去的一年中，我们与数十个团队合作，跨行业构建大型语言模型（LLM）Agent。始终，最成功的实现不是使用复杂的框架或专门的库，而是使用简单、可组合的模式构建。

在这篇文章中，我们分享了我们从与客户和建筑Agent合作中学到的经验，并为开发人员提供了关于构建有效Agent的实用建议。

什么是Agent？

“Agent”可以通过多种方式定义。一些客户将Agent定义为完全自主的系统，可以在较长时间内独立运行，使用各种工具来完成复杂的任务。其他人使用该术语来描述遵循预定义工作流的更具规范性的实现。

在Anthropic，我们将所有这些变体归类为Agent系统，但在工作流和Agent之间进行了重要的架构区分：

• 工作流是通过预定义的代码路径编排LLM和工具的系统。
• Agent是LLM动态指导自己的流程和工具使用的系统，保持对如何完成任务的控制。

下面，我们将详细探讨这两种类型的Agent系统。在附录1（“实践中的Agent”）中，我们描述了两个领域，客户在使用这些类型的系统时发现了特别的价值。

何时（以及何时不）使用Agent

在使用LLM构建应用程序时，我们建议找到最简单的解决方案，并在需要时仅增加复杂性。这可能意味着根本不构建Agent系统。Agent系统通常会为了更好的任务性能而牺牲延迟和成本，您应该考虑何时这种权衡是有意义的。

当需要更多的复杂性时，工作流为明确定义的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动决策时，Agent是更好的选择。然而，对于许多应用程序，通过检索和上下文示例优化单个LLM调用通常就足够了。

何时以及如何使用框架

有许多框架可以使Agent系统更容易实现，包括：

• 来自 LangChain 的 LangGraph；
• Amazon Bedrock的AI Agent框架；
• Rivet，一个拖放GUILLM工作流生成器；
• Vellum，另一个用于构建和测试复杂工作流的GUI工具。

相关链接：

LangGraph：https://langchain-ai.github.io/langgraph/

Amazon Bedrock：https://aws.amazon.com/bedrock/agents/

Rivet：https://rivet.ironcladapp.com/

Vellum：https://www.vellum.ai/

这些框架通过简化标准的低级任务，如调用LLM、定义和解析工具以及将调用链接在一起，使入门变得容易。然而，它们通常会创建额外的抽象层，这可能会掩盖底层提示和响应，使它们更难调试。当更简单的设置就足够时，它们还可能会使增加复杂性变得诱人。

我们建议开发人员直接使用LLM API：许多模式可以在几行代码中实现。如果您使用框架，请确保您理解底层代码。对底层代码的错误假设是客户错误的常见来源。

有关一些示例实现，请参阅我们的食谱（Building Effective Agents Cookbook）。

食谱链接：https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents

构建块、工作流和Agent

在本节中，我们将探讨我们在生产中看到的Agent系统的常见模式。我们将从我们的基础构建块——增强型LLM开始，逐步增加复杂性，从简单的组合工作流程到自主Agent。

  构建块：增强型LLM

Agent系统的基本构建块是通过检索、工具和内存等增强功能增强的LLM。我们当前的模型可以积极使用这些功能——生成自己的搜索查询、选择适当的工具并确定要保留哪些信息。

增强的 LLM

我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的LLM提供一个简单、文档齐全的界面。虽然有很多方法可以实现这些增强，但一种方法是通过我们最近发布的模型上下文协议，它允许开发人员通过简单的客户端实现与不断增长的第三方工具生态系统集成。

参考链接：

模型上下文协议：​​​https://www.anthropic.com/news/model-context-protocol​​

客户端实现：https://modelcontextprotocol.io/tutorials/building-a-client#building-mcp-clients​

对于本文的其余部分，我们将假设每个LLM调用都可以访问这些增强功能。

  工作流：提示链接 Workflow: Prompt chaining

提示链接将任务分解为一系列步骤，其中每个LLM调用处理前一个的输出。您可以在任何中间步骤上添加编程检查（参见下图中的“门”），以确保流程仍在正轨上。

提示链接工作流

何时使用此工作流：此工作流非常适合任务可以轻松干净地分解为固定子任务的情况。主要目标是通过使每个LLM调用成为更容易的任务来权衡延迟以获得更高的准确性。

提示链接有用的示例：

• 生成营销文案，然后将其翻译成不同的语言。
• 编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。

  工作流：路由 Workflow: Routing

路由对输入进行分类并将其定向到专门的跟进任务。此工作流程允许分离关注点并构建更专门的提示。如果没有此工作流程，针对一种输入进行优化可能会损害其他输入的性能。

路由工作流

何时使用此工作流：路由适用于复杂任务，其中有更好地单独处理的不同类别，并且可以通过LLM或更传统的分类模型/算法准确处理分类。

路由有用的示例：

• 将不同类型的客服查询（普通问题、退款申请、技术支持）引导到不同的下游流程、提示和工具中。
• 将简单/常见问题路由到Claude 3.5 Haiku等较小的模型，将困难/不寻常问题路由到Claude 3.5 Sonnet等功能更强大的模型，以优化成本和速度。

  工作流：并行化 Workflow: Parallelization

LLM有时可以同时处理任务，并以编程方式聚合其输出。这种工作流程，并行化，体现在两个关键变体中：

• 分段：将任务分解为并行运行的独立子任务。
• 投票：多次运行相同的任务以获得不同的输出。

并行化工作流

何时使用此工作流：当划分的子任务可以并行化以提高速度时，或者当需要多个视角或尝试以获得更高的置信度结果时，并行化是有效的。对于具有多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时，LLM通常表现更好，允许将注意力集中在每个特定方面。

并行化有用的示例：

分段：

• 实现护栏，其中一个模型实例处理用户查询，而另一个模型实例筛选不适当的内容或请求。这往往比让相同的LLM调用同时处理护栏和核心响应表现更好。
• 自动评估LLM性能，其中每个LLM调用在给定提示下评估模型性能的不同方面。

投票：

• 审查一段代码是否存在漏洞，如果发现问题，几个不同的提示会审查并标记代码。
• 评估给定内容是否不合适，多个提示评估不同方面或需要不同的投票阈值来平衡误报和误报。

  工作流：协调员-工作者 Workflow: Orchestrator-workers

在orchestrator-workers工作流中，中央LLM动态分解任务，将它们委托给工作LLM，并综合它们的结果。

业务流程协调程序-工作程序工作流

何时使用此工作流：此工作流非常适合无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。虽然它在地形上相似，但与并行化的关键区别在于它的灵活性——子任务不是预先定义的，而是由编排器根据特定输入确定的。

orchestrator-workers有用的示例：

• 每次对多个文件进行复杂更改的编码产品。
• 涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。

  工作流：评估器-优化器 Workflow: Evaluator-optimizer

在评估器-优化器工作流程中，一个LLM调用生成响应，而另一个在循环中提供评估和反馈。

评估器-优化器工作流

何时使用此工作流程：当我们有明确的评估标准，并且迭代细化提供可衡量的价值时，此工作流程特别有效。良好匹配的两个迹象是，首先，当人类表达他们的反馈时，LLM响应可以明显改善；其次，LLM可以提供这样的反馈。这类似于人类作家在制作精美文档时可能经历的迭代写作过程。

评估器优化器有用的示例：

• 文学翻译，其中有翻译LLM最初可能无法捕捉到的细微差别，但评估LLM可以提供有用的批评。
• 需要多轮搜索和分析以收集综合信息的复杂搜索任务，评估者在其中决定是否需要进一步搜索。

  智能体（Agents）

随着LLM在关键能力方面的成熟——理解复杂输入、参与推理和计划、可靠地使用工具以及从错误中恢复，Agent正在生产中崭露头角。Agent从人类用户的命令或交互式讨论开始他们的工作。一旦任务明确，Agent就会独立计划和操作，潜在地返回给人类以获取进一步的信息或判断。

在执行过程中，Agent必须在每个步骤（例如工具调用结果或代码执行）从环境中获得“地面实况”，以评估其进度。然后，Agent可以在检查点或遇到阻塞器时暂停以获得人类反馈。任务通常在完成后终止，但也经常包括停止条件（例如最大迭代次数）以保持控制。

Agent可以处理复杂的任务，但它们的实现通常很简单。它们通常只是循环中使用基于环境反馈的工具的LLM。因此，清晰而深思熟虑地设计工具集及其留档至关重要。我们在附录2（“提示工程您的工具”）中扩展了工具开发的最佳实践。

自主代理

何时使用Agent：Agent可用于难以或不可能预测所需步数的开放式问题，以及您无法硬编码固定路径的问题。LLM可能会运行许多回合，您必须对其决策有一定程度的信任。Agent的自主权使它们成为在可信环境中扩展任务的理想选择。

Agent的自主性质意味着更高的成本和可能的复合错误。我们建议在沙盒环境中进行广泛的测试，以及适当的防护措施。

Agent有用的示例：

以下示例来自我们自己的实现：

• 一个编码Agent，用于解决SWE工作台任务，其中涉及根据任务描述对许多文件进行编辑。参考链接：https://www.anthropic.com/research/swe-bench-sonnet
• 我们的“计算机使用”参考实现，其中克劳德使用计算机来完成任务。参考链接：https://github.com/anthropics/anthropic-quickstarts/tree/main/computer-use-demo

编码Agent的高级流程

组合和自定义这些模式

这些构建块不是规定性的。它们是开发人员可以塑造和组合以适应不同用例的常见模式。与任何LLM功能一样，成功的关键是衡量性能和迭代实现。重复一遍：只有在明显改善结果时，您才应该考虑增加复杂性。

总结

LLM领域的成功并不在于构建最复杂的系统。这是关于为您的需求构建正确的系统。从简单的提示开始，通过全面的评估对其进行优化，只有在简单的解决方案不足时才添加多步骤Agent系统。

在执行Agent时，我们尝试遵循三个核心原则：

1. 保持Agent设计的简单性。

2. 通过明确显示Agent的计划步骤来优先考虑透明度。

3. 通过彻底的工具留档和测试，精心制作您的Agent-计算机接口（ACI）。

框架可以帮助您快速入门，但不要犹豫，减少抽象层并在转向生产时使用基本组件进行构建。通过遵循这些原则，您可以创建不仅强大而且可靠、可维护且受用户信任的Agent。

  致谢

由Erik Schluntz和Barry Zhang撰写。这项工作借鉴了我们在Anthropic建立Agent的经验和客户分享的宝贵见解，我们深表感激。

附录1：实践中的Agent

我们与客户的合作揭示了AIAgent的两个特别有前途的应用程序，它们展示了上述模式的实际价值。这两个应用程序都说明了Agent如何为需要对话和行动的任务增加最大价值，具有明确的成功标准，启用反馈循环，并集成有意义的人类监督。

  A.客户支持

客户支持通过工具集成将熟悉的聊天机器人界面与增强的功能相结合。这是更适合开放式Agent的自然选择，因为：

• 支持交互自然遵循对话流程，同时需要访问外部信息和操作；
• 可以集成工具拉取客户数据、订单历史、知识库文章；
• 可以以编程方式处理退款或更新票证等操作；和
• 成功可以通过用户定义的决议来清楚地衡量。

一些公司已经通过基于使用的定价模型证明了这种方法的可行性，这种模型只对成功的解决方案收费，显示了对其Agent有效性的信心。

  B.编码Agent

软件开发领域已经显示出LLM功能的巨大潜力，其能力从代码完成发展到自主解决问题。Agent特别有效，因为：

• 代码方案可通过自动化测试验证；
• Agent可以使用测试结果作为反馈来迭代解决方案；
• 问题空间定义清晰、结构化；和
• 输出质量可以客观地衡量。

在我们自己的实现中，Agent现在可以仅根据拉取请求描述在SWE工作台验证基准测试中解决真正的GitHub问题。然而，尽管自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。

附录2：快速设计您的工具

无论您正在构建哪个Agent系统，工具都可能是您Agent的重要组成部分。工具使Claude能够通过在我们的API中指定它们的确切结构和定义来与外部服务和API进行交互。当Claude响应时，如果它计划调用工具，它将在API响应中包含一个工具使用块。工具定义和规范应该像您的整体提示一样得到及时的工程关注。在这个简短的附录中，我们描述了如何提示您的工具进行工程设计。

参考链接：

工具：https://www.anthropic.com/news/tool-use-ga

工具使用块：https://docs.anthropic.com/en/docs/build-with-claude/tool-use#example-api-response-with-a-tool-use-content-block

通常有几种方法可以指定相同的操作。例如，您可以通过编写diff或重写整个文件来指定文件编辑。对于结构化输出，您可以在markdown或JSON内返回代码。在软件工程中，这样的差异是表面上的，可以无损地从一个转换到另一个。然而，对于LLM来说，某些格式比其他格式要困难得多。编写diff需要在编写新代码之前知道块头中有多少行正在更改。在JSON内编写代码（与markdown相比）需要额外转义换行符和引号。

我们决定工具格式的建议如下：

• 在模型陷入困境之前，给它足够的令牌来“思考”。
• 保持格式接近模型在互联网上自然出现的文本。
• 确保没有格式化“开销”，例如必须准确计算数千行代码，或对它编写的任何代码进行字符串转义。

一个经验法则是考虑在人机界面（HCI）上投入多少精力，并计划在创建良好的Agent-计算机界面（ACI）上投入同样多的精力。以下是一些关于如何做到这一点的想法：

• 设身处地为模型着想。根据描述和参数，如何使用这个工具是显而易见的，还是需要仔细考虑？如果是这样，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的清晰边界。
• 如何更改参数名称或描述以使事情更加明显？将其视为为团队中的初级开发人员编写出色的文档字符串。在使用许多类似工具时，这尤其重要。
• 测试模型如何使用您的工具：在我们的工作台中运行许多示例输入，以查看模型犯了哪些错误，并进行迭代。
• 对你的工具进行防错设计（Poka-yoke your tools.）：改变论点，这样更难犯错误。

在为SWE工作台构建Agent时，我们实际上花了比整体提示更多的时间来优化我们的工具。例如，我们发现在Agent移出根目录后，模型会在使用相对文件路径的工具时犯错误。为了解决这个问题，我们将工具更改为始终需要绝对文件路径-我们发现模型完美地使用了这种方法。

SWE工作台链接：https://www.anthropic.com/research/swe-bench-sonnet

本文转载自 ​​王吉伟​​，作者： 王吉伟