目录

当我们谈论 Agent 工作流时，我们在谈论什么？

回望这一路，从最初迷信“一个超级 Prompt 解决一切”，到后来被现实狠狠打脸，再到如今沉下心来研究 Agent Workflow，我们的心路历程其实是每一个 AI 工程师的缩影。

起初，我们都以为 LLM 是那个无所不能的神。直到我们在生产环境中遇到了那些“神”也搞不定的瞬间：偶尔的幻觉、处理复杂逻辑时的顾此失彼、以及那令人抓狂的不稳定性。

这时候，我们才深刻意识到：在大模型应用落地的战场上，没有银弹，只有取舍。 而 Agent Workflow（智能体工作流），就是我们用来做取舍的工具箱。

今天，我们想脱离枯燥的教科书定义，用我们的视角，带大家重新审视这套“构建高效 Agent”的方法论。这不仅是对前七篇文章的总结，更是我们对 AI 工程化的一点深度反思。

一、为什么我们需要工作流？

简单说，是为了确定性。

LLM 本质上是一个概率模型，它的天性是“随机”和“创造”。但在企业级应用中，我们需要的是“稳定”和“可控”。工作流，就是把 LLM 这个充满不确定性的“黑盒”，装进一个确定性的“白盒”流程里。

我们不再指望模型自己“涌现”出完美的解决方案，而是通过拆解、路由、并行、反馈，把任务硬生生地“管”起来。

二、我们的“武器库”：五种核心模式

在我们的脑海里，这不仅仅是五种模式，而是应对不同敌人的五种武器。

1. Routing（路由）：分诊台的智慧

场景：当用户的需求五花八门，而单一的 Prompt 无法兼顾所有场景时。 我们的思考：这就像医院的分诊台。你不能让全科医生去给所有人看病，效率低且容易误诊。 核心价值：关注点分离。把简单问题给快模型（省钱、快），把复杂问题给强模型（保质）。这是在系统层面做出的第一次“质量与成本”的权衡。

2. Prompt Chaining（提示链）：流水线的艺术

场景：任务步骤清晰，但逻辑太长，模型容易“猪脑过载”。 我们的思考：还记得那是第一次写长 Prompt，模型总是漏掉中间的指令。后来我把它拆成了 Chain。 核心价值：用时间换可靠性。每一步只做一件事，每一步都可观测、可校验。虽然慢了点，但心里踏实。这是一种“慢就是快”的哲学。

3. Parallelization（并行）：大力出奇迹

这里其实藏着两把不同的剑：

  • Sectioning（分段）——为了快： 场景：任务能拆成独立的子任务（比如同时写五个段落）。 我们的思考：如果它们互不干扰，为什么要排队？全部一起上！ 核心价值：用算力换时间。增加并发，降低延迟，让用户觉得“哇，好快”。

  • Voting（投票）——为了稳： 场景：绝对不能出错的场景（比如合规审核）。 我们的思考：一个模型可能会看走眼，三个模型分开看走眼的概率就小得多了。 核心价值：用算力换确定性。这是给系统买的“保险”，虽然贵，但关键时刻能救命。

4. Orchestrator-Worker（协调器 - 工作器）：动态的指挥家

场景：任务太复杂，连我们都不知道第一步该干嘛，得边走边看。 我们的思考：这才是真正的 Agent 雏形。它像一个项目经理（Orchestrator），根据当前情况动态拆解任务，分发给打工人（Worker）。 核心价值：处理复杂性。它解决了静态工作流无法处理的动态问题，是迈向通用智能的重要一步。

5. Evaluator-Optimizer（评估与优化器）：工匠的执着

场景：能写出来，但写得不够好。 我们的思考：好文章是改出来的，代码也是。 核心价值：逼近质量上限。通过“生成 - 评估 - 修改”的闭环，把 LLM 的潜力榨干。这是追求极致质量时的不二之选，当然，代价是昂贵的 token 和时间。

三、深水区：模式的差异与协作

如果说上面的五种模式是独立的积木，那么在真实的复杂系统中，我们往往需要把它们搭在一起。这里有几个关键的“差异点”和“组合拳”，是我们踩过坑后总结出来的。

1. 差异辨析：谁是真正的“时间管理大师”？

  • Prompt Chaining vs. Orchestrator-Worker

    • Prompt Chaining 是线性的。就像流水线工人，A 做完给 B，B 做完给 C。路径是预设好的，死板但稳定。
    • Orchestrator-Worker 是发散的。像项目经理分派任务，可以同时派给 D、E、F，甚至根据 D 的反馈再派给 G。它更灵活，能处理未知，但管理成本极高。
    • 选型直觉：如果你能画出流程图，用 Chaining；如果你只能画出组织架构图，用 Orchestrator。

  • Routing vs. Orchestrator

    • Routing 是选择题。它只负责把请求导向某一条路，自己不参与后续。
    • Orchestrator 是问答题。它不仅要分派任务，往往还要回收结果，进行综合处理。
    • 选型直觉：Routing 是“要么 A 要么 B”；Orchestrator 是“既要 A 也要 B，最后还要 C 汇总”。

2. 协作场景：打出漂亮的“组合拳”

在实际工程中，单一模式往往独木难支。以下是我们常用的几种黄金组合：

  • Routing + Prompt Chaining（分而治之 + 步步为营）

    • 场景：客服系统。
    • 打法：先用 Routing 判断用户意图（是退款、咨询还是投诉？）。如果是退款，进入退款的 Prompt Chaining（核实订单 -> 计算金额 -> 发起退款）；如果是投诉，进入投诉的 Chaining。
    • 效果：既保证了术业有专攻，又保证了流程的规范性。

  • Orchestrator + Parallelization (Sectioning)（统筹全局 + 并行加速）

    • 场景：长研报生成。
    • 打法：Orchestrator 分析题目，列出大纲（背景、现状、趋势）。然后将这三个部分作为子任务，并行分发给三个 Worker（Sectioning）。最后 Orchestrator 回收所有段落，统一润色风格。
    • 效果：既处理了复杂任务的结构，又极大缩短了生成时间。

  • Prompt Chaining + Evaluator-Optimizer（稳扎稳打 + 精益求精）

    • 场景：代码生成助手。
    • 打法：先通过 Prompt Chaining 生成代码逻辑（理解需求 -> 设计接口 -> 编写代码）。在“编写代码”这一步，引入 Evaluator-Optimizer，反复运行单元测试，直到通过为止，再进入下一步。
    • 效果：在关键节点上死磕质量，确保最终交付物的可用性。

四、灵魂拷问：我们该怎么选？

站在十字路口，总结出了一套“选型心法”。核心依然是那个“不可能三角”：速度（Latency）、质量（Quality）、成本（Cost）。

  1. 默认选项：永远先试单 LLM。如果它能搞定，别折腾。简单就是美。
  2. 遇到瓶颈了吗？
    • 问题太杂？ -> 上 Routing。
    • 容易出错/步骤太多？ -> 上 Prompt Chaining。
    • 太慢了？ -> 检查子任务能拆吗？能拆就上 Parallelization (Sectioning)。
    • 不知道怎么拆？ -> 没办法，只能请 Orchestrator 出山了。
    • 绝对不能错？ -> 咬咬牙，上 Voting，花钱买平安。
    • 质量还不够好？ -> 上 Evaluator-Optimizer，死磕到底。

五、写在最后

这七篇文章精读 Anthropic 《Building effective agents》，加上这篇总结，构成了我们对 Agent Workflow 的完整认知拼图。

但我们知道，这只是开始。技术在变，模型在变，但工程化的思维不会变。无论未来模型变得多强，我们依然需要通过架构设计，在质量、成本和速度之间寻找那个微妙的平衡点。

不要迷信复杂的架构，被约束逼出来的，才是最好的设计。

愿我们在构建 Agent 的道路上，少一些盲从，多一些理性的权衡。

9ong@TsingChan 文章内容由 AI 辅助生成。