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 的核心区分标准、链式、路由、并行、编排者 — 执行者、评估者 — 优化者五种智能体设计模式均以此官方工程博客为核心依据。https://www.anthropic.com/engineering/building-effective-agents[2] OpenAI, 2024‑08‑06.Introducing Structured Outputs in the API。用于厘清大模型普通自由 JSON 输出与 JSON Schema 强约束结构化输出的核心差异与技术边界。https://openai.com/index/introducing-structured-outputs-in-the-api/口径说明文中0.95⁵≈77.4%为可公开复算的理论假设示例非真实业务实测数据工单流程为标准化教学演示案例不对应任意企业真实生产场景。所有 Agent 工程、提示工程、结构化输出落地结论生产环境均需基于自身业务评测集独立复现验证。