这其实是一次 tenantId 联调 bug，暴露了 AI 项目最缺的不是模型，而是Harness前面没整理完的关于Harness Engineering 的文章，为啥整理这一篇是因为这让我意识到一个趋势正在形成：AI 开发正在从"写提示词"转向"构建评估系统"。
什么是 Harness？
•❌ 不是业务逻辑•✅ 是"包在系统外面的一层控制系统"
二、这个词的来源（非常关键）
“harness”本来是个很形象的词：马具（给马套上的控制装置）
👉 核心隐喻：
核心本质：让一个"有能力但不可控"的系统变得可控。
类比理解
类比 1：马具（Horse Harness）
Harness 的原意就是"马具"。
马很有能力，能跑能拉，但如果不加马具：
•你没法控制方向•你没法让它停下来•你没法让它拉车
马具 = 控制框架，让有能力但不可控的马，变成可控的生产力。
类比 2：赛车游戏的手柄
想象你在玩赛车游戏：
•Prompt Engineering = 你告诉 AI"往左拐"•Context Engineering = 你给 AI 看地图、车速、油量•Harness Engineering = 你给它一个手柄，让它能实际操作，还能看仪表盘知道自己开得怎么样
手柄 + 仪表盘 + 赛道规则 = Harness
类比 3：你熟悉的 JUnit
写 Java 的同学都知道 JUnit：
@Test
public void testAdd() {
assertEquals(4, calculator.add(2, 2));
}
JUnit 做了什么？
•控制测试的执行顺序•提供断言方法验证结果•收集测试结果生成报告
JUnit 就是一个 Test Harness。
一句话定义
Harness = 用来控制、驱动、约束、评估一个系统行为的外部执行框架
它不是业务逻辑本身，而是包在业务逻辑外面的一套控制系统。
二、为什么 AI 突然需要 Harness？
先理解 AI 和传统软件的区别
|
维度
|
传统软件
|
AI（LLM）
|
| --- | --- | --- |
| 确定性 |
同样的输入，永远同样的输出
|
同样的 prompt，可能不同结果
|
| 可预测性 |
bug 能复现
|
"幻觉"随机出现
|
| 验证方式 | assertEquals(expected, actual) |
输出是自然语言，难断言
|
| 调试方式 |
打断点、看堆栈
|
不知道它"怎么想的"
|
关键问题：AI 是个"黑盒概率系统"，有能力，但不可控。
2025 年底发生了什么？
AI 从"聊天工具"变成了"自主干活的工人"。
Cursor 的实验[1]：让 AI 自主写浏览器，5 个月生成 100 万+ 行代码，人类零手写代码。
Anthropic 的实验[2]：16 个 Claude 并行工作，2 周从零写出 C 编译器。
OpenClaw：7x24 小时自主运行的 AI，不需要人类一直盯着。
新问题出现了：
•AI 干到一半停了，下次怎么接上？•AI 说"我做完了"，怎么验证真的做完了？•怎么保证 AI 不"跑偏"，不乱改其他代码？•多个 AI 一起干活，怎么协作？
这些都不是 prompt 能解决的，需要 Harness。
三、AI Harness 的 6 个核心组件
一个完整的 AI Harness 包含以下 6 部分：
┌─────────────────────────────────────┐
│ AI Harness 架构 │
├─────────────────────────────────────┤
│ 1. 可读环境（Legible Environment） │
│ → AI 能读懂项目状态 │
├─────────────────────────────────────┤
│ 2. 测试数据集（Test Dataset） │
│ → 有标准答案才能评估 │
├─────────────────────────────────────┤
│ 3. 执行器（Executor） │
│ → 控制 AI 怎么运行 │
├─────────────────────────────────────┤
│ 4. 评估器（Evaluator） │
│ → 判断 AI 做得对不对 │
├─────────────────────────────────────┤
│ 5. 端到端验证（E2E Verification） │
│ → 防止 AI "假完成" │
├─────────────────────────────────────┤
│ 6. 工具设计（Tooling） │
│ → 给 AI 用什么工具 │
└─────────────────────────────────────┘
组件 1：可读环境（最重要但最容易被忽视）
场景：AI 干到一半停了（断电、超时、出错），下个 AI 怎么接手？
反面教材：
•项目里到处是 TODO、FIXME，不知道哪个是真的待办•进度散落在聊天记录、个人笔记、脑子里•新 AI 花了半小时才搞懂"现在做到哪了"
正确做法：写清楚进度文件
project/
├── AGENTS.md # 项目架构、技术栈、开发规范
├── features.json # 功能清单和完成状态
│ └── [{"name": "登录", "status": "done"}, ...]
├── progress.md # 当前进度、阻塞项、下一步
│ └── "卡在微信支付签名，需要测试密钥"
└── init.sh # 一键初始化环境
关键原则：每个新 AI 应该几分钟内读懂项目，而不是猜。
OpenAI 的实践证明[3]：结构化的进度跟踪文件，比复杂的记忆系统更有效。
组件 2：测试数据集
核心问题：怎么判断 AI 做得好不好？
不能靠"感觉"，需要有标准答案。
怎么做：
1.收集 50-100 个真实场景的输入输出对2.覆盖正常 case、边界 case、错误 case3.每次改 Prompt 或换模型，跑一遍看准确率
示例（客服意图识别）：
[
{"input": "这个太贵了", "expected": "价格异议"},
{"input": "能便宜点吗", "expected": "价格异议"},
{"input": "谢谢我先看看", "expected": "暂缓决策"},
{"input": "怎么退款", "expected": "售后问题"}
]
目的：把"感觉好不好"变成"指标好不好"（准确率 85% vs 92%）。
组件 3：执行器（Executor）
控制 AI 怎么运行：
•用哪个模型？（GPT-4 / Claude / DeepSeek）•温度参数多少？（0.2 稳定，0.8 有创意）•超时时间多长？•失败怎么重试？•要不要并行跑多个模型对比？
作用：让 AI 的执行过程可控、可复现。
组件 4：评估器（Evaluator）
AI 的输出怎么评分？
| 评估方式 | 适用场景 | 示例 | | --- | --- | --- | | 规则匹配 | 结构化输出 | JSON 字段存在、值在范围内 | | LLM 打分 | 主观质量 | 用 GPT-4 给回答打 1-10 分 | | 人工评审 | 复杂场景 | 抽样检查、关键路径 | | 混合评估 | 通用 | 规则先过滤，LLM 再评估 |
示例：
请评估以下 AI 回复：
问题："怎么重置密码？"
AI 回答："..."
请从以下维度评分（1-10）：
1. 准确性：步骤是否正确
2. 完整性：是否漏了关键步骤
3. 清晰度：用户能否看懂
组件 5：端到端验证（E2E）—— 防止"假完成"
最大的坑：AI 特别喜欢说"我做完了"，其实有 bug。
为什么单元测试不够：
•代码通过了测试，但功能不工作•实现了功能，但破坏了其他模块•API 能调通，但前端展示错了
怎么做：
| 项目类型 | 验证方式 | | --- | --- | | Web 应用 | Playwright 自动跑一遍用户流程 | | API 服务 | 集成测试：调接口 → 查数据库 → 验状态 | | 代码生成 | 编译 + 运行 + 测试通过 | | 数据处理 | 输出格式 + 关键字段非空 + 无重复 |
反馈循环：
AI 说完成 → 自动测试 → 发现 bug → 反馈给 AI → 修复 → 重新验证
这比人工检查快得多。
组件 6：工具设计——少即是多
Vercel 的真实案例[4]：
原来：给 AI 20 个精细设计的专用工具
•查询用户工具、查询订单工具、更新状态工具...
问题：AI 经常选错工具，切换开销大。
改进后：删掉 80%，只留 2 个通用工具
1.bash 命令 - 文件操作2.SQL 执行 - 数据库查询
结果：
•成功率：80% → 100%•速度：快 3.5 倍
为什么：模型对 bash、SQL 这类通用工具理解更深，不用猜"该用哪个工具"。
设计原则：
优先给 AI 通用工具（文件、bash、SQL），别搞复杂的专用工具链。
四、真实数据：优化 Harness 比换模型更有效
案例 1：Hashline[5]——只改格式，模型没变
问题：AI 改代码时经常定位错行。
解法：不改模型，只改文件格式——每行加哈希
# 传统格式
function hello() {
return "world";
}
# Hashline 格式
1:a3|function hello() {
2:f1| return "world";
3:0e|}
AI 通过哈希引用行（"替换 2:f1"），不用精确重现字符串。
结果：
•模型得分：6.7% → 68.3%（10 倍提升）•模型权重完全没变
案例 2：LangChain[6]——固定模型，只优化 Harness
条件：固定 GPT-5.2，只改进 Harness
改进：加了一个自动分析失败模式的工具
结果：
•分数：52.8% → 66.5%•排名：30 名 → 5 名
结论：
别急着买更贵的模型，先优化 Harness，ROI 更高。
五、给你的落地建议：5 步走
第一步：写 AGENTS.md
项目根目录放这个文件，内容包括：
•项目结构：目录怎么组织的•技术栈：用什么语言、框架、数据库•构建命令：怎么编译、怎么跑测试•常见坑：之前踩过什么坑、怎么规避
原则：每次 AI 犯错，就加一条规则防止再犯。
第二步：整理测试集
找 30-50 个真实场景的输入输出对：
•从生产日志里挑真实的•覆盖正常 case、边界 case、错误 case•存成 JSON，方便批量跑
第三步：加 E2E 验证
别让 AI 自己说"做完了"，让它证明做完了：
•Web 项目：用 Playwright 自动跑核心流程•API 项目：写集成测试•代码生成：必须能编译、能跑通测试
第四步：简化工具链
检查你给 AI 用的工具：
•超过 10 个？考虑合并•能用 bash/SQL 解决的，别搞专用工具•优先用模型熟悉的通用工具
第五步：建进度看板
用简单的 markdown 跟踪：
## 已完成 ✅
- [x] 用户登录接口
## 进行中 🚧
- [ ] 支付接口（卡在签名验证）
## 阻塞项 🛑
- 需要测试环境密钥
## 下一步 📋
1. 搞定签名
2. 写回调接口
相关阅读：
•Anthropic：用并行 Claude 团队构建 C 编译器[7]•Mitchell Hashimoto：Harness Engineering 概念提出[8]
References
[1] Cursor 的实验:*cursor.com/blog/scalin… 的实验:*www.anthropic.com/engineering… 的实践证明:*openai.com/index/harne… 的真实案例:*vercel.com/blog/we-rem… Claude 团队构建 C 编译器:*www.anthropic.com/engineering… Hashimoto：Harness Engineering 概念提出: mitchellh.com/writing/my-…
原文链接阅读体验更优
