Harness Engineering：决定AI编程生产力的工程体系

Harness Engineering：决定AI编程生产力的工程体系

最近和AI一起写代码时，我越来越强烈地感觉到一件事。

同一个模型，放在网页聊天框里，你让它改一个项目，它往往会给你一段看起来不错的代码，然后补一句：你可以根据实际情况调整。

还是这个模型，放进一个成熟的AI编程工具里，它却能自己搜索仓库、定位函数、修改多个文件、运行测试，发现失败后继续修，最后告诉你改了什么、验证了什么、还有什么风险。

模型没有换，表现却像换了一个脑子。

于是行业里开始流传一个很有冲击力的公式：

AI编程生产力 = 大模型能力 × Harness工程体系能力

还有一个更大胆的判断：很多时候，同一模型在不同Harness下的表现差距，可能比不同模型在同一Harness下的差距更大。

这句话不必当成严格的数学定理，但它点破了一个容易被忽略的事实：我们每天讨论GPT、Claude、Gemini谁更强，却很少追问，模型究竟被放进了一个怎样的工作环境。

这个工作环境，就是本文要聊的Harness Engineering。

先别急着翻译Harness

Harness这个词不太好直译。

它原本可以指挽具、安全带、线束，也可以指测试系统里用于固定和连接被测对象的一套装置。放到AI Agent里，它表达的是同一种意思：不是替代核心，而是把核心接入一个可控制、可工作的系统。

大模型是其中最聪明的部分，但不是全部。

如果把大模型比作一个能力很强的新同事，Harness就是公司给他的整套工作条件：

• 他能看到哪些代码和文档
• 他可以使用哪些工具
• 他接到任务后按什么流程工作
• 他怎样知道修改是对还是错
• 哪些操作可以直接做，哪些必须审批
• 失败后如何重试、回滚和继续
• 团队用什么指标判断他到底有没有提高效率

所以，Harness Engineering可以先用一句白话来定义：

围绕大模型设计一套上下文、工具、流程、反馈和安全体系，让它从会回答问题，变成能稳定完成工程任务。

这不是给提示词换个高级名字，也不等于接几个MCP工具。它关注的是模型从接收任务到交付结果的完整闭环。

一个代码修改，看看差距是怎么拉开的

假设线上有一个Java服务，现在要给订单查询接口增加deliveryTime字段。

在普通聊天框里，你可能要这样做：

1. 把Controller代码复制进去。
2. 再把Service和DTO复制进去。
3. 解释项目使用的Java版本和框架版本。
4. 把模型生成的代码手动粘回仓库。
5. 编译后发现字段类型不对，再把报错贴给模型。
6. 修好编译问题，又发现序列化测试失败。
7. 继续来回复制，直到自己失去耐心。

这里的大模型更像一个隔着电话指导你的顾问。它也许很聪明，但看不到现场，更碰不到系统。

成熟Harness里的Agent会采用另一种方式：

1. 读取仓库说明，确认构建命令、编码规范和禁止修改的目录。
2. 搜索订单接口、DTO、数据库模型和相关测试。
3. 判断字段来自数据库、下游接口还是计算逻辑。
4. 制定最小修改计划，避免无关重构。
5. 修改代码，同时补充序列化和接口测试。
6. 执行编译、静态检查和目标测试。
7. 如果失败，根据真实错误继续定位和修复。
8. 展示变更摘要、测试证据和仍需人工确认的业务风险。

第二种方式的关键，不是模型第一次生成的代码更漂亮，而是它能接触真实环境反馈。

编译器说类型不对，测试说返回值不符合约定，Lint说代码不符合规范，Git Diff告诉它改动范围过大。这些反馈都是确定的、可观察的，比模型自己说应该没问题可靠得多。

AI编程真正跨过的门槛，不是从不会写代码到会写代码，而是从生成一次走向执行、验证、修正，直到满足交付条件。

Harness到底由什么组成

一个成熟的AI编程Harness，至少包含七层能力。

第一层：模型

模型负责理解需求、推理、规划和生成代码。它决定能力上限，但不能独自完成工程交付。

复杂重构可能需要更强的模型，简单代码检索则可以交给更便宜、更快的模型。成熟Harness甚至会根据任务难度自动路由模型，而不是所有事情都调用最贵的那一个。

第二层：上下文

上下文不只是你输入的那句话，还包括：

• 仓库目录和代码依赖
• 架构说明与编码规范
• API契约和数据模型
• Git历史与近期变更
• 当前任务进度
• 编译、测试和运行日志

很多人以为上下文窗口越大越好，其实未必。把几十万行代码一次性塞进去，就像把整个公司文件柜倒在新同事桌上，然后问他问题出在哪里。

更好的方式是提供地图和检索能力，让Agent先知道去哪里找，再按需读取高价值信息。

第三层：工具

工具决定模型能不能碰到真实世界。对编程Agent来说，常见工具包括：

• 文件和符号搜索
• 代码读取与修改
• Shell命令
• 编译器、Lint和测试框架
• Git Diff与提交历史
• 浏览器自动化
• 数据库或内部API

工具不是越多越好。功能重叠、参数含糊、输出冗长，都会让模型选错工具或者浪费上下文。

一个好工具应该像写给新同事的清晰接口：名字直白，参数明确，错误可理解，边界说清楚。

第四层：执行循环

真正的Agent不是调用一次模型，而是不断进行下面这个循环：

理解任务 -> 获取上下文 -> 制定计划 -> 调用工具 -> 观察结果 -> 调整下一步

什么时候继续，什么时候重试，什么时候停止，什么时候找人确认，都属于Harness的控制逻辑。

没有这个循环，模型只是一次性生成器；有了循环，它才开始像一个会根据现场情况调整动作的工程执行者。

第五层：验证

验证是AI编程从演示走向生产的分水岭。

对于软件工程，验证可以是：

• 能否编译
• 单元测试是否通过
• 接口契约是否变化
• 端到端功能是否正常
• 是否引入安全漏洞
• 性能是否明显退化
• Diff是否超出任务范围

最危险的Agent不是不会写代码，而是代码没验证就非常自信地告诉你已经完成。

所以，任务完成不能由模型自己宣布，而应该由外部证据定义。

第六层：安全与权限

能执行Shell、访问云资源、修改代码的Agent，本质上已经获得了操作系统和生产工具的入口。

只在系统提示词里写一句不要执行危险操作，远远不够。真正的边界应该落在确定性的控制上：

• 默认只读，按任务逐步授权
• 限制可访问目录和命令
• 使用沙箱或临时环境
• 凭证最小权限和短期有效
• 删除、发布、合并等高风险动作需要人工确认
• 所有工具调用保留审计记录
• 重要修改能够回滚

提示词是行为建议，权限系统才是硬边界。

第七层：评估与可观测性

如果团队只凭几次演示判断Agent好不好，很容易陷入感觉不错的陷阱。

Harness需要记录完整执行轨迹，并回答这些问题：

• 任务最终成功了吗
• 第一次成功率是多少
• 引入回归的比例是多少
• 人工接管了多少次
• 失败后能否自主恢复
• 平均耗时和Token成本是多少
• 哪个工具最常失败
• 更换模型后，整体结果到底提高了多少

没有评估，就无法知道应该升级模型、改进上下文，还是修复工具和流程。

提示词工程、上下文工程和Harness工程有什么区别

这三个概念不是相互取代，而是一层层扩大工程边界。

如果说提示词工程是在给一个人写清楚任务，上下文工程是在把正确资料放到他桌上，那么Harness Engineering就是设计整个工作岗位：电脑、权限、流程、验收、交接和审计都包括在内。

因此，一个写得很好的AGENTS.md或者CLAUDE.md很重要，但它只是Harness的一部分；接入MCP也很重要，但MCP解决的是模型如何连接工具和数据，同样不是完整答案。

大厂在做什么：名字不同，方向越来越一致

Harness Engineering并不是所有公司都统一采用的标准术语，但背后的工程思想已经非常清楚。

OpenAI：直接提出Harness Engineering

OpenAI已经在官方文章中直接使用Harness Engineering这个名称。它讨论的重点不是如何再润色一句Prompt，而是如何把代码仓库建设成适合Agent工作的环境。

仓库结构、AGENTS.md、测试、格式化、CI、文档、可观测反馈，这些过去主要服务于人类开发者的设施，现在也要变成Agent能够理解和使用的接口。

这意味着一件很有意思的事：过去我们只关注代码是否对人友好，未来还要关注仓库是否对Agent友好。

Anthropic：再强的模型也需要好的Agent Harness

Anthropic在长时间运行的编程Agent实验中发现，前沿模型仅靠一个高层任务仍会失败：一次想做太多、跨上下文后忘记进度、功能没完成就宣布成功，或者只跑局部测试而没有验证真实用户流程。

它的改进办法不是单纯换模型，而是改Harness：

• 首轮Agent初始化环境和完整功能清单
• 后续Agent每次只完成一个增量任务
• 用结构化文件保存进度
• 用Git保留可恢复状态
• 启动新一轮前先检查现状
• 通过浏览器自动化做端到端测试

这类设计看起来并不神秘，甚至很像成熟研发团队每天做的事情。恰恰说明Harness Engineering不是魔法，而是把软件工程常识重新应用到Agent身上。

Anthropic还提到，在构建SWE-bench编程Agent时，团队花在优化工具上的时间甚至多于优化总提示词。一个工具把相对路径改成强制绝对路径，就可能减少大量调用错误。

AWS：把Harness拆成企业生产架构

AWS目前更常使用Agentic AI Operational Foundations，而不是统一称作Harness Engineering，但它给出的架构几乎覆盖了完整Harness：

• AgentCore Runtime负责运行环境
• Memory负责跨会话状态
• Gateway负责工具发现与调用
• Identity和IAM负责身份与权限
• Guardrails负责输入输出边界
• Observability和CloudWatch负责轨迹、指标与告警
• Evaluations负责正确性、工具选择和行为漂移评估

AWS特别强调，能够写成确定性规则的边界，就不应该只依赖模型听话。例如IAM、Schema校验和权限策略应该成为硬控制，内容安全和行为判断再交给概率性的Guardrails与评估模型。

这对企业很重要。生产环境从来不能只问Agent聪不聪明，还要问它做了什么、为什么能做、失败如何发现、责任如何追溯。

Google：从感觉不错走向持续评估

Google Cloud强调Agent Evaluation和Continuous Evaluation。它关注的不只是最终回答像不像正确答案，还包括Agent的工具选择、参数、执行路径、任务完成度和异常恢复。

传统模型评测像考试看最后答案，Agent评测更像检查一个工程师完整的工作过程：资料找对了吗，命令执行对了吗，遇到错误有没有调整，最终系统真的可以运行吗。

这正是Harness的反馈层。没有持续评估，团队对Agent的优化很容易停留在换模型和调Prompt；有了评估，才知道问题究竟出在哪一层。

把这几家公司放在一起看，会发现它们虽然术语不同，但方向高度一致：

模型是推理核心，生产能力来自模型与上下文、工具、运行时、验证、安全和评估的共同作用。

为什么公式里是乘号，而不是加号

回到开头的公式：

AI编程生产力 = 大模型能力 × Harness工程体系能力

乘号表达的是短板效应。

如果模型能力很弱，Harness再完善，它也很难完成复杂推理；如果Harness接近于零，模型再强，也只能在聊天框里给建议，不能稳定交付。

不过还要加一个限定：同一Harness下，更强模型仍然有价值。尤其是跨模块重构、陌生代码理解、复杂故障定位等任务，模型能力会明显影响上限。

因此，Harness Engineering并不是模型无用论，而是在提醒我们：

• 不要把所有失败都归因于模型不够强
• 不要把升级模型当成唯一优化手段
• 不要用模型排行榜代替真实工程评估
• 不要忽略工具、反馈和仓库质量带来的放大效应

很多时候，你以为自己在比较模型，其实比较的是两个产品背后完全不同的Harness。

团队怎样搭建自己的最小Harness

Harness听起来很大，但团队不需要一开始就建设一个AI开发平台。可以从一个最小闭环开始。

第一步：把任务完成条件写清楚

不要只写优化订单接口，而要定义：

• 哪个行为需要改变
• 哪些文件或模块不能动
• 哪些测试必须通过
• 是否允许修改公共接口
• 什么情况必须找人确认

Agent最怕的不是任务难，而是完成的定义含糊。

第二步：让仓库可以被快速理解

团队可以先准备几样简单的东西：

repo/ ├── AGENTS.md # 构建方式、目录说明、工作规则 ├── docs/architecture.md # 核心架构和依赖边界 ├── scripts/dev.sh # 一键启动开发环境 ├── scripts/verify.sh # 一键执行基础验证 ├── tests/ # 可重复运行的测试 └── .github/workflows/ # CI质量门禁

这套东西不只服务Agent，也会改善新人入职、故障交接和日常开发体验。

第三步：先打通搜索、修改和验证

工具不用贪多。对大多数团队，第一阶段只要打通：

1. 准确搜索代码
2. 安全修改文件
3. 运行构建和目标测试
4. 查看Git Diff
5. 根据失败结果继续修正

如果这五步能稳定工作，价值往往已经超过接入几十个看起来很酷的工具。

第四步：用权限而不是提示词控制风险

开发环境可以自动执行只读命令和测试；文件修改限制在工作区；删除数据、访问生产、合并代码、发布版本必须人工确认。

权限应该随着风险上升逐级收紧，而不是让Agent默认拿着所有钥匙，再叮嘱它小心使用。

第五步：建立自己的真实任务集

不要只用公开榜单判断AI编程效果。团队可以从历史Issue中抽取20到50个有代表性的任务：

• 小型缺陷修复
• API字段调整
• 单元测试补充
• 依赖升级
• 跨模块重构
• 日志和配置问题

每次更换模型、Prompt、工具或流程，都在同一批任务上比较成功率、回归率、耗时、成本和人工接管次数。

到了这一步，你才真正拥有了可迭代的Harness，而不只是买了一个AI编程账号。

怎样判断一个AI编程工具的Harness好不好

以后评估AI编程产品，可以少问一句它用了什么模型，多问下面这些问题：

1. 它怎样理解仓库？是一次塞入大量文件，还是能按需搜索和追踪依赖？
2. 它有哪些真实工具？只能生成代码，还是能运行命令、测试和浏览器？
3. 它怎样处理失败？报错后停止，还是能根据反馈重新规划？
4. 它如何定义完成？靠模型自己宣布，还是由测试和质量门禁判断？
5. 它如何保存状态？长任务中断后，能否知道之前做了什么？
6. 它有哪些权限边界？是否支持只读、沙箱、审批和审计？
7. 它能否被评估？是否能看到成功率、工具轨迹、耗时和成本？
8. 它是否允许模型替换？Harness能力能否沉淀，而不是全部锁死在单一模型上？

这些问题比单纯比较某个模型在榜单上高了几分，更接近团队最终能获得多少生产力。

Harness Engineering会成为一个新岗位吗

有可能出现专门的Harness Engineer，但我更倾向于认为，它首先会变成现有工程岗位的一组新能力。

它和很多已有领域天然相连：

• 平台工程负责统一工具和开发者体验
• DevOps负责构建、测试和交付闭环
• SRE负责可观测性、可靠性和故障恢复
• 安全团队负责权限、隔离和审计
• 架构师负责上下文边界和系统契约
• 测试团队负责验收标准和评估数据集

换句话说，Harness Engineering并没有推翻软件工程。它是在模型具备行动能力之后，让那些看似传统的工程基础设施重新变得更重要。

过去，混乱的文档、脆弱的测试、无法一键启动的项目，主要让新人痛苦；现在，它们也会直接限制AI Agent的表现。

一个对人类工程师友好的仓库，通常也更容易被Agent使用。反过来，为Agent补齐的规范、脚本、测试和可观测性，最后也会回馈人类团队。

最后：别只盯着那颗越来越聪明的大脑

过去两年，我们习惯了追逐模型更新。上下文又长了多少，榜单又高了几分，代码能力又超过了谁。

这些当然重要。但当模型能力逐渐接近，真正拉开产品和团队差距的，很可能不再只是那颗大脑，而是谁给它准备了更好的工作环境。

它能不能找到正确的信息，能不能调用合适的工具，能不能从失败中恢复，能不能证明代码真的可用，能不能在权限范围内安全行动，能不能把每一次执行沉淀成下一次改进的依据。

这些问题合起来，才是Harness Engineering。

所以，以后再看到一个AI编程工具表现惊艳时，不妨多问一句：

到底是模型更聪明了，还是它终于被放进了一套真正能工作的工程体系？

对个人来说，学会用AI写代码只是起点；对团队来说，真正值得沉淀的不是某一次漂亮的生成结果，而是让结果可以重复出现的那套系统。

参考链接

1. OpenAI：Harness engineering - leveraging Codex in an agent-first world
2. Anthropic：Effective harnesses for long-running agents
3. Anthropic：Building effective agents
4. Anthropic：Effective context engineering for AI agents
5. AWS：Guidance for Agentic AI Operational Foundations on AWS
6. AWS Well-Architected：Implement guardrails and alignment controls
7. Google Cloud：From Vibe Checks to Continuous Evaluation

本文对以上官方资料的观点进行了归纳和转述。