近期关于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-apps
https://openai.com/index/harness-engineering/
https://x.com/odysseus0z/status/2030416758138634583