【从零理解 Spring AI · 16】Agent 与工作流：什么该写死，什么该让模型决定
写在开头
第四辑结束时，你手里已经攒齐了所有"零件"：稳定对话、结构化输出、流式、记忆、工具调用、检索增强。
现在到了拼整机的时候------用户问一个复杂问题，你的应用该按什么流程调用这些能力？
这一步有一个特别容易踩的坑：把"Agent"当成万能答案，什么都想让它自主决定。 这篇先讲清 Agent 和工作流的本质区别，把"什么该写死、什么该交给模型"这条边界画出来。
一、两种组织方式
1.1 工作流（Workflow）：流程写死，代码驱动
java
// 餐厅评论处理：三步固定流程
public String handle(String review) {
String category = model.call("判断这条评价属于：好评/差评/建议。评价：" + review);
String detail = model.call("提取评价里的具体问题点：" + review);
String reply = model.call("以客服口吻写一条回复，类型:" + category + "，要点:" + detail);
return reply;
}每一步干什么、上一步的输出怎么用，全是程序员写死的------像炒菜机器人：放油 → 炒蛋 → 加盐 → 出锅，顺序固定，鸡蛋坏了它也不会停。
1.2 智能体（Agent）：模型动态决策
java
// 不预设步骤，给模型工具和目标，让它自己决定走几步、怎么走
String answer = chatClient.prompt()
.user("帮我把这两天的差评汇总一下，重要的先整理，然后给相关用户各发一条安抚消息")
.tools(reviewTools, messageTools) // 给能力，不给流程
.call()
.content();
// 模型自己：先查差评 → 判断哪些"重要" → 逐条整理 → 逐个发消息
// ------中间可能调十几次工具，每一步都是它当下决定的像米其林主厨 ：看今天食材新不新鲜、客人有没有忌口，自己决定菜单和火候------会看结果、会调整、会返工。
炒菜机器人 vs 主厨
二、一张表看清取舍
| 维度 | 工作流 | Agent |
|---|---|---|
| 流程 | 写死，代码驱动 | 动态，模型决策 |
| 结果 | 可预期、可测试 | 不可完全预期 |
| 成本 | 可控（步骤固定） | 不可控（步骤数量模型定） |
| 调试 | 好排查（哪一步坏了很明显） | 难排查（决策链不透明） |
| 适合 | 流程明确的任务 | 路径无法预知的开放问题 |
核心认知：Agent 的灵活性不是免费的。 它每一步"自主决策"都意味着：可能选错工具、可能步骤冗余、可能陷入循环、出了问题你只能看日志倒推它为什么这么走。
三、选型铁律：能写死就写死
这条边界比大多数人想的要偏保守：
流程能写死就写死（工作流）。只有"路径无法预知、必须边看边决定"的问题，才交给 Agent。
用三个问题自测：
- 这个任务的步骤能提前列出来吗？ 能 → 工作流；
- 每步的输入输出形态固定吗？ 固定 → 工作流；
- "下一步做什么"必须依赖上一步的真实结果才能判断吗？ 是 → 这一步可以考虑 Agent。
现实系统几乎都是混合形态：骨架用工作流（保证主干可控），个别环节内嵌 Agent 的自主决策（处理开放子问题）。比如客服系统：分类、查订单、生成回复都是写死的流程；中间"综合判断用户情绪并决定补偿方案"这一个开放环节，才交给模型自主决策。
四、给 Agent 系上刹车：三个必备的限制
决定用 Agent 之后，第一件事不是兴奋，而是上刹车。模型自主决策意味着步骤数量不可控，没有限制的 Agent 循环就是一张无限烧钱的支票。三个必备限制：
① 最大步数。给一次任务设硬上限（比如最多 15 次工具调用），到顶立即停------宁可返回"未能完成"，也不能无限跑下去。Spring AI 里工具调用次数有内置上限保护（第 10 篇讲过的配置），Agent 场景要显式检查这个配置。
② 预算意识 。每一步都是一次模型调用。一个"整理差评并发消息"的任务如果涉及 50 个用户，可能是 100+ 次调用------上线前用真实任务量估算成本，别到账单出来才发现。
③ 结果校验 。Agent 声称"已完成"，不等于真的完成了。关键操作（发消息、写库）的落库结果要有独立核验------信任但要验证，这是对自主系统的基本态度。
还有一条工程实践：Agent 的每一步都记日志。决策链不透明是 Agent 最大的运维痛点，事后排查全靠"它第几步调了什么工具、传了什么参数"的完整轨迹。
五、为什么这篇放在工具调用之后
注意第 1.2 节的 Agent 代码------它没有任何新的 API。
.tools(...) 是第 10 篇的工具调用，模型自主决定调用哪个工具、循环几轮，靠的是第 10 篇的 ToolCallingAdvisor 驱动的循环。所谓 Agent，就是"给足工具和目标，让模型的自主决策驱动多轮工具调用"------零件全是前面几篇的，只是组装方式变了。
这也解释了为什么工具调用的安全设计那么重要：在 Agent 模式里，模型的决策链变长了，你的工具白名单、参数校验、调用上限就是全部的安全边界。
六、这篇的四个要点
- 工作流 = 流程写死：可预期、可测试、成本可控；缺点是僵硬。
- Agent = 模型动态决策：灵活、能处理开放问题；代价是不可预测、难调试、成本不可控。
- 选型铁律：能写死就写死；只有路径无法预知的开放问题才上 Agent。
- 现实是混合形态：工作流当骨架、Agent 做局部，且 Agent 的本质就是"工具调用循环"的组装方式。
延伸思考
如果决定用 Agent 或混合形态，接下来就是设计问题：多步任务怎么拆、几个模型调用怎么编排、结果怎么合并？
这些编排方式其实是有"套路"的------业界总结了五种基础模式，覆盖了绝大多数场景。下一篇一次讲全。
下一篇
《五种工作流模式：把复杂任务拆开》------链式、并行、路由、编排-工作者、评估-优化：每种模式怎么运作、适合什么任务、代价是什么。专栏收官篇。
本专栏按 Spring AI 当前版本讲解。