Work Agent 应如何在结构化工作流与高自主 Agentic 模式之间选择？

Work Agent 不应在“结构化工作流”和“高自主 Agentic 模式”之间做一次性的二选一。更可靠的做法，是先按任务的可预测程度、错误代价、验证能力和环境开放度确定自主权上限，再把一个任务拆成不同控制等级的阶段：稳定、重复、合规要求高的部分交给结构化工作流；目标明确但路径无法预先穷举、又能通过工具反馈及时纠错的部分，才交给 Agentic 循环。多数生产系统最终都会落在混合架构上，而不是完全固定或完全自主的两个极端。

两种模式解决的不是同一个问题

结构化工作流强调的是可预期执行。开发者预先定义步骤、分支、输入输出和失败处理，模型只在有限节点完成分类、抽取、生成或判断。它像一张明确的流程图：下一步由状态和规则决定，而不是由模型临场规划。只要输入分布相对稳定，这种设计就容易测试、审计、计费和回放。

Agentic 模式强调的是在不确定路径中寻找解法。系统给模型一个目标、一组工具和若干边界，模型根据当前观察决定下一步行动，执行后读取结果，再继续规划。常见循环可以概括为“观察、判断、行动、校验”，但真正重要的并不是循环名称，而是模型是否拥有选择工具、调整步骤、回退和终止的权力。

因此，两者的分界不是“有没有调用工具”，也不是“是否使用大模型”。一个包含十次工具调用的固定流水线仍然是工作流；一个只调用两次工具、但会根据结果自行改变计划的系统，也可能具有很强的 Agentic 特征。判断模式时，应看控制权在哪里：控制权主要在代码和流程图里，就是工作流；控制权主要在模型的动态决策里，就是 Agentic。

先用四个维度判断任务

路径是否可以提前描述

如果团队可以在开发阶段列出绝大多数步骤和分支，优先使用工作流。例如工单分类、合同字段抽取、固定模板报告、代码仓库的格式检查，都有清晰的输入输出契约。模型在这些场景中的价值是处理非结构化信息，而不是重新发明执行顺序。

如果目标清楚，但所需步骤取决于中间发现，Agentic 模式更合适。例如定位一次陌生代码库中的跨模块故障：初始症状只能给出若干假设，必须先搜索代码、读取日志、运行测试，再依据结果决定下一处调查位置。把所有调查路线事先写成分支，不仅成本高，也会很快失效。

错误代价是否可承受

自主权越高，可达状态越多，测试空间也越大。涉及付款、删除数据、修改生产配置、发送外部消息或处理敏感信息时，不能只用“模型通常会谨慎”作为保障。此类任务应把不可逆动作放进确定性步骤，并在动作前加入权限校验、参数校验、人工确认或审批策略。Agent 可以准备方案和参数，但不应天然拥有最终执行权。

相反，如果行动可撤销、影响范围小，并且失败只消耗少量时间或算力，就可以提高自主权。例如在隔离分支中修改代码、运行测试、根据失败信息继续修复，只要设有时间、次数和目录权限限制，就适合使用较长的自主循环。

结果能否被可靠验证

可验证性往往比任务难度更能决定 Agentic 模式是否可用。代码生成虽然复杂，但编译器、类型检查、测试和静态分析可以提供高质量反馈，因此适合有限自主。相反，“写得更有感染力”看似简单，却缺少低成本、客观的自动判据，自主迭代容易把模型自己的偏好当成改进。

应尽量把模糊目标转换为可观察条件，例如“服务能够启动”“指定测试通过”“输出符合 JSON Schema”“查询只读且返回列满足约束”。若无法建立可靠验证器，就应缩短自主循环，并增加人工评审，而不是让模型通过重复自评获得虚假的确定性。

环境是否开放且变化频繁

工具数量多、信息来源不断变化、任务入口不统一时，固定流程的维护成本会快速上升。Agentic 调度能够根据工具描述和即时结果选择路线，但开放环境也会带来权限扩散、提示注入、异常输出和成本失控问题。工具越开放，越要缩小单个工具的能力：读取和写入分离，预览和提交分离，搜索和执行分离，并让每个调用都有明确的参数结构。

一个可执行的选择规则

可以先计算一个朴素的“自主适配度”，不必追求精确数学模型，只用于迫使团队明确假设。设路径不确定性、自动验证强度、动作可逆性和环境变化度分别为一到五分，错误影响和合规约束也分别为一到五分。前四项越高越支持自主模式，后两项越高越要求结构化控制。

agentic_score =
    path_uncertainty
  + verifier_strength
  + reversibility
  + environment_volatility
  - error_impact
  - compliance_pressure

分数低时，使用固定步骤和显式分支；分数居中时，使用工作流作为骨架，仅把局部探索交给 Agent；分数高时，可以采用目标驱动的循环，但仍需预算、权限和终止条件。这个公式不是产品指标，真正用途是让产品、工程、安全和业务人员对每一项评分展开讨论，避免仅凭“这个任务看起来很智能”就提升自主权。

推荐的混合架构

生产级 Work Agent 可以划分为入口、规划、执行、验证和提交五层。入口层负责鉴权、解析目标和建立任务记录；规划层允许模型提出步骤；执行层只通过受控工具完成单步操作；验证层使用确定性检查或独立规则评估结果；提交层处理不可逆动作与最终状态。层与层之间传递结构化对象，而不是依靠一段不断增长的自由文本维持状态。

{
  "goal": "修复导致订单查询超时的问题",
  "constraints": ["不得修改数据库结构", "只允许在隔离分支写入"],
  "budget": {"tool_calls": 20, "minutes": 15},
  "current_step": "run_targeted_tests",
  "evidence": ["slow-query.log", "test-order-timeout"],
  "status": "running"
}

这里的结构化状态不是为了限制模型表达，而是为了让系统能够暂停、恢复、审计和重放。规划可以动态变化，但约束、预算和证据不能只藏在对话历史里。每次模型提出动作时，执行器都应重新检查权限和参数，不能因为规划阶段已经通过检查，就默认后续调用全部安全。

混合架构还有一个重要原则：自主权应按阶段变化，而不是按产品统一配置。信息收集阶段通常风险较低，可以允许广泛搜索；方案生成阶段可以允许多条候选路线；写入阶段应收紧目录、资源和参数；最终提交阶段则回到确定性流程或人工确认。这样既保留探索能力，也控制关键动作。

什么时候应该坚持结构化工作流

第一类是高频、稳定、可以标准化的任务。固定流程的延迟和成本更容易预测，也便于缓存中间结果。第二类是有强审计要求的任务，需要清楚说明每个分支为何发生。第三类是错误影响大且难以撤销的任务，尤其是跨系统写入。第四类是缺少有效反馈信号的任务，模型即使反复执行，也无法知道是否真正接近目标。

结构化并不意味着每一步都不用模型。可以让模型负责意图分类、字段映射或内容生成，再用程序决定流转。例如客服退款流程中，模型识别诉求并提取订单号，程序校验订单状态和退款政策，只有满足条件才进入退款节点。模型参与了关键理解，但没有控制资金动作。

什么时候值得提高 Agentic 程度

当任务具有较长尾部、步骤依赖中间结果、工具反馈清晰，并且团队难以维护大量分支时，提高自主权通常能减少流程工程成本。代码调查、资料综合、复杂数据诊断和多工具运维分析都可能属于这一类。但前提是系统能区分“没有找到证据”和“已经证明不存在”，并要求 Agent 保存所用证据，而不是只输出一个听起来合理的结论。

还要关注任务是否能自然分段。适合自主执行的任务通常可以拆成多个短回合，每个回合都有明确观察结果。若一次动作要等待很久、结果不可见，或失败后无法判断原因，Agent 就缺少纠错信号。此时增加思考轮次并不能弥补环境反馈不足，应先改造工具和可观测性。

不要把 ReAct 循环本身当成差异化

工具调用、计划列表和观察循环容易复制，真正影响 Work Agent 质量的是循环周围的工程系统。首先是上下文质量：系统能否只提供当前决策所需的信息，并保留可靠来源。其次是工具设计：工具是否语义清楚、参数受约束、错误可诊断。再次是状态管理：任务能否暂停、恢复、去重并避免重复副作用。最后是评估体系：团队是否知道成功率、人工接管率、平均步骤数、失败类型和单位成功成本。

不同 Code Agent 或 Work Agent 的差异，也常体现在它们如何处理边界情况，而不是正常路径上的演示效果。优秀系统会在证据不足时停下，在工具返回矛盾结果时暴露冲突，在预算耗尽前总结当前进展，并把待确认事项交给人。较弱的系统则容易继续生成步骤，用语言流畅度掩盖执行状态的不确定。

为自主循环设置硬边界

任何 Agentic 循环都应至少具备四类限制。其一是资源限制，包括最大步骤数、运行时间、令牌和费用。其二是权限限制，包括可访问的数据、可调用工具和可写范围。其三是状态限制，明确哪些操作幂等、哪些动作需要唯一请求标识、哪些结果必须落盘。其四是终止规则，区分成功、明确失败、需要人工输入和环境异常。

while task.status == "running":
    if budget.exhausted():
        task.status = "needs_review"
        break
    action = planner.next_action(task.state)
    policy.validate(action)
    result = tools.execute(action)
    task.state = verifier.update(task.state, result)

这段伪代码中，策略校验发生在每次执行之前，验证器负责更新状态，规划器不能自行宣布成功。实际系统还应为外部写入加入幂等键，为超时与未知结果设置单独状态。特别是支付、发布和消息发送场景，超时不等于失败，盲目重试可能产生重复副作用。

用渐进方式上线，而不是一次放开

第一阶段可以让 Agent 只观察和建议，真实动作仍由现有流程执行。通过记录它建议的工具、参数和顺序，团队能发现工具缺口和常见失败。第二阶段开放只读工具与沙箱写入，并建立离线任务集，统计任务完成率、验证通过率、平均调用数以及人工修正量。第三阶段才开放低风险写入，同时使用小流量、明确预算和自动回滚。

评估时不能只看最终回答是否像样。至少要检查目标是否完成、证据是否充分、是否违反约束、工具调用是否必要、成本是否可接受，以及同类输入下表现是否稳定。对自主系统而言，一次成功的精彩演示不如一百次可重复的普通执行有价值。

常见误区与排查方法

Agent 经常绕圈

先检查工具返回是否提供了足够的新信息，再检查状态中是否记录已尝试动作。若每轮都把完整对话交给模型，却没有结构化的尝试历史，模型容易重复搜索。可以为动作生成规范化指纹，阻止无参数变化的重复调用，并要求规划器说明下一步预期获得的新证据。

固定工作流分支越来越多

不要立即把整个系统改成自主 Agent。先找出分支膨胀最严重、同时又可验证和可撤销的局部，把这部分替换成受限规划器。外层入口、权限、提交和异常处理继续保持确定性。这样能用较小范围验证自主决策是否真的降低维护成本。

测试通过但线上仍不稳定

常见原因是测试只覆盖最终文本，没有覆盖工具异常、空结果、权限拒绝、超时和部分成功。应对每个工具建立契约测试，并在任务级回放中注入错误。还要检查线上输入是否比离线任务更长、更模糊或包含冲突约束；这些差异会显著改变规划行为。

成本和延迟不可控

记录每次任务的步骤数、模型调用、工具耗时和上下文大小，找出长尾而非只看平均值。可以将简单请求先交给确定性路由，只有满足复杂度条件才启动规划循环；也可以在每轮压缩已确认事实，仅保留仍影响决策的证据。预算到达阈值时应转人工或输出阶段性结果，而不是静默降低质量。

最终决策清单

如果任务路径稳定、错误昂贵、结果难验证或审计要求高，就选择结构化工作流。如果路径未知、环境变化快、工具反馈清楚、动作可撤销且预算可控，就可以提高 Agentic 程度。介于两者之间时，用结构化流程控制入口和提交，用 Agent 负责局部探索，并让确定性验证器决定是否过关。

选择的核心不是追求更像人的自主行为，而是把每一份自主权交给能从反馈中获益、又能被边界约束的任务阶段。随着工具、验证器和可观测性成熟，同一任务可以逐步提高自主程度；一旦失败代价、合规要求或环境不确定性上升，也应能够随时收回自主权。这种可调节的控制面，才是 Work Agent 从原型走向可靠生产系统的关键。