Harness Engineering 是一种让 AI Agent 可靠完成复杂任务的工程方法论。针对 LLM 无状态特性与软件开发有状态需求之间的矛盾，通过提升系统可读性、建立防御机制和反馈回路，实现对 AI 生成代码的管控。文章介绍了 AGENTS.md、Context Engineering 等概念，并分析了 OpenAI、Anthropic、LangChain 等厂商的实战案例及 MCP、A2A、ACP 协议差异，指出未来开发将进入人机双循环模式。
AI 写代码的速度已经超过了人类能"擦屁股"的速度。Harness Engineering，就是那根让烈马变战马的缰绳。
想象一下这个场景：
你雇了一个打字速度无限快、永远不喊累的实习生来写代码。听起来很美好对吧？但问题来了——
AI 写代码的速度，远远超过了团队能控制系统复杂度的能力。
这不是段子。OpenAI 的 Codex 团队在五个月内用 AI 写了一百万行代码，三个工程师平均每天合并 3.5 个 PR，没有一行是人手写的。Anthropic 的 Claude Code 能连续工作数天构建完整应用。
当 AI 从"辅助工具"变成"核心劳动力"，软件工程的规则也得跟着变。
Harness Engineering，就是这套新规则的名字。
在深入之前，我们先来一波"名词急救"。读技术文章最痛苦的事情，莫过于满屏英文术语看得人头大。这里用"人话"给你翻译一遍：
官方定义：设计一套系统，让 AI Agent 能可靠地完成复杂任务的工程方法论。
翻译：你有一匹跑得飞快的烈马（AI），Harness Engineering 就是给它装上缰绳、马鞍和导航仪，让它跑得快的同时，还能跑对方向、不踩坑。
Anthropic 官方定义："Agent Harness 是让模型能够作为 Agent 工作的系统：它处理输入、编排工具调用、返回结果。"
官方定义：为 AI 提供充分、结构化的上下文信息的工程实践。
翻译：给 AI 喂"正确的饲料"。你不能把一本 1000 页的书砸它脸上让它自己找答案，得给它一张 100 行的地图，让它按需查阅。
LangChain CEO Harrison Chase 的原话："Everything's context engineering."（一切皆是上下文工程。）
翻译：凭感觉让 AI 写代码。你说"帮我做个网站"，然后 AI 就开始嗡嗡嗡地干活，你也不太管它怎么实现。
听起来很酷，但就像凭感觉开车不看导航——短途还行，长途必翻车。Harness Engineering 正是 Vibe Coding 的"理性升级版"。
人话翻译：不只是帮你补全代码的 AI，而是能自己读需求、写代码、跑测试、修 Bug、提交 PR 的"AI 程序员"。
代表选手：GitHub Copilot、Claude Code、OpenAI Codex、Cursor Agent 等。
人话翻译：放在项目根目录的一个 Markdown 文件，相当于给 AI 的"入职培训手册"。告诉它：项目怎么跑、代码风格是啥、哪些地方不能碰。
目前已被 6 万+ 个 GitHub 开源项目采用，支持 Codex、Claude Code、Cursor、Copilot 等 25+ 种 AI 工具。由 Linux 基金会下属的 Agentic AI Foundation 维护。
这三个协议就像 AI 世界的"USB、蓝牙和 WiFi"，各管各的层：
| 协议 | 设计者 | 一句话定位 |
|---|---|---|
| MCP（Model Context Protocol） | Anthropic | 让 AI'会用工具'——连数据库、调 API |
| A2A（Agent-to-Agent） | Google DeepMind | 让 AI 之间'找帮手'——跨团队协作 |
| ACP（Agent Communication Protocol） | IBM / BeeAI | 让 AI 在'本地互通'——离线也能配合 |
后面有专门章节详细展开。
翻译：给系统做"体检"的自动化测试。不是检查功能对不对，而是检查架构健不健康——比如"有没有人偷偷引入了循环依赖？"'延迟有没有超标？'
这个概念由 ThoughtWorks 在《演进式架构》一书中提出，现在被用于 AI Coding 环境中，充当系统的"防腐层"。
翻译：以前的软件系统都是给人用的（Human-first），现在需要改造成 AI 也能理解、调用和验证的系统。就像以前的路只有人行道，现在还得加上自动驾驶车道。
把 AI 大模型想象成一台超强马力的发动机：
Harness Engineering 不是让 AI 变强，而是让 AI 的强变得可控。
LLM（大语言模型）有一个本质特性：无状态。每次推理都是独立的函数调用 f(context) → output。
但真实的软件开发任务是有状态的：需要记住"我做了什么"、'为什么这么做'、'下一步该做什么'。
Anthropic 打了一个精妙的比喻：'这就像一个软件项目由工程师轮班完成，每个新工程师到来时都不记得上一班发生了什么。'
这种矛盾会导致两种典型翻车姿势：
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 学得快
问题：很多项目的知识分散在代码注释、Confluence 文档、Slack 聊天记录和某位老员工的脑子里。人类可以靠"问一嘴"来获取，AI 不行。
解法：把隐性知识显性化，让代码仓库变成一张"可导航的知识地图"。
具体做法：
| 手段 | 说明 |
|---|---|
| AGENTS.md | 100 行的"入口地图"，指向详细文档 |
| 渐进式披露 | 不一次性喂所有信息，而是按需检索 |
| CLI / API 优先 | 工具能力暴露为机器接口，而非 Web UI |
| 结构化文档 | 用 JSON/YAML 替代自由格式的 Markdown |
关键洞察：把 100 页文档全塞给 AI，效果还不如给它一个 100 行的地图让它自己查。因为 Transformer 的注意力机制对中间内容会"打瞌睡"（Lost in the middle 现象）。
问题：AI 生成能力太强了，如果不设边界，它会"好心办坏事"——重复造轮子、绕过模块边界、引入隐式依赖……系统慢慢就腐化了。
解法：把工程约束变成系统的"物理定律"。AI 可以自由探索，但不能违反规则。
防御机制层次
静态分析 Linter / 类型检查
自动化测试 单元 / 集成 / E2E
架构验证 Fitness Function
Git Hooks 提交前 / 推送前拦截
在传统开发中，这些工具是"质量保障手段"；在 AI Coding 环境中，它们变成了系统边界的一部分。
类比：高速公路的护栏不是用来惩罚司机的，而是让所有车都在安全范围内行驶。Harness 的防御机制就是 AI 编程的"护栏"。
问题：AI 不会天然地验证自己的工作。它的训练数据主要是"写代码"（GitHub commits），而不是"写代码→测试→修复"的完整循环。
解法：构建从开发到部署的全链路反馈系统。
反馈回路闭环
AI 写代码
本地测试 Lint + 单元测试
CI 验证 集成测试 + 架构检查
线上监控 日志 + 指标
当这些信号能被统一收集并反馈给 AI 时，软件开发就从线性流程变成了循环系统。AI 不再是"写完就走"，而是在反馈驱动下持续调整。
场景：Codex 团队要用 AI 维护一个 100 万行的代码库，但 context window 只能装约 20 万 tokens。
核心策略：渐进式披露（Progressive Disclosure）
OpenAI: 渐进式披露
是 -> AGENTS.md 100 行入口地图
否 -> AI 需要更多信息？
-> 按需检索 设计文档/架构图
-> 开始编码
-> 自动偏差修复 后台定期扫描
关键做法：
为什么有效？每次按需检索的内容都落在 Transformer 注意力的"高效区域"（前 20% 和后 20%），而不是被埋在中间的"注意力黑洞"里。
场景：让 Claude 连续工作数天构建完整 Web 应用，但每个新会话都"失忆"。
核心策略：Initializer + Coding Agent 两阶段系统
阶段 1: 初始化 Agent
生成功能需求 200+ 个 pass/fail 标准
创建 progress.txt
写 init.sh 脚本
初始 git commit
阶段 2: 编码 Agent - 每个会话
读取状态 功能列表+git log+进度
只做一件事 实现一个功能
验证 端到端测试
记录状态 git commit+更新进度
下个会话
精妙之处：每个编码会话本质上是一个纯函数：
f(功能列表 + git history + progress notes) → 完成一个功能 + 更新记录
Agent 不需要"记住"任何事，因为所有信息都在输入中。写错了？下个会话用 git revert 回滚。
这就像医院的"交接班日志"——每个护士上班第一件事就是读上一班的记录，而不是靠前一个人的记忆。
场景：Agent 写完代码，自己看了一遍觉得"嗯，没问题"，就停了。但代码根本跑不通。
问题根源：LLM 的训练数据主要是"写代码"，不是"写代码→测试→修复"的完整循环。你在 prompt 里写"记得测试"，它可能直接忽略。
核心策略：Middleware 强制验证循环
LangChain: 强制验证循环
Agent 启动
LocalContextMiddleware 自动注入环境信息
Agent 编码
Agent 想退出？
是 -> PreCompletionChecklist 测试跑了吗？通过了吗？
未通过 -> 触发 LoopDetection 编辑同文件 5 次则提示换思路
通过 -> 允许退出
效果：同一个模型（GPT-5.2-Codex），只改 Harness，分数从 52.8% → 66.5%，提升 26%。
比喻：Prompt 里写"别忘了测试"就像在考场门口贴"禁止作弊"的标语——有人看，有人不看。Middleware 是直接装监控摄像头——想绕都绕不过去。
场景：Stripe 每周通过 AI 合并 1000+ 个 PR，零行人工代码。
核心策略：一键式端到端 Agent
Stripe Minions 流程
Slack/CLI 工程师发起任务
隔离沙箱 10 秒预热启动
Toolshed 400+ 内部工具-MCP
一次性生成代码
本地 Lint 5 秒内完成
CI 测试 最多 2 轮自动修复
生成 PR
人类 Review
关键设计：
为什么选择"一键式"而非"对话式"？因为对于定义清晰的任务，单次执行在延迟和成本上都碾压复杂的多轮对话。
场景：多个不同的 AI Agent（Claude Code、GitHub Copilot、Augment 等）需要在同一个代码库中协作。
核心策略：Kanban 驱动的多 Agent 协调
Routa 不用一个全能 Agent，而是配备了一支"AI 开发团队"：
| Agent 角色 | 职责 |
|---|---|
| Backlog Refiner | 把粗略想法变成可执行的用户故事 |
| Todo Orchestrator | 消除歧义，准备编码卡片 |
| Dev Crafter | 实现功能，运行测试 |
| Review Guard | 检查实现质量 |
| Reporter | 总结已完成的工作 |
工程防御机制方面：
这套系统自己也是用 AI Agent 开发的——"用 AI 管 AI"的递归之美。
当 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 |
用一个类比：
选择路径：
1️⃣ 先稳定 MCP → 让 Agent 能用工具
2️⃣ 再评估 ACP 或 A2A → 按需引入多 Agent 协作
3️⃣ 最后考虑多 Agent 编排 → 如 Routa 的 Kanban 模式
IEEE 已经启动了 Agentic AI 协议工作组，未来这三者可能走向融合。MCP 插件市场年增长 217%，生态建设势头最猛。
传统软件系统是给人用的：代码仓库的结构、工具的 UI、CI/CD 的操作方式，都假设使用者是人类。
当 AI 入场后，这些假设失效了。AI 不会"问同事"、不会"凭经验"、不会"读空气"。
工程系统需要从 Human-first 进化为 Agent-aware——不是取消对人的支持，而是同时支持人和 AI。
工程系统进化
AI 入场
Human-first 为人类设计：GUI/口头约定/经验传承
Agent-aware 人机共存：CLI+API/AGENTS.md/自动化验证
未来的软件开发将运行在两个循环中：
软件开发的双循环
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 的核心价值，就是用工程方法让概率性系统可靠运行。 不是消除不确定性，而是限制边界：
AI Coding 的未来，不是完全自动化的软件开发，而是人与 AI 共同运行的软件工程系统。
Harness Engineering，就是这个系统的工程基础设施。
或者用一句话总结：
好的缰绳不会让马跑得更慢，只会让它跑得更稳、更远。 🐎
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online