为什么同样一个任务，有时适合用工作流，有时必须放给 Agent？核心在于『提前能否枚举所有路径』。工作流是顺序/条件/并行节点组成的确定性剧本，适合标准化重复任务（如订单处理必须走校验→支付→物流）。Agent 是目标驱动的自主推理体，适合开放场景（如个性化搜索、版式各异的 PDF 解析）。两者的混合架构正成为主流：用工作流控制『必须守死的流程』，用 Agent 处理『不确定的中间步骤』，比如审批流程中 Agent 辅助生成意见，但状态流转仍由工作流引擎掌控。

作者用 Langfuse 对比工作流，但 Langfuse 本质是『事后』的 LLM 可观测性平台——它记录的是每一次调用的 Trace（模型、token、耗时），而非『事前』的流程设计图。阿里云等厂商已将其作为 Agent 可观测性组件嵌入，核心解决『黑盒推理』问题，比如定位 P95 延迟飙升是卡在哪一步模型调用上。但就像作者的判断：Trace 能把足迹画出来，却管不住脚往哪走。两者的本质区别是『记录路径』和『规划路径』的区别，不在一个决策层级。

作者提出的『问』——错了收不回的必须让人点头——在 2026 年已不仅是工程经验，而是法律硬约束。最高法 9 月发布的 AI 纠纷意见明确：AI 产品责任不只看『模型是谁的』，更看『谁能控制风险』。企业用 AI 客服出错，可能同时牵出模型商、集成商、业务方的连带责任。Microsoft 推出的 AI 共担责任模型也把『人工复核』作为 PaaS 层必备控制项。换言之，不去设计『问』环节，每一份 AI 自动结论都可能变成事故报告。

作者给出了『定-放-问』三原则，但在实际操作中，很多团队在第一步『定』之前就踩坑：没有划清 Agent 的目标边界、输入边界、权限边界、验收边界和接管边界。比如让 Agent『分析用户反馈』，它会自动补上下文，但补的很可能不是你想要的——然后生成一份『看起来合理但重点全歪』的报告。真正该问的不是『Agent 有多聪明』，而是『它进来以后，谁的成本降低了，谁的风险增加了，谁还要负责最后判断』。这五条边界清单，写在买工具之前。