在过去的一年里，Anthropic 与各行各业中数十个构建大型语言模型 Agents 的团队进行了合作。一致地发现，最成功的实现方案并没有使用复杂的框架或专门的库。相反，他们是使用简单、可组合的模式来构建的。
在这篇文章中，Anthropic 分享了从与客户合作以及自己构建 Agents 中学到的经验，并为开发者构建高效的 Agents 提供实用建议。
"Agent" 有几种不同的定义。一些客户将 Agents 定义为完全自主的系统，这些系统能够在较长时间内独立运行，并使用各种工具来完成复杂的任务。另一些客户则使用这个词来描述遵循预定义 Workflows 的更具规范性的实现。而 Anthropic 将所有这些变体归类为 agentic systems（智能体系统） ，但在架构上对 Workflows 和 Agents 进行了重要的区分：
Workflows 指的是通过预定义代码路径来编排 LLM 和工具的系统。
Agents 则是 LLM 动态引导自身流程和工具使用的系统，并保留对如何完成任务的控制权。
在使用 LLM 构建应用程序时，建议寻找尽可能简单的解决方案，并且仅在需要时才增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以牺牲延迟和成本为代价来换取更好的任务性能，您应该考虑这种权衡在何时是合理的。
当需要更高的复杂性时，Workflows 为明确定义的任务提供了可预测性和一致性；而当需要大规模的灵活性和模型驱动的决策时，Agents 则是更好的选择。然而，对于许多应用程序来说，通过检索和上下文示例来优化单一的 LLM 调用通常就足够了。
Rivet，一个拖放式 GUI LLM Workflow 构建器；
Vellum，另一个用于构建和测试复杂 Workflows 的 GUI 工具。
这些框架通过简化调用 LLM、定义和解析工具以及将调用链接在一起等标准的底层任务，使入门变得容易。然而，它们通常会创建额外的抽象层，这可能会掩盖底层的提示词 (prompts) 和响应，从而使调试变得更加困难。在简单的设置就足够的情况下，它们也可能诱使开发者增加不必要的复杂性。
我们建议开发者从直接使用 LLM API 开始：许多模式只需几行代码即可实现。如果您确实使用了框架，请确保您理解底层的代码。对底层机制的错误假设是导致客户使用时出现错误的常见原因。
构建 Blocks、Workflows 和 Agents
在本节中，我们将探讨在生产环境中常见的智能体系统模式。从基础构建块——增强型 LLM 开始，逐步增加复杂性，从简单的组合 Workflows 讲到自主的 Agents。
智能体系统的基本构建块是增强了检索、工具和记忆等功能的 LLM。让模型可以主动使用这些功能——生成自己的搜索查询、选择合适的工具并决定要保留哪些信息。
增强型 LLM Blocks在本文的剩余部分，我们将假设每次 LLM 调用都有权访问这些增强功能（MCP）。
提示词链将一个任务分解为一系列步骤，其中每次 LLM 调用都会处理上一次调用的输出。您可以在任何中间步骤添加编程式检查（见下图中的“gate”），以确保流程仍然按计划进行。
何时使用此 Workflow：当任务可以轻松且干净地分解为固定的子任务时，此 Workflow 是理想的选择。主要目标是通过让每次 LLM 调用成为更简单的任务，用延迟换取更高的准确性。
编写文档大纲，检查大纲是否符合特定标准，然后根据大纲编写文档。
路由对输入进行分类，并将其导向专门的后续任务。此 Workflow 允许关注点分离，并构建更专业的提示词。如果没有此 Workflow，针对一种输入的优化可能会损害对其他输入的处理性能。
路由 Workflow何时使用此 Workflow：路由非常适合复杂的任务，在这些任务中，存在明显的类别且最好分开处理，并且分类可以由 LLM 或更传统的分类模型/算法准确处理。
将不同类型的客户服务查询（一般问题、退款请求、技术支持）导向不同的下游流程、提示词和工具。
将简单/常见的问题路由到更小、更具成本效益的模型（如 Claude Haiku 4.5），并将困难/不寻常的问题路由到功能更强大的模型（如 Claude Sonnet 4.5），以优化最佳性能。
LLM 有时可以同时处理一项任务，并通过编程方式聚合其输出。这种 Workflow，即并行处理，体现在两个关键的变体中：
切片 (Sectioning)：将任务分解为独立运行的子任务。
投票 (Voting)：多次运行相同的任务以获得多样化的输出。
并行化 Workflow何时使用此 Workflow： 当划分的子任务可以并行化以提高速度时，或者当需要多个视角或尝试以获得更高置信度的结果时，并行化是有效的。对于有多个考量的复杂任务，当每一个考量都由单独的 LLM 调用处理时，LLM 通常表现更好，因为这允许它集中注意力在每一个特定的方面。
制定边界，其中一个模型实例处理用户查询，而另一个模型实例审查它们是否存在不当内容或请求。这通常比让同一个 LLM 调用同时处理护栏和核心响应表现得更好。
自动化评估 LLM 性能的 evals 工具，其中每次 LLM 调用评估模型在给定提示下表现的某个不同方面。
审查一段代码的漏洞，多套不同的提示词审查代码，发现问题则标记出来。
评估给定的内容片段是否不恰当，通过多个提示词评估不同方面或要求不同的投票阈值来平衡误报和漏报。
在编排者-工作者 Workflow 中，一个中心的编排者 LLM 会动态地分解任务，将它们委派给工作者 LLM，并综合它们的结果。
编排者-工作者 Workflow何时使用此 Workflow：此 Workflow 非常适合那些无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量以及每个文件中更改的性质可能取决于具体任务）。虽然它在拓扑结构上类似，但与并行化的关键区别在于其灵活性——因为子任务不是预先定义的，而是由编排者根据特定的输入决定的。
涉及从多个来源收集和分析信息以寻找可能相关信息的搜索任务。
在评估者-优化者 Workflow 中，一次 LLM 调用生成响应，而另一次调用则在一个循环中提供评估和反馈。
评估者-优化者 Workflow何时使用此 Workflow：当拥有明确的评估标准，并且迭代完善能够提供可衡量的价值时，此 Workflow 尤为有效。判断其是否合适的两个标志是：第一，当人类清晰表达反馈时，LLM 的响应能够得到显著改善；第二，LLM 自身能够提供这样的反馈。这类似于人类作家在撰写精美文档时可能会经历的迭代写作过程。
文学翻译，其中存在翻译 LLM 最初可能无法捕捉到的细微差别，但评估者 LLM 可以提供有用的批评建议。
需要多轮搜索和分析才能收集全面信息的复杂搜索任务，在这些任务中，由评估者决定是否需要进行进一步的搜索。
随着 LLM 在关键功能上的成熟——理解复杂输入、参与推理和规划、可靠地使用工具以及从错误中恢复——Agents 正在生产环境中崭露头角。Agents 的工作始于人类用户的命令或互动讨论。一旦任务明确，Agents 就会独立规划和运行，并有可能返回给人类以获取进一步的信息或判断。在执行期间，Agents 在每个步骤中从环境中获取“基本事实”（例如工具调用结果或代码执行结果）以评估其进度，这一点至关重要。然后，Agents 可以在检查点或遇到阻碍时暂停以获取人类反馈。任务通常在完成时终止，但为了保持控制，通常也会包含停止条件（例如最大迭代次数）。
Agents 可以处理复杂的任务，但它们的实现通常很简单。它们通常只是在循环中基于环境反馈使用工具的 LLM。因此，清晰周到地设计工具集及其文档至关重要。
自主 Agent何时使用 Agents： Agents 可用于难以或无法预测所需步骤数量，以及无法硬编码固定路径的开放式问题。LLM 可能会运行多个轮次，因此您必须对其决策有一定程度的信任。Agents 的自主性使其成为在可信环境中扩展任务的理想选择。
Agents 的自主性质意味着更高的成本，以及潜在的复合错误，强烈建议在沙盒环境中进行广泛的测试，并配备适当的任务边界。
高级编码流程 Agent这些构建块并不是规定死板的。它们是常见的模式，开发时可以对其进行塑造和组合以适应不同的用例。与任何 LLM 功能一样，成功的关键是衡量性能并对实现进行迭代。重申一遍：您只应该在复杂性能够明显改善结果时才考虑添加复杂性。
在 LLM 领域的成功并不在于构建最复杂的 Agents 系统，而在于构建适合需求的正确 的 Agents 系统。从简单的提示词开始，通过全面的评估来优化它们，只有在当简单的解决方案不足以应对时，才添加多步骤的智能体系统。
在实现 Agents 时，应该 努力遵循三个核心原则：
明确展示 Agent 的规划步骤，优先考虑
透明度。
通过全面的工具进行
文档记录和测试 ，精心打造 agent-computer 接口 (ACI)。
