Workflow

固定的是允许的流程#

Workflow 可以有分支、并行和模型判断，并不意味着每次都走相同路线。关键是程序预先定义了可走的步骤与衔接方式。模型可以决定“物流还是退款”，但不能因此任意添加一个未经设计的支付步骤。1

拆解一个工单流程#

本站教学示例： 把客服留言变成待处理工单。

1. 输入检查： 空消息直接返回提示，不调用模型。
2. 信息提取： 模型提取分类、订单号和原文依据。
3. 结构与业务校验： 检查字段、订单归属和必要信息。
4. 分支处理： 信息不足则询问；可处理则创建草稿；特殊情况转人工。
5. 记录结果： 保存工单标识与失败状态，便于恢复。

其中输入检查和订单归属适合普通代码；信息提取才是需要语言理解的部分。不必把每个步骤都包装成模型调用。

给每一步约定失败出口#

提取失败 → 限次重试或转人工
编号缺失 → 请求补充，不猜编号
权限不足 → 拒绝处理，不暴露订单内容
创建超时 → 先查请求状态，再决定是否重试

这份列表可以直接变成测试场景。还要区分“生成结果不合格”和“网络暂时失败”，避免对不同原因使用同一种重试。

重试不是从头再来#

如果创建工单已经成功，只是响应丢失，再执行一次可能产生重复记录。AWS 的一手工程资料讨论了利用幂等请求设计控制这类重复副作用。2

实践中要约定：哪个请求标识表示同一次业务意图、重复请求如何返回结果、保留多久、参数变化如何处理。本文只给出检查方向，不能代替具体业务接口的契约。

怎样证明流程改善了#

本站建议比较两版流程时，至少记录每个步骤的失败率、端到端完成率、人工介入次数和耗时。固定流程更便于定位错误，但仍可能包含不稳定的模型步骤；不能从流程图整齐就推断系统可靠。

如果分支开始难以维护，先检查任务是否划分过粗，再考虑让某个局部步骤具有自主决策能力。Workflow 与 Agent 可以组合，不需要一次把全部控制权交给模型。