Work Agent 应选择动态编排器还是可检查的固定工作流？

Work Agent 的默认选择应当是可检查的固定工作流，而不是让动态编排器接管整个执行循环。判断边界并不在于任务听起来是否“智能”，而在于运行前能否列出允许的下一状态：如果步骤、分支和验收条件能够预先描述，就用工作流；如果下一步必须根据执行中发现的证据临时决定，再把那一小段交给动态编排器。多数生产系统最终都会采用混合结构，即代码负责边界、状态和终止，模型只负责真正不确定的决策。

先区分两种架构解决的问题

固定工作流把任务表示为有向步骤、状态机或有向无环图。每个节点有明确输入和输出，路由条件由代码或结构化规则决定。例如“读取工单、分类、查询订单、生成回复、人工复核”可以在运行前完整画出。节点内部仍然可以调用大语言模型，但模型负责的是分类或内容生成，不负责随意改变流程。

动态编排器则让模型根据当前目标、上下文和工具结果决定下一步。它可能拆分子任务、选择工具、调用专业 Agent、补充搜索，再汇总结果。动态性的价值不是多调用几个模型，而是执行图在收到具体输入之前无法完整确定。例如处理陌生代码库中的跨文件故障时，必须先搜索符号，才能知道要检查哪些文件；调查结果又可能改变后续路径。

因此，“工作流”和“Agent”不是互斥的产品类别。工作流的某个节点可以是 Agent，编排器选出的动作也可以进入一个确定性子流程。真正需要决定的是：哪些控制权交给模型，哪些控制权留在代码中。

最实用的判断题：能否预先枚举下一状态

设计前先问：“在这次运行开始之前，我能否写出当前状态所有合法的下一状态？”如果答案是肯定的，即使有几十个步骤和多个条件分支，仍然适合固定工作流。复杂并不等于不确定；一个节点很多但转移规则清楚的状态机，通常比一个提示词驱动的通用编排器更容易维护。

如果答案是否定的，再确认不确定性究竟在哪里。模型“不知道该说什么”不代表需要动态编排。文案生成、摘要、信息抽取和评分都可以放进固定节点。只有模型“不知道下一步应该做什么”，例如不知道该收集哪类证据、该检查哪个子系统、该调用哪位专家，动态编排才开始产生实际价值。

还要排除一种常见误判：流程尚未梳理清楚，不等于业务本身不可预测。团队若只是没有把规则写出来，直接引入编排器会把缺失的产品规则藏进模型决策，短期看似省事，长期却难以解释和复现。应先用真实样本整理状态和异常路径，确实无法穷举的部分才标为动态区域。

固定工作流为何应成为默认方案

成本和延迟可以计算

固定工作流知道每个节点调用什么模型、最多调用几次，以及哪些步骤可以并行。团队能够给单次运行建立稳定预算，并针对高频节点使用更小的模型或缓存。动态编排器会引入额外的规划、路由和总结调用，同一输入也可能走不同长度的路径。如果业务对响应时间、调用额度或吞吐量敏感，可预测性本身就是核心能力。

失败可以局部重试

当节点的输入输出被持久化后，第三步失败只需重跑第三步，已经完成的外部操作不必重复。动态循环若没有清晰检查点，重试可能再次发送消息、创建记录或修改文件。对支付、发信、部署、删除等有副作用的动作，固定状态与幂等键尤其重要。

评估和审计更直接

工作流可以逐节点保存输入、输出、耗时、令牌消耗和评分。质量下降时，能够定位是分类错误、检索不足，还是生成结果未通过规则。若一个编排器同时决定分解、路由、重试和停止，最终结果失败后往往很难判断是哪一次决策造成偏离。可检查并非只为调试，也关系到权限审计、事故复盘和合规证明。

变更影响范围更清楚

固定契约让团队能够替换一个模型、调整一个提示词或升级一个工具，而不改变其他节点。测试也可以围绕节点和转移条件编写。动态架构中的提示词变化可能同时影响工具选择、循环次数和最终表达，回归范围更大，需要更多轨迹级评估才能获得同等信心。

动态编排器何时值得使用

第一类场景是开放式调查。用户只给出目标，没有给出完成目标所需的信息，系统必须边搜索边形成假设，并根据证据决定是否继续。例如复杂故障诊断可能从日志开始，随后转向配置、依赖、网络或数据一致性，预先列出每条路径的维护成本过高。

第二类场景是任务分解依赖输入结构。大型代码修改需要触及几个文件、由哪些专业角色处理，只有读取仓库后才能知道。编排器可以先建立任务图，再把边界明确的子任务交给执行者。这里动态产生的是计划，而不是放弃所有约束。

第三类场景是证据数量和来源不固定。研究任务可能在发现冲突资料后追加核验，或者在证据已经充分时提前停止。若用固定数量的搜索步骤，要么浪费调用，要么遗漏重要信息。此时编排器可决定“还缺什么”，但证据格式、来源白名单、预算和停止上限仍应由程序控制。

第四类场景是专业能力的动态路由。输入可能涉及数据库、前端、安全或基础设施，并且一个请求会跨越多个领域。编排器可从一组有描述、有权限边界的专业 Agent 中选择必要成员。若类别稳定且只能选一个专家，普通分类器加条件分支通常已经足够，不需要完整编排器。

推荐的混合架构：外层确定，内层动态

可靠的 Work Agent 通常把整体生命周期做成固定状态机，例如“接收、校验、计划、执行、验证、审批、完成或失败”。其中只有“计划”和某些“调查”节点允许动态编排。外层程序负责加载状态、限制权限、记录轨迹、检查预算，并决定是否可以进入下一阶段。

动态节点不应获得无限工具集，而应接收一组类型明确的动作。每个动作都声明输入结构、输出结构、是否有副作用、是否需要审批。编排器的输出先通过结构校验和策略检查，再由执行层调用工具。这样既保留了模型面对未知任务时的灵活性，也让系统能够拒绝越权参数和不存在的转移。

执行完成后，工具结果应作为环境事实写入状态，而不是只留在模型对话中。下一次决策使用这些事实继续推理。验证阶段则尽量采用独立规则、测试或评估器，不让执行者仅凭自己的文字宣布成功。代码任务可以运行测试和静态检查，数据任务可以检查行数、模式和约束，业务任务可以使用清晰的评分标准。

不要让模型同时掌握动作和终止权

动态循环最危险的设计，是让同一个模型既不断调用工具，又自行判断何时结束，并且没有外部上限。它可能重复搜索、在相似方案之间来回切换，或为了修复次要问题持续消耗预算。即使最终结果正确，运行成本和延迟也难以预测。

终止条件应放在模型之外。至少设置最大步骤数、最大模型调用数、总令牌或费用预算、总运行时间、连续无进展次数，以及副作用动作的次数限制。模型可以提交“已完成”“需要更多证据”或“无法继续”等结构化状态，但程序负责验证该状态是否合法。

还应定义失败出口。工具超时、结构化输出反复无效、权限被拒绝或验证连续失败时，系统应保存检查点并进入明确的失败或人工接管状态，而不是把错误文本再次喂给模型无限重试。可恢复失败与永久失败要分开处理，重试必须带上幂等键。

可检查性应落实为数据结构

“保留日志”还不够。每一次决策至少要记录运行标识、父步骤、当前目标、可选动作、实际选择、结构化参数、工具结果摘要、状态变更、模型与提示词版本、耗时和消耗。对动态生成的任务图，还要记录图的版本以及每次增删节点的原因。

检查点应能回答三个问题：系统现在认为哪些事实成立；哪些动作已经产生外部副作用；恢复后允许执行什么。仅保存自然语言聊天记录无法可靠回答这些问题。关键状态应放进可查询的结构化存储，较大的工具输出可以保存引用和内容摘要，同时保留原始产物供复核。

评估指标也要分层。节点级指标关注路由准确率、工具参数有效率、检索证据覆盖率和验证通过率；运行级指标关注任务完成率、人工接管率、总成本、端到端延迟以及副作用错误率。只比较最终回答的主观质量，会掩盖编排器用五倍调用换取微小提升的问题。

用风险而不是新颖程度决定控制强度

只读搜索、草稿生成和沙箱内分析可以给模型较大的行动空间，因为失败容易回滚。涉及对外发送、生产配置、资金、个人数据和删除操作时，应缩小动作集合，并加入审批、预览、权限最小化和幂等保障。动态编排并不意味着动态授权；工具是否可用应由当前身份、任务阶段和策略代码决定。

共享状态是多 Agent 系统的另一项风险。多个执行者并行修改同一文件或记录，可能产生覆盖和顺序依赖。只有子任务真正独立时才并行；否则使用所有权分区、事务、版本号或合并阶段。编排器可以建议并行，但运行时必须检测冲突，不能假设模型会自行协调。

从固定工作流渐进迁移

落地时可以先把最常见路径做成固定流程，并收集真实的失败样本。不要一开始就构造能够处理所有任务的总控 Agent。运行一段时间后，将无法用合理规则覆盖、且确实造成大量人工处理的单个节点替换为动态节点，同时保持其输入输出契约不变。

替换前建立基线数据，包括完成率、单次成本、延迟、重试次数和人工介入率。新编排方式先以影子模式运行，只生成决策而不执行，对比它与现有流程的选择。确认收益后再逐步放量，并保留回退到固定路径的开关。没有指标的“更灵活”无法证明是一项改进。

动态节点运行稳定后，也要反向固化高频模式。如果编排器在大量请求上反复生成相同的三步计划，就应该把这条路径提升为显式工作流，减少规划成本和随机性。架构不是从工作流单向升级为编排器，而是在发现新模式后不断把确定性收回代码。

一个可直接使用的决策清单

选择固定工作流前，确认下一状态可枚举、输入输出可定义、验收标准明确、外部副作用需要精确控制，并且成本和延迟需要稳定。如果多数条件成立，使用状态机、任务队列或有向图即可，模型只作为其中的受约束节点。

选择动态编排前，确认任务步骤确实取决于中间发现、固定分支的维护成本已经不可接受、系统拥有可用的环境反馈、收益足以覆盖额外调用，并且已经具备预算、追踪、验证、审批和停止机制。缺少后几项时，编排器只会放大不确定性。

两者都符合时，采用混合方案：固定外层管理生命周期与风险，动态内层解决开放式分解和证据收集，完成后回到固定验证与交付阶段。这个边界比争论“Agent 还是工作流”更有意义，因为它把每一份模型自主权都对应到一个可度量的业务需要。

结论

Work Agent 的成熟度不取决于它能自主调用多少工具，而取决于团队能否解释每一次状态变化、限制每一次副作用，并在失败后从明确位置恢复。已知步骤使用可检查的固定工作流，未知步骤使用受约束的动态编排器，是更稳健的默认策略。

实践中可以从一句话开始设计：能预先命名的下一状态写进代码，不能预先命名的选择交给模型；预算、权限、验证和终止始终留在模型之外。这样既不会为了确定性任务支付不必要的编排成本，也不会在真正开放的问题上被僵硬流程限制。