模型越来越强,为什么大家却开始重写 Harness
太长不看版 如果把《跟Cloudflare大佬学用 Claude Code》《Skills 详解》《深度拆解 Clawdbot(OpenClaw)架构与实现》放在一起看,会发现它们其实都在补模型外面的系统层 Harness 可以粗略理解成"把模型接进真实工作流的控制系统",里面不只有工具,还有状态、约束、反馈和验收 它现在变重要,原因很直接:模型一旦开始真正动手,系统层问题暴露得比能力问题更快 具体做法会随着模型迭代不断变化,但知识沉淀、硬约束、反馈回路、完成标准这些问题不会自己消失 如果现在准备补 Harness,我会更建议先补统一知识入口、硬约束和验证闭环,再谈多 Agent 和复杂编排 先别把 Harness 当成一层"壳" 很多人第一次听到 Harness,会本能地把它理解成"模型外面那层包装"。这个理解不算错,但也不够。 如果只是为了做一个短对话应用,你确实可以把它理解成包装层。一个聊天窗口,加一个消息循环,再加几个工具,差不多也能跑起来。但一旦任务开始变长,事情就不是"包一层"这么简单了。 模型自己不会保存状态,不会主动维护工作目录,不会判断某次输出是不是已经满足了系统约束,也不会天然知道什么时候该停、什么时候该继续、什么时候该回滚。它当然也不会自己给自己搭测试环境,更不会在写完之后自觉打开浏览器、点一遍页面、看一眼日志,再决定这次提交到底能不能合并。 所以我现在更愿意把 Harness 理解成另一种东西:它不是给模型套上的外壳,而是把模型接进工程世界的那层控制系统。 这里面通常包括几类东西: 状态怎么保存 工具怎么暴露 权限怎么约束 输出怎么验证 上下文怎么管理 任务怎么续跑 什么叫"真的完成了" 把这几样拆开看,你会发现它们并不花哨,甚至很多都不新鲜。文件系统、测试、日志、浏览器、Lint、计划文件、审批机制,这些原本就是软件工程里再普通不过的东西。 但一旦主角从人类工程师换成模型,它们突然重新变成了核心。 因为模型最擅长的是生成,最不擅长的是在约束里稳定收敛。 为什么它偏偏现在火了 如果把时间往前拨两年,你会发现那时候大家最关心的是 Prompt Engineering。核心问题是:怎么把一句话说清楚,让模型按你的意思回答。 后来上下文变长了,任务变复杂了,大家开始聊 Context Engineering。问题也跟着变了,不再是"这一句怎么写",而是"什么信息应该放进来,什么不该放进来"。 再往后走,就到了今天这个阶段。 Prompt Engineering 和 Context Engineering 当然没有过时。更准确地说,它们被包进了一个更大的问题里。 现在更让人头疼的问题变了:模型能理解需求,但在一个复杂系统里,它能不能把事情从头到尾做稳? 这也是为什么最近围绕 Harness 的材料,明显都带着一种很强的"实战味"。 Mitchell Hashimoto 提出 Engineer the Harness,出发点很具体:每当 Agent 犯了一个错误,就别只盯着这次对话修修补补,把修复方式沉淀进系统,让它下次别再犯 OpenAI 的 Codex 团队讲得更直接。他们从零开始跑出一个大规模代码库之后,最后得出的重点,落在三件事上:仓库怎么成为统一知识入口,架构边界怎么机械执行,PR 怎么通过 Lint 和测试去卡住错误方向 Anthropic 的材料也很典型。里面有一个很朴素的发现,我一直记得:模型并不擅长评价自己的工作 这句话看起来平淡,其实分量很重。因为它把很多人真实碰到的问题说穿了。页面看起来像是做完了,交互其实没通。功能大体对了,边界条件一跑就露馅。代码能过一部分测试,但系统层面已经悄悄偏离了原本的设计。 ...