06 · 工作流还是 Agent？

⏱ 24 分钟 ｜ ⭐⭐ 这行最重要的架构决策

🎯 一句话

能不用 Agent 就不用。 成功的系统靠的是简单可组合的模式，不是复杂框架—— 复杂度必须由数据证明必要，一步一步升级。

⚖️ 一、根本区分

💡 第 1 章你写的就是 Agent（模型决定调什么工具）。 如果把那个循环改成「固定先列文件、再算数、再总结」，就变成了工作流。

🔍 一个判断小技巧

   问自己：「我能提前画出这个任务的流程图吗？」

   能画出来（哪怕有分支）→ 工作流
   画不出来（因为下一步取决于上一步发现了什么）→ 才考虑 Agent

🪜 二、升级路径：每一步都要有数据支撑

   ① 优化过的单次 LLM 调用          ← 大多数需求到这就够了
        ↓ 成功率不达标？
   ② 加检索 / 加一两个工具
        ↓ 还不够？
   ③ 固定工作流（下面五种模式）
        ↓ 路径真的无法预先确定？
   ④ 自主 Agent

🔬 降级测试：怎么做

做 Agent 需求前，先从下往上爬，记录每级的成功率：

🔑 这张表的三个用处： 1. 证明复杂度必要——老板问「为什么这么贵」时你有答案 2. 找到性价比拐点——常常 ② 就够了，④ 只多 3% 却贵 10 倍 3. 模型升级后重跑——新模型可能让 ① 就达标了，你能砍掉整套架构

⚠️ 最常见的错误：跳过降级测试直接上 Agent， 然后花两周调试一个用工作流两小时就能做好的东西。

🧩 三、五种工作流模式

① 提示词链（Prompt Chaining）

   输入 → LLM(写大纲) → [程序检查大纲合格?] → LLM(按大纲写正文) → 输出
                              ↑ 闸门 gate

任务拆成固定顺序的步骤，中间可插程序化闸门检查。用延迟换准确率。

适合：能干净拆分的任务（先抽取再汇总、先写文案再翻译） 代价：每一步都要等，总延迟 = 各步之和

② 路由（Routing）

   输入 → LLM分类器 ──┬─ 退款请求 → 专门提示词A
                      ├─ 技术问题 → 专门提示词B
                      └─ 简单闲聊 → 小模型C（省钱）

适合：有明确类别、每类处理方式不同 ⭐ 最被低估的省钱手段：把简单请求路由给小模型（第 2 章的顾问策略）

⚠️ 坑：分类错了后面全错。要给分类器一个「不确定」的出口，兜底走通用路径。

③ 并行化（Parallelization）

两个变体：

   分片 Sectioning：独立子任务同时跑
      请求 ──┬─► 处理主任务
             └─► 内容安全审查     → 两者独立，可并行

   投票 Voting：同一任务跑 N 次取共识
      代码 ──┬─► 审查者1 ─┐
             ├─► 审查者2 ─┼─► 至少2人标记才算真漏洞
             └─► 审查者3 ─┘

⚠️ 关键忠告：动手实现之前先设计好聚合策略。 否则你会收获一堆互相矛盾的输出，却没有办法裁决。

常见聚合策略：多数投票 / 取并集（宁可误报）/ 取交集（宁可漏报）/ 再来一个模型仲裁

④ 编排器-工作者（Orchestrator-Workers）

   编排器 LLM：分析任务 → 动态拆分 → 派给工作者 → 综合结果

和并行化的区别：子任务不可预先确定，由编排器现场决定。

适合：跨多文件的代码修改、多来源信息搜集 这是多 Agent 的默认起点（第 13 章）

⭐ 注意这一节讲的五种模式，「拆分逻辑」都还写在你的代码里——是你决定了「先分类再分发」或者「编排器负责拆」。 还有一档介于工作流和 Agent 之间：让模型自己先把整个计划写出来，再按计划执行。 🔗 第 13 章把这一档拆成了三种可选骨架： Plan-and-Execute（先全盘规划再逐步执行，比 ReAct 省 token、但计划过时了要重规划）、 ReWOO（把计划里的中间结果用占位符串起来，规划阶段完全不看工具返回，token 更省）， 以及大家最熟的 ReAct（想一步做一步，最灵活也最贵）。 知道有这一档很重要——很多人在这一章的决策树末端直接跳到「上多 Agent」， ⚠️ 而实际上单 Agent 换个规划骨架就够了，成本差一个量级（第六节那个成本量级感就是在说这件事）。

⑤ 评估器-优化器（Evaluator-Optimizer）

   生成器 → 产出 → 评估器按标准打分 → 不合格带反馈回炉 → 循环

⚠️ 两条关键忠告： 1. 开始迭代前设好明确的停止标准——知道什么时候「够好」就是够好，否则无限循环烧钱 2. 评估器必须用独立上下文——让生成者自己评自己有系统性正面偏差（第 14 章）

适合：有清晰可衡量标准、初稿与成品差距大（文学翻译、反复打磨的报告） 代价：token 至少翻倍

🗺️ 四、选型决策树

   单次调用质量可接受？
        ├─ 是 → ⭐ 停。别加花样
        └─ 否 ↓
   有明确的输入类别？
        ├─ 是 → 【路由】（还能顺便省钱）
        └─ 否 ↓
   步骤有天然先后依赖？
        ├─ 是 → 【提示词链】
        └─ 否 ↓
   子任务独立且延迟是瓶颈？
        ├─ 是 → 【并行化】（先定聚合策略！）
        └─ 否 ↓
   有可衡量的质量标准，且值得多花 token？
        ├─ 是 → 【评估器-优化器】（先定停止标准！）
        └─ 否 ↓
   子任务无法预先确定？
        ├─ 是 → 【编排器-工作者】
        └─ 否 ↓
   路径真的不可预测 + 有可靠反馈信号 + 付得起代价？
        ├─ 是 → 【自主 Agent】
        └─ 否 → 回去重新想需求

🤖 五、什么时候才真的需要 Agent

三个条件必须同时满足：

🔑 条件 ② 最容易被忽略，也最致命。 没有反馈信号的 Agent = 一个没有指南针还在自信前进的旅行者。

这也解释了 Agent 的两大成功场景为什么是编码（反馈=测试/编译器） 和客服（反馈=用户响应+工具结果，成功可量化为解决率）。

💸 六、成本的量级感

来自公开工程实践的数据，帮你建立直觉：

💡 15 倍这个数字要记住：多 Agent 不是"稍微贵一点"，是一个数量级。 它必须换来相应量级的价值才划算。

🕳️ 七、五个常见误区

🔨 八、动手：给你的需求做降级测试

拿一个你想做「AI 自动化」的真实需求：

1. 准备 20 个真实样例（不是精心挑选的 demo，要包含难例）
2. 写一个尽力优化的单次提示词，跑一遍，记成功率
3. 不达标 → 加检索/工具，再跑
4. 还不达标 → 挑一种工作流模式，再跑
5. 把四行数字填进表格

💡 十有八九你会发现：② 或 ③ 就够了。而你原本打算直接上 ④。

📚 延伸阅读

• 构建有效的 Agent（最广为引用的方法论）
• 常见工作流模式及适用时机

✅ 检查点

1. 工作流和 Agent 的根本区别？有什么快速判断技巧？
2. 升级路径的四级是什么？降级测试的三个用处？
3. 并行化和评估器-优化器各有一条关键忠告，是什么？
4. 编排器-工作者和并行化的区别？
5. 真的需要 Agent 的三个条件？哪个最容易被忽略？
6. 多 Agent 大概贵多少倍？
7. 为什么说"可预测性是优点不是缺点"？

🛑 可以停在这里

⚡ 走神救援

能不用Agent就不用，复杂度必须由数据证明必要。根本区分是谁决定路径：工作流是你预写的代码路径（可预测、好调试、成本可估），Agent 是模型看反馈动态决定（难调试、更贵，错误还会复利放大）。判断技巧：能提前画出流程图就用工作流（哪怕带分支）；画不出来才考虑 Agent。升级梯子：单次调用（大多数需求到这就够了）→+工具→工作流→Agent，每级用降级测试（20个真实样例的成功率表，要含难例）证明必要，三个用处：证明复杂度必要、找性价比拐点（常常②就够，④只多 3% 却贵 10 倍）、模型升级后重跑帮你砍架构。⚠️最常见的错误是跳过降级测试直接上 Agent，然后花两周调一个工作流两小时就能做好的东西。五模式：链式(加闸门，用延迟换准确率)、路由(最被低估的省钱手段，⚠️分类错了后面全错，要给分类器一个「不确定」的出口)、并行(分片/投票，先定聚合策略——多数决/并集宁可误报/交集宁可漏报/模型仲裁，否则只是更快收到一堆矛盾结果)、编排器-工作者(子任务动态拆分，不可预先确定)、评估器-优化器(先定停止标准+评估器独立上下文，否则无限循环烧钱、自评还有正面偏差)。Agent三条件必须同时满足：路径不可测+有可靠反馈信号(最易忽略最致命)+付得起代价——⭐没有反馈信号的 Agent 就是没有指南针还在自信前进的旅行者。成本量级：单次 1×、三步工作流 3×、评估器-优化器 2–5×、多Agent贵约15倍，是一个数量级。可预测性是优点不是缺点。

下一节 👉 07-工具设计-能力的上限.md