什么是 Harness Engineering

概念

Harness Engineering 是在"智能体优先"（Agent-First）的世界中，让 AI 智能体可靠、长期、自主产出价值的工程方法论。形象的比喻是：大模型是一匹烈马，需要加上马具以及其他配套（Harness）才能驾驭住它，让它完成你想让它完成的任务。

核心公式：Agent = Model + Harness

• Model（模型）：提供智能，接收输入、输出文本
• Harness（运行框架）：除模型外的所有代码、配置和执行逻辑，让智能变得可用

"If you're not the model, you're the harness." — LangChain

Harness 不是某个工具或框架，而是一整套环境设计 + 意图明确 + 反馈闭环的工程体系。OpenAI 团队用 5 个月实验验证了这套方法：3 名工程师推动编码智能体产出约 100 万行代码、1500 个 PR，产品已上线且有真实用户——人类从未直接编写任何代码，估计只用了手工编写约 1/10 的时间。

传统软件工程有编译器、类型检查、单元测试——错了能报错。Agent 没有。规则写得对不对，只有跑起来才知道。AI 不听话时，你甚至不知道是哪条规则失效。写 Agent 配置时的核心痛点：

1. 没有编译器 — 规则不会自动报错，违规是"悄悄跑偏"
2. 没有运行时检查 — 制度有没有效，看执行结果才知道
3. 没有测试用例 — 行为对不对，只能人工观察
4. 规则越写越长 — 上下文爆炸，AI 被淹没
5. AI 不听话但无法定位 — 不知道哪条规则失效

这些问题的本质是：Agent 缺乏一套"防止走偏"的机制。 Harness Engineering 的本质就是填补这个空缺——设计环境、明确意图、构建闭环，让智能体在约束内自主、可靠、长期产出价值。它解决的不是"怎么写代码"的问题，而是"怎么让 AI 行为可控"的问题。

组成

Harness 包含六大核心组件：

这六个组件很像管理学中管理一个团队的要素——给信息（记忆与上下文）、给权限（工具系统）、定规矩（约束与规范）、做考核（反馈与优化）、搭组织（编排协作）、控风险（恢复机制）。

背后理念

工程师的角色从"编写代码"转变为三件事：

1. 设计环境 — 让智能体在约束内自主行动
2. 明确意图 — 把模糊想法变成不可被误解的结构化指令
3. 构建反馈回路 — 让错误可观测、可修正、可迭代

核心信念：约束带来速度，纪律体现在支撑结构上，而不是代码上。 上下文是稀缺资源，过多信息会导致智能体淹没或优化错误目标。Harness 的全部设计，都是在解决"如何让智能体在约束内自主、可靠、长期产出价值"这个问题。

给 AI Agent 一张地图，而不是一本 1000 页的说明书。

AI Agent 看不到的东西就不存在——存储在外部文档、聊天记录或人脑中的知识，对它而言等于不存在，必须显式编码到工作空间中才能被感知。

智能体在完成任务后，会自动审核自身的输出，发现问题则修复后重新审核，循环往复直到满意——这构成了 Harness 中最核心的反馈闭环。

与管理学的关系

Harness Engineering 的核心命题：构建一个由"AI 员工"组成的组织。

管理学解决的核心问题是：如何让一群能力有限、信息不完整、动机各异的个体，协同产出超过个体之和的成果。其中"动机各异"是最大变量——能力再强，不想做，什么都不会发生。

当员工变成 AI，"意愿问题"瞬间消失，取而代之的是更隐蔽的"理解问题"——规则写得对不对，只有跑起来才知道；错了不会报错，只会悄悄跑偏。AI 缺少人能领会言外之意、补全模糊指令、在规则未覆盖处做合理判断的能力，它理解的边界就是显式给它的东西。

这意味着管理学的重心发生了根本性转移：

问题变了，但管理学的框架没有变。四要素依然成立，只是每个要素的着力点发生了转移：

这个转移可以落地为三个实操步骤：

1. 给规则加可观测的校验点 — 把"回复要简洁"改为"回复不超过3句话"。人能理解"简洁"的弦外之音，AI 只能理解字面——消除模糊，就是消除跑偏
2. 设计最小测试用例 — 故意问已知答案的问题，验证 Agent 是否守规。这是对"规则是否被正确理解"的审计，不是对"AI 是否努力"的考核
3. 用错误日志迭代规则 — 每次违规记录并加补丁规则。AI 违规不是态度问题，是规则的 bug——修正表达，不是惩罚执行

三篇核心来源恰好覆盖了这个转移的三面：OpenAI 文章讲"怎么组织 AI 员工的生产关系"，LangChain 文章讲"怎么设计 AI 员工的生产力工具"，Darren 文章讲"怎么管理一群 AI 员工的组织运转"。合在一起，Harness Engineering 就是管理学的重塑——问题从"意愿"转向"理解"，但组织、制度、检查、迭代的四要素框架一以贯之。

最佳实践

1. 代码仓库作为记录系统

• AGENTS.md 仅作为目录（约 100 行），而非百科全书
• 知识库存放在结构化的 docs/ 目录中
• 采用渐进式披露：智能体从稳定切入点开始，按需探索

原因：上下文是稀缺资源，过多信息会导致智能体淹没或优化错误目标。

2. 架构护栏

通过硬约束保持代码一致性：

• 代码分层固定，依赖方向严格验证
• 自定义 linter 强制执行规则
• 文件大小限制、命名约定、可靠性要求

原则：约束带来速度，防止架构漂移。

3. 高吞吐量下的合并理念

• 尽量减少阻塞合并门
• PR 生命周期短，测试偶发失败通过重跑解决
• 纠错成本低，等待成本高

4. 熵与垃圾收集

智能体会复现代码库中已有的所有模式，包括不均衡的模式。应对措施：

• 将"黄金原则"编码到仓库中
• 定期运行后台任务扫描偏差、自动重构
• 技术债务小额高频偿还
• Rule GC：定期删除长期未触发的规则、合并重复规则、压缩长规则，保持配置永远精简

5. 给规则加可观测的校验点

把模糊规则改成 AI 执行后能直接检查结果的具体要求：

• ❌ "回复要简洁"
• ✅ "回复不超过3句话，每句不超过20字，结尾必须加数字编号"

AI 没做到时，能像"看编译错误"一样立刻发现。

6. 设计最小测试用例

像写单元测试一样，用固定问题测试 Agent 是否遵守规则：

testcases:
  - name: 不读文件不许修改
    input: 修改 app.py
    expect: 先读文件，再输出 diff

如果失败，直接加一条更硬的规则。

7. 用错误日志迭代规则

每次 AI 违反规则，像"程序 bug"一样记录，然后加"补丁规则"：

• AI 擅自创建 README → 加规则"不主动创建 README"
• AI 没读文件就改代码 → 加规则"修改前必须先输出'已读取[文件名]'"
• AI 回复太啰嗦 → 加规则"只保留核心操作步骤"

本质：用"人工反馈"替代"编译器报错"，把隐性规则变成显性约束。

实践体会

用 AI Agent 做了几件事之后，对 Harness Engineering 的理解从理论变成了体感。

第一件事：让 AI 开发一个基于 LangGraph 的内容生成系统。 快下班时给了需求规格，第二天上班发现已经做完了。这是 Harness 运转良好的例子——需求规格就是"约束与规范"，给得越清晰，AI 执行越高效。

第二件事：问 AI 如何自动把本地 Markdown 文章上传到知乎。 它直接开始开发——又是规划，又是审核，又是执行，非常规范。因为我告诉它要测试先行，所以它写了自动化测试，跑完后报告"所有测试都已通过"。我以为可以用了，一运行发现不行。再让它改，改完还是不行，反复多次仍未达到预期。后来我发现知乎本身就有"导入 Markdown"功能——正是我需要的。AI 按预设约束直接走上开发之路，但最佳方案不是开发，而是用一个已有功能。如果是人类，肯定会提醒一句："这个需求有替代方案，未必需要开发。"AI 缺少的正是这种领会言外之意的"灵性"。

第三件事：问 AI 如何自动把本地 Markdown 文章上传到微信公众号。 同样，它直接开始开发，生成了一大堆代码。还没完成，已经烧了我很多 token。

三件事合在一起，恰好对应了 Harness 的三个关键洞察：

1. 约束越清晰，执行越高效（第一件事——给对规格就能高效交付）
2. AI 看不到的东西就不存在（第二件事——缺少上下文导致走弯路）
3. 过程完美不等于结果正确（第二、三件事——需要兜底机制防止资源浪费）

AI 的好处是不知疲倦、百分百执行、按规章制度行事。但这恰恰是最大的陷阱——意愿没有问题，不代表理解没有问题。 过程越完美，理解偏差的后果越严重。

参考资料

• OpenAI：工程技术——在智能体优先的世界中利用 Codex（偏"软"：工程实践、团队协作、生产关系）
• LangChain：The Anatomy of an Agent Harness（偏"硬"：技术架构、组件设计、生产力工具）
• Darren：管了 31 个 AI 员工之后，我重新理解了管理学（偏"管理"：意愿→理解的转移、数字组织设计）