模型会的越来越多，Harness 还剩什么？

假设一个编程模型经常改完文件就宣布完成，我们便在外面加一条流程：修改之后必须运行检查，失败就把错误送回去继续修。系统的表现因此好了很多。后来，模型经过新的训练，自己就会检查、追错和重试。原来的流程还在，但它承担的工作已经变了。理解 Harness 工程，需要把模型的这种变化一起放进来。

Harness 可以理解为围绕模型搭建的工作系统。它把任务、上下文、工具和执行环境接起来，让一次次模型调用共同推进一件事。这个范围里既有启动进程、保存文件这样的运行工作，也有安排步骤、提醒检查、提供经验这样的行为引导。两类工作经常写在同一个框架里，随着模型成长，却会有很不一样的去向。

能力缺口有了可以反复推进的解决过程

模型能力的进步，越来越能够围绕具体目标来组织。需要它熟悉一个领域，就准备相应的材料；需要它掌握一套做法，就收集优秀示范；需要它在复杂任务里做出更好的选择，就构建能够执行、反馈和评估的环境。开发者开始掌握一套培养能力的方法，今天的短板也就成为下一轮可以着手改进的对象。

外部系统在这里很有价值。模型暂时不会安排检查顺序，可以由流程先安排；不熟悉某类问题，可以由人提供经验、工具或操作示范。在这些帮助下，系统能够完成过去做不好的任务，也产生了更好的过程记录：当时看到了什么，为什么采取这个动作，环境又返回了什么。原本只存在于人的经验或框架里的做法，开始有了可以学习的样本。

把这些轨迹筛选、整理后用于训练，模型就有机会学会其中的做法。SWE-Gym把代码仓库、可运行环境、测试与任务放在一起，用来训练软件工程智能体，也公开了智能体轨迹。这里很有意思的关系是：运行环境既帮助系统完成眼前工作，也为后来的模型改进提供材料。更好的工作条件，可以参与制造更好的模型。

产品使用又能让这个过程继续转动。失败暴露出新的任务和条件，归因帮助找到该修改的地方，人和系统一起把更好的路径做出来；这些路径进入训练，新模型再去面对更大的任务范围。外部能力、工作轨迹和模型能力由此连成一个循环。Harness 在循环里承担的是持续建设下一步工作条件的任务，它的内容会跟着能力边界移动。

下面把“先定位、再修改、最后检查”这套做法分成三个阶段。切换时，观察谁负责决定步骤，以及哪些设施始终留在外部。中间阶段很常见：模型已经能完成大部分工作，只需要一份按需读取的经验。能力的迁移可以一点点发生。

先把 Harness 里两种不同的责任分开

如果把所有东西都叫“框架”，我们很快会争论：模型变强之后，框架到底该更厚还是更薄？这两个答案可以同时成立。模型原本不会独立做事，需要大量行为引导；模型后来能连续工作数小时，却会对状态恢复、资源隔离和任务调度提出更高要求。代码的增减掩盖了职责的迁移。把它们分成运行设施与能力支持，才能看清究竟是什么在变。

运行设施负责让工作真实发生，并遵守系统约定。 一次模型调用只是其中一个环节。接受任务、保存状态、派发工具、等待结果、恢复执行、回收资源，都需要有人实际完成；访问哪些文件、使用谁的权限、什么结果才允许交付，也需要明确的执行位置。即使模型每次都作出正确判断，这些责任仍然存在。

可以把这部分的范围列得更具体一些：

能力支持负责让当前模型更有条件完成当前工作。 它补的是任务要求与模型表现之间的缺口：模型不熟悉的业务，通过资料补上；不稳定的判断，通过案例和流程帮助；反复需要的精确操作，交给现成工具。它也会安排上下文，让需要的材料在合适的时候出现。这里关注的是怎样做得更好，因此必须随着任务和模型变化重新评价。

能力支持也有几个容易辨认的落点：

这两张表描述的是职责，不能直接拿来按文件夹分家。一个工具同时有两面：它提供的曲线对齐算法是在补能力，调用它时的权限检查和资源回收属于运行设施。上下文压缩也一样：什么时候接近输入上限、把原始记录存到哪里，可以由系统管理；怎样概括才不丢关键状态，则包含模型可学习的判断。真正值得拆开的，是那些会独立变化的决定。

同一个检查步骤，为什么可能留下，也可能消失？

回到开头的编程任务。早期模型常常不检查，我们便强制在每次修改后运行测试。这段代码首先是在代替模型作决定。后来模型已经会根据改动选合适的检查，原来的强制流程反而可能让它对一次文案修改启动整套昂贵验证。此时减少提醒，是把已经学会的判断还给模型；我们省下的是照顾某种短板的工作。

但如果团队规定所有发布都必须通过同一组验收，检查就代表了一个外部承诺。模型即使判断“这次肯定没问题”，也不能替这个承诺作废。执行器仍要检查发布的实际版本与验收结果是否对应。前一种检查关心模型会不会做事，后一种关心系统有没有履行约定。两者在早期可能共用一段实现，模型进步后才显出不同去向。

一个很实际的判断办法是做两次替换：换成一个始终会选对步骤的模型，这个环节还需要吗？换成另一个用户或组织，这个环节的要求会变吗？ 前一个问题帮助找出弥补能力的部分，后一个问题帮助看见权限、业务规则和组织承诺。再进一步，可以在评测中移除某条提醒，观察成功率、成本和失败类型怎样变化。它是否仍然有用，应当由当前表现回答。

这种变化已经能在具体工程里看到。Anthropic 在 Managed Agents 的架构说明中提到，为旧模型安排的上下文重置，在换到更强模型后失去了原来的作用；它们因此把会话记录、Harness 和沙箱分成可以分别替换的部分。这个例子有意思的地方，在于稳定的是接口承诺，内部引导策略则可以跟着模型继续改变。

边界移动，工程仍然向前走

能力支持也不会整齐地全部消失。当前设备的维护记录、某家公司的工作习惯、刚刚改变的用户偏好，本来就适合在任务发生时提供；一个精确可靠的程序，即使模型会重写它，也仍值得复用。训练更适合吸收跨任务反复有用的理解与做法，外部系统则继续保存新事实、局部约定和可执行能力。所谓“下沉”，是重新分工，而不是追求最后只剩一个裸模型。

这就是我理解 Harness 工程时最看重的背景：培养能力正在成为一套可以持续推进的方法。我们先为一个领域建立工作条件，用外部支持把好的做法做出来，再让训练吸收其中能迁移的部分。运行设施承接更大的工作规模，能力支持继续向尚未解决的问题移动。设计 Harness 时，要同时看清今天的责任和明天可能发生的迁移，才不会把一个暂时的补丁误认成智能体永恒的结构。