工作流与自动化

Workflow Automation

很多 AI app 在单次 request demo 时都看起来不错，但一旦变成长任务、批处理、multi-step pipeline，就开始暴露问题：任务会丢、重试会乱、状态不清、人工 review 插不进去。AI engineer 真正的价值，往往不是把单次 prompt 调到 90 分，而是把整条 workflow 做到可恢复、可观察、可扩展。

所以这页讲的是 production workflow automation，不是“把几个 API 连起来”那么简单。

---

先说结论：先显式建状态，再谈自动化

AI workflow 最怕隐式状态。
一个 task 到底在哪一步、失败了几次、该不该转人工，如果都只能靠日志猜，这条 automation 很快会失控。

所以更稳的原则是：

1. 每一步有明确 state
2. 每一步能重试或恢复
3. 每一步都能被观测

---

什么时候你真的需要 workflow system

如果任务是跨时间、跨工具、跨状态的，workflow 就不是可选项了。

---

一个更可靠的 Workflow Skeleton

ingest
  -> queue
  -> worker step
  -> checkpoint
  -> next step or retry
  -> human review if needed
  -> completion

这里最关键的不是 queue 本身，而是 checkpoint 和 retry policy。

---

State Machine 为什么比“脚本串起来”更稳

一个更像 production 的 task state，至少应该有：

有了这层状态，你后面做 SLA、重跑、监控、审计都容易很多。

---

Retry 不只是“失败了再来一次”

更靠谱的 retry policy 至少要定义：

很多 workflow 出事故，问题不在第一次失败，而在失败后重复做错很多次。

---

Workflow 里的 LLM Step，要像不稳定依赖来设计

这点很关键。
LLM step 不是 deterministic function，所以你应该默认它会：

• timeout
• schema fail
• output drift
• 质量波动

这意味着每个 LLM step 最好都有：

• timeout
• schema validation
• fallback / retry
• low-confidence review path

把 LLM 当成稳定黑盒，是很多 workflow 后期难维护的根源。

---

HITL 路径一定要早设计

Human-in-the-loop 不是系统失败后的补丁，而是 workflow 的正式分支。

它通常适合：

如果 review path 是后面临时拼出来的，通常会非常难用。

---

Observability 不要只看 overall success rate

更应该看：

如果你只看 overall success，很多局部坏趋势会很晚才发现。

---

常见翻车点

AI workflow engineering 最值钱的地方，就是把这些“本来靠运气”的部分变成系统能力。

---

Practice

拿你现在一个 multi-step task，先画出这 5 个东西：

1. task states
2. retry policy
3. checkpoint location
4. review trigger
5. failure metric

这 5 个东西一旦明确，workflow automation 就已经比脚本堆叠成熟一个层级。