Harness：当 AI Agent 进入工程体系之后

先吐槽一句，这个行业是真的很爱造新词。

为什么会有Harness这个概念？

随着模型能力提升，Agent 已经可以承担越来越复杂的任务。从最早的代码补全，到现在可以连续运行几个小时，完成一个相对完整的系统开发。这种能力的变化，带来的并不是单纯的效率提升，也带来了很多麻烦：任务越复杂，Agent可能越跑偏，技术债也会越积越多。

在比较简单的demo和功能中，这个问题并不明显，因为任务足够简单。但一旦进入长流程和复杂逻辑，就会出现一系列问题：

• 上下文逐渐失效，信息开始丢失
• Agent 对任务理解发生偏移
• 输出质量波动明显
• 不同阶段之间缺乏连续性

所以很多开发人员就想从工程设计上来解决这些问题。

Harness到底在做什么

一句话，Harness就是一套用来规范和约束Agent行为的工程方法。

具体的内容就是一套包含了各种策略的方法论（以下是Anthropic的思路）：

1. 上下文管理（Context Management）

• Compaction（压缩）：保留关键信息，移除冗余对话
• Context Reset（上下文重置）：完全清空上下文，通过结构化交接让新 Agent 接管

Context Reset 比 Compaction 更彻底，给 Agent 一个”干净的 slate”，避免 context anxiety。

2. 任务分解（Task Decomposition）

• 使用 一个初始化agent 将产品需求分解为详细的功能列表
• 保证每个功能都是独立的、可测试的单元
• Coding Agent 每次只实现一个功能

功能列表使用 JSON 格式存储，Agent 只能修改状态字段（passes: true/false），不能删除或编辑测试。

3. 结构化交接（Structured Handoff）

• 进度文档：记录每个 Agent 完成的工作
• Git 历史：通过提交记录展示代码演进
• init.sh 脚本：快速重建开发环境
• 功能清单：明确的完成标准

每个新 Agent 启动时的标准流程：

1. 读取进度文档
2. 查看 Git 日志理解代码历史
3. 运行 init.sh 启动开发环境
4. 测试基础功能是否正常
5. 选择下一个要实现的功能

4. 生成器-评估器架构（Generator-Evaluator Architecture）

Generator Agent：负责实现功能 Evaluator Agent：负责质量评估

评估器使用具体的评分标准：

• 设计质量：是否形成统一的设计语言？
• 原创性：是否有定制化的创意，还是模板化的设计？
• 工艺：技术实现是否扎实？
• 功能性：是否真正可用？

评估器通过 Playwright MCP 实际操控应用，进行端到端测试，而不是仅仅看代码。

5. 迭代优化（Iterative Refinement）

• Generator 生成初版
• Evaluator 评估并给出详细反馈
• Generator 根据反馈改进
• 循环 5-15 轮直到质量达标

每轮迭代后，Generator 需要做出战略决策：

• 如果分数在提升 → 在当前方向继续优化
• 如果分数停滞或下降 → 转向全新的设计方向

非常烧token的玩法。

底层逻辑一致的不同路径

如果读了我之前的内容的朋友应该能发现，我在看到这套方法之前，根据自己的实践其实也在往类似的方向推进。

因为这个就是一个复杂系统的工程设计问题，底层的逻辑就是：

• 任务如何拆分
• 状态如何传递
• 过程如何约束
• 结果如何验证

最初只是因为一个很具体的问题：每次做一个新功能时，都需要重新写需求，让 AI 分析，然后再进入实现。但这个过程既不连续，也不稳定。后来就开始逐渐做了一些调整，譬如把需求改成固定模板；把开发流程拆解成明确的步骤；把所有这些可复用的逻辑都封装成skill。这些改变一开始只是为了减少重复、提高稳定性，但回过头来看，本质上做的事情和 Harness 是一致的，是为了让执行过程更可控（但是我还做不到完全放手，实在是信不过）。

Harness 更像一种工程取向

现在已经开始有人在比拼怎么设计Harness来让自己的agent自动跑的流程够久，但是我觉得这些没有太大意义。每个人的工作场景都不太一样，但是每个人都应该思考一下什么样的工程结构更能让你的项目长期稳定的工作。也许不需要多复杂的Agent系统，也不一定非要完整的Harness，也不需要完全自动化，需要在适当的时候由人介入。但是如果更稳定地和AI协作开发，是每个程序员都需要思考的问题。