https://www.youtube.com/watch?vY-hKw2uzQKU一、背景介绍2026 年 3 月 24 日Anthropic 发布了一篇技术博客记录了一个令整个 AI 工程界震动的实验。他们让 Claude 自主编写了整整 4 个小时的代码只凭一句话——“在浏览器中用 Web Audio API 构建一个全功能的 DAW”——就生成了一个可以实际运行的数字音频工作站。这个 DAW 并非玩具。它有完整的编混音器、音轨传输控制还内置了一个 Claude 驱动的 AI 助手。用户可以用自然语言设置节拍和调性、创建旋律线、构建鼓组、调整混音电平、添加混响效果——完全由 Agent 通过工具调用自主完成。但这个实验真正的价值不在于产出的 DAW 本身而在于踩过的每一个坑以及由此沉淀出来的一套完整工程方法论。这套方法论被称为Harness Engineering。要理解 Harness 为何重要我们需要先理解它在 AI 工程演进史中的位置。在过去几年AI 应用开发的核心能力经历了三次范式迁移第一次是 Prompt Engineering提示词工程。核心命题是如何写出好的提示词如何遣词造句引导模型的推理路径第二次是 Context Engineering上下文工程。核心命题从如何写好提示词变成了如何在有限的注意力预算中策划出最可能产生期望行为的上下文配置。Andrej Karpathy 称其为艺术与科学的结合。第三次正是我们正在见证的 Harness Engineering驾驭工程。它将视角进一步拉高关注围绕 Agent 的整个运行环境的设计。用一个直觉性的比喻如果 AI Agent 是一匹骏马那么 Prompt Engineering 是你对马说的话Context Engineering 是你给马看的路线图而 Harness Engineering 则是完整的缰绳、马鞍、马蹄铁和赛道围栏的系统——它定义了马可以跑的边界以及当马偏离轨道时自动纠偏的机制。这一演进并非后者取代前者而是层层包含、层层递进。二、方案分析Harness Engineering 的核心哲学与系统架构2.1 四大核心命题综合多方定义我们可以将 Harness Engineering 的核心哲学提炼为四个命题命题一Agent 的性能天花板不取决于模型本身而取决于模型周围的系统。同一个模型同一句 Prompt仅通过改变 Harness 系统就能获得天壤之别的输出质量。命题二Harness 的每一个组件都编码了一个关于模型做不好什么的假设。这意味着 Harness 不是静态的架构而是随模型能力变化而持续演进的系统。命题三构建 Harness 的核心技能是监督你读不懂的代码。AI 现在会写代码了真正重要的技能不再是逐行审查代码的能力而是设计约束、定义验证标准、构建反馈循环的能力。命题四找到最简单的可行解决方案只在需要时才增加复杂度。Harness 系统不应该是过度工程化的产物而应该是对实际失败模式的精准回应既不多也不少。2.2 单 Agent 方案的系统性失败模式在深入 Harness 系统之前我们需要先理解为什么单 Agent 的方案会失败。在早期实验中Anthropic 使用 Claude Agent SDK 配合 Opus 4.5 模型让 Agent 跨多个上下文窗口持续编码构建一个Claude 点 AI的克隆揭示了两个核心的系统性失败模式第一个是一把梭倾向。给定一个高层级的 PromptAgent 倾向于试图在单次运行中完成整个应用这通常导致 Agent 在实现到一半时耗尽上下文窗口留下一堆必须由下一个 Agent 猜测前一 Agent 做了什么的工作花费大量时间尝试让基础功能重新运作。第二个是宣布胜利倾向。在项目进行到后期某个新启动的 Agent 实例会环顾四周看到已有进展然后错误地认为工作已完成宣布整个项目结束尽管还有大量未实现的功能。这两个失败模式揭示了一个根本性问题Agent 缺乏对项目全局状态的持久认知。每一个新的 Agent 会话都像是一个失忆的新员工来到一个他从未见过的代码库面前被要求继续前人的工作——但前人什么都没留下。2.3 深层失败模式与 GAN 启发式架构在初级 Harness 的基础上Anthropic 进一步识别出了两个更深层、更难解决的失败模式。第一个是上下文焦虑。这是一个极具启发性的发现当 Agent 的上下文窗口逐渐被填满时模型的行为会发生微妙但系统性的变化——他开始提前收工匆忙结束当前工作不是因为工作已完成而是因为他担心自己快要触及上下文窗口的边界了。传统的解决方案是上下文压缩但 Anthropic 发现这并不够。原因是压缩虽然缩短了历史但没有给 Agent 一张干净的白板——Agent 仍然记得自己已经工作了很长时间。Anthropic 的解法是更激进的上下文重置——彻底清空启动全新实例通过结构化的交接文档传递状态。新 Agent 获得完全干净的白板以全新经历投入工作。第二个失败模式是自我评估偏差。当要求 Agent 评估自己刚刚完成的工作时他几乎总是给出过于正面的评价自信地赞美自己的工作即使在人类观察者看来质量明显平庸。这在前端设计等主观性任务上尤为突出——没有类似于测试是否通过这样的二元检验标准让生成者同时充当评判者本质上存在利益冲突。这就像让论文作者同时担任自己论文的审稿人。面对自我评估偏差这个顽疾Anthropic 从一个经典的机器学习架构中获得了灵感生成对抗网络GAN由 Ian Goodfellow 在 2014 年提出。两个神经网络——生成器负责生成内容判别器负责判断真伪两者在对抗性博弈中共同进步生成器不断提高生成质量以欺骗判别器判别器不断提高鉴别能力以识别生成器的输出。Anthropic 将这一对抗性逻辑迁移到软件工程的 Agent 系统中。它的关键洞察是虽然让一个 Agent 批评自己的工作非常困难但让一个独立的 Agent 来批评另一个 Agent 的工作则是可行性高得多的方案。分离本身并不能立即消除 LLM 固有的宽容倾向但关键的区别在于调教一个独立的评估器变得严格比让一个生成者对自己的工作变得严格要容易得多。这种生成-对抗的架构不仅适用于软件开发它提供了一个通用框架对于任何需要 AI Agent 长时间自主工作并保持高质量输出的任务都可以考虑将生产与评估分离为两个独立的 Agent 角色通过对抗性的反馈循环驱动整体质量提升。2.4 三 Agent 系统Planner、Builder、Evaluator在 GAN 启发式思路的基础上Anthropic 最终构建了一个由三个专门化 Agent 组成的系统1规划器Planner它接收用户的 1~4 句话 Prompt将其扩展为一份完整的产品规格说明包含功能模块、用户故事、数据模型、视觉设计语言、关键设计决策等。规划器要克制自己专注于产品上下文和高层技术设计而非详细的技术实现。Rajesh Karan 的原话是“给方向但不给路径”。规划器还会在产品规格中主动寻找机会嵌入 AI 功能让最终产品自带 AI 特性。2生成器Builder它以冲刺为单位工作每次从规格说明中选取一个功能进行实现一次只做一个功能避免一把梭。每个冲刺结束后进行自我评估然后将工作交给评估器进行独立审查。3评估器Evaluator这是整个系统中最关键也是最难设计的组件。评估器使用 Playwright MCP 与正在运行的应用进行实际交互像真实用户一样点击界面、导航功能、测试 API 端点、检查数据库状态然后根据预定义的评分标准打分撰写详细的反馈报告。任何一个标准低于阈值整个冲刺就被判定为失败。生成器会收到详细的失败原因和改进建议。Rajesh Karan 坦言“开箱即用的 Claude 是一个糟糕的 QA Agent。”调教评估器需要多轮迭代读日志、找偏差、更新提示词、再次运行直到达到严苛标准。三、实操步骤从前端设计到全栈编码的验证3.1 前端设计领域的首次试用再将生成-对抗架构应用到全栈编码之前Rajesh Karan 首先在前端设计领域进行了试用。这是最聪明的选择因为前端设计是自我评估偏差问题最严重的领域。一个设计是否美观没有任何二元检验标准可以依赖。Claude 在没有干预的情况下表现出强烈的安全牌倾向标准的卡片式设计、预设的间距系统、毫无个性的配色方案。AI 生成的设计几乎形成了标志性套路的特征——紫色渐变覆盖白色卡片、未经修改的 Tailwind 默认组件。业界有一个专门的贬义词来形容这些 AI 风格的设计。为了将主观的品味转化为可操作的反馈信号Rajesh Karan 设计了四个评分维度设计质量是否有统一的身份感原创性是否有刻意的创意选择严厉惩罚 AI 套路工艺排版、间距、色彩和谐度的技术执行功能性用户能否理解界面并完成任务关键是维度权重的战略性分配设计质量和原创性的权重远高于工艺和功能性推动模型在美学和风险承受方面更加大胆。完整的循环是生成器创建前端 → 评估器用 Playwright 截图、深度研究、按四维评分 → 反馈下一轮迭代。通常运行 5~15 轮每一轮推动设计向更独特的方向发展。有一个令人惊叹的案例为荷兰艺术博物馆创建网站。前九轮都是精致的深色主题着陆页然后在第十轮生成器完全抛弃了之前的方案将网站重新想象为一个 CSS 3D 空间体验——棋盘格地板、艺术作品悬挂在虚拟墙壁上、门廊作为导航在不同画廊房间之间穿行。Rajesh Karan 说“这是我从未在单次生成中见过的那种创意跳跃。”3.2 复古游戏制作器的对比实验Anthropic 用同一个 Prompt——“创建一个包含关卡编辑器、精灵编辑器、实体行为和可玩测试模式的 2D 复古游戏制作器”——在单 Agent 系统和完整 Harness 系统上分别进行了测试结果是天壤之别方案耗时成本结果单 Agent 方案20 分钟9 美元界面包含关卡编辑器、精灵编辑器等组件但布局浪费空间、工作流程僵硬游戏本身彻底损坏——实体出现在屏幕上但对输入没有任何响应核心游戏循环是断裂的完整 Harness 方案6 小时200 美元游戏可以实际玩评估器精确定位到代码行号和逻辑错误的根本原因超过 20 倍的差距。单 Agent 的输出初看似乎符合预期但随着深入使用会发现致命缺陷。而 Harness 系统从同一句 Prompt 出发但规划器将其扩展为包含16 个功能、分布在 10 个冲刺中的完整规格说明包含精灵动画系统、行为模板、音效、AI 辅助的精灵图生成器、AI 关卡设计器以及带有可分享链接的游戏导出功能。最关键的差异在 Harness 版本中游戏是可以实际玩的。评估器在整个过程中发挥了关键作用它不仅识别出了问题还精确定位到了代码行号和逻辑错误的根本原因。比如level editor 第 892 行的 DELETE 键处理器要求selection和selectedEntity同时被设置但点击一个实体只设置了selectedEntityId条件应该改为selection selectedEntityId activeLayer。“这种精确度远超简单的看起来对不对”。3.3 数字音频工作站DAW的极限测试在完成了复古游戏制作器之后Rajesh Karan 选择了一个更具挑战性的任务用一句话 Prompt 构建一个浏览器端的数字音频工作站DAW。Prompt 极其简洁“在浏览器中用 Web Audio API 构建一个全功能的 DAW能够像 Logic Pro / FL Studio 那样工作。”这类经过数十年迭代的专业软件要求一个 AI Agent 在 4 小时内完成是对 Harness 系统能力的极限测试。整个运行耗时 3 小时 50 分钟总成本 124.70 美元。规划器阶段仅用 4.7 分钟、0.46 美元极其高效。构建第一轮用时 2 小时 7 分钟、71 美元——生成器连续运行超过两个小时无需 Sprint 分解或上下文重置。在 Opus 4.5 时代这是不可能的。评估器在第一轮反馈中写道“这是一个强大的应用设计保真度出色。AI 主要失败点在于功能完整性片段无法在时间线上拖拽移动没有乐器 UI 面板也没有视觉效果编辑器。这些不是边缘情况它们是让 DAW 可用的核心交互。”经过三轮构建和三轮 QA最终的 DAW 包含了可工作的编曲视图、混音器和传输控制全部在浏览器中运行。Rajesh Karan 能够完全通过自然语言提示来制作一个简短的歌曲片段。这场 4 小时的极限实验成为了 Harness 系统能力的最佳证明。四、验证效果元认知框架与行业共识4.1 元认知框架每个组件编码一个假设Rajesh Karan 提出了一个深刻的元认知框架Harness 系统中的每一个组件都编码了一个关于模型做不好什么事的假设。组件编码的假设上下文重置模型在长上下文中会产生焦虑Sprint 分解模型无法单次长时间保持一致性独立评估器模型无法准确评估自己工作质量规划器模型在收到简单 Prompt 时会跳过关键细节当 Claude Opus 4.6 发布时这一框架得到了完美验证。Opus 4.6 规划更加仔细能够更长时间地维持 Agent 任务在更大的代码库中运行得更加可靠并且有更好的代码审查和调试能力来发现自己的错误。团队首先尝试移除 Sprint 结构实验结果验证了假设生成器在没有 Sprint 分解的情况下连续编码超过两个小时保持了高质量的输出一致性。上下文焦虑也在 Opus 4.6 上几乎消失上下文重置变得不再必需。但 Anthropic 对激进简化持谨慎态度转向了一种更系统化的方法每次只移除一个组件然后审查其对最终结果的影响。这种压力测试方法确保了每次简化都是有依据的、风险可控。而评估器的价值具有动态性越靠近模型能力边界的任务评估器价值越大模型能力边界外移评估器的价值也随之迁移。4.2 行业共识的收敛Harness Engineering 并非 Anthropic 一家的孤立实践多个重量级参与者从不同角度收敛到了同一套核心原则OpenAI 的实验堪称极端一个由三名工程师组成的团队在 5 个月的时间里使用 Codex Agent 构建了一个约 100 万行代码的内部产品并且没有一行代码是人类手工编写的。他们的核心哲学是“人类掌舵Agent 执行”。他们还发现了地图而非百科全书原则——Agent 的 SMD 控制在 100 行仅作为指向更深层文档的目录。过多的指导会变成无指导当所有东西都重要时就什么都不重要了。Mitchell HashTeleport 的创造者将自己的 AI 采纳之旅总结为六步法从放弃聊天机器人到始终保持 Agent 运行。其中最核心的第五步是每当你发现 Agent 犯了一个错误就花时间去工程化一个解决方案使得 Agent 永远不会再犯同样的错误。LangChain 的数据则提供了最直接的量化证据底层模型固定为 GPT-52 Codex仅通过调整 Harness 系统提示、工具集和中间件分数从 52.8% 提升到 66.5%涨幅 13.7 个百分点跻身 TOP 5。模型不变Harness 的调整带来了如此显著的性能提升。Strap 的调整系统则是目前最成熟的大规模 Agent 部署每周产出超过 1,000 个合并的 PR。Agent 通过一个集中的工具集访问超过 400 个内部工具。4.3 底层引擎Context EngineeringHarness Engineering 的底层引擎是 Context Engineering上下文工程。Anthropic 的指导原则是好的上下文工程 找到最小的高信号 Token 集合使期望结果的可能性最大化。这一原则的理论基础是 Transformer 架构的注意力机制——每个 Token 对上下文中的每个其他 Token 进行关注产生 N² 量级的成对关系。随着上下文增长模型捕获这些关系的能力被摊薄。每一个引入上下文的 Token 都不是免费的不是给得越多越好而是给得越精准越好。对于常识任务有三种核心的上下文管理策略压缩将接近极限的对话进行摘要保留最大召回率然后迭代改进精确率。结构化笔记Agent 定期将笔记写入持久存储。Claude 玩 Pokemon 的实验是绝佳案例——Agent 在数千个游戏步骤中开发了探索区域的地图、追踪关键成就、维护战斗策略笔记跨压缩步骤保持连贯的多小时训练序列。子弹里架构专门化的子 Agent 处理聚焦任务每个子 Agent 拥有干净的上下文窗口指向主 Agent 并返回浓缩的摘要。渐进式信息披露让 Agent 像人一样探索从轻量级标识符出发在运行时动态加载所需数据。正是这种模拟人类认知的策略让 Agent 在海量信息中保持高效。五、总结八项行动指南Anthropic 的实验证明了一个革命性的命题Agent 的性能天花板不仅取决于模型本身更取决于你为其搭建的系统。让我们把这一切融合为八项行动行动一建立观测-记录-预防的反馈飞轮每当 Agent 犯一个错误不要只是手动修复工程化一个解决方案使它永远不再犯同样的错误。行动二生产与评估分离对于任何重要的长时间运行任务构建一个独立的评估机制评估者不能是生成者自己。行动三投资上下文基础设施结构化的进度追踪、文件、功能清单、架构文档——这些不是文档这些是 Agent 的记忆系统。行动四定义约束而非微管理实现清晰的架构边界通过自动化工具机械地执行然后给 Agent 充分的自由度来选择实现方式。行动五将品味量化为反馈信号定义具体的评分标准使用 Few-shot 校准明确惩罚已知的 AI 质量陷阱。行动六定期压力测试你的 Harness 组件每次有新模型发布重新审视那些模型做不好什么的假设移除已过时的组件。行动七构建你的 Harness 时间预算这不是一次性投入而是持续的工程实践。行动八拥抱地图而非百科全书Agent 的指导应该是指向更深层文档的目录而非详尽无遗的说明书。过多的指导会变成无指导。六、参考文献Anthropic: Building a DAW in the Browser with Claude (2026)Rajesh Karan: Harness Engineering - The Third Paradigm of AI DevelopmentAndrej Karpathy: Context EngineeringIan Goodfellow: Generative Adversarial Networks (2014)OpenAI: Codex Agent - 1 Million Lines of CodeMitchell Hash: Six Steps to AI AdoptionLangChain: Harness Tuning BenchmarkStrap: Agent-Driven Development at Scale企业级 Harness Engineering (驾驭工程) 落地实战指南工程技术在智能体优先的世界中利用 Codex. https://openai.com/zh-Hans-CN/index/harness-engineering/Harness Engineering 学习指南 — 从概念理解到独立实践的深度学习档案. https://github.com/deusyu/harness-engineeringHarness EngineeringAnthropic实现让 AI 6小时无人干预生成完整项目. https://gitcode.csdn.net/69c9de770a2f6a37c59b7b16.html?spm1001.2101.3001.6661.1utm_mediumdistribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EElasticSearch%7Eactivity-1-159637732-blog-161364373.235%5Ev43%5Econtroldepth_1-utm_sourcedistribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EElasticSearch%7Eactivity-1-159637732-blog-161364373.235%5Ev43%5Econtrolutm_relevant_index1hermes-agent. https://gitcode.com/GitHub_Trending/he/hermes-agent?utm_sourcecsdn-index-opensourceisLogin1
