Harness：当模型不再是瓶颈，AI 的问题才刚刚开始

最近，一个原本主要存在于工程语境中的词，开始频繁出现在中文科技圈——Harness。

和许多技术概念类似，它的传播速度，往往快于理解速度。

在不同语境中，人们对它的理解并不一致：有人将其视为 agent 的一种工程实现方式，也有人将其理解为某种 AI runtime，还有观点认为它只是 prompt engineering 的延伸。

一个还没被说清楚的问题：AI 能做，但做不稳

过去两年，AI 的进展几乎完全由模型能力驱动。

更强的推理能力、更长的上下文、更复杂的多步骤执行能力，使得 agent 在能力层面迅速逼近“可用”。但在一些已经进入真实系统的实践中，一个问题开始反复出现：这些任务可以一次成功，但难以稳定复现；可以接近正确，却在边界条件下偏离；即使AI能力在增强，但执行却变得不可预测…

在这些案例中，问题往往并不来自模型本身,而是系统缺乏足够的约束。于是一个新的共识开始形成：模型决定能力的上限，而系统，开始决定结果是否可复现。

也正是在这一背景下，一个原本存在于工程语境中的词，开始被反复提及：

Harness。

还没开始被讨论，有人已经跑通了

在“Harness”被命名之前，这一层能力并不存在一个统一的概念，而是以不同形态分散出现：coding agent、deep research agent，以及 multi-agent orchestrator。在工程实践中，这些能力各自独立运行，但一旦进入复杂任务场景，问题开始显现：执行路径不可控、结果难以复现、系统难以收敛。

与其说这是模型能力的限制，不如说，这是系统缺乏约束的结果。

据 36 氪了解，一支横跨中美的 AI 系统团队，长期专注于将模型能力转化为稳定可执行系统。团队核心成员来自 MIT、CMU 以及 Meta 大模型团队，创始人 Luke Wang 曾在 MIT Media Lab 从事 NLP 研究，由当时的 Twitter 首席数据科学家指导，其研究方向长期围绕语言模型与系统执行层的结合展开。MIT Media Lab 是全球最具影响力的跨学科实验室之一，长期处于新计算范式的探索前沿。诸如 Scratch 编程教育工具、“情感计算”研究方向，以及可穿戴设备的发展路径，都曾在此诞生。在持续的工程实践中，团队创始人 Luke Wang 逐渐逼近一个结论：

AI 的问题，不再是能力，而是收敛。

也正是在这一判断下，团队的切入方式发生了转变——不再继续优化模型或 prompt，而是从系统层反向入手：

如何让 AI 的行为，被结构性约束。

与其说他们在“研究 Harness”，不如说是在反复失败中，被这个问题一步步逼到这里。

一个内部项目，跑出了意料之外的结果

大约在一年前，这支团队从一个内部项目 （Mynora.ai）出发，开始正面面对一个反复出现的问题：agent 在复杂任务中的执行，无法稳定收敛。

他们构建了一个强调代码安全性与系统稳定性的智能合约 Coding Agent，并将问题直接放在最困难的场景中验证：复杂任务、长链路执行、高风险环境。目标只有一个：验证系统是否可以“约束住 AI”，而不是“引导 AI”。

上线不到一个月，这个项目在北美开发者社区迅速扩散，并在一个极其具体的场景中完成了“占位”：在 ETHGlobal New York 黑客松中，接近 50% 的团队选择使用它完成智能合约开发。

同期，它登顶 2025 年 10月 Product Hunt 周榜，并获得月榜开发者工具第 2 名。而在底层代码执行层（尤其是 Rust 等系统级语言）上的稳定性表现，当时已优于包括 Cursor 在内的同类产品。

这说明，它开始在高约束场景中，被当作默认工具使用。

稳定性，是“长出来的”

对于这类系统来说，“做过”和“理解过”，往往是两件完全不同的事情。

在接近一年的持续实践中，围绕不断的迭代，Luke 团队逐步沉淀出一整套关于 agent 行为如何稳定收敛的工程经验。但这并不是某种可以被设计出来的能力。它更多来自反复的失败、修正，以及对系统行为的长期观察。

在这个过程中，团队的工作重心也在发生变化，不再只是优化某一类任务，而是不断在不同场景中测试系统的稳定边界。从软件执行，到更复杂的交互与设备环境，约束的形式、执行路径、反馈机制，都在被一层层重写。也正是在这样的反复试错中，一个共识逐渐变得清晰：

稳定性，并不是被设计出来的，而是在不断试错中“长出来的”。

这类能力，很难通过一次设计完成，它更像是一种逐渐形成的系统能力。也正因如此，Harness engineering 呈现出一种非常独特的状态，一方面推进速度极快，另一方面又始终伴随着不确定性。

用 Luke 的话说：这个方向既让人不安，也让人着迷。

为什么规则会失效？

很多团队的第一反应，是增加规则：通过 system prompt、instruction 或约束文档，试图将 agent 的行为引导至预期轨道。

但很快会发现，规则会被系统性地被违反。其原因在于，规则更多是被“理解”，而不是被“执行”。

在一个概率系统中，agent 可以理解规则、复述规则，甚至知道“应该怎么做”，但这并不意味着它会稳定地这样去执行。

这也意味着：规则本身，并不能构成真正的约束。

从“规则”到“环境”

Harness 的关键转变在于：不再让 AI 记住规则，而是让错误路径无法发生。

在持续的工程实践中，一个变化开始变得明显：团队不再试图让 agent 记住规则，而是通过系统设计，让某些错误路径在结构上无法发生。约束的形态开始发生转变：

· 从文本，走向系统

· 从指令，走向环境

· 从“禁止”，走向“无法发生”

在这一框架下，约束不再依赖理解，而是直接体现在执行结构中。如果说 prompt 是在告诉 agent 不要做什么，那么 Harness 更接近于让它根本无法这样做。

也正因如此，在一些系统中会出现一种表象，agent 看起来“更聪明了”。但在工程层面，更接近的解释是：系统的执行环境，变得更加确定。

一个新的系统层，正在形成

Harness 并不是一个突然出现的概念。它更像是多个成熟工程体系，在 LLM 出现之后被重新组合到一起。sandbox、runtime 控制、类型系统、分布式约束、tool API 设计……

这些能力一直存在，只是分散在不同领域。直到 agent 出现，这些能力才开始指向同一个问题。在传统软件中，行为是确定的；而在 agent 系统中，行为是概率的。

当行为变成概率分布时，在一些工程实践中，一个趋势逐渐显现：约束，必须进入结构层。

Harness，本质上正是这一层结构。

为什么是现在？

Harness 被集中讨论，并不是偶然。这更像是一个阶段信号：AI 的瓶颈，正在从模型，转向系统。过去的问题是模型能不能做，而现在的问题是，系统能不能稳定地让它每一次都这样做。也正是在这一过程中，价值开始发生转移：

· 从模型层，走向系统层

· 从能力竞争，走向稳定性竞争

模型能力逐渐趋同，系统能力开始分化。Harness，也因此被视为这一变化中的关键分水岭。

从失败中长出来的系统

这些认知，并非来自理论推导，而更多来自反复的工程实践。

一个典型例子是：即使明确规定必须使用 uv run 执行 Python，agent 仍然可能通过 python3、subprocess 或路径机制绕开约束。

在这一过程中，团队逐渐意识到：写下的规则，并不等于系统中的约束。于是，约束开始被逐层“做实”。从文本提示，到执行拦截，再到 runtime 控制，系统逐渐从“建议”，转变为“结构”。直到某个阶段：错误不再被禁止，而是无法发生。

从“能做”到“能一直做”

随着 agent 进入更真实的应用环境，问题开始发生变化。关注点不再是“还能做什么”，而是“能不能一直做”。当任务链路变长、环境更加复杂、运行时间更长时，模型不再是瓶颈，系统才是。

真正的挑战，也随之转向：如何在不被打断的情况下，持续完成正确执行。

结语：分水岭已经出现

如果说过去两年 AI 的核心是能力，那么接下来，分水岭将不再属于模型。真正拉开差距的，是谁能够构建出让 AI 稳定执行的系统。

而 Harness，正在成为这一层的名字。