夜雨聆风你有没有遇到过这种情况？
你精心写了一段Prompt，测试了十几次，终于让它在某几个case上表现完美。然后，换了一个名字、换了一个场景，AI又开始犯迷糊了。
或者，你把项目文档全部塞进Context，以为AI这下总能理解全貌了。结果它还是在关键节点"失忆"，忘了约定好的代码规范。
更离谱的是，你让它写完代码后必须跑测试，它答应了，但转头就忘了这件事。
这不是AI不够聪明。这是AI的工作方式和你想象的不一样。
2026年，一个叫Harness Engineering的概念开始在AI工程圈流行。它解决的核心问题很简单：怎么让AI从"可能做对"变成"必须做对"。
📚 一、问题的根源：AI是概率性的，但工程是确定性的
让我们先正视一个问题：AI模型不是代码编译器。
你写一段Java代码，只要语法正确，编译器就会100%按预期编译。这是确定性的。
但AI模型不一样。同样的输入，可能每次输出都略有不同。这是概率性的。
概率性在聊天场景里问题不大。用户问天气，AI偶尔多说或少说一个词，无所谓。
但当你让AI去操作代码仓库时，问题就大了：
你让它"每次修改后跑测试"，它可能跑，可能忘 你让它"遵循项目规范"，它可能在第3轮遵守，在第30轮忘掉 你让它"不要修改未请求的功能"，它可能"顺手优化"了隔壁模块
这不是AI的错。这是概率系统的本质：它不保证任何事情。
从42%到78%的秘密
Anthropic做过一个实验：用同一个模型、同样的提示词，唯一的变量是运行环境。
结果让人震惊：编程基准测试成绩从42%跃升到78%。
模型没变。提示词没变。变的只有运行环境。
这个"运行环境"，就是Harness。
📚 二、什么是Harness？
Harness这个词，原意是马具——缰绳、鞍具、护目镜那套东西。
它解决的是同一件事：把一个强大但难以控制的东西，变成可控的工具。
对于AI来说，Harness就是包裹在模型外面的那一整套控制系统：
状态管理 工具执行 反馈循环 验证机制 权限控制
这些都不是模型本身。它们是让模型变成Agent的那层外壳。
三代演进：不是在替代，是在升级
三代不是替代关系，而是层层包含：好的Harness内部依然需要精心设计的Context和Prompt。
📚 三、核心思路：约束换自主
这是理解Harness最重要的一句话：规矩越明确，AI能独立做的事越多。
听起来反直觉，对吧？
传统的思路是：我想让AI做某件事，所以我写一段Prompt，描述清楚。
但Prompt是软约束——AI可以选择听，也可以选择忽略。
Harness的思路是：我不需要AI"选择"听我的。我让不听变得不可能。
举几个例子：
不是告诉AI"不要忘记跑测试" → 而是在CI/CD流水线里设置强制门禁，测试不通过就阻止合并
不是告诉AI"遵循MVC架构" → 而是用自定义Linter自动检测架构违规，违规代码直接报错
不是告诉AI"不要删除生产数据库" → 而是在权限系统里把DROP DATABASE设为deny规则，AI连看都看不到这个选项
确定性层叠概率性
这才是Harness的精髓：用确定性系统包裹概率性模型。
AI负责"想"和"写"，确定性系统负责"验"和"挡"。
📚 四、Harness的六个关键组件
1. Hooks：生命周期拦截器
Hooks是挂在Agent执行流程关键节点上的钩子。
拿Claude Code来说，它提供了18+个生命周期事件：
PreToolUse工具执行前拦截，可以验证、拒绝或修改 PostToolUse工具执行后处理，比如自动格式化 StopAgent完成回复前触发，可以验证任务是否真正完成
Hooks支持四种处理方式：Shell脚本、Webhook、AI判断、子Agent。
应用场景：你发现AI总是忘记在提交前运行lint检查。解决方案不是写更长的Prompt，而是在PreToolUse挂一个Hook，强制检查git commit前是否执行了lint。
2. 权限系统：声明式边界
用allow/deny/ask三种规则声明Agent的行为边界：
- deny：绝对禁止，无论AI多"想"做
- allow：正常执行
- ask：需要人类确认
关键设计：deny规则优先级最高，无法被任何Hook或AI行为覆盖。
应用场景：禁止AI直接git push到main分支，禁止删除非白名单文件，禁止访问特定环境变量。
3. 配置层级：多层治理
Managed层（组织级） ↓Project层（项目级） ↓User层（个人级）高优先级覆盖低优先级。组织可以设定不可覆盖的安全底线，项目维护者可以设定团队规范，开发者可以保留个人偏好。
应用场景：公司层面规定所有项目的AI工具都不能执行rm -rf /；某个安全敏感项目额外禁止网络访问；开发者个人可以设置偏好的代码格式化规则。
4. 沙箱：操作系统级隔离
Agent只能访问白名单中的文件路径和网络域名。
这是OS级别的强制执行——Agent甚至不知道这些限制存在，自然也无法绕过。
应用场景：限制AI只能操作当前项目目录，无法访问公司内网数据库，无法对外发起网络请求。
5. MCP（Model Context Protocol）：外部能力标准化接入
MCP是一个标准协议，让AI可以安全地连接外部服务——数据库、GitHub、监控工具、Slack等。
类比来说，它就像软件工程的USB接口：统一的协议，让不同模型和不同服务可以自由互联。
应用场景：让AI可以直接查询生产数据库状态（只读），可以调用内部API，可以把错误日志发送到Slack。
6. 规则文件与技能系统：上下文注入
CLAUDE.md、.claude/rules/*.md提供项目级和路径级的指令注入。
自定义Skill封装领域知识，按需加载到上下文中。
重要区分：这是Harness中"概率性引导"的部分——不是强制执行，但能显著提高AI遵循意图的概率。
应用场景：在CLAUDE.md里写清楚项目技术栈和代码规范，在rules里定义具体的命名规范和架构约束。
📚 五、行业实践：三种典型架构
Anthropic的三Agent模式
Anthropic在C编译器项目中实践了一套受GAN启发的架构：
- Planner：负责把简单需求扩展成详细规格，关注宏观设计
- Generator：按Sprint实现功能，编码前先与Evaluator签订"合同"
- Evaluator：独立验证环节，用Playwright真的去点击页面、查API
关键发现：让Evaluator变严格，比让Generator学会自我批评容易得多。
来源说明：此架构来自Anthropic官方工程博客（2026年3月），不同来源对此有不同命名和解读，此处采用小团队实践视角。
Stripe的高吞吐模式
Stripe的AI编程系统每周合并1300+个无人值守PR。
他们的经验：
每个AI只配备精心筛选的工具子集（约500个MCP工具中的部分） CI最多跑两轮，不允许无限重试 仓库是AI唯一的知识来源
来源说明：此数据来自Stripe Engineering博客。
OpenAI的长任务模式
OpenAI团队做了一个极端实验：3人团队、5个月、完全禁止手写代码。
最终产出：100万行代码，约1500个PR，人均每天3.5个。
他们发现：当AI卡住时，正确的问题不是"怎么让它更努力"，而是"它缺什么能力？怎么让这个能力可被强制执行？"
来源说明：此实验来自OpenAI官方Harness Engineering博文（2026年2月）。
📚 六、实战：构建你的人机协作开发流程
结合上面的理论，这里分享一个四步人机协作开发流程的设计思路。
第一步：建立项目上下文（Inform）
创建一个CLAUDE.md文件，让AI知道项目的"入职培训手册"：
# 项目上下文## 技术栈- 后端：Go 1.21 + Gin框架- 数据库：PostgreSQL 15- 部署：Docker + K8s## 代码规范- 遵循Uber Go代码规范- 所有公共函数必须有文档注释- 错误必须使用errors.Wrap包装## 项目结构- cmd/: 应用入口- internal/: 内部包- pkg/: 可复用的包- api/: API定义和proto文件
第二步：设置防御边界（Constrain）
在.claude/rules/下创建规则文件，设定AI的"行为红线"：
# .claude/rules/00-governance.mdc# 决策优先级（强制）1. 正确性 > 2. 可回滚性 > 3. 可测试性 > 4. 可观测性 > 5. 性能 > 6. 代码美观# 变更边界- 未被明确请求的功能不得引入- 不"顺手优化"无关代码- 保持改动最小化- 不引入新依赖，除非明确必要# 危险操作必须确认- 删除文件需要用户确认- git push需要用户确认- 修改配置文件需要用户确认
第三步：构建验证闭环（Verify）
建立多层验证体系，确保AI的产出必须经过质量门禁：
# Makefileverify:@golangci-lint run ./...@go test ./... -race@go build ./...verify-full: verify@./scripts/golden-test.sh
关键原则：验证必须是确定性的。AI不能绕过验证，更不能自己判断自己是否通过。
第四步：实现自动纠正（Correct）
当验证失败时，AI应该进入修复循环：
while (测试未通过):分析失败原因制定修复方案执行修复重新验证如果超过3次尝试仍未通过，报告给用户
核心逻辑：不是让AI"更努力"，而是让它在每一次失败中学习规则。
📚 七、为什么说这是范式转换？
回顾软件工程的历史，有几次重大范式转换：
瀑布模型 → 敏捷开发 单体架构 → 微服务架构 现在：人工编码 → Harness Engineering
每次转换的核心都是同一件事：把人类的精力从"执行"转移到"设计"。
敏捷让开发者不用事无巨细规划，转向快速迭代；微服务让开发者不用在同一个代码库里纠缠，转向独立部署；Harness Engineering让开发者不用手写每一行代码，转向设计让AI稳定产出的系统。
这不是说代码不重要了。代码依然重要，只是编写代码的方式在变。
📚 八、给工程师的建议
如果你今天想开始实践Harness Engineering，这里有三条建议：
1. 从痛点出发不要一开始就设计完美的Harness系统。先列出AI最常犯的错误，从解决这些问题开始。
2. 从硬约束开始先把那些"绝对不能出错"的事情用确定性系统锁死：危险操作禁止、必须验证才能合并、敏感数据禁止访问。
3. 持续迭代每次AI犯了一个新错误，把它转化为一条规则或测试。你的Harness会随着使用越来越强大。
结语：AI模型决定了它"能做什么"，Harness决定了它"稳定做什么"。在未来几年里，真正区分不同团队能力的，可能不是他们用了什么模型，而是他们的Harness设计得有多好。
这是软件工程的新边疆。