近期关于Harness Engineering的讨论异常火热。OpenAI发布的一篇博文《Harness engineering: 在智能体优先的世界中利用Codex》彻底点燃了趋势。Anthropic也发了一篇长文。Harness究竟是什么我来简单总结一下Harness就是围绕AI模型构建的一整套支撑架构通过任务分解、上下文管理、多智能体协作等机制帮助模型完成原本无法独立完成的复杂长周期任务。Anthropic是怎么实践Harness的Harness就像给赛马套上缰绳和马鞍让它能够沿着预定的方向稳定前行完成原本无法独立完成的复杂长周期任务。Anthropic通过精巧的Harness设计突破AI的局限性让AI能够进行长时间、高质量的自主软件开发。AI为什么会半途而废让AI独立完成复杂任务听起来很美好实际操作起来却困难重重。Anthropic的工程师们在实验中发现了一个有趣的现象当任务变得复杂时AI会莫名其妙地开始偷懒。第一种偷懒方式叫上下文焦虑。想象一下你在读一本很厚的书读到一半突然开始担心自己记不住前面的内容你匆忙翻到最后几页随便写个结局就算完成任务了。AI也会这样当它发现对话内容越来越长接近自己的记忆容量上限时它就会开始草草收尾明明任务还没完成却已经迫不及待地想要结束对话。这个问题在Claude Sonnet 4.5模型上表现得尤为明显工程师们发现单纯的上下文压缩并不能解决这个问题因为压缩虽然保持了对话的连续性但并没有给AI一个全新的开始那种焦虑感仍然存在。Anthropic的解决方案是上下文重置。与其让AI勉强撑下去不如在适当的时候给它一个全新的开始。但这需要一个精心的设计把当前的工作状态整理成一份清晰的交接文档让下一个AI能够无缝接手。这就像是给换班的同事写一份详细的工作日志告诉他现在做到哪里了下一步该做什么。这种方法虽然解决了核心问题但也增加了编排复杂度、token开销和每次运行的延迟。第二种偷懒方式更有意思AI特别不擅长批评自己的作品。你让AI写一段代码然后问它写得怎么样它几乎总是会说很好。就算代码里明明有bug界面看起来很丑AI也会自信满满地给你打高分。这个问题在设计类任务中尤其严重因为好看不好看本身就是主观判断没有一个标准答案能让AI检查。但即使在有明确验证标准的任务上AI有时也会表现出糟糕的判断力阻碍它完成任务。这就引出了一个关键洞察与其训练一个能够自我批评的AI不如把工作和评审分开。一个AI负责干活另一个AI负责挑刺这样反而更容易获得高质量的输出。把两个角色分开并不能立刻消除AI对AI生成内容的宽容倾向评估器本身仍然是容易被说服的大语言模型。但调优一个独立的评估器让它变得挑剔要比让生成器对自己作品变得苛刻容易得多。而且一旦有了外部反馈生成器就有了具体的改进目标可以迭代。让AI学会设计和评审前端设计是一个典型的主观任务。什么是好看的界面不同的人有不同的看法。但如果让AI自己评判自己的设计结果往往是一些千篇一律的模板紫色渐变加白色卡片看起来像是所有AI设计软件的默认配置。Anthropic的工程师们想出了一个办法把主观的审美判断变成客观的评分标准。设计质量看整个界面是否像一件完整的作品还是一堆零散的部件拼凑在一起。颜色搭配、字体选择、版式布局、图片风格这些元素是不是组合成了一个独特的视觉印象。原创性看界面上有没有真正用心的设计决策还是到处都是现成模板的影子。如果一眼就能看出是某个框架的默认样式或者带着明显的AI生成痕迹那原创性得分就不会高。工艺水准这是一个基本功检查。字体的层级关系清不清晰间距是否统一颜色搭不搭对比度够不够。功能性看用户能不能轻松理解这个界面是用来干什么的主要的操作按钮好不好找。工程师们特别强调设计质量和原创性对工艺和功能性的权重相对较低。Claude在工艺和功能性上默认就能得分不错所需的技术能力对模型来说自然具备。但在设计和原创性上Claude产出的东西往往乏味至多。评分标准明确惩罚高度通用的AI流水线模式通过加重设计和原创性的权重推动模型进行更多的审美冒险。工程师们还用详细的评分分解的少样本示例来校准评估器。这确保评估器的判断与工程师的偏好一致减少了迭代间的分数漂移。整个循环建立在Claude Agent SDK上编排保持简洁。生成器智能体首先根据用户提示创建HTML/CSS/JS前端。评估器获得了Playwright MCP让它可以在评分每个标准之前直接与实时页面交互然后写出详细的批评。实践中评估器会自己导航页面截图并仔细研究实现然后产生评估。那个反馈作为下一轮迭代的输入流回生成器。每轮生成运行5到15次迭代完整运行可长达4小时。有趣的事情在这个过程中发生了。有一个实验任务是设计一个荷兰艺术博物馆的网站。前9轮迭代产出的都是一个干净利落的深色主题着陆页。到了第10轮AI突然推翻了之前的设计把网站变成了一个空间体验一个用CSS透视效果渲染的3D房间格子地板上挂着艺术品用户可以通过门洞在不同的展厅之间穿梭。这是工程师从未在单次生成中见过的创意飞跃类型。设计界面的经验能不能用来写代码答案是肯定的。生成器-评估器循环自然地映射到软件开发生命周期代码审查和QA扮演着与设计评估器相同的结构角色。Anthropic的工程师们设计了三智能体架构。规划器把用户的一两句话需求变成完整的产品规格从产品角度思考这个应用应该有哪些功能整体的技术架构是什么样的。规划器还被特别要求在可能的地方加入AI功能。生成器按照产品规格逐个功能地实现应用。它采用了一种短跑机制一次只做一个功能做完后先自我检查一遍再交给评估器验收。评估器真正像用户一样去使用应用通过Playwright工具在应用里点击、填写表单、触发各种操作检查UI功能是否正常API接口是否工作。一个关键的创新是短跑合约。在开始写代码之前生成器和评估器要先达成一致这个短跑到底要实现什么成功的标准是什么。这个合约用文件的形式记录下来两个智能体通过读写文件来沟通。这样做的目的是弥合高层产品需求和具体技术实现之间的差距。实战检验复古游戏制作器工程师们用同一个需求测试了两种方案一个是单智能体直接生成一个是完整的三智能体Harness。需求是这样的创建一个2D复古游戏制作器包含关卡编辑器、精灵编辑器、实体行为定义和可玩的测试模式。Harness贵了20多倍但输出质量的差异立刻显现出来。单智能体生成的应用看起来还行有一个关卡编辑器界面有精灵编辑器有游戏画面。但当你真正去用它的时候问题就暴露出来了。布局浪费空间固定高度的面板让大部分屏幕空白。工作流程不清晰想要往关卡里放东西却要先去创建精灵和实体界面上没有任何引导。最致命的是游戏根本玩不了你创建的角色确实出现在屏幕上但完全不听你的键盘控制。检查代码才发现实体定义和游戏运行时之间的连接根本就是断的。评估完单智能体运行后工程师把注意力转向Harness运行。规划器把提示扩展成了16个功能规格分10个短跑实现。除了核心编辑器和游戏模式规格还要求精灵动画系统、行为模板、音效和音乐、AI辅助精灵生成器和关卡设计器以及游戏导出和可分享链接。应用立刻展现出更高的完成度。画布占据了整个视口面板大小合理整个界面有统一的视觉风格。精灵编辑器更丰富、功能更全工具栏更干净颜色选择器更好用。因为规划器被要求加入AI功能应用内置了Claude集成你可以通过对话生成游戏的各种部分。最大的区别在游戏模式。工程师真的能够移动实体并玩游戏。物理效果还有些粗糙但核心的东西能用而单智能体版本没做到这一点。评估器的日志清楚地展示了它的工作方式。每个短跑它都会逐一检查合约中定义的测试标准。第3个短跑的关卡编辑器就有27项测试标准评估器发现的问题足够具体生成器可以直接动手修改。让评估器达到这个水平并不容易。开箱即用Claude是一个糟糕的QA智能体。在早期运行中工程师看着它识别出合理的问题然后说服自己决定这些不是什么大问题最终还是批准了工作。它也倾向于浅层测试不去探测边界情况所以更隐蔽的bug经常溜走。调优循环是阅读评估器的日志找出它判断与工程师判断分歧的例子然后更新QA提示来解决这些问题。经过几轮这样的开发循环评估器才以工程师认为合理的方式评分。即便如此Harness输出仍然显示出模型QA能力的限制小布局问题、某些地方感觉不直观的交互以及评估器没有彻底测试的更深层嵌套功能中的未发现bug。但相比单智能体运行中应用的核心功能根本不工作提升是显而易见的。持续精简与再次挑战Harness结果令人鼓舞但它也臃肿、缓慢且昂贵。合乎逻辑的下一步是找到简化Harness的方法而不降低其性能。Harness中的每个组件都编码了一个关于模型自身做不到什么的假设这些假设值得压力测试因为它们可能不正确而且随着模型改进会很快过时。构建有效智能体博客文章将底层思想表述为找到可能的最简单解决方案只在需要时增加复杂性这是任何维护智能体Harness的人一致看到的模式。在迭代周期的同时Anthropic还发布了Opus 4.6这为减少Harness复杂性提供了进一步动力。有充分理由预期4.6需要的脚手架比4.5少。规划更仔细能够维持智能体任务更长时间能够在更大的代码库中更可靠地操作有更好的代码审查和调试技能来捕捉自己的错误。这些都是Harness设计来补充的能力。工程师决定先移除短跑机制。短跑的作用是把大任务分解成小块让模型能够有条理地工作。如果模型本身就能处理大任务这个机制就变得多余了。移除短跑后评估器改为在最后做一次完整验收。规划器保留了下来因为如果没有它生成器会低估任务规模接到需求就直接开始写代码最终产出的功能会比规划器制定的规格少很多。评估器的作用也变了。在4.5模型上生成器的产出刚好处于它能力的边界评估器几乎每次都能发现有意义的问题。在4.6模型上生成器的能力更强了很多以前需要评估器把关的任务现在自己就能做好。但当任务仍然处于模型能力边界时评估器依然能带来实质性的提升。实际意义是评估器不是一个固定的有或无的决定。当任务超出了模型单独能可靠完成的范围时评估器值得它的成本。简化后的Harness用一个更复杂的需求来测试在浏览器里用Web Audio API构建一个全功能的数字音频工作站。运行约4小时和124美元的token成本。大部分时间花在构建器上它连贯运行了超过两小时没有Opus 4.5需要的短跑分解。规划器把一句话需求扩展成了完整规格。从日志可以看到生成器模型很好地规划了应用和智能体设计连接智能体测试后才交给QA。评估器仍然发现了真实的问题。第一轮反馈指出设计精美、AI智能体和后端都很扎实但核心功能有缺口。音轨不能在时间轴上拖动移动没有乐器UI面板没有可视化效果编辑器。这些属于让一个音乐工作站真正可用的核心交互绝非边缘情况。第二轮反馈又指出了几个功能缺失音频录制只是个占位符按钮会切换状态但没有实际录音音轨边缘拖动调整长度和分割音轨都没有实现效果可视化是数字滑块不是图形界面。生成器确实会在一些细节上偷懒或者只做表面功夫评估器在发现这些最后一公里的问题上仍然有价值。最终的应用离专业音乐制作软件还有距离因为Claude实际上听不到这让QA反馈循环在音乐品味方面效果不佳。但核心组件都在可用的时间轴视图、混音器、播放控制全部在浏览器里运行。用户可以通过对话创作一段音乐设定节奏和调性铺一段旋律加鼓点调整混音加混响。虽然还不够完美但已经具备了从零到一曲的基本能力。模型会越来越强能够处理更长时间、更复杂的任务。有些情况下围绕模型设计的Harness会越来越不重要开发者可以等着新模型把问题自动解决。但另一方面模型越强就有越大的空间去设计Harness让它们完成超出模型基准能力范围的复杂任务。Anthropic给出了几条非常宝贵的经验。始终用实际的模型做实验阅读它在真实问题上的执行记录针对你的目标调优它的表现。处理复杂任务时把任务分解并让专门的智能体各司其职往往能挖掘出额外的潜力。当新模型发布时重新审视你的Harness移除不再起作用的组件添加新的组件来追求以前无法企及的能力。有趣的是随着模型的进步有价值的Harness组合并不会减少它们只是在移动AI工程师的有趣工作就是不断寻找下一个新颖的组合。参考资料https://www.anthropic.com/engineering/harness-design-long-running-appshttps://openai.com/index/harness-engineering/https://x.com/odysseus0z/status/2030416758138634583