Agent 工作流全解析：企业级落地的几种编排模式

先泼一盆冷水

最近"多 Agent"特别火，好像不搞个几十个 Agent 互相协作，都不好意思说自己在做 AI。

但我想先泼盆冷水：绝大多数企业级场景，不需要那么复杂的多 Agent 系统，它们需要的是设计良好的 Agent 工作流（Agentic Workflow）。

这两者有什么区别？简单说——

• 多 Agent 系统：强调多个自主智能体之间的动态协商、涌现式协作，听起来很酷，但难调、难控、成本高；
• Agent 工作流：用相对固定的编排，把 LLM 的能力嵌进确定性的流程里，可控、可测、可上线。

这篇我把企业里真正在用的几种工作流模式讲清楚，以及什么时候该用哪种。

一、什么是 Agent 工作流

给个定义：

Agent 工作流，是用预先设计好的编排结构，把一个或多个 LLM 调用、工具调用串联起来，去稳定地完成一类任务。

关键词是"预先设计好的编排"。它不像全自主 Agent 那样让模型自己决定一切，而是由你这个设计者，定好流程的骨架，让 LLM 在骨架的关键节点上发挥智能。

这就像工厂的流水线 vs 一群自由发挥的工匠。流水线看着不那么"智能"，但它稳定、可预测、能规模化——这恰恰是企业最看重的。

二、五种核心编排模式

下面这五种，覆盖了我见过的绝大多数企业工作流。从简单到复杂排列。

模式一：链式（Prompt Chaining）

最基础的一种：把一个任务拆成几步，前一步的输出作为后一步的输入，顺序执行。

输入 → [步骤A] → [步骤B] → [步骤C] → 输出

比如"写一篇文章"可以拆成：拟提纲 → 写初稿 → 润色。每一步专注做好一件事，比让模型一口气写完质量更稳。

适用：任务能清晰拆成固定的几步。

模式二：路由（Routing）

先用一个分类器判断输入属于哪一类，再分发给专门的处理分支。

            ┌→ [技术问题处理]
输入 → [路由]┼→ [账务问题处理]
            └→ [投诉处理]

典型场景是智能客服：先判断用户问的是技术、账单还是投诉，再走对应的专家流程。好处是每个分支可以高度专门化，不用一个万能 prompt 应付所有情况。

适用：输入类型多样，不同类型处理方式差异大。

模式三：并行（Parallelization）

把可以同时做的子任务拆开，并行跑，最后汇总。

        ┌→ [子任务1]→┐
输入 → 拆分 [子任务2]→ 汇总 → 输出
        └→ [子任务3]→┘

比如审一份合同，可以同时跑"风险条款检查""合规性检查""格式检查"三路，最后合并报告。并行能大幅压缩耗时，前提是子任务之间没有依赖。

适用：有多个互相独立的子任务。

模式四：编排者-执行者（Orchestrator-Workers）

一个"编排者" Agent 负责拆解任务、分派给若干"执行者" Agent，再收集整合结果。

              ┌→ [执行者A]
[编排者]→ 派活 ┼→ [执行者B] → 编排者汇总
              └→ [执行者C]

它和"并行"的区别在于：子任务不是预先定死的，而是由编排者根据具体输入动态拆分。 比如让它"调研一个技术选型"，编排者会临场决定要调研哪几个方向，再分头去做。

适用：子任务无法预先固定，需要根据输入动态决定。

模式五：评估者-优化者（Evaluator-Optimizer）

一个 Agent 负责生成，另一个 Agent 负责评估打分，不合格就打回重做，循环直到达标。

[生成者]→ 产出 → [评估者]→ 不合格？→ 带反馈打回
   ↑___________________________________|
              合格 → 输出

这其实就是把"自我反思"拆成了两个角色。比如写营销文案，生成者出稿，评估者按"是否抓人、是否合规、是否符合品牌调性"打分，不行就带着具体意见退回重写。

适用：对产出质量要求高，且有明确的评估标准。

三、一张表，帮你快速选型

实战中往往是组合使用：比如先路由分流，某个分支内部再用链式，链式的某一步又用并行。别拘泥于单一模式。

四、人机协同：别让 Agent 全自动

企业落地有一条几乎是铁律的经验：关键节点一定要留人工介入点（Human-in-the-loop）。

哪些节点该留人？我的判断标准是看这一步出错的代价：

• 高代价、不可逆的操作（对外发布、资金往来、删除数据）→ 必须人工确认；
• 中等代价、可回滚（生成草稿、内部报告）→ 人工抽检；
• 低代价、可重来（中间步骤、检索）→ 全自动。

设计工作流时，把人工确认点画进流程图，而不是事后补救。好的工作流不是"全自动"，而是"该自动的自动，该把关的把关"。

五、上生产前，补齐这三件事

Demo 和生产之间的鸿沟，主要在这三块：

1. 可观测性。 工作流跑起来后，每个节点的输入输出、耗时、token 消耗都要能追溯。出了问题没有日志，你根本不知道是哪一环挂的。

2. 失败处理。 每个节点都可能失败。要明确：这一步失败了，是重试、跳过、走降级，还是整条流程中止？别让一个节点的失败拖垮全局。

3. 成本控制。 工作流节点越多，烧的 token 越多。简单节点用小模型，只在真正需要推理的节点上大模型；给整条流程设 token 预算上限。

写在最后

绕回开头那盆冷水：

大多数企业不需要炫酷的多 Agent 系统，它们需要的是一条设计良好、稳定可控的 Agent 工作流。

先用最简单的模式（链式、路由）解决问题，确实不够了再往上加复杂度。克制，是工作流设计里最被低估的美德。