【理论】Harness Engineering：从 Anthropic 的 4 小时 DAW 实验到 AI 原生开发的新范式

https://www.youtube.com/watch?v=Y-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"的克隆，揭示了两个核心的系统性失败模式：

第一个是"一把梭"倾向。给定一个高层级的 Prompt，Agent 倾向于试图在单次运行中完成整个应用，这通常导致 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 系统上分别进行了测试，结果是天壤之别：

超过 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 系统中的每一个组件都编码了一个关于"模型做不好什么事"的假设。

当 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 Hash（Teleport 的创造者）将自己的 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 Engineering

Harness 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 的指导应该是指向更深层文档的目录，而非详尽无遗的说明书。过多的指导会变成无指导。

六、参考文献

1. Anthropic: Building a DAW in the Browser with Claude (2026)
2. Rajesh Karan: Harness Engineering - The Third Paradigm of AI Development
3. Andrej Karpathy: Context Engineering
4. Ian Goodfellow: Generative Adversarial Networks (2014)
5. OpenAI: Codex Agent - 1 Million Lines of Code
6. Mitchell Hash: Six Steps to AI Adoption
7. LangChain: Harness Tuning Benchmark
8. Strap: Agent-Driven Development at Scale
9. 企业级 Harness Engineering (驾驭工程) 落地实战指南
10. 工程技术：在智能体优先的世界中利用 Codex. https://openai.com/zh-Hans-CN/index/harness-engineering/
11. Harness Engineering 学习指南 — 从概念理解到独立实践的深度学习档案. https://github.com/deusyu/harness-engineering
12. Harness Engineering：Anthropic实现让 AI 6小时无人干预生成完整项目. https://gitcode.csdn.net/69c9de770a2f6a37c59b7b16.html?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EElasticSearch%7Eactivity-1-159637732-blog-161364373.235%5Ev43%5Econtrol&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EElasticSearch%7Eactivity-1-159637732-blog-161364373.235%5Ev43%5Econtrol&utm_relevant_index=1
13. hermes-agent. https://gitcode.com/GitHub_Trending/he/hermes-agent?utm_source=csdn-index-opensource&isLogin=1