Workflows or Agents：如何选择和构建智能体

发表于 分类于 ， 本文字数： 4.3k 阅读时长 ≈ 16 分钟
Anthropic 演讲 “How We Build Effective Agents” 总结。

概述

文章内容源自 Anthropic 团队打造高效 AI 智能体的实战经验与思考。演讲者 Barry Zhang 提炼出三大核心思想，旨在为开发者提供一个务实且高效的智能体构建框架。视频首先回顾了从单一 LLM 功能到复杂工作流，再到自主智能体的技术演进路径，阐明了智能体在能力、成本和风险上的权衡。核心论点是，构建智能体并非适用于所有场景的“万灵药”，而应被视为扩展复杂、高价值任务的特定工具。视频得出的结论是，成功的智能体构建遵循三大原则：审慎选择应用场景（不要为所有事情构建智能体）、保持架构的极致简约（保持简单），以及采用智能体的视角进行调试与优化（像你的智能体一样思考）。通过这些原则，开发者可以避免不必要的复杂性，构建出更可靠、更易于维护的智能体系统。

智能体的演进之路：从单一功能到自主系统

在深入探讨如何构建有效的智能体之前，理解我们是如何走到这一步的至关重要。AI 应用的演进大致遵循了一个清晰的路径，从简单的功能模块化，逐步发展到我们今天所讨论的、具备更高自主性的智能体系统。这个过程反映了我们对大型语言模型能力利用的深化，也揭示了不同阶段的优势与挑战。

  • 第一阶段：单一 LLM 功能。 最初，开发者们主要利用 LLM 完成一些原子性的、定义明确的任务。这些任务包括文本摘要、分类、信息提取等。在两三年前，这些功能本身就足以令人惊叹，感觉如同魔法一般。实现方式通常是 输入 -> LLM 处理 -> 输出 的直接调用模式。例如，输入一篇长文，LLM 直接返回一段精炼的摘要。这个阶段的应用简单、直接且易于控制，如今这些功能已经成为 AI 应用的“基本盘”，是许多产品的基础能力。
  • 第二阶段：工作流（Workflows）。 随着产品变得更加复杂和成熟，单一的模型调用往往不足以解决完整的业务问题。开发者们开始变得更有创造力，通过代码将多个 LLM 调用编排起来，形成一个预定义的控制流，我们称之为“工作流”。例如，一个处理用户邮件的工作流可能包含三个步骤：首先，一个 LLM 调用将邮件分类为 “紧急” 或 “非紧急”；接着，另一个 LLM 调用根据邮件内容提取关键信息；最后，第三个 LLM 调用基于这些信息起草一封回复邮件。这种模式允许开发者在成本、延迟和性能之间做出权衡。比如，在工作流的不同节点使用不同规模和成本的模型，从而在保证效果的前提下优化资源消耗。工作流本质上是 Agentic 系统的雏形，它引入了多步推理和任务分解的概念，但其路径是固定的，缺乏应对环境变化的灵活性。
  • 第三阶段：智能体。 现在，随着模型能力的进一步增强，我们进入了智能体时代。与工作流最大的不同在于，智能体拥有自主决策其行动轨迹的能力。它们不再严格遵循预设的脚本，而是可以根据环境的反馈来独立或半独立地进行操作。一个智能体的工作模式更像是一个循环：它观察环境，通过 LLM 思考下一步行动，执行行动，然后再次观察行动带来的新环境状态，并根据反馈调整后续计划。这种模式赋予了系统前所未有的自主性和能力。然而，这种自主性也带来了新的挑战：成本、延迟和错误所导致的后果都随之上升。因为智能体的行为路径不再是完全可预测的，其探索过程可能会消耗大量资源，并且一旦出错，其影响也可能更大。

总的来说，这个演进过程是从确定性到非确定性、从指令执行到自主决策的过渡。理解这一背景，有助于我们认识到智能体并非简单的技术升级，而是一种全新的范式，需要我们用不同的思维方式来设计、构建和评估。

核心理念一：不要为所有事情构建智能体

尽管智能体代表了 AI 发展的热门方向，但一个最关键的实践原则是：不要为所有事情构建智能体。将智能体视为一种可以随意替换现有工作流或功能的 “即插即用式升级” 是一种常见的误解。相反，我们应该将智能体视为一种专门用于扩展那些具有高度复杂性和高价值任务的工具。对于结构清晰、路径明确的任务，传统的工作流往往是更具成本效益和可靠性的选择。Anthropic 团队提供了一个实用的清单，帮助开发者判断一个任务是否适合构建智能体。

这个清单包含四个核心问题，构成了一个决策框架：

  1. 任务是否足够复杂？
    • 智能体在模糊和不确定的问题场景中才能真正发挥其优势。当任务的决策路径难以预先绘制成一个完整的决策树时，智能体的自主探索和推理能力就显得尤为重要。
    • 反之，如果一个任务的逻辑分支清晰，你可以轻易地用一系列 if-else 语句或固定的步骤来描述整个流程，那么明确地构建一个工作流会是更好的选择。这样做不仅成本更低，而且系统行为更可控、更易于调试。对于这类问题，强行使用智能体反而会引入不必要的复杂性和不确定性。
  2. 任务的价值是否足够高？
    • 智能体的探索和多步推理过程会消耗大量的 tokens，这意味着其运行成本相对较高。因此，任务本身必须能够证明其高成本的合理性。
    • 一个简单的衡量标准是单次任务执行的预算。如果你的预算大约在 $0.1 左右，这大概只够支持 3 万到 5 万个 tokens 的处理，这对于需要多次试错和复杂推理的智能体来说可能捉襟见肘。在这种情况下，设计一个优化的工作流来解决最常见的场景是更明智的选择。但如果任务的价值超过 1 美元，甚至更高，那么投入资源构建一个智能体来实现自动化就是值得的。例如，一个能自动完成复杂软件开发任务的智能体，其节省的工程师时间和创造的价值远超其运行成本。
  3. 任务的所有环节是否都可行？
    • 在构建智能体之前，必须对其执行任务所需的关键能力进行风险评估。你需要确保智能体能够可靠地完成其行动过程中的每一个关键步骤，避免存在明显的瓶颈。
    • 例如，如果你正在构建一个编程智能体，你需要验证它是否具备编写高质量代码、调试以及从错误中恢复的能力。如果智能体在某个核心环节上表现不佳（比如无法稳定地设置开发环境），那么整个任务链条都将中断。如果发现存在这样的瓶颈，通常的建议是缩小范围，简化任务，或者先将有瓶颈的环节剥离出来，用更可靠的方式处理，而不是寄希望于智能体能奇迹般地解决它不擅长的问题。
  4. 错误的成本有多高？
    • 这个问题直接关系到系统的可靠性和安全性。如果智能体的错误会带来高风险，且这些错误很难被发现，那么赋予它完全的自主权将是非常危险的。
    • 在这种情况下，需要设置强有力的安全防护。例如，可以限制智能体只有 “只读” 权限，或者在关键决策点加入 “人工审核（human-in-the-loop）” 环节。相反，如果任务的容错率高，错误成本低，那么就可以给予智能体更大的自主权。例如，一个用于内部文档摘要的智能体，即使偶尔出错，其后果也是可控的。

通过系统地回答这四个问题，开发者可以更理性地评估是否应该采用智能体架构，从而将资源投入到最能发挥其价值的场景中。

核心理念二：保持简单

一旦你确定了一个适合构建智能体的用例，第二个核心理念便是：在迭代过程中尽可能地保持简单。许多开发者容易陷入一个误区，即一开始就试图构建一个极其复杂的、包罗万象的智能体架构。然而，实践经验表明，任何前期的复杂性都会极大地扼杀迭代速度。一个简单、清晰的架构不仅更容易构建和调试，也能让你更快地验证核心功能，获得最高的投资回报率。

Anthropic 团队将 Agents 的核心架构简化为一个极其精炼的模型：智能体是在循环中使用工具的模型（Agents are models using tools in a loop）。这个模型可以用一段伪代码清晰地表达：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 1. 初始化环境和工具
env = Environment()
tools = Tools(env)

# 2. 定义系统提示
system_prompt = "Goals, constraints, and how to act"

# 3. 启动主循环
while True:
    # LLM 根据系统提示和当前环境状态生成行动
    action = llm.run(system_prompt + env.state)

    # 工具执行行动并更新环境状态
    env.state = tools.run(action)

这个简单的循环框架由三个基本组件构成，它们共同定义了一个智能体的行为：

  1. 环境：这是智能体操作的系统或 “世界”。它可以是一个代码仓库、一个操作系统桌面、一个数据库，或者任何智能体需要与之交互的外部实体。环境的核心是它的状态，智能体的每次行动都会改变这个状态。
  2. 工具：这是智能体与环境交互的接口。工具集定义了智能体可以执行的所有 “动作”。例如，对于一个编程智能体，工具可能包括 read_file, write_file, run_bash_command 等。对于一个操控电脑的智能体，工具可能是 click(x, y), type("text"), take_screenshot() 等。工具的设计至关重要，它直接决定了智能体的能力边界。
  3. 系统提示：这是智能体的 “大脑” 或 “行为准则”。它定义了智能体的最终目标、必须遵守的约束，以及理想的行为方式。一个好的系统提示应该清晰地告诉模型它的角色、它能使用的工具以及它应该如何思考和行动。

在这个框架下，构建智能体的过程实际上就是设计并迭代这三个核心组件。开发者应该首先聚焦于搭建这个最简化的循环，确保它能够运转起来。一旦这个基础框架搭建完成，后续的优化可以逐步进行，例如：

  • 缓存行动轨迹：对于编程或计算机使用场景，可以缓存智能体的行动序列，以降低重复任务的成本。
  • 并行工具调用：对于搜索等需要多次调用工具的场景，可以并行执行多个工具调用，以显著减少延迟。
  • 优化用户体验：思考如何向用户展示智能体的进展，以建立信任。例如，可以实时显示智能体正在执行的命令或思考过程。

可以看出，尽管这些智能体在产品形态、覆盖范围和具体能力上千差万别，但它们的底层核心框架几乎完全相同，都遵循着 “环境-工具-提示” 这个简单而强大的循环逻辑。因此，在构建智能体的初期，专注于打磨这三个基本组件，才是通往成功的捷径。

核心理念三：像你的智能体一样思考

第三个，也是最关键的一个理念，是一种思维模式的转变：像你的智能体一样思考。这是在调试和优化智能体过程中最有效的心智模型。很多开发者（包括演讲者自己）在开发时，会从自己的视角出发，当我们看到智能体犯了一些低级的错误时，常会感到困惑和沮丧 —— 毕竟这些错误在人类看来显而易见。这种困惑的根源在于我们与智能体之间存在巨大的信息差。

将自己置于智能体的上下文窗口中（Put yourself in their shoes / context window）

  • 智能体的 “失明” 体验：人类开发者在调试时拥有完整的上帝视角，我们能看到代码、环境和历史记录。但智能体在每一步决策时，它所拥有的全部世界就是其上下文窗口内的信息。它看不到屏幕，听不到声音，它所 “看到” 的仅仅是传递给 LLM 的一段文本。这包括：系统提示、可用的工具描述、以及到目前为止的对话/行动历史。
  • 一个形象的比喻：想象你是一个计算机使用智能体。你的任务是 “安装 Spotify 并以 Barry 的身份登录”。你收到的第一个输入可能只是一张静态截图和一段描述。你决定移动鼠标并点击，执行 Tool: Move(48, 53) 和 Tool: Click()。在这个工具执行和下一次截图返回给你之间的 3-5 秒内，你实际上是 “闭着眼睛” 的。你不知道点击是否成功，是否弹出了新的窗口，或者是否什么都没发生。当你 “睁开眼睛”（收到新的截图和反馈）时，你必须根据这个全新的、可能与预期完全不符的静态信息来决定下一步。这个过程充满了不确定性，就像在黑暗中使用电脑一样。

如何实践这种思维模式？

  • 审查上下文：当智能体做出错误决策时，最重要的一步是精确地重建并审查它在决策那一刻所看到的完整上下文。通常你会发现，问题并不在于模型 “不够聪明”，而在于提供给它的上下文信息存在歧义、缺失或误导性。
  • 用模型分析模型：幸运的是，我们正在构建的系统能理解我们的语言。因此，一个非常有效的调试技巧是利用模型本身来分析上下文。你可以将出问题的整个上下文（包括系统提示、工具描述和历史记录）输入给 Claude，然后向它提问：
    1. 关于系统提示：这些指令中是否有任何模糊不清的地方？
    2. 关于工具描述：你知道如何使用这个工具吗？
    3. 关于行动轨迹：你为什么做出那个选择？
  • 优化上下文信息：通过这种 “自我反思” 式的方式，你可以得到关于如何改进上下文的宝贵见解。例如，在 “操控电脑” 的智能体例子中，仅仅提供一张截图是不够的。一个更好的上下文应该包含：
    • 环境上下文：”屏幕分辨率是 1024x768”，”你将每 3-5 秒收到一张截图”。
    • 推荐行动：”你可以并且应该通过终端来安装应用”。
    • 限制条件：”你无法解决 reCAPTCHA 验证码”。
    • 这些额外的信息极大地丰富了智能体的 “认知”，帮助它做出更合理的决策。

通过把自己想象成一个只能处理有限文本信息的存在，你就能更好地理解智能体的 “思考逻辑”，从而设计出更清晰、更无歧义的上下文，从根本上提升智能体的可靠性和性能。这不仅是一种调试技巧，更是一种构建智能体的核心设计哲学。

参考

How We Build Effective Agents: Barry Zhang, Anthropic