Subterranean Agent：把工作流编译进模型权重

学习目标

读完本文后，你应该能够：

1. 区分流程知识的三种存放位置（运行时编排器、in-context、模型权重）及其代价
2. 理解 Subterranean Agent 的「训练时外显，运行时内化」路线——数据生成、微调、部署的完整路径
3. 解读论文的三个实验领域（Travel Booking、Zoom Support、Insurance Claims）及其对工程实现的提醒
4. 评估 128-462 倍成本优势的前提条件，不把结论外推到开放域任务
5. 判断你的场景是否适合尝试编译路线，以及如果适合，按什么顺序落地风险最低

目录

• 学习目标
• 先分清流程知识放在哪里
• 编排器多出来的失败面
• 实验设置
• 一次理赔任务怎样被编译
• 质量：小模型先学流程，再靠容量补自然度
• 分数之外的边界
• 成本优势来自两个乘数
• 灵活性：30-50 分钟成立，但要看硬件条件
• 为什么论文坚持全参数微调
• 和相关工作的区别
• 适合使用 Subterranean Agent 的场景
• 一个更稳的落地顺序
• 最后的判断
• 自测题
• 进阶路径
• 参考资料

Agent 编排不是错，但它把流程知识留在了每一次推理里。Dennis 等人的 Subterranean Agent 论文尝试把这部分稳定知识挪到训练阶段：先用流程图和前沿模型生成对话，再把这些轨迹微调进 3B-8B 小模型。运行时不再注入流程图，也不再由外部路由器逐步调度。

这条路线只适合程序性任务：旅行预订、Zoom 支持、保险理赔这类步骤明确、分支可枚举、终点可判断的流程。离开这个前提，论文里的 87%-98% 质量和 128-462 倍成本优势都不能直接外推。

先把来源说清楚：这不是 OpenAI 论文。arXiv 页面显示作者为 Simon Dennis、Rivaan Patil、Kevin Shabahang、Hao Guo。OpenAI Agents SDK 只是在文中和 LangGraph、CrewAI、Semantic Kernel、Strands、LlamaIndex 一起出现，作为“表面编排”生态的一部分。把它写成“OpenAI 论文”，后面对实验边界的理解会偏。

先分清流程知识放在哪里

讨论这篇工作，先别急着问它能不能替代某个框架。更准确的问题是：流程知识到底放在运行时、prompt 里，还是模型权重里。

Subterranean Agent 走的是一条“训练时外显，运行时内化”的路线：

流程图 / 编排器
  -> 采样路径与场景变量
  -> Claude Sonnet 4.5 生成合成对话
  -> 全参数微调 Qwen 3B / 8B
  -> 运行时部署小模型，不再注入流程图

编排器没有消失，它被前移到了训练数据生成阶段。过去每次用户对话都要把流程解释给模型听；这条路线先把流程变成训练分布，再让模型在权重里学会“走流程”。

编排器多出来的失败面

外部编排在早期 Agent 系统里很自然。模型不稳定，就用状态机兜底；模型不知道下一步，就由图框架告诉它；模型容易跑偏，就把每个节点写成更窄的 prompt。

问题是，当前前沿模型已经能在不少程序性任务里自行维持流程。Dennis 等人的前序论文 In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks 做过一个对照：把完整流程放进 Claude Sonnet 4.5 的 system prompt，让模型 self-orchestrate，质量普遍高于 LangGraph 编排器。

外部编排会额外带来三类摩擦：

1. 节点 prompt 会切碎对话上下文。编排器在当前节点里生成回复，看起来更可控，但模型对完整对话的整体感会变弱，容易重复提问或忽略早先信息。
2. 路由本身会引入失败模式。每个 decision hub 都要选择下一条边；一旦路由错了，后面生成得再自然也救不回来。
3. 模板会限制自然对话节奏。节点模板往往把多个问题塞进一个轮次，而真实客服或销售对话更常见的节奏是一次只推进一个问题。

In-context 方案避开了这些摩擦，却把成本推到了 prompt 上：每轮都要带完整流程图，流程越大，token 越贵；还必须调用前沿模型；内部流程也会暴露给第三方模型服务。Subterranean Agent 沿着这个缺口往下走，保留 self-orchestration 的整体感，同时把流程从 prompt 移到权重。

实验设置

实验覆盖三个领域，复杂度从中等流程逐步拉到大型理赔流程。

三个领域都用 n = 200 个场景评估。场景覆盖不同路径、用户风格、满意度和任务变量。评估者是 Claude Sonnet 4.5，采用盲评，不知道对话来自哪种系统；论文还用 GPT-4.1 按同一 rubric 复评，以检查 Claude 作为生成器和裁判时的偏好风险。

评分维度是 5 个，每项 1-5 分：

两套基线决定了这组实验该怎么读：

1. LangGraph Orchestrator：Claude Sonnet 4.5 通过 LangGraph 执行流程，在 decision hub 用 LLM 分类器选择下一条边。
2. In-context baseline：同样是 Claude Sonnet 4.5，但把完整序列化流程图放进 system prompt，让模型自行决定下一步。

In-context baseline 在这里承担质量上界角色：前沿模型、完整流程上下文、无外部路由失败；它并不是现实部署成本最低的方案。

一次理赔任务怎样被编译

以保险理赔为例，这已经超出简单问答：用户提交理赔，系统判断是车险、财产险、健康险还是责任险；随后收集材料、检查缺失、判断覆盖范围和除外责任，最后进入赔付报价与反报价。整条流程被写成一个 55 节点图。

训练阶段会发生四步：

1. 从流程图中采样一条合法路径，例如“车险事故 -> 缺少维修发票 -> 重新请求文件 -> 覆盖范围成立 -> 进入报价”。
2. 采样场景变量，例如事故日期、保单类型、用户是否焦虑、材料是否齐全。
3. 用 Claude Sonnet 4.5 沿着路径逐轮生成自然对话。生成器看到当前节点模板和完整对话历史，但最终训练样本只保留自然对话，不保留流程标签。
4. 用这些合成对话对 Qwen 3B 或 Qwen3-8B 做全参数微调。

部署后，模型只看到类似下面的最小提示词：

You are a helpful travel booking assistant.

没有流程图状态，没有 routing logic，也没有“当前节点是 X”。如果用户在理赔中途说“我找不到维修发票”，模型仍然能回到补材料路径，因为训练数据反复呈现了这种对话分布。流程不再作为运行时规则出现，而是变成模型内部的隐式状态跟踪能力。

质量：小模型先学流程，再靠容量补自然度

这组实验的关键设计，是同模型对照：同样的 Qwen 2.5 3B Instruct，一组继续走显式编排，一组把流程编译进权重。

Travel Booking：同一个 3B 模型，编译比编排更稳

3B 编译模型没有打败 Claude；它在自然度和异常处理上仍然落后于前沿模型。关键在同模型对照：相同基础模型、相同流程、不同架构下，编译模型 5 项数值都高于 3B 编排器，其中 Task Success、Consistency、Graceful Handling、Naturalness 这 4 项达到显著差异；Information Accuracy 只是正向趋势，论文报告 p = .29，不能写成显著领先。

这个结果对工程实现很有提醒：编排器不总是“给小模型加护栏”。当节点模板和路由把对话切碎时，小模型反而更难形成端到端状态感。

Zoom Support：8B 后自然度补上来了

Zoom 支持任务换成 Qwen3-8B，并把训练数据扩到 6,264 条训练对话。

8B 编译模型在 Naturalness 上显著高于 LangGraph Orchestrator；Information Accuracy 明显落后。Graceful Handling 数值上略高，但论文把 Task Success、Consistency、Graceful Handling 归为 comparable，不能按“全面领先”解读。

容量增加后，模型能补上一部分“像熟练客服一样说话”的能力；但 Zoom 这类产品支持还需要大量具体 UI、设置路径、错误码知识，信息准确性仍然是瓶颈。

Insurance Claims：55 节点流程没有把方案压垮

保险理赔是论文的压力测试：55 个节点、6 个 decision hub、2,381 条无环路径。结果如下：

8B 编译模型达到 In-context 基线 92%-98% 的质量区间。对比 LangGraph，它在 Graceful Handling 和 Naturalness 上显著领先，Consistency 数值更高；Task Success 和 Information Accuracy 与 LangGraph 接近，论文没有把它们写成显著胜出。

这里的重点是失败面：流程越大，外部路由的错误越容易累积。LangGraph 在每个 decision hub 都要做一次分类或路由；编译模型没有显式路由步骤，少掉了这类失败模式。

分数之外的边界

这些数字很漂亮，但不能把结论外推得太远。

第一，论文测的是程序性对话任务，不是开放域研究、代码修复、长程工具使用或真实交易系统。旅行预订、技术支持、保险理赔都有明确分支和终止状态，这是 Subterranean Agent 最舒服的区域。

第二，训练数据由 Claude Sonnet 4.5 合成，评估也主要由 Claude Sonnet 4.5 完成。GPT-4.1 复评降低了裁判偏好风险，但没有完全替代真实用户实验、人工业务审核或线上 A/B。

第三，“运行时无编排”不等于“生产系统无工程外壳”。查库存、创建订单、修改赔案状态、触发退款，仍然需要权限、审计、工具调用、幂等和回滚。更稳的做法，是把稳定的对话策略和分支判断编译进模型，把外部副作用留给确定性的服务层。

成本优势来自两个乘数

论文报告的 128-462 倍成本优势来自两个乘数叠加。

乘数一：自托管小模型的每 token 成本

论文按 Qwen3-8B 在 A100 80GB 上通过 vLLM 批量推理估算成本。假设 GPU 租用价格为 $2.50/hr，吞吐参考 8B 模型公开 benchmark，折算约为：

这里得到约 65 倍每 token 成本差。这个数字依赖具体硬件价格、batch size、吞吐、利用率和运维能力；GPU 空转时，实际成本会变差。

乘数二：流程图不再每轮塞进 prompt

In-context baseline 每轮都要带完整流程图。论文估计 token 体积膨胀从 14 节点任务的约 2 倍，到 55 节点保险流程的约 7 倍。Subterranean Agent 的 prompt 是固定大小，流程越大，省下的流程注入成本越多。

这张表不支持“节点越多一定越便宜”这种读法。Zoom 和 Travel 都是 14 节点，但成本比不同，说明对话长度、输出长度、流程文本长度都会影响结果。更稳的结论是：当流程文本很长、每次都要重复注入时，编译进权重的成本优势会被放大。

论文还报告了 wall-clock 时间：保险理赔里 Subterranean Agent 平均 43.2 秒，LangGraph Orchestrator 平均 120.8 秒，约 2.8 倍加速。这里不只有模型尺寸差异，外部 API 往返和 decision hub 额外调用也被拿掉了。

灵活性：30-50 分钟成立，但要看硬件条件

“流程一变就要重新训练”是这条路线最大的心理门槛。论文把 recompile 拆成三段：

1. 数据生成：Claude Sonnet 4.5 遍历新流程图，生成约 1,600 条合成对话。对话彼此独立，可以并行；论文估计 15-30 分钟，主要受 API rate limit 限制。
2. 全参数微调：在 8xH200 上做数据并行，论文估计 10-15 分钟；如果只有单张 A100 80GB，训练约 3 小时。
3. 评估 spot-check：50 个场景的 vLLM 批量检查约 5 分钟；包括服务启动则约 10-15 分钟。

“30-50 分钟 recompile”只对应生产级 GPU 集群和并行数据生成条件。对普通团队，更现实的基线可能是 3-4 小时。即便如此，它仍然更像一次可自动化的模型构建流水线，而不是季度级的大训练项目。

工程上可以按变更频率判断：流程每周或每月改一次，编译路线可以进入 CI/CD；流程每天多次变更，运行时编排或 in-context 配置仍然更灵活。

为什么论文坚持全参数微调

论文没有把 LoRA 当作主方案。它引用了 Dennis 等人的 companion study：在 procedural tasks 上，LoRA rank 16-128 难以接近全参数微调。

这符合直觉。很多 LoRA 成功案例处理的是风格、格式、领域语气或轻量知识注入；这里要学的是多轮隐式状态跟踪：用户已经给过什么信息、当前处在哪个流程阶段、哪些分支已经排除、什么时候该终止或升级。它更像改变模型内部的对话状态机，而不是给模型贴一层新语气。

这不代表 LoRA 永远不行。至少在这组证据里，要把复杂流程变成模型的内生行为，全参数更新更可靠。

和相关工作的区别

把流程能力训练进模型并不新。这项工作把问题从“能不能 work”推进到“工程上值不值得换”。

亮点不在“模型可以学工作流”这个命题本身，而在于它把开发者最常问的三件事摆到实验台上：质量差多少、便宜多少、流程变了要多久。

适合使用 Subterranean Agent 的场景

更适合的场景：

1. 流程稳定：更新频率按周或按月计算，而不是每天不断改。
2. 分支清晰：能画成节点、边、条件和终止状态。
3. 对话量足够大：至少能摊销一次性数据生成和微调成本。
4. 流程逻辑敏感：不希望每轮把内部 SOP、赔付规则、客服策略发给第三方 API。
5. 上下文膨胀明显：流程图很大，每轮注入都在烧 token。

继续保留运行时编排的场景：

1. 流程高频变化：产品策略、合规规则、促销规则每天变。
2. 工具副作用重：系统要频繁写数据库、扣款、下单、发工单，需要确定性审计。
3. 强依赖实时数据：报价、库存、风控、政策状态都要即时查询。
4. 任务开放度高：模型需要探索、规划、调用多种工具，而不是沿着固定 SOP 前进。
5. 质量必须可解释到每个分支规则：监管或审计要求看到显式决策路径。

更可行的落地方式通常是混合架构：把稳定的对话推进策略编译进模型，把权限、外部动作、审计日志、灰度发布留在常规服务层。模型负责“怎么把对话往前带”，系统负责“哪些动作可以真的发生”。

一个更稳的落地顺序

团队真要试这条路线，不建议一上来就替换生产编排器。可以按下面的顺序收敛风险：

1. 先做流程盘点：把当前编排器里的节点、边、条件、终止状态抽出来，确认它真的是程序性流程。
2. 生成影子数据集：用现有流程和前沿模型生成 1,000-3,000 条合成对话，同时保留场景变量与期望终止状态。
3. 训练小模型并离线评估：和现有 LangGraph / CrewAI / Agents SDK 方案跑同一批场景，至少看任务完成、信息准确性、一致性、异常处理和自然度。
4. 单独评估失败样本：重点看路由错、重复问、编造政策、提前终止、升级失败这些生产里最贵的错误。
5. 灰度只读场景：先用于客服建议、内部助手、质检模拟这类低副作用场景，再考虑写入业务系统。
6. 把 recompile 做成流水线：流程图变更后自动生成数据、训练、评估、产出对比报告，失败则回退到上一版模型。

这条路线不追求“没有编排器”的纯粹性。它把编排器从在线路径挪到构建路径，让稳定流程变成一种可版本化、可回归测试、可灰度发布的模型资产。

最后的判断

Subterranean Agent 把 Agent 工程里的一个老问题重新摆正了：反复使用的流程知识，不一定要每轮放进 prompt；足够稳定的流程，也不一定要每轮由外部状态机解释。

但这条路只适合“程序性知识”。它不是通用智能体的银弹，也不能替代权限、工具、审计、数据一致性和人工业务验收。论文给出的 87%-98% 质量、128-462 倍成本优势很有吸引力，前提是你的任务确实像文中的三个领域：流程可画图、分支可枚举、输出可评估、变更可进入构建流水线。

最后的问题不再是"要不要编排"，而是：哪些流程应该留在运行时，哪些流程已经稳定到可以进入模型权重。

自测题

1. 流程知识的三种存放位置各有什么代价？举一个具体场景说明。

   答：表面编排——多一层状态机，路由错误会成为新失败源（例如复杂理赔流程的 decision hub 累积错误）。In-context——token 体积随流程膨胀，每次都要调用前沿模型（例如 55 节点保险流程的 prompt 膨胀 7 倍）。Subterranean——流程变更要重编译，适用边界取决于流程稳定性（例如每周改一次的促销规则不适合）。

2. 论文报告的 128-462 倍成本优势来自哪两个乘数？每个乘数的前提是什么？

   答：乘数一——自托管小模型 vs 云 API 的每 token 成本差（前提：GPU 租用价格、吞吐量、利用率）。乘数二——流程图不再每轮塞进 prompt（前提：流程文本很长，注入成本随流程变大而放大）。

3. 为什么论文坚持全参数微调而不是 LoRA？

   答：要学的是多轮隐式状态跟踪（用户已经给过什么信息、当前处在哪个流程阶段、哪些分支已经排除），更像改变模型内部的对话状态机，而不是贴一层新语气。LoRA 在 procedural tasks 上难以接近全参数微调。

4. 「30-50 分钟 recompile」的前提条件是什么？对普通团队更现实的基线是多少？

   答：前提——生产级 GPU 集群 + 并行数据生成。现实基线——单张 A100 80GB 训练约 3 小时，加上数据生成和评估，总共 3-4 小时。

5. 如果你要评估一个流程是否适合编译路线，按什么顺序验证？

   答：（1）流程是否可画成节点、边、条件和终止状态；（2）对话量是否足够摊销一次性成本；（3）和现有编排器跑同一批场景，对比任务完成、信息准确性、一致性、异常处理；（4）单独评估失败样本（路由错、重复问、提前终止）；（5）灰度只读场景，再考虑写入业务系统。

进阶路径

阶段一：理解论文（1-2 天）

• 通读论文 main text，重点看 Travel Booking 和 Insurance Claims 两个实验
• 理解「训练时外显，运行时内化」的路线和 in-context baseline 的对照关系
• 厘清 128-462 倍成本优势的两个乘数和各自前提
• 想清楚：你的场景里有没有「流程稳定、分支清晰、对话量大」的任务

阶段二：影子评估（3-5 天）

• 选一个现有编排器里的程序性流程（例如客服对话、预订流程、理赔初审）
• 用前沿模型生成 200-500 条合成对话（参考论文的数据生成方法）
• 和现有方案跑同一批场景，记录任务完成率、信息准确性、一致性、异常处理
• 重点看失败样本：路由错、重复问、编造政策、提前终止

阶段三：小规模微调实验（1-2 周）

• 如果用 Qwen3-8B 做全参数微调，需要 8xH200 或等效 GPU
• 如果只有单张 A100，训练时间约 3 小时，可以接受
• 用 vLLM 批量推理做离线评估，对比 LangGraph / in-context 的同场结果
• 记录：质量差多少、便宜多少、recompile 要多久

阶段四：混合架构落地（1-2 个月）

• 把稳定的对话推进策略编译进模型
• 把权限、外部动作、审计日志、灰度发布留在常规服务层
• 模型负责"怎么把对话往前带"，系统负责"哪些动作可以真的发生"
• 把 recompile 做成 CI/CD 流水线：流程图变更 → 自动生成数据 → 训练 → 评估 → 对比报告 → 失败回退

参考资料

• Simon Dennis, Rivaan Patil, Kevin Shabahang, Hao Guo. Compiling Agentic Workflows into LLM Weights: Near-Frontier Quality at Two Orders of Magnitude Less Cost. arXiv:2605.22502, 2026-05-21.
• Simon Dennis, Michael Diamond, Rivaan Patil, Kevin Shabahang, Hao Guo. In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks. arXiv:2604.27891, 2026-04-30; v2 2026-05-05.
• Chen et al. FireAct: Toward Language Agent Fine-tuning. arXiv:2310.05915, 2023.
• Fan et al. WorkflowLLM: Enhancing Workflow Orchestration Capability of Large Language Models. arXiv:2411.05451, 2024.
• Hosseini-Asl et al. A Simple Language Model for Task-Oriented Dialogue. NeurIPS 2020.