SDOF：以状态约束调度驯服多智能体编排中的对齐代价

# 在多智能体编排中通过状态约束调度缓解对齐代价 来源：https://arxiv.org/html/2605.15204 ###### 摘要 多智能体编排框架（如 LangChain、LangGraph 和 CrewAI）通过基于图结构的管道路由任务，但并未强制执行真实业务流程中的阶段约束。我们提出 SDOF，一个将多智能体执行视为受约束状态机的框架。SDOF 通过两个主要防御层运作，由三个组件实现：(1) 基于在线 RLHF 的专用意图路由器，通过生成奖励建模（GRPO）训练；(2) 状态感知调度器，带有 GoalStage 有限状态自动机检查和前置条件/后置条件技能注册表验证，实现可审计的执行控制。在一个由北森 iTalent 平台（服务 6000+ 家企业）支持的招聘系统中，185 个专家策划的场景触发了 1671 次真实 API 调用。我们采用 GSPO 对齐的 7B 意图路由器，在此 FSM 约束的对抗性路由基准上实现了高于零样本 GPT-4o 的联合准确率（80.9% 对比 48.9%）。在端到端执行中，SDOF 达到 86.5% 的任务完成率（95% CI 80.8–90.7），并阻止了注入的非法 HR 子集中的全部 22 项操作。在更广泛的消息级拦截审计中，SDOF 的精准率为 100%，召回率为 88%（专家一致率 κ=0.94）。另外，在跨越 8 个服务领域的 960 个 SGD 衍生对话上的评估，根据我们的 FSM 映射发现了 201 个阶段顺序冲突，其中 41 个出现在正常划分中。本 arXiv 版本报告当前验证的范围；后续更新将发布扩展的多种子训练比较和更深层次的工作流评估。 ## 1 引言 当基于 LLM 的智能体自动化企业工作流时，它们必须遵守每个流程所要求的顺序阶段约束。以招聘为例：候选人不能在简历筛选前被评估，面试轮次未结束前不能发出录用通知。违反这些约束会导致合规失败、数据损坏和法律风险。这些约束不同于一般的任务依赖关系：它们是领域特定的、按阶段排序的，并且必须在编排层而非单个智能体内部强制执行[19 (https://arxiv.org/html/2605.15204#bib.bib25)]。 当前的编排栈——LangChain[2 (https://arxiv.org/html/2605.15204#bib.bib3)]、LangGraph[9 (https://arxiv.org/html/2605.15204#bib.bib11)]、CrewAI[11 (https://arxiv.org/html/2605.15204#bib.bib4)]、AutoGen[21 (https://arxiv.org/html/2605.15204#bib.bib2)]——擅长在智能体和工具之间路由消息，但没有任何一个原生检查当前工作流阶段是否允许请求的操作。因此，如果存在图边，处于 SOURCING 阶段的智能体可以调用面试安排 API，即使业务流程禁止这样做。在受监管的行业中，这个差距是不可接受的。 我们提出 SDOF（状态驱动编排框架），它将多智能体任务执行建模为受约束的状态机，通过三个主要结构新增实现两个防御层： 1. 在线 RLHF 专用意图路由器：一个 7B 模型，使用 veRL (GRPO) 中的在线程序化奖励进行专门化，在我们的 FSM 约束基准上实现了高于 GPT-4o 零样本的联合准确率。 2. GoalStage FSM 和技能注册表：意图-阶段约束（Λ）和前置条件验证（Π_pre）用于降低乱序风险。 3. 状态感知调度器：通过阶段过滤的技能选择协调执行（算法 1 (https://arxiv.org/html/2605.15204#alg1)），在技能绑定前强制执行约束，并生成可重放的审计跟踪。 我们将 SDOF 部署在集成于北森 iTalent（服务 6000+ 家企业，48 个真实职位）的生产级智能招聘系统中进行评估，使用了 185 个专家策划的场景，包含 882 条消息和 1671 个真实 API 调用。我们还在来自 8 个领域的 960 个 SGD 衍生对话（800 个正常划分 + 160 个对抗性）上验证了跨领域泛化能力[15 (https://arxiv.org/html/2605.15204#bib.bib6)]。 我们的主要贡献是： - • 设计贡献：一种意图-阶段绑定公式（Λ），在状态转换验证之上增加了一个正交约束层。 - • SDOF 框架本身，将 GoalStage FSM、技能注册表和状态感知调度器打包成一个可重用的编排层。 - • 跨越两个数据源的评估——185 个 HR 场景（含真实北森 API 调用）和 960 个跨 8 个服务领域的 SGD 衍生对话——加上专家验证（κ=0.94）。 ## 2 相关工作 **LLM 智能体编排。** LangChain[2 (https://arxiv.org/html/2605.15204#bib.bib3)] 普及了将 LLM 调用与工具调用链接起来的方法。LangGraph[9 (https://arxiv.org/html/2605.15204#bib.bib11)] 在其上增加了一层有向图，允许循环的智能体交互和持久状态。CrewAI[11 (https://arxiv.org/html/2605.15204#bib.bib4)] 将智能体组织成基于角色的团队，进行层次化委派。AutoGen[21 (https://arxiv.org/html/2605.15204#bib.bib2)] 采取不同角度，允许多个智能体在群聊拓扑中对话。MetaGPT[7 (https://arxiv.org/html/2605.15204#bib.bib12)] 的精神与我们最接近：它围绕标准操作流程（SOP）构建智能体协作，但其 SOP 是刚性序列，而非带前置条件检查的基于约束的状态机。AgentScope[5 (https://arxiv.org/html/2605.15204#bib.bib13)] 针对分布式部署，无阶段级强制；AgentVerse[3 (https://arxiv.org/html/2605.15204#bib.bib27)] 关注涌现行为而非形式化工作流保证。更广的背景下，Wang 等人[20 (https://arxiv.org/html/2605.15204#bib.bib10)] 和 Xi 等人[23 (https://arxiv.org/html/2605.15204#bib.bib14)] 对该领域进行了综述。 这些框架暴露了不同的编排原语：LangGraph 侧重于转移图，AutoGen 侧重于群聊/选择器/群体团队，MetaGPT 侧重于 SOP 驱动的角色团队。然而，在原生形式下，它们并未将业务阶段合法性作为显式运行时契约暴露出来——而这正是本文评估的核心。表 1 (https://arxiv.org/html/2605.15204#S2.T1) 总结了实际差异。 近期的鞍架式运行时进一步以不同方向扩展了设计空间：它们将长期运行执行功能（如中间件管理的委派、沙箱、内存注入、摘要、调度和操作员干预）打包到通用智能体运行时中。这些系统是有益的证据，表明智能体质量越来越依赖于基础模型之外的运行时组织。然而，它们的设计重点通常是任务连续性和操作广度，而非在明确业务 FSM 下的工作流合法性。因此，SDOF 占据了一个更窄但实际独特的生态位。 **表 1：代表性编排框架的能力级比较。** **工具使用和 API 集成。** 另一条工作线集中于 LLM 如何调用外部工具。Toolformer[16 (https://arxiv.org/html/2605.15204#bib.bib8)] 让模型从自监督中学习工具调用；ReAct[24 (https://arxiv.org/html/2605.15204#bib.bib7)] 在思维链推理与动作执行之间交替；Reflexion[17 (https://arxiv.org/html/2605.15204#bib.bib9)] 在失败后引入口头自我批评。在 API 层面，ToolLLM[14 (https://arxiv.org/html/2605.15204#bib.bib19)] 对超过 16000 个真实端点进行基准测试，RestGPT[18 (https://arxiv.org/html/2605.15204#bib.bib20)] 针对 RESTful 服务，Gorilla[12 (https://arxiv.org/html/2605.15204#bib.bib21)] 通过检索改进 API 调用准确性。所有这些都解决了调用工具的能力——但都没有解决在给定工作流当前阶段下，何时允许调用的问题。 **面向 LLM 智能体的状态机。** StateFlow[22 (https://arxiv.org/html/2605.15204#bib.bib5)] 将 LLM 任务求解映射到有限状态机上，以结构化中间步骤。TaskWeaver[13 (https://arxiv.org/html/2605.15204#bib.bib26)] 采用代码优先的规划风格；DSPy[8 (https://arxiv.org/html/2605.15204#bib.bib16)] 将声明式 LLM 程序编译成优化过的管道。这些系统对计算施加了结构，但未对业务级阶段合法性施加结构。 **作为外化系统能力的规划。** 新兴的智能体工程路线将规划从潜在的思维链中外化为显式系统结构：计划制品、运行时待办状态、委派的规划器/执行器角色、中间件强制的检查点和评估框架。这个视角有助于定位 SDOF。我们并未声称拥有通用规划器；相反，SDOF 将企业相关的一个规划切片——某个操作在当前工作流阶段是否合法可执行——外化为一个可审计的编排契约。 **安全与受约束的 LLM 系统。** 护栏方法过滤模型输出——有害标记、幻觉事实、策略违规[4 (https://arxiv.org/html/2605.15204#bib.bib24)]。SDOF 工作在更早的一层：它在任何智能体执行之前阻止违反过程模型的动作，类似于编译时类型检查与运行时断言的对比。近期的安全基准 ASSEBench[1 (https://arxiv.org/html/2605.15204#bib.bib31)] 和 AMA-Bench[25 (https://arxiv.org/html/2605.15204#bib.bib30)] 报告了在上下文相关的权限提升中的严重失败——SDOF 的双层 FSM+前置条件架构旨在缓解这种失败模式。过程挖掘文献[19 (https://arxiv.org/html/2605.15204#bib.bib25)] 提供了从日志中发现类似 FSM 的工作流模型的技术，这一方向可能自动生成 SDOF 当前手动定义的阶段定义。 **智能体记忆机制。** 近期的基准测试揭示了智能体记忆能力与现实需求之间日益扩大的差距。LoCoMo[10 (https://arxiv.org/html/2605.15204#bib.bib32)] 显示 LLM 智能体在跨会话的长时域因果推理上失败——这正是 SDOF 的 GoalStage FSM 通过使会话状态显式化和持久化来应对的同类失败模式。MemoryArena[6 (https://arxiv.org/html/2605.15204#bib.bib29)] 表明，在共享状态一致性至关重要的相互依赖的多智能体任务中，单个智能体的记忆失效。我们的 GoalManager（由 PostgreSQL 支持）代表了这些基准所呼吁的共享过程记忆原语的具体实例化。 更广泛地说，大多数先前的记忆工作将记忆视为检索或连续性机制。SDOF 则相反，将记忆用作主动治理基底：工作流状态由 goal_id 限定，仅通过阶段合法转移进行变异，并由可重放的 ProcessEvent 跟踪镜像。在企业环境中，记住事实是不够的；系统还必须记住哪个工作流拥有状态，谁被允许推进它，以及变更在哪些前置条件下是可审计的。 **关键空白。** 没有任何先前的框架同时提供：(1) 与转移图正交的意图-阶段绑定；(2) 技能级别的前置条件验证；(3) 针对真实生产 API 的评估；(4) 用于多智能体协调的持久共享记忆基底。MetaGPT[7 (https://arxiv.org/html/2605.15204#bib.bib12)] 最为接近，但省略了两层检查（阶段+前置条件）且没有真实 API 验证。我们的重点与通信拓扑优化正交：无论智能体是通过固定图、监督器还是学习到的路由策略连接，SDOF 都在编排层约束哪些动作是合法的。 ## 3 系统架构 ### 3.1 概述：鞍架控制架构 图 1 (https://arxiv.org/html/2605.15204#S3.F1) 从控制视角说明了 SDOF 架构。SDOF 不是将智能体视为无约束的生成模型，而是将 LLM 核心包裹在一个鞍架式架构内。用户消息流经 IntentRouterAgent 进行意图识别。这个上层随后受到两个外部规则治理模块的约束：执行编排层（通过 StateAwareDispatcher 检查阶段和前置条件约束）和企业治理记忆基底。与那些针对广泛开放性活动优化通用任务连续性的通用鞍架运行时不同，SDOF 将运行时专门化围绕企业过程合法性：状态所有权、阶段合法调度、前置条件有界执行和可重放的审计跟踪。设计目标不是最大化通用自主性，而是确保每一步相对于正在自动化的业务流程保持合法。 **图 1：SDOF 作为企业鞍架架构。** 生成式 LLM 核心（上层）受到确定性编排和记忆模块（下层）的约束，以减少不受支持的状态转换和不受控制的工作流漂移。 一个实际的设计选择是，GoalManager 不仅仅是当前阶段的持久化缓存。它充当一个以目标为作用域的治理记忆层，在实现中跨越四个记录类别——目标、职位、候选人、过程事件——使得每个调度步骤都与工作流所有者（goal_id）、当前阶段、可变业务状态和可重放的审计历史绑定。这使记忆从被动的对话存储转变为在调度时被查询的主动控制面。 ### 3.2 GoalStage 有限状态自动机 我们将工作流自动机定义为一个元组 G = (S, s_0, T, δ, I, Λ)，其中： - • S = {init, src, int, off, onb, close}：工作流阶段 - • s_0 = init：初始阶段 - • T ⊆ S × S：合法转移 - • I：意图集合（create_demand, screen_resume 等） - • Λ: I → 2^S：意图-阶段绑定 **阶段语义。** 在本文中，init = 初始化，src = 寻源，int = 面试，off = 录用，onb = 入职，close = 工作流关闭。 **定义 1（意图-阶段绑定）。** 对于每个意图 i ∈ I，Λ(i) ⊆ S 定义了 i 合法可执行的阶段。意图 i 在阶段 s 上是阶段合法的，当且仅当 s ∈ Λ(i)。 **实际区别。** LangGraph 定义了 T（合法转移），但不定义 Λ（意图-阶段绑定）。处于 SOURCING 状态的智能体可以执行 evaluate_candidate，如果存在指向 INTERVIEW 的图边。SDOF 要求 s ∈ Λ(i)，这是一个正交约束。 ### 3.3 形式化问题定义和对齐代价 为了严格定义纯 LLM 对齐在企业工作流中的局限性，我们将智能体执行上下文形式化为一个元组 E = ⟨M, Π, Φ⟩，其中 M 是 GoalStage 自动机，Π 是 LLM 策略，Φ 表示结构化的语法前置条件（例如，JSON 模式遵循和参数约束）。 **定义 2（结构化任务的对齐代价）。** 令 P(Φ | x, Π) 为给定输入 x 时策略 Π 生成结构化有效输出的概率。一个强推理模型 Π_think 在生成最终动作字符串 y 之前引入潜在的思维链标记 z ∼ Π_think(·|x)。对齐代价是由中间推理引起的结构性退化： Δ_tax = P(Φ | x, Π_base) - P(Φ | x, z, Π_think) 经验上，随着轨迹 |z| 的增长，模型过度关注语义推理而牺牲了严格的句法边界，导致 Δ_tax ≫ 0。在本文中，我们通过实验将