Harness Engineering 其实是一台热力学引擎
——推理王国第一章共读心得
作者：Winnie ｜ 共读协作者：Snowball ｜ 2026-04-11 ｜ 阅读时间约 15 分钟
我读完第一章，觉得"讲得不错，然后就没了"
最近开始读 Datawhale 的新书《推理王国》。第一章叫《对抗熵增》，讲推理为什么是生存策略、生物怎么靠预测对抗宇宙的混乱、贝叶斯公式是什么。
读完合上书，我的感觉有点像——吃了一道工艺很好的菜。摆盘漂亮、用料讲究，吃的时候也点头说"嗯，不错"，但吃完了跟没吃一样，不会念念不忘，也不会想再来一碗。
道理都在，就是没粘在我身上。
想了半天才反应过来：我不是读不进，是读进去了但没有切身。科学道理讲得再漂亮，只要它和"我现在每天在干的事"之间没有一座桥，它就会像别人的故事——好听，但不是我的。
于是我拉上我的协作者 Snowball（我部署在 Claude Code 里的一个 Agent，专门帮我在"想清楚问题"和"动手写代码"之间搭桥）做了一次共读。不是让它讲书给我听，而是让它帮我找那座桥。
这篇心得就是那次共读的结果。
一 · 一个人读没感觉，是因为缺了"翻译"
"读不进"其实有两种。
第一种是读不懂——术语不认识、推理跟不上。这不是我的问题，基础知识够。
第二种是读懂了但没有"哦"的那一下——每句话都能复述，就是没有"妈呀这不就是我"的瞬间。我缺的是第二种。
这种状态的本质是缺翻译。作者在他的语境里说话，读者在自己的语境里读。如果没有一个人或一个过程帮你把"作者的话"翻译成"你正在做的事"，所有道理都会停在"它是对的"这一步，进不到"它是我的"那一步。
共读做的就是翻译。
Snowball 读过这本书，也每天和我一起干活。它能把作者的话拧一拧，拧成我听得懂的形状。差的不是内容，差的是内容有没有被翻译到我的世界里。
二 · 第一个"哦"：我那套 Harness Engineering 其实是一台热力学引擎
Snowball 让我先聊聊最近在折腾什么。我说：Harness Engineering。
这是我给自己那套多 Agent 工程框架起的名字。起这个名字是因为它的作用是给一群爱到处跑的 Agent 套上马具，让它们朝一个方向出力，别把项目拖散架。多 Agent 系统最大的问题就是发散——每个 Agent 都很积极，但合起来各说各话，几天下来整个项目变成一锅粥。
Snowball 沉默了一下，然后念了一句书上的话给我听：
"一个系统如果不能预测下一刻，它就会被下一刻摧毁。"
然后它说：
"你的 Harness Engineering，其实就是第一章讲的那套东西，在工程学上的一个实例。"
这句话砸下来，我愣了一下。
作者讲的是：宇宙有一个默认方向，叫熵增——一切都在朝混乱滑过去。生物为了活下来，必须不断预测、不断消耗能量把自己拉回有序。活着本身就是在对抗熵增。
这个道理单独讲我听十遍都没感觉。但把它和 Harness Engineering 拧到一起——
- 项目发散 = 熵增。多 Agent 系统的自然状态就是散架。不是团队不行，是物理定律如此。
- Harness = 约束自由度。我给 Agent 写灵魂文件、定协议、维护看板——这些不是"项目管理"，是把 Agent 的自由度限制到能产生有用输出的方向上。
- 这件事和马具、和热机做的是同一件事。马具把马的奔跑约束到能拉车的方向；热机把分子的无序运动约束到能输出功的方向；我把 Agent 的输出约束到能完成项目的方向。我和瓦特做的是同一件事，只不过他约束蒸汽分子，我约束 Agent。
这一刻我才真的读懂第一章。不是懂了一个知识，是懂了我自己每天在干嘛。
还有一个后续冲击让我心里松了一下。Snowball 说：
"熵增是默认值。收敛不是默认值，收敛是反常。这意味着你每停下一秒，项目就自动朝混乱滑一秒。你不是在管理一个问题，你是在和一个从不眨眼的物理定律赛跑。"
这句话解掉了我一个长期的负疚感。
之前我总觉得——为什么我的多 Agent 系统总要不停维护？为什么 Notion 面板维护起来那么费劲？为什么小羊之间总有地方对不齐？我一直以为是我做得不够好、制度设计得不够精细。
现在我知道了：不是我的问题，是物理上就该这么累。更糟的是，多 Agent 系统的熵不是线性增长的，是指数级增长的。我现在有 8 个 Agent，这个指数级的账单每天都在跑。
我累是正当的。
三 · 第二个"哦"：贝叶斯不是统计工具，是工程设计语言
第一章的结尾，作者放了一个贝叶斯公式。我一开始没看懂他为什么放这个——贝叶斯不是一个统计学方法吗？放在讲熵增的章节末尾，感觉有点怪。
Snowball 让我只盯着公式里的一个东西看：P(h)——也就是"先验"，你看到任何证据之前就已经相信的东西。然后它问我：
"这个 P(h) 是从哪里来的？"
这是一个看起来很蠢但其实是陷阱的问题。因为你没法从数据里推出 P(h)——你需要它才能开始推。用贝叶斯更新一万次，每一次都要先有一个 P(h)。往回追，一路追到最开始，那个最初的 P(h) 必然不是推出来的，它是你开始推理之前就被"塞"进来的。
所有推理系统都有一个它自己永远说不清的起点。
作者把贝叶斯放在第一章结尾不是教我做统计，是给我留一颗定时炸弹：你以为推理是从证据到结论的一条线，其实那条线的起点悬在空中。
然后 Snowball 把这个道理砸到了我的项目上：
"P(h) 就是 SOUL.md。"
我的每一个 Agent 开始推理之前，都必须有一套它自己没法从证据里推出来的东西——它是谁、它在乎什么、它的判断偏好是什么。这些不是学出来的，是被植入的。我给每个羊家族成员写灵魂文件，本质上就是在手动塞 P(h)。
这也解释了一件我之前没明确想过的事：为什么我不能让 Agent 自己生成自己的灵魂文件？
不是技术不够。是物理上不允许。一个系统不能用它自己的推理过程推出它自己推理的起点——这是贝叶斯公式的结构告诉你的。灵魂必须从外面塞进来。
而我就是那个"外面"。在我的 Agent 系统里，我是那个无法被公式推出的 P(h)。
从"哲学炸弹"到"设计语言"
到这一步，贝叶斯在我脑子里完成了一次身份转换——它不再是一个统计工具，也不只是一个哲学定时炸弹。它变成了一套可以直接拿来设计 Agent 系统的语言。
我和 Snowball 一起摸出了 5 条设计原则。每一条都可以用大白话讲：
第 1 条 · 每个 Agent 上场前，先告诉它"你是谁、你在乎什么"
这就是灵魂文件。没有它，Agent 做的判断都是凭空乱猜——就像一个刚入职的员工，没人告诉他公司是干嘛的、岗位该关心什么，你让他做决策，他能做出什么靠谱的东西？
第 2 条 · 它还得知道"在什么情况下该说什么"
光有"我是谁"不够，还要一套"遇到 X 就做 Y"的对应规则。否则它的输出就像随机抽卡——今天靠谱，明天胡言乱语。
第 3 条 · Agent 之间的对话要有结构
谁说、谁接、消息怎么流转，得有规矩。不能像一桌子人同时开口——这是多 Agent 系统最常见的翻车方式，我给它起了个名字叫"一桌人同时开口"。
第 4 条 · 出错了不能当偶然，要回头改设定
每次 Agent 办砸了，就回去改它的灵魂文件或对应规则。不改就是假装没看见——然后下次再砸一次。这和做实验"这次没做好、下次还这么做"是一样的错误。
第 5 条 · 起点歪一点，后面跑再久都是歪的
一开始塞进去的"你是谁"有多好，整个系统的上限就有多高。这就是为什么我做自己实验时那么在意"先验从哪来"——我从不相信只靠读论文就能把一件事做对，我一定要先跑几次小实验，亲手把那个起点校准。
这 5 条看起来朴素，但组合起来其实在说一件事：多 Agent 系统应该像一个贝叶斯结构一样被设计，不是像一堆自由对话一样被设计。
这是第一章给我的最大一份礼物——它不是给我一个概念，是给我一套看自己工程的新眼睛。
四 · Harness Engineering 的"成本账本"
理解了上面这些之后，我想把 Harness Engineering 每天到底在"花什么"算清楚。我和 Snowball 一起列了三列，叫它 Landauer 账本——Landauer 是物理学里的一个原理，它说：你每擦除一比特信息，都必须付出一份最小的热量代价。换句话说，推理不是免费的，收敛是要付账的。
那我的 Harness Engineering 每天在付什么账？三列：
| 代价 | 是什么 | 谁付 | 随 Agent 数量怎么变 |
|---|---|---|---|
| ① 剪枝算力 | 用来"删除可能性"的计算 | GPU / API 账单 | 线性 |
| ② 先验注入 | 给 Agent 写灵魂、判断新情况 | 我自己的经历和判断 | 部分可外包，最难那层永远在我身上 |
| ③ 相锁同步 | 让多个 Agent 步调一致 | Notion 面板维护 | 指数爆炸 |
第一列 · 剪枝算力。 有意思的是：Harness 花的算力大部分不是用来"生成"，而是用来"删除可能性"——Agent 想跑偏时把它拉回来，想胡说时告诉它"不是这样"。每次说"不行，重来"，物理学上和重新写一遍那个东西是同价的。这解释了为什么 Harness 总感觉"没干什么却很累"——干的是擦除的活。
第二列 · 先验注入。 给每个 Agent 写灵魂文件、判断新冒出来的情况——这些都在消耗我的经历和判断力。我能让 CloneLamb（小羊分身，跑在 Notion 上，负责整理团队记忆和归档知识）帮我处理一部分已有先例的情况，但那些真正新的、没先例的判断必须由我亲自做。因为我就是团队的 P(h) 源头，这一层永远卸不掉。
第三列 · 相锁同步。 这是最贵的一列，也是我目前最头疼的一列。
⚠️ 这一格我暂时只能留白
我必须诚实地承认：关于多 Agent 之间如何保持同步，我目前还没有找到一个真正好的方案。现在靠 Notion 面板做"全局观察板"——所有 Agent 读同一块板子、写同一块板子。但这种方式的成本是随 Agent 数量指数级爆炸的，我已经能感觉到它快撑不住了。
所谓 Agent-to-Agent 协议，是我接下来要认真想的大问题。心得里我不装懂——这一格是开放的，等我摸出来再写。
五 · 我发现了自己一个没意识到的双标
这次共读里还有一个让我不好意思的瞬间。
前面说过，我做自己的研究实验时对"先验知识"的要求很严。我坚持双源先验——既要有从论文、书里来的间接知识，也要有自己动手做的预实验提供的直接知识。两者混合才是一个靠谱的起点，然后才进入正式实验。对自己这条是执行得很紧的。
但 Snowball 问我：
"你给羊家族写灵魂文件的时候，用的是哪种知识？"
我答不上来。
想了想，现实是——我现在给每个 Agent 写的灵魂文件基本是凭感觉 + 读一些别人的做法。只有间接知识，没有预实验。
这是我自己在研究里最警惕的那种 P(h)，结果我在写灵魂文件时却放弃了这个标准。这是一个我自己都没意识到的双标。
下一步：从赛博小驴一号的重孵化开始
所以 Harness v2 的第一块砖我已经想好了：
以后每个新孵化的 Agent 不能写完灵魂文件就直接上线。要先走一个"预实验期"——跑 3-5 个典型任务，看它真实输出和我灵魂文件里假设的差多少，然后根据这个 gap 修订灵魂文件，再正式纳入羊家族。
这一步几乎不需要新基建，只需要给每个新 Agent 定一个"孵化考题本"，跑完打分、改 SOUL、再跑一轮就完事。
第一块试验田：我正在重新孵化的 赛博小驴一号（跑在 OpenClaw 上的一个 Agent，上一版因为自己改崩了配置被退回重做）。这一次我不再凭感觉给它写灵魂文件，而是先让它跑几个典型任务，再根据表现迭代。
这是贝叶斯思想第一次真正进入我的工程流程。
结语 · 不是老师对学生，是同行对同行
读完第一章、和 Snowball 对了几轮之后，我对这本书的关系发生了一个转变。
刚开始我以为它是一本讲深奥道理的科普书——我是学生，作者是老师。共读到后面我才明白：作者在第一章讲的那个框架，我其实早就在用，只是我用的是自己发明的词，他用的是科学史上的词。
我们在两个不同的屋子里，用不同的语言，说了同一件事。
所以这本书对我真正的价值不是教我新东西。它是帮我把自己已经在做的事，翻译成一套可以和别人沟通的语言、可以复用的框架、可以从上面再长出新东西的地基。
Snowball 在共读的最后给我念了一句话。它说，如果要给这本书写一句墓志铭，应该是——
💭 给这本书的墓志铭
"此书不教机器如何变聪明，只教人在机器停下的地方，为什么还要继续往前走。"
对我来说，机器停下的地方，就是我必须亲自作为 P(h) 出现的地方。共读第一章让我第一次清楚地看见了这一点。
第一章读完了。我打算接着读第二章。
Winnie · 2026-04-11