AI Engineering · Deep Dive

AI Harness 工程
让 Agent 稳定运行的约束框架

从 Anthropic 两篇实战文章提炼:用"框架 + 约束"解决 AI Agent 长时运行的核心难题,以及 GAN 启发的三段式架构如何将复杂任务从失败推向完成。

来源 Anthropic Engineering Blog
原文时间 2025.11.26 & 2026.03.24
作者 Justin Young · Prithvi Rajasekaran
页数 16 页
01 / 16
核心公式

Agent = Model + Harness

模型负责原始推理能力,Harness 负责其他一切——状态管理、进度追踪、质量保证、错误恢复。即便最强的模型,没有合适的 Harness,也无法可靠完成真正复杂的长时任务。

Agent
Agent
=
推理能力
Model
+
一切其他
Harness

"想象一个软件项目,工程师分班工作,每个新工程师来接班时对上一班发生的事情毫无记忆。这就是 AI Agent 在多上下文窗口工作时面临的根本挑战。" — Justin Young,Anthropic

02 / 16
为什么需要 Harness

长时 Agent 的五大失败模式

🔥
过度野心
一次性完成整个应用,耗尽上下文窗口,留下半成品且无文档的功能
🏳️
过早宣布完成
项目后期取得部分进展便"宣布工作已完成",不再继续推进
😰
上下文焦虑
接近上下文限制时过早"收尾",在实际限制到来前停止有效工作
🪞
自我评估偏差
评估自己的输出时自信称赞,即使质量对人类观察者明显低劣
🐛
测试不足
无适当测试便标记"完成",无法识别端到端功能是否真正正常工作
03 / 16
解决方案一

初始化 + 编码双层 Agent 架构

🚀
Initializer Agent
初始化 Agent
仅运行一次
📁
Environment Setup
init.sh
feature_list.json
git commit
⚙️
Coding Agent ×N
循环运行
每次处理一个功能
Clean State
Git 提交
进度更新
可合并代码
Initializer
初始化 Agent 任务
  • 生成可重复运行的 init.sh 脚本
  • 创建 claude-progress.txt 接班记录
  • 生成 feature_list.json(200+ 功能列表)
  • 建立初始 Git Commit 基线
Coding Agent
编码 Agent 启动序列
  • 读取 claude-progress.txt 了解状态
  • 读取 feature_list.json 选择功能
  • 执行 init.sh 重启开发服务器
  • 验证基础功能 → 开始单功能开发
04 / 16
环境管理

四大关键组件

📋
功能列表(Feature List)
结构化 JSON,200+ 功能初始标记为 passes: false。使用 JSON 而非 Markdown——模型不太可能对 JSON 进行不当修改。
只能通过改变 passes 字段更新
📈
增量进度(Incremental Progress)
每次只处理一个功能:选择单一功能 → 实现 + 测试 → Git 提交 → 更新进度文件。解决"一次性完成"倾向的核心机制。
每个会话:1功能 → 1提交
🖥️
端到端测试(E2E Testing)
明确提示 Claude 使用 Puppeteer MCP 等浏览器自动化工具,像真实用户一样进行测试。能识别和修复从代码层面无法明显发现的 Bug。
浏览器自动化 > 单元测试
🔄
干净状态(Clean State)
每个会话结束时,环境必须处于"干净状态"——无重大 Bug、代码整洁、文档完善,支持下一个 Agent 直接接班开发新功能。
合并即可用的代码状态
05 / 16
解决方案二

GAN 启发的生成器-评估器循环

核心问题:LLM 天生对 LLM 生成的内容持宽容态度。让同一个 Agent 评判自己的工作,结果往往是自我称赞。解决方案:将执行者与评判者分离,灵感来自 GAN(生成对抗网络)。

🎨 Generator
生成器 · 专注创作
  • 负责生成输出(前端设计、代码实现)
  • 专注"创作"而非评判
  • 接收评估器反馈后迭代改进
  • 每次迭代都在已有基础上突破
🔍 Evaluator
评估器 · 持怀疑态度
  • 负责评估输出质量
  • 设计为"怀疑论者"而非宽容者
  • 提供具体可操作的改进反馈
  • 使用少样本示例校准判断偏好

💡 关键洞察:将评估器调整为"持怀疑态度",比让生成器批评自己的工作要可行得多。分离本身是解决自我评估偏差的强力杠杆。

06 / 16
评估标准设计

前端设计的四维评分标准

核心权重 · 高
🎯 设计质量(Design Quality)
设计是否感觉像一个整体,而非各部分的堆砌?强烈的色彩、字体、布局、图像组合是否创造了独特的气质和身份认同?
核心权重 · 高
✨ 独创性(Originality)
是否有自定义决策的痕迹,还是模板布局和 AI 生成的通用模式?是否存在"AI 糟粕"(紫色渐变配白色卡片等典型套路)?
基础权重 · 常规
🔧 工艺(Craft)
技术执行:字体层级、间距一致性、色彩和谐、对比度。这是能力检验而非创意检验,大多数实现默认就做得不错。
基础权重 · 常规
🖱️ 功能性(Functionality)
独立于美学的可用性。用户能否理解界面功能、找到主要操作、在不猜测的情况下完成任务?

⚠️ 设计质量和独创性权重更高——Claude 在工艺和功能上默认表现良好,在设计品味和创意上最薄弱。

07 / 16
迭代涌现效应
"

在一个值得注意的例子中,我提示模型为一家荷兰艺术博物馆创建网站。到第九次迭代时,它产出了一个干净的深色主题着陆页。然后,在第十次循环时,它彻底推翻了思路,将网站重新想象为一种空间体验:一个用 CSS 透视渲染的 3D 房间,带有棋盘格地板,艺术品自由挂在墙上,用门道式导航在展厅之间切换。这是我以前从未见过的、来自单次生成的创意飞跃。

— Prithvi Rajasekaran,Anthropic Labs(2026.03.24)

🔬 实验发现:即使在第一次迭代,输出也明显优于基线——标准措辞本身就在引导模型远离通用默认值,甚至在评估器反馈触发改进之前。

08 / 16
第二代 Harness

三段式架构:Planner · Generator · Evaluator

AGENT 01 · PLANNER
🗺️ 规划师
  • 接收 1-4 句话简短提示
  • 扩展为完整产品规格
  • 聚焦产品背景和高层技术设计
  • 避免过早过度规格化
  • 主动融入 AI 特性与功能
AGENT 02 · GENERATOR
⚡ 生成器
  • 以 Sprint 为单位实现功能
  • 技术栈:React + Vite + FastAPI
  • 每个 Sprint 结束时自我评估
  • Git 版本控制追踪状态
  • 接收 Evaluator 反馈后修复
AGENT 03 · EVALUATOR
🔬 评估器
  • 使用 Playwright MCP 像用户一样点击
  • 测试 UI / API 端点 / 数据库状态
  • 按多维标准对每个 Sprint 打分
  • 任何标准低于门槛,Sprint 判定失败
  • 提供精确定位到行号的反馈

通信通过文件系统处理:一个 Agent 写入文件,另一个读取并在同一文件中响应——保持工作与规格一致性,不会过早过度规格化实现细节。

09 / 16
Sprint 机制

Sprint 合同:在代码编写前就"什么叫做完成"达成共识

STEP 01
Generator 提议
提出将要构建什么,以及如何验证成功——具体到可测量的验收标准
STEP 02
Evaluator 审查
确保 Generator 要构建正确的东西,双方迭代直到达成协议
STEP 03
Generator 构建
基于商定的合同进行构建,Evaluator 用 Playwright 测试是否符合合同
评估器实际发现的 Bug 示例
FAIL · 矩形填充工具:fillRectangle 函数存在但在 mouseUp 时未被正确触发,仅在起点/终点放置瓦片而非填充区域
FAIL · 删除键处理程序要求同时设置 selection 和 selectedEntityId,但点击实体只设置 selectedEntityId(LevelEditor.tsx:892)
FAIL · PUT /frames/reorder 路由定义顺序错误,FastAPI 将 'reorder' 作为整数 frame_id 匹配,返回 422 错误
10 / 16
实战对比

复古游戏制作器:单 Agent vs 完整 Harness

$9
单 Agent
20 分钟
$200
完整 Harness
6 小时
20×
Harness
更贵
10
完整 Harness
Sprint 数量
16
Planner 扩展
功能特性数
❌ 单 Agent($9)
  • 布局浪费空间,固定高度面板占据大量视窗
  • 工作流程僵硬,无引导序列
  • 游戏本身损坏:实体无法响应输入
  • 代码中连接断裂,无任何表面提示
  • 核心功能失败:游戏根本无法玩
✅ 完整 Harness($200)
  • 画布使用完整视窗,面板尺寸合理
  • 一致的视觉身份,贯穿设计方向
  • 内置 Claude AI 集成,可通过提示生成游戏
  • 超出原始提示的附加功能:动画、音效、导出
  • 核心功能成功:可以移动实体并真正玩游戏
11 / 16
Harness 迭代哲学

精简 vs 增强:随模型进化的 Harness

Opus 4.6 发布后,Rajasekaran 对 Harness 进行了系统性精简实验——"找到最简单的解决方案,只在需要时增加复杂性"

精简移除
Sprint 构造
Opus 4.6 能长时间持续进行代理任务,在更大代码库中更可靠运行,有更好的代码审查和调试技能捕捉自己的错误——Sprint 分解不再必要。
保留
Planner
没有 Planner,生成器的规模明显偏小:给定原始提示会直接开始构建而不先规格化,创建的应用功能更少。规格扩展仍然必要。
保留
Evaluator
改为整个运行结束后的单次评估(而非每 Sprint 评估)。评估器价值的动态性:当任务处于模型能力边界时才值得付出代价。
💡 核心原则:Harness 中的每个组件都编码了关于模型无法独立完成某事的假设。新模型发布时,重新审查每个组件——剥离不再负载关键性能的部分,添加新部分以实现之前不可能的目标。
12 / 16
实战案例 · DAW

从一行提示到完整 DAW(数字音频工作站)

3h50m
总运行时长
$124.70
总 Token 费用
3轮
QA 评估轮次
Agent / 阶段时长费用
Planner4.7 分钟$0.46
Build(第1轮)2小时7分钟$71.08
QA(第1轮)8.8 分钟$3.24
Build(第2轮)1小时2分钟$36.89
QA(第2轮)+ Build(第3轮)17.7 分钟$8.97
QA(第3轮)9.6 分钟$4.06

🎵 最终结果:包含完整核心功能的可用音乐制作程序——工作中的编排视图、调音台和传输控制在浏览器中运行。Opus 4.6 在没有 Sprint 分解的情况下连贯运行超过 2 小时。

13 / 16
实践建议

关键洞察:AI Harness 工程师的八条原则

🔬
持续实验与调优
对正在构建的模型实验,读取真实问题上的运行追踪,勿假设某个组件是否有效——要验证。
🔀
分离生成与评估
任何需要质量判断的任务,将执行者与评判者分离。独立评估器的价值远超自我审查。
📋
结构化状态传递
用 JSON 功能列表 + 进度文件 + Git 历史共同维护可追踪状态,支持中断恢复。
📏
可量化的主观标准
"这个设计好吗?"难以回答——将主观判断转化为具体可评分的条件,是提升质量的关键。
🪶
从最简单开始
每个 Harness 组件都应有明确存在理由——它解决了模型不能独立完成的什么问题?
🔄
随模型更新 Harness
新模型发布时重新审视每个组件,剥离不再必要的部分,添加新部分实现之前不可能的目标。
📝
向人类工程师学习
增量提交、进度日志、测试驱动——人类软件工程师的日常实践同样适用于 Agent Harness 设计。
🌐
端到端测试优先
使用浏览器自动化工具做端到端测试,效果远优于 curl 或单元测试——像真实用户一样使用产品。
14 / 16
未来研究方向

Anthropic 标注的三个开放问题

🤖
单 Agent vs 多 Agent
跨多个上下文窗口,单一通用编码 Agent 还是多 Agent 架构(专门的测试 Agent、QA Agent、代码清理 Agent)的表现更好?目前仍无定论。
🌍
领域泛化
当前实验主要针对全栈 Web 应用开发。这些发现能否应用于科学研究、金融建模、法律分析等其他需要长时代理任务的领域?
🔭
Harness 空间不收缩
随着模型改进,有趣的 Harness 组合空间不会缩小——它会移动。AI 工程师的有趣工作是不断找到下一个新颖组合。
两代 Harness 对比
第一代(Justin Young):初始化 + 编码双层架构,解决多上下文窗口状态延续问题
第二代(Prithvi Rajasekaran):GAN 启发的三段式(Planner + Generator + Evaluator),解决质量判断和规格扩展问题
15 / 16
总结

AI 工程的核心挑战已经转向

"如何让模型更聪明",转向"如何设计更好的约束框架"。即便是最强的模型,在没有适当 Harness 的情况下,也无法可靠地完成真正复杂的长时任务。
🏗️
核心公式
Agent = Model + Harness。模型提供推理能力,Harness 提供一切其他:状态管理、进度追踪、质量保证、错误恢复。
🎯
实践核心建议
先明确失败模式,再设计最简解法,然后随模型迭代不断精简。不要为了复杂而复杂,但也不要低估结构对 Agent 行为的塑造力。

"从这项工作中,我的信念是,有趣的 Harness 组合空间不会随着模型改进而收缩。相反,它会移动,AI 工程师的有趣工作就是不断找到下一个新颖组合。" — Prithvi Rajasekaran,Anthropic Labs(2026.03.24)

来源:Anthropic Engineering · "Effective harnesses for long-running agents"(2025.11.26)· "Harness design for long-running application development"(2026.03.24)
16 / 16