前言：

上一篇讲了"怎么用 LangGraph 构建 Agent",这一篇回答一个更根本的问题:该不该做成 Agent? 这是 Agent 架构里最重要、也最常被跳过的决策。业界(以 Anthropic 那篇广为流传的《Building Effective Agents》为代表)给出的答案出奇一致:能用确定性工作流解决的,就别放权给 Agent。 这一篇讲清工作流的五种编排模式、Agent 该在什么时候登场,以及生产系统最常见的形态——混合架构。

一、先把两个词定义清楚

这两个词天天被混用,先钉死定义:

工作流(Workflow):LLM 和工具按预先写死的代码路径执行。哪一步调模型、哪一步调工具、顺序和分支,都是开发者定的。LLM 只负责每一步"内容"(生成、分类、翻译),不负责"流程"。

Agent:LLM 在运行时自主决定流程——下一步做什么、调哪个工具、要不要继续,由模型动态判断(第 01 篇的感知-规划-行动-观察回路)。

   工作流:流程是代码,模型只填空
   [步骤1] ──▶ [步骤2] ──▶ [步骤3]      ← 路径写死,每步内部用 LLM
   
   Agent:流程是模型现场决定的
   [LLM] ──想──▶ 调工具A? 调工具B? 结束?  ← 路径运行时才知道

关键差异一句话:工作流的行为是可预测的,Agent 的行为是涌现的。 可预测意味着好测试、好调试、成本延迟可控;涌现意味着能处理没预料到的情况,但也可能跑偏。

这不是二选一的站队,而是一根滑杆——你要为系统的每个环节选择合适的自主度。下面先看工作流一侧的五种经典模式,它们能解决的问题比多数人以为的多得多。

二、五种工作流编排模式

模式 1:Prompt Chaining(提示链)

做法:把任务拆成固定的几步,每步一次 LLM 调用,前一步的输出是后一步的输入。步骤之间可以插程序化校验(gate)。

[生成大纲] ──▶ ✓校验(字数/格式) ──▶ [按大纲写正文] ──▶ [翻译成英文]

这就是之前范式文章讲过的 Sequential 流水线的单模型版。用 Java 写不过是几次方法调用:

String outline = chat("为主题《" + topic + "》生成大纲");
if (outline.lines().count() < 3) throw new RetryException("大纲太短"); // gate
String article = chat("按此大纲写正文:\n" + outline);
String english = chat("把这篇文章翻译成英文:\n" + article);

适用:任务能清晰拆成固定子步骤,且每步比"一次干完"更简单可控。比如"先写大纲再写正文"就比"直接写一篇长文"质量稳定得多——用延迟换准确性。

为什么它常被低估:很多人觉得"这也算编排?"——但生产里 60% 的"Agent 需求"拆开看就是一条提示链。它可测试、可缓存、每步可独立优化,出问题一眼定位。

模式 2:Routing(路由)

做法:先用一次 LLM 调用(或小模型/分类器)判断输入属于哪类,再分发给专门优化过的下游处理路径。

                  ┌──▶ [退款流程]      (专用提示+工具)
  用户输入 ─[分类]─┼──▶ [技术支持流程]
                  └──▶ [闲聊直接回复]   (甚至用便宜的小模型)

适用:输入天然分成几类,且各类的最优处理方式不同。客服是最典型的例子。

它的隐藏价值是成本:分流后,简单请求走小模型、复杂请求才走大模型,这是第 20 篇"模型路由与级联"的雏形。别用一个全能大提示处理所有类型的输入——分类各个击破,每条路径的提示都能写得更短更准。

模式 3:Parallelization(并行化)

做法:把任务同时交给多个 LLM 调用,再聚合结果。两种子形态:

• 切分(Sectioning):任务拆成独立子块并行处理(如十份文档同时摘要)。
• 投票(Voting):同一任务跑多次,取多数/最优(如三次独立判断"这段代码有没有漏洞",两票以上才报警)。

  切分:[文档1]─┐                投票:[判断1]─┐
       [文档2]─┼─▶ 汇总              [判断2]─┼─▶ 多数表决
       [文档3]─┘                     [判断3]─┘

适用:切分用于子任务独立、延迟敏感的场景;投票用于对可靠性要求高于成本的判断类任务(评审、安全检查)。投票本质是用冗余对冲单次调用的随机性——不用多轮对话,只是简单重复+表决。

模式 4:Orchestrator-Workers(编排者-工人)

做法:一个中心 LLM 动态拆解任务、分发给工人 LLM、汇总结果。

等等,这不就是之前讲的 Supervisor 吗?——结构相同,但这里强调的是它和 Parallelization 的分界:并行化的子任务是预先可知的(十份文档就是十个子任务);而 Orchestrator-Workers 的子任务由模型在运行时决定(要查哪几方面的资料,看了题目才知道)。

所以它是工作流向 Agent 过渡的临界点:流程骨架还是写死的(拆解→执行→汇总三段),但"拆成什么"已经交给了模型。自主度滑杆从这里开始右移。

模式 5:Evaluator-Optimizer(评估-优化循环)   

做法:一个 LLM 生成,另一个 LLM 按标准评估并给意见,循环打磨直到达标或到轮数上限。它是五种模式里唯一带循环的,但循环的结构(生成→评估→再生成)依然是写死的——所以它仍属于工作流,不是 Agent。判断达没达标的是模型,但"达标就走、不达标就回炉"这条路是你定的。

三、什么时候才真的需要 Agent

五种工作流模式看完,你会发现能覆盖的场景相当广。那 Agent 留给什么?

Agent 适用的判据,本质上只有一条:你无法预先枚举解决路径。

具体表现为:

• 步数不可预知:修一个 bug 要几轮"改→测→再改"?看运气,写不死。
• 分支爆炸:客户问题可能涉及 20 种工具的任意组合,路由表写不完。
• 需要对中间结果做开放式反应:搜出来的资料决定下一步搜什么,无法预排。

编码 Agent 是最典型的例子:任务开放(什么 bug 都有)、步数不定、但有可靠的自动化反馈(测试跑没跑过)。最后这点极其关键——

Agent 的可行性 = 任务的开放性 × 反馈的可验证性。 只开放没反馈(比如"写一份战略报告",好坏没有客观信号),Agent 会在错误方向上自信地跑很远;既开放又有反馈(编码+测试),Agent 才真正如鱼得水。

反过来,出现这些信号就该退回工作流:流程其实只有固定几步;错误的代价高到不能接受"偶尔跑偏";延迟或成本预算紧张;需要向审计方解释每一步为什么发生。

一张决策图总结:

 任务路径能预先写出来吗?
    ├─ 能 ──▶ 用工作流(五种模式里挑)
    │         ├─ 固定几步 → Prompt Chaining
    │         ├─ 输入分几类 → Routing
    │         ├─ 子任务独立/要冗余 → Parallelization
    │         ├─ 子任务要动态拆 → Orchestrator-Workers
    │         └─ 质量要迭代打磨 → Evaluator-Optimizer
    └─ 不能 ──▶ 结果能被客观验证吗?
                ├─ 能(测试/规则/数据核对)→ 上 Agent,配好预算和护栏
                └─ 不能 ──▶ 慎重:先想办法造出验证手段,
                            或把人放进回路( interrupt)

四、混合架构:生产系统的真实形态

实际生产里,纯工作流和纯 Agent 都是少数,主流形态是"工作流骨架 + Agent 节点":整体流程用确定性结构钉死,只在真正需要开放式判断的节点放权给 Agent。

拿一个"智能运维工单系统"举例:

 工单进入
     │
  [路由] 分类:配置类 / 故障类 / 咨询类          ← 工作流:Routing
     │
     ├─ 配置类 ──▶ [提示链] 生成配置→校验→执行    ← 工作流:Chaining
     │
     ├─ 咨询类 ──▶ [RAG 问答] 直接回复           ← 工作流:单步
     │
     └─ 故障类 ──▶ ┌────────────────────┐
                   │  诊断 Agent(自主)    │      ← Agent:路径不可枚举
                   │  查日志⇄查指标⇄查变更 │        (步数不定、组合爆炸)
                   └────────┬───────────┘
                            │ 出修复方案
                   [人工审批] ✋                  ← 人在环(interrupt)
                            │
                   [提示链] 执行修复→验证→关单     ← 工作流:收尾要确定性

注意这个结构的深意:Agent 被"关"在一个笼子里——它上游有确定性的分流(只有故障类才进 Agent),下游有人工审批和确定性收尾(修复动作绝不让 Agent 直接执行)。Agent 的开放能力被用在刀刃上(诊断),而高风险环节(执行变更)牢牢握在确定性流程和人手里。

落到之前讲的 LangGraph 上,这个混合架构就是:图的骨架是工作流,其中一个节点内部是 Agent 循环——图的边(routing、审批)都是显式的,只有 diagnose 节点里模型在自主转圈。工作流和 Agent 不是两种系统,是同一张图上不同自主度的节点。

三条混合架构的设计经验:

• 入口和出口永远确定性。进入系统的分类、离开系统的执行/交付,用工作流钉死。Agent 放中间,跑偏了也出不了笼子。
• 给 Agent 节点单独设预算。最大步数、最大 token、最长耗时,超了就降级到人工——Agent 节点是系统里方差最大的部分,必须单独限流。
• 先建评估,再放权。想把某个工作流节点升级成 Agent?先给这个节点建好评估集,证明 Agent 版效果确实更好,再换。凭感觉放权是事故之源。

五、踩坑记录:编排决策上最常见的错

坑一:简单驱动架构。 "我们做了一个多 Agent 自主系统"比"我们写了个提示链"听起来性感得多,于是大量本该三步链解决的需求被做成了 Agent。评估标准只有一个:同样效果下,越简单越好。 Anthropic 的原话值得贴在墙上:找最简单的方案,只在需要时增加复杂度。

坑二:用 Agent 兜"想不清楚"。 流程想不清楚,就"让 Agent 自己看着办"——这不是架构,是弃权。Agent 不会替你想清楚业务,它只会把你的模糊放大成不可预测。想不清楚流程时,正确动作是去把流程想清楚,或先上线一个窄的工作流收集数据。

坑三:一个超级 Agent 包打天下。 把 30 个工具、10 种职责塞给一个 Agent,让它什么都能干——结果什么都干不稳。该拆的时候拆:横向拆成路由+专门路径,纵向拆成骨架+Agent 节点。

坑四:路由类别设计得含糊。 Routing 模式的效果上限取决于类别定义。类别之间有重叠("咨询"和"投诉"边界模糊)、或者没有兜底类别("其他"),分类器就会摇摆。类别要互斥、有兜底,且给分类 LLM 的每个类别都配清晰描述和例子

坑五:投票模式用同一个提示跑三遍。 温度不为零时结果确有差异,但偏差方向是相关的——同一个提示的三次输出会犯同一类错。要多样性就真的做出多样性:不同措辞、不同视角、甚至不同模型,否则投票只是自我安慰。

六、小结

这一篇核心就一句:自主度是成本,不是卖点——按需购买。 五种工作流模式(Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer)覆盖了大部分场景;Agent 只在"路径不可枚举且结果可验证"时才真正值回票价;而生产系统的常态是混合架构——确定性的骨架,把 Agent 关进笼子,好钢用在刀刃上。