Harness Engineering：包围模型的是什么
关键方程
Agent = Model + Harness什么是 Harness？
Harness（支架）：包裹模型的支架，让它实际完成任务。
组成： - Prompts（提示词） - Tools（工具） - Context policies（上下文策略） - Hooks（钩子） - Sandboxes（沙盒） - Sub-agents（子 Agent） - Observability（可观测性）
为什么这个区分重要？
常见错误直觉：
白皮书警告：
“There is a temptation to treat the model as the system. A new model comes out, the agent gets smarter. An older model and the agent gets worse. The model becomes the explanation for everything good and bad. That intuition is wrong, and it leads to the wrong investments.”
翻译：有诱惑将模型视为系统。新模型出来，Agent 变聪明。旧模型，Agent 变差。模型成为一切好坏的解释。那个直觉是错的，导致错误的投资。
正确理解：
“The model is one input into a running agent. Everything else is the harness: the scaffolding wrapped around the model that lets it actually finish something.”
翻译：模型是运行 Agent 的一个输入。其他一切都是 harness：包裹模型的支架，让它实际完成某事。
Harness 的六层组成
┌─────────────────────────────────────────────────────┐
│ 1. Instructions and Rule Files │
│ → 定义 Agent 身份、关心什么、禁止做什么 │
│ → AGENTS.md、CLAUDE.md、GEMINI.md、skill 文件 │
├─────────────────────────────────────────────────────┤
│ 2. Tools │
│ → Agent 可调用的函数、MCP 服务器、API │
│ → 告诉模型何时如何调用 │
├─────────────────────────────────────────────────────┤
│ 3. Sandboxes & Execution Environments │
│ → Agent 代码运行的地方 │
│ → 可访问什么、不可触及什么 │
├─────────────────────────────────────────────────────┤
│ 4. Orchestration Logic │
│ → Sub-agent 生成、模型路由、专家交接 │
│ → 触发规则 │
├─────────────────────────────────────────────────────┤
│ 5. Guardrails / Hooks │
│ → 特定生命周期点运行的确定性代码 │
│ → 工具调用前、文件编辑后、commit 前 │
│ → Agent 应永不忘记但经常忘记的事 │
├─────────────────────────────────────────────────────┤
│ 6. Observability │
│ → Logs、traces、评估、成本和延迟计量 │
│ → 无此无法判断 Agent 是否做好或悄然漂移 │
└─────────────────────────────────────────────────────┘白皮书强调：
“If that sounds like a lot of surface area, it is. And it is the team’s surface area, not the model provider’s.”
翻译：如果这听起来表面面积很大，确实如此。而且这是团队的表面面积，不是模型提供商的。
Harness 在 SDLC 各阶段的角色
| SDLC 阶段 | Harness 角色 | 关键动作 |
|---|---|---|
| Requirements & Planning | 配置 Harness | 提供 Instructions/Rule Files、定义工具、设置基本规则 |
| Implementation | 运行 Harness | 作为边界保持 Agent 专注、安全、高效；提供沙盒、执行环境、工具 |
| Testing & QA | 反馈循环 | 促进自主自纠正；orchestration logic 捕获错误并路由回模型 |
| Review & Deployment | 观察 Harness | 运行 hooks 阻止不当操作；observability 追踪 token 成本、延迟、Agent drift |
Vibe Coding vs Agentic Engineering 的真正区别
白皮书澄清：
“The transition is defined by how deliberately you configure and apply the harness.”
翻译：转变由如何有意识地配置和应用 harness定义。
| 方式 | Harness 配置 |
|---|---|
| Vibe Coding | 最小或隐式支架，仅瞄准快速实现 |
| Agentic Engineering | 清晰、广泛 harness 抽象，从第一个规划文档到生产监控引导 AI |
Harness 的影响可测量
Terminal Bench 2.0: - 团队将 coding Agent 从 Top 30 外移到 Top 5 - 仅改变 harness，没有模型变更
LangChain 研究: - 提高 coding Agent 13.7 分（相同基准） - 仅微调系统 prompt、tools、middleware（固定模型）
为什么这很重要？
白皮书给出最重要的日常版本：
“When an agent does something wrong, the first instinct is to blame the model. More often, the failure traces back to a missing tool, a vague rule, an absent guardrail, or a context window stuffed with noise. Most agent failures, examined honestly, are configuration failures.”
翻译：当 Agent 做错事时，第一个直觉是责怪模型。更多时候，失败追溯到缺失工具、模糊规则、缺失护栏、或塞满噪音的上下文窗口。诚实地检查，大多数 Agent 失败是配置失败。