Agent 与工作流的边界
本节目标
学完后，你应能：
- 在单次调用、确定性程序、LLM 工作流和 Agent 之间做可解释选择。
- 用任务不确定性、可验证性、风险、成本和失败恢复决定自治等级。
- 设计“固定外壳 + 局部自治”的混合架构。
- 通过 baseline/eval 证明 Agent 的复杂度确有收益。
四种结构，不是两个标签
| 结构 | 谁控制路径 | 适合场景 | 典型例子 |
|---|---|---|---|
| 确定性程序 | 代码/规则 | 输入和变换完全可定义 | 定时复制文件、校验 JSON |
| 单次 LLM 调用 | 应用只调用一次模型 | 受控摘要、分类、抽取 | 从工单提取字段 |
| LLM 工作流 | 代码预定义步骤/分支，模型完成局部判断 | 路径大体可知、需语言理解 | 解析→校验→审批→入账 |
| Agent | 模型根据环境反馈动态选择步骤和工具 | 路径/步数难预设、需探索与纠错 | 在未知仓库中定位回归 |
Anthropic 的第一方工程文章把 workflow 描述为预定义代码路径，把 agent 描述为模型动态控制过程与工具使用。OpenAI 的工程指南也把 Agent 的核心放在模型管理执行、动态选择工具并能在失败时停止/交还控制。两者都建议从简单方案开始。
这不是产品命名争论。一个名为“Agent”的 SDK 流程可以完全是固定工作流；一个没有框架的短 loop 也可以是真正的 Agent。
六个选型问题
1. 下一步是否依赖未知观察
如果在设计时能列出绝大多数步骤与合法分支，优先工作流。若必须探索环境、每次观察都会改变下一步，Agent 才有明显价值。
2. 成功是否可验证
Agent 会放大错误链。若无法定义外部成功证据，先改善任务和 verifier，而不是增加自主规划。
3. 风险是否可隔离和恢复
若错误会产生不可逆财务、法律、人身或公开沟通影响，应降低自治：用候选生成、人工审批、沙箱或固定工作流包住高风险步骤。
4. 规则是否已复杂到难维护
大量例外、非结构化材料和上下文判断可能适合模型；但“规则多”也可能说明领域模型或数据质量有问题。先比较规则/分类器 baseline。
5. 延迟与成本是否允许多轮
Agent 每轮都可能调用模型和工具，尾延迟、成本、限流与复合失败都会增长。质量提升必须通过真实任务集衡量。
6. 操作者能否理解和接管
必须能看到进度、停止原因、已产生副作用和下一审批对象。无法安全接管的自治不是成熟设计。
一个实用评分表
每项 0–2 分：
| 维度 | 0 | 1 | 2 |
|---|---|---|---|
| 路径不确定性 | 固定 | 少量分支 | 需持续探索 |
| 环境反馈 | 无 | 一两次 | 多轮决定下一步 |
| 成功验证 | 确定 | 部分人工 | 可自动验证但路径开放 |
| 可恢复性 | 难恢复 | 可审批/补偿 | 沙箱、幂等、检查点完备 |
| 规则维护 | 简单 | 中等 | 语言/例外高度复杂 |
| 多轮收益 | 无证据 | 小样本有效 | 评测稳定显著 |
评分不是自动决策：
- 路径与反馈低：确定性程序/单次调用。
- 中等：LLM 工作流或 router。
- 路径与反馈高，且验证/恢复也成熟：局部或完整 Agent。
- 风险高但恢复差：无论总分多高，都不应直接全自动。
固定外壳，自治内核
常见稳健结构：
确定性入口
→ 身份、输入、目标与预算校验
→ [受限 Agent：探索、检索、生成候选]
→ 确定性 verifier
→ 审批 / 固定提交步骤
→ 审计与补偿例如退款系统：
- 固定：鉴权、订单归属、法定期限、最大金额、支付 API、审计。
- Agent：从非结构化对话中定位问题、收集缺失材料、提出退款理由与候选金额。
- 人工/规则：超过阈值、冲突证据或高风险账户。
模型不应自由决定资金权限、收款账户或是否绕过审计。
自治不是开关
可以逐级增加：
- 建议：只生成计划/候选，不执行工具。
- 只读 Agent：可探索，不能写。
- 受限写入：写动作逐项审批。
- 规则内自动写入：低风险、幂等、小范围自动；超界暂停。
- 长任务自治：有持久检查点、预算、监控与接管。
每升一级都要增加相应 eval、安全和恢复证据。不要用“模型更强了”替代风险论证。
典型模式怎样归类
| 模式 | 默认归类 | 何时变成 Agent |
|---|---|---|
| prompt chaining | 工作流 | 模型能动态选择是否/如何继续 |
| routing | 工作流 | router 可循环探索并改路 |
| parallelization | 工作流 | 子任务集合由模型动态生成与收敛 |
| evaluator–optimizer | 工作流 | 迭代次数/工具/路径由模型动态控制 |
| planner–executor | 取决于实现 | 计划可根据观察自由修改且步数开放 |
不要因出现多个 LLM call 就称为 Agent。
评测复杂度是否值得
建立三条 baseline：
- 规则或确定性脚本；
- 单次 LLM/固定 workflow；
- 受限 Agent。
用同一任务集比较：
- 任务成功与关键子目标；
- 人工介入率；
- 非法动作/安全违规；
- p50/p95 延迟与模型/工具成本；
- 平均步数、重复动作与恢复成功率；
- 结果可解释/可审计性。
若 Agent 只提高少量主观“看起来更聪明”，却显著增加成本和失败面，应回退到更简单结构。
反例与改造
固定报表上传
“每天 9 点读取固定 CSV，校验后上传固定位置”使用调度器 + 脚本。LLM 只可用于异常解释；无需 Agent 动态决定路径。
未知仓库性能回退
需要探索文件、运行不同测试、根据 profile 调整假设，路径难预设。可使用 Agent，但：
- 限制仓库与命令；
- 默认只读，修改走 diff；
- 时间/步骤上限；
- 完成必须有 benchmark 证据。
客服退款
不要让 Agent 直接全自动退款。把材料理解做成局部 Agent，把身份、金额、账户、审批与支付提交放固定外壳。
动手练习
选择以下任务并完成 ADR：
- 自动处理客户退款；
- 迁移 500 个 Markdown；
- 调查生产 API 延迟上升；
- 每周生成固定报表。
ADR 至少回答：选择哪一级自治、为什么不用更简单方案、哪些动作固定、成功证据、预算、最坏失败、人工接管和回退方案。
自测
- workflow 与 Agent 的核心区别是谁控制执行路径，还是是否使用 LLM？
- 为什么“规则很多”不足以证明需要 Agent？
- 哪些高风险步骤应留在固定外壳？
- 如何用 baseline 证明多轮 Agent 的价值？
- 只读 Agent 与自动写入 Agent 需要的验证证据有什么不同？
能写出一份有 baseline、风险和回退的选型 ADR，才算掌握。
下一步
进入 状态、上下文与记忆，让选定的 Agent 能跨多轮保持事实一致。
参考资料
以下为第一方工程资料，获取/复核日期：2026-07-21。