Anthropic 构建高效 AI Agent —— 实用的模式与指南

TL;DR

Anthropic 发布了一份指南，总结了构建基于 LLM 的 Agent 一年的经验，表明简单的、可组合的模式——增强型 LLM、提示词链、路由、并行化、编排者-工作者、评估者-优化者以及自主 Agent——优于沉重的框架，并就何时使用每种模式以及如何设计工具提供了具体建议。

什么才算作“Agent”？

Agent 是指 LLM 能够动态决定调用哪些工具以及如何按顺序执行操作，并对整个过程保持控制权的系统。相比之下，workflow（工作流）遵循固定的代码路径来编排 LLM 调用和工具。这种区别构成了指南的其余部分。

何时采用 Agentic 系统

  • 从简单开始：优先使用带有检索和上下文示例的单次 LLM 调用。只有在能够证明可以改善结果时，才增加复杂度。
  • 权衡意识：Agent 会增加延迟和成本，但对于开放式问题，它们可以提升任务性能。
  • 在模式之间进行选择：
    • Workflows → 对定义明确的任务进行可预测、一致的处理。
    • Agents → 实现大规模、模型驱动的灵活决策。

框架 vs. 直接使用 API

  • 热门 SDK（Claude Agent SDK, Strands Agents SDK, Rivet, Vellum）通过抽象 LLM 调用、工具解析和链式调用来降低准入门槛。
  • 注意：抽象可能会隐藏提示词和响应，使得调试变得更加困难，并鼓励不必要的复杂度。
  • 建议：从原始 LLM API 开始；如果使用框架，请保持对底层代码的可视性。

核心构建模块：增强型 LLM

一个 augmented LLM（增强型 LLM）将基础模型与检索、工具使用和记忆相结合。Anthropic 的模型可以生成搜索查询、选择工具并决定保留哪些内容。Model Context Protocol 为集成第三方工具提供了标准的客户端实现。

常见的 Workflow 模式

1. Prompt chaining

  • 定义：将任务分解为连续的 LLM 调用，并可选择性地插入程序化门控。
  • 何时使用：固定子任务，且准确率的提升优于增加的延迟。
  • 示例：生成营销文案 → 翻译；大纲 → 验证 → 编写完整文档。

2. Routing

  • 定义：Clasify（分类）输入并将其分发到专门的下游提示词或工具。
  • 何时使用：具有不同类别且能从定制化处理中获益的任务。
  • 示例：将客户服务查询路由到不同的处理器；将简单问题发送给 Claude Haiku 4.5，将难题发送给 Claude Sonnet 4.5。

3. Parallelization

  • 变体：
    • Sectioning – 将独立的子任务拆分并并发运行。
    • Voting – 多次运行相同的提示词以收集多样化的答案。
  • 何时使用：通过并发获得速度提升，或通过多角度视角获得更高的置信度。
  • 示例：护栏（Guardrails）机制（使用单独的模型进行安全筛选）；使用多个提示词进行代码漏洞审查；内容审核投票。

4. Orchestrator-workers

  • 定义：一个中央 LLM 动态地将问题分解为子任务，并委派给工作者 LLM，然后合成结果。
  • 何时使用：复杂、不可预测的任务，例如无法预定义子任务的情况（例如：多文件代码更改、多源搜索）。

5. Evaluator-optimizer

  • 定义：一个 LLM 生成输出；第二个 LLM 评估并提供反馈，形成一个迭代优化循环。
  • 何时使用：存在明确的评估标准，且迭代改进能带来可测量的价值。
  • 示例：文学翻译（带有细致的评论）；多轮搜索（评估者决定是否需要进一步探测）。

Autonomous agents

  • 生命周期：接收命令或交互式提示词 → 计划 → 在循环中执行工具调用 → 可选地暂停以获取人类反馈 → 在完成或达到最大迭代次数限制后终止。
  • 关键要求：
    1. 具有清晰文档的工具集（参见附录 2）。
    2. 在每次工具调用后从环境中获得 Ground-truth（基准真相）反馈。
    3. 使用护栏（Guardrails）和沙盒测试来减轻累积误差。
  • 何时使用：对于步骤数不可预测的开放式问题，且可以接受对模型决策的能力的信任度时使用。
  • 现实世界示例：
    • 通过编辑多个文件来解决 SWE-bench 任务的编程 Agent。
    • “Computer use” 演示，其中 Claude 控制桌面以完成用户指定的目标。

组合与定制模式

所呈现的模式是 building blocks（构建模块），而非严格的配方。开发者应该：

  • 在每个阶段测量性能。

  • 增加复杂度仅在它能带来可测量的改进时。

  • 迭代提示词、工具定义和编排逻辑。

可靠 Agent 的核心原则

  1. Simplicity – 保持 Agent 的设计极简。
  2. Transparency – 在日志中公开计划步骤和工具调用。
  3. Tool engineering – 投入精力进行清晰、文档齐全的工具接口设计（参见附录 2）。

Appendix 1 – Agents in practice (summary)

  • 客户支持：对话流结合工具集成（例如：获取订单数据、办理退款）可以实现可测量的解决率指标。
  • 编程 Agent：自动化测试提供客观验证；Agent 通过测试反馈进行迭代，以解决真实的 GitHub issues。

Appendix 2 – Prompt engineering your tools

  • 设计提示：
    • 为模型提供足够的 tokens 以便在必须输出工具调用之前进行思考。
    • 使用模型熟悉的格式（例如：使用纯代码而非重度转义的 JSON）。
    • 避免不必要的格式化开销（例如：不进行行数统计、最小化转义）。
  • 人机交互思维：将工具规范（tool specs）视为开发者文档字符串（docstrings）——包含示例、边缘情况和清晰的参数名称。
  • 测试：在 Anthropic 的 workbench 中运行大量示例，以发现误用模式。
  • Poka-yoke（防错设计）：通过结构化参数来使模型难以出错。
  • 案例研究：在 SWE-bench Agent 中将相对路径切换为绝对路径，消除了路径解析错误。

Final takeaway

使用 LLM Agent 的成功关键不在于构建最复杂的架构，而在于选择正确的可组合模式，严格测试工具接口，并仅在能够证明可以改善结果时才增加复杂度。

Sources

相关