你可能遇到过这种纠结：同样是让 AI 干一串活，有人让你上自主 Agent，说它能自己规划、自己调工具；有人让你用可视化工作流，说节点连起来才可控。两边听完更懵了。这篇不讲概念定义，只讲工程上怎么分：什么任务适合放手让模型自己走，什么任务必须把步骤画出来，以及选完之后超时、并发、降级、日志该怎么铺。
你可能遇到过这种纠结：同样是让 AI 干一串活，有人让你上自主 Agent，说它能自己规划、自己调工具；有人让你用可视化工作流，说节点连起来才可控。两边听完更懵了。这篇不讲概念定义，只讲工程上怎么分：什么任务适合放手让模型自己走，什么任务必须把步骤画出来，以及选完之后超时、并发、降级、日志该怎么铺。
先说一句立场：这两种东西不是谁替代谁，而是两种不同的编排范式。自主 Agent 把「下一步做什么」的决策权交给模型，可视化工作流把决策权交给画出这张图的人。所以真正要问的不是「哪个更强」，而是「这个任务里，谁做决策更划算、更安全」。
先按任务形状分流，而不是按工具分流
很多团队选型的顺序反了——先定了工具，再想办法把任务塞进去。正确顺序是先看任务本身的形状。任务路径能不能提前画出来，通常比团队偏好更能决定选哪个。
- 路径是否预先确定
- 步骤固定、分支有限就画工作流；步骤要边做边看结果再决定下一步，才考虑自主 Agent
- 失败代价
- 出错后能重跑、结果可人工复核的，容忍自主决策；一出错就要赔钱或对外发内容的，优先把关键节点钉死
- 输入是否稳定
- 输入结构固定、字段可枚举的适合工作流；输入是开放问题、需要先探索再收敛的适合 Agent
有一种情况要直接排除：既想完全放手、又要求结果每次可复现。这两个诉求本身冲突，因为自主决策意味着每次路径可能不同。遇到这种需求，先砍掉一个再选，别指望用提示词把模型约束成确定性状态机——那还不如直接画工作流。
两种方式的花钱和变慢方式不一样
成本结构是选型时最容易被低估的一环。自主 Agent 的调用次数由模型自己决定，同一个任务两次跑可能差好几轮；工作流的路径是固定的，调用次数可以预估。这不是谁贵谁便宜的问题，而是预算怎么定、上限怎么设的问题。
| 维度 | 自主 Agent | 可视化工作流 |
|---|---|---|
| 调用次数 | 由模型每步自行决定，波动大 | 路径固定，可提前估算 |
| 成本上限 | 靠步数上限和工具白名单兜住 | 靠单节点重试次数和输出长度控制 |
| 延迟特征 | 多轮串行，天然偏慢 | 可并行铺节点，首字时间更好压 |
| 波动来源 | 任务复杂度差异、模型选择不同 | 单节点重试、上游数据量变化 |
具体单次成本怎么折算，到 /tools/model-cost-calculator 按你选的模型和预估 token 量算一遍，别凭感觉。延迟方面也一样，输入输出长度一变，数字就变，用当时的数据说话。
- 给 Agent 设一个「最大步数」，超过就中止并落日志，这是控成本最直接的手段
- 给每个工具调用记一次计数，跑完统计哪类任务步数明显偏高
- 工作流里把可并行的节点拆开，别串成一条长链
- 上线前用真实样本跑几轮，把成本分布和耗时分布记下来，而不是只看平均值
可控性和可调试性差在哪儿
出问题的时候，这两种编排的排查手感完全不同。工作流出错能定位到具体节点，把那个节点的输入输出抓出来重放就行；自主 Agent 要按调用链还原每一步决策，日志字段不够根本查不动。
- 第一步：分清是模型问题还是编排问题把同一份输入分别喂给单次模型调用和完整链路，看单次输出是否已经跑偏。跑偏就是提示词或模型选型问题，不跑偏再往下查编排。
- 第二步：抓单步输入输出工作流按节点抓，Agent 按调用轮次抓。重点关注「它为什么选了这个工具」，而不是只看最终结果对不对。
- 第三步：确认工具本身是否正常如果报错集中在参数格式上，先核对工具的参数定义和实际传入值是否匹配，工具参数类报错可以参考 /guides/tool-call-param-errors 那套对照。
团队协作层面还有个现实差异：工作流可以由不写代码的人改节点，Agent 的提示词和工具定义改动通常要开发介入。如果你的业务方经常要自己微调流程，这一条可能比技术指标更能决定选谁。
上线前要补的护栏和灰度动作
护栏不是上线后再加的补丁，而是选型的前提条件。选自主 Agent 之前先问自己：步数上限、工具白名单、单次任务成本上限、超时中止，这四样有没有。缺一样，这个方案就不该进生产。这些在 /guides/agent-runaway-guardrails 里已经讲透，这里只强调它是前置条件。
| 护栏项 | Agent 侧 | 工作流侧 |
|---|---|---|
| 执行边界 | 步数上限、超时中止 | 单节点超时、最大重试次数 |
| 权限边界 | 工具白名单、参数校验 | 节点可调用的工具集固定 |
| 失败处理 | 中止后落状态，人工介入 | 降级分支走哪个兜底节点 |
| 成本边界 | 单次任务成本上限 | 单节点输出长度上限 |
日志至少记这几项：任务 ID、每步输入输出摘要、耗时、token 数、命中哪个工具或节点、最终状态。缺了这些，事后没法复盘，也没法判断该不该调整编排方式。
- 灰度先放小流量跑通完整链路，再逐步放开，别一上来就全量
- 上线初期把人工复核放在关键节点后面，而不是放在最后一步
- 每次放开流量前对比一次成本分布和失败率，异常就回退
- 把复核结果反哺回提示词或节点配置，形成闭环
还有一条不适用的情况要说清楚：如果整个任务就是一次模型调用加排版，那既不需要 Agent 也不需要复杂工作流，硬上编排只会增加维护成本。选型的目的不是用上新东西，而是匹配任务。
下一步想对比不同模型在两种编排下的成本差异，先到价格追踪页看当时的数字，再决定用哪个模型去跑你的第一条链路。→常见问题
是不是步骤多就该用工作流，步骤少就用 Agent？
步数不是决定因素，路径是否可预先写死才是。三步但每步都要根据上一步结果换不同工具，工作流画起来会很别扭；二十步但每步条件都能枚举，画成工作流反而更稳更便宜。先问路径能不能提前定下来，再问步数。
两者能不能混着用？
可以，而且多数认真做的项目是混着的。常见做法是把确定性高的环节做成工作流节点，只在需要探索的那个环节里嵌一段自主决策，并在外面套上步数和成本上限。混用时最难的是边界划分：哪个节点交出去、回来时要求什么格式，这个格式约定没定好，后面全是脏数据。
选错了想换，迁移成本高吗？
取决于你把业务逻辑写在哪。如果逻辑全塞在提示词里，换编排方式等于重写；如果把工具定义、数据格式、校验规则抽成独立的一层，编排层只是调用它，迁移就只是换编排器。事前多做一层抽象，比事后重写便宜得多。
