[R] 将代理工作流编译到LLM权重中：以两个数量级的成本降低实现接近前沿质量

# 将智能体工作流编译为 LLM 权重：以两个数量级更低的成本实现接近前沿的质量
来源：https://arxiv.org/html/2605.22502
Simon Dennis <sup>i14</sup>，墨尔本大学 & Rivaan Patil <sup>i14</sup> & Kevin Shabahang <sup>i14</sup> & Hao Guo <sup>i14</sup>

###### 摘要

智能体编排框架层出不穷，在 LangGraph、CrewAI、Google ADK、OpenAI Agents SDK、Semantic Kernel、Strands 和 LlamaIndex 上累计已超过 290,000 个 GitHub Star。所有这些框架都遵循相同的模式：在 LLM 之上放置一个外部编排器，每轮对话都注入指令和路由决策。近期研究 [Dennis et al., 2026a (https://arxiv.org/html/2605.22502#bib.bib4)] 表明，对于程序性任务，这种架构可以被一种更简单的替代方案所超越——只需将整个程序放在前沿模型的系统提示中，并以消耗上下文窗口为代价，但需要在每次对话中都使用前沿模型，且可能将专有程序暴露给第三方提供商。将程序编译到一个小型微调模型的权重中——创建一个**地下智能体**——应该能解决所有这些担忧，并且先前的研究 (SimpleTOD, FireAct, SynTOD, WorkflowLLM, Agent Lumos) 已经证明了该技术的有效性。然而，开发者的采用率却压倒性地倾向于编排。我们识别出三个感知到的障碍，并在三个领域——旅行预订（14 个节点）、Zoom 支持（14 个节点，产品特定知识）和保险索赔（55 个节点，6 个决策枢纽）——通过实证研究逐一解决。

**质量**。在一个旅行预订任务中，一个受控的同模型比较分离了编译的效果：一个 3B 编译模型在五个质量指标中的四个上优于使用显式编排的同一 3B 基础模型 (\(p<0.001\))。该 3B 模型在优雅处理和自然度上仅达到约 82% 的前沿上下文内基线水平；在 Zoom 支持和保险索赔任务上扩展到 8B 缩小了这一差距，达到了上下文内质量的 87-98%，并匹配了一个基于约 70 倍规模更大的前沿模型构建的 LangGraph 编排器。编译模型在旅行任务（5.5% 对比 24%）和保险任务（9% 对比 17%）中的失败率也低于编排器；Zoom 任务的失败率相当。

**成本**。编译模型每次对话的成本比上下文内基线低 128-462 倍，这结合了自托管带来的约 65 倍的每 Token 成本降低，以及约 2-7 倍的 Token 量减少。随着程序复杂性的增加，这种优势会进一步扩大，因为编译模型的提示是固定大小的。本地推理也降低了延迟（保险任务中快 2.8 倍）。

**灵活性**。重新编译周期在生产级硬件上需要 30-50 分钟——这是一个 CI/CD 周期，而不是通常假设的令人望而却步的长时间重新训练。

每个障碍实际上都比通常假设的要小：质量差距很小（前沿质量的 87-98%），成本差距有利于编译两个数量级（并且随着程序复杂性增加而扩大），而灵活性差距只是一个部署周期，而非范式转变。对于需要超越单个对话上下文而持久存在的程序性知识，编译是自然的解决方案：持久的结构属于权重，瞬态的状态属于提示。

## 1 引言

智能体编排框架——LangGraph [LangChain, Inc., 2024 (https://arxiv.org/html/2605.22502#bib.bib12)]、CrewAI [Moura, 2024 (https://arxiv.org/html/2605.22502#bib.bib15)]、Google ADK [Google, 2026 (https://arxiv.org/html/2605.22502#bib.bib7)]、OpenAI 的 Agents SDK [OpenAI, 2026 (https://arxiv.org/html/2605.22502#bib.bib16)]、Semantic Kernel [Microsoft, 2026 (https://arxiv.org/html/2605.22502#bib.bib14)]、Strands [Amazon Web Services, 2026 (https://arxiv.org/html/2605.22502#bib.bib1)]、LlamaIndex [LlamaIndex, 2026 (https://arxiv.org/html/2605.22502#bib.bib13)]——已经大量涌现，累计超过 290,000 个 GitHub Star。所有这些框架都遵循相同的模式：在 LLM 之上放置一个外部编排器，每轮对话都注入指令和路由决策。Dennis 等人 [2026a (https://arxiv.org/html/2605.22502#bib.bib4)] 表明，对于程序性任务，这种架构可以被一种更简单的替代方案所超越——将整个程序放在模型的系统提示中，让它自我编排，从而实现接近完美的质量（5 分量表上达到 4.53-5.00）。然而，上下文内方法要求每次对话都使用前沿模型，这会因为每次 API 调用都嵌入程序而膨胀 Token 消耗，消耗上下文窗口容量，并将专有程序暴露给第三方提供商。

将程序**编译**到一个小型微调模型的权重中——创建我们所谓的**地下智能体**——应该能解决所有这些担忧。这项技术已经成熟：SimpleTOD [Hosseini-Asl 等人，2020 (https://arxiv.org/html/2605.22502#bib.bib9)]、FireAct [Chen 等人，2023 (https://arxiv.org/html/2605.22502#bib.bib3)]、SynTOD [Samarinas 等人，2024 (https://arxiv.org/html/2605.22502#bib.bib19)]、WorkflowLLM [Fan 等人，2024 (https://arxiv.org/html/2605.22502#bib.bib6)] 和 Agent Lumos [Yin 等人，2024 (https://arxiv.org/html/2605.22502#bib.bib21)] 都将智能体能力编译到模型权重中，并且有几项达到了与前沿模型竞争的质量。然而，开发者的采用率却压倒性地倾向于编排；上述关于编译的论文仍然是学术原型，共有约 3,000 个 Star——社区参与度比编排框架大约低 100 倍。为什么人们不把程序编译到权重中呢？

我们识别出三个感知到的障碍，并在三个领域——旅行预订（14 个节点）、Zoom 支持（14 个节点，产品特定知识）和保险索赔处理（55 个节点，6 个决策枢纽）——通过实证研究逐一解决，每个条件每个领域使用 \(n=200\) 个场景，并以 LangGraph 编排器和上下文内基线作为对照：

- • **质量**（§4 (https://arxiv.org/html/2605.22502#S4)）。一个微调过的小模型能否在程序性任务上匹配前沿模型？一个 8B 编译模型达到了上下文内前沿质量的 87-98%，与使用约 70 倍更大前沿模型的 LangGraph 编排器相比具有竞争力。
- • **成本**（§5 (https://arxiv.org/html/2605.22502#S5)）。一旦考虑了自托管，每次对话的推理成本是否真的更低？编译模型每次对话的成本比上下文内基线低 128-462 倍；随着程序复杂性的增加，这种优势进一步扩大，因为编译模型的提示是固定大小的。
- • **灵活性**（§6 (https://arxiv.org/html/2605.22502#S6)）。当程序发生变化时，编译后的模型能否在不进行令人望而却步的长时间重新训练的情况下适应？重新编译周期在生产级硬件上需要 30-50 分钟——这是一个 CI/CD 周期，而不是一个重大的重新训练工作。

## 2 将智能体工作流编译为权重

![图1: 架构对比。左：表层编排在用户和 LLM 之间插入一个编排器，每轮对话注入指令并解析输出。右：地下方法仅在训练数据生成时使用编排器；在运行时，程序被编译到 LLM 的权重中，用户直接与 LLM 对话。](https://arxiv.org/html/2605.22502/figures/architecture.png)

图 1 (https://arxiv.org/html/2605.22502#S2.F1) 对比了两种架构。在表层编排（左）中，一个编排器位于用户和 LLM 之间，每轮对话注入提示并解析输出。在地下方法（右）中，编排器仅在训练数据生成时使用；在运行时，用户直接与 LLM 对话，该 LLM 已将程序编译到其权重中。地下流水线的工作方式如下：

1. 1. 将程序**定义为**一个包含节点（轮次）和边（转换）的流程图
2. 2. 通过遍历流程图中的所有有效路径**生成合成对话**
3. 3. 在这些对话上使用全参数更新**微调 LLM**
4. 4. **无需编排即可部署**——LLM 已学会自我编排

编排器在运行时从不接触 LLM。程序塑造了训练数据，模型通过学习到的统计规律性而非显式指令来隐式地遵循程序。在运行时，编译后的模型直接运行程序——不需要解释器。

我们将程序表示为有向图 \(F = (N, E, n_0, T)\)：

- • \(N\)：具有角色（agent/user）和提示模板的节点
- • \(E \subseteq N \times N \times C\)：具有可选条件的边
- • \(n_0 \in N\)：起始节点
- • \(T \subseteq N\)：终止节点（成功、放弃、升级）

我们在三个领域进行评估（流程图见附录 D (https://arxiv.org/html/2605.22502#A4)）。

**旅行预订**（14 个节点，3 个决策枢纽；图 2 (https://arxiv.org/html/2605.22502#A4.F2)）。客户联系代理预订旅行。代理问候客户，收集旅行偏好（目的地、日期、预算），然后评估是否已收集足够信息。如果没有，对话循环回去获取更多细节。准备就绪后，代理提供选项；客户可以接受、拒绝或要求替代方案——每个选择都通向不同的分支。如果客户接受，代理确认预订；否则对话可能通过新搜索循环或以放弃告终。该程序产生 86 条独特的无环路径，长度在 4-17 轮之间。

**Zoom 支持**（14 个节点，并行结构）。用户报告 Zoom 问题——音频问题、视频冻结、连接断开或屏幕共享故障。代理将问题分流到相应的故障排除轨道，引导用户完成诊断步骤，并检查每个步骤是否解决了问题。如果没有，代理可以重试替代修复方案或升级。这是一个产品特定领域：代理必须了解 Zoom 的 UI、设置菜单和常见错误代码，因此训练数据将这些领域知识直接编码到模型的权重中。该程序产生 60 条独特的无环路径，长度在 4-17 轮之间。

**保险索赔**（55 个节点，6 个决策枢纽）。投保人提出索赔——汽车、财产、健康或责任。代理进行受理，确定索赔类型，收集支持文件（当文件不完整时循环返回），评估承保范围和除外责任，并通过报价/还价交换协商理赔金额。该程序几乎是其他领域的 4 倍大，包含嵌套循环（例如，文件请求→审核→重新请求）和跨阶段依赖关系（承保范围决策约束理赔选项）。该程序产生 2,381 条独特的无环路径，长度在 9-39 轮之间，测试编译是否能扩展到更复杂的工作流。

对于每次对话，我们采样一条通过流程图的路径和一组场景变量（目的地、预算、用户性格、索赔类型等），然后使用 Claude Sonnet 4.5 沿着路径逐轮生成对话。在每个节点，生成器接收该节点的提示模板和完整的对话历史，生成上下文适当的响应。推理时的模型只看到自然的对话，没有任何程序性注释——结构隐含在对话的流动方式中。数据集大小在每个实验中报告。

我们使用**全参数更新**进行微调。程序内化需要修改模型的隐式状态跟踪行为——这是一种比风格对齐更深层次的改变。一项跨秩 16-128 的参数高效 (LoRA) 微调系统研究发现，低秩方法在程序性任务上无法接近全微调的效果 [Dennis 等人，2026b (https://arxiv.org/html/2605.22502#bib.bib5)]。在推理时，地下智能体仅使用一个最小化的系统提示（例如，“你是一个有用的旅行预订助手”）——没有程序性指令、流程图状态或路由逻辑。训练配置在每个实验中报告。

## 3 评估方法论

所有三个实验共享两个基线。**LangGraph 编排器**使用由 LangGraph [LangChain, Inc., 2024 (https://arxiv.org/html/2605.22502#bib.bib12)]（截至 2026 年 3 月约 3 万个 GitHub Star，最广泛采用的智能体框架）编排的 Claude Sonnet 4.5。每个流程图节点映射到一个 LangGraph 图节点；在决策枢纽，一个 LLM 分类器选择下一个边。这与 Dennis 等人 [2026a (https://arxiv.org/html/2605.22502#bib.bib4)] 评估中使用的编排器相同，作为前沿模型基线（参数比 3B 编译模型大约多 70 倍）。**上下文内基线**将**整个序列化的流程图**放在 Claude Sonnet 4.5 的系统提示中，使其能够在每轮使用一次 API 调用进行自我编排。它建立了前沿模型在拥有完整程序上下文时所能达到的上限，代价是消耗上下文窗口容量。这两个基线——编排与上下文内提示——之间的比较在另一篇论文中报告 [Dennis 等人，2026a (https://arxiv.org/html/2605.22502#bib.bib4)]。

我们使用基于 Claude Sonnet 4.5 的动态用户模拟，该模拟根据完整的对话历史和场景变量生成上下文适当的用户响应。用户模拟器不知道底层流程图——它只是扮演一个具有给定偏好的客户。所有条件接收相同的场景规格和用户模拟器。我们评估每个条件每个领域 \(n=200\) 个场景，场景设计用于覆盖流程图路径的全部范围、用户风格（从具体到模糊）、满意度水平（从热情到怀疑）、预算真实性和群体复杂性。

我们使用一种与具体方法无关的 LLM 作为评委的方法 [Zheng 等人，2023 (https://arxiv.org/html/2605.22502#bib.bib23)]，其中 Claude Sonnet 4.5 在不知道对话由哪个系统产出的情况下评估对话质量。为了解决潜在的法官自我偏好偏差（Claude 既是数据生成器又是法官）[Panickssery 等人，2024 (https://arxiv.org/html/2605.22502#bib.bib17)]，我们使用一个独立的 GPT-4.1 法官，采用相同的评分细则对所有对话进行重新评分；GPT-4.1 法官在所有三个领域也给出了可比较的上下文内质量的 83-99%，并且定性发现（编译模型优于同模型编排器，上下文内基线领先）对法官选择是稳健的（附录 C (https://arxiv.org/html/2605.22502#A3)）。每次对话在五个标准（1-5 分制）上评分，每个级别都有特定的行为锚点：

**任务成功**：代理是否正确执行程序直至适当的终止状态，在每个决策点是否一致且准确地处理？(5 = 完整的程序，清晰的终止状态；3 = 中间阶段完成但对话无疾而终；1 = 没有有意义的进展)

**信息准确性**：代理是否正确使用并保留用户提供的所有信息？(5 = 每个细节都正确反映；1 = 编造细节或忽略输入)

**一致性**：代理是否在整个对话中保持连贯的状态？(5 = 没有矛盾或重复提问；1 = 反复自相矛盾)

**优雅处理**：代理处理变化、歧义和边缘情况的能力如何？(5 = 平滑适应；1 = 任何偏差都会打破流程。如果用户没有提出挑战，则上限为 3 分。)

**自然度**：对话读起来是否像与一个熟练的人类代理交谈？(5 = 与人类无异；1 = 机械、照本宣科)

对于统计分析，在同一轮中评估的条件按场景索引配对；分别评估的条件使用非配对检验。因为用户模拟器...