Harness Engineering 前沿挑战（八）：未解决的问题与未来方向
约 11 分钟3097 字0 次阅读
Harness Engineering 前沿挑战（八）：未解决的问题与未来方向
引言
Harness Engineering 是一个快速发展的领域，充满了未解的问题。了解这些"不知道"比记住已知的更重要——它们是指南针，指引着这个领域的未来研究方向。
这一篇整理了目前仍未解决的核心问题，以及社区正在探索的方向。
一、棕地项目改造：最大的未解决挑战
1.1 所有成功案例都是绿地
目前所有公开的 Harness Engineering 成功案例——OpenAI、Anthropic、Stripe、Hashimoto——全部是在全新项目上从零搭 Harness。
但现实中绝大多数团队面对的是已经跑了多年的代码库：
- 十年历史、没有架构约束
- 到处是技术债务
- 规范散落在不同地方
- 没有统一的入口文件
怎么把 Harness 引入一个这样的项目？目前没有任何公开方法论。
1.2 Böckeler 的比喻
她把这个挑战比作"在从未用过静态分析工具的代码库上运行静态分析"：
你会被警报淹没。
不是因为静态分析工具不好，而是因为代码库里有太多违反规则的地方，同时规则本身也可能需要调整。
1.3 Ambient Affordances 概念
Böckeler 提出了一个深刻的概念：Ambient Affordances。
强类型语言天然有类型检查作 sensor； 清晰的模块边界方便定义架构约束； Spring 这样的框架抽象了很多细节。
环境本身的结构特性决定了 Harness 能做多好。
这意味着：
- 绿地项目：可以从第一天就设计好 Harness
- 棕地项目：需要先改善代码库的结构特性，再逐步引入 Harness
二、功能验证：严重被忽视的领域
2.1 现状
大量讨论聚焦在架构约束和熵管理，但功能正确性验证被严重忽视。
大多数团队的做法：
- Feedforward：给功能规格
- Feedback：看 AI 生成的测试套件是否绿色通过
2.2 Böckeler 的尖锐批评
"This puts a lot of faith into AI-generated tests, that's not good enough yet."
用 AI 生成的测试来验证 AI 生成的代码，本质上是在用同一双眼睛检查自己的作业。
2.3 Approved Fixtures 模式
Thoughtworks 的一些团队在某些场景下用 Approved Fixtures 模式取得了好效果：
- 人工预先准备"正确结果"的 Fixture
- Agent 生成的输出与 Fixture 对比
- 适用于输出结构化、可预期的场景
但这个模式不适用于所有场景，不是一个全量解决方案。
2.4 开放问题
| 问题 | 现状 |
|---|---|
| 如何验证 AI 做对了事？ | 远未解决 |
| AI 生成测试的可靠性？ | 不足以作为唯一验证 |
| 人类审查的边界在哪？ | 不清晰 |
三、长期可维护性：没人知道答案
3.1 Greg Brockman 的问题
2025 年 Greg Brockman（OpenAI 联合创始人）提出了一个问题：
LLM 代码经常重新实现已有功能，长期效果未知。
这个问题至今没有人回答。
3.2 长期风险
- 重复实现：每次需求来了，Agent 倾向于自己写而不是复用现有代码
- 风格漂移：不同时间的生成物风格不一致
- 依赖膨胀：Agent 引入外部依赖但没有清理
- 文档腐烂：生成代码的文档是否跟着更新？
3.3 初步思路
Carlini 的"去重 Agent"是应对策略之一：
专门有一个 Agent 负责检测并删除重复的代码实现
但这只是局部优化，不是系统性解决方案。
四、Harness 该做厚还是做薄？
4.1 两个相反的案例
| 团队 | 方向 | 现象 |
|---|---|---|
| Manus | 越做越薄 | 五次重写，每次都更简单 |
| OpenAI | 越做越厚 | 五个月投入，越做越复杂 |
4.2 Böckeler 的分析
场景决定设计。
- 通用产品：追求最小化——覆盖最多场景，不针对特定需求
- 特定产品：可以高度定制——针对特定领域优化
4.3 一个关键发现
Anthropic 验证了一个反直觉的结论：
随着模型变强，已有 Harness 应该定期简化。
因为每个 Harness 组件都编码了一个"模型靠自己做不到"的假设。当模型能力提升后，某些假设不再成立，对应的组件就变成了冗余。
五、单 Agent vs 多 Agent：规模决定
5.1 两个极端
| 人物 | 立场 | 理由 |
|---|---|---|
| Hashimoto | 坚持单Agent | "我不打算跑多个Agent，也不想跑" |
| Carlini | 16并行Agent | 需要并行才能在合理成本内完成编译器 |
5.2 Decoding AI 的反直觉发现
"我一开始建了5个专业Agent，每个处理一步。后来发现一个带记忆和智能上下文工程的单Agent表现超过了整个Agent群。"
5.3 决策框架
| 场景 | 建议 |
|---|---|
| 小项目，单一目标 | 单Agent + 配得好的Harness |
| 大项目，复杂工作流 | 多Agent分工 |
| 需要并行加速 | 16+ 并行 |
| 不确定 | 先试单Agent，瓶颈了再考虑多Agent |
六、Harness 模板化：企业级未来
6.1 趋势
Böckeler 预测：
"Harness 将成为新的服务模板。"
大多数企业有两三个主要技术栈，未来团队可能会从一组预制 Harnesses 中选择，就像今天从服务模板实例化新服务。
6.2 类比服务模板
今天：
服务模板（Spring Boot模板、Koa模板）
→ 团队实例化
→ 自定义配置
→ 持续维护同步
未来：
Harness模板（电商Harness、SaaS后台Harness、数据管道Harness）
→ 团队选择
→ Agent类型和约束定制
→ 持续同步上游改进
6.3 挑战
但也面临类似服务模板的问题：
- 团队实例化后会与上游不同步
- 版本管理和贡献流程更复杂
- Non-deterministic 组件难以测试
七、开放问题清单
7.1 设计层面
| 问题 | 现状 | 谁在关注 |
|---|---|---|
| 棕地改造方法论 | 无公开方案 | Böckeler |
| 功能验证体系 | 严重缺失 | Böckeler |
| 长期可维护性 | 未知 | Greg Brockman |
| Harness厚薄判断 | 场景决定 | Böckeler |
7.2 工程层面
| 问题 | 现状 | 谁在关注 |
|---|---|---|
| Harness覆盖率评测 | 缺失 | Böckeler |
| 多Agent冲突解决 | 不成熟 | 社区 |
| 跨Harness迁移 | 困难 | Hermes（做迁移工具） |
7.3 安全层面
| 问题 | 现状 | 谁在关注 |
|---|---|---|
| 提示注入防护 | CVE-2026-25253 | OpenClaw |
| 多租户隔离 | 不成熟 | 企业用户 |
| 审计和合规 | 早期 | 金融、医疗 |
八、给研究者的方向
基于以上分析，以下是值得探索的方向：
方向1：棕地渐进式改造
问题：如何把 Harness 引入有技术债的现有代码库？
可能路径：
- 先做代码库健康度评估
- 设计"最小可行 Harness"从最高价值场景入手
- 建立度量体系追踪改进
方向2：可信的功能验证
问题：如何验证 AI 生成的功能是正确的？
可能路径：
- 形式化验证 + AI
- Property-based testing + AI
- Human-in-the-loop 但有效分工
方向3：Harness 版本化理论
问题：如何系统化管理 Harness 的演进？
可能路径：
- 借鉴测试覆盖率的思想
- 定义 Harness "覆盖率"和"质量"度量
- 建立 CI 集成的 Harness 评测
方向4：自适应 Harness
问题：Harness 能否根据模型能力自动调节？
可能路径：
- 模型能力评估 → Harness 组件选择
- 根据任务难度动态调整约束强度
- 自动移除冗余组件
总结
Harness Engineering 领域有七个"不知道"与一个"知道"：
七个不知道：
- 棕地改造怎么搞
- 功能验证怎么做
- 长期可维护性如何保证
- Harness 该厚还是薄
- 单还是多 Agent 怎么选
- 如何评测 Harness 覆盖率
- 如何做自适应 Harness
一个知道：
模型决定上限，Harness 决定底线。结构和约束 in，结构和约束 out。
这是 Harness Engineering 的核心哲学，无论领域如何演进，这一条不会变。
标签：#AI #Agent #HarnessEngineering #前沿 #未解决问题 #研究方向