跳到主要内容

Agent 和 Workflow 的边界，我现在更倾向怎么划

· 阅读需 5 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-14 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

过去几个月，几乎所有做 AI 应用的人都会碰到一个问题：这件事到底应该设计成 Agent，还是设计成 Workflow？一开始我对这个边界也没有特别强的判断，很多场景看起来都“可以上 Agent”，因为它听起来更灵活、更聪明、更接近用户对 AI 的想象。

但做过几轮之后，我反而越来越保守。我现在更倾向于把 Workflow 当成默认选项，把 Agent 当成例外选项。不是因为 Agent 没价值，而是因为大多数业务流程真正需要的不是自由发挥，而是稳定、可解释、可观测、可回退。

换句话说，Agent 的价值在于处理不确定性；Workflow 的价值在于约束不确定性。真正的设计重点，不是二选一，而是先判断你的业务到底更怕哪一种东西。

为什么我越来越倾向“Workflow 优先”​

很多业务流程表面复杂，但本质路径其实很明确。它们可能有很多步骤、很多状态、很多接口，但并不意味着每一步都需要模型自己规划。

例如：

  • 工单流转
  • 审批推进
  • 表单补全
  • 知识问答后的人工转派
  • 内容生成后的审核发布

这些场景真正困难的地方，往往不是“下一步做什么”，而是：

  • 每一步有没有执行成功
  • 哪一步失败了
  • 谁应该接管
  • 是否可以回滚

这些都更适合 Workflow。

Workflow 的好处在于，它让流程结构清楚可见：

  • 步骤是什么
  • 输入输出是什么
  • 成功条件是什么
  • 失败后的动作是什么

只要业务有明显的主路径，我都会优先把它表达成 Workflow，而不是把规划权一开始就交给 Agent。

那 Agent 什么时候才真的有价值​

Agent 真正有价值的场景，通常满足下面几个特征：

1. 任务路径本身不固定​

系统需要根据上下文动态决定接下来做什么，而不是简单地顺着预定义步骤往下走。

2. 工具选择有明显开放性​

不是“必须按 A → B → C”，而是可能需要在多种工具能力之间做判断。

3. 任务目标比步骤更稳定​

也就是说，你知道最终想达成什么，但中间怎么走并不固定。

4. 允许一定试错​

如果每一次错误调用代价都很高，那让 Agent 自由探索通常不是好主意。

所以在我看来，Agent 更适合：

  • 多工具检索与综合分析
  • 需要多轮试探的信息搜集
  • 辅助规划和建议生成
  • 复杂但低风险的任务拆解

而不适合一上来就接管高风险主流程。

一个很实用的判断标准​

如果我今天要判断一个场景是 Agent 还是 Workflow，我会先问四个问题：

1. 路径是不是大体已知​

如果已知，优先 Workflow。

2. 每一步是不是都能定义明确成功条件​

如果能，优先 Workflow。

3. 任务中间是否必须让系统自主探索​

如果必须，Agent 才更有价值。

4. 出错代价能不能承受​

如果不能承受，就不要轻易把高自由度交出去。

这四个问题能帮我避免“因为 Agent 听起来更先进，所以默认想上 Agent”的冲动。

我更喜欢的一种组合方式​

现在我最喜欢的其实不是“纯 Agent”或“纯 Workflow”，而是下面这种组合：

  • 外层用 Workflow 控制主路径。
  • 局部节点允许 Agent 自主处理。

例如一个知识处理流程可以这样拆：

  1. 接收用户请求。
  2. 做权限校验。
  3. 进入“信息搜集”节点。
  4. 在这个节点里允许 Agent 调用多个工具搜集资料。
  5. Agent 返回结构化结果。
  6. Workflow 再决定是继续、转人工还是结束。

这种方式的好处是，系统把“自由度”压缩在局部，而不是把整个链路都交给 Agent。

为什么这条边界对工程特别重要​

如果边界划错，后面最先崩的通常不是模型效果，而是系统治理。

把应该做成 Workflow 的场景做成 Agent，常见后果是：

  • 行为不可预测
  • 日志很难读
  • 重试逻辑混乱
  • 幂等难做
  • 权限边界不清

把应该给 Agent 一点自由度的场景强行做成纯 Workflow，也会出问题：

  • 规则越来越多
  • 例外分支越来越复杂
  • 维护成本不断上涨
  • 用户一换问法就容易失败

所以边界问题本质上不是“技术风格选择”，而是系统复杂度管理。

一个简单示意​

async function handleTask(input) {
  const normalized = normalizeInput(input)
  const allowed = await checkPermission(normalized.userId)
  if (!allowed) return deny()

  const gathered = await agentCollectContext(normalized)
  if (!gathered.ok) return handoffToHuman()

  return runWorkflow([
    'validate',
    'compose',
    'review_or_publish'
  ], gathered.data)
}

这里最关键的不是代码本身，而是边界：

  • Agent 负责搜集和综合
  • Workflow 负责控制主流程

这比“所有事情都交给 Agent”更接近我现在的偏好。

总结​

我现在更倾向的划法很简单：能定义主路径的，先做 Workflow；只有在任务本身确实需要动态探索和工具选择时，才把一部分自由度交给 Agent。

Agent 的价值在于处理开放性，Workflow 的价值在于管理稳定性。真正成熟的 AI 系统，往往不是在两者之间二选一，而是清楚知道哪一层该自由，哪一层必须被约束。