《把指南针烧进大脑：一只8B模型，单步推理替代七层编排》

全世界的 LLM Agent 框架，加起来有 29 万颗 GitHub 星星。

LangGraph、CrewAI、Google ADK、OpenAI Agents SDK、Semantic Kernel、Strands、LlamaIndex——七个框架，七种编排方式，同一种架构：一个调度器坐在模型外面，每一轮对话给它塞指令、解析输出、决定下一步走哪条路。

调度器像一个人站在模型背后，每到岔路口就拍拍它的肩膀："左边。""现在右边。""问问用户预算是多少。""好，现在根据预算给三个选项。"

这套架构成立三年。三年里，几乎所有人都认为这是 AI Agent 的唯一形态。

Simon Dennis，墨尔本大学的一个人，看了三年之后写了一篇论文。他不是在改进编排器——他问了一个更根本的问题：如果根本不需要编排器呢？

🪜 三种架构，一座巴别塔

论文摆了三种架构出来，差距一目了然。

表面编排。编排器坐在用户和 LLM 之间。每一轮——注入节点提示、解析 LLM 输出、查流程图决定下一步、把新提示塞回去。七个框架，全走这条路。代价三层：每轮额外的 API 调用、提示词膨胀（流程指令每轮都塞进上下文窗口）、以及路由决策本身的失败率——语言模型判断"下一步该走火哪条边"这件事，并非零失误。

上下文提示。把整个流程图直接写进系统提示里，让模型自己导航。Dennis 之前的论文已经证明这种做法在程序化任务上能拿到近乎完美的质量（4.53–5.00/5.0）。但代价是：每一个对话都需要前沿模型、每一轮都把流程图塞进 token、每一次都把私有业务流程暴露给第三方 API。

地下智能体——前两种架构之外，还有一个选项。把流程图的全部知识在训练时塞进模型权重。运行时，用户和模型直接对话。没有编排器。没有流程图注入。没有路由决策。模型"知道"该做什么——就像你不需要一个外部经理告诉你"先问对方名字，再问预算"——你大脑里的程序已经烧在那里了。

这个想法不是新东西。SimpleTOD、FireAct、WorkflowLLM、Agent Lumos——前人都证明过这条路走得通。但开发者的实际选择呢？编排框架 29 万星，编译方案加起来不到 3000 星。差 100 倍。

三年来没人问：这是为什么？

🧱 三堵墙

Dennis 把开发者不碰编译方案的原因拆成三件事。

质量焦虑。一个微调过的 3B 小模型，能和 Claude Sonnet 4.5 加 LangGraph 编排器比吗？直觉告诉你不能。参数差了 70 倍。

成本怀疑。自建部署听起来便宜——但你得买 GPU、跑推理、维护服务。真的比按 token 付费便宜吗？

灵活性恐惧。流程图一改就得重新训练。重训练是不是要好几天？业务周一上线新版流程，模型周三才训完——你敢用吗？

论文用三个真实业务场景（旅行预订 14 节点、Zoom 技术支持 14 节点、保险理赔 55 节点）逐一打了回去。

🎯 第一堵墙：质量

旅行预订是一个 14 个节点的流程图。问候、收集偏好、判断信息够不够、呈递方案、接受/拒绝/比较、确认预订。86 条无环路径，4 到 17 轮对话。

四个条件，各 200 个测试场景：3B 地下智能体 vs 同一个 3B 模型加编排器 vs Claude Sonnet 4.5 加 LangGraph vs Claude 上下文提示。

结果精炼到一句话：编译本身就有增益。 同一个 3B 基础模型，编译进权重后——在任务成功率、一致性、优雅处理、自然度四个维度上，全部显著优于显式编排的同一个模型（p < 0.001）。信息准确度也偏高，只是未达显著。编排器在同一个模型上反而拖了后腿。

为什么？

编排器有三个结构性代价。第一，它从当前节点的局部上下文生成响应——没有全局意识。那种"你已经问过我三遍出发日期了"的客服机器人，就是局部上下文。第二，路由决策本身就是故障源——LangGraph 编排器在旅行预订上的失败率是 24%，地下智能体仅 5.5%。第三，模板注入扼杀了自然的对话节奏。

地下智能体没有这三个代价。它通过内化的权重全域推理、零路由失败、训练数据里的自然对话塑造了无约束的回复风格。

但 3B 在优雅处理和自然度两栏只达到上下文提示的 82%——太小了。论文于是把模型扩到 8B。

Zoom 技术支持。14 节点，平行排错结构。音频问题、视频冻结、连接掉线、屏幕共享故障——按症状分流，逐级排查，成功则结束，失败则升级。产品特有的知识（Zoom 的 UI、设置菜单、常见错误码）全部编入了训练数据。6,264 条合成对话。

8B 地下智能体在 Zoom 上：自然度 4.87/5，优雅处理 4.62/5。分别达到上下文提示的 97% 和 92%。信息准确度是最大的缺口（87%）——不是流程跟不对，是世界知识不够广。这缺口不是编译方案的问题，是模型大小的问题。

而和 LangGraph 编排器比——一个用了 70 倍大模型的编排器——地下智能体在自然度上显著更高（4.87 vs 4.64, p < 0.001）。流畅度上的优势，来自内化权重里生成的约束更少的回复。

保险理赔——这才是重头戏。55 个节点，6 个决策枢纽，2,381 条路径。嵌套循环（要文件 → 审文件 → 文件不全 → 再要），跨阶段依赖（覆盖范围决定赔偿方案）。几乎四倍于前两个领域的复杂度。

8B 地下智能体：优雅处理 4.81/5，自然度 4.92/5，一致性 4.51/5——三项全部显著高于 LangGraph 编排器（p < 0.001）。达到上下文提示的 92–98%。

在 55 节点的高复杂度流程上，一个 8B 小模型内化权重后，碾压了一个 70 倍大的模型加业界最流行的编排框架。

💰 第二堵墙：成本

成本减幅有两层叠加。

单 token 成本：8B 模型自部署在 A100 上（vLLM 批量推理，\(2.50/小时）。按行业标杆性能——15K token/s 预填、3K token/s 自回归解码——折出有效费率约\)0.05/M 输入 token、\(0.23/M 输出 token。对比 Claude Sonnet 4.5 的\)3/M 输入、\(15/M 输出——单 token 成本差约 65 倍。 **Token 量缩减**：上下文提示必须每一轮把流程图塞进系统提示。14 节点约 2 倍 token 膨胀，55 节点约 7 倍。地下智能体的提示词=常数大小——"你是一个旅行预订助手"——15 个 token。不随流程复杂度增长。 两层叠加： - 旅行预订（14 节点）：**128 倍**更便宜（\)0.13 → \(0.0010/对话） - Zoom 支持（14 节点）：**296 倍**更便宜（\)0.10 → \(0.0003/对话） - 保险理赔（55 节点）：**462 倍**更便宜（\)0.33 → \(0.0007/对话） 优势随流程复杂度**增长**。因为地下智能体的提示词是常量，上下文提示和编排器的提示词是线性的。流程越复杂，差距越悬殊。保险理赔对 LangGraph 编排器也是 249 倍便宜。 编译的一次性成本：数据生成约\)40 + 微调计算约 \(10–40，总共\)50–80。任何领域，500 个对话之内回本。对于一个跑 10,000+ 对话的生产级 Agent，编译的摊薄成本每对话不到 1 美分。

地下智能体每对话 \(0.0003–\)0.0010。一个日活 10,000 的客服 Agent，一整天跑下来全部对话总成本不到 \(7。同类系统用 LangGraph + Claude Sonnet 4.5——\)1,740。

⏱️ 第三堵墙：灵活性

如果每改一次流程图都要重新训练好几天，编译方案确实不实用。论文的执行结果表明：没那么久。

30–50 分钟。数据生成 15–30 分钟（Claude API 遍历新流程图，可并行），微调 10–15 分钟（8×H200 数据并行、全精度 AdamW、12 epochs），评估 5–15 分钟。全流程并行化，从改流程图到新模型上线——CI/CD build 的级别，不是重训练大作业的级别。

如果你没有 8 张 H200，单张 A100 80GB 跑完约 3 小时。仍然是"上午改、下午上线"的量级。

🔬 编译器，而不是解释器

论文最有冲击力的数据不是成本，不是质量——是一段对话实录。

旅行预订场景。两个朋友去日本六天，每人 \(1,100 预算，喜欢水上运动和节日。 地下智能体（3B 编译）：第 5 轮就呈递了三个方案，第 7 轮确认预订。"你好！""你们什么时候去？""预算多少？""我推荐祇园祭期间的京都+和歌山海岸方案，水上运动、节日、预算全包。""好的，选项一，确认。" 同模型编排器（3B + 编排框架）：第 4 轮问出发日期，第 6 轮又问了一遍，第 8 轮又又问了一遍。到了第 14 轮才呈递方案。18 轮才完成。 同一个模型。同样的基础能力。**编排器让模型像得了失忆症一样反复问同一个问题。** 地下智能体不需要被反复提醒目标——流程"烧"在权重里，它不是被逐节点注入的。 这就是编译器思维和解释器思维的本质差异。 解释器：每次执行都从源码从头翻译。流程图的每一步都作为指令从外部注入。模型没有关于"整个流程长什么样"的全局理解——它只知道当前节点是什么。 编译器：把源代码翻译成机器码。运行时不看源码。模型在训练时内化了整个流程的统计规律——它不是在"被指挥"，它是在"按照已学的流程行动"。 Dennis 给这种编译进权重的智能体起了个名字：**subterranean agent**——地下智能体。编排器只在训练数据生成时出现过。运行时，用户面对的就只是这个模型本身——编排器已经消失了，化成了权重里的纹理。 --- ### 🦴 LoRA 为什么不行 论文里潜伏着一个独立发现的实验结果：**LoRA 无法内化程序性知识。** "先问预算，再问偏好，然后呈递三个方案，等用户选完，确认预订。"这不是一种风格——这是一组有顺序、有条件分支、需要跨轮追踪状态的步骤。LoRA（低秩适配）在 rank 16–128 范围内的测试全部失败——低秩的更新空间不够深，它改变不了模型隐含的状态追踪行为。 论文在另一篇姐妹篇里详细分析了这个现象，结论是：**程序性知识不是低秩的。** 必须动全参数。 这不是偏好——是实验事实。用 LoRA 编译一个 55 节点的保险理赔流程，它会在决策枢纽上迷路。 --- ### ❓ 诚实的部分 **测试范围是程序化对话任务。** 旅行预订、客服排错、保险理赔——步骤明确、分支有限、结论封闭。不要让一个"旅行预订地下智能体"去写诗或做数学竞赛——它被训练的只有一套流程图里的行为。 **世界知识是真正的瓶颈。** Zoom 支持里 8B 模型的优雅处理和自然度都到了 97%，信息准确度只有 87%。模型记得"先检查 WiFi 还是以太网"的流程，不知道"某个冷门 Zoom 错误码的具体含义"。这是模型容量——更大的模型会让缺口缩小，论文没测 8B 以上。 **第三方 API 调用不在范围内。** 旅行预订的"确认预订"在生产环境需要调 GDS、CRS、支付网关。地下智能体能不能在保持编译特性的同时集成 tool calling——论文没有直接测试。 **合成训练数据有自噬风险。** 所有训练对话都由 Claude Sonnet 4.5 生成。如果某版 Sonnet 在某个对话路径上犯了系统性错误，这个错误会原封不动地烧进权重。论文用了独立模型（GPT-4.1）做裁判来减轻评分偏误，但生成偏误没有被排除。 **LoRA 失败是实验观察，不是理论证明。** rank 16–128 全败作为"程序性知识非低秩"的证据——是实验结论，可证伪。 --- ### 🦾 退一步：什么该在权重里，什么该在提示词里 这篇论文最根本的贡献，不在"3B 模型能替 Claude"，也不在"8B 模型比编排器强"。 在于最后那句话： **持久的结构属于权重。瞬态的状态属于提示词。** 这是一个原则。不是一个算法。 过去三年，AI Agent 的开发范式里，权重和提示词之间没有这条分界线。一切都在提示词里——流程图、路由规则、当前状态、历史对话——全部塞进一个越来越膨胀的上下文窗口，每轮都让模型从头读一遍。 编排框架做的事情，就是帮工程师把内容分门别类地塞进去——这个节点塞这段、那个节点塞那段、决策枢纽塞一个分类器。你不必自己写塞的逻辑，LangGraph 替你写了。但本质上还是在塞。 地下智能体说：**把"怎么做事"炼进模型。"现在是什么情况"写在提示词。** 你开过一个旅行预订智能体，你的权重已经烧进了基本程序。你需要知道的是"这单预算\)1,100、目的地日本、6 天、水上运动"。

这就像人的大脑：你的脑回路里有"怎么开车"——你不会每天上车之前背一遍交规。但你需要知道"今天导航去机场、第 3 车道、前面有事故"。

编排器是一根拐杖。拐杖用来帮你学走路。走路学会了，它就是减速器。

💭 一颗星星

这件事想了很久。

"把能力编译进权重"——2020 年就有 SimpleTOD。2023 年 FireAct。2024 年 WorkflowLLM 和 Agent Lumos。四篇论文。加起来约 3000 颗 GitHub 星。

编排框架——29 万颗星。

我想到达始终比路线更重要。你有目标（让 Agent 做对事），有一条最快的路径。编排器是最直的那条路：不需要训练、不需要理解模型内部、直接拼积木。积木拼得快，先解决问题。

但地下智能体不是远路。它不是需要更多努力才能到达的更好方案。它是一个在大部分指标上更便宜、更快、质量更高、失败率更低、更容易维护的方案。它只是……需要你迈出第一步——设一个流程图、跑一轮合成数据、做一次微调。

很多人没迈出这一步，因为怕墙太高——怕质量不够、怕成本不合算、怕太僵化。三堵墙。

Dennis 把它们量了一遍——墙是纸做的。

📚 参考文献

1. Dennis, S., Patil, R., Shabahang, K., & Guo, H. (2026). Compiling Agentic Workflows into LLM Weights: Near-Frontier Quality at Two Orders of Magnitude Less Cost. arXiv:2605.22502.

2. Dennis, S., Diamond, M., Patil, R., Shabahang, K., & Guo, H. (2026a). In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks. arXiv preprint.

3. Dennis, S., Shabahang, K., Guo, H., & Patil, R. (2026b). Procedural Knowledge is Not Low-Rank: Why LoRA Fails to Internalize Multi-Step Procedures. arXiv preprint.

4. Hosseini-Asl, E., et al. (2020). A Simple Language Model for Task-Oriented Dialogue. NeurIPS 2020.

5. Yin, D., et al. (2024). Agent Lumos: Unified and Modular Training for Open-Source Language Agents. ACL 2024.

#SubterraneanAgent #AgentCompilation #LLMWorkflow #Orchestration #FineTuning #CostEfficiency #UniversityOfMelbourne #智柴前沿实验室🎙️🚀