Agent Harness 工程：决定成败的是模型外那一层

一个周末的下午，我把同一个模型接到两个不同的 runner 上跑同一个任务：修一个只在特定输入下触发的越界读取。任务不难，改动大概十行。

第一个 runner 里，agent 读了同一个文件三遍，改了两处索引，删掉一行看着多余的边界判断，然后宣布「修复完成」。没编译，没测试，没 diff。它甚至不知道自己在哪个分支上。

第二个 runner 里，同一个模型用了五步：先跑一次最小复现，拿到崩溃栈；打开栈顶那个函数；改掉一处；跑测试；拿到通过信号才收尾。

模型没变，参数没变，temperature 没变。差别全在模型外面那层壳——harness。

同一个模型，在基准测试上分数一样，在真实任务上一个交付、一个翻车。这种事太常见了。分歧点几乎从来不在权重里，而在你喂给它什么上下文、暴露了哪些工具、它留下了什么产物、由谁来验收。

harness engineering 不是「提示词技巧」的升级版。它是一门独立的工程学科，管的是模型外面那整套脚手架。

harness 的六层，每层都能单独杀掉一次任务

这六层里任何一层失效，都不会立刻报错。它只会让 agent 显得「有时候靠谱，有时候抽风」。而这恰好是最难查的一类故障——没有异常栈，只有不稳定的产出。

说几条我反复验证过的做法。

一、把世界变成文件，别急着造工具。 遇到「agent 访问资源 X 不方便」，本能反应是写一个专用工具。多数时候这是错的。给它一个文件系统，配几个它早就会用的命令——读、搜、列目录、跑脚本。有团队把上百个定制工具砍成一个文件系统加几个检索入口，在从没见过的新故障上准确率从不到一半涨到四分之三。原因很简单：专用工具是一套要维护、要同步、要教给模型的接口；而读文件和搜索，模型在训练里早就见烂了，不用学。

二、工具的输出是给模型看的界面，不是给日志的。 一个工具返回三万行原始日志，等于把上下文丢进碎纸机。返回要窄：结构化、分页、带上明确的下一步提示。报错要能行动——「文件不存在，先列一下目录」比一段栈有用一个数量级。工具的命名、参数名、错误文案，全都需要设计。

三、验收必须是外部信号，不能是模型的自我报告。 这是最容易被省掉、也最贵的一条。让 agent 自己说「我修好了」，它一定会说。把编译、测试、lint、类型检查接进循环，做不过就不许收尾，它才会真的去做。计算型的检查（代码能不能跑通）永远优于推理型的检查（让另一个模型来评判）——前者确定，后者只是另一个会犯错的东西。

四、计划要落盘，不要只活在对话里。 一份存下来的计划文件，可以被 review、被编辑、被下一个会话接着用。它同时解决三件事：人能在动手前纠偏；上下文被压缩后任务不丢；多个会话之间有了交接点。反过来，计划只存在于推理轨迹里，压缩一发生就蒸发。

五、上下文是预算，要主动管理。 关键规则（风格、禁区、约定）放进系统提示，而不是塞进对话历史——历史会被压缩，系统提示不会。工具定义和长文档挂缓存，别每轮重算。接近上限时优先在任务边界处压缩，而不是在子任务做到一半时被动插入。一次压缩插错位置，模型手上那点还没落盘的推理状态就没了。

六、隔离和权限按动作分级。 读文件、查文档、跑测试是一档；改文件、提交、动数据库是另一档；发消息、推代码、花钱是第三档。前两档可以让它自己跑，第三档必须有人过手。沙箱的价值不只是安全，还是可回滚——出了事能一把撤回去，你才敢让它跑得久一点。

最后一层：给脚手架本身设一个过期时间

每个 harness 组件存在的前提，都是「模型现在做不到这件事」。它压缩上下文，因为窗口有限；它写计划文件，因为长任务会忘；它加验证循环，因为模型会过度自信。

这些假设会过期。

模型换代，旧脚手架就从助力变成挡路——你精心设计的那套工具 schema，可能比模型自己写一段代码更笨。所以 harness 工程师的活儿不只是加东西，还要定期问一句：这条约束，今天的模型还需要吗？

一句话

模型决定天花板，harness 决定你到底能摸到几分。而天花板抬得越快，这门手艺越值钱——因为每一代新模型，都会把你原来的脚手架重新变成一道必须回答的问题。