单 Work Agent 与多智能体应用的工作流跳转和全局意图有何差异？

单 Work Agent 与多智能体应用的真正差异，不在于是否都能调用工具，也不在于是否都使用 ReAct 循环，而在于“谁拥有跨任务的控制权”。单 Work Agent 通常由一个模型围绕同一份上下文持续规划，在当前任务内部选择工具或调用一个工作流；多智能体应用则在上层增加控制器，把多个边界相对独立的工作流或智能体当作可路由单元，并能依据用户意图切换执行单元。工作流跳转因此是执行范围的变化，全局意图则是能够越过当前局部流程、在多个流程中统一生效的高优先级控制信号。

先分清模型循环、工作流和多智能体控制器

这三个概念经常被放在一起讨论，但它们解决的问题处于不同层级。模型循环负责“下一步做什么”：读取当前观察，决定调用工具、继续推理还是结束。工作流负责“业务步骤怎样稳定执行”：它用节点、条件、参数和异常分支表达一个相对明确的处理过程。多智能体控制器负责“当前应该由哪个业务单元处理，以及何时换到另一个单元”。

例如，一个办公助手要处理报销、会议室预订和 IT 故障。单 Work Agent 可以把三类工具全部交给一个模型，由模型每轮判断调用哪个工具；也可以为模型提供三个工作流，让它在任务开始时选择一个。只要执行期间始终由同一个模型、同一套上下文和同一个任务状态主导，它仍然属于单智能体范畴。

多智能体应用会把报销、会议室和 IT 支持封装为不同子工作流或子智能体，再由控制器识别用户意图、选择入口，并在必要时进行跨工作流跳转。各单元可以拥有不同的提示词、知识库、工具权限、输入输出契约和终止条件。这里的“多”不是简单地多调用几次模型，而是存在多个受控执行边界，并有一个上层机制管理这些边界。

工作流跳转的差异在于作用域

单 Work Agent 也能在一个工作流中设置条件分支。比如报销金额超过阈值就进入审批节点，否则直接进入记账节点。这种跳转发生在同一工作流内部，变量定义、权限和生命周期通常没有改变。即便模型临时改用另一个工具，本质上也只是当前 Agent 在自己的动作空间中做出选择。

多智能体的工作流跳转则是从一个执行单元转交到另一个执行单元。控制器需要回答四个额外问题：什么信号触发转交，哪些状态需要传递，接收方从哪个入口继续，以及原工作流是暂停、终止还是等待后续恢复。因而它更接近带语义路由的状态机，而不是普通的条件分支。

华为云相关产品文档给出了两种典型控制方式。模型自动控制模式由模型依据用户输入判断调用哪个工作流；指定顺序模式则按预先给定的顺序依次执行工作流。前者适合用户意图变化较多、路由规则难以完全枚举的场景，后者适合步骤固定、审计要求较高的业务。无论哪种模式，工作流本身仍负责局部业务逻辑，控制器负责跨工作流的选择和衔接。

跳转不是重新从零对话

可靠的跨工作流跳转必须定义状态契约。至少要区分用户原始输入、经过确认的业务实体、只在当前工作流内有效的临时变量，以及允许全局共享的状态。比如用户先在“产品咨询”流程选定产品，再说“帮我申请试用”，跳转到“试用申请”流程时应传递产品标识和用户身份，但不应把前一个流程的全部推理记录无差别注入新流程。

如果没有明确契约，多智能体只是把一个难调试的大提示词拆成若干个相互污染的小提示词。常见后果包括字段同名但含义不同、旧流程的约束覆盖新流程、重复询问用户已经提供的信息，以及两个工作流相互跳转形成循环。因此，工程上还需要设置最大跳转次数、幂等标识和明确的终态。

全局意图为什么不是普通意图

普通意图通常只在当前工作流的局部语境中有效。例如“修改日期”在差旅流程中表示修改出发日期，在会议流程中可能表示修改会议日期。它由当前流程解释，并跳到当前流程内的对应节点。

全局意图是跨工作流共享、优先级更高的公共控制意图。典型例子包括“转人工”“取消办理”“重新开始”“不是本人”“停止联系”和“退出”。用户无论正处于哪个业务流程，只要触发这些意图，系统都应以一致方式响应。它可能直接返回固定答复，也可能中断当前流程并跳转到专门的处理工作流。

这意味着全局意图要在局部意图之前或以可覆盖方式参与识别。若用户在填写报销信息时说“算了，帮我转人工”，局部流程不应把这句话误判成报销备注，而应让“转人工”获得控制权。官方文档所说的“其他意图可覆盖”，正是让当前工作流的意图识别节点能够接受全局意图接管，并跳转到全局意图对应动作。

全局意图也是一种中断机制

可以把普通流程理解为主程序，把全局意图理解为受控中断。中断发生时，系统不仅要识别名称，还要规定中断后的执行动作：继续当前业务、终止整个任务，还是处理后等待用户输入。以“隐私撤回”为例，系统可能需要立即停止当前收集流程、清除尚未提交的临时字段并进入合规处理流程；以“帮助”为例，则可以解释规则后恢复原来的节点。

因此，全局意图不能只写成一句宽泛描述。每个全局意图都应有清晰的触发样例、反例、优先级、可触发范围、状态保存策略和恢复策略。否则一个过宽的“取消”意图可能误伤“取消某一行商品”，把用户从整个订单流程中退出。

两种架构的状态和责任边界

单 Work Agent 的核心状态往往是一条连续会话加一组工具结果。模型既做规划者，也做局部路由器，所有工具共享相近的上下文。它的优势是实现简单、延迟较低，调试时可以沿着一条决策链追踪。任务种类有限、权限相近、上下文规模可控时，这种结构通常已经足够。

多智能体应用至少包含控制器状态、全局状态和子工作流状态。控制器保存当前活动单元、候选路由、跳转计数和生命周期阶段；全局状态保存经过约束、允许跨单元传递的数据；子工作流只管理自己的局部变量。三个层次应通过明确接换数据，不能默认所有上下文对所有子智能体可见。

责任边界也随之变化。控制器负责意图识别、路由、超时、跳转上限和统一终止；子工作流负责在本领域内完成任务，并返回结构化结果与下一步建议；全局意图处理器负责跨流程的一致行为。模型可以参与这些决策，但系统仍应使用规则、类型校验和状态机约束关键路径。

用一个执行过程观察两者差别

假设用户输入：“我想了解云主机，另外不要再给我打营销电话。”单 Work Agent 可能在同一次模型规划中识别两个需求，先调用产品知识库，再调用偏好记录工具。是否先处理退订、失败后是否继续介绍产品，都依赖该 Agent 的提示词和当轮规划。

多智能体应用可以先由控制器将“云主机咨询”路由到产品咨询工作流。执行中识别到“不再营销”这一全局意图后，控制器立即中断局部流程，跳到联系偏好工作流并写入禁止营销状态。若该动作定义为终止，则不再返回产品推销内容；若定义为处理后继续，则在确认用户偏好后恢复产品咨询。优先级、状态转移和恢复方式都成为显式配置，而非藏在一个模型的临时推理中。

当前状态：产品咨询.收集需求
用户输入：不要再给我打营销电话
识别结果：全局意图.停止营销
控制动作：中断当前工作流
目标工作流：联系偏好管理
传递状态：用户标识、渠道、会话标识
完成动作：终止会话

这段结构化记录体现了多智能体系统的价值：路由决策可以被审计，跨流程数据可以被限制，终止语义可以被测试。它也揭示了额外成本，因为系统必须维护更多状态、契约和观测指标。

什么时候单 Work Agent 更合适

如果任务共享同一组工具和权限，步骤虽然动态但目标一致，且不同任务之间没有强隔离要求，应优先选择单 Work Agent。典型场景是代码仓库内的分析、修改和测试：模型可以根据观察反复选择搜索、编辑和执行命令，不必为了每一种工具建立独立智能体。

判断依据不应是工具数量，而应是边界数量。十个工具若都服务于同一目标、共享上下文，仍可以属于一个 Agent；两个流程若面向不同责任人、使用不同敏感数据并有独立服务等级，就可能值得拆成两个子智能体。过早拆分会增加路由误判、上下文转换、端到端延迟和测试组合数。

什么时候需要多智能体

当应用存在多个稳定业务域，而且需要在对话过程中根据意图切换；当不同业务域需要不同权限、知识或合规策略；当“转人工”“终止”“身份异常”等公共意图必须随时接管；或者当各流程由不同团队独立发布和维护时，多智能体控制器才产生明确收益。

多智能体的优势不是让模型凭空更聪明，而是提升模块隔离、治理能力和演进独立性。它允许报销流程升级而不改动 IT 支持提示词，也允许安全团队统一维护全局的身份异常处理。但这些收益只有在接口和状态治理到位时才成立。

验证设计是否真的需要跳转和全局意图

可以先列出所有用户意图，并标记其作用域。只影响某个流程内部步骤的意图留在局部；要求在多个流程中保持相同行为的意图才提升为全局意图。随后为每次跨工作流转移写出来源状态、触发条件、目标入口、传递字段、失败处理和最终动作。如果这些信息写不清楚，说明流程边界还不稳定。

测试时至少覆盖四组情况：局部意图不会被全局意图误抢占；全局意图能在每个允许的节点接管；跳转后只携带白名单状态；连续跳转不会超过限制或形成循环。还要记录意图置信度、路由结果、跳转原因、每个工作流耗时和最终终态，以便定位问题究竟来自识别、状态映射还是子流程本身。

最终可以用一句话概括：单 Work Agent 优化的是一个执行主体如何完成任务，多智能体应用治理的是多个执行主体如何分工、切换和接受公共控制。工作流跳转是跨执行边界的路由，全局意图是能够在这些边界之上接管流程的公共意图。只有业务确实存在这些边界时，多智能体才不是形式上的复杂化。