先说一个核心判断：想要构建高效的AI智能体，实践经验表明，简洁的策略往往比复杂的框架更有效。

本文翻译自Anthropic近期发布的深度文章《Building effective agents》。过去一年里，我们与数十个团队合作，覆盖多个行业，共同开发基于大语言模型（LLM）的智能体系统。一个反复出现的洞察是：那些真正投入生产并稳定运行的智能体方案，没有一个是依靠复杂框架或专用库取得成功的。相反，采用简单、可组合模式的方案，效果出奇地好。

下面，我们将从这些合作经验中提炼出核心建议，帮助开发者理解如何构建真正高效的AI智能体（Agent）。

什么是智能体？

“智能体”这个词的定义堪称众说纷纭。有些团队将其理解为完全自主运行的系统，能够长时间独立工作，利用各种工具完成复杂任务；另一些团队则用它来描述更受控制的实现，基本遵循预设的工作流程。在Anthropic，我们将所有这类系统统称为智能体系统。但在架构层面，我们做了一项重要区分——这可能是全文最核心的概念之一：工作流和智能体是截然不同的两种模式。

• 工作流：LLM和工具通过预定义的代码路径编排，本质上是按照固定的“剧本”执行。
• 智能体：LLM动态地自主决定流程和工具使用，由模型自己规划如何完成任务。

理解这两者的区别，将直接影响你选择哪种构建方式。下文会详细展开。附录1还整理了客户在实际应用中发现特别有价值的两个领域，供你参考。

何时（以及何时不）使用智能体

构建LLM应用时，一个最简单却最容易被忽略的法则：先找最简单的解决方案，不要一上来就追求复杂。很多时候，你根本不需要构建智能体系统。智能体系统通常以更高的延迟和成本为代价，换取更好的任务表现——因此，必须仔细权衡这笔交易是否划算。

如果复杂度不可避免，工作流能提供可预测性和一致性，特别适合定义清晰的任务；而智能体则更适合需要灵活性和模型自主决策的场景。不过，对于许多应用来说，只需优化单次LLM调用——比如做好检索和上下文示例——就完全足够。

何时以及如何使用框架

目前市面上有不少框架能简化智能体系统的实现：例如LangChain的LangGraph、Amazon Bedrock的AI Agent框架、Rivet（拖放式GUI工作流构建器）、Vellum（另一个GUI工具）。

这些框架的优势在于，它们帮助开发者处理底层标准化操作——调用LLM、定义和解析工具、串联调用，让新手能快速上手。但问题也随之而来：它们会创建额外的抽象层，使底层提示和响应变得模糊，增加调试难度。更糟糕的是，它们可能让你在明明只需要简单设置的情况下，硬是增加了不必要的复杂性。

因此，建议从直接使用LLM API开始。许多模式其实只需几行代码就能实现。如果确实需要框架，前提是你必须真正理解底层代码——不少客户出问题，根源就在于对底层机制做了错误假设。

构建块、工作流和智能体

这一节，我们重点拆解生产环境中常见的智能体系统模式。从最基础的构建块——增强型LLM——开始，逐步向上，从简单的组合工作流直到自主智能体。

构建块：增强型LLM

智能体系统的最小单元，是经过检索、工具和记忆等能力增强后的LLM。如今的模型已经能够主动使用这些能力——比如自行生成搜索查询、选择合适的工具、决定保留哪些信息。

关键在于做好两件事：根据你的具体用例来定制这些功能；同时，确保给你的LLM提供一个简单、文档完善的接口。有多种方法可以实现这些增强，其中一种就是Anthropic最近发布的模型上下文协议（MCP），它允许开发者通过简单的客户端实现，与不断增长的第三方工具生态系统集成。

在接下来的讨论中，默认每次LLM调用都已经具备这些增强能力。

工作流：提示链

提示链的核心思路，是将任务拆解为一系列步骤，每次LLM调用都处理前一次调用的输出。你可以在任何中间步骤加入程序化检查（比如图中的“门控”），确保流程不偏离预设轨道。

何时使用： 当任务能被清晰分解成固定子任务时，特别适合。核心目的是通过让每次LLM调用变得更简单，用延迟换取更高的准确性。

适用场景：

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

工作流：路由

路由做的事情，是对输入进行分类，然后导向专门的后续任务。它的好处是实现了“关注点分离”，可以构建更专业的提示。否则，优化一种输入，就可能影响其他输入的表现。

何时使用： 适用于复杂任务，不同类别需要单独处理，且分类可以由LLM或传统分类模型准确完成。

适用场景：

• 客户服务：把一般问题、退款请求、技术支持分到不同的下游流程和工具。
• 成本优化：把简单或常见的问题路由到小模型（如Claude 3.5 Haiku），困难和罕见的问题路由到更强的模型（如Claude 3.5 Sonnet）。

工作流：并行化

LLM有时候可以同时处理一项任务，然后用程序化方式把输出聚合起来。并行化主要有两种变体：

• 分段：把任务拆成独立运行的子任务。
• 投票：多次运行同一个任务，获取多样化的输出。

何时使用： 当子任务可以并行化来提速，或者需要从多个角度、多次尝试来获得更高置信度结果时。对于复杂任务，LLM在每次考虑都由单独调用处理时，表现通常更好——它能集中精力处理某个具体方面。

适用场景：

• 分段：比如让一个模型实例处理用户查询，另一个实例筛选不当内容或请求——这比让同一个LLM调用既处理护栏又处理核心响应效果更好。再比如自动化LLM性能评估，每次调用只评估模型在某一方面的表现。
• 投票：审查代码是否存在漏洞，用几个不同提示分别审查；评估内容是否不当，用多个提示、不同投票阈值来平衡误报和漏报。

工作流：编排器-工作器

在这个工作流中，有一个中央LLM动态地分解任务，把它委派给工作器LLM，最后综合结果。注意，子任务不是预设好的，而是由编排器根据具体输入来确定——这是它与并行化的本质区别。

何时使用： 适用于复杂任务——比如编码场景，需要改哪些文件、每个文件里具体改什么，完全取决于任务描述。

适用场景：

• 每次对多个文件进行复杂更改的编码产品。
• 需要从多个来源收集和分析信息的搜索任务。

工作流：评估器-优化器

在这个工作流中，一个LLM调用负责生成响应，另一个LLM调用在循环中提供评估和反馈。效果好的前提是：有明确的评估标准，而且迭代优化能带来可衡量的价值。如果人类给出明确反馈时，LLM能显著提升响应质量，这就是一个适用信号。

何时使用： 适用于有明确标准、且迭代优化能产生显著效果的场景。

适用场景：

• 文学翻译：翻译LLM可能抓不住细微之处，但评估器LLM可以提供有用的批评。
• 复杂搜索：需要多轮搜索和分析来收集全面信息，评估器决定是否需要继续搜索。

智能体

随着LLM在理解复杂输入、推理规划、可靠使用工具、从错误中恢复等能力上的成熟，智能体开始在生产环境中崭露头角。它的工作方式如下：收到人类指令或通过对话明确任务后，独立规划和操作，过程中可能会回头找人类获取更多信息或做判断。关键在于，智能体每一步都从环境里获取“真实情况”（比如工具调用结果、代码执行结果），来评估自己进展是否正常。遇到瓶颈时，它可以暂停，等待人类反馈。任务完成后就终止，通常会设置一些停止条件（比如最大迭代次数）来保持控制。

智能体能处理复杂的任务，但实现方式其实很简单——无非就是让LLM在循环里根据环境反馈使用工具。因此，工具集的设计和文档质量，就成了重中之重。附录2专门讲了如何优化工具的提示工程。

何时使用： 适用于难以预测步骤数量、无法硬编码固定路径的开放性问题。但要注意，智能体的自主性意味着更高成本和累积错误的潜力，所以需要在沙盒环境里做广泛测试，并设置好安全护栏。

适用场景：

• 解决SWE-bench任务的编码智能体——根据任务描述对多个文件进行编辑。
• “计算机使用”智能体——让Claude像人一样操作电脑完成任务。

组合和定制这些模式

上面所有提到的构建块，都不是什么成文的规定。它们就是常见的模式，开发者可以按需组合和调整。成功的关键，还是那几样——衡量性能，然后迭代优化。再次强调：只在能显著改善结果时，才去增加复杂性。

总结

在LLM领域，成功并不在于构建最复杂的系统，而在于构建最适合你需求的系统。从简单的提示开始，用全面的评估来优化，只有当前面的方法不够用时，再考虑上多步骤的智能体系统。

总结下来，三个核心原则值得反复提醒自己：

1. 简洁性：在智能体设计中始终保持简单。
2. 透明度：让智能体的规划步骤清晰可见。
3. 良好的ACI：通过全面的工具文档和测试，精心设计智能体-计算机接口（Agent-Computer Interface）。

框架可以帮你快速入门，但进入生产环境时，别犹豫——减少抽象层，用基本组件来构建。这样出来的智能体，才能既强大又可靠，既易于维护又值得用户信任。

附录1：实践中的智能体

在合作中，我们发现了两个特别有前景的智能体应用方向，它们能充分展示上述模式的价值。这两个场景都符合一个共性：需要对话加行动、有明确的成功标准、支持反馈循环、且可以整合有意义的人工监督。

A. 客户支持

客户支持是熟悉的聊天机器人界面，加上工具集成的能力。适合用更开放的智能体，原因如下：

• 支持交互天然是对话式，同时需要访问外部信息和操作。
• 可以集成工具来拉取客户数据、订单历史、知识库文章。
• 退款、更新工单等操作可以程序化处理。
• 成功与否可以通过用户定义的解决方案清晰衡量。

已经有公司采用基于使用量的定价模式，只对成功解决的问题收费——这说明他们对智能体的有效性很有信心。

B. 编码智能体

在软件开发领域，LLM的能力已经从代码补全进化到了自主解决问题。智能体在这里特别有效：

• 代码解决方案可以通过自动化测试来验证。
• 智能体能拿测试结果做反馈，迭代优化。
• 问题空间定义清晰、结构化。
• 输出质量可以客观衡量。

在Anthropic自己的实现中，智能体已经可以仅根据拉取请求描述，解决SWE-bench Verified基准测试里的真实GitHub问题。不过，虽然自动化测试能验证功能，但人工审查仍然不可或缺——要确保解决方案符合更广泛的系统要求。

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

无论构建哪种智能体系统，工具都是关键组成部分。工具通过API中指定的结构定义，让Claude能和外部服务及API交互。当Claude响应时，如果计划调用工具，它会在API响应中包含一个工具使用块。工具定义和规范，应该像整体提示一样，投入同等的提示工程精力。

很多操作可以有多种写法：比如文件编辑，可以写diff（差异），也可以重写整个文件；结构化输出，可以放在Markdown里，也可以放在JSON里。但注意，有些格式对LLM来说，写起来要难得多——比如写diff需要知道块头中有多少行改了；写JSON需要对换行符和引号做额外转义。

关于工具格式的选择，几点建议：

• 给模型足够的令牌让它“思考”，别把自己写进死胡同。
• 保持格式接近模型在互联网上看到的自然文本。
• 避免格式化“开销”，比如需要精确计算几千行代码，或者对写的代码做字符串转义。

一个经验法则：想想你在人机交互界面（HCI）上花了多少心思，然后计划在智能体-计算机接口（ACI）上花同样的精力。具体怎么做？

• 设身处地为模型想：这个工具用起来会不会让人困惑？好的工具定义应该包含示例用法、边缘情况、输入格式要求、与其他工具的清晰边界。
• 想想怎么改参数名或描述，让模型更容易理解。这就像是在为团队里的初级开发者写一份优秀的文档字符串。
• 多测试模型怎么用你的工具：在工作台里跑各种输入，看模型犯哪些错，然后迭代。
• 对工具做防错法设计：更改参数，让模型更难犯错。

有个很典型的案例：在为SWE-bench构建智能体时，开发团队在优化工具上花的时间，比优化整体提示还多。他们发现，当智能体移出根目录后，模型在使用相对文件路径的工具时会犯错。解决方法很简单——把工具改成要求始终用绝对文件路径，模型就完美地接受了。