造 AI 工作流与应用：把不确定的部分关进笼子

第一篇说了判据。这一篇讲工作流具体怎么造，以及怎么让它可靠。

核心手法：让模型填空

工作流的可靠性来自一个简单的安排：结构由代码定，内容由模型填。

生成一份报告：章节顺序、每节的字数上限、要不要出图 —— 代码定死；每节写什么 —— 模型填。

这样拿到的是两样都要的东西：产出结构完全可预测（能校验、能比较），内容仍然灵活。

很多被做成 agent 的需求，这个形态就够了。

三种基本形状

形状	用在哪	注意
串联	每一步依赖上一步	错误会 100% 传染到下游
路由	先分类再分流	分类错了后面全错，所以分类要能兜底
并行 + 汇总	几件事互不依赖	汇总那一步往往是真正的难点

串联那条注意事项是我踩过的：多步骤流水线里，第一步让模型抽出一个结构，它编造了一个源材料里根本不存在的东西；第二步直接读那个结构，从它铺出来的每一条产出都继承了这个错。

传染率 100%，因为每一步的产物是下一步唯一的输入。

所以：在交接处校验

这是工作流最该花力气的地方，而多数人跳过它。

每一步的产物在被下一步使用之前，要过一道检查。 检查什么取决于场景，但有一条通用的：

下游校验的时候，参照物只认原始材料，不认上一步的产物。 否则上一步脑补出来的东西会被当成事实引用 —— 错误就这么洗白了。

结构化输出是工作流的地基

步骤之间传的必须是结构化数据，不能是自然语言段落。理由很实际：自然语言没法校验。

用 Pydantic 这类定义形状，然后校验。这里有条实战经验：

模型不守约的时候，重试要带上具体的错误和一个最小的正确样例。只丢一句「解析失败」会把它带得更偏 —— 它不知道往哪个方向改，就换个花样再错一次。

还有个坑值得提：想要 JSON 就打开 JSON 模式，这个直觉有时会害人。我实测过一次：同一份提示词，带 JSON 模式，服务端返回 [] 三个 token 就结束；去掉之后同一个模型给出完整结构。因为那个模式只保证语法合法，而 [] 也是合法 JSON —— 它成了最短的合法答案。

错误处理：分类比重试重要

一步失败了怎么办？关键不是「重试几次」，是分类：

类别	该怎么办
认证失败、参数写错	立刻失败 —— 重试一百次输入都一样
限流、超时、5xx	退避后重试
现场已经脏了	重试单步没用，回退整段

**判据不是「失败了没有」，是「重试有没有可能成功」。**这套分类在 harness 那一层是同一张表。

我在这一格踩过：把 401 归进了「可重试」，一轮跑完发现每个任务都白试三次，报的是同一句认证失败。

边界与代价

工作流的僵硬是真的代价。 遇到没设计过的输入它会直接卡住。如果你的输入分布很宽，写死所有分支的维护成本会超过收益。

并行的汇总步骤经常是隐藏的复杂度。 三个分支各自产出，怎么合并、冲突了听谁的 —— 这一步的逻辑往往比三个分支加起来还难。

「结构由代码定」有个前提：你知道结构该是什么。 探索性的任务里你不知道 —— 那时候该用 agent，而不是硬猜一个结构出来。