本文永久链接 – https://tonybai.com/2025/03/11/building-effective-agents
近来，人工智能领域再次风起云涌，各种能力超强的大模型、创新概念和工具层出不穷，让人目不暇接。从DeepSeek发布的开源MoE 模型DeepSeek-V3和令人惊艳的具备深度思考能力的推理模型DeepSeek R1，到声称是“世界上第一个通用AI智能体(Agent)”的Manus以及其开源复刻品OpenManus，再到Anthropic推出让业界大牛程序员Steve Yegge都感到惊叹的Claude Code代码辅助编写Agent工具以及其使用的模型上下文协议（MCP），以及Docker之父Solomon Hykes的Dagger项目转型构建AI Agent工具，无不预示着AI Agent时代的加速到来。
在这一波澜壮阔的技术浪潮中，如何构建高效、可靠且易于维护的AI Agent系统，成为了开发者们共同关注的焦点。Anthropic作为大模型领域的领军企业之一，其在构建AI Agent方面的经验和见解，无疑具有重要的参考价值。
本文翻译自Anthropic官方博客文章《Building Effective AI Agents》，旨在分享Anthropic在与客户合作以及自身实践中总结出的AI Agent构建经验。原文深入探讨了Agentic Systems的概念、架构、常见模式、最佳实践以及工具开发等关键问题，并提供了实用的建议和案例。
选择翻译这篇文章，不仅仅是因为它内容翔实、具有指导意义，更是出于“翻译中学习，学习中翻译”的初衷。通过对原文的翻译，同时也是一次深入学习和理解AI Agent构建技术的绝佳机会。希望本文的翻译能够为广大中文读者提供有益的参考，共同探索AI Agent的无限可能。
注：原文发表于2024年12月中旬，网络上有过很多中文译版，如果你曾阅读过那些文章，你大可忽略本篇文章。
以下是文章正文。
在过去的一年里，我们与数十个团队合作，在各个行业构建大型语言模型 (LLM) 智能体 (Agents)。最成功的那些实现并没有使用复杂的框架或专用库。相反，他们都是使用简单、可组合的模式进行构建的。
在这篇文章中，我们将分享与客户合作和自行构建智能体过程中所学到的知识，并为开发者提供构建高效智能体的实用建议。
什么是智能体？
“智能体(Agent)” 可以有多种定义方式。一些客户将智能体定义为完全自主的系统，它们可以在较长时间内独立运行，使用各种工具来完成复杂的任务。另一些客户则使用该术语来描述遵循预定义工作流的更规范性的实现。在Anthropic，我们将所有这些变体归类为智能体系统(agentic systems)，但在工作流(workflows)和智能体(agents)之间做了重要的架构区分：
- 工作流是通过预定义的代码路径编排LLM和工具的系统。
- 智能体则是LLM动态指导自身流程和工具使用的系统，控制它们完成任务的方式。
下面，我们将详细探讨这两种类型的智能体系统。在附录1（“智能体的实践应用”）中，我们描述了客户发现使用这些系统特别有价值的两个领域。
何时（以及何时不）使用智能体
在使用LLM构建应用程序时，我们建议找到尽可能简单的解决方案，并且仅在需要时才增加复杂性。这可能意味着根本不需要构建智能体系统。智能体系统通常会牺牲延迟和成本来换取更好的任务性能，你应该考虑这种权衡何时有意义。
当需要更多复杂性时，工作流为定义明确的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。然而，对于许多应用程序来说，使用检索和上下文示例优化单个LLM调用通常就足够了。
何时以及如何使用框架
有许多框架可以更容易地实现智能体系统，包括：
这些框架通过简化标准低级任务（如调用LLM、定义和解析工具以及将调用链接在一起）使入门变得容易。然而，它们通常会创建额外的抽象层，这可能会掩盖底层的提示和响应，使它们更难调试。它们还可能诱使在更简单的设置就足够的情况下增加复杂性。
我们建议开发者首先直接使用LLM API：许多模式可以在几行代码中实现。如果你确实使用了框架，请确保你了解底层代码。对底层内容的错误假设是客户错误的常见来源。
请参阅我们的cookbook 以获取一些示例实现。
构建块(Building Blocks)、工作流和智能体
在本节中，我们将探讨我们在生产中看到的智能体系统的常见模式。我们将从基础构建块——增强型LLM——开始，并逐步增加复杂性，从简单的组合工作流到自主智能体。
构建块：增强型LLM
智能体系统的基本构建块是经过增强的LLM，增强功能包括检索、工具和记忆。我们目前的模型可以主动使用这些功能——生成自己的搜索查询、选择合适的工具以及确定要保留的信息。
图：增强型LLM
我们建议重点关注实现的两个关键方面：根据你的特定用例定制这些功能，并确保它们为你的LLM提供简单、文档齐全的接口。虽然有很多方法可以实现这些增强，但有一种方法是通过我们最近发布的Model Context Protocol，它允许开发者通过简单的客户端实现 与不断增长的第三方工具生态系统集成。
在本文的其余部分，我们将假设每次LLM调用都可以访问这些增强功能。
工作流：提示链(Prompt Chaining)
提示链将任务分解为一系列步骤，其中每个LLM调用处理前一个调用的输出。你可以在任何中间步骤上添加程序化检查（参见下图中的“Gate”），以确保流程仍在正轨上。
图：提示链工作流
何时使用此工作流： 当任务可以轻松干净地分解为固定的子任务时，此工作流非常理想。主要目标是通过使每个LLM调用成为更简单的任务来权衡延迟以获得更高的准确性。
提示链有用的示例：
- 生成营销文案，然后将其翻译成不同的语言。
- 编写文档大纲，检查大纲是否符合特定条件，然后根据大纲编写文档。
工作流：路由(Routing)
路由对输入进行分类并将其定向到专门的后续任务。此工作流允许分离关注点，并构建更专业的提示。如果没有此工作流，针对一种类型的输入进行优化可能会损害其他输入的性能。
图：路由工作流
何时使用此工作流： 路由适用于存在不同类别的复杂任务，这些类别最好单独处理，并且可以使用LLM或更传统的分类模型/算法准确地进行分类。
路由有用的示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）定向到不同的下游流程、提示和工具。
- 将简单/常见问题路由到较小的模型（如Claude 3.5 Haiku），将困难/不常见问题路由到功能更强大的模型（如Claude 3.5 Sonnet），以优化成本和速度。
工作流：并行化(Parallelization)
LLM有时可以并行处理多个任务，并以编程方式聚合它们的输出。这种工作流（并行化）体现在两个关键变体中：
- 分段(Sectioning)：将任务分解为并行运行的独立子任务。
- 投票(Voting)：多次运行同一任务以获得不同的输出。
图：并行化工作流
何时使用此工作流： 当可以将划分的子任务并行化以提高速度，或者需要多个视角或尝试以获得更高置信度的结果时，并行化是有效的。对于具有多个考虑因素的复杂任务，LLM通常在每个考虑因素由单独的LLM调用处理时表现更好，从而可以集中关注每个特定方面。
并行化有用的示例：
- 分段：
- 实现防护措施，其中一个模型实例处理用户查询，而另一个模型实例筛选不当内容或请求。这往往比让同一个LLM调用同时处理护栏和核心响应效果更好。
- 自动评估LLM性能，其中每个LLM调用评估模型在给定提示上的性能的不同方面。
- 投票：
- 审查一段代码是否存在漏洞，其中几个不同的提示会审查代码，如果发现问题则标记。
- 评估给定内容是否不当，其中多个提示评估不同的方面或需要不同的投票阈值来平衡误报和漏报。
工作流：编排器-工作者(Orchestrator-Workers)
在编排器-工作者工作流中，中央LLM动态分解任务，将它们委托给工作者LLM，并综合它们的结果。
图：编排器-工作者工作流
何时使用此工作流： 此工作流非常适合你无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量以及每个文件中更改的性质可能取决于任务）。虽然在拓扑上相似，但它与并行化工作流的关键区别在于其灵活性——子任务不是预先定义的，而是由编排器根据特定输入确定的。
编排器-工作器有用的示例：
- 每次对多个文件进行复杂更改的编码产品。
- 搜索任务涉及收集和分析来自多个来源的信息以获取可能的相关信息。
工作流：评估器-优化器(Evaluator-Optimizer)
在评估器-优化器工作流中，一个LLM调用生成响应，而另一个LLM调用提供循环评估和反馈。
图：评估器-优化器工作流
何时使用此工作流： 当我们有明确的评估标准，并且迭代改进提供可衡量的价值时，此工作流特别有效。良好匹配的两个迹象是，首先，当人类阐明他们的反馈时，LLM响应可以得到明显改善；其次，LLM可以提供此类反馈。这类似于人类作家在撰写精美文档时可能经历的迭代写作过程。
评估器-优化器有用的示例：
- 文学翻译，其中存在翻译器LLM最初可能无法捕捉到的细微差别，但评估器LLM可以提供有用的批评。
- 复杂的搜索任务，需要多轮搜索和分析才能收集全面的信息，评估器决定是否需要进一步搜索。
智能体(Agents)
随着LLM在关键功能（理解复杂输入、参与推理和规划、可靠地使用工具以及从错误中恢复）方面的成熟，智能体正在生产中出现。智能体通过人类用户的命令或交互式讨论开始其工作。一旦任务明确，智能体就会独立计划和操作，可能会返回给人类以获取更多信息或判断。在执行期间，智能体在每个步骤中从环境中获得“真实情况”（例如工具调用结果或代码执行）以评估其进度。然后，智能体可以在检查点或遇到障碍时暂停以获取人类反馈。任务通常在完成后终止，但通常也包含停止条件（例如最大迭代次数）以保持控制。
智能体可以处理复杂的任务，但它们的实现通常很简单。它们通常只是LLM在循环中根据环境反馈使用工具。因此，清晰而周到地设计工具集及其文档至关重要。我们在附录2（“提示工程你的工具”）中扩展了工具开发的最佳实践。
图：自主智能体
何时使用智能体： 智能体可用于难以或无法预测所需步骤数量的开放式问题，以及你无法硬编码固定路径的问题。LLM可能会运行多个回合，你必须对其决策制定有一定程度的信任。智能体的自主性使其成为在受信任环境中扩展任务的理想选择。
智能体的自主性意味着更高的成本，以及潜在的复合错误。我们建议在沙盒环境中进行广泛测试，并采取适当的护栏。
智能体有用的示例：
以下示例来自我们自己的实现：
图：编码智能体的高层次抽象流程
组合和定制这些模式
这些构建块不是规定性的。它们是开发人员可以塑造和组合以适应不同用例的常见模式。与任何LLM功能一样，成功的关键在于衡量性能并迭代实现。再次强调：你应该考虑仅在可以证明改进结果时才增加复杂性。
总结
LLM领域的成功不在于构建最复杂的系统。它在于构建适合你需求的系统。从简单的提示开始，通过全面的评估优化它们，并且仅在更简单的解决方案不足时才添加多步骤智能体系统。
在实施智能体时，我们尝试遵循三个核心原则：
- 在智能体的设计中保持简单性。
- 通过明确显示智能体的规划步骤来优先考虑透明度。
- 通过彻底的工具文档和测试来仔细设计你的智能体-计算机接口(ACI)。
框架可以帮助你快速入门，但在转向生产时，请毫不犹豫地减少抽象层并使用基本组件进行构建。通过遵循这些原则，你可以创建不仅强大而且可靠、可维护并受到用户信任的智能体。
致谢
本文由Erik Schluntz和Barry Zhang撰写。这项工作借鉴了我们在Anthropic构建智能体的经验以及客户分享的宝贵见解，我们对此深表感谢。
附录1：智能体的实际应用
我们与客户的合作揭示了AI智能体的两个特别有前景的应用，它们展示了上述模式的实用价值。这两个应用都说明了智能体如何为需要对话和行动、具有明确的成功标准、启用反馈循环以及集成有意义的人类监督的任务增加最大价值。
A. 客户支持
客户支持将熟悉的聊天机器人界面与通过工具集成增强的功能相结合。这非常适合更开放式的智能体，因为：
- 支持交互自然地遵循对话流程，同时需要访问外部信息和操作；
- 可以集成工具来提取客户数据、订单历史记录和知识库文章；
- 可以以编程方式处理诸如发放退款或更新工单之类的操作；以及
- 可以通过用户定义的解决方案明确衡量成功。
一些公司已经通过基于使用量的定价模型证明了这种方法的可行性，该模型仅对成功的解决方案收费，表明对他们智能体的有效性充满信心。
B. 编码智能体
软件开发领域已经显示出LLM功能的巨大潜力，其功能从代码完成发展到自主解决问题。智能体特别有效，因为：
- 代码解决方案可以通过自动化测试进行验证；
- 智能体可以使用测试结果作为反馈来迭代解决方案；
- 问题空间定义明确且结构化；以及
- 可以客观地衡量输出质量。
在我们自己的实现中，智能体现在可以根据拉取请求描述本身解决SWE-bench Verified 基准测试中的真实GitHub问题。然而，虽然自动化测试有助于验证功能，但人工审查对于确保解决方案与更广泛的系统要求保持一致仍然至关重要。
附录2：提示工程你的工具
无论你构建哪种智能体系统，工具都可能是智能体的重要组成部分。工具 使Claude能够通过在我们的API中指定其确切结构和定义来与外部服务和API交互。当Claude响应时，如果它计划调用工具，它将在API响应中包含一个工具使用块。工具定义和规范应该像你的整体提示一样受到提示工程的重视。在这个简短的附录中，我们将描述如何提示工程化你的工具。
通常有几种方法可以指定相同的操作。例如，你可以通过编写diff或重写整个文件来指定文件编辑。对于结构化输出，你可以在markdown或JSON中返回代码。在软件工程中，像这样的差异是表面上的，并且可以从一种格式无损地转换为另一种格式。然而，某些格式比其他格式更难让LLM编写。编写diff需要在编写新代码之前知道块头(chunk header)中更改的行数。在JSON中编写代码（与markdown相比）需要对换行符和引号进行额外的转义。
我们对决定工具格式的建议如下：
- 给模型足够的token来“思考”，然后再将自己逼入绝境。
- 保持格式接近模型在互联网文本中自然看到的内容。
- 确保没有格式“开销”，例如必须准确计算数千行代码，或对它编写的任何代码进行字符串转义。
一个经验法则是考虑在人机界面(HCI)上投入了多少精力，并计划在创建良好的智能体-计算机界面 (ACI) 上投入同样多的精力。以下是关于如何做到这一点的一些想法：
- 设身处地为模型着想。根据描述和参数，是否明显知道如何使用此工具，或者你是否需要仔细考虑？如果是这样，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的明确边界。
- 你如何更改参数名称或描述以使事情更明显？将其视为为你团队中的初级开发人员编写出色的文档字符串。在使用许多类似的工具时，这一点尤其重要。
- 测试模型如何使用你的工具：在我们的workbench中运行许多示例输入，以查看模型犯了哪些错误，并进行迭代。
- 防呆(Poka-yoke) 你的工具。更改参数以使其更难出错。
在为SWE-bench 构建我们的智能体时，我们实际上花了更多时间优化我们的工具而不是整体提示。例如，我们发现，在智能体移出根目录后，使用相对文件路径的工具会出现错误。为了解决这个问题，我们将工具更改为始终需要绝对文件路径——并且我们发现模型完美地使用了这种方法。
Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且，2025年将在星球首发“Go陷阱与缺陷”和“Go原理课”专栏！此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！
著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。
Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com
我的联系方式：
- 微博(暂不可用)：https://weibo.com/bigwhite20xx
- 微博2：https://weibo.com/u/6484441286
- 博客：tonybai.com
- github: https://github.com/bigwhite
- Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
- Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。
评论