如果任务路径可以在上线前画出来，而且执行会写数据库、发消息、改设备状态或触发审批，先用 Dify Workflow。如果目标明确但解决路径无法预先枚举、工具选择必须依赖中间发现，而且错误输出仍可由人复核，再考虑 Dify Agent。大多数企业项目真正需要的不是二选一，而是 Workflow 掌握入口、权限、写操作和结束条件，Agent 只处理边界清楚的推理子任务。
这个判断比“Agent 更智能、Workflow 更可控”更有用，因为生产系统的核心问题不是谁更聪明，而是谁拥有控制权：谁能选工具、谁能产生副作用、谁负责重试、谁能停止任务、谁能解释一次失败。Dify 官方文档把 Agent Strategy 描述为让 LLM 选择工具、调用工具并处理结果的推理逻辑，同时提供 maximum_iterations 约束；Workflow 则用节点、变量和显式分支组织任务。两者能力会重叠，但控制权不应重叠。
一分钟结论：先看副作用，再看推理自由度
选择顺序应当是：先判断动作出错后能否安全撤销，再判断路径是否真的未知。不要从“是否用了 LLM”开始，因为 Workflow 也可以包含 LLM 节点；也不要从“是否调用工具”开始，因为 Agent 和 Workflow 都能调用工具。真正区分它们的是，工具调用的选择权和顺序控制权是在设计时固定，还是在运行时交给模型。
| 生产条件 | Workflow | Agent | Hybrid |
|---|---|---|---|
| 步骤、分支和结束条件可预先描述 | 首选 | 没有必要 | 仅在局部语义任务使用 |
| 工具会产生不可逆或高成本副作用 | 首选，并加入审批、幂等和补偿 | 不应直接拥有写权限 | Agent 给建议，Workflow 执行 |
| 工具选择依赖连续发现，路径无法枚举 | 容易形成分支爆炸 | 适合 | 适合，外层保留预算与停止条件 |
| 每一步必须可重放、可审计 | 天然更容易 | 需要额外记录每轮模型与工具日志 | 外层可重放，内层保留推理轨迹 |
| 输出由人复核且无直接副作用 | 可以，但可能僵硬 | 适合 | 视后续动作决定 |
这张表的结论不是“所有生产任务都选 Workflow”。它说明：副作用越大，控制权越应该前移到确定性流程；探索空间越大，自主性才越值得放给 Agent。 如果一项任务既有探索又有写操作，混合架构通常比纯 Agent 更稳妥。
三次桌面演练：相同模型，不同控制边界
本次修订用 evidence/selection-replay.mjs 对三个合成场景做固定权重演练。权重覆盖路径可预测性、工具选择不确定度、副作用风险、审计重放要求和异常多样性。它不是 Dify 性能测试，而是把架构判断变成可复核的输入与输出。
第一个场景是发票审核：字段校验、额度审批和 ERP 写入都有明确顺序，错误写入需要补偿，审批还要留下责任链。演练结果选择 Workflow。这里让 Agent 自主决定是否跳过校验，不能带来足够收益，却会扩大重复写入、越权审批和无法重放的风险。LLM 可以负责票据字段解释或异常说明，但写入动作应继续由固定节点完成。
第二个场景是开放式资料研究：用户给出问题后，系统可能先搜索规范，再查厂商文档，随后因为证据冲突改查版本记录。路径依赖中间发现，最终结果只是建议，且有人复核。演练结果选择 Hybrid，纯 Agent 得分也高。外层 Workflow 可以固定数据边界、预算、引用格式和结束条件；内层 Agent 决定下一次检索工具及查询词。这样不会为了追求自主性而丢掉成本上限和引用要求。
第三个场景是告警处置：系统要先阅读告警、拓扑和运行手册，再决定是创建工单、请求人工批准还是执行受限修复。诊断路径多变，处置动作却有真实副作用。演练结果明显偏向 Hybrid。Agent 可以生成“最可能原因 + 建议动作 + 证据”，但 Workflow 必须验证资产、权限、维护窗口和幂等键，最后才调用写工具。
三次演练共同说明：不要按业务名称选择机制，而要按一次运行中哪一段需要探索、哪一段必须确定来切分。同一个客服、研究或运维应用里，读取和推理可以是 Agent，授权和副作用仍然可以是 Workflow。
控制权矩阵：把“智能”拆成五个可分配责任
第一项是工具选择权。Agent 的价值来自它能根据中间结果选择下一工具；但工具越多、描述越相似，误选概率和测试组合都会上升。生产设计应给 Agent 一个最小工具集，并把读取工具和写入工具分开。不要把“查库存”和“修改库存”包装成一个宽权限工具。
第二项是顺序控制权。Workflow 的节点顺序可以直接审查；Agent 的顺序来自模型在当次上下文中的判断。若法规、账务或设备安全要求先校验再执行，就应把顺序固定在 Workflow，不能只写进 system prompt 后期待模型永远遵守。
第三项是停止权。Agent Strategy 的 maximum_iterations 可以限制回合，但回合数不是完整预算。还要定义总 token、工具调用次数、单工具超时、累计费用和不可恢复错误。Workflow 外层适合统一执行这些停止条件，防止 Agent 在“还差一步”的循环中持续消耗。
第四项是错误处置权。Dify 的预定义错误处理支持停止、默认值和失败分支，并暴露 error_type 与 error_message。确定性流程可以把 rate limit 送到延迟队列，把数据校验错误交回用户，把关键写操作失败转人工。Agent 可以解释错误，但不应自行把关键错误改写成“成功”。
第五项是最终状态所有权。聊天回复可以由 Agent 生成；订单、工单、权限、设备命令和审计状态必须由业务系统确认。Dify 输出只能是请求或建议，成功状态要以目标系统的事务回执为准。否则日志里会出现“Agent 说完成了”，而业务对象实际没有改变的假成功。
矩阵给出的推荐是：把语义不确定性交给 Agent，把状态确定性交给 Workflow 与业务系统。 这不是保守地限制 AI，而是让每一层只承担它能验证的责任。
运维账本：没有运行证据，就没有可控的 Agent
Workflow 的可观测性重点是节点输入输出、分支、耗时、错误和重试；Agent 还要增加每轮模型选择、工具名、工具参数、工具结果、停止原因和累计预算。Dify Agent Strategy 的官方示例提供分层日志，可把多轮调用挂到 parent log；Dify 与 Weave 的集成文档列出 workflow_run_id、版本、token、状态、错误和节点执行信息。这些字段足以构造运行账本，但团队仍需决定保留期限、脱敏和告警规则。
建议至少记录四组指标。结果指标包括人工接受率、任务完成率和错误副作用；路径指标包括平均回合、工具误选和无效循环；资源指标包括 token、工具耗时与总费用；恢复指标包括失败分支命中、人工接管和补偿成功率。只看“回答看起来不错”会掩盖重试成本和偶发越权。
每次运行还要保留关联 ID。外层 Workflow run、Agent round、工具调用和业务事务应能互相追踪。没有这个关联，事故发生后只能看到多段孤立日志，无法确认是模型误判、工具返回陈旧数据，还是业务 API 已执行但响应丢失。
失败不是同一种失败：三类事故需要三种退路
第一类是推理失败，例如 Agent 反复调用同一工具、忽略足够证据或在两个结论间循环。解决方法不是无限重试，而是触发回合与预算上限，保存当前证据，转交人工或降级到固定 Workflow。继续换模型重试可能只会增加成本和不一致输出。
第二类是工具失败，例如超时、限流、返回格式变化或部分成功。读取工具可以按幂等策略重试；写工具需要幂等键、事务回执和补偿动作。Dify 的失败分支适合把不同 error_type 导向不同路径，但是否已写入仍必须向目标系统查询，不能用 HTTP 超时直接推断未执行。
第三类是治理失败，例如工具权限过宽、敏感数据进入模型上下文、日志保留了密钥，或新版本改变了批准条件。此类问题不能靠 prompt 修复，应立即撤销工具权限、切回已批准版本并审计受影响运行。把权限限制放在工具实现和网关，而不是仅放在 Agent 指令里。
因此，失败设计要在上线前完成：什么错误可以自动重试，什么错误必须停止，什么状态需要补偿，什么条件必须人工接管。没有退路的自主性，不应进入生产写链路。
版本切换：先保存可重放样本，再谈升级与回滚
Agent 与 Workflow 的变化来源不同。Workflow 版本改变节点、变量或分支；Agent 还可能因模型、prompt、工具描述、工具集合和最大回合变化而改变路径。只给应用打一个“v2”标签不足以复现结果，发布清单必须同时固定这些依赖。
升级前应保存一组代表性样本：正常输入、边界输入、工具超时、权限拒绝、部分写入和恶意提示。新版本先在只读或 shadow 模式重放，比较选择的工具、调用次数、最终建议和副作用请求。只有路径差异可解释、资源预算可接受、失败分支仍有效，才逐步放量。
flowchart LR
A("固定 Workflow"):::blue -->|路径未知但仅只读| B("Workflow + Agent 子任务"):::cyan
B -->|样本回放通过| C("受限写工具"):::orange
C -->|幂等与补偿通过| D("扩大自主范围"):::violet
D -->|异常或预算超限| E("回滚到已批准版本"):::slate
C -->|高风险动作| F("人工审批"):::green
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
回滚也要分层。模型或 prompt 退回旧版本，不代表已经撤销工具产生的业务动作；后者需要补偿事务或人工修复。运行账本必须能告诉操作人员哪些请求只生成了建议，哪些请求已得到目标系统确认。
从 Workflow 起步，而不是从纯 Agent 返工
第一阶段先用 Workflow 固定输入验证、数据访问、输出格式和错误分支。此时即使使用 LLM，也让它完成分类、抽取或生成，不给它自由选择写工具。团队可以先获得真实运行样本，知道哪些分支稳定、哪些例外难以枚举。
第二阶段只把一个“分支爆炸”的只读子任务改成 Agent，例如在多个知识源中决定下一步检索。给它最小工具集、最大回合、预算和结构化输出，外层 Workflow 继续验证结果。若没有证据表明固定流程已成为瓶颈，就不需要升级自主性。
第三阶段才考虑受限写工具。写入前必须有权限检查、审批或策略判断，调用必须带幂等键，调用后必须读取目标状态确认。任何无法补偿的动作继续保留人工批准。这样系统即使误判，也会在副作用边界前停止。
如果你的团队正在搭建 Dify 流程，可以先参考智能家居与 IoT 的 Workflow 模板模式；如果问题已经超出编排层，还应重新判断Dify 与自研 AI 应用的系统边界。
哪些项目不该使用 Agent
规则已经稳定、分支数量有限的任务，不该为了“Agentic”改造成 Agent。它会把可测试的确定性逻辑变成概率路径，增加 token、日志和回归成本。对账、授权、设备安全联锁和法规判断也不应由 Agent 单独作最终决定。
数据和工具边界尚未治理的项目同样不适合。若团队不知道哪些数据能进模型、工具是否幂等、失败后由谁接管，先补基础工程，再谈自主性。Agent 不会自动修复模糊的系统所有权，反而会把模糊放大到运行时。
最终选择可以压缩成一句话：能在设计时决定的控制权留给 Workflow，只有必须在运行时根据新证据选择的步骤才交给 Agent；任何高风险副作用都由确定性边界再次确认。
