Harness Engineering
Harness Engineering
1. 当前面临的问题
当把一个任务交给大模型，它会：
- 开始阶段非常积极往前冲，一段时间后context耗尽了，留下一个烂摊子。后续再去做完全不知道之前在干嘛
- context快要满时，模型开始主动收尾，尽管任务并没有完成
- 模型做了一些代码上的改动，用
curl命令跑了个API测试，就告诉你没问题，当你打开浏览器一看啥也没有 - 你让模型评估自己的工作成果，它偏向于夸赞自己的结果，尽管并非如此
2. 什么是Harness Engineering
Harness Engineering 是为 AI Agent 构建完整运行环境和控制系统的工程方法，使其在明确约束下稳定、高效地完成复杂任务。和之前的Prompt Engineering、Context Engineering相比：
| Prompt Engineering | Context Engineering | Harness Engineering | |
|---|---|---|---|
| 核心问题 | 怎么【说】 | 模型【看到什么】 | 整个系统怎么【跑】 |
| 人机关系 | 人在每步 | 人设计信息流 | 人设计环境，Agent自动跑 |
| 出错处理 | 重新问 | 优化context | 自动反馈修复 |
| 适用场景 | 一问一答 | 复杂 RAG 应用 | 长时间agentic任务 |
| 关键指标 | 答案质量 | 上下文相关性 | 任务完成率 + 稳定性 |
3. 各家公司是怎么做的
3.1 OpenAI
AGENTS.md 是目录，而不是百科全书
最初生成的 AGENTS.md 是一本成百上千页的巨型说明书，但大量的说明指令反直觉的没有带来如预期中的效果改进。这个问题带来一些新的经验。
| 经验 | 表现 | 根本原因 |
|---|---|---|
| 上下文（Context）稀缺 | 巨大的指令文件挤掉任务和代码 | 上下文是有限资源 |
| 指令失效 | 指令中过多规则导致模式匹配而非理解 | 注意力被稀释，无法区分优先级 |
| 知识腐烂 | 手册变成陈旧规则的坟场 | 缺乏有效的维护机制 |
| 难以核实 | 单一文本块无法进行结构化检查 | 缺乏可验证的知识组织形式 |
于是，OpenAI不再将所有内容都放在 AGENTS.md 中，而是将其变成一本知识库目录，记录各个知识库的位置，agent通过这个目录，被指导下一步应该去哪里查看信息，这就是渐进式披露
用工具强制执行架构规则
团队通过使用 自定义linter、自动化测试，使得每一次错误，都会成为agent学习反馈信号
让应用对Agent可读
- 接入Chrome DevTools Protocol，让agent可以截图、读取DOM、自动操作UI，使系统对agent可见
- 同时暴露日志：LogQL，使agent能够自动分析bug并修复
Agent 自主性带来的熵增问题
通过将“代码质量黄金准则”写成程序，使得agent能够自动清理无用的代码
3.2 Anthropic
双Agent架构
第一代Harness建立了“初始化 Agent + 编码 Agent”的双 Agent 架构解决方案：
- 初始化 Agent（Initializer Agent）：作为第一个会话，然后专门负责搭建环境；
- 编码 Agent（Coding Agent）：在后续每个会话中作出增量进展，并为下一个会话留下清晰的交接物。
初始化 Agent 的关键产出包括：一个 init.sh 脚本（定义如何启动开发服务器）、一个 claude-progress.txt 进度文件（记录已完成工作的日志）、一次初始 git commit（显示已添加的文件），以及一个功能列表文件（feature list）——将用户输入的任务处理为具体的、可测试的功能需求，初始状态全部标记为”未完成”。
编码Agent通过读取git日志以及进度文件掌握现状，读取功能列表文件并选择优先级最高且未完成的功能开始工作。结束时提交git并更新任务进度，让下一个agent接手时可以直接处理任务。
还有一个问题是：编码 Agent 修改代码后仅用单元测试或 curl 命令验证，这样无法测试到功能是否真的能正常运行如交互功能。因此，要求编码 Agent 使用浏览器自动化工具如 Playwright MCP 像真实用户一样进行端到端测试，这样可以显著提升性能
三Agent架构
新的问题：
- 自我评估差，agent倾向于自信夸赞自己的作品
- 上下文焦虑，当它们认为自己快要达到上下文窗口极限时，开始提前收尾结束工作
针对新的问题，工程师参考对抗生成网络GAN，提出了“Planner + Generator + Evaluator”的三 Agent 架构解决方案：
- Planner（规划 Agent）： 接收用户的 1~4 句话提示，将其扩展为完整的产品规格。规划时刻意停留在高层设计，避免指定实现细节——避免 Planner 在细节上出错，错误级联传导到下游实现。目标是约束交付物，让 Agent 自己找到路径。
- Generator（生成 Agent）：继承第一代的”每次只做一个功能”原则，以迭代冲刺（Sprint）的方式工作。每个迭代冲刺结束后，Generator 先进行自评，再移交结果给 Evaluator。
- Evaluator（评估 Agent）： 有一套包括产品深度、功能性、视觉设计、代码质量的评分标准。每个标准都有一个硬性阈值，如果任何一项低于该阈值则该迭代失败，生成 Agent 收到来自评估 Agent 关于出错原因的详细反馈。
通过上下文重置（Context Reset）——完全清除上下文窗口并启动一个新 Agent 并配合结构化的交接机制（该机制会传递前一个 Agent 的状态和后续步骤）——可以给 Agent 提供了全新的上下文状态，就像一张完全干净的白板。这样能让 Agent 上下文窗口从头开始，清除上下文焦虑。它与上下文压缩的区别在于：压缩是将更早的对话就地压缩后同一 Agent 在缩短的会话上继续工作，而上下文焦虑依然存在。
4. Harness要随模型能力动态调整
随着模型能力的提升，对先前模型所施加的Harness工程可能不适合于能力更强的模型，Harness里对应的约束产生的开销会更慢、更贵、更复杂，而没有带来相当的收益。所以每换一次新模型，都要重新跑一遍任务，看看哪些约束可以被精简掉。