你可能已经用 AI 写过代码、生成过文章，但你有没有想过：随着 AI 越来越能干，"让 AI 好好干活"这件事本身，已经成了一门独立的工程学问？
从一个真实故事说起
2025 年底，OpenAI 内部做了一个大胆的实验：他们用自研的 Codex 智能体，在几乎零人工码字的情况下，构建了一款完整的内部产品。这个产品包含了应用逻辑、单元测试、CI 配置、API 文档，甚至内部工具，总代码量超过百万行。
参与的工程师没有在写代码——他们在设计让 AI 能正确写代码的环境。
这就是 Harness Engineering（驾驭工程） 的雏形。
什么是 Harness Engineering？
如果你用 ChatGPT 生成过代码，你大概有过这种体验：AI 给出的代码看起来挺对，但跑起来就是不行；再追问几轮，它绕来绕去，最后改得面目全非。
这不是 AI 不够聪明，而是你没有给它一个好的"工作环境"。
Harness Engineering 就是系统地解决这个问题的工程实践。它的核心主张是：
模型的能力只是上限，真正的输出质量由你为它搭建的"驾驭框架（Harness）"决定。
Martin Fowler（《重构》作者，ThoughtWorks 首席科学家）在 2026 年初给出了一个简洁的定义：
Harness Engineering 是让 AI 智能体保持正轨的工具和实践的总称。
它既不是 Prompt Engineering（你问什么），也不是 Context Engineering（你给它看什么），而是运行 AI 的整套操作框架。
Harness 是什么？用类比来理解
想象你是一位技术 Leader，手下来了一位新员工——聪明绝顶、精通各种语言和框架，但完全不了解你们公司的代码规范、部署流程、业务逻辑。
你会怎么做？
你会给他：
- 一份仓库规范文档（告诉他什么能做什么不能做）
- 一套CI 流水线（让他提交代码后自动跑测试，出错有反馈）
- 代码评审机制（他的输出经过人工或自动审核）
- 可观测性工具（你能随时看他在做什么）
这套组合，就是一个 AI Harness。只不过那位新员工，是 AI 智能体。
Harness Engineering 的五大核心支柱
1. 🧭 上下文工程（Context Engineering）
AI 模型的质量，很大程度上取决于它"看到"了什么。
上下文工程是指：精心设计喂给模型的信息，确保它在每次任务中都能获得最相关、最精确、最够用的上下文，而不是随手粘贴的一大坨代码。
常见手段包括：
- RAG（检索增强生成）：不把整个代码库扔给 AI，而是检索出最相关的几个文件
- Session 摘要：将长对话历史压缩成结构化摘要，而不是原样保留
AGENTS.md文件：在仓库根目录放一个机器可读的说明文件，告诉 AI 这个仓库的约定、命令、架构规则
# AGENTS.md（示例片段）
## 项目约定
- 所有 API 函数必须有 JSDoc 注释
- 数据库操作统一使用 /src/db/client.ts 中的封装
- 禁止直接调用 fetch，必须使用 src/utils/request.ts
## 常用命令
- 运行测试：`npm test`
- 构建：`npm run build`
- 代码检查：`npm run lint`
2. 🔄 反馈回路（Feedback Loops）
没有反馈的 AI 就是"甩锅"——它生成完就完了，对不对它不知道。
好的 Harness 会让 AI 拥有自我验证和自我修正的能力：
- AI 修改代码 → 自动运行测试 → 测试失败 → AI 读取错误日志 → AI 再次修改 → 直到测试通过
- 这个循环不需要人介入，AI 在一个受控的沙盒里"自己折腾自己"
这是 AI Coding Agent 和传统 AI 代码补全最本质的区别：它不只是生成，它还能迭代。
3. 🚧 护栏与约束（Guardrails & Constraints）
AI 很强大，也很危险——尤其是当它被允许执行 shell 命令、写数据库、发 HTTP 请求的时候。
Harness 需要明确定义 AI 的权限边界：
- 它可以读哪些文件，不能读哪些
- 它能不能联网
- 它执行的命令需不需要人工确认
- 哪些操作是不可逆的，必须有额外审批
这不只是安全问题，也是工程质量问题：你得让 AI 在一个可重复、可预期的范围内工作，而不是每次都让它"自由发挥"。
4. 👁️ 可观测性（Observability）
你用 LLM 写了个功能，上线了，出 bug 了——你怎么知道是 AI 的问题，还是你的 Prompt 的问题，还是 Harness 的设计问题？
可观测性是 Harness Engineering 中经常被忽视的一环，包括：
- 记录每次 AI 的输入输出（不只是最终代码，还有中间推理步骤）
- 追踪 Token 消耗（防止上下文爆炸）
- 监控 Agent 行为序列（它依次调用了哪些工具？哪一步出错了？）
没有可观测性，你就是在"黑盒驾驶"。
5. 🏗️ 架构约束（Architectural Constraints）
这是最高层的设计考量：你的代码架构和工程规范，要从一开始就考虑"AI 能不能理解它、能不能安全地修改它"。
OpenAI 的实践显示：模块化、关注点分离、明确的接口定义，不仅对人类友好，对 AI 智能体同样关键。一个边界清晰的架构，让 AI 改动一个模块时不容易"连累"其他部分。
一个典型的 AI 工程师工作日：对比
| 传统工程师工作日 | Harness Engineer 工作日 |
|---|---|
| 写代码实现功能 | 设计 AGENTS.md，定义 AI 的工作规范 |
| 手动跑测试 | 搭建 AI 自动测试-修复的反馈回路 |
| Code Review | 审查 AI 的行为日志，优化 Harness |
| 排查 Bug | 分析 AI 智能体失败的步骤，改进约束 |
| 写文档 | 把架构意图写成机器可读的约束规则 |
"我已经在用 Cursor / Claude Code 了，这和我有关系吗？"
有关系，而且很大。
你可能已经发现：同样一个需求，有人用 AI 写出来的代码干净、可维护，有人拿到的是一坨能跑但没法看的屎山。
区别不在于他们用了哪个 AI，而在于他们为 AI 准备了什么：
- 有没有在仓库里放架构说明？
- 有没有让 AI 在改完代码之后自动跑测试？
- 有没有明确告诉 AI 哪些文件不能动？
- 有没有把"业务不变量"变成代码里的断言，让 AI 自己能验证？
这些都是 Harness Engineering 的日常实践，只不过现在很多人在无意识地做——而做得好的人，效率远超做得糟的人。
相关开源项目
如果你想深入实践，这些开源项目值得关注：
🤖 AI Agent 框架
| 项目 | 简介 | GitHub |
|---|---|---|
| OpenHands (原 OpenDevin) | 全功能开源 AI 软件工程师框架，支持多种 Agent 策略，内置浏览器/终端/代码执行环境 | All-Hands-AI/OpenHands |
| AutoGPT | 最早的自主 AI Agent，支持任务分解、工具调用、记忆管理 | Significant-Gravitas/AutoGPT |
| Claude Code | Anthropic 出品的终端 AI 编码助手，天然强调仓库上下文和 CLAUDE.md 约束文件 | 商业产品，社区有大量实践分享 |
📊 评测与基准
| 项目 | 简介 | GitHub |
|---|---|---|
| SWE-bench | 用真实 GitHub Issue 评测 AI 修 Bug 能力的标准基准，已成行业事实标准 | princeton-nlp/SWE-bench |
| AgentBench | 综合评测 AI Agent 在多种真实任务中表现的基准套件 | THUDM/AgentBench |
🔧 工具与基础设施
| 项目 | 简介 | GitHub |
|---|---|---|
| LangGraph | 基于图结构的 Agent 编排框架，擅长构建有状态、多步骤的 AI 工作流 | langchain-ai/langgraph |
| AgentOps | AI Agent 的可观测性平台，记录每次 LLM 调用、工具使用、费用开销 | AgentOps-AI/agentops |
| Guardrails AI | 为 LLM 输出添加验证、重试、格式约束的开源库 | guardrails-ai/guardrails |
📦 DevOps 侧的 Harness
| 项目 | 简介 | GitHub |
|---|---|---|
| Harness Open Source | CI/CD + 代码托管 + 制品仓库的一体化开发者平台，是"Harness"这个名字最早的来源之一 | harness/gitness |
我的理解：Harness Engineering 是"AI 时代的架构设计"
在我们熟悉的工程世界里，好的架构师不写最多代码，但他设计的系统让其他人（和 AI）能高效、正确地工作。
Harness Engineering 把这个逻辑推进了一步：
你的工程设计，不仅要让人类程序员看懂，还要让 AI 智能体能理解、能遵守、能验证。
这意味着：
- 注释不只是给人看的，是给 AI 的上下文
- 测试不只是验证代码，是 AI 自我修正的反馈信号
- 架构文档不只是方便 onboarding，是 AI 的行为约束规范
这个转变还在早期，争议也不少——Martin Fowler 本人就指出，目前的 Harness Engineering 实践缺乏足够的验证机制，很多"成功案例"可能存在幸存者偏差。
但方向是清晰的：下一代高效工程师，不只是会用 AI，而是会为 AI 搭建高质量的工作环境。
延伸阅读
- Martin Fowler: Harness Engineering - 概念提出者的原始论述
- OpenAI: How we built our first Codex product - OpenAI 实践报告
- SWE-bench Leaderboard - 各 AI 智能体在真实软件工程任务的评测排名
shareAI-lab/learn-claude-code- 专注于 Harness Engineering 实践的开源学习仓库
写于 2026 年 3 月 | 本文使用 AI 辅助研究，Harness 由人工设计与审核
