Harness Engineering决定AI编程生产力的工程体系最近和AI一起写代码时我越来越强烈地感觉到一件事。同一个模型放在网页聊天框里你让它改一个项目它往往会给你一段看起来不错的代码然后补一句你可以根据实际情况调整。还是这个模型放进一个成熟的AI编程工具里它却能自己搜索仓库、定位函数、修改多个文件、运行测试发现失败后继续修最后告诉你改了什么、验证了什么、还有什么风险。模型没有换表现却像换了一个脑子。于是行业里开始流传一个很有冲击力的公式AI编程生产力 大模型能力 × Harness工程体系能力还有一个更大胆的判断很多时候同一模型在不同Harness下的表现差距可能比不同模型在同一Harness下的差距更大。这句话不必当成严格的数学定理但它点破了一个容易被忽略的事实我们每天讨论GPT、Claude、Gemini谁更强却很少追问模型究竟被放进了一个怎样的工作环境。这个工作环境就是本文要聊的Harness Engineering。先别急着翻译HarnessHarness这个词不太好直译。它原本可以指挽具、安全带、线束也可以指测试系统里用于固定和连接被测对象的一套装置。放到AI Agent里它表达的是同一种意思不是替代核心而是把核心接入一个可控制、可工作的系统。大模型是其中最聪明的部分但不是全部。如果把大模型比作一个能力很强的新同事Harness就是公司给他的整套工作条件他能看到哪些代码和文档他可以使用哪些工具他接到任务后按什么流程工作他怎样知道修改是对还是错哪些操作可以直接做哪些必须审批失败后如何重试、回滚和继续团队用什么指标判断他到底有没有提高效率所以Harness Engineering可以先用一句白话来定义围绕大模型设计一套上下文、工具、流程、反馈和安全体系让它从会回答问题变成能稳定完成工程任务。这不是给提示词换个高级名字也不等于接几个MCP工具。它关注的是模型从接收任务到交付结果的完整闭环。一个代码修改看看差距是怎么拉开的假设线上有一个Java服务现在要给订单查询接口增加deliveryTime字段。在普通聊天框里你可能要这样做把Controller代码复制进去。再把Service和DTO复制进去。解释项目使用的Java版本和框架版本。把模型生成的代码手动粘回仓库。编译后发现字段类型不对再把报错贴给模型。修好编译问题又发现序列化测试失败。继续来回复制直到自己失去耐心。这里的大模型更像一个隔着电话指导你的顾问。它也许很聪明但看不到现场更碰不到系统。成熟Harness里的Agent会采用另一种方式读取仓库说明确认构建命令、编码规范和禁止修改的目录。搜索订单接口、DTO、数据库模型和相关测试。判断字段来自数据库、下游接口还是计算逻辑。制定最小修改计划避免无关重构。修改代码同时补充序列化和接口测试。执行编译、静态检查和目标测试。如果失败根据真实错误继续定位和修复。展示变更摘要、测试证据和仍需人工确认的业务风险。第二种方式的关键不是模型第一次生成的代码更漂亮而是它能接触真实环境反馈。编译器说类型不对测试说返回值不符合约定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工程有什么区别这三个概念不是相互取代而是一层层扩大工程边界。概念核心问题典型产物Prompt Engineering这一轮应该怎样告诉模型系统提示词、任务指令、示例Context Engineering这一轮应该让模型看到什么仓库地图、检索结果、历史摘要、工具返回Harness Engineering如何让模型持续做对并证明做对了工具、循环、状态、测试、权限、评估体系如果说提示词工程是在给一个人写清楚任务上下文工程是在把正确资料放到他桌上那么Harness Engineering就是设计整个工作岗位电脑、权限、流程、验收、交接和审计都包括在内。因此一个写得很好的AGENTS.md或者CLAUDE.md很重要但它只是Harness的一部分接入MCP也很重要但MCP解决的是模型如何连接工具和数据同样不是完整答案。大厂在做什么名字不同方向越来越一致Harness Engineering并不是所有公司都统一采用的标准术语但背后的工程思想已经非常清楚。OpenAI直接提出Harness EngineeringOpenAI已经在官方文章中直接使用Harness Engineering这个名称。它讨论的重点不是如何再润色一句Prompt而是如何把代码仓库建设成适合Agent工作的环境。仓库结构、AGENTS.md、测试、格式化、CI、文档、可观测反馈这些过去主要服务于人类开发者的设施现在也要变成Agent能够理解和使用的接口。这意味着一件很有意思的事过去我们只关注代码是否对人友好未来还要关注仓库是否对Agent友好。Anthropic再强的模型也需要好的Agent HarnessAnthropic在长时间运行的编程Agent实验中发现前沿模型仅靠一个高层任务仍会失败一次想做太多、跨上下文后忘记进度、功能没完成就宣布成功或者只跑局部测试而没有验证真实用户流程。它的改进办法不是单纯换模型而是改Harness首轮Agent初始化环境和完整功能清单后续Agent每次只完成一个增量任务用结构化文件保存进度用Git保留可恢复状态启动新一轮前先检查现状通过浏览器自动化做端到端测试这类设计看起来并不神秘甚至很像成熟研发团队每天做的事情。恰恰说明Harness Engineering不是魔法而是把软件工程常识重新应用到Agent身上。Anthropic还提到在构建SWE-bench编程Agent时团队花在优化工具上的时间甚至多于优化总提示词。一个工具把相对路径改成强制绝对路径就可能减少大量调用错误。AWS把Harness拆成企业生产架构AWS目前更常使用Agentic AI Operational Foundations而不是统一称作Harness Engineering但它给出的架构几乎覆盖了完整HarnessAgentCore 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。团队怎样搭建自己的最小HarnessHarness听起来很大但团队不需要一开始就建设一个AI开发平台。可以从一个最小闭环开始。第一步把任务完成条件写清楚不要只写优化订单接口而要定义哪个行为需要改变哪些文件或模块不能动哪些测试必须通过是否允许修改公共接口什么情况必须找人确认Agent最怕的不是任务难而是完成的定义含糊。第二步让仓库可以被快速理解团队可以先准备几样简单的东西repo/ ├── AGENTS.md # 构建方式、目录说明、工作规则 ├── docs/architecture.md # 核心架构和依赖边界 ├── scripts/dev.sh # 一键启动开发环境 ├── scripts/verify.sh # 一键执行基础验证 ├── tests/ # 可重复运行的测试 └── .github/workflows/ # CI质量门禁这套东西不只服务Agent也会改善新人入职、故障交接和日常开发体验。第三步先打通搜索、修改和验证工具不用贪多。对大多数团队第一阶段只要打通准确搜索代码安全修改文件运行构建和目标测试查看Git Diff根据失败结果继续修正如果这五步能稳定工作价值往往已经超过接入几十个看起来很酷的工具。第四步用权限而不是提示词控制风险开发环境可以自动执行只读命令和测试文件修改限制在工作区删除数据、访问生产、合并代码、发布版本必须人工确认。权限应该随着风险上升逐级收紧而不是让Agent默认拿着所有钥匙再叮嘱它小心使用。第五步建立自己的真实任务集不要只用公开榜单判断AI编程效果。团队可以从历史Issue中抽取20到50个有代表性的任务小型缺陷修复API字段调整单元测试补充依赖升级跨模块重构日志和配置问题每次更换模型、Prompt、工具或流程都在同一批任务上比较成功率、回归率、耗时、成本和人工接管次数。到了这一步你才真正拥有了可迭代的Harness而不只是买了一个AI编程账号。怎样判断一个AI编程工具的Harness好不好以后评估AI编程产品可以少问一句它用了什么模型多问下面这些问题它怎样理解仓库是一次塞入大量文件还是能按需搜索和追踪依赖它有哪些真实工具只能生成代码还是能运行命令、测试和浏览器它怎样处理失败报错后停止还是能根据反馈重新规划它如何定义完成靠模型自己宣布还是由测试和质量门禁判断它如何保存状态长任务中断后能否知道之前做了什么它有哪些权限边界是否支持只读、沙箱、审批和审计它能否被评估是否能看到成功率、工具轨迹、耗时和成本它是否允许模型替换Harness能力能否沉淀而不是全部锁死在单一模型上这些问题比单纯比较某个模型在榜单上高了几分更接近团队最终能获得多少生产力。Harness Engineering会成为一个新岗位吗有可能出现专门的Harness Engineer但我更倾向于认为它首先会变成现有工程岗位的一组新能力。它和很多已有领域天然相连平台工程负责统一工具和开发者体验DevOps负责构建、测试和交付闭环SRE负责可观测性、可靠性和故障恢复安全团队负责权限、隔离和审计架构师负责上下文边界和系统契约测试团队负责验收标准和评估数据集换句话说Harness Engineering并没有推翻软件工程。它是在模型具备行动能力之后让那些看似传统的工程基础设施重新变得更重要。过去混乱的文档、脆弱的测试、无法一键启动的项目主要让新人痛苦现在它们也会直接限制AI Agent的表现。一个对人类工程师友好的仓库通常也更容易被Agent使用。反过来为Agent补齐的规范、脚本、测试和可观测性最后也会回馈人类团队。最后别只盯着那颗越来越聪明的大脑过去两年我们习惯了追逐模型更新。上下文又长了多少榜单又高了几分代码能力又超过了谁。这些当然重要。但当模型能力逐渐接近真正拉开产品和团队差距的很可能不再只是那颗大脑而是谁给它准备了更好的工作环境。它能不能找到正确的信息能不能调用合适的工具能不能从失败中恢复能不能证明代码真的可用能不能在权限范围内安全行动能不能把每一次执行沉淀成下一次改进的依据。这些问题合起来才是Harness Engineering。所以以后再看到一个AI编程工具表现惊艳时不妨多问一句到底是模型更聪明了还是它终于被放进了一套真正能工作的工程体系对个人来说学会用AI写代码只是起点对团队来说真正值得沉淀的不是某一次漂亮的生成结果而是让结果可以重复出现的那套系统。参考链接OpenAIHarness engineering - leveraging Codex in an agent-first worldAnthropicEffective harnesses for long-running agentsAnthropicBuilding effective agentsAnthropicEffective context engineering for AI agentsAWSGuidance for Agentic AI Operational Foundations on AWSAWS Well-ArchitectedImplement guardrails and alignment controlsGoogle CloudFrom Vibe Checks to Continuous Evaluation本文对以上官方资料的观点进行了归纳和转述。