讨论 Workflow 和 Agent 时，人们常把“更智能”当成选择标准。这个标准很容易把产品带偏。
我更愿意问：任务里的不确定性由谁承担，出了问题以后谁能定位、谁来负责。
谁承担不确定性
Workflow 把主要判断放在设计阶段。输入经过哪些节点，什么时候分支，输出满足什么格式，通常都提前写清楚。运行时遇到异常，系统按已经定义的规则降级或停止。
Agent 把一部分判断留到运行时。它根据目标选择下一步，决定是否调用工具、是否继续搜索、现有结果是否足够。它能处理更开放的任务，也会带来更难预测的路径。
这不是技术高低之分。它决定了系统的责任结构。
先看错误代价
如果一个任务步骤清楚，输出必须稳定，错误还会直接影响用户，就没有必要为了“像 Agent”而增加自主决策。可验证的 Workflow 往往更合适。
如果设计者只能定义目标，无法提前列出所有有效路径，而且每一步都需要根据新信息调整，Agent 才开始有价值。
还要看错误能不能被发现和纠正。可逆、低风险的试错可以留给 Agent；高风险结论需要明确的数据来源、权限、校验和人工责任。模型能力再强，也不能替产品补上这些约束。
混合形态更常见
真实业务很少要求整条链路都自主运行。更常见的做法是先把任务拆开，只在不确定性集中的节点使用 Agent，其余步骤继续用 Workflow 固定下来。
例如，检索策略可能需要根据结果动态调整，但引用格式、必填字段和发布 Gate 可以保持确定。这样既保留必要的灵活性，也让失败能够回到具体节点。
产品设计的重点不是给系统贴上 Agent 标签，而是决定哪些判断可以交给模型，哪些判断必须留在规则和人手里。
这条边界会移动
模型、工具和业务容错空间都在变化。今天需要多步决策的任务，明天可能被更稳定的模型和更清楚的流程简化；今天看似固定的步骤，也可能因为数据质量变化而需要重新判断。
所以我不会先决定“要做一个 Agent”。我会先画清任务、数据和失败路径，再找出真正无法预先定义的部分。
如果一个 Workflow 已经能稳定解决问题，就先用它。Agent 应该出现在不确定性确实存在的地方，而不是出现在方案名称里。