本文翻译自文章：《Building effective agents》(Anthropic, 2024.12.19)

翻译时，加入了一些个人色彩🙂，并做了必要的删改。

在正文开始之前，我想说一下为什么要推荐它。文章聚焦于如何构建有效的智能体（agents），没有夸大智能体的作用，当然也没有贬低，而是从经验的角度出发，提供了非常实用的建议。文中提到，过去一年，很多团队尝试利用大型语言模型（LLM）来开发智能体，而成功的案例往往有一个共同点：它们采用了简单且可组合的设计模式。这篇文章总结了这些实践经验，强调从简单入手、逐步增加复杂性的重要性，并分享了具体的工作流程和智能体设计思路。

无论你是刚刚听说智能体的新手，还是已经有一定经验的开发者，这篇文章都能为你提供启发。它不仅能帮你更高效地构建智能体，还能让你避免一些常见的错误和不必要的复杂性。希望你在阅读后能有所收获，找到适合自己的方法来提升工作效率和成果！

正文开始

在过去的一年中，我们投入了大量时间，观察多个团队如何与大型语言模型（LLM）智能体互动——这些小型软件承诺能够自动化从客户支持到编码的各种任务。我近距离观察了数十个跨行业的团队，发现了一个关键点：真正成功的团队并未依赖华丽的框架或一堆巧妙的库。他们保持简单，组合了一些基本模式，任何拥有笔记本电脑和决心的人都能实现。事实证明，复杂性往往被高估了。

本文将分享我们从自身摸索以及观察合作伙伴成功经验中学到的东西。如果你是一位希望利用 LLM 构建实用工具的开发者，这篇文章正是为你而写。没有废话，只有实用的建议。

智能体到底是什么？

“智能体”这个词常被提及，仿佛它的含义不言自明，但其实它相当难以捉摸。有人将其想象为一个完全自主的系统，能够连续运行数天，动态调用工具处理复杂混乱的任务；另一些人则认为它不过是遵循清单的美化脚本。在Anthropic，我一直在研究这些系统，我们将所有变体统称为“具有代理性质的系统”。不过，我喜欢将它们分为两类：

• 工作流：想象这是一场精心编排的舞蹈。LLM 及其工具遵循预先编码的步骤，可预测、可重复，就像工厂流水线。
• 智能体：这些更像是即兴表演者。LLM 自主决定使用哪些工具以及如何使用，掌控整个过程。

稍后，我们将在附录1（“实践中的智能体”）中给出几个现实世界的例子，展示两者的应用场景。现在，你只需知道它们处于一个从脚本化到自由发挥的光谱中，你的选择取决于你的目标。

何时使用智能体（以及何时跳过它们）

我们在使用 LLM 构建应用时的准则很简单：从最简单的方案开始。不要想得太复杂。通常，一个单一的 LLM 调用就能解决问题，或许再加点检索技巧或在提示中嵌入几个示例。智能体和工作流虽然诱人，但它们会带来延迟、成本和额外的麻烦。你需要问自己：这些代价值得吗？

如果你的任务简单且定义明确，工作流是最佳选择。它就像一辆可靠的老式皮卡车——稳定且不出意外。但如果任务需要灵活应变、快速思考并在问题复杂时扩展能力，智能体就派上用场了，这里灵活性是关键。然而，我见过太多案例，人们在简单提示调整就够用的情况下过度设计了智能体，别掉进这个陷阱。

框架：有帮助，但需谨慎

市面上有许多工具宣称能让智能体开发变得轻松，比如 LangChain 的 LangGraph 、亚马逊 Bedrock 的 AI Agent框架、Rivet 的拖放式GUI，或 Vellum 的工作流调整工具。这些工具很方便，适合快速上手，帮你处理调用 LLM、连接工具和链接组件等繁琐工作。但它们有个问题：增加了抽象层。当系统出错时，你面对的是一个黑盒，调试起来异常困难。而且，这些工具可能会诱导你在不需要时增加复杂性。

我的建议是：从基础开始，直接使用 LLM 的 API。你会惊讶于几行代码能实现多少功能，完全无需框架。如果确实要用这些工具，先弄清楚底层机制。我见过太多错误是因为开发者假设这些“魔法盒子”无需理解就能正常工作。如果你感兴趣，可以查看我们的基础示例代码，里面有最简洁的实现方式。

基础：构建块、工作流、智能体

接下来，我将分解智能体系统的核心组成部分，从基础的增强型 LLM 开始，逐步增加复杂性，从规范的工作流到自由发挥的智能体。

构建块：增强型LLM

每个具有代理性质的系统都以一个功能增强的 LLM 为核心，配备额外能力：

• 检索：从外部获取信息。
• 工具：执行操作，比如搜索或编辑文件。
• 记忆：跟踪任务进展。

我们在 Anthropic 的模型天然支持这些功能，它们能生成搜索查询、选择合适的工具并决定保留哪些信息。你的任务是确保这些附加功能适配你的问题，并为 LLM 提供清晰、有文档支持的使用方式。我们有一个名叫“模型上下文协议(MCP)”的工具，能轻松连接第三方工具，但还有其他实现方法。本文中，我们假定每次LLM调用都自带这些功能。

工作流：提示链

将任务拆分成小块，每块对应一个 LLM 调用，前一个的输出作为后一个的输入。你可以加入检查点（我们称之为“Gate”）来确保过程不偏离轨道。这比单次调用慢，但通过将每步控制在可管理范围内，能显著提高准确性。

适用场景：任务可以按顺序分解，例如先撰写营销文案再翻译，或先勾勒文档大纲、审查后再完善。

工作流：路由

这种模式类似分类处理。LLM 评估输入（比如一个客户问题），然后将其分配到合适的路径：退款问题走一条提示，技术支持走另一条。这样能保持专注，避免“一刀切”提示在半数情况下失效。

适用场景：有明确类别的复杂任务，比如客户服务（简单问题交给轻量模型如 Claude 3.5 Haiku，复杂问题交给强大模型如 Claude 3.5/3.7 Sonnet）。

工作流：并行化

多个LLM同时处理任务，之后将输出整合。有两种形式：

• 分段：将任务拆成独立部分，比如一个LLM起草代码，另一个寻找漏洞。
• 投票：多次运行同一任务，选择最佳结果或标记差异。

适用场景：需要速度，或通过冗余确保信心。例如，同时筛选查询中的不良内容和回答问题，或多次检查代码漏洞。

工作流：编排器-工作者

一个 LLM 扮演“老板”，根据输入动态制定计划并将任务分配给“工作者” LLM。比如在编码中，它决定需要调整哪些文件、如何调整，然后汇总结果。

适用场景：不可预测的任务，比如编辑大型代码库或从多源搜集信息。

工作流：评估者-优化器

一个 LLM 生成初稿，另一个对其进行批评，双方反复改进。这就像机器间的结对编程，适合有明确目标且反馈能提升质量的任务，比如优化翻译或深化搜索结果。

适用场景：目标是迭代改进，且 LLM 能有效扮演批评者角色。

智能体

现在进入深水区。智能体是完全释放的 LLM，能自主推理、规划、调用工具并修正错误。你只需给它一个指令，它便接手全部流程，每步都会根据工具结果或代码运行情况进行验证，直到完成。你可以设置暂停点供人工干预，或限制尝试次数（如“10次后停止”）以控制范围。

实现起来比听起来简单：只需 LLM、工具和一个反馈循环。关键在于工具设计——清晰、有文档支持且可靠。（详见附录2“对工具进行提示工程”）

适用场景：开放式、无法脚本化的复杂任务，比如在庞大代码库中编码，或让 Claude “使用计算机”解决问题。成本较高，错误可能累积，因此需在沙盒中彻底测试。

混合和匹配

这些模式并非固定配方，而是像乐高积木，可根据需求自由组合。关键是衡量效果并不断调整，除非复杂性确实有回报，否则不要随意增加。

总结

用 LLM 构建应用不是为了炫耀最前沿的技术，而是为了以最少麻烦解决问题。

• 从简单提示开始，调整到最佳状态，仅在简单方案不足时引入多步骤智能体。
• 当你决定放大招时，保持设计简单，明确展示计划步骤，并精心设计智能体与外部世界的交互接口。
• 框架能帮你快速起步，但到了关键时刻，别害怕抛弃它们，直接使用原始代码。

这就是全部——聪明地构建，严格测试，避免不必要的复杂化。

致谢

本文由 Erik Schluntz 和 Barry Zhang 撰写，基于我们在 Anthropic 的观察以及客户分享的宝贵经验，感谢他们的贡献。

附录1：实践中的智能体

以下是智能体大放异彩的两个场景：客户支持和编码。两者都结合了对话与行动，有明确的成功指标，且能很好地融入反馈和人工监督。

A. 客户支持

这是增强版的聊天机器人。它们能交谈、拉取数据（订单、知识库文章）并执行操作（退款、创建工单），一切在一个流程中完成。成功指标是已解决案例的数量。有些公司甚至按效果收费，只有解决问题时才计费。

B. 编码智能体

从代码自动补全到独自修复 GitHub 问题，编码智能体表现卓越。原因在于代码可测试、反馈即时且质量可衡量。我们的 SWE-bench 智能体能完美处理拉取请求，尽管人类仍需审查整体情况。

附录2：对工具进行提示工程

工具是智能体的“手”。Claude 通过我们的 API 使用工具——只要定义得当，它会在需要时自动调用。但工具设计不可马虎。例如，一个文件编辑工具可以输出差异或重写整个文件；输出格式可能是 Markdown 或 JSON。这些看似小事，但笨拙的格式会让 LLM 出错。

以下是我们针对确定工具格式给出的建议：

• 在模型把自己逼入绝境之前，给它足够的标记来“思考”。
• 使格式接近模型在互联网上的自然文本中看到的内容。
• 确保没有格式化“开销”，例如必须准确计算数千行代码的数量，或者对它编写的任何代码进行字符串转义。

有个实用的方法是，先考虑在人机交互界面（HCI）上投入了多少精力，然后计划在创建出色的智能体 - 计算机交互界面（ACI）时投入同等的精力。以下是关于如何做到这一点的一些思路：

• 站在模型角度思考——工具是否直观？添加示例、边缘情况和边界说明。
• 参数命名像在向新手解释代码。
• 反复测试——运行输入，找出问题并修复。
• 确保防错设计（绝对路径优于相对路径）。

在SWE-bench中，我们对工具的关注超过了对提示的优化。一个小调整——强制使用绝对路径——就将错误率降至零。智能体与计算机的接口和人机接口一样重要，值得投入精力。