什么是 Harness Engineering?
Harness(驾驭/套件) 是包裹在 AI 模型周围的基础设施层,用于管理长时间运行的任务,确保 agent 可靠、高效、可控。
| |
核心功能:
- 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 |
知识库设计
| |
关键洞察:
“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 个阶段
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 在跑 | 最大化产出 |
关键原则
- 分解任务,不要 “一次画完猫头鹰”
- 给 agent 验证工作的能力 → 它会自己修错
- 关掉通知,人类控制中断时机
Martin Fowler:Harness 的三大组件
组件架构
| |
未来预测
| 问题 | 观点 |
|---|---|
| Harness 会成为新服务模板吗? | 可能,团队从预设 harness 启动 |
| 会导致技术栈收敛吗? | 可能,优先选择 “AI-friendly” 的栈 |
| 老代码库能 retrofit harness 吗? | 成本可能太高,和新项目两世界 |
Philipp Schmid:Bitter Lesson 的教训
来源: The importance of Agent Harness in 2026
为什么需要 Harness?
- Benchmark 无法测量 50+ 步后的可靠性
- 模型可能在长时间运行后 “漂移”
- 需要系统验证多步工作流
实例:Harness 的快速迭代
| 公司 | 变化 |
|---|---|
| Manus | 6 个月重构 harness 5 次 |
| LangChain | 1 年重构 Deep Research agent 3 次 |
| Vercel | 删除了 80% 的 agent 工具 |
三个建议
- Start Simple:不要构建复杂的控制流
- Build to Delete:架构要模块化,随时准备删代码
- The Harness is the Dataset:agent 失败的轨迹是训练数据
Cursor:Self-Driving Codebases
来源: Towards self-driving codebases
实验:1000+ Agents 协作构建浏览器
架构演进:
| |
最终设计
| |
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 Harness | harness 决定体验,模型只是 CPU | Cursor, 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 选择基本是噪声
实践建议
对于个人开发者
- 从 Agent 开始,不要从 Chatbot 开始
- 建立自己的 Harness:
- 自定义 linter
- 结构测试(如 ArchUnit)
- 文档索引
- 让 agent 能验证自己的工作
- 关掉通知,人类控制中断
对于团队
- Harness 可能成为新的服务模板
- 知识库要像代码一样维护:
- 专门的 “doc-gardening” agent
- CI 验证知识库一致性
- 架构约束要可执行:
- LLM-based + 确定性检查
- 定期 “garbage collection”
核心共识
1. Harness 是必需的
模型本身不足以保证长时间运行的可靠性
2. Harness 要轻量
过度工程化的 harness 会被更强的模型淘汰
3. 知识库是核心
AGENTS.md 当目录,不是百科;知识要版本化、可验证
4. 人类角色转变
从写代码 → 设计环境、指定意图、构建反馈循环