Martin Fowler 这篇文章为 Coding Agent 的 Harness 给出了最清晰的框架定义：Agent = Model + Harness，核心目标是提高 Agent 一次做对的概率，以及建立自纠正反馈循环。
🔥 框架核心：Feedforward + Feedback
Fowler 将 Harness 的控制机制分为两类：
- Guides（前馈控制）：在 Agent 行动之前进行引导，增加首次就产出好结果的概率
- Sensors（反馈控制）：在 Agent 行动之后观察并帮助其自纠正，特别是当信号针对 LLM 优化时效果最佳（如自定义 linter 消息中包含自纠正指令——一种「正向 prompt injection」）
两者缺一不可：只有 Feedback 会让 Agent 不断重复同样的错误；只有 Feedforward 则编码了规则但永远不知道是否有效。
🧠 控制机制的两种执行类型
Computational：确定性、快速、CPU 运行 → 测试、Linter、类型检查、结构分析
Inferential：语义分析、AI Code Review、LLM as Judge → Skills、AI 代码审查
Computational 控制便宜且可靠，适合每次变更都运行；Inferential 控制更贵且非确定性，但能提供丰富的语义判断。
🔑 关键洞察
Harness 的三层调控维度
- Maintainability Harness：调控内部代码质量和可维护性，当前最成熟的类型
- Architecture Fitness Harness：定义和检查架构特性（本质是 Fitness Functions）
- Behaviour Harness：功能行为正确性——这是最大的「房间里的大象」，目前主要依赖 AI 生成的测试套件，但还不够可靠
Harnessability 不是平等的
强类型语言天然有类型检查作为 Sensor；清晰的模块边界支持架构约束规则；Spring 等框架抽象了细节，隐式提高了 Agent 成功率。
Greenfield 团队可以从第一天就植入可驾驭性，Legacy 团队则面临「最需要 Harness 的地方最难构建」的困境。
Harness Templates 是下一个演进方向
大多数企业有几种常见的服务拓扑覆盖 80% 需求。这些可能演变为 Harness Templates：一组捆绑的 Guides 和 Sensors，将 Coding Agent 约束到特定的结构、约定和技术栈。团队可能会部分基于「已有哪些 Harness 可用」来选择技术栈。
🚀 引发思考
Fowler 指出了几个关键的开放问题：
- Harness 一致性：随着 Harness 增长，如何保持 Guides 和 Sensors 同步、不互相矛盾？
- 信任边界：当指令和反馈信号指向不同方向时，能在多大程度上信任 Agent 做出明智的权衡？
- 检测盲区：如果 Sensors 从未触发，是高质量还是检测机制不充分？
- Harness 覆盖率：我们需要类似代码覆盖率和变异测试的手段来评估 Harness 的覆盖和质量。
Harness 不应该旨在完全消除人类输入，而是将人类注意力引导到最有价值的地方。这是 2026 年 AI 工程领域最重要的实践范式之一。
📎 相关阅读
- OpenAI: Harness Engineering — Leveraging Codex in an Agent-First World
- Stripe: Minions — Stripe's One-Shot End-to-End Coding Agents
- arXiv: Building Effective AI Coding Agents for the Terminal (OPENDEV)
- Louis Bouchard: Harness Engineering — The Missing Layer Behind AI Agents
逍遥云初 | 2026.04.30
