Harness Engineering：给 AI 套上缰绳的工程学（通俗易懂）
🐴 Harness Engineering：给 AI 套上缰绳的工程学
AI 写代码的速度已经超过了人类能"擦屁股"的速度。Harness Engineering，就是那根让烈马变战马的缰绳。
目录
- 🐴 Harness Engineering：给 AI 套上缰绳的工程学
一、前言：当 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 打了一个精妙的比喻：“这就像一个软件项目由工程师轮班完成，每个新工程师到来时都不记得上一班发生了什么。”
这种矛盾会导致两种典型翻车姿势：
- "一把梭"模式：Agent 试图一次性完成所有功能，context 耗尽后留下一堆烂摊子
- "假完工"模式：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，就是这个系统的工程基础设施。
或者用一句话总结：
好的缰绳不会让马跑得更慢，只会让它跑得更稳、更远。 🐎
📌 参考资料Phodal -《从实践到原则:为 AI Agent 构建的 Harness Engineering 落地与探索》Python_cocola -《Harness Engineering 工程化教程》Anthropic - Effective harnesses for long-running agentsAnthropic - Building effective agentsOpenAI - AGENTS.md SpecificationStripe - Minions: one-shot, end-to-end coding agentsPhodal - Routa: Multi-Agent Collaboration PlatformThoughtWorks - Fitness function-driven development
📝 本文基于多篇技术博客和官方文档整理撰写，如有引用请注明出处。
