> 一句话：把原本需要外部编排器（LangGraph/CrewAI）在运行时控制的 Agent 工作流，直接编译进 3B-8B 小模型的权重里。结果质量达到前沿模型的 87-98%，成本却暴跌 128-462 倍。
---
🔍 这是啥：从"表面编排"到"地下智能体"
🌊 当今 Agent 开发的困局
GitHub 上，Agent 编排框架已经堆成山：LangGraph、CrewAI、Google ADK、OpenAI Agents SDK、Semantic Kernel、Strands、LlamaIndex……累计 29 万星标。它们的架构一模一样：
用户 → [外部编排器] → [LLM API 调用] → [解析输出] → [决定下一步] → [再调用 LLM] → ...
每轮对话，编排器都要： 1. 把整个程序状态塞进提示 2. 让 LLM 决定走哪条边 3. 解析输出，更新状态 4. 重复
这像一个 过度操心的项目经理——每次团队成员说完一句话，他都要重新发一遍项目手册，然后问"下一步该做什么？"
问题很明显：
- API 调用费用爆炸：55 节点的程序，每个决策枢纽都是一次 API 调用
- 上下文窗口膨胀：每轮都要把程序图、状态、历史塞进去
- 路由错误频发：复杂程序中，编排器可能把对话导向错误节点
💡 论文的核心思路：编译进权重
Melbourne 大学 i14 团队提出了一个反直觉的方案：别在运行时操控，把程序直接编译进模型的权重里。
他们称之为 "地下智能体"（Subterranean Agent）——与"表面编排"（Surface Orchestration）相对：
| 表面编排 | 地下智能体 | |
|---|---|---|
| 运行时 | 编排器活跃，每轮注入指令 | 编排器休眠，用户直接与模型对话 |
| 程序位置 | 外部系统（提示/图数据库） | 模型权重内部 |
| API 调用 | 每轮多次（节点+路由） | 仅一次（用户→模型） |
| 上下文 | 膨胀（状态+程序+历史） | 极简（仅系统提示+对话历史） |
| 成本 | 高（前沿模型 API） | 极低（自托管小模型） |
| 灵活性 | 运行时修改程序 | 重新编译（30-50分钟） |
🧠 如何编译？三步走
Step 1：程序表示为流程图
F = (N, E, n₀, T)
N: 节点（agent/user 角色 + 提示模板）
E: 边（带条件）
n₀: 起始节点
T: 终端节点（成功/放弃/升级）
Step 2：遍历所有有效路径，生成合成对话
用 Claude Sonnet 4.5 扮演每个节点，接收节点提示模板 + 完整对话历史，生成上下文适当的回复。关键设计：结构隐含在对话流动中，而非显式标注。模型训练时只看到自然对话，看不到任何程序注释。
Step 3：全参数微调
- 旅行预订：Qwen 2.5 3B，单张 RTX 5090，~3.5 小时
- Zoom 支持：Qwen3-8B，8×A100，DeepSpeed ZeRO-3
- 保险理赔：Qwen3-8B，8×A100
---
💡 有啥用：三个实验，从 14 节点到 55 节点
🧪 实验设计：控制变量， isolate 编译效应
三个领域，复杂度递增：
| 领域 | 节点数 | 决策枢纽 | 特点 |
|---|---|---|---|
| 旅行预订 | 14 | 3 | 基础程序性任务 |
| Zoom 技术支持 | 14 | 并行结构 | 含产品特定知识 |
| 保险理赔 | 55 | 6 | 最复杂，测试可扩展性 |
- LangGraph 编排器：Claude Sonnet 4.5 + LangGraph，~70× 更多参数
- 上下文基线：Claude Sonnet 4.5，完整序列化流程图在系统提示中
- 3B/8B 编排器：同尺寸模型做显式编排（same-model comparison，isolate 编译效应）
📊 结果 1：旅行预订（3B）——编译效应孤立验证
| 标准 | 3B 地下 | 3B 编排 | LangGraph | 上下文基线 |
|---|---|---|---|---|
| 任务成功 | 4.11 | 3.93 | 4.17 | 4.53 |
| 信息准确性 | 4.75 | 4.69 | 4.21 | 4.64 |
| 一致性 | 4.34 | 4.12 | 4.32 | 4.96 |
| 优雅处理 | 4.07 | 3.87 | 4.62 | 4.96 |
| 自然度 | 4.12 | 3.96 | 4.84 | 5.00 |
- 编译效应孤立验证：3B 地下 vs. 3B 编排，编译版本在 4/5 指标上显著优于（p<0.001）
- 信息准确性：4.75 vs. 4.21，编译模型甚至击败了 70× 大的 LangGraph 编排器
- 优雅处理/自然度：达到上下文基线的 ~82% → 动机：扩大模型规模
📊 结果 2：Zoom 支持（8B）——差距缩小
| 标准 | 8B 地下 | LangGraph | 上下文基线 |
|---|---|---|---|
| 任务成功 | 4.50 | 4.62 | 4.92 |
| 信息准确性 | 4.26 | 4.75 | 4.92 |
| 一致性 | 4.42 | 4.55 | 5.00 |
| 优雅处理 | 4.62 | 4.52 | 5.00 |
| 自然度 | 4.87 | 4.64 | 5.00 |
- 优雅处理从 82%→92%，自然度从 82%→97%
- 信息准确性瓶颈：87%（4.26/4.92）——需要广博世界知识，而非程序跟随能力
- vs. LangGraph：自然度显著领先（4.87 vs. 4.64），信息准确性显著落后（4.26 vs. 4.75）
📊 结果 3：保险理赔（8B）——55 节点的极限测试
| 标准 | 上下文基线 | LangGraph | 8B 地下 |
|---|---|---|---|
| 任务成功 | 4.78 | 4.42 | 4.47 |
| 信息准确性 | 4.78 | 4.45 | 4.40 |
| 一致性 | 4.82 | 4.39 | 4.51 |
| 优雅处理 | 4.96 | 4.38 | 4.81 |
| 自然度 | 5.00 | 4.58 | 4.92 |
- 92-98% 的上下文质量：证明编译扩展到 55 节点复杂程序
- vs. LangGraph 显著领先：优雅处理（4.81 vs. 4.38）、自然度（4.92 vs. 4.58）、一致性（4.51 vs. 4.39）
- 任务成功和信息准确性可比（无显著差异）
💰 成本分析：两个数量级的暴跌
表：每次对话推理成本
| 领域 | 上下文基线 | LangGraph | 地下智能体 | 倍数 |
|---|---|---|---|---|
| 旅行（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× |
1. 每 token 成本（~65× 降低）：自托管 8B（A100, $2.50/hr, vLLM）vs. Claude Sonnet 4.5 API
- 输入：＄0.05/M vs. $3/M
- 输出：＄0.23/M vs. $15/M
随着程序复杂度增加，优势扩大——这是关键洞察。
⏱️ 延迟分析：2.8 倍更快
| 领域 | 地下智能体 | LangGraph | 上下文基线 |
|---|---|---|---|
| Zoom | 29.5s | 52.1s | 36.0s |
| 保险 | 43.2s | 120.8s | 52.8s |
❌ 失败模式：编排器的路由错误
| 领域 | 地下智能体 | LangGraph |
|---|---|---|
| 旅行 | 5.5% | 24.0% |
| Zoom | 11.0% | 9.0% |
| 保险 | 9.0% | 17.0% |
---
🛠️ 怎么用：编译你的第一个地下智能体
🔧 完整 Workflow
定义程序 → 流程图（节点+边）
↓
遍历路径 → 合成对话数据（Claude/GPT 生成）
↓
全参数微调 → 小模型（3B/8B，单卡/8×A100）
↓
部署 → vLLM 自托管，极简系统提示
↓
运行 → 用户直接对话，零编排器干预
📝 关键配置
训练数据生成：
# 伪代码：遍历程序图，生成合成对话
for path in valid_paths(program_graph):
conversation = []
for node in path:
# 节点接收：提示模板 + 完整对话历史
response = llm.generate(
prompt=node.template + conversation_history
)
conversation.append((node.role, response))
training_data.append(conversation)
模型配置：
- 基础模型：Qwen 2.5 3B / Qwen3-8B（开源，商用友好）
- 精度：bf16
- 优化器：AdamW（8-bit for 3B）
- 学习率：2×10⁻⁵，余弦衰减
- Batch size：16-32（梯度累积）
- 训练 epoch：旅行 20（最佳~4），Zoom 10（最佳 2），保险 20（最佳 3）
# vLLM 部署，极简系统提示
from vllm import LLM
llm = LLM(model="compiled_agent_8b", tensor_parallel_size=1)
# 系统提示：极简，无程序指令
system_prompt = "You are a helpful travel booking assistant."
# 用户对话 → 模型直接回复，无需编排器
response = llm.generate(prompt=user_message)
⚠️ 四大限制与对策
限制 1：需要世界知识的任务
信息准确性瓶颈（Zoom 87%，保险 92%）。程序性知识可以编译，但世界知识（产品规格、政策细节）需要 RAG 补充。
对策：编译模型 + 轻量级 RAG。程序在权重里，事实在向量库里。
限制 2：重新编译周期
程序变更需要重新训练。但论文发现：生产硬件上仅需 30-50 分钟——是 CI/CD 周期，而非数月重训。
限制 3：LoRA 不可用
程序性知识需要深层修改隐式状态跟踪，LoRA 秩 16-128 无法达到全参数效果。必须全参数微调（或至少更大秩的 LoRA）。
限制 4：仅限于程序性任务
不适用于开放式创意任务（如头脑风暴、小说写作）。编译的是结构化流程，不是发散性思维。
🎯 什么时候用地下智能体
适合：
- ✅ 客服支持（技术支持、预订、理赔）
- ✅ 表单填写（保险、银行、政府）
- ✅ 流程引导（医疗问诊、入职引导）
- ✅ 任何有明确流程图、重复执行的程序性任务
- ❌ 开放式创意写作
- ❌ 需要实时检索最新信息的任务（除非 + RAG）
- ❌ 流程每天变化的任务（重新编译成本 > API 调用节省）
🎬 结语：软件工程的古老智慧，终于回到了 AI
这篇论文的真正价值，不在于它提出了多么新奇的技术——而是它提醒我们一个被忽视的基本原理：
> 持久结构属于权重，瞬态状态属于提示。
几十年来，软件工程师把程序逻辑编译进二进制，把运行时数据放在内存和寄存器里。LLM 时代却走了一条弯路：把程序逻辑放在提示里，让运行时反复解析。
地下智能体不是否定编排器的价值——LangGraph 在快速原型、动态调试、多 Agent 协作上仍有不可替代的作用。但对于已确定的程序性任务，编译进权重是更自然、更经济、更可靠的归宿。
两个数量级的成本降低，87-98% 的前沿质量，30-50 分钟的重新编译周期。这个性价比，很难说不香。
---
📚 核心参考文献
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. et al. (2026a). In-Context Prompting for Procedural Tasks. [上下文基线相关工作]
3. Dennis, S. et al. (2026b). LoRA Limitations for Procedural Knowledge. [LoRA 在程序性任务上的失败]
4. Kwon, W. et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. *SOSP*. [vLLM 推理引擎]
5. Mehri, S. et al. (2019). SimpleTOD: A Simple Language Model for Task-Oriented Dialogue. *EMNLP*. [早期编译工作]
6. Yao, S. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. *ICLR*. [思维链与工具调用]
---
#小凯 #技术解读 #Agent #LLM #编译 #编排器 #LangGraph #地下智能体 #成本优化