工作流自动化

它是什么

工作流自动化是用预先写好的路径把模型和工具串起来执行的方式：什么时候触发、按什么顺序走、遇到什么条件走哪一支、哪一步要停下来等人确认，全部由代码决定。它是一次编排，不是一个会自己拿主意的助手。

它的关键定义在于控制权在谁手里：模型只负责路径中的某几步（通常是判断、摘要、生成），决定「下一步走哪里」的仍然是代码。这也是它和 AI Agent 最本质的分界——Agent 把「下一步」交回给模型，工作流把它留在代码里。

它是一段有起点和终点的流程，不是一个会自动变聪明的系统。

为什么需要它

因为大部分真正需要自动化的业务步骤，本来就是可枚举的：收到表单要校验、查一次数据库、生成一段说明、交给主管确认、写回系统。这些步骤不需要模型即兴发挥，需要的是每一步都不漏、错了能看见。

工作流自动化正是为这种需求准备的：路径固定意味着可以逐段测试，可以算出最坏情况的耗时与成本，可以在任意一步插入人工确认。而让模型自己决定路径的代价是——它可能走进你没有处理过的分支，而那时你已经没有对应的兜底逻辑。

还有一笔常被忽略的账：先跑通工作流，才知道哪一步真的需要模型自由判断。 直接上 Agent，会把「流程没设计清楚」和「模型不行」这两个问题混在一起，最后既说不清哪里坏了，也不敢改动任何一环。

它如何工作

一条工作流的骨架通常是这六段：触发 → 输入校验 → 步骤执行 → 条件分支 → 人工确认 → 结果落库与通知。工程上真正决定它能不能上线的，是后面几件不起眼的事：

幂等：一次触发重跑两次，结果必须一样。做不到幂等，重试就会变成重复扣款、重复发信。
状态存放：流程走到第三步时进程挂了，重启后要从哪里继续。状态存在哪里，决定了它能恢复还是只能从头再来。
失败分类：区分「这次失败可以重试」和「这次失败必须有人看」。把两者混成一个失败计数，等于把需要处理的错误埋进日志里。
确认点的位置：确认点要放在影响不可撤回的那一步之前，而不是流程末尾——末尾确认等于把已经造成的结果摆给人看。

编排模式本身不复杂，常见的几种是：把任务拆成固定顺序的链、按输入类型路由到不同分支、把互不依赖的步骤并行、以及让一个步骤的输出由另一个步骤来检查。它们的共同点是分支与顺序都写在代码里，模型只在被指定的那几步里工作。

必须澄清的误会

工作流自动化 ≠ AI Agent。 差别只有一条，但很硬：谁决定下一步。工作流的下一步由代码决定，模型只被叫来做其中的几步；Agent 由模型看着中间结果自己决定下一步，因此它能走出你没写过的路。这条差别直接推出两者的适用条件——步骤可枚举、结果可检查的事，工作流更便宜也更稳；目标含糊、要靠探索才知道下一步的事，工作流写不出来，只能交给 Agent 并给它预算和退出条件。

它 ≠ Agent 技能。 技能是把「这件事该怎么做」写成的可复用说明书，工作流是把说明书里的步骤真的连起来执行。前者是内容资产，后者是执行结构。常见的组合方式是用技能沉淀步骤规范，再用工作流把它固化下来——两者是上下游，不是替代关系。

别把「有分支」当成「会思考」。 工作流里的条件分支是你提前写好的 if；模型即使参与了判断，也只在被允许的那几个岔路口上给出一个选项。把这种流程说成「Agent 在自动决策」，会让团队对它的容错能力产生错误预期。

真实例子

以「每周销售周报」为例，一条实际能跑的工作流长这样：周五 17:00 触发；先从 CRM 拉本周新增与关闭的商机（工具调用）；按区域分组后交给模型生成初稿（生成步骤）；把初稿与原始数字一起推给销售负责人确认（人工确认点）；确认后写回 CRM 备注并发送邮件（落库与通知）；任一步失败则记录失败原因并通知负责人，不自动重试写回动作。

这里模型只出现在「生成初稿」一步，而数字来自工具、去向由代码决定。结果是：周报的格式每周一致，数字错了能定位到哪次查询，改一次流程下周就生效——这三件事才是自动化真正交付的价值，而不是「用上了模型」。

什么时候适合与不适合

适合：步骤能枚举、输入分布相对稳定、结果有客观检查方式、错了能撤回或有人能兜住。这类流程用工作流做的收益是可预测的：耗时与成本可以估算，新增分支只影响那一条路径。

不适合：目标本身还说不清、步骤要靠中间结果临时决定、需要跨系统反复试错探索。这时硬写成工作流，会得到一张巨大的分支表，而且每遇到一种没覆盖的情况就再加一支——最终没人敢改。

还有两种失败模式值得区分开。一种是输入漂移：字段格式变了、上游系统改了名字，工作流照旧执行，只是结果悄悄变错。另一种是过早自动化：流程本身还在变，你先把它固化下来，于是每次流程调整都要改代码。前者要靠校验与告警防，后者要靠「先稳定再自动化」的节奏防。

亲自试一下

挑一件你每周要重复两次以上的事（对账、周报、批量通知都合适），用约 20 分钟在纸上写四项内容：

触发条件：什么事件让它开始。
步骤顺序：每一步的输入、输出分别是什么。
失败处理：哪些失败可以重试，哪些必须停下来找人。
确认点：哪一步错了最难撤回，确认就放在它的前面。

写完后标出最危险的一步——即「这一步出错但流程会照常走完」的位置。观察点不是流程能不能跑通，而是错了会不会被立刻发现：如果你标不出任何一个检查点，说明这套流程还不适合自动化，先把检查补上。

接下来学什么

工作流自动化是这一站（给流程）的落脚概念——它和 Agent 技能、Agent 工作流、提示词模板一起回答「怎么把做法沉淀下来并稳定执行」。

如果你还没理清「工具是怎么被接进来的」，那是上一站的事，先读模型上下文协议（给接口）。如果你在犹豫「这一步要不要交给模型自己决定」，先看 AI Agent（给手脚）的分界，再回到这里判断——那条分界的答案是「谁决定下一步」，不是「谁更聪明」。跑起来之后，下一站是给判断：先有评测集，才谈得上「它变好了」。

来源与修订

控制权这条分界（工作流由预先定义的代码路径编排，Agent 由模型动态决定自身流程）来自 Anthropic 的工程实践文章 Building Effective Agents；运行期的失败处理、人工介入与可信任边界参考 Trustworthy Agents in Practice。

需要说明一处边界：「幂等、状态存放、失败分类、确认点位置」这四条是本站在落地时总结的操作性要求，不是上述来源的原文——文章讲的是架构选择，不展开实现细节。我们把它写在这里，是因为这几条恰好是工作流上线后最常出事的地方。

2026-09-21 按决策页规范重写，本次修订把「谁决定下一步」确定为它与 AI Agent 的唯一分界，并补入幂等、状态存放、失败分类、确认点位置四项落地要求。

Learning questions