智能体编排平台中，工作流与 Agent 如何分工？

智能体编排平台中，工作流与 Agent 如何分工？

在智能体编排平台上搭建应用时，经常会遇到一个问题：某个任务应该交给工作流，还是交给 Agent？

比如处理一张订单，既需要查询数据、检查状态、执行操作，也可能需要理解用户描述、分析异常原因。如果把所有步骤都交给 Agent，执行过程容易变得难以预测；如果全部写成固定流程，又可能无法应对开放式问题。

一个实用的设计原则是：

工作流负责明确的执行规则，Agent 负责需要理解、判断和探索的任务。

两者配合的关键，是把自主决策放在合适的位置，并为它设置清晰的输入、输出和权限边界。

一、先理解两者的区别

本文中的"工作流"，指由开发者预先定义主要执行路径的流程；"Agent"，指能够根据目标和执行反馈，动态选择下一步动作的智能体。不同平台的名称可能不同，但可以用这个标准判断。

例如，一条固定流程：

接收工单 → 校验字段 → 查询订单 → 根据订单状态分支 → 返回结果。

它的执行顺序和分支条件由开发者设计，属于工作流。即使某个节点调用大模型，也不意味着整条流程已经变成 Agent。

而下面的任务具有更强的自主性：

分析订单失败原因，自行决定先查日志、核对支付状态，还是检查库存记录；根据结果继续调查。

这里，下一步并没有完全预先写死，更适合由 Agent 执行。

对比维度	工作流	Agent
主要控制方式	预定义节点、条件与状态迁移	根据目标和反馈动态决策
执行路径	相对明确	可能因问题不同而变化
适合的问题	规则清楚、重复性高	信息不完整、需要探索
可预测性	通常更容易控制	需要额外约束与验证
主要风险	分支遗漏、流程僵化	判断错误、无效循环、错误调用工具
验证重点	分支与状态是否正确	结论是否有依据、行动是否合理

需要注意：工作流的路径明确，并不代表输出一定确定。外部接口、大模型节点和并发执行，仍然可能产生不同结果。

二、工作流负责把业务规则落实为执行约束

工作流最适合承接那些"已经知道应该怎么做"的部分。

1. 参数校验与条件分支

必填字段是否存在、订单是否处于可操作状态、金额是否超过审批阈值，这些规则应该尽量通过明确逻辑判断。

例如：

订单不存在 → 返回业务错误
订单已退款 → 返回已有退款结果
退款金额超过可退金额 → 拒绝执行
需要审批 → 进入审批节点

这些规则不需要 Agent 每次重新理解和决定。

2. 权限检查与审批

Agent 可以提出建议，但操作权限应由执行系统检查。

例如，Agent 判断"这笔订单可以退款"，并不代表它获得了退款权限。执行前仍然需要验证申请人身份、订单归属、可退金额和审批状态。

提示词中的"不要越权"，不能代替真实的权限控制。

3. 状态管理与故障恢复

流程进行到哪一步、哪些操作已经完成、失败后从哪里恢复，都适合由工作流或配套执行系统记录。

特别是写入操作，不能简单地"失败就从头再来"。接口超时可能发生在服务端已经成功处理之后，重复执行可能造成重复提交。

因此，重试、幂等和状态确认应在执行层设计，而不是临时交给 Agent 猜测。

三、Agent 负责处理不确定的信息

Agent 的价值，主要体现在无法提前列出全部步骤的任务中。

1. 理解自然语言诉求

用户可能说：

钱扣了，订单却一直没成功，帮我看看。

Agent 可以把这段描述整理成结构化信息：

{
  "intent": "payment_order_inconsistency",
  "reported_payment_status": "charged",
  "reported_order_status": "not_successful",
  "missing_information": ["order_id"]
}

这里应当区分"用户报告的状态"和"系统确认的状态"，避免把描述直接当成事实。

工作流随后可以根据缺失字段，进入补充信息或查询步骤。

2. 动态选择调查步骤

同样是订单失败，原因可能来自支付回调、库存、超时关闭或数据同步。

Agent 可以根据已有证据，选择下一项相关查询，而不必每次执行所有查询。

但工具范围应当受控。例如，诊断 Agent 可以读取脱敏日志和订单状态，不必同时拥有修改数据库、退款和部署服务的能力。

3. 汇总证据与生成解释

多个系统返回的结果往往不适合直接展示给用户。Agent 可以整理时间线、解释冲突，并提出下一步建议。

输出最好区分：

• 已确认的事实。
• 基于证据的推断。
• 尚未解决的问题。
• 建议采取的行动。

这样，后续流程能够根据证据处理结果，而不是依赖一段语气笃定的说明。

四、用一个订单异常场景说明分工

假设平台需要处理"支付成功，但订单未完成"的工单。

可以这样设计：

阶段	负责方	主要职责
接收工单	工作流	保存请求、生成任务标识
理解诉求	Agent 或固定模型节点	提取问题类型与必要信息
校验身份	工作流与业务服务	验证用户与订单归属
查询基础状态	工作流	获取订单、支付等必要数据
分析异常	Agent	按需使用只读工具，形成有依据的结论
检查建议	工作流与业务规则服务	验证建议是否满足执行条件
执行业务操作	受控业务工具	按授权、审批和幂等要求执行
返回处理结果	工作流，可结合模型生成文案	以真实执行结果为依据反馈用户

这里最重要的边界是：Agent 的建议不是执行凭证。

即使 Agent 输出"建议退款"，也必须通过独立的规则与权限检查。不能因为输出格式正确，就认为业务判断正确。

五、为 Agent 定义明确的输入输出契约

如果 Agent 节点只返回一段自由文本，后续流程很难稳定判断下一步。

例如：

看起来可能是支付回调的问题，建议稍后再试，必要时人工处理。

这段话缺少明确状态，也没有可追踪的依据。

可以约定如下输出结构：

{
  "status": "needs_manual_review",
  "confirmed_facts": [
    {
      "description": "支付服务返回交易成功",
      "evidence_ref": "payment_query_01"
    }
  ],
  "hypotheses": [
    "订单状态更新可能未完成"
  ],
  "recommended_action": "check_callback_processing",
  "unresolved_questions": [
    "支付回调是否已被订单服务成功消费"
  ]
}

工作流随后验证：

• 必填字段是否齐全。
• 状态和动作是否属于允许值。
• 证据引用是否对应真实工具结果。
• 建议是否在当前任务的权限范围内。

结构化输出让结果更容易处理，但不保证内容真实。字段校验之后，仍然需要事实和业务规则校验。

六、限制 Agent 的探索范围，设置退出条件

开放式调查容易出现循环：反复查询相同数据、不断尝试相似工具，或者持续分析却没有新增证据。

因此，在编排时应明确：

目标：
定位订单与支付状态不一致的可能原因。

允许工具：
订单查询、支付查询、脱敏日志检索。

结束条件：
- 已获得足够证据；
- 需要当前工具无法取得的信息；
- 达到时间或工具调用预算；
- 连续查询未获得新信息。

退出要求：
返回已确认事实、未解决问题和建议下一步。

达到预算上限不应被当成"任务成功"。系统需要保留明确的结束原因，例如完成、受阻、超时或需要人工处理。

只有区分这些状态，后续工作流才能正确接续。

七、什么时候只用工作流就够了？

并不是调用了 AI，就需要搭建一个完整 Agent。

例如，从工单中提取订单号和问题类别，如果处理步骤固定，可以使用：

输入文本 → 模型提取 → 格式校验 → 规则分支。

这已经能够完成任务，没有必要额外引入自主规划和多轮工具选择。

可以用下面的方式判断：

任务	优先考虑
固定字段提取、分类、摘要	工作流中的模型节点
明确规则下的审批与状态流转	工作流
根据证据动态选择查询步骤	Agent
开放式调查后执行受控操作	工作流与 Agent 组合
单次明确的业务写入	经过校验的业务工具或服务

是否使用 Agent，取决于任务是否需要动态决策，而不是任务看起来是否复杂。

八、两类常见的设计误区

把所有事情交给一个"全能 Agent"

理解需求、查询数据、判断权限、审批和执行全部集中在一个 Agent 中，会让职责和故障原因难以区分。

更合理的做法是让系统约束高风险动作，把自主性用于信息分析和方案选择。

把每个步骤都拆成一个 Agent

分类 Agent、校验 Agent、格式化 Agent、路由 Agent，不一定比几个普通节点更有效。

过度拆分会增加调用成本、交接信息和排查难度。能用明确代码或单次模型调用完成的步骤，就不必引入自主执行循环。

拆分的依据应当是职责、权限和独立验收需求，而不是节点越多越先进。

九、如何验证这套分工是否有效？

工作流和 Agent 应分别测试，再做端到端验证。

工作流重点检查条件分支、审批阻断、重复请求、失败恢复和执行状态。

Agent 重点检查事实准确性、证据质量、工具选择，以及信息不足时能否明确停止。

最后还要覆盖几种组合场景：

• Agent 给出了格式正确但业务错误的建议。
• 外部查询超时，暂时无法判断操作是否成功。
• 调查预算耗尽，仍然缺少关键证据。
• 用户中途修改目标或撤销操作。
• 任务重启后，已有步骤不应被重复执行。

这些场景能够检验平台是否真正把"分析建议"和"业务执行"分开。

结语

智能体编排平台中，工作流提供稳定的执行顺序、状态管理和权限边界；Agent 在这些边界内理解信息、探索问题并提出有依据的建议。

设计时，可以先用明确流程搭出骨架，再把确实需要动态判断的部分交给 Agent。

让规则明确的步骤可预测，让需要探索的步骤有空间，让最终行动始终可验证。