Harness Engineering：2026 年 AI 编程的核心战场

Harness Engineering：2026 年 AI 编程的核心战场

写在前面

2026 年春天，AI 编程领域出了一件挺有意思的事——各家模型你追我赶，GPT-5.4 来了，Opus 4.6 来了，Gemini 3.1 也来了，但很多一线工程师发现，换个更强的模型对实际产出的提升，远不如把模型外面那一圈东西搞好来得猛。

这"外面那一圈东西"，现在有个正式名字了：Harness Engineering（驾驭工程）。

---

一、Harness 到底是什么

先说定义。2026 年 2 月 5 日，HashiCorp 联合创始人 Mitchell Hashimoto 在一篇博客里首次明确提出了这个术语。六天后 OpenAI 在他们那篇"百万行代码实验报告"里正式采用，紧接着 Martin Fowler（没错，写《重构》那位）也跟进撰文。

核心公式只有一行：

Agent = Model + Harness

• Model：大模型本身——GPT、Claude、Gemini、DeepSeek，负责理解和推理
• Harness：模型之外的一切——系统提示词、工具定义、编辑格式、上下文管理、错误处理、重试逻辑、安全边界、状态持久化、任务编排……

Martin Fowler 给了个更精炼的拆法：

组成	作用	时机
Guides（前馈控制）	在 Agent 行动之前引导它做对	事前
Sensors（反馈控制）	在 Agent 行动之后帮它自我纠正	事后

打个比方：模型是一匹千里马，Harness 是缰绳、马鞍和马蹄铁。缰绳不是为了把马勒住不让它跑，而是让它在正确的赛道上全力冲刺。

---

二、为什么说"瓶颈不在模型"

这个判断不是拍脑袋得出的，有一组实验数据很有说服力。

实验一：Can Bölük 的编辑工具对比

一个叫 Can Bölük 的开发者做了个大规模测试：16 个模型、3 种编辑格式、每种 540 个任务。他把编辑工具格式从 str_replace 换成自创的 hashline，模型完全没动——

Grok Code Fast 1 的成功率从 6.7% 飙到 68.3%。翻了十倍。

他自己总结得很精辟："你在怪飞行员技术差，其实是起落架坏了。"

实验二：LangChain 的排名跃升

LangChain 团队底层模型一个参数都没改，纯靠优化外部驾驭环境（文档结构、验证回路、追踪系统），在 Terminal Bench 2.0 上的分数从 52.8% 升到 66.5%，全球排名从第 30 直接跳到第 5。

实验三：40% 上下文阈值

Dex Horthy 发现了一个很实际的问题：168K token 的上下文窗口，用到大约 40% 的时候 Agent 输出质量就开始明显下降。他管这叫"Dumb Zone"——0~40% 是 Smart Zone，推理清晰、工具调用准确；超过 40% 就开始出幻觉、兜圈子、格式混乱。

这说明什么？上下文不是越多越好，管理上下文的手段（也就是 Harness 的一部分）才是关键。

---

三、三代范式演进：怎么走到今天的

回顾一下这几年 AI 工程方法论的演变脉络，会发现有一条清晰的递进关系：

范式	时间	核心问题	比喻
Prompt Engineering	2023~2024	怎么把话说清楚	对马喊话的技巧
Context Engineering	2025	怎么给 AI 喂信息	给马看的地图
Harness Engineering	2026~	怎么让 Agent 可靠地工作	给马造一条高速公路，配上护栏、限速牌和加油站

三者不是替代关系，是嵌套包含关系：Prompt ⊂ Context ⊂ Harness。

• Prompt 解决表达——让模型听懂你想干什么
• Context 解决信息——让模型在合适的时机拿到正确且必要的信息
• Harness 解决执行——让整个系统在长链路任务中持续正确、偏差能纠正、故障能恢复

---

四、六层架构：从"定义边界"到"兜底恢复"

业内目前比较被认可的是一套六层体系框架，层层递进，形成完整闭环：

L1：信息边界层

解决什么问题：Agent 该知道什么、不该知道什么。

相当于给新员工一份岗位说明书。不是把公司所有文档都塞给它，而是告诉它"你负责什么、相关资料在哪里、不用管的别看"。

代表实践：

• AGENTS.md 控制在 50~100 行，写成"地图"而非"百科全书"
• 采用"你想做什么 → 去哪里看"的面向任务结构
• Mitchell Hashimoto 的做法——AGENTS.md 里每一行对应一个历史 Agent 失败案例

L2：工具系统层

解决什么问题：Agent 怎么跟外部世界交互。

工具的选拔、调用时机、结果的提炼与反馈。Anthropic 的实践数据很有参考价值：通过"Tool Search Tool"按需发现工具，仅加载当前任务实际需要的工具，节省约 85% 的上下文 Token，准确率提升明显（Opus 4 从 49% 到 74%，Opus 4.5 从 79.5% 到 88.1%）。

L3：执行编排层

解决什么问题：多步骤任务怎么串起来。

让 Agent 像人一样走完"理解目标 → 判断信息 → 分析 → 生成 → 检查"的完整轨道，而不是一股脑全干完。

Anthropic 的 Planner → Generator → Evaluator 三 Agent 编排，Stripe 的混合状态机（确定性节点 + Agent 节点），都是这一层的典型实现。

L4：记忆与状态层

解决什么问题：长任务中间结果怎么管。

独立管理当前任务状态、中间产物和长期记忆，防止上下文腐化。Anthropic 的做法很有启发性——不压缩上下文，而是启动全新 Agent + 结构化交接文档恢复状态（类似重启进程解决内存泄漏）。

L5：评估与观测层

解决什么问题：Agent 怎么知道自己做对了没有。

建立独立于生成过程的验证机制。OpenAI 的做法是把可观测性栈暴露给 Agent 自己——Agent 能自己抓 DOM 快照、截图、查日志，而不是等人来检查。

L6：约束、校验与恢复层

解决什么问题：出错了怎么办。

预设规则拦截错误，失败时提供重试或回滚。OpenAI 的经验是"自定义 Linter + 结构测试强制执行"，他们内部有句话："If it cannot be enforced mechanically, agents will deviate."

六层的核心价值：从 L1（定义边界）到 L6（兜底恢复）形成完整闭环。建议从 L1 和 L6 入手——L1 决定 Agent 知道该干什么，L6 决定它搞砸了能不能拉回来，这两层投入产出比最高。

---

五、一线团队怎么做的

OpenAI：3 人 5 月 100 万行零手写代码

这是 2026 年初最震撼的案例。核心经验：

1. 地图式文档：AGENTS.md 只当目录，详细规则按需加载
2. 机械化约束：自定义 Linter 报错自带修复方法（"❌ 什么错了 → ✅ 怎么改 → 📖 文档在哪"）
3. 可观测性给 Agent 看：Agent 能自己抓 DOM 快照、截图、查日志
4. 主动熵管理：后台 Agent 定期扫描，清理速度跟上生成速度
5. 仓库即事实源：写在 Slack / Wiki 里的知识对 Agent 等于不存在

Anthropic：GAN 式三智能体 + Context Resets

• Generator 和 Evaluator 独立，避免"自我评价偏差"
• 不压缩上下文，直接启动新 Agent + 结构化交接文档
• 关键洞察："Harness 中的每个组件都编码了一个关于模型做不到什么的假设——随着模型变强，应定期简化 Harness"

Stripe：500 个工具 + 300 万测试的 CI 反馈

• 近 500 个工具集中管理，通过 Toolshed MCP 按任务筛选子集
• 混合状态机架构（确定性节点 + Agent 节点）
• 300 万+ 测试的 CI 反馈作为验证闭环

---

六、Harness 与 Framework 的关系

很多人会问：Harness 和 LangChain、AutoGen、CrewAI 这些 Agent 框架是什么关系？

答案是：Harness 不是 Framework 的替代品，而是位于它们之上的一层。

┌─────────────────────────────────────────────────┐
│  Harness Layer（驾驭层）                          │
│  约束 · 反馈循环 · 上下文工程 · 熵管理 · 生命周期  │
├─────────────────────────────────────────────────┤
│  Agent Frameworks（LangGraph / AutoGen / CrewAI） │
│  智能体定义 · 消息路由 · 任务生命周期               │
├─────────────────────────────────────────────────┤
│  SDK / API（OpenAI / Anthropic / Gemini）         │
│  模型调用 · 工具注册 · 流式输出                     │
├─────────────────────────────────────────────────┤
│  Foundation Model（GPT / Claude / Gemini）        │
└─────────────────────────────────────────────────┘

一个观察是：模型正在吸收框架大约 80% 的功能。但剩下那 20%——持久化、确定性重放、成本控制、可观测性、错误恢复——恰好是驾驭层的价值所在。

---

七、Agent 常见翻车姿势

Anthropic 工程师总结了三种典型失败模式，做过 AI 编程的大概都中过：

1. 试图一步到位：Agent 想在一个会话里把所有功能做完，上下文窗口耗尽，留下一堆半成品
2. 过早宣布胜利：项目后期看到已有进展就直接宣布任务完成，实际还差一大截
3. 过早标记功能完成：代码写完就标 done，没做端到端测试。单元测试通过不代表功能可用

还有一个格外危险的特性：Agent 非常擅长模式复制——包括坏模式。不加约束的 Agent 会以惊人速度积累技术债务。

---

八、在 CodeBuddy IDE 中的最佳实践

CodeBuddy IDE 本身就是一个比较完整的 Harness 载体。它的 Craft Agent 模式、MCP 协议支持、Skills 系统、Working Memory 机制，天然适合落地 Harness Engineering。具体怎么做：

8.1 Phase 1：信息边界——先把"地图"画好

创建项目级 AGENTS.md

在项目根目录或 .codebuddy/ 下创建，控制在 50~100 行：

# codebuddy.md

## 项目简介
xxx 前端项目，基于 React + TypeScript，
负责 xx 策略模板、套餐管理、WebProtection UI。

## 快速导航
| 你想做什么 | 去哪里看 |
|-----------|---------| 
| 了解模块结构 | docs/architecture/overview.md |
| 了解组件规范 | docs/conventions/components.md |
| 了解 API 接口 | docs/reference/api-spec.yaml |
| 了解当前迭代 | docs/plans/current-sprint.md |

## 硬性规则
1. 组件文件不超过 300 行
2. 使用 TDesign 组件库，不引入其他 UI 框架
3. 接口调用统一走 apiClient，禁止裸 fetch
4. 新增页面必须有对应的 E2E 测试
5. 国际化 key 统一管理，不在组件内硬编码

配置 CodeBuddy 的 Working Memory

CodeBuddy 的 .codebuddy/memory/ 目录就是 L4（记忆与状态层）的天然实现。日常开发中把关键决策、踩坑记录写进去，Agent 下次启动时会自动读取，不用每次重新交代上下文。

8.2 Phase 2：工具与约束——用 MCP 和 Linter 锁住边界

MCP 集成

CodeBuddy 原生支持 MCP。根据项目需要配置 MCP Server：

// ~/.codebuddy/mcp.json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    },
    "github": {
      "command": "npx",
      "args": ["@anthropic/github-mcp@latest"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

这样 Craft Agent 在执行任务时可以直接调用 Playwright 做端到端验证、通过 GitHub MCP 创建 Issue 和 PR。

Linter 规则即 Prompt

这是 Harness Engineering 投入产出比最高的实践之一。核心思路：每条 Linter 错误信息本身就是一个自动触发的 Prompt。

// eslint-rules/no-raw-fetch.js
module.exports = {
  meta: {
    messages: {
      noRawFetch: [
        '❌ 禁止直接使用 fetch()。',
        '✅ FIX: 使用统一的 API Client：',
        '   import { apiClient } from "@/lib/api-client";',
        '   const data = await apiClient.get("/endpoint");',
        '📖 See: docs/conventions/api-calls.md'
      ].join('\n')
    }
  }
};

Agent 看到这种报错，不需要任何额外提示就能自己改对。

8.3 Phase 3：验证闭环——让 Agent 自己检查自己

利用 Craft 模式的 Plan → Act 循环

CodeBuddy 的 Plan 模式天然实现了"规划与执行分离"。复杂功能先用 Plan 模式审批方案，确认后再切到 Craft 模式执行。

PostToolUse 自动验证

利用 CodeBuddy 的 Hook 机制（或在 codebuddy.md 中写明），要求 Agent 每次编辑代码后自动运行：

1. TypeScript 类型检查（tsc --noEmit）
2. Lint 检查
3. 相关单元测试

如果失败，Agent 会拿着错误信息自动修复，不用人介入。

Skills 按需加载

CodeBuddy 的 Skills 系统本质上就是 Anthropic 所说的"延迟加载层"——会话开始时不占上下文，只在被触发时才注入。合理组织项目 Skills（放在 .codebuddy/skills/ 下），可以有效控制上下文利用率，避开那个 40% 的"Dumb Zone"。

8.4 持续维护检查清单

□ codebuddy.md 保持 50~100 行，每次 Agent 犯新错就更新
□ Working Memory 记录关键架构决策和踩坑点
□ MCP Server 按需配置，不贪多
□ Linter 规则的错误信息带修复建议
□ 复杂功能先 Plan 再 Craft
□ 定期清理 .codebuddy/memory/ 中过期的日志
□ 每两周回顾一次 codebuddy.md，删掉不再需要的规则

---

九、成熟度自评

最后给一个成熟度参考，方便对号入座：

阶段	特征	你在干什么
Level 0	直接给 prompt，无结构化约束	手动写代码 + 偶尔用 AI
Level 1	codebuddy.md + 基础 Linter	主要写代码，AI 辅助
Level 2	CI 集成 + 自动化测试 + 进度追踪	规划 + 审查为主
Level 3	多 Agent 分工 + 分层上下文 + 持久化记忆	环境设计 + 管理为主
Level 4	无人值守并行化 + 自动化熵管理 + 自修复	架构师 + 质量把关者

大多数团队目前在 Level 1 到 Level 2 之间。不用着急上 Level 4——从一份好的 AGENTS.md 和一条带修复建议的 Linter 规则开始，比什么都不做强一百倍。

---

总结

Harness Engineering 的核心洞察其实就一句话：

模型决定了系统的上限，Harness 决定了系统的底线。

2026 年的竞争格局，两者缺一不可。但从投入产出比看，目前 Harness 的杠杆率远高于模型升级。与其等下一个更强的模型，不如现在就把项目的 AGENTS.md 写好、把 Linter 规则配上、把验证闭环搭起来。

工程师的角色正在从"代码编写者"转变为"环境建筑师"——从构建产品，转向构建能够构建产品的工厂。

这不是一个多遥远的未来。它已经在发生了。