在与数十个跨行业的团队合作开发大语言模型（LLM）智能体后。我们发现最成功的实现方案都采用了简单、可组合的模式，而非复杂的框架。

在过去一年中，我们与数十个跨行业的团队合作构建大语言模型（LLM）智能体。那些最成功的实现方案始终没有依赖复杂的框架或专用库，而是采用简单、可组合的模式进行构建。

在本文中，我们将分享从客户合作及自身智能体开发实践中获得的经验，并为开发者提供构建高效智能体的实用建议。

什么是智能体？

“智能体”可以有多种定义。一些客户将其定义为能够长期独立运行、利用各种工具完成复杂任务的完全自主系统；另一些客户则用该术语描述遵循预定义工作流的、更具指令性的实现方式。在 Anthropic，我们将这些不同形式统称为“智能体系统”，但在架构上对“工作流”和“智能体”做出重要区分：
• 工作流是指通过预定义代码路径协调大语言模型与工具的系统。
• 智能体则是指由大语言模型动态主导自身流程与工具使用、自主掌控任务执行方式的系统。

下文将详细探讨这两类智能体系统。在附录1（《实践中的智能体》）中，我们描述了两个客户在其中显著受益于这类系统的应用领域。

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

在使用大语言模型构建应用时，我们建议尽可能采用最简单的解决方案，仅在必要时才增加复杂性。这意味着有时甚至完全不需要构建智能体系统。智能体系统通常以更高的延迟和成本换取更优的任务表现，因此你应仔细评估这种权衡是否值得。

当确实需要更高复杂度时，对于定义明确的任务，工作流能提供可预测性和一致性；而当需要大规模的灵活性和模型驱动的决策能力时，智能体则是更优选择。然而，对许多应用场景而言，通过检索增强和上下文示例优化单次大语言模型调用通常已足够。

何时以及如何使用框架

目前有许多框架可简化智能体系统的实现，包括：
• Claude 智能体 SDK；
• AWS 的 Strands Agents SDK；
• Rivet，一款支持拖拽操作的图形化 LLM 工作流构建工具；
• Vellum，另一款用于构建和测试复杂工作流的图形化工具。

这些框架通过简化调用 LLM、定义与解析工具、串联调用等标准底层任务，帮助开发者快速上手。但它们往往引入额外的抽象层，可能掩盖底层提示词（prompt）与响应，使调试变得更加困难。此外，它们还容易诱使开发者在简单方案已足够的情况下过度增加系统复杂度。

建议开发者先直接使用 LLM API：许多模式只需几行代码即可实现。如果确实使用框架，请务必理解其底层代码逻辑。对框架内部机制做出错误假设，是客户常见问题的重要根源。

本节将探讨在生产环境中观察到的智能体系统常见模式。本文将从基础构建模块——增强型 LLM 出发，逐步提升复杂度，从简单的组合式工作流过渡到自主智能体。

构建模块：增强型 LLM

智能体系统的基本构建模块是一种经过增强的大语言模型，其增强能力包括检索、工具调用和记忆功能。我们当前的模型能够主动运用这些能力——自行生成搜索查询、选择合适的工具，并决定保留哪些信息。

增强型 LLM

建议重点关注实现中的两个关键方面：一是根据你的具体用例定制这些能力，二是确保它们为你的大语言模型提供一个简单且文档完善的接口。尽管实现这些增强功能的方式多种多样，但其中一种方法是通过我们近期发布的“模型上下文协议”（Model Context Protocol），该协议允许开发者通过简单的客户端实现，与不断扩展的第三方工具生态系统集成。

在本文后续部分，我们将默认每次大语言模型调用均可访问上述增强能力。

工作流：提示词链式调用（Prompt Chaining）

提示词链式调用将一项任务拆解为一系列步骤，其中每次大语言模型调用都处理前一次调用的输出结果。你可以在任意中间步骤加入程序化检查（见下图中的“门控”/“gate”），以确保整个流程仍在正确轨道上运行。

何时使用此工作流：当任务可以轻松且清晰地拆分为固定的子任务时，这种工作流尤为理想。其主要目标是通过让每次大语言模型调用处理更简单的任务，以牺牲一定延迟为代价换取更高的准确性。

提示词链式调用的典型应用场景包括：

• 先生成营销文案，再将其翻译成另一种语言；
• 先撰写文档提纲，检查提纲是否满足特定标准，再基于该提纲撰写完整文档。

工作流：路由（Routing）

路由机制会对输入进行分类，并将其导向专门的后续任务。这种工作流有助于实现关注点分离，并构建更具针对性的提示词。若不采用路由机制，在优化某一类输入表现的同时，可能会损害对其他类型输入的处理效果。

The routing workflow

何时使用此工作流：当面对复杂任务，且存在明显可区分的类别、各需独立处理，同时分类本身可通过大语言模型或更传统的分类模型/算法准确完成时，路由机制效果显著。

路由的典型应用场景包括：

• 将不同类型的客户服务请求（如一般咨询、退款申请、技术支持）分别引导至不同的下游流程、提示词和工具；
• 将简单或常见的问题路由至成本更低、效率更高的小型模型（如 Claude Haiku 4.5），而将复杂或罕见的问题交由能力更强的模型（如 Claude Sonnet 4.5）处理，以在性能与成本之间取得最佳平衡。

工作流：并行化（Parallelization）

大语言模型有时可同时处理同一任务的不同部分，其输出再通过程序化方式聚合。这种并行化工作流主要有两种关键变体：

• 分段处理（Sectioning）：将任务拆分为多个相互独立的子任务，并行执行；
• 投票机制（Voting）：多次执行相同任务，以获得多样化的输出结果。

The parallelization workflow

何时使用此工作流：当拆分后的子任务可并行执行以提升速度，或当需要多个视角或多次尝试以提高结果置信度时，并行化非常有效。对于涉及多重考量因素的复杂任务，通常让每个因素由单独的大语言模型调用处理，使模型能集中注意力于特定方面，从而获得更优表现。

并行化的典型应用场景包括：

分段处理：

• 实施安全护栏（guardrails）：一个模型实例处理用户查询，另一个同时筛查内容是否包含不当请求或敏感信息。这种方式通常优于让单次 LLM 调用同时承担核心响应与安全审查双重职责。
• 自动化评估 LLM 性能：每次 LLM 调用评估模型在给定提示下表现的某一特定维度。

投票机制：

• 审查一段代码是否存在漏洞：多个不同提示分别审查代码，一旦发现潜在问题即予以标记；
• 判断某段内容是否不当：多个提示从不同角度进行评估，或设置不同的投票阈值，以在误报（false positives）与漏报（false negatives）之间取得平衡。

工作流：协调器-工作者（Orchestrator-Workers）

在协调器-工作者工作流中，一个中心大语言模型（LLM）会动态地分解任务，将其委派给多个工作者 LLM，并综合它们的输出结果。

The orchestrator-workers workflow

何时使用此工作流：该工作流适用于那些无法预先确定所需子任务的复杂场景（例如在编程任务中，需要修改的文件数量及每个文件的具体变更内容通常取决于具体任务）。尽管其拓扑结构与并行化类似，但关键区别在于其灵活性——子任务并非预先定义，而是由协调器根据具体输入动态决定。

协调器-工作者的典型应用场景包括：

• 每次操作均需对多个文件进行复杂修改的编程类产品；
• 需从多个来源收集并分析信息以识别潜在相关内容的搜索任务。

评估器-优化器（Evaluator-Optimizer）

在评估器-优化器工作流中，一次 LLM 调用生成初始响应，另一次 LLM 调用则在循环中提供评估与反馈，以迭代优化结果。

The evaluator-optimizer workflow

何时使用此工作流：当具备清晰的评估标准，且通过迭代优化能带来可衡量的价值时，该工作流尤为有效。判断其适用性的两个关键信号是：第一，当人类明确表达反馈意见时，LLM 的输出确实能得到显著改进；第二，LLM 本身能够提供此类反馈。这类似于人类作者在打磨一篇精炼文章时所经历的反复修改过程。

评估器-优化器的典型应用场景包括：

• 文学翻译任务，其中译者 LLM 可能最初未能捕捉某些细微语义，而评估器 LLM 能提供有价值的批评建议；
• 需要多轮搜索与分析才能全面收集信息的复杂搜索任务，由评估器判断是否有必要继续执行后续搜索。

Agents（智能体）

随着大语言模型（LLM）在理解复杂输入、进行推理与规划、可靠使用工具以及从错误中恢复等关键能力上的不断成熟，智能体（Agents）正逐步进入生产应用阶段。智能体的工作通常始于用户下达的指令，或与用户进行交互式讨论。一旦任务目标明确，智能体便会自主制定计划并独立执行，必要时可返回向人类用户请求更多信息或判断。在执行过程中，智能体必须在每一步都从环境中获取“真实反馈”（例如工具调用结果或代码执行输出），以评估自身进展。随后，智能体可在预设检查点或遇到障碍时暂停，等待人工反馈。任务通常在完成后终止，但也常设置停止条件（如最大迭代次数）以保持对流程的控制。

智能体能够处理高度复杂的任务，但其实现方式往往相当简洁——通常只是大语言模型在一个循环中根据环境反馈调用工具。因此，清晰且深思熟虑地设计工具集及其文档至关重要。在附录2（《为你的工具进行提示工程》）中进一步阐述了工具开发的最佳实践。

Autonomous agent

何时使用智能体：当面对开放式问题，即难以甚至无法预知所需步骤数量，且无法硬编码固定执行路径时，智能体尤为适用。此时，大语言模型可能需要进行多轮操作，你必须对其决策能力具备一定程度的信任。正是这种自主性，使智能体非常适合在可信环境中规模化执行任务。

然而，智能体的自主性也意味着更高的成本和错误累积的风险。我们建议在沙盒环境中进行充分测试，并部署适当的安全护栏（guardrails）。

智能体的典型应用场景包括（以下示例来自我们自身的实现）：

• 一个用于解决 SWE-bench 任务的编程智能体，该任务要求根据任务描述对多个文件进行修改；
• 我们的“计算机使用”参考实现，其中 Claude 直接操作计算机完成各类任务

High-level flow of a coding agent（编程智能体的高层流程）

组合与定制这些模式

上述构建模块并非强制性规范，而是开发者可根据不同用例灵活调整和组合的常见模式。与任何 LLM 功能一样，成功的关键在于衡量性能并持续迭代实现方案。再次强调：只有在新增的复杂度能明确带来效果提升时，才应考虑引入它。

总结

在大语言模型（LLM）领域取得成功，并不在于构建最复杂的系统，而在于构建最适合你需求的系统。从简单的提示词开始，通过全面的评估对其进行优化，仅在更简单方案无法满足要求时，才引入多步骤的智能体系统。

在实现智能体时，我们力求遵循三项核心原则：

• 保持智能体设计的简洁性；
• 通过明确展示智能体的规划步骤来优先保障透明度；
• 通过详尽的工具文档和充分测试，精心设计智能体与计算机的交互接口（Agent-Computer Interface, ACI）。

框架虽能帮助你快速起步，但在迈向生产环境时，不要犹豫减少抽象层级，转而使用基础组件进行构建。遵循这些原则，你将能够打造出不仅强大，而且可靠、可维护并赢得用户信任的智能体。

附录1：智能体在实践中的应用

我们与客户的合作揭示了两类尤为有前景的人工智能智能体应用场景，充分体现了前文所述模式的实际价值。这两个场景均表明，当任务同时涉及对话与操作、具备明确的成功标准、支持反馈循环，并能融入有意义的人类监督时，智能体最能创造价值。

A.客户支持

客户支持将人们熟悉的聊天机器人界面与通过工具集成实现的增强能力相结合。这种场景天然适合更开放式的智能体，原因如下：

• 支持交互本身具有自然的对话流程，同时需要访问外部信息并执行操作；
• 可集成工具以获取客户数据、订单历史和知识库文章；
• 退款发放或工单更新等操作可通过程序化方式处理；
• 成功与否可通过用户定义的解决结果清晰衡量。

多家公司已通过按使用效果计费的定价模型（仅对成功解决的问题收费）验证了该方法的可行性，体现出对其智能体效能的信心。

B.编程智能体

在软件开发领域，大语言模型功能展现出非凡潜力——其能力已从代码补全演进至自主解决问题。智能体在此场景中尤为高效，原因在于：

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

在我们自身的实现中，智能体现在仅凭拉取请求（pull request）描述，即可在 SWE-bench Verified 基准测试中解决真实的 GitHub 问题。然而，尽管自动化测试有助于验证功能正确性，人类审查对于确保解决方案符合更广泛的系统需求仍然至关重要。

附录2：为你的工具进行提示工程

无论你构建何种智能体系统，工具很可能都是其中的关键组成部分。工具使 Claude 能够通过在 API 中明确定义其结构和行为，与外部服务及 API 进行交互。当 Claude 决定调用某个工具时，其 API 响应中会包含一个工具调用（tool use）区块。工具的定义与规范应获得与整体提示词同等程度的提示工程关注。在本简短附录中，我们将说明如何对工具进行提示工程设计。

同一操作通常有多种表达方式。例如，你可以通过生成 diff（差异补丁）来指定文件修改，也可以直接重写整个文件；对于结构化输出，你可以将代码放在 Markdown 中，也可以放在 JSON 中。在软件工程中，这类差异往往是形式上的，可无损地相互转换。然而，对大语言模型而言，某些格式远比其他格式更难生成。例如，编写 diff 需要在写出新代码之前就确定代码块头中更改的行数；而在 JSON 中（而非 Markdown）嵌入代码则需要额外转义换行符和引号。

工具格式选择的建议如下：

• 为模型预留足够的 token 用于“思考”，避免过早陷入格式约束；
• 尽量采用模型在互联网文本中常见、自然出现的格式；
• 确保没有不必要的格式“开销”，例如要求精确统计数千行代码，或对所生成的代码进行复杂的字符串转义。

一个经验法则是：思考人类在人机交互（HCI）上投入了多少精力，并计划在构建优质的智能体-计算机接口（Agent-Computer Interface, ACI）上投入同等努力。以下是一些具体建议：

• 设身处地站在模型的角度思考：仅凭工具描述和参数，使用方式是否一目了然？还是需要仔细推敲？如果是后者，模型很可能也会遇到同样困难。优秀的工具定义通常包含使用示例、边界情况、输入格式要求，以及与其他工具的清晰区分。
• 如何调整参数名称或描述，使其更加直观？可将其视为为团队中的初级开发者撰写一份出色的文档字符串（docstring）。当你使用多个相似工具时，这一点尤为重要。
• 测试模型如何使用你的工具：在我们的 Workbench 中运行大量示例输入，观察模型常犯哪些错误，并持续迭代优化。
• 对工具进行“防错设计”（Poka-yoke）：调整参数设计，使错误更难发生。

在为 SWE-bench 构建智能体时，我们实际上花在工具优化上的时间超过了整体提示词的设计。例如，我们发现当智能体离开根目录后，使用相对路径的工具容易出错。为此，我们将工具修改为始终要求绝对路径——结果发现模型使用这一方式时表现完美无瑕。

文章原文地址https://zhilianwx.com/ai/125.html