Anthropic Agents年度总结

2025年，Agentic系统将真正进入成熟期。Computer Use、MCP（模型上下文协议）、改进的工具调用能力……这些基础设施正逐步就绪。现在是时候认真规划如何搭建这些系统了。Anthropic近期总结了2024年的一系列最佳实践，并发布了一篇题为《如何构建有效的智能体》（Building effective agents）的文章，系统梳理了业界一线团队的真实经验与落地心得。

什么是智能体（Agents）？

“Agent”这个词的解读多种多样。有些团队将其理解为完全自主的系统——能够长时间独立运行，借助各类工具完成复杂任务；另一些团队则用它来指代遵循预定义工作流程、更偏规范性的实现。在Anthropic看来，所有这些变体都可以归类为Agent系统，但在工作流与Agent之间，存在一条重要的架构分界线：

• 工作流：通过预先编码好的路径，将LLM与工具有序串联起来执行任务的系统。
• Agent：让LLM自身动态地引导流程与工具的使用，保持对任务完成方式的自主掌控。

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

使用LLM构建应用时，最明智的做法始终是优先寻找最简单的方案，只在确实必要时才增加复杂度。这意味着，很多时候你根本不需要构建Agent系统。Agent系统通常以更高的延迟和成本来换取更优的任务性能——这笔投入必须精打细算，只在确实值得时才出手。当复杂度确需提升时，工作流能够为定义清晰的任务提供可预测性与一致性；而当需要大规模灵活性以及模型驱动的决策时，Agent才是更合适的选择。不过说实话，对于许多应用场景而言，仅靠优化单个LLM调用（配合检索和示例上下文）就能解决问题，根本用不上那些花哨的架构。

何时以及如何使用框架

市面上已有不少框架能让Agent系统的实现变得更便捷，例如：

• LangChain的LangGraph
• Amazon Bedrock的AI Agent框架
• Rivet（一款拖放式GUI LLM工作流构建工具）
• Vellum（另一个用于构建和测试复杂工作流的GUI工具）

这些框架简化了调用LLM、定义解析工具、链式调用等标准底层任务，上手确实很快。但它们往往会引入额外的抽象层，把底层的提示和响应隐藏起来，调试起来反而更费周折。更麻烦的是，明明一个简单设置就能搞定，这些框架却容易让人忍不住往上叠加功能。因此强烈建议：直接使用LLM API——很多模式用几行代码就能实现。如果你非要使用框架，那一定要吃透底层代码。对底层逻辑的错误假设，是客户错误最常见的来源，没有之一。

构建块、工作流和Agent

这一部分我们来看看生产环境中常见的Agent系统模式。从最基础的构建块——增强型LLM——开始，逐步叠加复杂度，一直延伸到自主Agent。

构建模块：增强型 LLM

Agent系统的基本积木就是LLM，但它必须经过增强——比如配上检索、工具和记忆能力。当前的模型已经能够主动使用这些能力：自己生成搜索查询、选择合适的工具、判断哪些信息值得保留。

增强型LLM

在具体实施中，有两个关键点值得重点关注：一是根据你的用例来定制这些增强功能，二是确保它们为LLM提供简单、有据可查的接口。实现方式有很多种，其中一种是借助最近发布的模型上下文协议（MCP），它让开发者能够通过简单的客户端接入不断扩展的第三方工具生态。在后续讨论中，我们默认每次LLM调用都已经具备这些增强能力。

工作流程：提示链

提示链就是把任务拆分成一连串步骤，每个LLM调用都处理前一步的输出结果。你可以在任意中间步骤加入程序检查（也就是下图中的“门”），确保流程没有跑偏。

提示链工作流程

什么时候使用这种工作流？当任务能够干净利落地拆解为固定的子任务时，它特别有效。核心理念是：牺牲一点点延迟，换来更高的准确率，因为每个LLM调用都只专注于一个更简单的子问题。

适用例子：

• 生成营销文案，然后翻译成不同语言。
• 先撰写文档大纲，检查大纲是否符合标准，再根据大纲生成完整的文档。

工作流程：路由

路由负责对输入进行分类，然后将其引导至专门的下游任务。这样做的好处是分离关注点，从而构造出更专业的提示。如果没有路由，为了迎合一种输入而做的优化，反而可能损害其他输入的效果。

路由工作流程

什么时候使用？当任务中存在明显不同的类别，最好分开处理，并且分类这件事能够靠LLM或传统模型/算法准确完成。

适用例子：

• 把不同类型的客户服务咨询（普通问题、退款、技术支持）导引到不同的流程、提示和工具中。
• 把简单/常见问题交给轻量模型（比如Claude 3.5 Haiku），把困难/冷门问题升级给更强模型（比如Claude 3.5 Sonnet），这样能够优化成本和响应速度。

工作流程：并行化

LLM有时候可以同时执行一项任务，然后通过编程汇总输出。这种并行化工作流有两个关键变体：

• 分段：把任务拆解成并行的独立子任务。
• 投票：用同一个任务运行多次，拿到不同输出再综合判断。

并行化工作流程

什么时候使用？当子任务可以并行来提速，或者需要多个视角/尝试来获得更可靠的结果时，并行化非常有效。对于那种需要考虑多个方面的复杂任务，把每个方面交给单独的LLM调用处理，模型反而表现更好——因为它能够集中注意力于每个特定维度。

适用例子：

• 切片：
  • 实施双重防护：一个模型实例处理用户查询，另一个同时筛查不适当内容。这比让同一个LLM既做核心响应又做审核要强。
  • 自动评估LLM性能：每个LLM调用针对提示的不同侧面进行评估。
• 投票：
  • 审查代码漏洞：用几个不同的提示分别审查同一段代码，发现问题就标记。
  • 判断内容是否违规：多个提示从不同维度评估，设定不同的投票阈值来平衡误报和漏报。

工作流程：Orchestrator-workers

这种模式中，一个中央LLM（编排器）动态地把任务拆分成子任务，分派给多个worker LLM，最后再把结果汇总。

Orchestrator-workers 工作流程

什么时候使用？当子任务无法提前预测时特别有效——比如编码任务，需要修改哪些文件、每个文件怎么改，完全取决于具体需求。从拓扑上看，它和并行化有些相似，但关键区别在于灵活性：子任务不是事先定好的，而是编排器根据当前输入动态决定的。

适用例子：

• 编码产品：每次对多个文件进行复杂修改。
• 搜索任务：需要从多个来源收集和分析信息，找出相关结果。

工作流程：评估器-优化器

在这个模式中，一个LLM负责生成响应，另一个则在一个循环里提供评估和反馈。

评估器-优化器工作流程

什么时候使用？当我们有清晰的评判标准，并且迭代改进能够带来可衡量的价值时，它尤其好用。两个典型标志：一是当人类给出反馈时，LLM的响应能够明显改善；二是LLM本身就能够生成那种有价值的反馈。这就像人类作者在打磨一篇好文章时反复修改的过程。

适用例子：

• 文学翻译：译者LLM一开始可能漏掉某些细微之处，但评估者LLM能够给出有用的批评。
• 复杂搜索任务：需要多轮搜索和分析才能收集全面信息，评估者决定是否要再来一轮。

智能体Agents

随着LLM在理解复杂输入、推理规划、可靠使用工具和从错误中恢复这些关键能力上日趋成熟，智能体已经开始投入生产。它们通常由人类用户下达命令，或者通过对话互动开始工作。任务一旦明确，智能体就独立地规划、操作，过程中可能向人类请求更多信息或判断。执行时，它必须从环境中获取“基本事实”（比如工具调用结果或代码执行输出）来评估进度。遇到瓶颈或需要检查时，它也可以暂停，等待人类反馈。任务完成后终止，但通常也会设置停止条件（比如最大迭代次数）来保持控制。

智能体可以处理复杂的任务，但它们的实现通常很简单。本质上就是一个配上工具的LLM，靠环境反馈来指导下一步。因此，把工具集及其文档设计得清晰、周到，才是关键。

自主智能体

什么时候使用智能体？当问题是开放式的，很难甚至不可能提前预测具体步骤，而且你也无法硬编码固定路径时，智能体就派上用场了。LLM可能会运行很多轮，你必须对其决策有一定程度的信任。智能体的自主性让它在受信任的环境里特别适合扩展任务，但也意味着更高的成本和潜在的复合错误风险。建议在沙盒中做充分测试，并配上合适的防护措施。

智能体有用例子：以下来自Anthropic自己的实践：

• 一个编码智能体，专门解决SWE-bench任务——根据任务描述对多个文件进行编辑。
• “计算机使用”参考实现：让Claude直接用计算机完成任务。

编码智能体的高级流程

组合和定制这些模式

这些构建块并不是什么死规定。它们只是开发者在不同场景下可以拿来使用、可以自由组合的常见模式。跟任何LLM功能一样，成功的秘诀在于：衡量性能，然后迭代实现。再强调一遍：只有当复杂度真的能明显改善结果时，才该往上加。

概况总结

在LLM领域取得成功，不在于构建最复杂的系统，而在于构建适合你实际需求的系统。从最简单的提示开始，用综合评估来优化，只有等到简单方案搞不定了，才去上多步骤的智能体系统。

在落地智能体时，有三个核心原则值得遵循：

1. 保持智能体设计的简单性。
2. 通过明确展示智能体的计划步骤来优先考虑透明度。
3. 通过全面的工具文档和测试，精心打磨智能体-计算机接口（ACI）。

框架能帮你快速起步，但在投入生产时，别犹豫——去掉那些抽象层，用基础组件自己构建。遵循这些原则，你就能创建出既强大又可靠、可维护、让人放心的智能体。

附录 1：实践中的Agent

在与客户合作中，我们发现了两种特别有前景的智能体应用，正好能够体现上述模式的实用价值。它们都说明了一点：智能体最适合那些需要对话加行动、有明确成功标准、有反馈闭环、而且能接入有意义的人工监督的任务。

A. 客户支持

客户支持通过工具集成，把熟悉的聊天机器人界面和增强能力结合起来。这对更开放的智能体来说是天生的好场景，因为：

• 支持交互自然遵循对话流，同时还必须访问外部信息和执行操作；
• 可以对接工具来拉取客户数据、订单记录和知识库文章；
• 退款、改签等操作能够通过编程自动化；
• 成功与否可以通过用户定义的解决标准来明确衡量。

不少公司已经通过按使用量付费的模式证明了这条路走得通——只对成功解决问题的方案收费，这也表现出对自身智能体效率的信心。

B. 编码Agents

软件开发领域已经展现出LLM的巨大潜力，从代码补全一路进化到自主解决问题。Agent在这方面特别有效，因为：

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

在Anthropic自己的实现中，Agent已经能够仅凭一个拉取请求描述，就搞定SWE-bench Verified基准里的真实GitHub问题。不过，尽管自动化测试有助于验证功能，人工审核仍然必不可少——要确保解决方案符合更广泛的系统要求。

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

无论你构建的是哪种Agent系统，工具都大概率是核心组件。通过在API中详细指定外部服务和API的结构与定义，工具能让Claude与它们交互。当Claude决定调用工具时，它会在API响应中包含一个工具使用块。工具的定义和规范，应该像你的整体提示一样，精心对待。这个附录简要说一下怎么对工具做即时工程。

通常，同样的操作可以有多种实现方式。比如编辑文件，你可以写diff，也可以直接重写整个文件。对于结构化输出，你可以用markdown返回代码，也可以用JSON。在软件工程里，这些差异只是表面的，可以无损地在格式间转换。但对LLM来说，某些格式写起来就是更费劲。比如编写diff，你需要知道块头有多少行发生了变化才能写对；在JSON里写代码，还要额外转义换行和引号。

关于工具格式的建议：

• 给模型足够的“思考”空间——确保token数量充足，别让它还没想明白就被迫输出。
• 保持格式贴近模型在互联网文本中自然见过的样子。
• 避免任何格式化“开销”，比如必须准确计数几千行代码，或者对自己写的代码做字符串转义。

一个简单的经验法则：想想在人机界面（HCI）上你花了多少心思，那么在设计Agent-计算机界面（ACI）时，投入同样甚至更多的精力。具体可以这样做：

• 站在模型的角度想：根据描述和参数，这个工具怎么用是不是一目了然？如果人类都得琢磨半天，那模型也一样。好的工具定义通常包含示例用法、边界情况、输入格式要求，以及与其他工具的明确界限。
• 试试调整参数名或描述，让一切更直观。就像给团队里的初级开发人员写漂亮的文档字符串一样。当你在使用多个相似工具时，这点尤其重要。
• 测试模型怎么用你的工具：在工作台里跑一批示例输入，观察模型容易在哪里犯错，然后迭代改进。
• 防错设计：调整参数，让错误不容易发生。

在为SWE-bench构建Agent时，我们花在优化工具上的时间，实际上比优化整体提示还要多。举个例子：我们发现一旦Agent离开根目录，用相对路径引用文件时就会出错。解决方法是把工具改成强制要求绝对路径——结果模型用起来毫无问题。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Anthropic Agents年度总结要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题