필사 모드: 构建高效的 AI 智能体 — 五种工作流模式与智能体参考指南

• 引言 — 工作流、智能体，以及增强型 LLM
• 五种工作流模式
• 自主智能体 — 循环，以及何时动用它
• 失败模式 — 过度设计、失控循环、成本与延迟
• 框架 — 快速起步，调试的代价
• 结语 — 简单·透明·ACI
• 参考资料

引言 — 工作流、智能体，以及增强型 LLM

在“智能体”一词不断被滥用、含义膨胀的当下，Anthropic 的工程指南 Building Effective Agents 却难得地从一个冷静的定义讲起。本文是把这份文档整理成可在实务中随时翻阅的参考。核心的区分只有一个。

• 工作流（workflow）。 指 LLM 与工具由人预先设定的代码路径（“predefined code paths”，Anthropic）来编排的系统。流程由开发者固定。
• 智能体（agent）。 指 LLM 自行动态地指挥自身流程与工具使用、掌握“如何完成任务”这一控制权的系统。流程由模型在运行时决定。

在这两者之上，有一条贯穿全文的建议：不要去造最精巧的系统，而要造 契合需求的正确系统。文档主张从简单的提示开始，用全面的评估来打磨，只有当更简单的方案不够用时，才加入多步骤的智能体系统。

所有模式的最底层，都是 增强型 LLM（augmented LLM）。它不是一个只会吐出文本的模型，而是叠加了三种能力的模型。

• 检索（retrieval）。 自行生成检索查询，拉取所需的信息。
• 工具（tools）。 挑选契合情境的工具，对外部系统采取实际行动。
• 记忆（memory）。 判断该保留什么、该丢弃什么，并交接给下一步。

工具集成推荐通过 Model Context Protocol (MCP) 这类标准来接入。这个模块就是下面所有模式的原子单元。

五种工作流模式

首先要记住一点：下面这五种全都是 工作流。哪怕 LLM 调用出现很多次，它们的顺序和连接方式也由代码固定。自主智能体会在下一节里单独讨论。

上表用于快速查阅，每种模式实际如何运转，下面再各补一行。

• 提示链。 把任务拆成顺序步骤，每次 LLM 调用都以上一步的输出作为输入。在步骤之间设置程序化的关卡（格式·条件检查），防止出错的输出泄漏到下一步。延迟会增加，但每次调用只专注于一件事，因此准确率提升。
• 路由。 先对输入分类，再送往专用的提示或模型。关注点得以分离，可按路径分别优化，也避免了把所有情况硬塞进一个提示时出现的质量下降。
• 并行化。 分段把彼此独立的子任务同时运行以降低延迟，投票则把同一输入运行多次再汇总结果（多数表决·共识）。就像把回答生成与安全检查分开的护栏那样，当某些事情混在一次调用里会互相干扰时，把它们拆开尤其有用。
• 编排者-工作者。 中央 LLM 在运行时把问题拆成子任务、委派给工作者，再综合结果。子任务的数量和形态由模型而非代码决定，这正是它与并行化的决定性区别，因此这一模式站在工作流与智能体的边界上。
• 评估者-优化者。 一个 LLM 生成草稿，另一个 LLM 给出评估与反馈，如此往复循环。只有当存在明确的评估标准、且反复迭代确实能改进结果时才划算 — 标准一旦模糊，循环就只是在烧钱。

最后，这五种并不互斥。实际的系统通常会把它们叠加使用 — 在路由之后接一段提示链，或者让编排者的工作者在内部调用并行化。模式是乐高积木，不是宗教信仰。

自主智能体 — 循环，以及何时动用它

自主智能体看起来很炫，但实现通常很简单。借用 Anthropic 的说法，智能体更接近于 一个在循环中、基于环境反馈使用工具的 LLM。它在每一步获得工具结果或代码执行结果这样的“事实依据（ground truth）”，据此自行判断进展。

智能体循环（概念）
  1. 人给出目标 (或通过对话收窄范围)
  2. LLM 制定计划并调用工具
  3. 环境返回结果   = 事实依据
  4. LLM 查看结果并判断: 完成了吗? 否则回到 2 反复
  5. 停止条件: 完成判定 · 步数预算 · 人工检查点

这里的关键就是事实依据。把智能体与普通聊天机器人区分开的，是它用每一步来自环境的真实信号 — 工具是否成功、代码是否通过 — 来校正自己的判断。没有这个反馈闭环，它就只是一个被多次调用的提示而已。

何时用智能体取代工作流。 如果任务定义清晰、且可预测性与一致性很重要，那么工作流更好。只有当无法预测所需的步骤数、也无法把固定路径硬编码下来时，智能体才真正划算。但这是有代价的 — 文档明确指出，智能体“用延迟和成本换取更好的任务性能（trade latency and cost for better task performance）”。只有在这笔交换说得通的时刻，才该动用它。快速判断清单：

• 能否事先勾勒出步骤数与路径 → 能，就用工作流。
• 对同一输入，一致且可复现的结果是否重要 → 用工作流。
• 所需的工具和步骤是否因输入而异、无法预测 → 用智能体。
• 增加的延迟和成本能否用性能提升来证明其合理 → 不能的话，就暂缓使用智能体。

ACI 占了一半。 智能体的成败在很大程度上取决于工具设计。Anthropic 把它称为智能体-计算机接口（agent-computer interface，ACI），并强调要像给人编写 API 文档那样，为模型清晰地记录并测试工具。含糊的 schema 和敷衍的工具说明，是智能体失败最常见的根本原因。

文档的附录举出智能体特别契合的两个领域。客户支持要顺着对话流程走，同时需要外部信息与行动（查询·退款等），而且能以成功解决的数量清晰地衡量成效 — 一些公司甚至自信到采用只对成功解决计费的按量付费模式。

编程尤其契合，因为答案可以用自动化测试来验证。智能体把测试结果当作反馈来迭代，Anthropic 举了在 SWE-bench Verified 上仅凭 PR 描述就解决真实 GitHub issue 的例子。不过，答案是否符合更大系统的要求，依然需要人来审查。

失败模式 — 过度设计、失控循环、成本与延迟

一份参考要真正有用，就不能只画出顺利的图景，还得记下经常出问题的地方。

• 过度设计与过早引入框架。 开局第一手就搬出笨重的智能体框架，是最常见的失误。文档警告说，框架虽让起步变容易，却会加上一层遮蔽底层提示与响应的抽象，使调试变难。请从直接使用 LLM API 起步，复杂性“只在它能明显改善结果时（only when it demonstrably improves outcomes）”才添加。
• 失控的循环。 智能体本质上是循环，没有停止条件的话，就会重复同样的错误，烧掉 token 和成本。务必加入步数上限、超时和人工检查点。把计划步骤外显出来的 透明性，能及早发现这类失控。
• 成本与延迟。 每一步都是一次额外的 LLM 调用。多智能体或投票会成倍地消耗 token。请先测量它是否真的落在面向用户的延迟预算之内 — 性能再高，响应太慢就没法用在产品里。
• 放任工具设计。 如果不像对待提示那样用心对待前面说的 ACI，再好的模型也会在设计糟糕的工具面前不知所措。
• 跳过评估。 一边堆上智能体的复杂性，一边却不去衡量它是否真的比简单的基线更好。文档的处方很明确 — 用全面的评估打磨简单的提示，只在更简单的方案不够用时才添加复杂性。

框架 — 快速起步，调试的代价

文档正面讨论了智能体框架。像 Claude Agent SDK 这样的 SDK，或 Rivet·Vellum 这样的 GUI 构建器，都能降低上手的门槛，但也有代价 — 它们加上一层遮蔽底层提示与响应的抽象，让人难以看清究竟什么进入了模型、什么又从中输出，从而使调试变得复杂。

因此建议很朴素：先直接使用 LLM API 把底层弄明白，等清楚那层抽象究竟替你做了什么，再引入框架。这并不是说框架不好，而是说：在不了解底层的情况下叠上去的便利，一旦出问题反而会拖你后腿。

结语 — 简单·透明·ACI

用文档提出的智能体实现三条核心原则来收尾。

• 简单。 保持设计简单，复杂性只在结果明显变好时才添加。
• 透明。 不要隐藏智能体的计划步骤，而要显式地展示出来。
• ACI。 通过充分的工具文档化与测试，用心打造智能体-计算机接口。

这篇文章留给实务的教训很朴素。大多数生产环境的问题，用单次 LLM 调用或一两个工作流模式就足以解决。真正需要自主智能体的时刻比想象中更少，而承认这种“少”的判断本身，就是好的工程。归根结底，成功不在于建造最精巧的系统，而在于挑选契合需求的正确系统 — 这一句话，就是这份参考的要旨。

参考资料

• Anthropic — Building Effective Agents（工程指南，原文）
• Anthropic Cookbook — patterns/agents（五种模式的最小实现代码）
• Model Context Protocol — Introduction（工具集成标准）