Work Agent 与 Workflow 的架构边界和混合落地方式是什么？

Work Agent 与 Workflow 的真正边界，不在于系统是否调用了大模型，也不在于页面上有没有一张流程图，而在于“下一步由谁决定”。如果节点、顺序、分支和退出条件主要由开发者预先定义，系统就是 Workflow；如果系统只接收目标与约束，运行时再由模型根据观察结果选择工具、调整计划并判断何时结束，它更接近 Work Agent。生产系统通常不应在二者之间二选一，而应让 Workflow 掌握确定性的控制面，把无法预先穷举的局部任务交给 Agent。

先用控制权判断架构边界

一个工作流可以包含大模型节点。例如，工单流程依次执行字段校验、意图分类、知识检索、回复生成和人工复核，其中分类与生成由大模型完成，但节点之间的连线、失败分支和完成条件都已写死。这仍然是 Workflow，因为模型只是被调度的能力，并没有决定整个任务如何推进。

反过来，一个 Agent 也可以在内部执行固定步骤。它可能先读取任务，再列计划，然后逐项调用工具。只要计划能够依据新观察动态改变，工具的选择和调用次数无法在运行前完全确定，并且模型拥有有限范围内的推进权，它就具备 Agent 特征。因此，“是否有循环”“是否调用工具”“是否使用 ReAct”都不是充分判据，核心判据是运行时决策权。

还可以从输入契约判断。Workflow 的输入通常是结构化参数，输出和中间状态也有明确模式；Agent 的输入更常是目标、上下文、预算和禁止事项。前者执行一张预先设计的图，后者在约束内寻找一条可行路径。边界并非绝对二元，而是一条自主程度连续谱：固定流水线、带条件分支的流程、由模型路由的流程、受限 Agent，以及高自主 Agent。

Workflow 适合承接确定性控制面

当业务步骤稳定、规则可以枚举、结果必须复现或每一步都需要审计时，应优先使用 Workflow。常见任务包括数据格式转换、审批、账务处理、批量导入、权限检查、发布流水线和合规归档。这些环节的价值来自稳定，而不是临场发挥。

Workflow 的优势是成本和风险容易估算。每个节点可以设置输入模式、超时、重试次数、幂等键和补偿动作；运行记录可以准确回答哪一步失败、使用了什么参数、是否允许重放。即使其中某个节点调用大模型，也能先验证结构化输出，再进入后续步骤。

它的限制也很明确。业务变化会增加分支，例外不断累积后，流程图可能变成难以维护的条件网络。对于开放式调查、跨来源分析或需要根据中间结果反复调整策略的任务，开发者很难提前写出完整路径。此时继续堆叠条件分支，维护成本可能高于引入受限 Agent。

Work Agent 适合处理不可预枚举的决策

Work Agent 面向的是“目标明确，但路径不能完整预设”的工作。它通常包含目标理解、规划、工具调用、环境观察、结果评估和重新规划。ReAct 循环只是其中一种实现：模型生成动作，系统执行动作并返回观察，再由模型决定下一步。Plan-and-Execute、反思式修正和多智能体协作也属于可选模式，不应被当作每个任务都必须使用的功能。

Agent 的差异化也不只在循环本身。成熟系统的竞争力通常来自工具质量、上下文组织、权限模型、长任务状态、失败恢复、结果验证和人机协作。两个产品即使都采用类似的推理与工具调用循环，只要可访问的数据、工具调用成功率、上下文压缩方式和验证机制不同，最终可靠性就会明显不同。

自主性会带来代价。模型可能选择不必要的工具、重复尝试、错误理解观察结果，甚至在没有足够证据时宣布完成。调用次数不固定也会让延迟和成本形成长尾。因此，Agent 不适合直接掌管资金划转、权限授予、生产删除等高风险动作。此类动作应由确定性的策略层复核参数，并在必要时要求人工确认。

用四个问题完成选型

路径能否在开发阶段写清楚

如果百分之八九十的路径都能提前描述，且新增例外并不频繁，Workflow 通常更合适。如果任务要先探索环境，拿到结果后才能决定下一步，Agent 的价值才会显现。不要因为流程包含大模型就自动升级为 Agent。

错误的影响是否可逆

生成一份待审阅草稿出错，通常可以低成本重做；发送通知、修改订单或删除资源则可能造成外部影响。错误越难撤销，越应缩小 Agent 的权限，把最终提交放到工作流或人工审批节点中。

结果能否被机器验证

如果输出有 JSON Schema、单元测试、静态检查、数据库约束或可计算的质量指标，系统可以允许 Agent 多一些自主空间，因为每次产出都能经过客观门禁。若验收标准主要依赖主观判断，就需要更严格的预算限制、抽样复核或人工确认。

异常种类是否持续增长

稳定而有限的异常适合显式分支；来源经常变化、输入高度非结构化且异常无法枚举时，受限 Agent 更有维护优势。判断时应统计真实运行中的异常，而不是仅凭演示案例决定。

混合架构的推荐分层

实用的混合方案可以分为控制层、智能任务层和执行层。控制层由 Workflow 负责，保存任务状态，实施超时、预算、权限、重试与人工审批；智能任务层由 Agent 负责，在限定目标下规划和选择工具；执行层封装数据库、搜索、文件和业务接口，并对每次调用进行参数校验与审计。

典型的数据流是：工作流创建任务并提供目标、可用工具、预算和验收条件；Agent 在沙箱内完成探索，返回结构化候选结果和证据；工作流验证结果，决定重试、转人工或调用有副作用的业务接口；最后由工作流归档产物和运行记录。这样，Agent 负责“不知道具体怎么做”的部分，Workflow 负责“必须按规矩做”的部分。

{
  "goal": "形成供应商风险摘要",
  "allowed_tools": ["search_vendor", "read_record"],
  "limits": {"max_steps": 12, "timeout_seconds": 180},
  "acceptance": {
    "required_fields": ["summary", "evidence", "uncertainties"]
  },
  "forbidden_actions": ["update_vendor", "send_email"]
}

这类任务契约比一句自然语言指令更可靠。它明确了目标、工具白名单、步数和时间预算、输出字段以及禁止动作。Agent 可以自由选择读取顺序和分析路径，却不能越过权限边界。工作流收到结果后还应使用模式校验，并检查证据字段是否为空，而不是仅判断模型是否返回了文本。

三种常见的混合落地方式

把 Agent 作为单个工作流节点

这是风险最低的方式。流程的前后步骤固定，只有某个复杂节点由 Agent 完成，例如在内容审核流水线中让 Agent 汇总问题并提出修改建议。节点必须有明确输入、结构化输出、最大执行步数和失败回退。它适合首次引入 Agent 的团队。

由工作流路由到多个专业 Agent

工作流先依据任务类型、数据等级或风险等级选择专业 Agent。每个 Agent 只拥有完成其职责所需的工具，例如研究 Agent 只能读取资料，运维 Agent 只能查询监控。路由可以使用规则，也可以让模型给出候选分类，但最终权限映射应保持确定性。

Agent 规划，Workflow 执行

对于跨系统任务，可以让 Agent 生成声明式计划，但不直接执行。工作流逐项验证计划中的动作、参数和前置条件，然后调用受控接口。若观察结果与计划假设不符，再把新状态交给 Agent 重规划。这种方式同时保留动态适应能力和执行可控性。

状态、重试和幂等是落地重点

混合系统必须区分业务状态与模型对话。业务状态应保存在工作流数据库中，包括任务编号、当前阶段、已执行动作、外部资源标识和审批记录；对话历史只是 Agent 的推理上下文，不能成为唯一事实来源。上下文被裁剪或模型切换后，系统仍应能从持久化状态恢复。

重试也要分层。网络超时可以由工具适配器做短重试；结构化输出不合法可以要求 Agent 修正一次；业务规则不满足则应回到明确节点或转人工。不要让模型无限反思，也不要对有副作用的接口进行无条件重试。所有写操作都应携带幂等键，执行后保存外部系统返回的资源标识。

终止条件必须可执行。除了“任务完成”，还要设置最大步数、最大模型费用、整体超时、连续失败次数和无进展检测。系统可比较最近几次动作与观察，发现重复调用时中断并返回诊断信息。终止不是 Agent 自己的一句判断，而是控制层共同执行的策略。

验证混合架构是否真的更好

上线前应准备一组来自真实业务的任务集，分别用纯 Workflow、受限 Agent 和混合方案运行。至少记录任务成功率、人工接管率、平均与高分位延迟、模型和工具成本、无效调用次数、不可恢复错误数。只比较演示效果，很容易忽略长尾失败。

还要进行故障注入：让工具超时、返回空数据、返回格式错误或撤销权限，观察系统是否正确重试、降级和停止。对于外部写操作，应验证重复提交不会创建两个资源；对于人工审批，应验证暂停后可以恢复到相同状态。日志中应关联一次任务的模型调用、工具调用和工作流节点，但不得记录密钥和不必要的敏感正文。

避免把伪需求包装成 Agent

如果任务只是固定调用三个接口，再按模板生成结果，使用普通程序或 Workflow 往往更便宜、更可靠。若分类问题能用有限规则稳定解决，也没有必要加入自主循环。Agent 的合理投入点，是规则维护已经无法覆盖变化，并且动态规划带来的成功率提升足以抵消模型成本和治理成本。

最终可以采用一条简单原则：默认使用最小自主性，只有在数据证明固定流程无法经济覆盖时，才逐步开放决策权。先把 Agent 放进一个有清晰输入输出的节点，再依据失败数据扩大它的任务范围；始终把权限、预算、审计和外部副作用留在确定性控制层。这样设计，Workflow 提供可预测的运行骨架，Work Agent 提供局部适应能力，两者的混合才是可维护的工程架构，而不是一张更复杂的流程图。