在过去一年中，Anthropic与数十个跨行业团队合作，共同构建基于大语言模型的智能体。他们发现，最成功的实现往往不是使用了复杂的框架或专用库，而是采用了简单、可组合的模式。

简单、可组合的模式优于复杂框架

在过去一年中，Anthropic与数十个跨行业团队合作，共同构建基于大语言模型的智能体。他们发现，最成功的实现往往不是使用了复杂的框架或专用库，而是采用了简单、可组合的模式。

本文将分享Anthropic从客户合作和自身构建中积累的经验，为开发者提供实用的建议。

什么是“智能体”？

“智能体”可以有多种定义方式。有些人将其定义为完全自主的系统，能够长期独立运行，使用各种工具完成复杂任务；另一些人则用它来描述更遵循预设工作流的实现。

在Anthropic，我们将所有这些变体统称为“智能体系统”，但在架构上区分两种类型：

• 工作流：通过预定义代码路径来编排LLM和工具的系统

• 智能体：LLM动态指导自身流程和工具使用的系统，保持对任务完成方式的控制

何时使(不)用智能体

在构建LLM应用时，建议寻找最简单的解决方案，只在必要时增加复杂度。这意味着有时根本不需要构建智能体系统。

智能体系统通常以延迟和成本换取更好的任务性能。当需要更高复杂度时：

工作流适合明确定义的任务，提供可预测性和一致性；

智能体则是在需要大规模灵活性和模型驱动决策时的更优选择。

对于许多应用来说，优化单次LLM调用（配合检索和上下文示例）通常已经足够。

关于框架的建议

现有许多框架可以简化智能体系统的实现，例如 Claude Agent SDK、AWS Strands Agents SDK、Rivet、Vellum 等。

这些框架通过简化底层任务（如调用LLM、定义和解析工具、链式调用）让入门变得容易。但它们也可能：

创建额外的抽象层，掩盖底层提示和响应，增加调试难度；

诱使你在简单方案足够时过度增加复杂度。

建议开发者从直接使用LLM API开始：许多模式只需几行代码即可实现。如果确实使用框架，请确保理解底层代码——对底层机制的错误假设是常见的错误来源。

构建Blocks、Workflow与Agent

这里我们探讨一些生产上常见的智能体模式，从最基础的 Block(即增强性 LLM)开始，逐渐提升复杂度，到简单的 workflow 组合，再到自主性的 Agent。

构建Block：增强型LLM

智能体系统的基本单元是增强型LLM——具备检索、工具、记忆等能力的LLM。当前模型可以主动使用这些能力：生成自己的搜索查询、选择合适的工具、决定保留哪些信息。

建议关注两个关键点：为特定用例定制这些能力，并确保为LLM提供简单、文档清晰的接口。

构建 Workflow

1.Prompt Chaining提示词链

将任务分解为一系列步骤，每个LLM调用处理前一个的输出。可在中间步骤加入程序化检查(如下图中的‘gate’)以确保流程按预期工作。

适用场景：任务可以清晰分解为固定子任务。用延迟换取更高准确度。

示例：生成营销文案后翻译成另一种语言；先写文档大纲并检查条件，再基于大纲写文档。

2.Routing路由

对输入进行分类，并导向专门化的后续任务。实现关注点分离，构建更专用的提示。

适用场景：存在不同类别的复杂任务，且分类可以准确完成。

示例：将不同类型的客服查询（一般问题、退款、技术支持）分流到不同流程；将简单问题路由到小模型（如Claude Haiku），复杂问题路由到更强大模型（如Claude Sonnet）。

3.Parallelization并行化

LLM同时处理任务，并通过程序化方式聚合输出。分为两种：

分段：将任务拆分为独立的并行子任务

投票：多次执行相同任务以获得多样化的输出

适用场景：子任务可以并行加速，或需要多角度/多次尝试以获得更高置信度结果。

示例：一个模型处理用户查询，另一个模型同时进行内容安全过滤；多个模型分别评估代码漏洞；多个提示词从不同的角度共同判断内容是否不当。

4.Orchestrator-workers编排器-工作者

中央LLM动态分解任务，委派给工作者LLM，并综合其结果。

与并行化的关键区别：子任务不是预定义的，而是由编排器根据具体输入决定。

适用场景：无法预知所需子任务的复杂任务（如编码中需要修改哪些文件、每文件改什么取决于任务）。

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

5.Evaluator-optimizer评估器-优化器

一个LLM生成响应，另一个LLM提供评估和反馈，形成循环。

适用场景：有明确的评估标准，且迭代优化能带来可衡量的价值。两个标志：LLM响应可以通过人工反馈得到明显改善；LLM能够提供这样的反馈。

示例：文学翻译中的细微之处；需要多轮搜索和分析的复杂搜索任务。

构建智能体

随着LLM在关键能力上的成熟——理解复杂输入、推理与规划、可靠使用工具、从错误中恢复——智能体开始在生产环境中涌现。

工作方式：从人类用户的指令或交互讨论开始，任务明确后，智能体自主规划并运行，必要时返回向人类索取信息或判断。执行过程中，智能体需要从环境获取“真实信息”（如工具调用结果或代码执行输出）来评估进度。可以在检查点或遇到障碍时暂停并请求人工反馈。

实现：通常很简单——就是LLM在循环中根据环境反馈使用工具。关键在于清晰、周到地设计工具集及其文档。

适用场景：开放性问题，难以或无法预测所需步骤数，无法硬编码固定路径。需要对LLM的决策有一定信任度。自主性使其非常适合在可信环境中扩展任务。

注意：自主性意味着更高的成本和潜在的复合错误。建议在沙盒环境中进行广泛测试，并设置适当的防护栏。

示例：解决SWE-bench任务的编码智能体，用于根据任务描述对多个文件进行编辑

组合与定制

这些构建块并非规定性的，而是常见模式，开发者可以根据不同用例进行塑造和组合。成功的关键在于：衡量性能，迭代实现。只有在能明显改善结果时才增加复杂度。

在LLM领域，成功不在于构建最复杂的系统，而在于为你的需求构建正确的系统。从简单提示开始，通过全面评估优化，只有在简单方案不足时才增加多步智能体系统。

实现智能体时，遵循 三条核心原则：

1.保持设计简单
2.优先考虑透明度：明确展示智能体的规划步骤
3.精心设计智能体-计算机接口（ACI）：通过详尽的工具文档和测试

框架可以帮助你快速入门，但在转向生产环境时，不要犹豫减少抽象层，用基础组件构建。遵循这些原则，你可以创建既强大又可靠、可维护且受用户信任的智能体。

实践中的智能体

A. 客户支持

客户支持结合了聊天机器人界面和工具集成能力。支持交互自然遵循对话流程，同时需要访问外部信息和执行操作（如拉取客户数据、订单历史、知识库文章，以及执行退款、更新工单等）。成功可以通过用户定义的解决方案清晰衡量。

B. 编码智能体

软件工程领域展示了LLM能力的显著潜力：

• 代码解决方案可通过自动化测试验证；
• 智能体可以利用测试结果作为反馈进行迭代；
• 问题空间定义清晰且结构化；
• 输出质量可以客观衡量。

Anthropic的智能体已能仅根据PR描述解决SWE-bench Verified中的真实GitHub问题。但请注意：自动化测试有助于验证功能，人工审查对于确保解决方案符合整体系统需求仍然至关重要。

工具的提示工程

无论构建哪种智能体系统，工具都将是重要组成部分。以下建议：

• 给模型足够的token来“思考”，避免陷入困境
• 保持格式接近模型在互联网文本中自然见过的形式
• 避免格式“开销”（如准确计数数千行代码或转义字符）

一条经验法则：思考我们在人机交互（HCI）上投入了多少精力，并计划在创造良好的智能体-计算机接口（ACI）上投入同样多的精力。

具体做法：

• 站在模型的角度思考工具描述是否清晰
• 好的工具定义通常包含示例用法、边界情况、输入格式要求以及与其他工具的清晰边界
• 测试模型如何使用你的工具：在工作台中运行大量示例输入，观察模型犯的错误，并迭代改进

对工具进行“防错设计”：修改参数使错误更难发生

例如，在构建SWE-bench智能体时，Anthropic发现模型在使用相对文件路径时会出错，于是将工具改为始终要求绝对文件路径——模型完美地使用了这一方法。

原文来自 Anthropic Engineering: Building effective agents