什么是 Harness Engineering?

Harness(驾驭/套件) 是包裹在 AI 模型周围的基础设施层,用于管理长时间运行的任务,确保 agent 可靠、高效、可控。

1
2
3
4
5
6
7
类比:
┌─────────────────────────────────────────────────────┐
│  Model = CPU        → 原始计算能力                   │
│  Context Window = RAM → 有限的工作内存              │
│  Agent Harness = OS  → 管理上下文、启动序列、工具调用 │
│  Agent = Application → 具体的用户逻辑               │
└─────────────────────────────────────────────────────┘

核心功能:

  • Context Engineering:上下文压缩、卸载、隔离
  • 生命周期管理:启动钩子、工具处理
  • 可靠性保障:重试、验证、guardrails

OpenAI:0 手写代码实验

来源: Harness engineering: leveraging Codex in an agent-first world

实验成果

指标数据
时间5 个月
手写代码0 行
产出100 万行代码
团队3 人 → 7 人
PR 数量1500+
吞吐量3.5 PR/人/天

核心经验

挑战解决方案
环境不明确构建工具、抽象、内部结构让 agent 能工作
上下文爆炸AGENTS.md 当目录,不是百科全书
知识腐烂专门的 linter 和 CI 验证知识库
QA 瓶颈让 agent 直接访问 UI、logs、metrics

知识库设计

1
2
3
4
5
docs/
├── design/           # 设计文档,带验证状态
├── architecture/     # 架构地图,模块分层
├── quality/          # 质量评级,追踪缺口
└── plans/            # 计划作为一等公民,版本化

关键洞察:

“When the agent struggles, we treat it as a signal: identify what is missing — tools, guardrails, documentation — and feed it back into the repository.”


Mitchell Hashimoto:AI 采用的 6 个阶段

来源: My AI Adoption Journey

Hashimoto(HashiCorp 创始人)分享了他的 AI 采用路径:

阶段演进

阶段行动效果
1. Drop the Chatbot停止用聊天界面写代码聊天 ≠ Agent
2. Reproduce Your Own Work手动做一遍,再用 agent 做一遍形成专业知识
3. End-of-Day Agents每天下班前启动 agent利用非工作时间
4. Outsource the Slam Dunks把确定性任务交给 agent自己做其他事
5. Engineer the Harness构建自己的 harness放大 agent 能力
6. Always Have an Agent Running持续有 agent 在跑最大化产出

关键原则

  1. 分解任务,不要 “一次画完猫头鹰”
  2. 给 agent 验证工作的能力 → 它会自己修错
  3. 关掉通知,人类控制中断时机

Martin Fowler:Harness 的三大组件

来源: Harness Engineering

组件架构

1
2
3
4
5
6
7
8
9
Harness Components
├── Context Engineering
│   ├── 代码库中的知识库
│   └── 动态上下文(observability、浏览器导航)
├── Architectural Constraints
│   ├── LLM-based agent 监控
│   └── 确定性 linter + 结构测试
└── "Garbage Collection"
    └── 定期 agent 找不一致、违反约束

未来预测

问题观点
Harness 会成为新服务模板吗?可能,团队从预设 harness 启动
会导致技术栈收敛吗?可能,优先选择 “AI-friendly” 的栈
老代码库能 retrofit harness 吗?成本可能太高,和新项目两世界

Philipp Schmid:Bitter Lesson 的教训

来源: The importance of Agent Harness in 2026

为什么需要 Harness?

  • Benchmark 无法测量 50+ 步后的可靠性
  • 模型可能在长时间运行后 “漂移”
  • 需要系统验证多步工作流

实例:Harness 的快速迭代

公司变化
Manus6 个月重构 harness 5 次
LangChain1 年重构 Deep Research agent 3 次
Vercel删除了 80% 的 agent 工具

三个建议

  1. Start Simple:不要构建复杂的控制流
  2. Build to Delete:架构要模块化,随时准备删代码
  3. The Harness is the Dataset:agent 失败的轨迹是训练数据

Cursor:Self-Driving Codebases

来源: Towards self-driving codebases

实验:1000+ Agents 协作构建浏览器

架构演进:

1
2
3
4
5
v1: 单 agent → 失败(任务太复杂)
v2: 多 agent + 共享状态文件 → 失败(锁竞争)
v3: Planner + Executor + Workers → 瓶颈在最慢的 worker
v4: Continuous Executor → agent 被过多角色压垮
v5: Root Planner → Subplanners → Workers → 成功!

最终设计

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
┌─────────────────────────────────────────────────────┐
│                 Root Planner                        │
│  • 理解整体状态                                      │
│  • 分解任务                                          │
│  • 不写代码                                          │
└──────────────────┬──────────────────────────────────┘
                   │ spawns
┌─────────────────────────────────────────────────────┐
│               Subplanners                           │
│  • 完全拥有子任务                                    │
│  • 递归分解                                          │
└──────────────────┬──────────────────────────────────┘
                   │ spawns
┌─────────────────────────────────────────────────────┐
│                  Workers                            │
│  • 不知道大局                                        │
│  • 只管自己的任务                                    │
│  • 完成后写 handoff                                  │
└─────────────────────────────────────────────────────┘

Stripe:Minions 系统

来源: Minions: Stripe’s one-shot, end-to-end coding agents

成果

  • 每周 1000+ PR 合并
  • 人类 review,minions 写代码
  • One-shot:一次提交,端到端

METR:SWE-bench 的局限性

来源: Many SWE-bench-Passing PRs Would Not Be Merged into Main

核心发现

约 50% 通过 SWE-bench 自动测试的 PR 不会被维护者合并

改进速度(pp/yr)比 benchmark 显示的慢 9.6 个百分点

失败原因分布

原因说明
Core functionality没有正确解决问题或有 bug
Breaks other code触碰了无关代码,导致破坏
Code quality代码冗余、不符合规范

结论: Benchmark 分数 ≠ 真实世界有用性


Big Model vs Big Harness 辩论

来源: Latent Space: Is Harness Engineering real?

两派观点

阵营观点代表
Big Model所有 secret sauce 都在模型里,harness 越薄越好OpenAI, Anthropic
Big Harnessharness 决定体验,模型只是 CPUCursor, LangChain

Claude Code 的做法

“It’s very much the simplest thing by design. We’ve rewritten it from scratch probably every three weeks.”

中间立场

  • METR 研究显示 Claude Code 和 Codex 并不比基础 scaffold 好多少
  • Scale AI 的 SWE-Atlas 显示 harness 选择基本是噪声

实践建议

对于个人开发者

  1. 从 Agent 开始,不要从 Chatbot 开始
  2. 建立自己的 Harness:
    • 自定义 linter
    • 结构测试(如 ArchUnit)
    • 文档索引
  3. 让 agent 能验证自己的工作
  4. 关掉通知,人类控制中断

对于团队

  1. Harness 可能成为新的服务模板
  2. 知识库要像代码一样维护:
    • 专门的 “doc-gardening” agent
    • CI 验证知识库一致性
  3. 架构约束要可执行:
    • LLM-based + 确定性检查
    • 定期 “garbage collection”

核心共识

1. Harness 是必需的

模型本身不足以保证长时间运行的可靠性

2. Harness 要轻量

过度工程化的 harness 会被更强的模型淘汰

3. 知识库是核心

AGENTS.md 当目录,不是百科;知识要版本化、可验证

4. 人类角色转变

从写代码 → 设计环境、指定意图、构建反馈循环


参考资源