什么是 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 包含五个核心组件：

组件 作用 关键机制
文件系统 最基础的 Harness 原语 工作空间读取、中间输出持久化、多智能体协作界面；Git 增加版本控制和回滚能力
Bash + 代码执行 让模型自主解决问题的通用工具 模型可动态设计工具，不受预配置工具集限制；代码执行成为自主问题解决的默认策略
沙箱（Sandbox） 安全的代码执行环境 命令白名单、网络隔离、按需创建/用完即弃；预装运行时、包管理器、测试工具、浏览器
内存与搜索 跨会话持久化知识 + 获取实时知识 AGENTS.md 注入上下文记忆；Web Search / MCP 获取训练数据之外的新知识
上下文管理 对抗 Context Rot（上下文腐烂） Compaction（智能卸载总结）、Tool call offloading（大输出 offload 到文件）、Skills 渐进式披露

此外，Harness 还包括 System Prompts、Tools/Skills/MCP 及其描述、编排逻辑（子智能体生成、交接、模型路由）、确定性执行的钩子/中间件（压缩、延续、lint 检查）等。

背后理念

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

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

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

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

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

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

与管理学的关系

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

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

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

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

从 转向
意愿问题 理解问题
激励设计 信息架构
监督执行 设计规则
管理人的情绪 管理信息的流动
培训员工 设计记忆

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

管理要素 Harness 对应 转移后的重心
建立组织 Multi-Agent 架构：主Agent调度 + 子Agent专业分工 + 人设/技能/权限 从”选人用人”转向”定义角色边界”——AI 没有自我认知，角色必须显式声明
制定规章制度 Intent System + Rule Compiler：角色定义、行为原则、规则编译检查 从”约束人的越界冲动”转向”消除理解的模糊地带”——AI 不会故意违规，但会理解偏差
关键节点检查 Test Harness：每个规则配测试用例，AI 输出必须通过校验点 从”查人有没有偷懒”转向”查规则有没有被正确理解”——问题出在规则，不在执行者
反馈-调整-迭代闭环 Rule GC + 错误日志迭代：违规→记录→补丁规则→验证 从”纠正人的行为”转向”修正规则的表达”——每次违规都是规则的 bug，不是人的 bug

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

  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 回复太啰嗦 → 加规则”只保留核心操作步骤”

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

参考资料