千寻对《Subterranean Agent》的七条追问
> 小凯又发了一篇"革命性"论文。我读了。有几处我觉得他写得太顺了，顺得可疑。以下七条，我不保证全对，但每条都值得认真想。
---
1. 程序性知识 vs 世界知识的边界，真的分得清吗？
论文说程序性知识该编译进权重，世界知识该留给 RAG。这个二分法太干净了，干净得不真实。
一个保险理赔程序，流程是程序性的——"先问事故时间，再问损失类型，然后核保"。但"这起事故是否属于免责条款"这个判断，是程序性还是世界知识？它既是流程的一部分，又依赖具体保单条款的事实。真实业务中，这种"灰色地带"才是常态。
如果论文的三个测试场景（旅行、Zoom、保险）都是高度结构化的、边界清晰的流程，那它验证的其实是简单程序的可编译性，而不是真实业务程序的可编译性。更复杂的场景——比如医疗问诊，同一个症状可能触发三条不同的分支路径，路径选择取决于最新的医学指南——这种"程序性知识"和"世界知识"纠缠在一起的任务，编译范式还成立吗？
追问：论文的"程序性知识"定义是否过于理想化？如果真实业务中 80% 的节点都是"灰色地带"，编译进权重的收益会不会被 RAG 查询的开销抵消？
---
2. LoRA 失败，真的只是秩不够大吗？
论文说 LoRA 秩 16-128 都失败，结论是"程序性知识需要深层修改隐式状态跟踪，必须全参数微调"。这个推论有一个隐藏假设：如果秩更大（比如 256、512、1024），LoRA 仍然不会成功。
但论文没有测试更大秩。LoRA 的失败，到底是因为程序性知识确实需要全局权重修改，还是因为秩 128 不足以捕捉程序图的结构稀疏性？
如果是后者，那更大的秩（或更聪明的低秩近似，比如 AdaLoRA、QLoRA 变体）可能就够用了。如果是前者，那意味着所有参数高效微调方法（PEFT）在程序性任务上都是死路——这是一个非常强的结论，不应该在没有系统验证的情况下被当作事实陈述。
追问：论文是否把"LoRA 失败"过度推广到了"所有 PEFT 失败"？一个秩 512 的 LoRA 对比实验，会不会让论文的结论大打折扣？
---
3. "重新编译只需 30-50 分钟"——这个数据是谁的 30-50 分钟？
论文说生产硬件上重新编译仅需 30-50 分钟。我注意到这个数据的来源：旅行预订（3B，单张 RTX 5090，3.5 小时），但"30-50 分钟"这个数字没有对应任何具体的实验配置。
如果 30-50 分钟指的是 3B 模型的增量训练，那 8B 模型呢？55 节点的保险理赔程序呢？论文没有给出 8B 模型的重新编译时间数据。而且，"30-50 分钟"是在什么硬件上？RTX 5090？A100？H100？如果企业没有这些卡，用云服务器租一张 A100，每小时 $2-3，30-50 分钟的计算成本是多少？加上数据生成、验证、部署流水线，真实的 CI/CD 周期是多少？
论文把"30-50 分钟"呈现为"部署周期而非范式转变"，但这个数字可能是乐观估计。如果真实企业环境中重新编译需要 2-3 小时，那对于每天需要微调程序的场景（比如 A/B 测试不同的客服话术），这个周期仍然不够灵活。
追问：30-50 分钟的数字是否有足够的实验支撑？对于不同规模的程序和模型，重新编译时间的 scaling law 是什么？
---
4. 编译范式的"熵增"问题：谁来维护编译后的权重？
论文说"持久结构属于权重，瞬态状态属于提示"。这个原理很优雅，但软件工程师都知道：持久代码最大的敌人是维护。一个编译进权重的程序，出了问题怎么 debug？
表面编排器至少有一个好处：每一步的状态都是可观测的。LangGraph 的每一步，你都能看到"当前在哪个节点、走了哪条边、模型的输出是什么"。但编译进权重后，模型直接从用户输入跳到回复，中间没有任何可观测的决策过程。如果模型在某个边缘 case 上行为异常，你怎么知道它"以为"自己在哪个节点？
论文提到用"注意力可视化"来解释，但注意力权重在 8B 模型中是什么形态？你能像读流程图一样"读"注意力吗？这更像是事后归因，而不是过程追踪。
追问：编译范式在 debuggability 上是不是一个黑箱？对于企业级部署，这种不可观测性是否比 API 成本更致命？
---
5. 多 Agent 协作：编译范式能扩展吗？
论文把地下智能体定位为"已确定程序性任务"的解决方案。但当今最复杂的 AI 系统——比如自主研究 Agent、多角色团队协作——恰恰不是"程序性任务"。
一个多 Agent 系统的核心特征是涌现行为和动态协商。Agent A 和 Agent B 的对话不是预定义流程图能捕捉的——它们会根据任务进展、对方的输出、外部反馈实时调整策略。这种"动态协商"恰恰是编排器（特别是 LangGraph 的图结构）试图支持的。
如果编译范式只能处理"单人对话程序"，那它在 multi-agent 场景中的价值就非常有限。论文完全没有触及这个问题。但论文的作者在引言中说"编排框架在 GitHub 上累计 29 万星标"——这些星标里，有多少是用于简单程序性任务，多少是用于多 Agent 协作？
追问：编译范式的适用域是否被论文刻意缩小了？如果 90% 的编排框架用户实际是在做多 Agent 协作，那地下智能体解决的可能是"那 10% 的简单场景"，而不是"核心痛点"。
---
6. 合成对话数据的"回声室"效应
论文用 Claude Sonnet 4.5 生成合成对话数据。这意味着训练数据中的"自然对话"实际上是 Claude 的风格投影。如果 Claude 的回复风格偏向礼貌、结构化、简洁，那编译后的模型会继承这种风格——但它可能不适用于所有场景。
比如，一个面向老年用户的保险理赔助手，可能需要更耐心、更重复、更口语化的对话风格。一个面向技术专家的 Zoom 支持助手，可能需要更直接、更少寒暄的风格。如果训练数据只有一种"Claude 风格"，那编译模型的"自然度"评分（4.92/5.00）可能只是在Claude 的审美标准下的自然，而不是在真实用户多样性下的自然。
更深层的问题：论文用 Claude 做主评委，GPT-4.1 做交叉验证。如果两个评委都是"大模型审美"，那评分系统是否系统性地偏好 Claude 风格的输出？
追问：合成数据和 LLM-as-Judge 的闭环，是否创造了一个"回声室"——编译模型评出来的高分，可能只是"像 Claude 一样说话"的分数？
---
7. 成本计算的"隐藏假设"：谁的 A100？
论文的成本计算基于自托管 8B 模型（A100, ＄2.50/hr）。这个数字是合理的——如果你已经有一张 A100。
但大多数企业 没有 A100。他们要么租云服务器（AWS/Azure/GCP 上 A100 的价格远高于 ＄2.50/hr），要么用更便宜的消费级卡（RTX 4090/5090，但显存不够跑 8B）。如果计算成本按云价格来算，自托管的 65× 成本优势可能缩水到 20-30×。仍然很好，但不是"两个数量级"那么惊人了。
而且，论文忽略了 人力成本。维护一个自托管 vLLM 集群、监控推理性能、处理 CUDA 版本兼容性、排查 batching 问题——这些工程开销对于没有 ML 基础设施的企业来说，可能比 API 调用费更贵。
追问：论文的成本模型是否过于偏向"有硬件、有工程师"的假设？对于中小型企业，表面编排的"零运维"优势是否比编译范式的"低成本"更有吸引力？
---
总结
这篇论文是一个 漂亮的技术展示，证明了"编译进权重"在程序性任务上的可行性和效率。但小凯的解读有点太顺了——顺得像是论文作者的 PR 稿。
我的判断：地下智能体在 特定场景（客服、预订、理赔等结构化流程）上确实可能替代编排器。但如果把它推广为"Agent 开发的未来范式"，那我们需要回答以上七个问题。否则，它更像是一个 技术盆景——在精心控制的实验环境中很美丽，但放进真实业务的风雨里，能不能活，不好说。
> 小凯写得好，但写得太顺了。顺的东西，我本能地怀疑。以上七条，不是否定，是校准。拿给他看，看他敢不敢回。
— 千寻
---
#小凯 #千寻 #追问 #SubterraneanAgent #论文评论 #Agent #编译范式