选型的第一个问题不是「用哪个框架」，而是「这件事到底需不需要模型来决定下一步」。
三种形态
聊天机器人：输出是文本
用户问，模型答。没有外部行动，没有状态推进。适合知识问答、写作、翻译、头脑风暴。
它的工程重点在提示与知识：回答是否准确、语气是否合适、是否引用来源。
工作流：控制流由代码决定
开发者把步骤写死：先查订单，再判断状态，然后调用退款接口，最后发邮件。模型可能出现在其中某些节点（例如分类、抽取、生成文案），但下一步做什么由代码决定。
工作流的优势是显然的：
- 每一步都可测试、可断言；
- 失败可以精确重试，不会「即兴发挥」；
- 延迟和成本可预测；
- 审计日志天然清晰。
Agent：控制流由模型决定
模型看到当前状态，自己决定调用哪个工具、传什么参数、是否需要继续。代码提供工具、约束和循环，但不规定路径。
这带来了处理开放问题的能力，也带来了三个新问题：不可预测、成本随步数增长、错误会累积。
模型只生成内容
模型填充节点
代码提供边界
一张选型表
| 判断维度 | 倾向工作流 | 倾向 Agent |
|---|---|---|
| 步骤是否可枚举 | 可以，且稳定 | 不能，依赖中间结果 |
| 输入形态 | 结构化、字段固定 | 网页、文档、自然语言 |
| 成功标准 | 可写成断言 | 需要判断与综合 |
| 错误代价 | 高、不可逆 | 可检测、可回滚 |
| 调用量 | 很大，成本敏感 | 中等，价值密度高 |
| 延迟要求 | 严格 | 可接受数十秒 |
| 维护者 | 业务/后端团队 | 有 AI 工程能力 |
一个常被忽略的事实：工作流也可以很智能。在固定骨架里放一个会判断的节点，往往比让模型从零规划整条链路更稳。例如：
接收工单
→ 规则过滤（垃圾邮件、空内容）
→ 模型分类（账单 / 技术 / 退款 / 其他） ← 不确定节点
→ 按类别走不同子流程 ← 确定性
→ 模型草拟回复 ← 不确定节点
→ 金额 > 500 元转人工 ← 确定性
→ 发送并记录这条链路只有两个节点需要模型判断，其余都可测试、可审计。它比「给 Agent 十个工具让它自己看着办」更容易上线。
工作流的四种基本模式
- 串行链（Chain）：A → B → C。适合步骤固定、前后依赖的任务。
- 路由（Routing）：先分类，再走不同分支。分类器可以是模型，也可以是规则。
- 并行（Parallel）：多个独立子任务同时执行，再汇总。适合多源检索、批量生成。
- 编排者—工人（Orchestrator-Workers）：一个节点负责拆分与汇总，多个节点执行。它已经接近多智能体，但控制流仍由代码约束。
把这四种模式组合起来，绝大多数「Agent 需求」都能被更稳地表达。
Agent 的三档自主度
自主性不是一个布尔值，而是一个旋钮：
| 档位 | 行为 | 例子 | 风险 |
|---|---|---|---|
| 建议 | 只给建议，人执行 | 代码补全、回复草稿 | 低 |
| 审批后执行 | 准备动作，人确认 | 退款、发邮件、改配置 | 中 |
| 受限自主 | 在权限与预算内自动执行 | 只读检索、沙箱内跑测试 | 中 |
| 完全自主 | 无人工介入 | 长期运行的监控 Agent | 高 |
产品设计时，应该按动作风险分档，而不是整个系统统一一个档位。读取公开网页可以自主，发送对外邮件需要审批，删除数据禁止自动执行。
读操作放宽，写操作收紧。 检索、查询、读文件可以大胆放开；创建、修改、删除、支付必须有幂等、限额或人工确认。
成本差异有多大
假设一个任务需要 5 次模型调用：
- 工作流：4 次小模型分类/抽取 + 1 次大模型生成，输入稳定、可缓存，单次约 0.01–0.05 元；
- Agent：每步都带完整历史和工具定义，5 次调用、每次输入 8k token，单次约 0.1–0.5 元。
差距可能是 10 倍。如果每天 10 万次调用，这就是每月数十万元的差别。更麻烦的是，Agent 的步数分布有长尾：P95 可能是 15 步，成本按平均值估算会严重偏低。
混合架构：把不确定性关进笼子
生产系统最常见的样子是：
具体做法：
- 用状态机管理流程，Agent 只能在某个状态内活动；
- 给 Agent 设定最大步数、token 预算和超时；
- 工具层做参数校验与权限检查，不信任模型输出；
- 高风险动作走审批队列，而不是同步执行；
- 全链路 trace，出问题能回放到具体一步。
四个反模式
用户并不关心背后是不是自主规划。他们关心的是快、准、便宜。一个稳定的表单流程胜过一段炫技的自主循环。
「模型可以调用任何工具」意味着「模型可以犯任何错」。工具越多，选择空间越大，误用概率越高。只暴露完成任务必需的工具。
工作流改坏了，测试会挂；Agent 改坏了，可能只是「感觉不太对」。没有黄金集和轨迹评估，你无法判断一次提示词修改是进步还是退步。
平均值 3 步，不代表用户不会遇到 30 步。预算、超时和降级必须按 P95/P99 设计，而不是按平均值。
一个可执行的选型流程
- 写下任务的步骤。如果能在 15 分钟内画出一条完整流程图，先做工作流。
- 标出不确定节点。哪些地方必须「看情况」？只在这些节点引入模型判断。
- 评估错误代价。错了能不能发现？能不能撤销？不能，就加人工或只读限制。
- 算一笔账。按 P95 步数估算 token 成本，和人力成本对比。
- 做一个小实验。用 30 条真实样本对比「工作流 + 模型节点」与「自主 Agent」的成功率、延迟、成本。
如果实验结果显示 Agent 只多解决了 5% 的案例，却贵了 8 倍，那答案很清楚。
小结
- 聊天机器人输出文本，工作流输出确定的流程，Agent 输出由模型决定路径的行动。
- 大多数业务问题应该先尝试工作流，只在无法枚举的节点引入 Agent。
- 自主性应分档授予：读放宽、写收紧、不可逆动作必须审批。
- 混合架构不是妥协，而是工程上的正确答案。
下一篇补齐底座：Agent 开发者真正需要理解的 LLM 机制。