我在《Agent 时代的工程学：六个决策点》里列过一张地图，六个决策点覆盖了控制流、行动接口、上下文、单体/多体、评测、能力提升。但那张表有一个位置空着没填：一条业务流程本身，该住在哪里？代码里、system prompt 里、技能库里，还是别的什么地方？2026 年 5 月澳大利亚墨尔本大学 Dennis 团队的《Compiling Agentic Workflows into LLM Weights》（arXiv 2605.22502）补上第四把椅子——把流程编译进 8B 小模型的权重里——并给出一组让 LangGraph 阵营需要认真回应的数字。这篇把这把椅子摆进决策地图，顺便解释为什么它不是对苦涩教训的反叛。
先摆前三把椅子：过程知识已经有过三个家
在这篇论文之前，Agent 工程师默认过程知识只有三个可能的落脚点。
椅子一：代码里的外部 orchestrator。 LangGraph、CrewAI、Google ADK、OpenAI Agents SDK、Semantic Kernel、Strands、LlamaIndex 全都属于这一派，合计 29 万 GitHub star。做法是：在 LLM 上方架一个 orchestrator，每一轮由代码决定「现在应该跳到哪个节点、注入哪段 prompt、解析什么输出」。LangGraph 单库就有约 3 万 star，占了这派的第一梯队。
椅子二：前沿模型的 system prompt（in-context orchestration）。 Anthropic 在《Building Effective Agents》里给出的反直觉建议——「很多场景根本不需要 agent 框架」——本质上就是这条路：把整张流程图序列化成文本，塞进 Claude/GPT 的 system prompt，让前沿模型自己 self-orchestrate。Dennis 团队自己去年的一篇文章（Dennis et al., 2026a）已经证明：对纯 procedural 任务，这条路在质量上碾压 orchestrator（4.53 vs 4.17 五分制评分）。但代价是三条硬约束：每一次会话都得用前沿模型、上下文窗口被 procedure 占掉一大截、专有流程被泄露给第三方 API 提供商。
椅子三：外部技能库（skills / procedural memory）。 Voyager（arXiv 2305.16291）开创的思路——把学会的行为沉淀成可检索、可组合的可执行代码技能，Claude Skills / Agent Skills 是今天的产品形态（我在《Skills 与 MCP 研究前沿》追过这条线）。这条路和椅子一有点像，都是「procedure 存在模型外面」，区别只是存储介质从代码变成了可检索的知识片段。
三把椅子的共同点是：procedure 永远在推理时被外部送进模型——不管送进来的是 orchestrator 的 prompt 片段，还是完整的 system prompt，还是从技能库检索出来的知识条目，模型自己不知道流程长什么样。
第四把椅子：编译进权重的 Subterranean Agent
Dennis 团队的第四把椅子叫 subterranean agent——地表下的 agent。名字来自一张图：外部 orchestrator 是「地表编排」（用户←orchestrator←LLM），subterranean 版本把 orchestrator 藏到训练管线里去（用户直接对 LLM 讲话，orchestrator 只在训练时露面）。
编译管线四步：
- 把 procedure 定义成有向图 F = (N, E, n₀, T)：N 是节点（每个节点有 agent/user 角色和 prompt 模板），E 是带条件的边，n₀ 是起点，T 是终止节点（成功/放弃/升级）。
- 合成对话生成：用 Claude Sonnet 4.5 沿流程图采样路径，按节点模板 turn-by-turn 生成上下文相关的合成对话。每个节点看到的是「当前节点模板 + 完整对话历史」——保证生成质量足够高。
- 全量微调（不是 LoRA）：论文明确点出「Dennis et al. 2026b 系统研究了 LoRA rank 16–128，在 procedural 任务上都够不着全量微调」。原因是过程内化要求修改模型的隐式状态跟踪行为，比风格调整更深。用 AdamW 8-bit（3B）或 DeepSpeed ZeRO-3（8B），lr 2×10⁻⁵ cosine decay。
- 无 orchestration 部署：推理时只给一句最小 system prompt（“You are a helpful travel booking assistant”），没有流程指令、没有节点状态、没有路由逻辑——一切都在权重里。
跑通这个管线的门槛低到让人意外：3B 版本在一张 RTX 5090 上 3.5 小时训完，8B 版本在 8×A100 上 10 分钟一个 epoch。这个门槛，是这条路值得写进决策地图的第一个理由。
三个障碍被数字化拆掉
论文的贡献不在管线（SimpleTOD、FireAct、SynTOD、WorkflowLLM、Agent Lumos 早就跑通了同类技术），而在于把三个「大家默认过不去」的障碍逐个测出数字：
障碍一：质量真的够吗？
三个实测领域，参数量差 ~70 倍：
| 领域 | Subterranean | LangGraph Orch | In-Context 前沿 |
|---|---|---|---|
| 旅游预订 14 节点（3B） | 4.11 / 4.75 / 4.34 / 4.07 / 4.12 | 4.17 / 4.21 / 4.32 / 4.62 / 4.84 | 4.53 / 4.64 / 4.96 / 4.96 / 5.00 |
| Zoom 支持 14 节点（8B） | 4.50 / 4.26 / 4.42 / 4.62 / 4.87 | 4.62 / 4.75 / 4.55 / 4.52 / 4.64 | 4.92 / 4.92 / 5.00 / 5.00 / 5.00 |
| 保险理赔 55 节点 6 枢纽（8B） | 4.47 / 4.40 / 4.51 / 4.81 / 4.92 | 4.42 / 4.45 / 4.39 / 4.38 / 4.58 | 4.78 / 4.78 / 4.82 / 4.96 / 5.00 |
（五个分数依次是：任务成功、信息准确、一致性、优雅处理、自然度；n=200，Claude Sonnet 4.5 作 judge，1–5 分制。）
看两个数字：8B 编译版在 Zoom 和保险两个领域，5 项指标里有 3 项打过或打平 Claude Sonnet 4.5 + LangGraph 的组合——参数量差 70 倍还能反超。跟纯 in-context 前沿的差距集中在信息准确度上（87%），这是「模型知识广度」瓶颈，不是「跟不跟得住流程」瓶颈——扩到更大基座就能补齐。
障碍二：算上自建成本，真的更便宜吗？
单次会话成本表：
| 领域 | In-Context | LG Orch | Subterranean | 相对 In-Context 便宜 |
|---|---|---|---|---|
| 旅游 14 节点 | $0.133 | $0.077 | $0.0010 | 128× |
| Zoom 14 节点 | $0.103 | $0.054 | $0.0003 | 296× |
| 保险 55 节点 | $0.327 | $0.174 | $0.0007 | 462× |
（API 侧按 Claude Sonnet 4.5 15/M output；自建按 Qwen3-8B 跑 A100 80GB 预留价 $2.50/hr + vLLM 批量推理。）
便宜的两倍来源：~65× 每 token 便宜（自建 vs API）+ 2–7× token 总量减少（compiled 模型的 prompt 是常数大小，in-context 每轮都要重放整张 procedure，procedure 越复杂 in-context 越吃亏）。462× 里，procedure 复杂度贡献了后半段。
一次性编译成本：数据生成 ~10–40，合计 0.01。这个盈亏平衡数字是这条路能不能立起来的关键：只要一个流程一年跑得动 500 次，就够本。
障碍三：流程改了要不要重训，代价多大？
答案：30–50 分钟一次完整重编译（数据生成 15–30 分钟 + 8×H200 微调 10–15 分钟 + 抽检 5 分钟）。这不是「重训一个大模型」那种以周为单位的工程事件，是 CI/CD 里的一次构建。每天跑一次都不会成为瓶颈。
反直觉的那一击：为什么 8B 打得过 Claude 4.5 + LangGraph？
这才是全篇最扎人的部分。Dennis 团队在 §4.4 里点出 orchestration 有三条结构性代价，subterranean 版本不是「用容量赢」，是用架构规避这三条：
代价一：碎片化推理。 LangGraph 每个节点只看当前节点上下文，模型没有机会对整条流程做整体推理。Subterranean 版本的权重里已经把整张图内化了，每一句回答都是在整条 procedure 的语境下生成的。
代价二：routing 是新增的失败模式。 决策枢纽处，LangGraph 用一个 LLM 分类器选下一条边——这是 orchestrated 架构独有的失败模式，非 orchestrated 架构根本不存在这个环节。数字非常直接：
| 领域 | Subterranean 失败率 | LangGraph 失败率 |
|---|---|---|
| 旅游 | 5.5% | 24.0% |
| Zoom | 11.0% | 9.0% |
| 保险 55 节点 | 9.0% | 17.0% |
（失败=judge 给 task success ≤ 3。）旅游任务 24% 的失败率里，主要成分就是决策枢纽处 routing 走错——subterranean 版本「按构造消灭了这类错误」。
代价三：模板注入压制自然度。 LangGraph 每个节点的 prompt 模板会把「一次问多个问题」硬塞给模型；subterranean 版本从合成数据里学到「每轮问一个问题」的 interview 风格（64% 的轮次恰好一个问题）。因此在自然度指标上，8B 编译版能反超 Claude 4.5 + LangGraph（Zoom: 4.87 vs 4.64；保险: 4.92 vs 4.58，均 p < 0.001）。
这三条加起来的含义很硬：LangGraph 不只是”额外的运行时开销”，它在结构上限制了主模型的能力上限。你用 Claude 4.5 跑 LangGraph，得到的不是 Claude 4.5 的完整能力，是被 orchestration 结构性削弱后的 Claude 4.5。
决策传导链：这个决策会传到哪里？
把「procedure 住在哪里」当决策点，往下看它传导到哪些产品决定：
成本上限： 决定了单次会话价格能压到几分钱还是几毛钱——差两个数量级。SaaS 类产品毛利率的地板。
上下文窗口预算： 在 in-context 路线下，procedure 越大就越挤压对话历史；在 subterranean 路线下，procedure 常数大小占位，对话历史可以吃满窗口。procedure 一旦超过 100 节点，in-context 路线的窗口崩溃就快到了。
保密性边界： in-context 路线下，专有 procedure 每次会话都要发给第三方 API；subterranean 路线下 procedure 只在训练时接触外部 API，运行时完全本地权重。企业合规、金融、医疗类客户会直接把这一条作为门槛。
更新节奏： 外部 orchestrator 改流程 = 改代码 = 分钟级；subterranean 改流程 = 重编译 30–50 分钟 = 小时级。这个差距在日更尺度上不是障碍，在分钟级 hotfix 尺度上是。
调试链路： 外部 orchestrator 里流程走到哪一步、为什么走错，看代码日志就能定位；subterranean 里流程完全在权重中，调试要靠 eval 集回归——这条要用评测门禁那套办法接住，才不至于失控。
失败模式转换： routing 错误（orchestrator 独有）消失，但幻觉、越权、编造字段（LLM 通病）依然在——甚至可能因为「模型自己 self-orchestrate」而更难约束。你换的是一组失败模式，不是消除失败。
收敛度：还没收敛，但技术障碍已经被数字化拆掉
按我在决策地图里定的判据——「有论文把原理讲清楚 + 有不止一家生产系统落成默认组件」——这个决策点只完成了前半段：
- 论文侧：SimpleTOD (2020)、FireAct (2023)、SynTOD (2024)、WorkflowLLM (2024)、Agent Lumos (2024)、Dennis 2026——技术管线走通六年了。Dennis 2026 这篇把最后三个「大家默认不行」的障碍（质量、成本、灵活性）逐条测出数字。
- 产品侧：这派整体 GitHub star ~3000（Agent Lumos 独占大头），vs orchestration 派 29 万 star——差了 100 倍社区规模。生产环境里几乎没人这么干，我目前也没看到明面上的商业化项目在跑 subterranean。
判断：这是决策地图里的 explore 区，但赌哪个方向已经比较清楚——高频程序性任务（客服、结算、单一垂类工单处理）是第一波会落地的地方，因为盈亏平衡只需要 500 次会话，一个中等规模客服流程一周就跑到了。低频、探索型、开放式任务（编程助手、研究 agent）还是 in-context 或 orchestrator 的地盘，不适合编译。
接线：这把椅子怎么和已有节点挂上钩？
- 对《Agent 时代的工程学：六个决策点》的补丁：原地图决策点六是「靠外挂还是靠训练」，训练路径整体标 ❌ 未收敛。这篇论文把训练路径里的流程内化这一支从「未收敛」推进到「技术障碍已经拆掉，产品端待启动」，可以在原表加第七行。
- 对《Loop 还是 Graph？》的解答：Loop 派信模型、Graph 派信代码，这篇给出第三条路——训练时按 Graph 设计（严谨的流程图），运行时看起来像 Loop（模型 self-orchestrate）。原地图上「谁决定下一步」的争论在这里被消融：设计权由人拿，执行权由模型自己拿。
- 对《主模型在思考，谁在打下手？》的极端化：那篇讲了小模型接管主模型推理循环里的 8 个岗位（路由员、安检员、精简师…）。subterranean 是同一逻辑的极端形式——整条 procedure 都由小模型自己吃掉，主模型直接不出场。SLM 岗位地图里最激进的那格，就是编译版。
- 对《训练小模型的三条路》的补第四条：原三条是蒸馏、量化、专家混合。第四条：procedural compilation——不是通用能力压缩，是把一段业务流程当成需要压进小模型的知识。用大模型（Claude 4.5）合成数据这一步，和蒸馏共享底层机制。
- 对评测门禁体系的强依赖：subterranean 的调试成本高（权重级黑盒），配套必须先把 eval 门禁建起来——否则重编译一次没法确认没退化，这条路根本走不通。
苦涩教训是站在哪一边？
看上去这条路有很强的「手工设计流程图」味道——像是在跟苦涩教训对着干。但换一个视角就翻过来了：
在这条路里，flowchart 只是数据生成脚手架，训练完之后就扔了。运行时权重里学到的是”如何自然地跟用户走完这类流程”——是能力，不是规则。手工痕迹在训练时被溶解成学到的表示。
真正被苦涩教训吃掉的是 orchestrator。 LangGraph 每个节点上人写的 prompt 模板、决策枢纽处的路由分类器、状态转移逻辑——这些才是”人工设计的巧劲”。这篇论文的实验数据（LangGraph 在旅游任务上 24% 失败率、graceful handling 反被 8B 打过）恰恰印证：这些手工巧劲在为通用能力让路。
同样的模式在别处已经反复上演：Cursor 曾经手工 patch 编辑，被通用模型收回；Reasoning-to-program 的三次外包里，外部脚手架不断被内化进模型。subterranean 是同一部剧的下一幕，只是这次被溶解的不是 tokenization 或 patch 逻辑，是整条业务流程。
苦涩教训不反对”用大模型合成数据教小模型”——那是苦涩教训的经典执行路径（大模型足够强 → 合成足够好的数据 → 小模型足够便宜 → 端到端便宜地把任务办成）。它只反对”用人手工写死一条推理路径”。这篇论文的做法是前者，不是后者。
一个诚实的提醒
我没有亲手复现这个管线（RTX 5090 我没有，但 A100 云上 3 小时也就 20，不做实验永远不知道纸面上的 462× 在自己场景里能兑现多少。
实操版本已经铺好：见陪读篇 《手把手把 5 节点流程编译进 0.5B 权重——Subterranean Agent 实操陪读篇》——把规模缩到 Qwen2.5-0.5B + 一张消费级显卡（或 M-series Mac）能跑的版本，含 5 节点日报归档流程、Claude API 合成数据脚本、SFTTrainer 全量微调代码、对照 Claude in-context 的评测脚本，以及一份 12 项自检清单。约 $2 API 花费，本地训练免费。
参考来源
核心论文
同技术流派的前置工作
- SimpleTOD (Hosseini-Asl et al., 2020)
- FireAct (Chen et al., 2023)
- SynTOD (Samarinas et al., 2024)
- WorkflowLLM (Fan et al., 2024)
- Agent Lumos (Yin et al., 2024)
被论文测量的对照面
- LangGraph（29 万 star 中最大单库，~3 万 star）
- CrewAI、Google ADK、OpenAI Agents SDK、Semantic Kernel、Strands、LlamaIndex（论文列举的 orchestration 派整体）
- Anthropic: Building Effective Agents（in-context 路线的工程共识）
接线到已有节点