Harness工程本质：给大模型构建操作系统

一、一个反直觉的结论：瓶颈往往不在模型

提到Agent效果不佳，多数开发者的第一反应是“模型不够聪明”，于是把希望寄托在下一代更强模型上。然而，行业里一系列控制变量实验给出了相反的结论：在模型权重、提示词、评测任务完全不变的前提下，仅仅调整外层工具的交互格式，就能让任务通过率出现数量级的变化。

其中最具代表性的一组公开对照实验是这样设计的：实验对象为某款代码生成模型，全程不改动模型权重、提示词和评测任务，唯一的变量是文件编辑工具的交互格式。当工具采用传统的差分补丁格式时，代码任务通过率仅为6.7%；更换为基于行定位标记的编辑格式后，同一模型在同一批任务上的通过率直接升至68.3%，相差整整十倍。

这并非孤例。多家技术团队都发布过同类测试：固定同一款模型，只优化工具调用协议、上下文管理策略和执行循环逻辑，基准分数普遍能提升十几个到三十多个百分点。这种优化收益在许多场景下甚至超过一次模型版本迭代，也印证了行业内的一个共识：模型能力的上限，很大程度上由外层Harness决定。

二、十倍差距从何而来：机械性失误，而非智力短板

要理解这个差距，需要先看传统差分补丁格式对模型输出的苛刻要求。所谓差分补丁，就是要求模型输出一段精确描述“删哪几行、加哪几行”的文本，工具侧再据此改写文件。示意如下：

--- a/src/utils.py
+++ b/src/utils.py
@@ -12,2 +12,2 @@
 def format_name(user):
-    return user.first + " " + user.last
+    return f"{user.first} {user.last}"

这种格式隐含了一个假设：模型输出的每一行上下文、每一个空格、每一层缩进，都必须与目标文件完全一致。只要有一处对不上，补丁就无法应用，整个操作直接失败。

问题在于，模型是逐token生成文本的，上下文行、行号、空白字符这类信息本就是它最容易出错的地方。于是出现了一种非常典型的失败模式：模型对问题的分析完全正确，修复逻辑也写得无误，仅仅因为补丁中一处缩进或空格不匹配，工具执行报错，任务被判失败。换句话说，模型“想对了、写对了”，却败给了格式校验。

改用行定位标记的编辑格式后，情况发生了质变。模型只需给出“在哪个文件、哪几行附近、替换成什么内容”这类相对粗粒度的指令，文件的精确定位、文本匹配、实际写入、冲突处理等机械性工作全部交给Harness底层完成。文本校验被弱化，模型从“逐字节复述文件内容”中解放出来，失误率自然大幅下降。

这个实验揭示的规律可以概括为一句话：很多被误认为“模型能力不足”的问题，本质上是“接口设计与模型输出特性不匹配”的问题。 把机械性、校验性的工作从模型侧转移到工具侧，是Harness工程最核心的设计思想之一。

三、Harness Engineering的定义：给模型建操作系统

Harness Engineering的本质，是为AI构建“工作环境”的工程化方法论。它不训练模型、不改动模型参数，而是围绕模型搭建一整套让它能稳定发挥的运行时支撑体系。

先记住这个公式：

Agent = Model + Harness

我们日常看到的智能体，从来不是裸模型，而是“模型 + 外层工程体系”的复合体。Harness覆盖的范围相当广，主要包括：

1. 系统提示词与上下文管理：定义角色、规则与任务边界，决定哪些信息进入上下文窗口、以何种顺序呈现、何时裁剪压缩；
2. 工具调用接口：设计工具的参数结构、校验规则与返回格式，让模型的“动手能力”有稳定出口；
3. 文件系统与工作区：为模型提供可读写的项目环境，并与真实生产数据隔离；
4. 沙箱隔离：限制代码执行的权限与资源边界，保证安全可控；
5. 执行编排：负责任务分解、循环调度、并行执行、子任务管理等流程控制；
6. 反馈回路：把执行结果、报错信息结构化后回传给模型，支撑自我修正；
7. 错误拦截与兜底：捕获格式错误、超时、死循环等异常，避免单点失败拖垮整个任务；
8. 状态管理：维护长任务的进度、记忆与断点，让跨轮次、跨会话的工作得以延续。

模型只负责推理和生成，其余全部由Harness承接。一个设计良好的Harness执行循环，通常长这样：

while not task.done:
    action = model.decide(task, harness.observations())
    result = harness.execute(action)      # 工具调用、文件读写、命令执行
    if result.failed:
        result = harness.normalize(result)  # 转成结构化错误，而非原始报错
        harness.inject_feedback(result)     # 回传模型，触发自我修正
    harness.record(task, action, result)    # 状态与上下文维护

四、CPU与操作系统：一个足够准确的类比

理解Harness最直观的方式，是把模型类比为CPU，把Harness类比为操作系统。

CPU再强，如果操作系统天天崩溃、驱动不兼容、内存泄漏，用户体验也好不到哪去——顶配旗舰芯片装上一个不稳定的系统，实际表现可能还不如旧芯片配一套成熟稳定的系统。反过来，一块普通的芯片，配上调度合理、生态完善的操作系统，也能流畅支撑绝大多数日常任务。

大模型同样如此。模型参数量决定的是“推理与生成”这一单点能力的上限，而任务最终能否高质量完成，取决于整条链路：指令如何传达、工具如何调用、错误如何恢复、上下文如何保持。这些恰恰全是Harness的职责。这也解释了为什么Harness优化带来的收益，经常超过模型本身的升级。

五、构建高质量Harness的实践要点

结合上述原理，工程实践中有几条被反复验证的原则值得遵循：

1. 接口设计宁可窄而稳，不要宽而脆。 工具参数越自由、格式校验越严格，模型踩坑的概率越高。把参数结构设计得简单明确，把容错逻辑做在工具侧，是降低失败率的第一原则。

2. 失败必须可恢复。 任何一次工具调用失败，都不应该意味着任务终止。错误信息要结构化——告诉模型“错在哪、为什么错、可以怎么改”，而不是抛出一段原始异常文本。

3. 机械性工作尽量下沉到工具侧。 行号定位、文件匹配、格式转换、依赖检查这类确定性任务，能由代码完成就不要指望模型逐字输出。模型擅长决策与生成，不擅长扮演精确的文本复制器。

4. 上下文是稀缺资源，要主动治理。 无关信息会稀释模型对关键任务的注意力。该裁剪的裁剪、该摘要的摘要、该外置到文件或存储的状态就外置，保持上下文“少而相关”。

5. 评测驱动迭代。 Harness的每项改动——换一个工具格式、调一次上下文策略——都应通过固定的任务集验证收益，用数据而不是直觉驱动优化。

六、结语：解决“稳定干活”，而非“够不够聪明”

回到最初的问题：Harness Engineering解决的是什么问题？它解决的不是“模型够不够聪明”，而是“模型能不能稳定、高质量地干活”。

前者是模型研发侧的问题，后者是工程侧的问题。对绝大多数构建AI应用的开发者和企业来说，短期内更换更强模型带来的收益，往往不如把Harness这层“操作系统”打磨扎实。先让现有模型在一个设计良好的工作环境里充分释放能力，再谈模型升级，是更务实、回报也更确定的路径。