25 Workflow 与 Agent 的边界¶

难度：中级｜前置：Tool Calling、状态机｜目标：避免把确定性流程错误地交给模型

三种控制方式¶

固定工作流¶

A → B → C

步骤可预先确定，适合：

数据校验；
审批；
扣费；
发送前确认；
固定 ETL。

条件工作流¶

校验
├─ 通过 → 执行
└─ 失败 → 人工

条件由程序或规则决定。

Agent¶

模型根据目标和上下文动态选择下一工具，适合：

自然语言意图；
开放式分析；
步骤数量不固定；
多种信息源的动态选择。

最成熟的组合¶

确定性入口
→ Agent 分析/选择只读工具
→ 确定性校验
→ 人工审批
→ 确定性副作用执行

模型不需要控制所有步骤。

用图表达状态¶

以故障诊断为例：

parse_request
→ validate_device
→ agent_collect_evidence
→ deterministic_checks
→ generate_report
→ [需要维修?]
     ├─ 否 → end
     └─ 是 → approval → create_ticket

Node 粒度¶

一个节点只做一件可观察、可重试的事。过大的节点：

无法知道失败位置；
恢复会重复更多副作用；
不容易设置不同超时和重试；
评测困难。

过小则增加状态和编排复杂度。以独立失败、独立重试和独立观测为边界。

错误属于流程¶

暂时错误：有限重试；
模型可修复：返回结构错误让模型修复；
用户可修复：暂停等待输入；
权限错误：直接失败；
未知错误：记录并人工处理。

自测¶

哪些步骤必须保持确定性？
为什么生产系统不是“全部 Agent 化”？
Node 应该按什么边界拆分？
权限错误为什么通常不应该重试？

完成标准¶

能为一个业务划分 Workflow 和 Agent 节点
能画出条件和人工审批分支
能按错误类型设计处理
能解释节点粒度取舍