能用固定流程描述的，就别上智能体。判断标准只有一句话：你能否提前画出这张流程图？能画出、步骤数可预期的，用工作流；画不出、步骤数取决于中间结果的，才用智能体。选错的代价是成本翻倍且不可控。
两者的本质差别
| 维度 | 工作流 | 智能体 |
|---|---|---|
| 路径 | 预先定义，节点与边固定 | 运行时决定，循环调用工具 |
| 可预测性 | 高，同样的输入同样路径 | 低，路径依赖模型判断 |
| 成本 | 模型调用次数可控 | 可能多轮，成本与延迟不可控 |
| 适用场景 | 步骤确定、需合规留痕 | 开放式问题、步骤数不可预知 |
Anthropic 的判断很直接：智能体适用于难以或无法预测所需步骤数、且无法硬编码固定路径的开放性问题；如果任务的解决路径已知，写清楚流程往往比让模型自由发挥更好。
四个判断问题
- 步骤能提前列全吗？能 → 工作流。
- 失败有明确恢复动作吗？没有，需要临场判断 → 智能体。
- 需要审计与确定性吗？需要 → 工作流（可用图引擎显式建模状态）。
- 成本敏感吗？敏感 → 工作流，把模型调用压到必要节点。
现实里大多是混合体
LangChain 的技术栈划分说明了这一点：LangGraph 的定位是”在同一工作流中混合确定性与智能体步骤”，支持人工审批、中断、重试与容错。真实系统通常长这样：外层是确定性骨架（取数、校验、落库、通知），内层某几个节点是模型决策或子智能体。
从工作流升级到智能体的信号
出现这三条就该考虑升级：一是规则分支数量爆炸，维护成本超过收益；二是中间结果需要判断才能决定下一步；三是任务输入天然开放式，无法枚举。升级时不要整体替换，只把最不确定的那个节点换成智能体。
落地建议
- 先写死成功路径：先用确定性代码跑通一次完整任务，再决定哪一步交给模型。
- 用图而不是链：需要重试、回滚、人工介入时，链的表达能力不够。
- 给停止条件：最大迭代次数、预算上限、超时，缺一不可。
- 保留降级开关：智能体节点失败时能回落到固定规则路径。
相关阅读：智能体规划模式、多智能体编排、编码代理沙箱环境。框架选型可参考 LangChain 入门教程。
了解智能体规划模式智能体一定比工作流高级吗？
不是。智能体是用不确定性换灵活性。流程确定时用工作流，成本更低、行为可预测、更容易通过审计。
能不能先上智能体，跑通后再固化成工作流？
可以，而且是推荐路径。先让智能体探索出有效路径，再把稳定下来的路径固化成确定性流程，成本与稳定性都会改善。
混合架构怎么划分边界？
凡是涉及外部副作用、需要事务保证、需要留痕的步骤放确定性节点；只有需要理解与判断的步骤放智能体节点。
多智能体是不是更好？
多智能体增加协调成本与错误传播面。只有在单智能体上下文不够或需要并行专才时才考虑，不要为了架构好看而上。
评论 (0)