Agent Workflow 一旦承载长任务、人工确认和真实工具，它就不再是一张可以随手改的流程图。运行中的实例可能停在旧节点，等待一个旧 schema 的工具结果；这时删节点、换工具或调整状态含义，会让恢复逻辑无法解释历史。
我会像发布代码一样发布 Workflow：源码构建成不可变 definition，锁定 Prompt/模型/工具/策略依赖，通过静态检查和回归后灰度。新版本默认只接新 Run，旧实例继续原版本，确需迁移则使用显式 migration plan。
邓明瑞 / 纯粹
企业 Agent 先做 Workflow：自由度应该放在真正需要判断的地方
企业里讨论 Agent，常从“让模型自己规划并完成任务”开始。实际落地时，很多目标早已有明确步骤：查元数据、生成 SQL、跑验证、等待确认、发布结果。把这些步骤全部交给模型动态决定，会增加成本和不确定性，却没有增加业务价值。
我的默认选择是先做 Workflow。运行时控制阶段与状态，模型只出现在需要语言理解或候选判断的节点。只有任务路径确实无法预先枚举、并且工具与权限边界已经成熟，才开放有限 Agent loop。
