Agent 工作流

它是什么

Agent 工作流是一种混合结构：流程的骨架仍然是预先定义的步骤，但在其中若干步骤上，判断权交给模型——比如「这份资料属于哪一类」「这条记录该走哪个分支」「这一步的结果够不够格进下一步」。骨架留下，判断放出来。[S1]

它存在的理由是工程上的一个现实：多数业务流程不需要全自由，只需要在少数几个地方不写死。 全写死（纯工作流自动化）会在规则边界上频繁出错；全放开（自主 Agent）会失去可测试性与可解释性。混合结构正好卡在中间。

为什么需要它

因为「模型判断」和「代码执行」各自擅长的事情不一样，强行让其中一方包办都会出问题。

让代码包办判断，就要把判断写成规则。规则能覆盖 90% 的输入，剩下的 10% 是长尾——而长尾恰恰是业务里最需要正确处理的那些情况（格式不规范的用户反馈、措辞含糊的工单、边界情况）。规则写法只有一个结局：不断加 if，直到没人敢改。

让模型包办执行，就失去了「每一步都能测」的能力。你可以测「它有没有调用正确的工具」，但很难证明「它在任何输入下都不会越过某条线」。

Agent 工作流的价值在于把这两件事拆开：不可预测的部分被限制在几个确定的步骤里，其余部分仍然可测试。 这也让成本可估算——每一步的调用次数上限是设计时定好的，不是运行时涌现的。

它如何工作

设计 Agent 工作流时，真正要回答的是三个问题：

• 哪些步骤交给模型？ 判据通常是「这一步的判断能不能用规则穷举」。能穷举的留在代码里；不能穷举的（语义分类、质量判断、自然语言生成）交出去。注意一个常见错误：把「需要用到自然语言」当成「必须交给模型」——从文本里抽一个固定格式的编号，是正则的活，不是模型的活。
• 交出去的那一步，输出必须是什么形状？ 自由判断最容易失控的地方是输出格式。要求它输出一个枚举值、一个结构化字段，而不是一段散文，下游才接得住。
• 哪几步之间必须有检查点？ 检查点的作用有两个：一是拦住明显的错，二是给“模型判断偏了”这件事留下可观测的证据。检查点要放在错误会扩散的那一步之前。

除了这三问，还需要为「模型判断失败」准备一条路：判断结果不在允许的枚举值里怎么办、连续两次判断冲突怎么办。这条兜底路径在自主 Agent 里是不存在的（它没有固定分支），在 Agent 工作流里则必须写出来。

必须澄清的误会

Agent 工作流 ≠ 工作流自动化。 两者都叫「工作流」，差别在控制权的分布。工作流自动化里，走哪一步完全由代码决定，模型只是被叫来做某几步的生成；Agent 工作流里，有几步的走向由模型的判断决定，因此路径会随输入变化。这直接改变工程要求：工作流自动化可以穷举所有路径并逐条测试，Agent 工作流不能——它只能靠检查点、输出枚举和日志来约束。

Agent 工作流 ≠ AI Agent。 自主 Agent 连「有哪些步骤」都在运行时决定，它可以发明流程；Agent 工作流仍然是设计者写下的骨架，模型只在被指定的岔路口投票。把两者混在一起谈，会导致对容错能力的错误预期：Agent 工作流的异常范围大致可枚举，自主 Agent 的不行。

它不是「半自动」或「过渡形态」。 有一种说法是「先搭工作流，等模型强了再全部交给它」。这个判断把「可测试」当成了过渡期的妥协，但可测试性本身是长期价值——特别是当流程涉及资金、对外沟通或不可撤回的操作时，全程可解释的结构不是临时措施。

还有一个容易搞反的点：把判断交给模型，不等于把责任交给模型。 判断是模型做的，但「判断错了会怎样」仍由设计者负责。所以每一个交给模型的判断，都要配一个「它判断得不对时，会发生什么」的答案。

真实例子

一个「客户反馈自动分派」的流程可以这样混合：收到反馈后固定执行输入校验（代码）；用模型判断这条反馈属于「功能缺陷 / 使用疑问 / 功能请求 / 情绪抱怨」四类中的哪一类，只允许输出这四个值之一（模型判断，输出枚举）；按类别路由到不同的处理分支（代码）；进入分支后固定执行「查历史工单 → 生成回复草稿」（代码 + 生成）；发送前由人工确认（人工检查点）；最后写回系统并记录本次判断的类别（代码）。[S1][S2]

这里模型只出现在一步，且输出被限制在四个值以内。结果是：流程的路径仍然可以穷举（四类分支），但分类这件事不再需要维护一张越来越长的规则表。运维时如果发现分类大量出错，可以单独评估和调整这一步，而不必动整个流程。

什么时候适合与不适合

适合：流程骨架相对稳定、其中少数几步的判断难以规则化、结果需要可解释、出错的后果需要可控制。典型的是分派、分级、摘要、抽字段、质量初筛这类环节。

不适合：判断本身可以规则化（那就用代码，别引入模型的不确定性）；或者流程本身还在剧烈变化（此时应该先稳定骨架，而不是先嵌入判断）。也不适合那些「模型判断错了也没人会发现」的环节——没有检查点的模型判断，本质上就是把不确定性直接放进生产链路。

Agentic 工作流的两类主要失败模式需要区别对待。 一种是判断漂移：模型对同一输入的分类随时间或版本变化，而流程照旧执行，问题是静默的。防它要靠固定样本回归。另一种是兜底缺失：模型输出了枚举之外的答案，流程没有对应分支而走入异常路径。防它要在设计时就规定「不在枚举内」的处理方式。

亲自试一下

挑一个你正在跑（或将会跑）的固定流程，用约 45 分钟做一次改造推演：

1. 把现有步骤画出来，标出哪些是代码执行、哪些是判断。
2. 从判断里挑出最难用规则穷举的一个，假设把它交给模型。
3. 写下这一步的输出必须是什么（尽量收敛到一个枚举值或结构化字段）。
4. 在它前后各加一个检查点，写下这两个检查点各自能拦住什么。
5. 回答一个问题：这个判断如果错了，谁会先发现？

第 5 问是这次练习的重点。如果你答不出「谁会先发现」，说明这一步不该现在交出去——先补检查点，再考虑替换。

接下来学什么

Agent 工作流是这一站（给流程）里承接「把做法沉淀下来」的那一环。要把它用对，需要先看清它两侧的邻居：工作流自动化 代表「全部写死」的一端，AI Agent 代表「全部放开」的一端，Agent 工作流是中间那条线。

如果你还没弄清「判断交给模型之后，输出格式为什么要收得那么紧」，看 结构化输出 与 函数调用。如果你关心的是「模型判断错了怎么办」，那是 给判断 的题目：先有 评测集，才能说这一步的分类是不是变差了。如果你担心的是「某一步不该自动做」，跳到 给安全。

来源与修订

把「混合结构」作为一种独立形态、并强调检查点与可测试性，来自 Anthropic 的 Building Effective Agents；对自主程度与人工介入边界的判断，参考 Trustworthy Agents in Practice。[S1][S2]

需要说明一处边界：「哪些步骤该交给模型、输出必须收敛到枚举、检查点放在错误扩散之前、兜底路径必须显式写出」这四条是本站在落地时总结的操作性判据，不是上述来源的原文。来源讨论的是结构选型，不会替你决定某一步该不该交给模型——那要看你这一步的后果可不可撤回。

2026-09-21 按决策页规范重写，本次修订把「哪些步骤该交给模型」写成三个可执行的判断问题，取代了原先只描述形态的写法。