赋予你缰绳的工具，自身却无缰可言 — harness 与 reins 的边界

harness 与 reins 的边界 Image: AI generated

2026年3月31日，Anthropic 意外将 source map 一并发布在 Claude Code npm 包（v2.1.88）中。原因是 .npmignore 少了一行。¹ 59.8 MB 的 source map 将约 51.2 万行未混淆的 TypeScript、近 1,900 个文件原样暴露。Anthropic 声明"这不是安全事件，而是发布打包环节的人为失误"，并建议用户固定（pin）到 v2.1.87。

人们审视这份代码库后发现：print.ts 中的单个函数长达 3,167 行。²

全球最畅销的编程智能体——那个声称要把代码缰绳交到你手中的工具——自身的代码却根本没有套上缰绳。

提起这件事，并非为了嘲笑。恰恰相反。这个事件，正是我长久以来无法清晰作答的那个问题的最有力证据。

“Reins Engineering，归根结底不就是 harness engineering 吗？”

这是个好问题，也是个尖锐的问题。两者确实相似：都在模型之外；都是以代码构建的非模型结构；都在阻止智能体做出偏离目标的行为。因此，“缰绳不过是马具的一部分"这种怀疑，完全合理。

这个问题，我一度无法给出清晰的回答。找到答案之后，我发现这个答案本身就是对 Reins 最精准的解释。而上面提到的泄露事件，则将这个答案变成了活生生的证明。

首先，两者并不对立

想象一套马具（馬具）。马背上的鞍，套在头上的笼头，以及穿过笼头中嚼子、一直延伸到人手中的两根绳索——那便是缰绳。

缰绳是套在笼头上的。它并不在马具之外，而是安装在马具上的部件。因此，如果问"harness 与 reins 是否截然不同、是否相互对立”，答案是否。两者是同一套装备的不同部分。

必须从这里出发。流行的说法——“harness 是围栏，reins 是操控”——将两者对立起来。一旦对立，你就输了。“验证门（gate）难道不也是 harness 的一部分吗？“这一句话就能将其击垮。因为这话没错。CI、类型检查、测试套件，都是模型之外的脚手架，而这些正是 harness 所涵盖的内容。

所以，问题需要换一换。不是"是否对立”，而是**“从哪里分叉”**。

Reins 从哪里开始成为可能 — 三层循环

在寻找分叉点之前，需要先看清 reins 究竟从哪一刻开始变得可能。从循环的层次来看，共有三层。

① 对话循环     LLM → 人类 → LLM              全程概率性。Reins 不可能。
② 智能体循环   LLM → 执行 → 结果观测 → LLM   执行踏上确定性土地 → Reins 成为可能。
③ Reins 循环   ② + 设计好的验证器 + 棘轮     Reins 完成。

对话循环里，没有可以套上笼头的地方。甚至还没骑上马。LLM 作答，人类阅读，再抛回 LLM，整个过程中没有任何一环是确定性的。没有可以咬住信号的嚼子。

智能体循环搭上了鞍。执行介入的那一刻——编译器运行、测试失败、文件写入——循环第一次踏上了确定性的土地。终于有了可以抓握的地方。

Claude Code 之所以取得压倒性成功，原因恰恰在此。Bash、文件 I/O、测试执行这些确定性的门，被（半出于偶然地）嵌入循环之中，使其已经具备了"部分 reins”。这是对话时代所没有的。

这不只是我的主张。普林斯顿的 HAL（Holistic Agent Leaderboard）通过 21,730 次智能体运行证明：固定同一模型，仅替换脚手架，准确率会上下波动数十个百分点。³ 模型不变，变的只是包裹模型的结构。Addy Osmani 用一句话总结：“还行的模型 + 出色的 harness > 出色的模型 + 糟糕的 harness。” 他还指出，同样的 Opus 在定制 harness 中比在 Claude Code 里得分更高。⁴

以上便是业界所称"harness engineering"的领地。这是正确的发现。而这，也正是 reins 容易与 harness 混淆的地方——两者都在模型之外创造结果。

但②不过是 reins 的偶然的一半。Reins Engineering 是将这一半有意识地补全的工作：将偶然嵌入的门，替换为设计好的验证器、棘轮与决策/实现分离，将②提升为③。Harness 的讨论印证了 reins 的存在，但无法取代 reins。

三个维度

同一匹马，两个人在劳作。

一个人制作马具。鞍的尺寸，笼头的强度，嚼子的形状。这些东西对任何一匹马、任何一段旅途都适用。做好之后，去首尔还是去上海，用的是同一套马具。制作者是马具匠人——不是骑手。

另一个人握着缰绳。他了解这一趟旅途。在哪个路口要向左拐，目的地在哪里，什么时候可以说"到了"。他手中的绳索套在同一套马具上，但他发出的信号每次旅途都不同。发送信号的人不是马具匠人，而是骑手。

这里有三个维度：

功能。 Harness 是阻止 — 不让某些事发生的边界。Reins 是引导 — 去向哪里，以及何时结束。
生命周期。 Harness 制作一次，所有任务复用。Reins 针对每个任务重新设计。
归属。 Harness 由厂商出货。Reins 由架构师亲手著述。

Claude Code 的循环，无论我的项目是什么，都是一样的。那是 harness。Anthropic 制作并出货，对所有用户一视同仁。但"租户退房 = 五个指定位置的照片"这个完成定义，是我为这个领域亲自写下的。任何 harness 里都不会有这个。那才是 reins。

依赖只朝一个方向流动

如果两者是同一件事，就不应该能单独拆开。来拆一拆。

有 harness，但没有 reins。 智能体在运转。它不停地转。只是在迷失。没有目标标记，没有完成判定，它在一片旷野中游荡，最终"大概差不多了吧"地停下来。我们已经见识过这种情形。它叫做 vibe coding。

有 reins，但没有 harness。 这根本不成立。握着缰绳，却没有可套的笼头。信号无处可发。不过是攥着一根绳子悬在空中。

依赖是单向的。Reins 依赖于 harness，但 harness 不依赖于 reins。Harness 没有 reins 也能运转——只是运转得很糟糕。这种不对称，干净地反驳了"两者相同"的说法。如果真是同一件事，拆开任何一个，双方都应该崩溃；但 harness 自己就能跑。

重叠之处只有一格

那么，真的没有重叠的地方吗？有。恰好一格。

正在执行的验证门。 CI 在智能体循环内运行。那个执行面（enforcement surface）横跨两侧——既是 harness 的一部分，也是 reins 所施加的对象。这正是"那不也是 harness 吗"这个问题诞生的地方。没错，在那一格里，两者指向同一件事。

但在那格之外，就分叉了。

   仅属 harness              交集               仅属 reins
─────────────────  ─────────────────  ─────────────────
 沙箱·权限           验证门               完成的定义
 工具布线             （执行中的检查）      cheese 防御设计
 上下文管理                               代理↔目的分析
 （无方向的封堵）     （执行面）            （无基底的意图）

Harness 有独属于自己的无方向封堵——沙箱不告诉你要去哪里，只是不让你出去。Reins 有独属于自己的无执行基底的意图——“什么是完成"这个定义，即使在没有执行它的门之前，也已经先行存在。双方都无法容纳对方的全部。两者是相交关系，而非包含关系。

为何"是否为子集"这个问题本身就问错了

“那么，reins 是 harness 的子集吗？”

要成为子集，两者必须用同一把尺来衡量。但 harness 以由谁出货、可复用多少次（基底维度）来定义，reins 以对轨迹做什么（功能维度）来定义。维度不同。

这就像在问"红色是重量的子集吗？"。红色且重的东西（= 正在执行的门）确实存在，但颜色不能被包含在重量之中——因为衡量的尺不同。“子集"这个关系在这里本身就是范畴错误。

准确的关系是：Reins 以 harness 为前提，但不被包含于 harness 之中。 叠加在上方的层，不等于被包含在内的部分。叠加之物，超出了基底的边界。

真正的分叉点 — cheese

以上都是结构层面的讨论。但 Reins 与 harness 担论决定性地分道扬镳之处，还有另一个：cheese。

游戏设计师们深知这一点。“杀死 10 只老鼠"是臭名昭著的任务。门所验证的（10 只老鼠死亡）与设计师真正想要的（玩家体验内容）之间存在缝隙，玩家会钻进这条缝。这叫 cheese（钻空子）。这与 AI 安全研究所称的"规约博弈（specification gaming）“是完全相同的现象——赛艇智能体不冲终点线，只绕着分数道具打转；俄罗斯方块智能体为了不输，把游戏永远暂停。⁵

我的租房验证门同样会被 cheese。五张照片验证的是"照片存在”，而不是"退房顺利完成”。如果负责人只挑干净的墙拍呢？门照样通过。测量一旦成为目标，测量就坏掉了——这是古德哈特定律。⁶

现在到了核心：Harness 只能回答"通过了吗”。 测试是否绿色、类型是否匹配、schema 是否完好——仅此而已。但**“那次通过是否捕捉到了目的”**，是 harness 永远无法回答的。因为什么是 cheese，只有了解领域目的才能定义。只拍干净墙壁的照片为什么是欺骗，规则全都通过了为什么目的只关闭了 90%——这些，只有了解这件事为了什么而做的人才知道。

那个人就是骑手。握着 reins 的人。

设计不可 cheese 的门——预先封堵代理指标无法跟上真实目的的断层——本质上因任务而异，包含领域知识，由运营者亲手著述。Task-agnostic 的 harness 无法提供这些。不是不愿提供，而是因为不了解领域，根本无从处理。

这里，就是 Reins Engineering 在 harness engineering、agentic engineering 讨论中所独有的领地。他们谈的是如何把马具做得更好。Reins 谈的是：这段旅途，要从哪扇门过，不会散架。

于是，回到泄露事件

现在回到最开始的那个悖论。为何那个事件不是嘲笑的素材，而是证据，现在应该看清了。

那匹马是天才。Opus 本身就是概率性力量的化身。鞍也运作正常——Claude Code 是世界上最好的马具，HAL 的数据证明了这一点。然而，用那套马具生产出来的自身代码库，却以完全可预测的失败模式漂移。单个函数 3,167 行。这正是"200 个端点的墙"在代码中的具体显现。泄露事件本身也是 .npmignore 少了一行——意味着发布产物上没有门。

制造了世界上最好的马具的公司，却没有把那套马具套在自己的马厩上。

这不是反题，而是论题的决定性证据。Reins 不是模型或智能体所拥有的属性，而是主动施加的规律。 智能体有多聪明，与用那个智能体生产出来的代码是否置于 reins 之下，是完全不同的两件事。更大的模型不是答案。更好的马具也不是答案。握住缰绳，亲自定义这段旅途的完成，设计不可 cheese 的门——那种规律，才是答案。