先这样答
两者的分界线在「下一步由谁决定」。Workflow 里步骤是工程师预先编排的：先抽取、再校验、然后生成、最后人工审核，模型只负责每个节点内的任务，控制流是写死的。Agent 里控制流交给模型：它看着当前状态决定调什么工具、走哪条路，代码只提供工具和护栏。
工程性质上差别很大。Workflow 可预测、可测试、好排查：失败发生在哪个节点一目了然，成本稳定可估。Agent 灵活、能处理意外路径，但行为有波动、成本不可精确预估、测试要靠评测集而不是单元测试。
所以「什么时候不该用 Agent」的答案很直接：只要你能把任务的决策流程画成一张有限的流程图，就该用 Workflow 或者干脆是普通代码。发票识别、固定格式的审批流、模板化的内容生产，这些任务路径是确定的，上 Agent 只会引入不必要的波动和成本。该用 Agent 的是路径真不确定的任务：开放式的排查、调研、多方案的取舍，事先无法穷举分支的那种。
实践里最健康的形态是混合：整体骨架是 Workflow，个别节点内部是小 Agent。比如客服系统，工单分类、路由是流程，疑难工单的排查节点交给一个带工具的 Agent，跑完回到流程里继续走。按「确定性就用流程，不确定性才给自主」这条线分配，系统才又稳又省。
面试官会怎么追问
- 为什么说上 Agent 是负收益？ 波动是成本：同一任务轮数不同、路径不同，错误率更高、排查更难，这些代价换不来任何收益，因为任务本来不需要自主决策。
- 怎么判断我的任务属于哪类？ 拿历史 50 个案例画路径：分支能数清的走 Workflow；分支数不清、且不同案例路径差异大的，才考虑 Agent。
- 从 Workflow 起步，什么时候升级成 Agent？ 出现流程图装不下的分支时：某个节点总是要人工介入做判断，把那个节点换成 Agent 是最自然的演进路径。
回答的坑
- 把 Agent 当万能解。敢说「这个场景别用 Agent」的候选人反而更可信。
- 不谈可测性。Workflow 单元测试、Agent 评测集，工程手段的差异是面试官想听的细节。
同系列的题
—— 本题完 ——