AI AGENT 工程范式进化史 • 第二站 • CHAIN / WORKFLOW ENGINEERING
明明每一步都做对了， 为什么串起来 还是会翻车？
第一站，我们把用户的一句话写成了标准订单。可一到真实业务，事情立刻变了：识别问题、判断优先级、走不同支线、生成回复、校验格式——一张订单写清楚了，不代表整桌菜能一次端出来。
这一站开始拆工序。标题里的“五分之一”不是行业调查，也不是说 80% 的人都做错了；它指的是：如果你把工作流只理解成“一步接一步”，那确实只看见了本文五种常见接法中的一种。
00 / 接住上一站
订单写清楚以后，后厨才刚刚开始忙。
总览里那家小餐馆，到了午市高峰。第一站解决的是点菜窗口：把“随便来点吃的”改成“牛肉面，不要香菜，面硬一点，汤少一些”。这张单现在足够标准，能被机器读取，也能被后厨检查。
但订单一进后厨，就要经过备料、煮面、装碗和出餐核对。有人对花生过敏，要走专门支线；凉菜和热菜可以同时做；碰上十桌宴席，主厨还得临时拆任务；出餐检查不通过，菜要带着具体原因返工。
所以第二站不重讲怎么写订单。
我们只看订单离开窗口之后，怎样在不同工序之间流动。第一站优化“一次调用怎么说”，第二站优化“整件事先做什么、再做什么”。
01 / 先把定义说准
Workflow 不是一条线，而是一组预先组织好的路径。
Anthropic 在《Building Effective Agents》里给了一个很实用的区分：Workflow 是由代码预先组织模型和工具的执行路径；Agent 则由模型动态决定自己的过程和工具使用。
这一定义比“有向无环图”更适合本文。因为 Workflow 可以是直线，也可以有分支、并行，甚至包含局部反馈回路。把所有 Workflow 都说成 DAG，会和后面的评估—优化循环自相矛盾。
人话版：
餐馆老板先把大部分规矩写好：普通面走哪几步，过敏单多过哪道检查，哪几道菜可以同时开火。模型可以参与其中，但不是想去哪儿就去哪儿。
02 / 拆链的收益与代价
拆开以后，每一步更简单；串起来以后，错误也会传下去。
把“分类、判断、生成、校验”全塞在一次调用里，模型要同时顾很多事。拆开以后，每一步目标更窄，提示词更容易写，评测也更容易定位：到底是分类错了，还是生成错了。Anthropic 把 Prompt Chaining 的主要取舍概括为：用更高的延迟，换取更容易完成的子任务和潜在的更高准确性。
但“拆得越细越稳”只对了一半。步骤变多，也意味着接口变多、延迟变长、成本增加，而且前一步的脏数据可能被后面加工得越来越像真的。
上图不是实测业绩，而是一道透明的示例算术：假设五步彼此独立、每步正确率都是 95%，而且五步都必须正确，端到端就是 0.95⁵≈77.4%。现实里各步并不独立，难度也不同，所以不能拿这个数字预测你的系统；它只提醒我们，单步看起来不错，不等于全程自然可靠。
真正该问的不是“能拆几步”，而是：
拆出来的每一步，能不能单独评测？边界有没有清楚的输入输出？这一步如果失败，系统能不能尽早停下来？
03 / 本文核心
五种常见接法，解决五种不同的问题。
下面五种模式来自 Anthropic 的工程总结。它们不是唯一分类，也不是从低到高的升级等级；真实系统经常把几种组合在一起。
① 链式：事情能按固定顺序拆开
前一步输出交给后一步。适合“先生成提纲，再检查提纲，最后按提纲写正文”这类顺序明确的任务。优点是直观、好调试；缺点是第一步错了，后面可能一路错。
厨房里就是备菜 → 腌制 → 炒制 → 装盘。顺序是业务决定的，不需要模型现场发明。
② 路由：输入类别不同，后续处理就不同
先判断类型，再送往专用流程。退款、物流、技术咨询不该共用一套又长又矛盾的提示词。路由的前提是：类别边界能说清，而且分类本身足够可靠。
厨房里，冷菜送冷菜档，热菜送炒锅档，过敏单先送复核台。不是让一个厨师同时扮演所有档口。
③ 并行：互不依赖的事情，同时做
并行有两类常见玩法：一类是把独立子任务分开同时处理，主要省时间；另一类是让多个调用从不同角度检查同一问题，再用规则汇总，主要增加覆盖面或置信信息。第二类并不天然保证正确，汇总规则同样要评测。
厨房里，凉菜、热菜和甜点可以同时开工，但“腌制完成之前先炒肉”就不叫并行，只叫跳步骤。
④ 编排者—执行者：要做几份活，运行时才知道
一个中心模型先看具体输入，再动态拆出子任务，交给多个执行者，最后汇总。它和普通并行的区别是：普通并行的子任务提前写好；这里的子任务由编排者根据本次输入临时决定。
厨房里，固定套餐不需要这一套；但十桌宴席临时加菜时，主厨得先看菜单、人数和上菜时间，再决定凉菜档、热菜档和甜点档各做什么。
⑤ 评估者—优化者：有明确标准，返工才有意义
一个调用先生成，另一个按明确标准评价，并给出具体反馈；未通过就带着反馈继续修改。它适合“人能指出哪里不好，而且模型也能给出这种反馈”的任务。
厨房里不是一句“再做好一点”，而是“盐度超标、中心温度不够、摆盘少了一份配菜”。没有评价标准的返工，只是在重复消耗。
04 / 链上的阀门
Gate：别让错误顺利地流到最后。
工作流里最便宜、也最容易被忽略的组件，往往不是另一次大模型调用，而是一道确定性检查：字段齐不齐、类型在不在允许范围、金额是不是数字、下一步需要的订单号有没有拿到。
Anthropic 在 Prompt Chaining 的图里专门画了 Gate。它的意义不是让系统更聪明，而是让错误尽早暴露。厨房里，过敏备注没打印出来，就应该停在备菜台，而不是等菜端到顾客面前再补救。
能用普通代码检查的，就别再问模型“你确定吗” 。
JSON Schema、枚举、必填字段、金额范围和权限规则，优先用确定性校验。OpenAI 的 Structured Outputs 能让支持的模型按开发者提供的 JSON Schema 输出；但业务内容是否正确，仍然需要独立评测。
05 / 系列主线案例
工单系统：从一张标准小票，变成可检查的处理流程。
第一站，我们只做了一件事：把用户自由文本变成结构化工单。现在同一个系统继续往前走。用户说：“上次那箱芒果还是坏的，别再让我等了。”
第二站先不追求“自动解决一切”，而是把可预先定义的路径接稳：
- 沿用第一站的结构化工单，并先做 Schema 校验；
- 按问题类型路由到退款、物流或其他支线；
- 根据支线生成回复，只有英文渠道才增加翻译步骤；
- 最终检查必填字段、禁用承诺和输出格式，不通过就停止或交给人。
这里不写没有来源的漂亮提升数字。真正上线时，要用自己的标注集分别记录：类型判断、优先级、政策合规、回复质量和格式校验；最后再看端到端成功率。
怎么砍步骤：
如果两个相邻步骤总是一起评测、一起失败，而且中间结果没有被复用或检查，它们可能不值得拆开。反过来，只要中间结果需要被路由、缓存、人工查看或确定性校验，这个边界通常就有价值。
06 / 到底该选哪一种
别从图形开始，从失败方式开始。
| 固定先后 | 用链式 |
| 类别决定路径 | 用路由 |
| 子任务互不依赖 | 用并行 |
| 子任务无法预先列全 | 用编排者—执行者 |
| 有清楚的质量标准 | 用评估者—优化者 |
实际项目通常会组合：先路由，进入某个支线后再链式处理；安全检查和主任务并行；复杂输入交给编排者拆活；关键输出最后过 Gate。组合的前提是每多一层复杂度，都能解释它解决了哪种真实失败。
07 / 这一站的边界
工序排对了，信息没送对，还是会做错。
回到那家餐馆。订单已经标准化，备料、煮面、装碗也排得很顺。可熟客只说一句：“还是上次那碗，别放花生。”流程可以准确把它送到过敏复核台，却不知道“上次那碗”到底是什么。
工单系统也一样。它能把“上次那箱芒果还是坏的”准确路由到售后，却未必知道是哪张订单、是否已经补发、当前退款政策是什么。接线再漂亮，也接不出系统从未送来的信息。
第二站只带走一句：
Workflow 不是把模型多调用几次，而是把步骤、分支、并行、返工和接口组织成可检查的路径。可路径只是路，下一步还要解决“走到这里时，模型到底该看到什么”。
流程排好了，
为什么模型还是会一本正经地做错？
因为它看见的信息可能太少、太多、过期、互相冲突，
或者根本没有在正确的步骤出现。
【进入第三站 · Context 不是越长越好，答案可能就埋在中间 →】
关于这个系列
《AI Agent 工程范式进化史》——跟着同一家餐馆连续升级，一站一站讲透 AI Agent 工程的演进：
Prompt → Chain → Context → Harness → Loop → Graph → 还会有的…
参考来源：
[1] Anthropic, 2024‑12‑19. Building Effective Agents。本文 Workflow 与 Agent 的核心区分标准、链式、路由、并行、编排者 — 执行者、评估者 — 优化者五种智能体设计模式，均以此官方工程博客为核心依据。www.anthropic.com/engineering…
[2] OpenAI, 2024‑08‑06. Introducing Structured Outputs in the API。用于厘清大模型普通自由 JSON 输出与 JSON Schema 强约束结构化输出的核心差异与技术边界。openai.com/index/intro…
口径说明：
文中 0.95⁵≈77.4% 为可公开复算的理论假设示例，非真实业务实测数据；工单流程为标准化教学演示案例，不对应任意企业真实生产场景。所有 Agent 工程、提示工程、结构化输出落地结论，生产环境均需基于自身业务评测集独立复现验证。
