LLM 可靠性是工程问题，而非终审判决

# 想象一下，如果裸体的人更愚蠢。事实证明，"裸模型"确实如此。

抱歉，这里说的不是那种裸体模特。但你此刻感受到的失落？那正是 Kyle Kingsbury 对大语言模型（LLM）的感受。

Kyle Kingsbury 是当今最优秀的系统工程师之一。他的 Jepsen 项目花了十年时间，系统性地证明了分布式数据库并未如宣传所言那般运作——CockroachDB、MongoDB、Redis 以及数十个其他系统，都做出了它们无法兑现的一致性承诺。他发布了研究结果，厂商修复了漏洞，整个行业因此变得更加诚实。Jepsen 是应用怀疑主义的杰作。(https://jepsen.io/)

上周，他发表了一篇长达 32 页的文章，题为《一切的未来都是谎言，我猜：关于扯淡机器的废话》。这篇文章文笔优美、研究深入、读来令人忍俊不禁，却在最重要的问题上得出了错误的结论。(https://aphyr.com/data/posts/411/the-future-of-everything-is-lies.pdf)

他的观察是正确的，但他的结论并非如此。

关于范围的说明：本文针对的是 Kingsbury 的技术论断——即 LLM 是不可靠的扯淡机器，无法产出值得信赖的输出。他对劳动力替代、信息生态和文化影响的更广泛忧虑，是真实存在的独立议题，各自都值得单独撰文探讨。我在此不加讨论，并非对其的否定，而是专注于架构问题：模型的不可靠性究竟让有用的系统成为不可能，还是让它成为一个工程问题？我认为是后者。Kingsbury 的文章假设是前者。这正是我们分歧所在。

## 在台架上测试发动机

Kingsbury 的文章以一份 LLM 失败案例目录的形式展开。他让 Gemini 将材质应用于一个 3D 浴室渲染图，结果它忘记了马桶，还改变了房间的形状。他让 Claude 进行图像到图像的转换，结果生成了数千行 JavaScript 代码，产生了一堆毫无意义的乱码多边形。他让 ChatGPT 在蓝色衬衫上添加白色补丁，结果它改变了颜色、移动了补丁，最后又把它们删掉了。他还目睹一位同事的 LLM 声称下载了股票数据，却生成了一张由随机数构成的图表。

这些失败案例，每一个都是真实的。我见过类似的失败。每一个使用 LLM 进行构建的人都经历过。Kingsbury 并没有捏造任何东西。

但请看这些案例中发生了什么：一个人坐在原始语言模型面前，用自然语言输入请求，然后看着它失败。

没有告诉模型如何处理任务的技能文件，没有处理需要精确性的部分的确定性工具，没有将请求路由到正确能力的解析器，也没有管理上下文、执行安全规则或约束行为的框架。

他是在台架上测试发动机，然后得出汽车不安全的结论。

## 架构问题

为尚未阅读本系列第一篇文章的读者解释几个术语。技能文件（skill file）是一种可复用的 Markdown 文档，用于教导模型如何处理某项任务——它是一套流程，而非一个提示词。解析器（resolver）是一张路由表，告诉模型针对哪项任务应读取哪份文档。确定性代码（deterministic code）是每次都能产生相同输出的软件——SQL 查询、API 调用、数学计算——这些是模型永远不应触碰的部分。框架（harness）是一个轻量级的协调器，在循环中运行模型、读取文件并管理上下文。合在一起就是：轻框架，重技能。(https://x.com/garrytan/status/2042925773300908103)

Kingsbury的核心论点是，LLM是"废话机器"。它们会胡编乱造，行为混乱，容易被操控，根本不可信。他得出这个结论的方式，是将模型孤立地进行测试，就像测试一个函数那样：输入进去，输出出来，然后评估输出结果。

遇到Kingsbury所描述的那些问题的人，恰恰是这样做的：直接与裸模型对话，却期待得到可靠的输出。而没有遇到这些问题的人，则搭建了框架（harness）。这并不是因为框架能让模型变得可信，而是因为框架能让整个系统变得可信——即使其内部的模型并不可信。

顺带一提，Kingsbury其实知道框架的存在。他引用了Claude Code的源代码泄露事件：Anthropic围绕自家模型构建了51.2万行工程代码。就连世界上最优秀的LLM的制造者，也不信任裸奔的模型。他们用实时代码库上下文、提示缓存、专用工具、会话记忆和并行子智能体将其层层包裹。这51.2万行代码本身就是证据，证明模型可靠性是一个工程问题，而非哲学问题。

但我想坦诚地承认一点：51.2万行代码并不简单。我即将描述的这套模式——技能（skills）、解析器（resolvers）、确定性代码、测试——在概念上是清晰的，但稳健的实现是真正的工程挑战。框架会失效，技能会编码错误的流程，验证层的质量也只取决于它所检查的不变式是否正确。我的主张并不是框架能让一切变得简单，而是框架能将模型的不可靠性，从一个"停下来的理由"转变为一个"待解决的问题"。这一区别至关重要。

股票数据的例子是最清晰的说明。一个LLM声称下载了股价并生成了图表，但数据是随机的。Kingsbury将此作为LLM会撒谎的证据。但实际发生了什么？有人让一个语言模型（一台文本预测机器）从互联网上获取数据，而它根本无法从互联网获取数据——它没有工具，没有HTTP客户端，也没有API密钥。于是它做了语言模型会做的事：生成了一段看起来像股票数据响应的文本。

解决方法不是换一个更好的模型，而是一个确定性工具：一个真正调用股票API、返回真实数字、并将其作为上下文传递给模型的函数。模型永远不会碰数据获取这件事——它决定查什么，代码决定怎么查。相同输入，相同输出，每次如此。

这正是我在《薄框架，厚技能》中描述的架构：将智能向上推入技能层，将执行向下推入确定性代码层，保持框架轻薄。这样做之后，Kingsbury所描述的那类失败就会变得极不可能发生——不是因为模型变聪明了，而是因为我们从一开始就没有要求模型去做它做不到的事。并非所有失败都会消失，但失败模式会从"模型幻觉了"转变为"技能写错了"或"工具有Bug"——而这些都是可调试、可测试、可修复的问题。这就是混沌与工程之间的区别。(https://x.com/garrytan/status/2042925773300908103)

## 浴室问题

以Kingsbury的浴室例子为证。他让Gemini（一个语言模型）将材质应用到一个3D渲染图上。Gemini不是图像编辑器，也不是3D建模工具，它是一个以附加功能形式获得了图像处理能力的文本预测系统。它忘记画马桶，当然；它改变了房间的形状，当然——它不过是在用像素即兴发挥而已。

一个经过适当封装的系统会以不同的方式处理这个问题。技能文件会规定：将任务分解为步骤。

- 步骤 1：识别图像中的每个表面（使用视觉模型）

- 步骤 2：针对每个表面，选择合适的材质（隐性判断——由模型决定）

- 步骤 3：使用确定性图像处理工具应用材质（代码——Pillow、OpenCV 或 Blender 脚本）

- 步骤 4：验证输出几何形状与输入几何形状是否匹配（确定性比较）

模型负责判断。代码负责执行。解析器在两者之间路由。封装层编排整个流程。

这是否总会奏效？不。技能文件可能会错误地分解任务。视觉模型可能会误识别表面。确定性比较可能使用了错误的容差。这些都是真实存在的失败模式，我每一种都遇到过。但它们是可调试的失败模式——你可以找到出错的那一步，修复它，然后重新运行。Kingsbury 的失败无法调试，因为根本没有系统可供调试。有的只是一个即兴发挥的模型。

## 参差不齐不等于残缺

Kingsbury 最精彩的观察之一是"参差不齐的技术前沿"——即大语言模型的能力边界不规则、难以预测。它们能做多变量微积分，却在简单的文字题上栽跟头。它们能写文章，却数不清字母的个数。（https://www.hbs.edu/ris/Publication%20Files/24-013_d9b45b68-9e74-42d6-a1c6-c72fb70c7571.pdf）

这个观察是正确且重要的。但 Kingsbury 得出了错误的结论。他认为参差不齐的前沿使大语言模型不适合需要可靠性的任务。这个现象实际上意味着的是：你需要路由。

解析器是上下文的路由表。当出现 X 类型的任务时，加载技能 Y。当任务需要数字母时，路由到代码——一个三行的 Python 函数。当任务需要写文章时，路由到模型。当任务需要图像编辑时，路由到一个将两者结合的流水线。

参差不齐的前沿是支持封装工程的论据，而非反对 AI 的理由。不规则性是真实存在的。解决方案就是绕过它进行路由！你必须在模型薄弱之处使用确定性代码，在代码无法推理之处使用模型判断。解析器负责绘制这片领域的地图。

在我自己的系统中，我将 OpenClaw 的大脑解析器设计为 80 行 Markdown，以编号决策树的形式将每条知识路由到正确的目录。在没有它之前，技能会自行做出归档决策，13 个中有 10 个是错的。加入它之后，归档错误降至零。模型并没有变得更聪明。是路由变得明确了。（https://x.com/garrytan/status/2044479509874020852）

## 混乱是约束存在的理由

Kingsbury 认为大语言模型是混沌系统。它们对输入的微小扰动敏感，易受对抗性操控，行为难以预测。他说得对。换一种方式提问会改变答案。重新排列句子会改变输出。不可见的 Unicode 字符可以劫持行为。

他将此呈现为一个根本性问题。确实如此！——如果你是在将原始的、非结构化的输入直接喂给一个裸模型的话。

但如果你通过技能文件对输入加以约束，情况就未必如此了。

技能文件是一种结构化的 Markdown 文档，定义了操作流程。它告诉模型该读取什么、该考虑什么、该输出何种格式，以及该遵守哪些约束。模型接收的输入并非"修复这张图片"——而是一份长达 200 行的文档，其内容是：这是任务，这是流程，这是优质输出的样子，这些是你拥有的工具，这些是你没有的工具，如果你不确定该怎么办。

通过技能文件进行结构化输入，远比自由形式的自然语言混乱程度低得多。技能文件约束了路径的走向。它不能消除混沌（在随机系统中没有什么能做到这一点），但它能引导混沌，就像河堤引导河流一样。Kingsbury 说得没错，没有河堤的河流会泛滥。但这并不是反对河流存在的理由。这是主张修建河堤的理由。

## 推理能力：一个转移注意力的论点

Kingsbury 就"推理"模型提出了一个颇为巧妙的观点。他指出，思维链追踪（模型在"思考"时输出的意识流文本）"本质上是大语言模型在为自己写同人小说"。他引用了 Anthropic 的研究发现：Claude 的思维链追踪并不能可靠地反映其实际推理过程。（https://www.anthropic.com/research/reasoning-models-dont-say-think）

这一点是真实的，但无关紧要。思维链追踪是草稿纸，而非最终产品。当人类进行长除法运算时，纸上的中间步骤并不是其神经元活动的忠实记录——它们是组织运算过程的工具。没有人会用草稿的工整程度来评价一位数学家。

重要的是输出结果。这个系统（模型加上框架加上工具）能否产出正确、可验证的结果？这才是可检验的问题。Kingsbury 并没有对此进行测试，因为他根本没有构建这个系统。

他评估的是草稿纸，而非答案本身。

## 我们同样不知道阿司匹林为何有效

在文章接近结尾处，Kingsbury 写道："我们并不真正了解 Transformer 模型为何如此成功，也不知道如何让它们变得更好。"这是事实。同样是事实的还有：阿司匹林的作用机制直到 20 世纪 70 年代才被完全理解；全身麻醉至今仍未被完全理解；自行车的稳定性原理亦是如此——陀螺理论被证明是错误的，直到 2011 年才得到确切解释。

实际效用并不需要理论的完备性。工程实践可以在研究持续推进的同时向前推进——这一直以来都是如此。

我们没有等到 1971 年的作用机制论文发表后才停止开阿司匹林处方。我们也没有因为争论机翼究竟为何能产生升力而让飞机停飞。问题不在于我们是否理解其机制。问题在于：我们能否利用现有能力构建可靠的系统，对其进行严格测试，并随着理解的深入不断加以改进？Kingsbury 隐含地假定，理解不完整就意味着我们无法构建。而整个工程史都在说明恰恰相反。

## Jepsen 实际上会发现什么

这里有一个讽刺之处。Kingsbury 的 Jepsen 方法论恰恰是评估 AI 系统的正确方式。只是它被应用到了错误的层面。

Jepsen 通过注入故障并检验不变量来测试数据库。它不测试 CPU，不测试操作系统，它测试的是数据库本身——在压力下的完整系统，对照其自身所声称的特性。当 CockroachDB 声称具备线性一致性时，Jepsen 注入了网络分区，并检验该声明是否成立。

将相同的方法论应用于AI系统，测试目标就显而易见了。不要测试模型是否会产生幻觉！它当然会。测试的应该是系统是否会产生幻觉：

- 执行框架是否能阻止幻觉数据抵达用户？

- 技能文件是否在需要精确性的地方将任务路由至确定性代码？

- 解析器是否对正确的输入触发？

- 实体传播是否完整？

这些都是可测试的主张。我们测试它们。

- 确定性代码的单元测试。

- 流水线正确性的集成测试。

- 用于路由准确性的解析器触发评估。（https://x.com/garrytan/status/2044479509874020852）

- 用于输出质量的LLM评审评估。

- 完整流水线的端到端测试。

智能体系统的测试金字塔是存在的。只是Kingsbury测试的不是这个。他测试的是原始模型，就好比对裸文件系统而非数据库运行Jepsen。

## 真相的美学

让我来回应Kingsbury最深层的论点——那个大多数读者即便无法清晰表达也会有所感知的论点。大语言模型产出的不是真相，而是看起来像真相的文字。是真相陈述的美学外观，却缺乏认识论根基。用哈里·法兰克福在哲学意义上的定义来说，它们是"胡说机器"：对自身输出的真值漠然置之的系统。

这是对的。而这恰恰是架构如此重要的原因。

裸模型产出的是貌似可信的文字。有执行框架的系统产出的是经过验证的文字。

1. 技能文件说："对照源数据核查你的工作。"

1. 确定性代码说："将此输出与基准事实对比，若有偏差则拒绝。"

1. 模型生成草稿。

1. 系统生成经验证的结果。

1. 貌似可信与经过验证之间的差距，正是框架工程所填补的差距。

但Kingsbury完全忽略了这一点：验证的质量取决于技能文件的质量。而技能文件由人来编写——创始人、开发者或提示词编写者。

这正是开源如此重要的原因。闭源智能体永远无法让你编写验证其输出的技能，因为法律主义和安全主义阻碍了真正验证所需的深度定制。你需要能够说："这是我的模式，这是我的不变量，这是在我的领域中正确的样子，现在对照这些进行验证。"而通过一个保护其系统提示的API，你做不到这一点。

认识论问题是真实存在的。解决方案是开放式执行框架，由用户掌控验证层。靠的不是信任，而是工程。

这正是我的YC合伙人兼好友Pete Koomen在《AI无马马车》中所谈到的。用户必须自己编写提示词，否则我们将沦为一个无从窥见的系统提示的奴隶。（https://koomen.dev/essays/horseless-carriages/）

## 汽车

在文章结尾，Kingsbury将AI比作汽车。他请读者思考的不是汽车有多快，而是汽车对城市做了什么。他的答案？无序蔓延、铅中毒、被夷平的社区、对汽车的依赖。这是个好比喻。

但他从中得出了完全错误的教训。我们解决汽车问题，靠的不是对发动机持怀疑态度。我们靠的是工程学：安全带、溃缩区、催化转化器、交通信号灯、高速公路设计、燃油喷射、ABS防抱死系统、安全气囊、排放标准。每十年都有新的工程技术让这套系统变得更安全、更高效、更实用——不是通过让发动机变得更聪明，而是通过在它周围构建更好的系统。

对发动机的怀疑从未救过任何人。救人的是对底盘的工程设计。

这就是对Kingsbury那篇文章的回答。不是"要小心"，不是"这些机器是骗子"。

答案是：

- 构建系统。
- 编写技能。
- 测试代码。
- 通过解析器进行路由。
- 让确定性的部分保持确定性。
- 让潜在的（模型）部分受到约束。
- 测试系统，而非模型。
- 当系统失败时——因为它终将失败——调试出问题的那一步，修复技能，然后重新运行。

Kingsbury说得对，裸模型是不可靠的。他说得对，它们会产生幻觉，它们是混沌的，它们产生的是真相的外表而非真相本身。他错在哪里？他把这些属性当作了终审判决，而非设计约束。模型是不可靠的。系统不必如此。

模型是发动机。框架是汽车。去造那辆车吧。

——

我将本系列中描述的架构开源了。GBrain是知识层，让你构建自己的个人OpenClaw/Hermes智能体，替你完成工作。GStack是技能层，助你与Claude Code快速协作。(https://github.com/garrytan/gbrain) (https://github.com/garrytan/gstack)