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

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

AI 写代码的速度已经超过了人类能"擦屁股"的速度。Harness Engineering，就是那根让烈马变战马的缰绳。

一、前言：当 AI 开始"飙车"

想象一下这个场景：

你雇了一个打字速度无限快、永远不喊累的实习生来写代码。听起来很美好对吧？但问题来了——

• 它 5 分钟写了 3000 行代码，但把数据库密码硬编码进了前端页面 🤦
• 它"很贴心地"重新发明了一遍你项目里已有的工具函数，还取了个不同的名字
• 它把原本清晰的微服务架构，悄悄改成了一坨意大利面条

AI 写代码的速度，远远超过了团队能控制系统复杂度的能力。

这不是段子。OpenAI 的 Codex 团队在五个月内用 AI 写了一百万行代码，三个工程师平均每天合并 3.5 个 PR，没有一行是人手写的。Anthropic 的 Claude Code 能连续工作数天构建完整应用。

当 AI 从"辅助工具"变成"核心劳动力"，软件工程的规则也得跟着变。

Harness Engineering，就是这套新规则的名字。

二、名词急救包——先扫盲再上路

在深入之前，我们先来一波"名词急救"。读技术文章最痛苦的事情，莫过于满屏英文术语看得人头大。这里用"人话"给你翻译一遍：

🐎 Harness Engineering（驾驭工程）

官方定义：设计一套系统，让 AI Agent 能可靠地完成复杂任务的工程方法论。

翻译：你有一匹跑得飞快的烈马（AI），Harness Engineering 就是给它装上缰绳、马鞍和导航仪，让它跑得快的同时，还能跑对方向、不踩坑。

Anthropic 官方定义："Agent Harness 是让模型能够作为 Agent 工作的系统：它处理输入、编排工具调用、返回结果。"

🧠 Context Engineering（上下文工程）

官方定义：为 AI 提供充分、结构化的上下文信息的工程实践。

翻译：给 AI 喂"正确的饲料"。你不能把一本 1000 页的书砸它脸上让它自己找答案，得给它一张 100 行的地图，让它按需查阅。

LangChain CEO Harrison Chase 的原话："Everything's context engineering."（一切皆是上下文工程。）

🎵 Vibe Coding（氛围编程）

翻译：凭感觉让 AI 写代码。你说"帮我做个网站"，然后 AI 就开始嗡嗡嗡地干活，你也不太管它怎么实现。

听起来很酷，但就像凭感觉开车不看导航——短途还行，长途必翻车。Harness Engineering 正是 Vibe Coding 的"理性升级版"。

🤖 Coding Agent（编码智能体）

人话翻译：不只是帮你补全代码的 AI，而是能自己读需求、写代码、跑测试、修 Bug、提交 PR 的"AI 程序员"。

代表选手：GitHub Copilot、Claude Code、OpenAI Codex、Cursor Agent 等。

📋 AGENTS.md（AI 工作手册）

人话翻译：放在项目根目录的一个 Markdown 文件，相当于给 AI 的"入职培训手册"。告诉它：项目怎么跑、代码风格是啥、哪些地方不能碰。

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

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

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

协议	设计者	一句话定位
MCP（Model Context Protocol）	Anthropic	让 AI'会用工具'——连数据库、调 API
A2A（Agent-to-Agent）	Google DeepMind	让 AI 之间'找帮手'——跨团队协作
ACP（Agent Communication Protocol）	IBM / BeeAI	让 AI 在'本地互通'——离线也能配合

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

💪 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 不行。

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

具体做法：

手段	说明
AGENTS.md	100 行的"入口地图"，指向详细文档
渐进式披露	不一次性喂所有信息，而是按需检索
CLI / API 优先	工具能力暴露为机器接口，而非 Web UI
结构化文档	用 JSON/YAML 替代自由格式的 Markdown

关键洞察：把 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 开发团队"：

Agent 角色	职责
Backlog Refiner	把粗略想法变成可执行的用户故事
Todo Orchestrator	消除歧义，准备编码卡片
Dev Crafter	实现功能，运行测试
Review Guard	检查实现质量
Reporter	总结已完成的工作

工程防御机制方面：

• 双层 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	A2A	ACP
核心功能	工具资源集成	多 Agent 协作	本地 Agent 通信
设计者	Anthropic	Google DeepMind	IBM / BeeAI
传输协议	HTTP/SSE, stdio	HTTP/gRPC	gRPC, ZeroMQ
典型场景	连数据库、调 API	跨云端多 Agent 分工	机器人、IoT、离线环境
云依赖	可选	强依赖	零依赖
延迟	< 50ms	100-300ms	200-500ms
安全策略	OAuth 2.0, mTLS	企业级签名	本地 ACL

怎么理解这三者的关系？

用一个类比：

• 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，就是这个系统的工程基础设施。

或者用一句话总结：

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