Agent 模式

从增强型 LLM 到自主 Agent — Anthropic 的 Agent 系统模式分类、构建模块及适用场景

增强型 LLM (Augmented LLM)

每个 Agent 系统都从同一个构建模块开始：一个通过检索、工具和记忆增强的 LLM。模型主动生成自己的搜索查询、选择合适的工具、并决定保留哪些信息。这个增强型 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)

Workflow vs. Agent

Anthropic 在两类 Agent 系统之间划出清晰的界限：

维度WorkflowAgent
控制流预定义的代码路径编排 LLM 调用LLM 动态指导自己的流程和工具使用
可预测性高 — 相同输入遵循相同路径可变 — 模型根据上下文决定下一步
适用于结构一致的明确定义任务步骤数不可预测的开放式问题
权衡灵活性较低，可靠性更高能力更强，成本更高，错误可能累积

关键洞察：当 Workflow 就够用时，不要使用 Agent。 Workflow 为明确定义的任务提供可预测性和一致性。当需要大规模的灵活性和模型驱动的决策时，Agent 才是更好的选择。

五种 Workflow 模式

1. 提示链 (Prompt Chaining)

将任务分解为顺序步骤。每次 LLM 调用处理前一次的输出，步骤之间可选地设置编程验证门。

结构: LLM → 门控 → LLM → 门控 → LLM

适用于: 可分解为固定子任务的任务，用延迟换取更高准确度。

示例: 生成营销文案 → 验证语调 → 翻译为目标语言。

2. 路由 (Routing)

先对输入进行分类，然后将其导向专门的处理器。每个处理器可以有自己的提示词、工具，甚至模型。

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

适用于: 具有不同类别需要不同处理的复杂任务。

示例: 客户服务 — 将一般咨询、退款请求和技术问题路由到不同的专用提示词。

3. 并行化 (Parallelization)

同时运行多个 LLM 调用，然后聚合结果。两种变体：

  • 分段 (Sectioning) — 将独立子任务分配到并行调用
  • 投票 (Voting) — 对同一任务运行多次以获得多样化视角

适用于: 通过分工提速，或通过多视角提高置信度。

示例: 代码审查 — 一个调用检查安全漏洞，另一个检查性能，第三个检查风格。

4. 编排器–工作者 (Orchestrator–Workers)

中央 LLM 动态分解任务，将子任务委派给工作者 LLM，然后综合结果。与并行化不同，子任务不是预定义的 — 编排器根据具体输入确定它们。

结构: 输入 → 编排器 → [工作者₁, 工作者₂, ...工作者ₙ] → 编排器 → 输出

适用于: 无法提前预测所需子任务的复杂任务。

示例: 多文件代码修改，编排器识别哪些文件需要修改并将每个委派给工作者。

5. 评估器–优化器 (Evaluator–Optimizer)

一个 LLM 生成，另一个评估并提供反馈。循环持续直到满足质量标准。

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

适用于: 存在明确的评估标准，且迭代改进能产生可衡量的改善。

示例: 文学翻译 — 生成器产出翻译，评估器检查细微差别和文化准确性，循环改进直到双方满意。

自主 Agent (Autonomous Agent)

当没有任何结构化 Workflow 模式适合时 — 当问题是开放式的、步骤数不可预测、且没有硬编码路径可行时 — 你需要一个自主 Agent。

自主 Agent 本质上很简单：

while not done:
    观察环境（工具结果、用户反馈）
    决定下一步行动
    通过工具执行行动
    评估结果

模型掌控做什么和何时停止。它在每一步从工具结果和代码执行中获取基础事实，利用该反馈规划后续行动。

关键考量：

  • 更高成本 — 开放式循环消耗更多 token
  • 错误累积 — 每步的错误传播到后续步骤
  • 需要护栏 — 沙箱执行、权限边界和人机协作检查点

工具设计：Agent-计算机接口

工具是 Agent 的双手。糟糕的工具设计是 Agent 失败最常见的原因之一 — 不是因为模型不够智能，而是因为接口模糊不清。

设计原则

  1. 自包含描述 — 每个工具的文档字符串应精确说明何时以及如何使用它，包括边界情况和输入格式要求
  2. 最小重叠 — 如果人类工程师无法明确判断在某种情况下使用哪个工具，模型也无法判断
  3. 绝对优于相对 — 具体标识符（绝对文件路径）优于相对引用
  4. 先思考再执行 — 提供”思考” token 让模型在做出不可逆工具调用之前进行推理
  5. 格式遵循训练数据 — 保持工具输入/输出格式接近训练数据中自然出现的形式

“站在模型的角度思考。仅凭描述和参数，使用这个工具的方式是否显而易见，还是你需要仔细思考？“

何时不该构建 Agent

最重要的模式是知道何时不使用 Agent：

  1. 从单个优化的提示词开始
  2. 添加检索和上下文示例
  3. 添加工具进行外部交互
  4. 仅当单次调用方法达到上限时引入 Workflow 模式
  5. 仅当 Workflow 无法处理所需的灵活性时部署自主 Agent

“在 LLM 领域的成功不在于构建最复杂的系统。而在于构建满足需求的正确系统。”

每一层复杂性都增加了成本、延迟和失败模式。正确的 Harness 是能解决问题的最简单的那个。

来源

Building Effective Agents — Anthropic, 2024.12.

这页有帮助吗？
在 GitHub 编辑