什么是 Agent？
'Agent'的定义多种多样。一些客户将 Agent 视为完全自主的系统，能够在长时间内独立运行，利用各种工具来完成复杂的任务。另一些客户则用这个词来描述遵循预定义工作流程、更具规范性的实现。
在 Anthropic，我们将所有这些类型都归为 Agentic Systems，但在架构上，我们会对**工作流（Workflow）**和 Agent 做出重要的区分：
- 工作流是由预定义的编码路径来编排 LLM 和工具的系统。流程是固定的，LLM 在其中扮演特定角色。
- Agent 则是 LLM 动态指导自身流程和工具使用的系统，它们掌控着自己完成任务的方式，具有更高的自主性。
下文中，我们将详细探讨这两种 Agentic 系统。在实际应用中，理解这两者的区别对于选择合适的架构至关重要。
何时（以及何时不）使用 Agent
在使用 LLM 构建应用时，我们建议尽可能找到最简单的解决方案，只在必要时才增加复杂性。这意味着，有时甚至完全不需要构建 Agentic 系统。Agentic 系统通常会牺牲一定的延迟和成本来换取更好的任务性能，你需要仔细考虑这种权衡是否值得。
当确实需要更复杂的方案时，对于那些定义明确的任务，工作流能够提供可预测性和一致性；而当需要大规模的灵活性以及模型驱动的决策时，Agent 则是更好的选择。
不过，对于许多应用来说，通过检索增强生成（RAG）和上下文示例来优化单个 LLM 调用，通常就已经足够了。不要为了使用 Agent 而使用 Agent。
何时以及如何使用框架
有许多框架可以简化 Agentic 系统的实现，例如 LangChain 的 LangGraph、Amazon Bedrock 的 AI Agent 框架、Rivet 以及 Vellum 等。这些框架通过简化一些标准的底层任务，例如调用 LLM、定义和解析工具，以及将多个调用链接在一起，让上手变得更加容易。
然而，它们通常会引入额外的抽象层，这可能会掩盖底层的提示和响应，使得调试变得更加困难。它们还可能诱使你在原本可以用更简单设置就能搞定的情况下，添加不必要的复杂性。
我们建议开发者们一开始直接使用 LLM API：许多模式只需几行代码即可实现。如果你确实要用框架，请确保你理解了底层代码。对'引擎盖'下内容的错误假设，是客户经常犯错的一个常见原因。
构建块、工作流和 Agent
在本节中，我们将探讨在生产环境中常见的 Agentic 系统模式。我们会从最基础的构建块——增强型 LLM 开始，逐步提升复杂性，从简单的组合式工作流，到自主的 Agent。
构建块：增强型 LLM
Agentic 系统的基本构建块是经过增强的 LLM，这些增强包括检索（Retrieval）、工具（Tools）和记忆（Memory）等。我们当前的模型可以主动使用这些能力——生成它们自己的搜索查询、选择合适的工具，并决定要保留哪些信息。
我们建议重点关注实现的两个关键方面：根据你的特定用例定制这些能力，并确保它们为你的 LLM 提供一个简单、文档完善的接口。虽然实现这些增强的方法有很多，但其中一种方法是通过模型上下文协议（Model Context Protocol），该协议允许开发者通过一个简单的客户端实现与不断增长的第三方工具生态系统集成。
在本文的后续部分，我们将假设每次 LLM 调用都可以访问这些增强的能力。
工作流：提示链（Chaining）
提示链将一个任务分解成一系列步骤，其中每个 LLM 调用都处理前一个调用的输出。你可以在任何中间步骤上添加程序化的检查（参见下图中的'关卡'），以确保流程仍在正轨上。
何时使用此工作流： 当任务可以轻松、清晰地分解为固定子任务时，此工作流是理想选择。其主要目的是通过将每个 LLM 调用简化成一个更容易的任务，来用延迟换取更高准确性。
提示链适用的示例：
- 生成营销文案，然后将其翻译成不同的语言。
- 撰写文档大纲，检查大纲是否符合特定标准，然后根据大纲撰写文档。
- 数据提取：先识别实体，再分类实体，最后格式化输出。
工作流：路由（Routing）
路由将输入进行分类，并将其定向到专门的后续任务。此工作流允许分离关注点，并构建更具针对性的提示。如果没有这个工作流，针对一种类型的输入进行优化可能会损害其他类型输入的性能。
何时使用此工作流： 对于那些存在明显类别、且这些类别最好分开处理的复杂任务，以及当分类可以由 LLM 或更传统的分类模型/算法准确处理时，路由非常有效。
路由适用的示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）定向到不同的下游流程、提示和工具。
