Harness Engineering：给 AI 套上缰绳的工程学

目前已被 6 万+ 个 GitHub 开源项目采用，支持 Codex、Claude Code、Cursor、Copilot 等 25+ 种 AI 工具。由 Linux 基金会下属的 Agentic AI Foundation 维护。

🔌 MCP / ACP / A2A（三大 AI 协议）

这三个协议就像 AI 世界的"USB、蓝牙和 WiFi"，各管各的层：

后面有专门章节详细展开。

💪 Fitness Function（架构适应度函数）

翻译：给系统做"体检"的自动化测试。不是检查功能对不对，而是检查架构健不健康——比如"有没有人偷偷引入了循环依赖？"'延迟有没有超标？'

这个概念由 ThoughtWorks 在《演进式架构》一书中提出，现在被用于 AI Coding 环境中，充当系统的"防腐层"。

🏗️ Agent-aware System（AI 感知型系统）

翻译：以前的软件系统都是给人用的（Human-first），现在需要改造成 AI 也能理解、调用和验证的系统。就像以前的路只有人行道，现在还得加上自动驾驶车道。

三、Harness Engineering 到底是什么？

一个比喻说清楚

把 AI 大模型想象成一台超强马力的发动机：

• 🏎️ 裸跑（没有 Harness）：发动机直接放在地上，一踩油门轮子打滑，到处乱窜
• 🚗 有 Harness：发动机装进底盘，配上方向盘（上下文）、刹车（防御机制）、仪表盘（反馈回路），变成一辆可控的赛车

Harness Engineering 不是让 AI 变强，而是让 AI 的强变得可控。

为什么需要它？

LLM（大语言模型）有一个本质特性：无状态。每次推理都是独立的函数调用 f(context) → output。

但真实的软件开发任务是有状态的：需要记住"我做了什么"、'为什么这么做'、'下一步该做什么'。

Anthropic 打了一个精妙的比喻：'这就像一个软件项目由工程师轮班完成，每个新工程师到来时都不记得上一班发生了什么。'

这种矛盾会导致两种典型翻车姿势：

1. "一把梭"模式：Agent 试图一次性完成所有功能，context 耗尽后留下一堆烂摊子
2. "假完工"模式：Agent 看到一点进展就宣布"搞定了！"，实际上核心功能连影子都没有

Harness Engineering 就是在无状态的 LLM 和有状态的任务之间搭桥。 就像操作系统让无状态的 CPU 运行有状态的程序一样。

硬数据说话

LangChain 做了一个关键实验：用同一个模型（GPT-5.2-Codex），只改了 Harness 设计，在 Terminal Bench 2.0 基准测试上的得分从 52.8% 飙升到 66.5%——提升了 26%。

而把模型从 GPT-5.2 升级到 GPT-5.3？只提升了 0.7%。

结论：当模型能力达到一定水平后，Harness 设计才是效果的主要瓶颈。

四、三大核心能力：读得懂、管得住、学得会

Harness Engineering 的核心可以用三个词概括：可读性、防御、反馈。

Harness Engineering 核心模型 系统可读性 - 让 AI 看得懂 防御机制 - 让 AI 走不偏 反馈回路 - 让 AI 学得快

📖 可读性：让 AI "看得懂"你的系统

问题：很多项目的知识分散在代码注释、Confluence 文档、Slack 聊天记录和某位老员工的脑子里。人类可以靠"问一嘴"来获取，AI 不行。

解法：把隐性知识显性化，让代码仓库变成一张"可导航的知识地图"。

具体做法：

关键洞察：把 100 页文档全塞给 AI，效果还不如给它一个 100 行的地图让它自己查。因为 Transformer 的注意力机制对中间内容会"打瞌睡"（Lost in the middle 现象）。

🛡️ 防御机制：收敛 AI 的"行动空间"

问题：AI 生成能力太强了，如果不设边界，它会"好心办坏事"——重复造轮子、绕过模块边界、引入隐式依赖……系统慢慢就腐化了。

解法：把工程约束变成系统的"物理定律"。AI 可以自由探索，但不能违反规则。

防御机制层次 静态分析 Linter / 类型检查 自动化测试 单元 / 集成 / E2E 架构验证 Fitness Function Git Hooks 提交前 / 推送前拦截

在传统开发中，这些工具是"质量保障手段"；在 AI Coding 环境中，它们变成了系统边界的一部分。

类比：高速公路的护栏不是用来惩罚司机的，而是让所有车都在安全范围内行驶。Harness 的防御机制就是 AI 编程的"护栏"。

🔄 反馈回路：让 AI 在犯错中成长

问题：AI 不会天然地验证自己的工作。它的训练数据主要是"写代码"（GitHub commits），而不是"写代码→测试→修复"的完整循环。

解法：构建从开发到部署的全链路反馈系统。

反馈回路闭环 AI 写代码 本地测试 Lint + 单元测试 CI 验证 集成测试 + 架构检查 线上监控 日志 + 指标

当这些信号能被统一收集并反馈给 AI 时，软件开发就从线性流程变成了循环系统。AI 不再是"写完就走"，而是在反馈驱动下持续调整。

五、四大厂商实战：看看大佬们怎么"驯马"

案例 1：OpenAI —— 给 AI 一张地图，而不是一本百科全书

场景：Codex 团队要用 AI 维护一个 100 万行的代码库，但 context window 只能装约 20 万 tokens。

核心策略：渐进式披露（Progressive Disclosure）

OpenAI: 渐进式披露

是

否

AGENTS.md 100 行入口地图

AI 需要更多信息?

按需检索 设计文档/架构图

开始编码

自动偏差修复 后台定期扫描

关键做法：

• AGENTS.md 当目录：100 行的稳定入口，指向完整知识库
• 偏好"无聊"的技术：因为 AI 对常见技术建模更准确
• 约束条件而非具体实现：告诉 AI'必须在边界解析数据'，但不规定怎么实现
• 自动偏差修复：后台任务定期扫描架构偏移，自动开 PR 修复

为什么有效？每次按需检索的内容都落在 Transformer 注意力的"高效区域"（前 20% 和后 20%），而不是被埋在中间的"注意力黑洞"里。

案例 2：Anthropic —— 每次上班先"读日志"

场景：让 Claude 连续工作数天构建完整 Web 应用，但每个新会话都"失忆"。

核心策略：Initializer + Coding Agent 两阶段系统

Anthropic: 两阶段系统

阶段 2: 编码 Agent-每个会话

下个会话

读取状态 功能列表+git log+进度

只做一件事 实现一个功能

验证 端到端测试

记录状态 git commit+更新进度

阶段 1: 初始化 Agent

生成功能需求 200+ 个 pass/fail 标准

创建 progress.txt

写 init.sh 脚本

初始 git commit

精妙之处：每个编码会话本质上是一个纯函数：

f(功能列表 + git history + progress notes) → 完成一个功能 + 更新记录 

Agent 不需要"记住"任何事，因为所有信息都在输入中。写错了？下个会话用 git revert 回滚。

这就像医院的"交接班日志"——每个护士上班第一件事就是读上一班的记录，而不是靠前一个人的记忆。

案例 3：LangChain —— 用"硬规则"替代"软劝说"

场景：Agent 写完代码，自己看了一遍觉得"嗯，没问题"，就停了。但代码根本跑不通。

问题根源：LLM 的训练数据主要是"写代码"，不是"写代码→测试→修复"的完整循环。你在 prompt 里写"记得测试"，它可能直接忽略。

核心策略：Middleware 强制验证循环

LangChain: 强制验证循环

是

未通过

通过

触发

Agent 启动

LocalContextMiddleware 自动注入环境信息

Agent 编码

Agent 想退出?

PreCompletionChecklist 测试跑了吗？通过了吗？

允许退出

LoopDetection 编辑同文件 5 次则提示换思路

效果：同一个模型（GPT-5.2-Codex），只改 Harness，分数从 52.8% → 66.5%，提升 26%。

比喻：Prompt 里写"别忘了测试"就像在考场门口贴"禁止作弊"的标语——有人看，有人不看。Middleware 是直接装监控摄像头——想绕都绕不过去。

案例 4：Stripe Minions —— 从 Slack 消息到合并 PR

场景：Stripe 每周通过 AI 合并 1000+ 个 PR，零行人工代码。

核心策略：一键式端到端 Agent

Stripe Minions 流程

Slack/CLI 工程师发起任务

隔离沙箱 10 秒预热启动

Toolshed 400+ 内部工具-MCP

一次性生成代码

本地 Lint 5 秒内完成

CI 测试 最多 2 轮自动修复

生成 PR

人类 Review

关键设计：

• 隔离执行：每个 Agent 运行在独立的 devbox 中，与生产环境和互联网隔离
• 400+ 工具：通过 MCP 协议集成文档、工单、构建状态、代码搜索
• 一击式执行：不搞多轮对话，定义好任务直接执行到底

为什么选择"一键式"而非"对话式"？因为对于定义清晰的任务，单次执行在延迟和成本上都碾压复杂的多轮对话。

案例 5：Routa.js —— 用看板管理 AI 团队

场景：多个不同的 AI Agent（Claude Code、GitHub Copilot、Augment 等）需要在同一个代码库中协作。

核心策略：Kanban 驱动的多 Agent 协调

Routa 不用一个全能 Agent，而是配备了一支"AI 开发团队"：

工程防御机制方面：

• 双层 Git Hooks：Pre-commit 快速检查 + Pre-push 结构化错误反馈
• Lint 策略降级：部分规则降为警告，确保多 Agent 协作不卡壳
• 自动化看板：Issue 进入时自动补充上下文，过期 Issue 自动清理

这套系统自己也是用 AI Agent 开发的——"用 AI 管 AI"的递归之美。

六、协议江湖：MCP vs ACP vs A2A

当 AI Agent 开始协作，它们需要一套"通信语言"。目前业界形成了三大协议，它们不是互相替代的关系，而是处于不同的系统层级。

分层架构

AI Agent 协议栈

A2A - Agent-to-Agent 多 Agent 跨域协作层 by Google

ACP - Agent Communication Protocol 本地 Agent 通信层 by IBM

MCP - Model Context Protocol 工具/资源集成层 by Anthropic

详细对比

怎么理解这三者的关系？

用一个类比：

• MCP 是"手"——让 AI 能抓东西（调用工具、访问数据）
• ACP 是"对讲机"——让同一个办公室的 AI 互相喊话
• A2A 是"电话会议系统"——让不同公司的 AI 开联席会议

使用建议

选择路径：1️⃣ 先稳定 MCP → 让 Agent 能用工具 2️⃣ 再评估 ACP 或 A2A → 按需引入多 Agent 协作 3️⃣ 最后考虑多 Agent 编排 → 如 Routa 的 Kanban 模式 

IEEE 已经启动了 Agentic AI 协议工作组，未来这三者可能走向融合。MCP 插件市场年增长 217%，生态建设势头最猛。

七、未来展望：人和 AI 的"双循环"

从 Human-first 到 Agent-aware

传统软件系统是给人用的：代码仓库的结构、工具的 UI、CI/CD 的操作方式，都假设使用者是人类。

当 AI 入场后，这些假设失效了。AI 不会"问同事"、不会"凭经验"、不会"读空气"。

工程系统需要从 Human-first 进化为 Agent-aware——不是取消对人的支持，而是同时支持人和 AI。

工程系统进化

AI 入场

Human-first 为人类设计: GUI/口头约定/经验传承

Agent-aware 人机共存: CLI+API/AGENTS.md/自动化验证

双循环开发模式

未来的软件开发将运行在两个循环中：

软件开发的双循环

AI 循环：怎么实现

人类循环：为什么做

输入约束

结果反馈

代码生成

业务目标

产品决策

制定规则

测试验证

自动修复

• 人类循环关注"为什么做"——业务目标、产品价值、战略方向
• AI 循环关注"怎么实现"——代码生成、测试、修复、验证

人类不再逐行写代码，而是设计系统、制定规则、管理循环。

换句话说：人类负责建造杠杆，AI 负责放大杠杆。

三个值得关注的趋势

趋势 1：模型和 Harness 协同演化

直觉上你可能觉得"模型越强，Harness 越简单"。但现实恰恰相反——OpenAI 和 LangChain 的 Harness 复杂度一直在增加。未来可能出现"Harness-optimized"的专用模型，就像 RISC 架构简化指令集让编译器承担更多优化一样。

趋势 2：从压缩到架构

早期的 Context Engineering 关注怎么"压缩"信息。但 OpenAI 和 Hightouch 的实践表明：问题不是"怎么压"，而是"怎么组织"。未来的 Harness 不会更简单，而会更结构化——就像 Kubernetes 不是让容器变简单，而是让容器可管理。

趋势 3：Harness 成为持久竞争壁垒

即使模型变得完美，Harness 积累的领域知识、工作流模式、安全策略不会过时。这就像云服务商的价值不在"服务器更快"，而在"让基础设施可管理、可扩展、可靠"。

八、结语

让我们回到最初的那匹烈马。

传统软件系统的核心是确定性：给定相同输入，总能得到相同输出。工程师通过测试、类型系统、静态分析把所有可能的执行路径控制住。

但当执行层从 CPU 变成 LLM，系统变成了概率性的。Agent 在第 50 步会做什么，取决于前 49 步动态构建的 context。这种不确定性无法通过"写更好的代码"消除——因为它是 LLM 的本质特征。

Harness Engineering 的核心价值，就是用工程方法让概率性系统可靠运行。 不是消除不确定性，而是限制边界：

• OpenAI 用地图 + 按需检索，限制 AI 看到的信息空间
• Anthropic 用功能列表 + git commits，把大任务拆成 200+ 个可验证小步骤
• LangChain 用强制验证循环，让 AI 无法跳过测试
• Stripe 用隔离沙箱 + 一键执行，把执行路径限定在安全范围内

AI Coding 的未来，不是完全自动化的软件开发，而是人与 AI 共同运行的软件工程系统。

Harness Engineering，就是这个系统的工程基础设施。

或者用一句话总结：

好的缰绳不会让马跑得更慢，只会让它跑得更稳、更远。 🐎

📌 参考资料 Phodal -《从实践到原则：为 AI Agent 构建的 Harness Engineering 落地与探索》 Python_cocola -《Harness Engineering 工程化教程》 Anthropic - Effective harnesses for long-running agents Anthropic - Building effective agents OpenAI - AGENTS.md Specification Stripe - Minions: one-shot, end-to-end coding agents Phodal - Routa: Multi-Agent Collaboration Platform ThoughtWorks - Fitness function-driven development