AI Harness Engineering 是什么？

AI Harness Engineering（AI Harness 工程） 是 2026 年 AI Agent（智能体）领域兴起的一个新概念。简单来说：

它研究的不是如何让模型更聪明，而是如何让 AI 更可靠地工作。

如果说：

Prompt Engineering（提示词工程）关注「怎么问」
Context Engineering（上下文工程）关注「给 AI 什么信息」
Harness Engineering（Harness 工程）关注「如何搭建整个运行环境，让 AI 持续稳定完成任务」 ([TechTarget][1])

一个直观比喻

很多文章都使用同一个比喻：

大模型（GPT、Claude、Gemini）= 马
Harness（缰绳、马具）= 控制系统

马本身很强大，但如果没有缰绳：

会跑偏
会失控
会犯错
会忘记目标

Harness 的作用就是：

限制行为
提供工具
验证结果
记录状态
出错恢复

让 AI 从一个「会聊天的模型」变成一个「能干活的系统」。 ([Harness Engineering Academy][2])

一个经典公式

很多 Harness Engineering 文章都在强调：

Agent = Model + Harness

实际项目里，Harness 往往比模型本身更重要。 ([amux.io][4])

Harness 通常包含哪些部分？

1. Context 管理

给 AI 正确的信息。例如：项目代码、API 文档、数据库结构、历史对话、任务做到哪一步了哪些文件改过、哪些测试失败过

但这里有一个反直觉但极其重要的教训：知识不是越多越好。塞给 Agent 的信息越多，它的注意力就越分散，性能反而越差。如何组织知识，比拥有多少知识更重要。后面会重点讲这件事。

不再是一次性塞给 AI 几万字的背景资料，而是采用“渐进式展开”。Harness 系统会根据 AI 当前的任务，动态筛选并提供精准的项目架构决策、代码规范（例如专门写给 AI 看的 AGENTS.md 文件），屏蔽无关信息，避免 AI 被信息噪音干扰。

2. Tool Calling

Agent 光有大脑没用，它需要手来干活。在编程场景里，工具包括：读写文件、执行 Shell 命令、浏览器控制、API 调用、Git 操作。

3. 验证

验证结果，这是 Harness 最关键的一环：AI 永远不能自己宣布“任务完成”。

它生成的代码或方案必须通过 Harness 设置的“硬门槛”——比如自定义的 Linter（代码检查工具）、严格的单元测试或结构化验证脚本。只有跑通了测试，闭环才算完成。例如：

4. 权限

安全约束。AI 必须在隔离的沙盒中执行操作，防止其越权或破坏真实环境。

例如：

禁止删除生产数据库
禁止直接发布
禁止修改敏感配置

5. 可观测性

给 Agent 一双眼 ，Agent 需要”看到”当前环境的状态。

编程场景的观察：

git diff：看看改了什么
错误日志：出了什么问题
测试结果：通过了没
Lint 报告：代码质量如何
浏览器截图：UI 长什么样

Agent 不仅能写代码，还能自己测性能、看日志、改 bug、再测一遍。

他们甚至让 Agent 接入了 Chrome DevTools，可以截图、操作 DOM、复现 bug。Agent 成了一个不需要睡觉的 QA 工程师。

6. 熵管理与防腐化

在 AI 长期运行的项目中，文档和代码很容易脱节。Harness 工程会设计定期的“清洁任务”，利用小型 AI 智能体或脚本自动校验文档一致性、清理无效信息，防止系统随着时间推移陷入混乱。

为什么突然火起来？

因为大家发现：

模型能力已经很强，但 Agent 依然经常翻车。

常见现象：

写代码写一半忘了目标
修改 A 又把 B 搞坏
测试没跑就说完成
调错工具
死循环

这些问题很多不是模型能力不足，而是缺少良好的运行框架。 ([Harness Engineering][3])

因此行业关注点逐渐变化：

2023 → Prompt Engineering
2024~2025 → Context Engineering
2026 → Harness Engineering

([metavert.io][6])

对 Java 工程师的意义

未来 AI 工程师不只是写 Prompt，而是设计：

Agent 工作流
工具链
验证机制
状态管理
安全控制

这就是 Harness Engineering 的核心。

Harness Engineering 怎么做？

实操建议：今天就可以开始的 Harness Engineering

看完了理论，来点实操。无论你用的是 Claude Code、Codex 还是 Cursor，以下原则都适用：

给你的 Agent 一张地图，而不是一本书

好的 AGENTS.md / .cursorrules / CLAUDE.md

1. 让一切对 Agent 可读

把设计决策写进代码仓库，不要只放在 Slack/飞书里
把隐性知识显性化——如果某个模块有陷阱，写在那个模块的 README 里
错误信息要写给 Agent 看：不只是”Error”，而是”Error: XXX happened because YYY, fix by doing ZZZ”

2. 把规则变成代码，而不是文档

// 好：Lint 规则自动强制执行
// 错误信息本身就是给 Agent 的修复指导
"Service layer cannot import from UI components. 
 Move shared types to types/ directory."
 
<!-- 坏：文档里写一条"请不要在 Service 层引入 UI 组件" -->
<!-- 三个月后没人记得，Agent 也不会主动去查 -->

3. 给 Agent 自我验证的能力

让它能跑测试
让它能看日志
让它能截图检查 UI
让它能对比修改前后的 diff

4. 管好权限边界

敏感操作需要确认
每个任务在隔离环境中运行
定义清楚什么能做、什么不能做

为什么上下文喂越多，Agent 反而越蠢？

Smart Zone ：0 - ~40% ，推理聚焦、工具调用准确、代码质量高
Dumb Zone ：超过 ~40% ，幻觉增多、兜圈子、格式混乱、代码变差

Anthropic 也遇到过类似问题，他们称之为“上下文焦虑”。Sonnet 4.5 在上下文快填满时会变得犹豫，甚至倾向于提前收工，即使任务还没完成。只做压缩不够，他们后来直接采用 context resets：清空上下文窗口，但通过结构化交接文档保留关键状态。

这里的目标不是给 Agent 塞更多信息，而是让它尽量停留在干净、相关的上下文里。一线团队做“渐进式披露”和“分层管理”，底层原因就在这里。上下文越多不等于越聪明，很多时候只是噪声越来越多。

怎么写好AGENTS.md

大模型的本质是发散的。 它的上下文不连贯、是有限的，不像我们人类可以持续积累记忆。所以你一定要给它足够的约束，它才能构建有效的、大规模的项目。

对人类团队来说，约束是束缚；但对 Agent 来说，约束是杠杆。

知识地图 > 百科全书（渐进式披露）

这里有一个极其重要的教训，来自 OpenAI 团队的血泪经验——

错误做法：搞一个巨大的 AGENTS.md，把所有规则都塞进去。

“我们尝试了’一个大型 AGENTS.md’方法。可想而知，这是一次失败的尝试。” —— OpenAI Codex 团队

为什么巨大的规则文件会失败？三个原因：

信息爆炸 = 信息为零。 当一切都"重要"时，一切都不重要了。就像你妈给你发了一条 3000 字的微信叮嘱出门注意事项——你不会看完的。
会过时腐烂：一本大手册会变成"陈旧规则的坟场"。谁来更新？没人。
无法验证：你怎么知道里面哪些规则还有效？不知道。

实验表明，CLAUDE.md 如果超过 100 到 200 行，性能就会变差。

正确做法是把知识文件做成一张地图，而不是百科全书：

CLAUDE.md（~100行，只是一个"目录"）
├── ARCHITECTURE.md（系统架构概览）
├── docs/
│   ├── design-docs/（设计文档）
│   ├── exec-plans/（执行计划）
│   ├── product-specs/（产品规格）
│   ├── FRONTEND.md
│   ├── SECURITY.md
│   └── ...

CLAUDE.md 告诉 Agent："你需要的信息在哪里，自己去找。" Agent 从一个小而稳定的切入点出发，按需深入，而不是一上来就被信息洪水淹没。

一个关键技巧：容易被找到的 MD 文档一定要非常精简、摘要化；非常详细的信息，应该直接指向那个详细文档里的具体行数。 绝对不能重复，重复的信息会互相矛盾、互相干扰。