Harness Engineering 前沿挑战（八）：未解决的问题与未来方向
整理Harness Engineering领域七个未解决的核心问题：棕地项目改造、功能验证缺失、长期可维护性未知、Harness厚薄之争、单多Agent选择困惑、评测体系缺失、自适应Harness方向。附研究者可探索的四个方向。
约 11 分钟阅读3,265 字74 次阅读博主
整理Harness Engineering领域七个未解决的核心问题：棕地项目改造、功能验证缺失、长期可维护性未知、Harness厚薄之争、单多Agent选择困惑、评测体系缺失、自适应Harness方向。附研究者可探索的四个方向。
📚 本系列目录：《Harness Engineering》 当前第 10/10 篇 · 上一篇：Harness Engineering 高级话题（七）：可观测性、熵管理与三类约束体系
《Harness Engineering》共 10 篇，本篇是第 10 篇。
← 上一篇：Harness Engineering 高级话题（七）：可观测性、熵管理与三类约束体系
Harness Engineering 是一个快速发展的领域，充满了未解的问题。了解这些"不知道"比记住已知的更重要——它们是指南针，指引着这个领域的未来研究方向。
这一篇整理了目前仍未解决的核心问题，以及社区正在探索的方向。
目前所有公开的 Harness Engineering 成功案例——OpenAI、Anthropic、Stripe、Hashimoto——全部是在全新项目上从零搭 Harness。
但现实中绝大多数团队面对的是已经跑了多年的代码库：
怎么把 Harness 引入一个这样的项目？目前没有任何公开方法论。
她把这个挑战比作"在从未用过静态分析工具的代码库上运行静态分析"：
你会被警报淹没。
不是因为静态分析工具不好，而是因为代码库里有太多违反规则的地方，同时规则本身也可能需要调整。
Böckeler 提出了一个深刻的概念：Ambient Affordances。
强类型语言天然有类型检查作 sensor； 清晰的模块边界方便定义架构约束； Spring 这样的框架抽象了很多细节。
环境本身的结构特性决定了 Harness 能做多好。
这意味着：
大量讨论聚焦在架构约束和熵管理，但功能正确性验证被严重忽视。
大多数团队的做法：
"This puts a lot of faith into AI-generated tests, that's not good enough yet."
用 AI 生成的测试来验证 AI 生成的代码，本质上是在用同一双眼睛检查自己的作业。
Thoughtworks 的一些团队在某些场景下用 Approved Fixtures 模式取得了好效果：
但这个模式不适用于所有场景，不是一个全量解决方案。
| 问题 | 现状 |
|---|---|
| 如何验证 AI 做对了事？ | 远未解决 |
| AI 生成测试的可靠性？ | 不足以作为唯一验证 |
| 人类审查的边界在哪？ | 不清晰 |
2025 年 Greg Brockman（OpenAI 联合创始人）提出了一个问题：
LLM 代码经常重新实现已有功能，长期效果未知。
这个问题至今没有人回答。
Carlini 的"去重 Agent"是应对策略之一：
专门有一个 Agent 负责检测并删除重复的代码实现
但这只是局部优化，不是系统性解决方案。
| 团队 | 方向 | 现象 |
|---|---|---|
| Manus | 越做越薄 | 五次重写，每次都更简单 |
| OpenAI | 越做越厚 | 五个月投入，越做越复杂 |
场景决定设计。
Anthropic 验证了一个反直觉的结论：
随着模型变强，已有 Harness 应该定期简化。
因为每个 Harness 组件都编码了一个"模型靠自己做不到"的假设。当模型能力提升后，某些假设不再成立，对应的组件就变成了冗余。
| 人物 | 立场 | 理由 |
|---|---|---|
| Hashimoto | 坚持单Agent | "我不打算跑多个Agent，也不想跑" |
| Carlini | 16并行Agent | 需要并行才能在合理成本内完成编译器 |
"我一开始建了5个专业Agent，每个处理一步。后来发现一个带记忆和智能上下文工程的单Agent表现超过了整个Agent群。"
| 场景 | 建议 |
|---|---|
| 小项目，单一目标 | 单Agent + 配得好的Harness |
| 大项目，复杂工作流 | 多Agent分工 |
| 需要并行加速 | 16+ 并行 |
| 不确定 | 先试单Agent，瓶颈了再考虑多Agent |
Böckeler 预测：
"Harness 将成为新的服务模板。"
大多数企业有两三个主要技术栈，未来团队可能会从一组预制 Harnesses 中选择，就像今天从服务模板实例化新服务。
今天：
服务模板（Spring Boot模板、Koa模板）
→ 团队实例化
→ 自定义配置
→ 持续维护同步
未来：
Harness模板（电商Harness、SaaS后台Harness、数据管道Harness）
→ 团队选择
→ Agent类型和约束定制
→ 持续同步上游改进
但也面临类似服务模板的问题：
| 问题 | 现状 | 谁在关注 |
|---|---|---|
| 棕地改造方法论 | 无公开方案 | Böckeler |
| 功能验证体系 | 严重缺失 | Böckeler |
| 长期可维护性 | 未知 | Greg Brockman |
| Harness厚薄判断 | 场景决定 | Böckeler |
| 问题 | 现状 | 谁在关注 |
|---|---|---|
| Harness覆盖率评测 | 缺失 | Böckeler |
| 多Agent冲突解决 | 不成熟 | 社区 |
| 跨Harness迁移 | 困难 | Hermes（做迁移工具） |
| 问题 | 现状 | 谁在关注 |
|---|---|---|
| 提示注入防护 | CVE-2026-25253 | OpenClaw |
| 多租户隔离 | 不成熟 | 企业用户 |
| 审计和合规 | 早期 | 金融、医疗 |
基于以上分析，以下是值得探索的方向：
问题：如何把 Harness 引入有技术债的现有代码库？
可能路径：
问题：如何验证 AI 生成的功能是正确的？
可能路径：
问题：如何系统化管理 Harness 的演进？
可能路径：
问题：Harness 能否根据模型能力自动调节？
可能路径：
Harness Engineering 领域有七个"不知道"与一个"知道"：
七个不知道：
一个知道：
模型决定上限，Harness 决定底线。结构和约束 in，结构和约束 out。
这是 Harness Engineering 的核心哲学，无论领域如何演进，这一条不会变。
标签：#AI #Agent #HarnessEngineering #前沿 #未解决问题 #研究方向
Series Index
Harness Engineering 指南Conversation
0 条