Quartz 4

🔍 搜索

构建有效 AI Agent

7 min read

构建有效 AI Agent

原文：Building Effective Agents
来源：Anthropic Research
翻译整理：2026-06-16

核心论点

“最成功的实现方案使用的是简单、可组合的模式，而非复杂的框架。”

这是 Anthropic 在大量实践后得出的核心结论——在 Agent 设计中，简单性是一种竞争优势，而不是妥协。

两个基本概念：工作流 vs Agent

在讨论”Agent 系统”时，需要区分两类截然不同的东西：

类型定义特点
工作流（Workflow）LLM 和工具通过预定义代码路径编排流程固定，可预测，可调试
AgentLLM 动态决定流程和工具使用方式流程灵活，适应性强，更难控制

大多数生产系统实际上是工作流，而不是真正的 Agent。在不需要动态决策的场景下，使用工作流比使用 Agent 更可靠。

什么时候应该用 Agent

Agent 引入了更高的延迟和成本，只有在以下情况才值得：

  • 任务是开放式的，步骤无法预先确定
  • 需要根据环境反馈动态调整策略
  • 任务复杂度足以抵消 Agent 带来的额外成本

默认选择应该是：从最简单的方案开始，只在有充分理由时才增加复杂度。

五种核心工作流模式

模式 1：Prompt 链（Prompt Chaining）

将任务分解为顺序执行的步骤，每步之间设置程序化检查点。

输入 → [LLM 步骤 1] → 检查点 → [LLM 步骤 2] → 检查点 → [LLM 步骤 3] → 输出

适用场景：任务可以自然分解为清晰的阶段，且每阶段输出是下一阶段的输入。

模式 2：路由（Routing）

先对输入进行分类，再将其导向专门的下游处理流程。

输入 → [分类器] → 客服问题 → [客服 LLM]
                → 技术问题 → [技术 LLM]
                → 退款问题 → [退款流程]

适用场景：不同类型的输入需要明显不同的处理策略，用一个通用 LLM 处理所有类型效果差。

模式 3：并行化（Parallelization）

两种变体：

  • 并行独立子任务：将任务拆分，多个 LLM 同时处理不同部分
  • 投票共识：对同一任务运行多次，通过多数投票提高可靠性
            ┌→ [LLM 实例 A] ──┐
输入 ──────→├→ [LLM 实例 B] ──┼→ 结果聚合 → 输出
            └→ [LLM 实例 C] ──┘

适用场景：任务有多个独立子部分（并行），或对准确性要求极高、需要多数验证（投票）。

模式 4：编排者-工作者（Orchestrator-Workers）

核心 LLM 动态分解任务，分配给工作者 LLM 执行，再汇总结果。

[编排者 LLM]
  ├── 动态分解任务
  ├── 分配给 Worker A → 执行 → 返回结果
  ├── 分配给 Worker B → 执行 → 返回结果
  └── 汇总所有结果 → 最终输出

适用场景：任务结构在运行前不可知，需要动态决定子任务划分方式。

模式 5：评估者-优化者（Evaluator-Optimizer）

一个 LLM 生成输出，另一个 LLM 评估并提供反馈，形成迭代改进循环。

[生成 LLM] → 初始输出 → [评估 LLM] → 反馈 → [生成 LLM] → 改进输出 → ...

适用场景：有明确的质量标准，且初版输出通常需要迭代改进（如代码生成、文本优化）。

三条实现原则

原则 1：保持设计简洁

从最简单的方案开始，只在数据证明需要时才增加复杂度。复杂框架不等于更好结果。

原则 2：通过显式规划步骤提升透明度

让 Agent 在执行前先输出计划，使其决策过程可观察、可调试。

原则 3：像工程 API 一样工程化 ACI

ACI（Agent-Computer Interface） = Agent 与工具之间的接口。

工具文档和测试应该得到与代码同等级别的工程投入。Anthropic 在 SWE-bench 实现中，在工具优化上花费的时间超过了在 prompt 优化上的时间。

真实应用案例

客户支持 Agent

结合要素：

  • 自然对话界面（处理用户意图）
  • 工具集成（访问订单数据、执行退款等操作）
  • 多步骤问题处理能力

关键成功因素：在执行不可逆操作（如退款）前设置人工确认检查点。

代码生成 Agent

核心优势：利用自动化测试作为可靠的验证和迭代信号。

Agent 可以：生成代码 → 运行测试 → 根据测试失败信息修改代码 → 重新运行测试。这个循环可以在无需人工介入的情况下自主迭代。

工具开发最佳实践

  • 使用熟悉的格式：工具输入/输出格式应匹配互联网常见文本模式，降低 LLM 理解成本
  • 最小化格式开销：避免不必要的嵌套、冗余字段
  • 提供使用示例：描述中包含「何时用」「如何用」的具体例子
  • 大量测试：用多种输入场景测试工具，找出边缘情况
  • 防错设计（Poka-yoke）：在工具设计层面防止常见错误，而非依赖 LLM 不犯错

核心记忆点

简单 + 可组合 + 工具打磨 > 复杂框架

在 Agent 系统中，工具质量对最终性能的影响往往超过模型选择或 prompt 设计。

Graph View