大多数团队一开始并不需要智能体。

他们需要的是一个可靠的系统：能够使用模型、调用少量工具，并在不引入不必要的不确定性的情况下完成边界明确的任务。

这一区别很重要，因为如今几乎所有将大语言模型（LLM）与工具结合的应用都可能被称为 智能体（agent）。但从架构角度看，工作流与智能体之间存在重要差异。

工作流（workflow） 的执行路径主要由代码预先定义。模型可以进行分类、生成、提取，或在有限的选项中做出选择，但执行步骤的顺序仍由应用程序控制。

智能体（agent） 则对执行顺序拥有更大的决策权。它能够检查当前状态、决定下一步操作、选择工具、重复执行步骤、从失败中恢复，并在认为目标已经完成时停止。

Anthropic 也做出了类似的区分：工作流按照预定义的编排路径执行，而智能体则动态地决定自身的执行过程和工具使用方式。OpenAI 的智能体文档同样将运行时建立在一个迭代循环之上，涵盖模型决策、工具执行、状态管理和停止条件。

实践中真正需要回答的问题，并不是哪种架构听起来更先进，而是 模型究竟需要多大的决策权。

架构的自主性阶梯

可以把 AI 系统看作一个自主程度逐级提高的阶梯。

  1. 单次模型调用 —— 一次输入，一次输出。
  2. 确定性工作流 —— 执行步骤固定，模型调用嵌入其中。
  3. 动态工作流 —— 部分路由或任务分解由模型驱动，但应用程序代码仍然约束整个过程。
  4. 智能体 —— 模型反复决定下一步行动，直到达到目标、遇到阻碍或触发停止条件。

每提高一级，都可能增加灵活性，但也可能带来更高的延迟、成本、可观测性要求，以及更多的故障模式。

因此，默认的工程策略应当很简单：从能够可靠解决任务的最低自主性级别开始。

何时工作流是更好的架构

当任务的大部分执行过程在开始前就已知时，应选择工作流。

文档处理就是一个很好的例子：

  • 对文档进行分类；
  • 提取必需字段；
  • 验证输出；
  • 将异常情况转交审核；
  • 存储结果。

模型仍然可以在多个阶段发挥作用，但应用程序已经知道这些阶段分别是什么。

当你需要以下能力时，工作流尤其合适：

  • 可预测的执行路径；
  • 稳定的延迟；
  • 有明确上限的成本；
  • 各步骤之间的显式验证；
  • 较强的可审计性；
  • 简便的重试机制；
  • 明确的故障状态责任归属。

有几种非常实用的模式符合这一架构。

提示链（Prompt chaining）

一次模型调用生成的中间结果成为下一步骤的输入。当复杂任务能够被清晰地拆分，且每一步都能单独验证时，这种模式很有用。

路由（Routing）

分类器从已知的后续处理路径中选择一条。客户支持是常见例子：账单问题、账户访问、技术故障和滥用举报，可以分别进入专门的处理流程。

并行化（Parallelization）

彼此独立的子任务同时运行，随后合并结果。当任务能够拆分，且每个执行单元不需要了解其他执行单元的中间结果时，这种模式效果很好。

评估器—优化器循环（Evaluator-optimizer loops）

一个模型生成答案，另一个模型依据明确的标准进行评估。循环可以持续到达到质量阈值，或耗尽预设的最大尝试次数。

这些模式看起来可能很复杂，但它们仍然属于工作流，因为应用程序依然定义着运行结构。

何时有理由使用智能体

当关键执行步骤 无法在事先完整指定 时，智能体才开始体现价值。

考虑这样一项编程任务：

找出这次生产环境回归问题的根本原因，以最小且安全的改动修复它，运行相关测试，并解释发生了哪些变化。

系统可能需要：

  • 根据发现的问题检查不同的文件；
  • 搜索日志；
  • 选择要运行的测试；
  • 在测试失败后修正假设；
  • 编辑一个或多个文件；
  • 在执行高风险操作前停止并请求批准。

执行开始时，确切路径尚未确定。固定工作流可以尝试将所有分支都编码进去，但到了某个程度，它就会变成对模型本可直接完成的决策过程进行手工编写的模仿。

当任务具备以下四个特点时，智能体最能发挥优势：

  1. 目标清晰，但实现路径尚不明确。
  2. 环境能够在每次操作后提供反馈。
  3. 模型具有能够检查或改变该环境的实用工具。
  4. 应用程序能够对智能体允许执行的操作施加硬性边界。

最后一点至关重要。没有边界的自主性并不是架构优势，而是一种运营风险。

实用决策对照表

问题 优先选择工作流 优先选择智能体
执行步骤是否事先已知？ 通常是 通常不是
模型是否需要反复选择下一步行动？ 很少需要 需要
可预测的延迟是否重要？ 非常适合 更难保证
每次运行的成本是否受到严格限制？ 更容易控制 更难控制
环境能否在每次操作后提供有用反馈？ 有帮助 必不可少
是否需要很强的可复现性？ 非常适合 需要更多控制措施
能否通过权限和停止条件限制故障影响？ 仍然重要 强制要求
任务在不同案例间是否有很大差异？ 可能变得脆弱 更适合

不必要的智能体带来的隐性成本

最大的错误，并不是在本该使用智能体时选择了工作流，而是在工作流已经能够解决问题时仍然构建智能体。

智能体会引入额外的工程要求：

  • 工具权限；
  • 状态管理；
  • 循环终止机制；
  • 重试策略；
  • 审批检查点；
  • 执行追踪；
  • 对多步骤执行轨迹的评估；
  • 中间操作只部分成功时的恢复机制。

单次模型调用可以通过比较输入和输出来评估。多步骤智能体则往往必须作为一条执行轨迹来评估：它观察到了什么、做出了什么决定、调用了哪些工具、环境发生了什么变化，以及最终状态是否真正正确。

这就是为什么智能体的可靠性不只是模型质量问题，更是一个 系统工程问题。

混合架构往往是正确答案

这并不是一个非此即彼的选择。

可靠的生产系统通常会在一个有明确边界的智能体外围使用确定性工作流。

例如：

  1. 验证请求；
  2. 对风险进行分类；
  3. 创建沙箱；
  4. 让智能体在沙箱内解决任务；
  5. 运行确定性检查；
  6. 对敏感操作要求批准；
  7. 持久化保存结果和审计轨迹。

工作流控制系统边界。智能体负责处理那些执行路径确实会动态变化的部分。

这种结构将自主性限制在能够创造价值的地方，同时避免让模型拥有周边所有环节的控制权。

添加智能体循环前要回答的五个问题

在实现智能体之前，先回答以下问题：

1. 哪项决策无法通过普通应用逻辑可靠地编码？

如果你无法指出这项决策，那么你可能根本不需要智能体。

2. 系统在每次操作后能够观察到什么真实依据？

智能体需要反馈。测试结果、API 响应、文件状态、数据库查询结果、浏览器状态和人工批准，都能提供证据，帮助判断是否取得了真正的进展。

3. 智能体所需的最大权限是什么？

如果任务只需要三个工具，就不要开放十个。如果只读权限已经足够，就不要授予写入权限。对于不可逆操作，没有审批检查点就不应允许执行。

4. 本次运行如何停止？

在投入生产前，定义成功条件、迭代次数上限、预算限制、超时机制和升级处理路径。

5. 如何评估整条执行轨迹？

不要只衡量最终答案。还应跟踪工具选择、不必要的步骤、重试次数、延迟、Token 用量、成本、人工干预，以及任务是否完成。

设计原则

工作流优化的是 控制能力。

智能体优化的是 适应能力。

大多数生产系统都需要两者，但所需的比例并不相同。

如果任务有稳定的执行路径，就把这条路径编码下来。如果任务需要在运行时探索，就让模型做出那些确实无法预先确定的决策。然后用确定性检查、权限、可观测性和停止条件为这种自主性建立边界。

目标不是构建自主性最强的系统。

目标是构建 能够可靠解决实际问题、同时自主性最低的系统。

参考资料