Harness Engineering真相：为何我不会将它视为未来？

为什么我在团队全力推行 Harness Engineering，却并不将其视为终极答案

过去数年，软件工程领域围绕AI的讨论经历了多个阶段：先是代码补全，接着是交互式问答，随后是Agent自主修改代码、执行测试、提交PR。表面上，焦点集中在模型能力的提升。但在实际团队中，真正决定AI能否融入生产流程的关键，往往不是“模型能否编写代码”，而是一个更根本的问题——团队是否为其构建了足够稳固的工程支撑体系。

这正是我所理解的Harness Engineering。

我在团队中强力推动它，并非因为它代表着软件工程的最终形态，而是因为在当前阶段，它是将AI从“个人提效工具”转化为“团队生产力系统”最明确的实施路径。

1. 软件工程中的 Harness Engineering 究竟指什么

Harness一词，原意为“马具、装备、约束装置”。在工程领域，它常见于test harness这一术语，指代为稳定运行、观察和验证某段程序而搭建的外部支撑框架。

将其置于AI软件工程的语境中，Harness Engineering的定义更接近于：

它不是某款单一工具，也不是某套提示词模板。它更像是一个围绕AI Agent构建的工程运行时环境，需要包含以下要素：

• 任务描述规范：需求如何撰写、约束如何表达、验收标准如何界定、边界条件如何划分。
• 上下文供给机制：代码库、文档、架构约定、业务规则、历史决策——模型如何获取这些信息。
• 工具调用接口：搜索代码、运行测试、访问日志、读写文件、查阅文档、调用内部平台的能力。
• 工作流编排：从issue到设计、编码、测试、审查、发布，这条协作链路如何打通。
• 质量验证体系：单元测试、集成测试、lint、类型检查、静态分析、回归用例、评估集。
• 权限与安全边界：哪些操作可自动执行，哪些必须人工审批，敏感信息如何隔离。
• 组织知识沉淀：团队风格、模块边界、常见陷阱、最佳实践——这些内容如何持续更新。

纵观整个研发工程体系，Harness Engineering并不取代需求管理、代码仓库、CI/CD、测试平台或发布系统。它更像是为AI协作而设计的一层中枢，架设在“人类研发活动”与“底层工程基础设施”之间，将大模型接入现有的软件生产链路。

一个简化的结构可以这样理解：其核心不是“让AI变得更聪明”，而是“让AI在一个更适合工作的系统里运作”。

缺少这一层Harness时，开发者使用AI的方式通常是：打开聊天窗口，粘贴一段代码，询问修改意见，复制答案，再手动验证。这种方式适合个人探索，但很难纳入团队级别的流程。

有了Harness之后，AI的工作方式更接近真实的工程协作——它能读取完整上下文，理解团队约束，修改代码，运行验证，输出一份可审查的变更，并将失败信息反馈给下一轮行动。

2. Harness Engineering 的基本落地方式与价值

落地Harness Engineering，第一步不应从“该买哪个AI工具”开始思考，而应从“团队希望AI参与哪些工程动作”出发。

常见的落地路径大致分为五层。

第一层，是个人工具。开发者使用Copilot、Cursor、Claude Code、Codex或其他AI编码助手解决局部问题。这一层收益最明显，但高度依赖个人能力。

第二层，是团队规则。团队开始维护一套统一的AI使用规范，如代码风格、commit约定、review清单、测试要求、禁止修改的目录、常见问题处理方式。这一步将个人经验转化为团队资产。

第三层，是仓库上下文。团队为代码库准备好Agent能读懂的文档：系统架构、模块边界、本地启动方式、测试命令、关键业务概念、目录说明、依赖关系。很多时候，AI犯错并非能力不足，而是因为它不知道那些团队默认知晓的信息。

第四层，是工具链接入。Agent不再仅回答问题，而是可以调用工具：搜索代码、编辑文件、运行测试、查询接口文档、读取日志、触发CI。近期MCP这类协议之所以流行，本质上是因为它解决了“模型如何以标准化方式连接外部工具和数据源”的问题。

第五层，是AI-native SDLC。AI开始参与需求澄清、方案设计、代码实现、测试补齐、审查辅助、发布说明编写、事故复盘——整个软件生命周期。到这一步，Harness不再是局部辅助设施，而是团队工程系统的一部分。

它的价值主要体现在四个方面。

第一，降低上下文切换成本。开发者无需反复解释项目背景、目录结构、测试命令、业务规则——AI可通过稳定上下文自行获取这些信息。

第二，提升交付一致性。团队可将“我们希望代码怎么写、测试怎么补、PR怎么描述”等要求固化到规则和验证链路中，而非依赖每个开发者的临场发挥。

第三，扩大自动化边界。传统自动化擅长确定性任务（如构建、测试、发布）；AI擅长半结构化任务（如理解需求、修改代码、补充文档）。Harness将两者连接，使更多工程活动进入可自动执行、可观察、可回滚的范围。

第四，形成团队级的学习系统。每一次失败的AI任务，都可沉淀为更好的文档、更明确的规则、更完整的测试、更安全的权限边界。团队不仅是在“使用AI”，更是在训练自己的工程系统，使其更适合与AI协作。

3. 为什么它是当前软件工程 AI 化的最佳实践之一

当前AI的编码能力已足够强大，但尚未强大到可以无视工程环境的程度。

一个模型能写出漂亮的函数，却可能不知道仓库中某个字段不可改动；它能生成看似合理的测试，却可能不知道团队使用的测试夹具是什么；它能完成局部重构，却可能无意破坏某个隐含的跨模块约定。

这就是当前AI工程化的核心矛盾：模型的通用能力快速膨胀，但它对每个具体工程环境的理解仍然非常有限。

Harness Engineering的价值，正是将这些散落各处的约束，组织成模型可直接使用的工作环境。

对团队而言，它带来的改变并非“大家写代码更快”这么简单，而是开发模式的一次重构。

团队会从“人写代码，AI补几行”逐渐转向“人定义问题和边界，AI执行部分工程闭环，人负责判断和承担责任”。

这种变化会带来几个非常实际的结果。

• 新成员上手更快。因为团队不得不将隐性知识显性化——AI能读，新人也能读。
• 低价值重复劳动减少。样板代码、测试补齐、简单迁移、文档更新、机械重构等，均可逐渐交由Agent完成。
• 工程规范更容易落地。过去规范写在文档里，靠审查兜底；现在规范可嵌入Agent规则、CI校验和自动修复流程中。
• 资深工程师的时间被重新分配。他们会减少机械实现的时间，更多投入架构判断、任务拆解、复杂问题定位、质量标准制定和系统演进。

这也是为什么，在2026年这个时间节点上，Harness Engineering是软件工程AI化最值得投入的实践之一。它能把AI输出的那部分不确定性，包裹进一个相对稳定的工程系统里，让个人的效率提升演变为整个团队的生产力提升。

4. 为什么它不是未来，而只是中间过渡阶段

然而，越是认真推进Harness Engineering，就越不能将其误认为是终局。

它很重要，但其重要性背后有一个前提：当前的大模型还需要外部支架才能工作得好。

今天我们需要编写rules，是因为模型还不能稳定地理解团队的具体偏好。我们需要手工维护上下文，是因为模型无法天然拥有一个组织的完整工程记忆。我们需要复杂的工具编排，是因为模型还不能原生、安全、可靠地完成所有工程动作。我们需要大量的验证链路，是因为模型的输出仍然可能在局部正确、系统错误之间摇摆。

换句话说，Harness Engineering解决的，是“当前模型能力与真实工程复杂度之间的落差”。

只要这个落差存在，Harness就有价值。但若未来模型自身能逐步吸收这些能力，Harness的形态就一定会被压缩。

很多今天看似“工程平台能力”的东西，未来可能变成模型的基础能力或标准能力。

• 今天我们需要告诉AI“这个仓库怎么跑测试”；未来Agent可能自动识别项目结构、推断测试入口、构建隔离环境，并在失败时理解失败原因。
• 今天我们需要编写大量提示词规范；未来模型通过组织记忆和持续反馈，可能自动学会团队的偏好。
• 今天我们需要在工具之间手工搭桥；未来模型和工具之间可能通过更统一的协议、权限模型和运行时环境直接协作。
• 今天我们需要将任务拆解成很细的步骤；未来更强的工程Agent可能自行完成任务分解、风险识别、并行执行和结果合并。

所以，Harness Engineering不是未来本身。它更像是从“人类主导的软件工程”走向“AI深度参与的软件工程”之间的一座脚手架。

脚手架非常重要。没有它，高楼建不起来。但如果有一天高楼稳定成型，脚手架本身不会成为建筑的主体。

5. 为什么大模型会吞噬这一块内容

大模型吞噬Harness Engineering，并非指所有工程平台都会消失，也不是说团队不再需要流程、权限和验证。恰恰相反，未来的软件工程系统仍然需要约束，只是许多约束的表达方式会发生迁移——从“外部配置”变成“模型原生能力的一部分”。

这种吞噬会发生在三个方向上。

第一，模型会吞噬上下文工程。

今天我们在模型周围做大量的上下文工程：切分文档、编写检索逻辑、维护规则文件、设计提示词模板。未来，模型的上下文窗口、长期记忆、代码理解能力和多模态理解能力会持续增强。更多项目知识将被模型以更自然的方式吸收、更新和调用。

第二，模型会吞噬工具编排。

今天我们需要明确告诉Agent调用什么工具、按什么顺序、失败时如何处理。未来的Agent更像是一个运行在工程操作系统上的智能进程：它知道何时该读代码，何时该查文档，何时该跑测试，何时该请求权限，何时该停下来询问人类。

第三，模型会吞噬初级质量判断。

今天许多验证依赖外部脚本和人工检查清单。未来模型会更擅长识别代码异味、接口破坏、测试不足、迁移风险、性能隐患和安全问题。CI不会消失，但它的角色会从“唯一判断者”变为“模型自我验证体系的一部分”。

我们可以把这个演进过程理解为：每一层都不是简单替代上一层，而是把上一层的显性工作逐渐内化。

• 提示词不会消失，但不会再是主要门槛。
• 上下文不会消失，但不一定需要人工拼接。
• Harness不会消失，但它会越来越像是底层的那个基础设施，而非每个团队都需要手工维护的一大堆规则和脚本。

6. 软件工程未来的几种猜想

如果Harness Engineering只是一个过渡阶段，那么未来会是什么样子？

那个未来大概率不是“程序员消失”。更可能发生的是：软件工程的核心对象会发生改变。

过去，软件工程师主要操作代码。未来，软件工程师会更多地操作意图、约束、系统边界以及智能体协作网络。

这里有几点猜想。

第一，需求会变成可执行的对象。

未来需求文档不再只是给人阅读的自然语言，而是同时面向人和Agent的一份规格系统。它包含业务目标、边界条件、验收测试、风险等级、合规要求、观测指标。需求一旦形成，Agent便可直接依据它生成方案、代码、测试和发布计划。

第二，代码库会变成会自我解释的系统。

今天的代码库主要由人维护，文档往往落后于代码。未来的代码库会持续生成自身模块地图、依赖关系、风险区域、变更影响分析和演进建议。开发者打开的是一堆文件，而是一个可对话、可解释、可协商变更路径的系统。

第三，开发团队会从“人组成的团队”变成“人和智能体组成的团队”。

一个团队里可能会有测试Agent、迁移Agent、文档Agent、审查Agent、性能Agent、依赖治理Agent。人类工程师的职责不是逐行指挥它们，而是定义目标、分配权限、设计反馈机制，并对最终结果负责。

第四，架构能力会重新升值。

当编写代码的边际成本持续下降，真正稀缺的是判断力——什么不该做，边界设在哪里，系统复杂度如何控制，哪些约束必须长期稳定，哪些可以快速试错。AI会降低实现成本，但不会自动为组织带来清晰的战略和架构取舍。

第五，软件交付会更接近连续演化。

未来的软件可能不再以大版本发布为主要节奏，而是围绕目标指标持续生成、验证、发布和回滚。开发从“项目制”进一步转向“演化制”：系统不断观察自身、提出改进、生成变更、接受审查、进入生产。

7. 软件开发从业人员应该做哪些准备

如果我们承认Harness Engineering很重要，但又不是终局，那么个人和团队的准备方向就会变得更清晰。

第一，学会把隐性知识显性化。

未来最有价值的工程师，不仅是能把代码写出来的人，更是能把复杂系统解释清楚的人。你需要能够清晰地写出模块边界、业务规则、约束条件、失败模式和测试策略。因为这些内容不仅需要给人看，也需要给AI看。

第二，提升任务定义的能力。

在AI时代，模糊的任务定义会制造更大的混乱。优秀的工程师需要能把“做一个功能”拆解成目标、非目标、输入输出、验收标准、风险点和回滚方案。任务定义得越清楚，Agent的执行质量就越高。

第三，掌握验证思维。

不要只问“AI能不能写出来”，要问“我怎么知道它写对了”。测试、类型系统、静态分析、可观测性、灰度发布、回滚机制、评估集——这些会成为AI时代工程师的核心武器。

第四，理解工具和协议。

MCP、Agent运行时、CI/CD、权限系统、代码搜索、知识库、日志平台——这些都是AI进入工程系统的接口。你不一定需要成为每个领域的专家，但需要理解它们如何连接成一个可靠的工作环境。

第五，保留架构判断和产品判断。

当模型越来越会写代码时，工程师的差异性会更多地体现在判断力上：识别真正的问题，拒绝错误的需求，控制复杂度，设计可演化的系统，理解业务目标和用户价值。

第六，训练与AI协作的工作习惯。

不要把AI当搜索引擎用，也别把它当廉价实习生使。更好的方式是把它当作一个高吞吐、可并行、需要约束、需要验证的工程协作者。你给它上下文、目标和边界，它给你方案、实现和反馈；你负责判断、整合和承担后果。

第七，主动参与团队Harness建设。

如果你所在的团队还没有AI rules、仓库上下文、Agent工作流、自动验证体系，现在就可以动手开始搭建。不要等模型变得完美。真正的红利属于那些在模型还不那么完美时，就已经学会重构工程系统的团队。

结语：推进它，但不要迷信它

我推进Harness Engineering，是因为它提供了AI进入真实软件工程的一条具体、可控、可复制的路径。

它让团队从零散地使用AI，走向系统性的AI协作；从个人提效，走向组织提效；从“模型写几行代码”，走向“模型参与工程闭环”。

但我不认为它就是未来。

未来不会停在Harness上。它会发生在大模型、工具、上下文、验证、权限和组织协作逐渐融合之后。到那时，今天很多需要手工搭建的支架，会被模型能力、标准协议和AI-native工程平台所吞噬。

所以，更准确的态度应该是这样：

这不是矛盾，而是工程演进的常态。真正值得追求的，不是某个特定的中间形态，而是让团队持续地靠近更高质量、更高速度、更低摩擦的软件创造方式。