有效 Agent

Anthropic 在 2024 年底发布的《Building Effective Agents》中总结了一个朴素但很重要的经验：成功的 Agent 系统通常不是靠复杂框架堆出来的，而是靠简单、可组合、可测试的模式逐步搭起来的。

什么是 Agent

“Agent”这个词有很多用法。有些团队把它理解为长时间独立运行、使用多种工具完成复杂任务的自主系统；也有团队把它用来描述遵循预设流程的 LLM 应用。

Anthropic 把这些实现都归为 agentic systems，但在架构上区分两类：

  • Workflow：LLM 和工具通过预定义的代码路径被编排。
  • Agent：LLM 动态指导自己的流程和工具使用，并保持对任务完成方式的控制。

下面的模式都围绕这条分界展开：什么时候应该把控制流写进代码，什么时候才应该把更多决策交给模型。

何时使用 Agent，何时不要

构建 LLM 应用时，优先寻找能解决问题的最简单方案，只有在确实需要时才增加复杂度。很多场景并不需要 agentic system；一个优化过的 LLM 调用，加上检索和上下文示例，通常已经足够。

Agentic system 往往用更高延迟和更多成本换取更好的任务表现，所以必须判断这种交换是否值得：

  • 对于边界清晰、流程稳定的任务，Workflow 能提供更好的可预测性和一致性。
  • 对于需要大规模灵活性、步骤数不可预测、必须由模型根据中间结果决策的任务，Agent 更合适。

关键原则是：当 Workflow 就够用时，不要急着构建 Agent。

何时使用框架

很多框架可以降低 agentic system 的起步成本，例如调用 LLM、定义工具、解析工具调用、串联多步流程、搭建可视化工作流等。这些能力能帮助团队更快做出原型。

但框架也会增加抽象层。它可能隐藏真实 prompt、模型响应、工具输入输出和中间状态，让调试变难；也可能诱导团队在简单结构足够时过早引入复杂编排。

Anthropic 的建议是：尽量先理解底层 API 和基本组件。很多模式只需要少量代码就能实现。如果使用框架，也要知道框架底下真实发生了什么；对底层行为的错误假设，是很多生产问题的来源。

构建块：增强型 LLM

Agentic system 的基本构建块，是一个通过检索、工具和记忆增强的 LLM。当前模型可以主动使用这些能力：生成搜索查询、选择合适工具、决定保留哪些信息。

Agent 模式：从 Workflow 到自主 Agent 增强型 LLM (Augmented LLM) 模型 + 检索 + 工具 + 记忆 检索 工具 记忆 Workflow 模式 1. 提示链 LLM → 门控 → LLM → 门控 → LLM 顺序执行 + 验证 2. 路由 输入 → 分类器 → 处理器 分类后专门处理 3. 并行化 分段 | 投票 并发执行后聚合 4. 编排器–工作者 动态分解 + 委派 运行时确定子任务 5. 评估器–优化器 生成器 ⇄ 评估器 循环 迭代直到质量达标 自主 Agent (Autonomous Agent) 自主 Agent 循环 观察 → 决策 → 执行 → 评估 → (重复直到完成) 模型控制下一步做什么以及何时停止 来源: Anthropic — "Building Effective Agents" (2024.12)

实现增强型 LLM 时，重点是两件事：

  • 这些能力是否针对具体用例做了裁剪，比如检索范围、工具权限、记忆类型是否真的服务当前任务。
  • 这些能力是否为 LLM 提供了清晰、稳定、文档充分的接口。

后面的模式默认每次 LLM 调用都能访问这些增强能力。

Workflow：提示链

提示链把任务拆成一串顺序步骤。每次 LLM 调用处理上一步的输出；必要时，可以在中间步骤加入程序化检查，也就是 gate，确保流程仍在正确轨道上。

结构：LLM → gate → LLM → gate → LLM

何时使用：任务能被清楚拆成固定子任务，并且愿意用更高延迟换取更高准确度。拆分后的每个 LLM 调用都应该更简单、更容易完成。

例子：

  • 先生成营销文案，再翻译成另一种语言。
  • 先写文档大纲，检查大纲是否符合要求，再根据大纲写正文。

Workflow：路由

路由先对输入分类，再把它导向专门的后续任务。这样可以分离关注点，为不同类别设计更专门的 prompt、工具甚至模型。否则，为一种输入优化 prompt，可能会伤害另一种输入的表现。

结构：输入 → 分类器 → 专用处理器 A | B | C

何时使用：任务有清晰的类别，不同类别最好分开处理，并且分类本身足够可靠。分类可以由 LLM 完成，也可以由传统分类模型或算法完成。

例子：

  • 客服系统：把一般咨询、退款请求、技术支持导向不同下游流程、prompt 和工具。
  • 模型分层：简单常见问题交给成本更低的模型，困难或罕见问题交给能力更强的模型。

Workflow：并行化

并行化让多个 LLM 调用同时处理任务，然后用程序聚合结果。它有两个常见变体：

  • 分段：把任务拆成独立子任务，并行运行。
  • 投票：对同一任务运行多次，得到更多样的输出。

何时使用：子任务可以并行提速，或者需要多个视角、多次尝试来提高置信度。对于有多重考虑的复杂任务，让每个 LLM 调用专注一个方面，通常比一次调用同时处理所有要求更可靠。

例子：

  • 分段：一个模型实例处理用户问题，另一个模型实例检查不当内容或请求，用于实现 guardrails。
  • 分段：自动化 evals 时，让不同 LLM 调用分别评估模型表现的不同方面。
  • 投票：代码审查时，用多个 prompt 检查漏洞，只要任一调用发现问题就标记出来。
  • 投票：内容安全评估时，用多个 prompt 检查不同风险，并用不同投票阈值平衡误报和漏报。

Workflow：编排器-工作者

在编排器-工作者模式中，中央 LLM 动态拆解任务，把子任务委派给 worker LLM，再综合结果。

结构：输入 → 编排器 → [worker₁, worker₂, ...workerₙ] → 编排器 → 输出

何时使用：任务复杂，而且无法提前预测需要哪些子任务。它和并行化在形态上相似，但关键区别在灵活性：并行化的子任务通常预先定义好，而编排器-工作者的子任务由编排器根据具体输入动态决定。

例子：

  • 代码产品需要根据任务说明修改多个文件，每次涉及的文件数量和修改性质都不同。
  • 搜索任务需要从多个来源收集、分析可能相关的信息。

Workflow：评估器-优化器

评估器-优化器模式让一个 LLM 生成答案，另一个 LLM 在循环中评估并给出反馈。

结构：生成器 ⇄ 评估器（循环直到通过）

何时使用：有清晰的评估标准，而且迭代优化能带来可衡量的价值。两个适配信号是：人类给出反馈后，LLM 的回答确实能明显变好；同时，LLM 自己也能提供这类有用反馈。这类似人类写作者反复打磨一篇文档的过程。

例子：

  • 文学翻译：初版可能遗漏细微语气或文化含义，评估器可以给出有用批评。
  • 复杂搜索：需要多轮搜索和分析来收集完整信息，评估器判断是否还需要继续搜索。

Agent

随着模型在理解复杂输入、推理规划、可靠使用工具、从错误中恢复等方面变强，Agent 正在进入生产环境。

Agent 通常从人类用户的一条命令，或一段交互式讨论开始。任务明确后，它会独立规划和执行；必要时，也会回到人类那里请求更多信息或判断。

执行过程中，Agent 必须不断从环境获得 ground truth，例如工具调用结果、代码执行结果、用户反馈。它用这些反馈评估进展、规划下一步，并在检查点或遇到阻塞时暂停请求人类帮助。任务通常在完成时结束，但也应设置停止条件，例如最大迭代次数，来保持控制。

Agent 的实现常常很朴素：本质上就是一个 LLM 根据环境反馈，在循环中使用工具。

while not done:
    observe environment
    decide next action
    execute action via tools
    evaluate result

何时使用：问题开放、很难或不可能预测所需步骤数，也无法硬编码固定路径。LLM 可能运行很多轮，因此你必须对它的决策有一定信任。Agent 的自主性适合在可信环境中扩展任务执行。

关键风险：

  • 成本更高：开放式循环会消耗更多 token。
  • 错误可能累积：前一步错误会影响后续决策。
  • 需要充分测试：尤其要在沙箱环境中测试，并配合合适的 guardrails。

例子：

  • 代码 Agent：根据任务描述修改多个文件，解决 SWE-bench 这类任务。
  • Computer use：让 Claude 使用计算机完成任务的参考实现。

组合和定制这些模式

这些构建块不是固定模板，而是常见模式。开发者应该根据用例塑形、组合和裁剪它们。

和所有 LLM 功能一样，关键是测量表现并持续迭代。只有当复杂度能明显改善结果时，才应该增加复杂度。

总结

构建 LLM 系统的目标，不是做出最复杂的系统，而是做出满足需求的正确系统。

一个稳妥的复杂度阶梯是：

  1. 从简单 prompt 开始。
  2. 用系统化 eval 优化 prompt。
  3. 在单次调用不够时，引入多步 Workflow。
  4. 只有当 Workflow 处理不了所需灵活性时，才使用自主 Agent。

实现 Agent 时，Anthropic 强调三条原则：

  1. 保持设计简单。
  2. 优先保证透明度，明确展示 Agent 的规划步骤。
  3. 认真设计 Agent-Computer Interface，也就是工具文档和工具测试。

框架可以帮助快速起步；但进入生产时，不要害怕减少抽象层，回到更基本的组件。这样构建出来的 Agent 才更可靠、更可维护，也更容易获得用户信任。

附录 1：实践中的 Agent

Anthropic 观察到两类特别有价值的 Agent 应用。它们共同说明：Agent 最适合那些同时需要对话和行动、有清晰成功标准、能形成反馈循环、并能引入有意义人类监督的任务。

客户支持

客户支持把熟悉的聊天界面和工具集成结合起来，很适合更开放的 Agent：

  • 支持对话天然是连续交互，同时又需要访问外部信息和执行动作。
  • 工具可以拉取客户数据、订单历史和知识库文章。
  • 退款、更新工单等动作可以由程序处理。
  • 成功可以通过用户定义的解决结果来衡量。

一些公司采用按成功解决结果计费的模式，说明它们对 Agent 效果有足够信心。

代码 Agent

软件开发领域从代码补全走向自主解决问题，显示出很大的潜力。Agent 在这里特别有效，因为：

  • 代码方案可以通过自动化测试验证。
  • Agent 可以根据测试结果迭代方案。
  • 问题空间定义清晰、结构化。
  • 输出质量可以客观衡量。

自动化测试能验证功能是否正确，但人类审查仍然重要，因为它能判断方案是否符合更广泛的系统要求。

附录 2：为工具做 Prompt Engineering

无论构建哪种 agentic system，工具通常都是关键部分。工具定义和工具规格，应该像整体 prompt 一样被认真设计。

同一个动作常常有多种表达方式。比如编辑文件，可以写 diff，也可以重写整个文件；结构化输出可以放在 Markdown 代码块里，也可以放进 JSON。对软件工程师来说，这些格式差异可能只是表面差异，可以无损转换；但对 LLM 来说，有些格式明显更难写对。

例如，写 diff 需要先知道 chunk header 中有多少行会变化；把代码写进 JSON，比写进 Markdown 多了换行和引号转义负担。

选择工具格式时，可以遵循这些建议：

  • 给模型足够 token 先思考，避免它在写到一半时把自己逼进格式死角。
  • 让格式接近模型在互联网文本中自然见过的形态。
  • 避免格式开销，比如要求模型精确维护几千行代码的行数，或对大段代码做字符串转义。

Anthropic 建议像重视 HCI 一样重视 ACI：过去我们会投入大量精力设计人机接口，现在也应该投入同样精力设计 Agent-计算机接口。

具体做法包括：

  • 站在模型角度看工具：只看描述和参数，是否显而易见该怎么用？好的工具定义通常包含示例、边界情况、输入格式要求，以及与其他工具的清晰区别。
  • 调整参数名和描述，让正确用法更明显。可以把工具说明当成写给团队里初级工程师的优秀 docstring。
  • 用大量样例测试模型如何使用工具，观察它会犯什么错，然后迭代工具定义。
  • 用 poka-yoke 的思路设计工具参数，让错误更难发生。

Anthropic 在构建 SWE-bench Agent 时，花在优化工具上的时间甚至超过了整体 prompt。一个具体经验是：相对文件路径会在 Agent 离开仓库根目录后造成错误；要求工具始终使用绝对路径后，这类错误就消失了。

来源

Building Effective Agents — Anthropic, 2024.12。

这页有帮助吗？
在 GitHub 编辑