43 Agent 与 Workflow：固定流程和动态决策的边界
Agent 与 Workflow：固定流程和动态决策的边界
Agent 不比 Workflow 天然高级。固定流程适合确定性任务，Agent 适合需要动态理解和选择工具的任务。
[TOC]
1. 先把 Agent 想清楚
很多人一听到 Agent，就会想到“让大模型自己决定下一步”。这个理解只对了一半。
在真实项目里，Agent 更像是一个被工程规则约束住的任务执行器：
模型负责理解自然语言、提出候选动作
代码负责权限校验、状态流转、工具执行
业务接口负责最终事实和写操作
日志审计负责事后追踪
如果一个任务本来只有三个固定步骤，却硬塞给模型决定下一步，系统会变得更贵、更慢、更难测试。
所以这一阶段的博客不要写成“模型越来越聪明”。更准确的写法是：我们正在学习如何把模型的灵活性放进一个可控的工作流里。
2. 一个业务场景
用户说：“我的订单坏了，帮我看看怎么售后。”系统可能先查知识库，也可能查订单，也可能创建工单。这里需要动态判断。但真正创建工单前，仍然要走固定校验和用户确认。
这个场景里面最重要的不是模型能不能说出一段好听的话，而是：
它选了哪个工具
为什么能调用这个工具
参数从哪里来
权限在哪里校验
失败后状态怎么变
用户确认前会不会产生真实写入
把这些问题问清楚，Agent 项目才不会变成一个不可解释的聊天黑盒。
这一节要先判断边界，而不是直接说“用 Agent”。
1. 如果路径固定、风险高、结果必须稳定，优先 Workflow
2. 如果用户表达开放、路径不固定、需要动态选工具，才考虑 Agent
3. 如果涉及写操作，Agent 只能提出意图，真正执行必须进入固定流程
4. 每个动态决策都要有可枚举的结果，不能让模型临时创造流程节点
5. 最后用测试样例证明：同一个输入会进入可解释、可审计的路径
它解决的是决策边界问题：什么时候该灵活，什么时候必须确定，而不是比较两个名词谁更高级。
3. 核心概念
1. Workflow
步骤和分支由代码预先定义，适合审批、支付、创建工单等高风险动作。
这一点在项目里要落到具体规则：高风险动作优先固定流程。
2. Agent
模型根据上下文选择工具和下一步，适合入口自然语言复杂、路径不完全固定的任务。
这一点在项目里要落到具体规则：模型负责理解和路由。
3. 状态机
用状态记录当前任务位置、工具结果、等待确认和终态。
这一点在项目里要落到具体规则：状态让流程可恢复。
4. 混合模式
生产系统常用 Agent 做理解，Workflow 做执行。
这一点在项目里要落到具体规则：灵活和确定性要组合。
4. 整体流程
graph TD;
A["用户自然语言"] --> B["模型识别意图"];
B["模型识别意图"] --> C["代码路由到允许分支"];
C["代码路由到允许分支"] --> D["工具查询或检索"];
D["工具查询或检索"] --> E["必要时进入确认"];
E["必要时进入确认"] --> F["Workflow 执行业务动作"];
F["Workflow 执行业务动作"] --> G["返回结果"];
这张图里，模型只是其中一个节点。工具、状态、权限、确认和审计同样重要。
如果一个 Agent 图里只有“用户 -> 模型 -> 答案”，那它还只是 Chat，不是能进入业务系统的 Agent。
5. 落地步骤
1. 按风险分类
只读查询可以更动态，写操作必须更确定。
完成后应该能看到：一张动作风险表。
2. 定义允许路径
路由只能返回预定义节点，不能让模型创造节点名。
完成后应该能看到：路由枚举。
3. 设置终止条件
最大步数、最大工具调用、超时和失败状态必须明确。
完成后应该能看到：状态机终态清单。
4. 把写动作独立出来
创建、修改、删除都放到确定性节点，并加权限、确认和幂等。
完成后应该能看到：写操作节点设计。
6. 状态、接口或工具字段
| 项目 | 说明 |
|---|---|
| taskType | 任务类型 |
| riskLevel | 风险级别 |
| decisionOwner | 模型或代码 |
| allowedTools | 可用工具集合 |
| terminalState | 成功、失败、等待确认等终态 |
字段设计要尽量结构化。不要让下游通过一段自然语言去猜“成功了没有”“下一步要干什么”。
7. 示例
适合 Workflow：退款审批、工单创建、权限变更
适合 Agent：理解用户问题、选择查知识库还是查订单、整理多工具结果
推荐组合：Agent 负责理解，Workflow 负责关键动作
示例里的字段不一定照搬，但思想要保留：输入、状态、输出、错误和审计信息要分开。
8. 哪些事不能交给模型自由发挥
权限授予、支付退款、删除数据、创建工单、修改订单状态都不能只靠模型决定。模型可以提议，但执行要经过代码规则。
这一节特别重要。Agent 项目最容易踩坑的地方，就是把“理解意图”和“执行业务动作”混成一件事。
模型可以建议动作，但最终执行必须经过代码和业务系统的规则。
9. 测试路径
建议至少准备下面几类测试：
正常路径：输入完整，工具正常返回
缺字段路径：订单号、联系方式、问题描述不完整
权限路径：查询别人的订单、访问无权知识库
失败路径：工具超时、模型输出非法、检索为空
恢复路径：等待确认时服务重启、重复确认、超时确认
Agent 的测试不能只看最终回答。你要检查状态、工具调用、审计日志和是否产生真实副作用。
10. 工程取舍
- Workflow 可测试性强，但对自然语言入口不够灵活。
- Agent 灵活，但必须限制工具、步数和权限。
- 混合方案更符合真实业务系统。
取舍讲清楚以后，读者才能知道你为什么这样设计，而不是以为所有问题都要上 Agent。
11. 常见坑
- 为了使用 Agent 把简单流程复杂化。
- 模型可以访问任意工具。
- 没有最大步数导致循环调用。
- 把自然语言回答成功当成业务执行成功。
这些坑本质上都和一个问题有关：没有把模型输出当成“不可信的候选结果”。
12. 验收清单
- ☐ 能说明哪些步骤用 Agent
- ☐ 写操作有固定校验
- ☐ 状态机有终止条件
- ☐ 工具集合受限
- ☐ 关键路径有测试
如果这些检查项没过，先不要急着加更多工具。工具越多，边界越乱，排查越难。
13. 落地清单
- ☐ 列出 10 个业务动作并按风险分级
- ☐ 画出 Agent + Workflow 混合图
- ☐ 设计最大步数和终止状态
- ☐ 写一个不用 Agent 更合适的反例
练习时可以先用 Mock，不要一开始就连真实订单或工单系统。等状态、权限和幂等设计清楚后，再接真实接口。
14. 小结
Agent 和 Workflow 不是对立关系。真正可用的系统，通常是用 Agent 处理不确定入口，用 Workflow 兜住确定性执行。
Agent 的价值来自灵活性，但安全来自边界。能把这两件事同时讲清楚，才算真正理解 Agent 工程化。