构建有效的 Agent
发布日期： 2024年12月19日 作者： Erik S. 和 Barry Zhang 来源： Anthropic 工程博客
概述
作者与数十个跨行业的团队合作构建 LLM Agent。他们的关键发现是："最成功的实现使用简单、可组合的模式，而不是复杂的框架。"
什么是 Agent？
"Agent" 有多种定义。有些人将 Agent 视为完全自主的系统；另一些人则描述为遵循预定义工作流程的更具规范性的实现。Anthropic 将所有变体归类为 Agent 系统，并区分两种类型：
- 工作流程：LLM 和工具通过预定义的代码路径进行编排的系统
- Agent：LLM 动态指导自身流程和工具使用的系统，保持对如何完成任务的控制
何时（以及何时不）使用 Agent
建议是找到尽可能简单的解决方案，只在需要时增加复杂性。Agent 系统通常以延迟和成本换取更好的任务性能。工作流程为定义明确的任务提供可预测性，而 Agent 在需要灵活性和模型驱动决策的大规模场景中更有效。对于许多应用，"优化单个 LLM 调用，配合检索和上下文示例通常就足够了。"
何时以及如何使用框架
提到了几个框架：
- Claude Agent SDK
- AWS 的 Strands Agents SDK
- Rivet（拖放式 GUI LLM 工作流程构建器）
- Vellum（用于构建和测试复杂工作流程的 GUI 工具）
这些框架简化了调用 LLM、定义和解析工具以及链式调用等底层任务。然而，"它们通常会创建额外的抽象层，可能模糊底层的提示词和响应，使其更难调试。" 建议直接使用 LLM API，因为许多模式只需几行代码即可实现。
构建块、工作流程和 Agent
构建块：增强型 LLM
基本构建块是一个增强了检索、工具和记忆等功能的 LLM。当前模型可以主动使用这些能力——生成搜索查询、选择工具以及决定保留哪些信息。建议侧重于根据特定用例定制能力，并确保为 LLM 提供简单、文档完善的接口。Model Context Protocol 是集成第三方工具的一种方法。
工作流程：提示词链
提示词链将任务分解为一系列步骤，其中每个 LLM 调用处理前一个调用的输出。可以在中间步骤添加程序化检查（"门控"）。
适用场景： 适合可以清晰分解为固定子任务的任务，通过使每个 LLM 调用成为更简单的任务来以延迟换取更高准确性。
示例：
- 生成营销文案，然后翻译成另一种语言
- 编写大纲，检查是否符合标准，然后据此编写文档
工作流程：路由
路由对输入进行分类并将其引导到专门的后续任务，实现关注点分离和更专业的提示词。
适用场景： 适用于具有不同类别的复杂任务，最好分别处理，且分类可以准确完成。
示例：
- 将不同的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程
- 将简单/常见问题路由到更小、更具成本效益的模型（如 Claude Haiku 4.5），将困难/异常问题路由到更强大的模型（如 Claude Sonnet 4.5）
工作流程：并行化
LLM 可以同时处理一个任务，输出通过程序聚合。两种关键变体：
- 分段：将任务分解为独立的子任务并行运行
- 投票：多次运行同一任务以获得多样化输出
适用场景： 当子任务可以并行化以提高速度，或需要多个视角以获得更高置信度结果时有效。LLM 通常在每个考虑因素由单独调用处理时表现更好。
示例（分段）：
- 实现防护栏，其中一个模型实例处理查询，另一个筛选不当内容
- 自动化评估，每个 LLM 调用评估模型性能的不同方面
示例（投票）：
- 使用多个不同提示词审查代码漏洞
- 使用多个提示词评估内容适当性，需要不同的投票阈值
工作流程：编排器-工作者
中心 LLM 动态分解任务，委派给工作者 LLM，并综合它们的结果。
适用场景： 适合子任务无法预先确定的复杂任务。与并行化的关键区别在于灵活性——子任务不是预定义的，而是由编排器根据特定输入确定。
示例：
- 编码产品对多个文件进行复杂更改
- 搜索任务从多个来源收集和分析信息
工作流程：评估器-优化器
一个 LLM 调用生成响应，另一个在循环中提供评估和反馈。
适用场景： 当存在明确的评估标准且迭代改进提供可衡量价值时特别有效。两个适合的标志：LLM 响应通过明确的反馈得到改善，且 LLM 能够提供这种反馈。这类似于人类作家经历的迭代写作过程。
示例：
- 文学翻译，评估器 LLM 可以批评其中的细微差别
- 需要多轮搜索和分析的复杂搜索任务
Agent
随着 LLM 在关键能力上的成熟，Agent 在生产中出现：理解复杂输入、推理和规划、可靠使用工具以及从错误中恢复。Agent 从人类用户的命令或交互式讨论开始。一旦任务明确，它们独立规划和操作，可能会返回人类获取信息或判断。在执行过程中，从环境中每一步获取"真实情况"至关重要。Agent 可以在检查点或遇到阻碍时暂停以获取人类反馈，停止条件（如最大迭代次数）有助于保持控制。
Agent 实现通常很直接——"通常只是 LLM 在循环中根据环境反馈使用工具。" 清晰地设计工具集及其文档至关重要。
适用场景： 适用于所需步骤难以或无法预测、无法硬编码固定路径的开放式问题。LLM 可能会运行多个回合，需要一定程度的信任其决策能力。自主性使 Agent 成为在可信环境中扩展任务的理想选择。
自主性意味着更高的成本和错误累积的潜在风险。建议在沙箱化环境中进行大量测试，并设置适当的防护栏。
示例：
- 用于解决 SWE-bench 任务的编码 Agent，涉及根据任务描述对多个文件进行编辑
- "计算机使用"参考实现，Claude 使用计算机完成任务
组合和自定义这些模式
这些构建块不是规定性的——它们是开发者可以塑造和组合的常见模式。成功的关键是衡量性能并迭代。复杂性应该"仅在明显改善结果时"才增加。
总结
成功不在于构建最复杂的系统，而在于构建适合你需求的系统。从简单的提示词开始，通过全面评估进行优化，只在较简单的解决方案不足时才添加多步骤 Agent 系统。
实现 Agent 的三个核心原则：
- 在 Agent 设计中保持简单性
- 通过明确展示 Agent 的规划步骤来优先考虑透明性
- 通过彻底的工具文档和测试精心设计 Agent-计算机接口（ACI）
框架可以帮助快速起步，但不要犹豫减少抽象层，用基本组件构建生产系统。
附录 1：Agent 实践
两个特别有前景的应用展示了实际价值：
A. 客户支持
客户支持结合了熟悉的聊天机器人界面和通过工具集成增强的能力，使其天然适合更开放式的 Agent，因为：
- 支持交互自然遵循对话流程，同时需要访问外部信息和操作
- 工具可以拉取客户数据、订单历史和知识库文章
- 发放退款或更新工单等操作可以通过程序处理
- 成功可以通过用户定义的解决来清晰衡量
几家公司在使用按成功解决收费的定价模型证明了可行性。
B. 编码 Agent
软件开发展示了 LLM 功能的显著潜力，能力从代码补全发展到自主解决问题。Agent 特别有效，因为：
- 代码解决方案可以通过自动化测试验证
- Agent 可以使用测试结果作为反馈迭代解决方案
- 问题空间定义明确且结构化
- 输出质量可以客观衡量
Agent 现在可以在 SWE-bench Verified 基准中仅根据 Pull Request 描述解决真实的 GitHub issue。然而，人工审查对于确保解决方案符合更广泛的系统需求仍然至关重要。
附录 2：工具的提示词工程
工具使 Claude 能够通过指定其确切结构和定义来与外部服务和 API 交互。工具定义和规范应该获得与整体提示词同等的提示词工程关注。
存在几种指定相同操作的方法（例如 diff 与重写整个文件、markdown 中的代码与 JSON）。某些格式对 LLM 来说比其他格式更难编写——例如，编写 diff 需要在编写新代码之前知道块头中有多少行在变化。
决定工具格式的建议：
- 给模型足够的 Token 来"思考"，然后再把自己写进死胡同
- 保持格式接近模型在互联网文本中自然看到的格式
- 避免格式化开销，如保持数千行代码的精确计数或字符串转义代码
一个经验法则：想想在人机接口（HCI）上投入了多少精力，计划在创建良好的 Agent-计算机接口（ACI）上投入同等精力。
额外指导：
- 站在模型的角度——从描述和参数来看，如何使用工具是否显而易见？
- 考虑如何使参数名称或描述更清晰，就像为初级开发人员编写优秀的文档字符串一样
- 通过运行大量示例输入并在错误上迭代来测试模型如何使用工具
- 为工具设置防错机制——更改参数使错误更难发生
对于 SWE-bench Agent，团队"花在优化工具上的时间比优化整体提示词还多"。例如，模型在使用相对文件路径的工具上犯错，在离开根目录后。修复方法是要求绝对文件路径，之后模型完美地使用了该方法。