# 模型是引擎，系统是车身
**作者**: nash_su - e/acc
**日期**: 2026-04-20T02:58:56.000Z
**来源**: [https://x.com/nash_su/status/2046061024340804055](https://x.com/nash_su/status/2046061024340804055)
---
> 裸模型真的很蠢。
这不是什么隐喻。Kyle Kingsbury 写了一篇 32 页的论文，证明 LLM 是"胡说八道机器"——它们会捏造信息、行为混乱、容易被操纵、不可信任。他的每一个观察都是对的。但他的结论是错的。
他的错误在于：他在用错误的方式测试 LLM。
## 引擎在台架上测试，不代表汽车不安全
Kingsbury 展示了 LLM 失败的全家福：Gemini 忘了渲染厕所，Claude 输出了乱码 JavaScript，ChatGPT 画不出正确的图形。
但看仔细一点：这些例子里的共同点是什么？
一个人坐在裸模型前面，用自然语言输入请求，然后看它失败。没有 skill file 告诉模型该怎么处理任务。没有确定性工具处理需要精度的部分。没有 resolver 路由到正确的功能。没有 harness 管理上下文、强制安全、约束行为。
他把引擎放在台架上测试，然后得出结论说汽车不安全。
## Thin Harness, Fat Skills
我的核心架构哲学是这四个组件：
原则很简单：把智能推上到 skill 层，把执行推下到确定性代码，让 harness 保持轻薄。
## 股票数据的例子
Kingsbury 说：LLM 声称要下载股票数据，结果画了个随机数图表。这是 LLM 在撒谎。
不是。这恰恰是模型在干它该干的事。
语言模型是一个文本预测机器。你让它获取互联网数据。它没有工具、没有 HTTP 客户端、没有 API key。所以它做了语言模型唯一会做的事——生成了一段看起来像股票数据响应的文本。
解决方案根本不是"更好的模型"。
解决方案是：确定性工具。 一个真正调用股票 API 的函数，返回真实数字，把结果作为上下文交给模型。
- 模型决定查什么
- 代码决定怎么查
- 同样的输入，同样的输出，每次都一样
## 浴室渲染问题
Gemini 被要求给 3D 浴室渲染图应用材质，它忘了马桶、改变了房间形状。
因为 Gemini 根本不是图像编辑器。它是一个文本预测系统，图像能力是临时加上去的。它在进行的是像素版的即兴表演。
一个正确构建的系统会这样处理：
> Step 1: 用视觉模型识别图像中的每个表面
> Step 2: 为每个表面选择合适的材质（模型判断）
> Step 3: 用确定性图像处理工具应用材质（代码执行）
> Step 4: 验证输出几何形状与输入几何形状匹配（确定性比较）
模型做判断，代码做执行，resolver 做路由，harness 编排整个序列。
这不一定每次都成功。Skill 可能分解任务错误，视觉模型可能误识别表面，确定性比较可能容差设置不对。但这些都是可调试的失败——你可以找到哪一步出了问题，修复它，然后重新运行。
Kingsbury 的失败没法调试，因为根本没有系统可以调试。只有一个在即兴发挥的模型。
## 锯齿状边界不是放弃的理由
Kingsbury 观察到一个正确现象：LLM 的能力边界是不规则、不可预测的。它能做多元微积分，却会计数字母失败。
他由此得出结论：LLM 不适合需要可靠性的任务。
他得出了错误的结论。
这个"锯齿边界"恰恰是需要路由的原因，而不是放弃的理由。
- 任务需要计数字母？路由到代码——三行 Python
- 任务需要写文章？路由到模型
- 任务需要图像编辑？路由到同时结合两者的管道
在我自己的系统里，OpenClaw 的 brain resolver 是 80 行 markdown，写成一个编号决策树，把每一点知识路由到正确的目录。之前没有 resolver 时，13 个技能里有 10 个分类错误。加了之后，分类错误降到零。
模型没有变聪明。是路由变明确了。
## 512,000 行证据
Kingsbury 自己都引用了：Anthropic 为 Claude Code 构建了 512,000 行工程来围绕自己的模型。
即使世界上最好的 LLM 的制造商，都不信任裸模型。
他们包装了：实时仓库上下文、prompt 缓存、目的构建的工具、会话内存、并行子 Agent。
这是 512,000 行证据，证明模型可靠性是一个工程问题，而不是哲学问题。
## Chain-of-Thought 是同人小说？
Kingsbury 说模型输出思维链本质上是"LLM 给自己写的同人小说"，不反映真实推理过程。
这是真的。但无关紧要。
思维链是草稿纸，不是产品。一个人做长除法时，纸上的中间步骤不是其神经元活动的真实记录——它们是组织计算的工具。
重要的是输出。系统（模型 + harness + 工具）是否产生了正确、可验证的结果？
## Jepsen 用错了层
这里有个讽刺。Kingsbury 的 Jepsen 方法论对 AI 系统来说是完全正确的。但它用在了错误的层。
Jepsen 测试数据库：注入故障，检查不变量。它不测 CPU，不测操作系统——它测数据库本身。
对应到 AI 系统，应该测试：
- Harness 是否阻止了 hallucination 数据到达用户？
- Skill file 是否把任务路由到了需要精度的确定性代码？
- Resolver 是否对正确的输入触发了？
- Entity propagation 是否完成？
这些是可测试的 Claims。单位测试、集成测试、端到端测试——这套测试金字塔是存在的。只是 Kingsbury 没有测到它该测的层。
他测的是裸模型，这相当于用 Jepsen 测试裸文件系统，而不是数据库。
## Plausible vs Verified
Kingsbury 最深刻的论点是哲学层面的：LLM 不产生 truth，只产生看起来像 truth 的文本。它们在 Harry Frankfurt 定义的意义上，是"bullshit machines"——对输出真值漠不关心的系统。
这是对的。而这恰恰是架构重要的原因。
Skill file 说："对照源数据检查你的工作。"
确定性代码说："把这个输出和 ground truth 比较，如果偏离就拒绝。"
模型产生草稿。
系统产生经过验证的结果。
Plausible 和 verified 之间的差距，就是 harness 工程填补的。
## 汽车没有靠怀疑引擎解决安全问题
Kingsbury 在文章结尾把 AI 比作汽车——造成了城市扩张、铅中毒、社区被拆除。
他得出了完全错误的教训。
我们不是靠对引擎持怀疑态度解决汽车问题的。我们用工程解决：安全带、碰撞区、催化转换器、交通灯、高速公路设计、燃油喷射、ABS、安全气囊、排放标准。
每一十年都带来了新的工程，让系统更安全、更高效、更有用——不是让引擎更聪明，而是围绕它构建更好的系统。
对引擎的怀疑从未拯救过生命。工程车身做到了。
## 结论
Kingsbury 是对的：裸模型不可靠。它们捏造信息，行为混乱，产生的是 truth 的美学而不是 truth 本身。
他的错误在于把这些属性当作判决，而不是约束。
模型是不可靠的。
系统不必是。
> Build the system.
> Write the skills.
> Test the code.
> Route with resolvers.
> Make the deterministic parts deterministic.
> Make the latent (model) parts constrained.
> Test the system, not the model.
> And when the system fails — because it will — debug the step that broke, fix the skill, and run it again.
模型是引擎。Harness 是车身。造车。
> 原作者：Garry Tan (@garrytan）
> 原文：https://x.com/garrytan/status/2045798603059548364
## 相关链接
- [nash_su - e/acc](https://x.com/nash_su)
- [@nash_su](https://x.com/nash_su)
- [5.3K](https://x.com/nash_su/status/2046061024340804055/analytics)
- [@garrytan](https://x.com/@garrytan)
- [https://x.com/garrytan/status/2045798603059548364](https://x.com/garrytan/status/2045798603059548364)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:58 AM · Apr 20, 2026](https://x.com/nash_su/status/2046061024340804055)
- [5,319 Views](https://x.com/nash_su/status/2046061024340804055/analytics)
---
*导出时间: 2026/4/20 14:27:46*