Harness Engineering：AI时代的软件工程新范式

2026-03-29 3 minute read

Harness Engineering，是在AI大模型时代，以确定性系统外壳约束概率性AI行为，通过上下文工程、架构约束、熵管理三位一体，构建可长期稳定运行的AI Agent系统，推动软件工程从代码实现转向系统设计，成为下一代AI工程化的核心范式。

引言

在人工智能，特别是大型语言模型（LLM）能力迅速发展的时代，软件开发领域正经历一场深刻的范式转移。传统以代码为中心的工程方法正在被一种以语言为中心的新范式所取代。这一新范式将工程设计的核心原则，如控制、可靠性和可扩展性，应用到了人与AI的交互界面上。本报告将深入探讨这一新兴领域，提出“Harness Engineering”（驾驭工程）这一术语，用以描述其背后的系统性原则、核心实践、行业案例及未来挑战。报告旨在为软件工程师、技术领导者及行业观察家提供一个全面的框架，以理解并应用这一即将定义未来技术格局的关键技术。

一、超越提示词与上下文

在深入探讨Harness Engineering之前，必须首先理解它所处的演化脉络。它并非一个凭空出现的概念，而是对已有AI工程实践的一次系统性整合与升华。它标志着行业的焦点从与AI模型的“单次对话”转向了构建一个让AI能够“持续可靠工作”的完整系统。

1.1 定义Harness Engineering

Harness Engineering（驾驭工程）被定义为一个新兴的工程学科，其核心目标是设计和实现一套围绕AI Agent（人工智能体）的完整系统，该系统由约束（Constraints）、护栏（Guardrails）、反馈循环（Feedback Loops）和生命周期管理工具组成，旨在使AI Agent能够持续产生正确、可审计且可维护的输出。它的本质是构建一个“确定性外壳”（Deterministic Shell），用以包裹和管理AI模型“概率性”（Probabilistic）的本质。

这一领域的开创者，HashiCorp联合创始人Mitchell Hashimoto，为其赋予了简洁而有力的定义：“每当你发现一个Agent犯了错误，你都应该花时间去设计一个解决方案，确保该Agent在未来永远不会再犯同样的错误”。这一定义精准地捕捉了Harness Engineering的核心精神——它是一种以错误为驱动的系统设计思维，将工程实践的重心从“纠正AI的错误”转移到“预防错误的发生”。

与传统的软件工程范式不同，Harness Engineering处理的是一种新型的、非确定性的“材料”。传统工程构建于逻辑和规则之上，输入与输出之间存在确定的因果链。然而，AI模型，特别是大型语言模型，其行为是概率性的，无法通过传统意义上的“程序逻辑”进行控制。Harness Engineering的创新之处在于，它并未试图将AI变成一个确定性的系统，而是构建一个由确定性组件组成的、能够管理和引导AI probabilistic nature的外部环境。就像交通规则和道路护栏并非限制汽车的性能，而是为了引导其安全、高效地达成目标一样，Harness正是这样一个引导AI的系统。

1.2 AI工程的三次浪潮

Harness Engineering的出现是AI工程化发展的一个必然阶段，它清晰地展示了从“交互”到“集成”，再到“系统设计”的认知演进路径。

第一次浪潮：提示词工程 (Prompt Engineering) - “教AI如何对话”
这是AI工程化的启蒙阶段，大约在2022年至2024年间占据主导地位。该阶段的核心焦点是优化与AI的单次、一次性交互。工程师们通过精心设计的提示词，利用诸如Few-shot、思维链（Chain-of-Thought）、角色扮演等技巧，试图引导模型在一次性的问答中给出更精准的输出。
然而，随着AI从简单的聊天机器人进化为需要处理复杂、多步骤任务的Agent时，单条指令的局限性暴露无遗。其核心问题在于，这类方法高度依赖人工经验，难以实现规模化复用，并且无法应对复杂任务的持续输出需求。提示词工程解决了“怎么说”的问题，但并未解决“基于什么信息说”和“在什么条件下说”。
第二次浪潮：上下文工程 (Context Engineering) - “为AI提供正确的背景”
大约在2025年，行业的焦点从单条指令扩展到了动态系统的构建。上下文工程的核心是管理提供给模型的信息，确保Agent在执行任务时拥有足够的背景知识。这包括了检索增强生成（RAG）、对话历史管理、工具输出整合、系统指令编排等一系列技术。其本质是“为AI配备全面的参考资料”，解决了提示词工程在信息量和持续性上的不足。
尽管上下文工程极大地提升了AI在单次任务中的表现，但它仍然停留在“被动响应”的模式。系统可以向AI展示信息，但缺乏对其输出的主动控制和纠错机制。当面对长期、复杂的任务时，Agent依然会面临稳定性不足、行为失控等问题。
第三次浪潮：驾驭工程 (Harness Engineering) - “设计AI工作的系统”
进入2026年，Harness Engineering成为AI工程化的第三个关键阶段。它代表了从“优化输入”到“优化环境”的根本性思维转变。Harness Engineering综合了前两者的能力，但将其提升到全生命周期控制系统设计的层面。它通过引入架构约束、反馈回路、熵管理等机制，为AI Agent构建了一个能够长期、稳定、高质量完成工作的“操作系统”或“脚手架”。其本质是“为AI搭建一个能长期高效干活的办公室”，将工程的重心完全转移到系统环境的设计上。

1.3 从“马”到“骑手”的类比

为了直观地理解Harness Engineering，以下类比被广泛引用：将AI模型想象成一匹拥有神力的烈马或独角兽。

烈马（AI模型）： 它力量强大，跑得飞快，但难以预测，可能狂奔至悬崖或原地打转。
缰绳、马鞍和跑道（Harness）： 这些马具并非是为了限制马的速度，而是为了引导其力量，确保它能沿着正确的路径前进。它们代表了架构约束和明确的边界。
马车和舒适的承载空间（Harness）： 这代表了上下文工程，它为AI提供了稳定、结构化的信息和工具，使其能在其中高效工作。
车上的镜子（Harness）： 这象征着反馈循环和可观测性，让系统能够实时监控AI的状态和表现。
车夫（Harness）： 这代表了熵管理，持续清理AI工作过程中产生的“杂草”和“杂乱痕迹”，即技术债务。

从这个类比中可以引出一个深刻的悖论：增加信任需要约束解空间（Increased trust requires constrained solution spaces）。这个看似矛盾的观点是Harness Engineering的核心洞见之一。为了让AI的行为更可预测、更值得信赖，工程师不应给它无限的自由，而必须通过明确的规则来限制其选择的范围。就像法律体系越完善，公民的自由和安全感反而越高；高速公路有了护栏，司机才敢放心地疾驰。对于AI而言，清晰的边界非但不会限制其创造力，反而能使其在明确的框架内更高效地收敛到正确的解决方案，避免在无限的试错空间中浪费算力。

这种范式的转变，也重新定义了人与AI的关系。在提示词和上下文时代，人类更像是“教师”或“对话者”，试图通过语言教会AI如何行动。而在Harness时代，人类的角色演变为“系统设计师”或“世界构建师”（world-builder）。人类不再需要就每一个具体步骤与AI交互，而是 upfront 投入精力设计一个完整的、能够自我修正的系统规则。这种转变要求工程师具备更强的系统性思维和抽象能力，其价值也从“写代码的速度”转变为“设计系统的能力”。

表1：AI工程范式比较

特征	提示词工程	上下文工程	驾驭工程
主要目标	优化单次交互	管理动态信息	构建完整系统
核心问题	“怎么说”（What to say）	“知道什么”（What to know）	“在什么条件下运行”（What conditions to run in）
主要焦点	输入提示词的设计	上下文信息的构建与管理	环境、约束与反馈机制的设计
核心机制	Few-shot、思维链、角色扮演	RAG、对话历史、工具集成	架构约束、垃圾回收、可观测性、闭环反馈
人类角色	教师/指令者	信息架构师	系统设计师/世界构建师
解决的关键局限性	一次性交互的模糊性	信息孤岛与上下文断裂	长期运行的稳定性、可控性与可维护性
代表性类比	给马下达指令	为马准备地图和指南针	为马配备完整的马具、跑道和驯马师

这张表格清晰地展示了三种范式的递进关系，强调了Harness Engineering是如何在前两者的基础上，通过系统性的环境设计，解决了AI从“能做事”到“ reliably 持续做事”的根本问题。它标志着AI工程从一门“手艺”（craft）向一门真正的“工程学科”（engineering discipline）的演进。

二、Harness的三位一体

Harness Engineering并非单一技术的名称，而是一个由三个核心支柱构成的系统工程框架。Thoughtworks的杰出工程师Birgitta Böckeler，在Martin Fowler的个人博客上发表的一篇分析文章中，将OpenAI的实验报告提炼为一个清晰的三维框架，这被视为该领域的奠基性理论之一。这三个维度分别是：上下文工程、架构约束和熵管理。它们共同构成了一个完整的Harness，缺一不可。

2.1 上下文工程（Context Engineering）

这是Harness的“信息层”，其核心目标是确保Agent在正确的时间获得正确的信息，从而解决“知识”的问题。

核心机制：
- 渐进式披露 (Progressive Disclosure)： 这是上下文工程的关键创新。它反对将一个庞大的、臃肿的指令文件（如AGENTS.md）一次性提供给Agent，因为这样会淹没其注意力，导致性能下降。正确的做法是建立一个结构化的文档体系（如docs/目录），让Agent可以根据需要，在合适的层级（全局、项目、子目录）动态地加载相关信息。这种机制类似于为新员工设计的渐进式入职培训，而非一次性塞给他们一本厚重的公司百科全书。
- 动态可观测性 (Dynamic Observability)： 这赋予了Agent“看见”其自身工作和系统运行时状态的能力，是实现自我修正闭环的关键。通过将日志、指标、追踪等可观测性数据暴露给Agent，使其能够查询服务性能、验证自身操作结果，甚至通过浏览器协议（如Chrome DevTools Protocol）直接与UI交互来复现和修复Bug。这标志着Agent从单纯的“代码生成器”向“能够理解其代码运行时行为的完整系统”的进化。
- 工具定义即协议 (Tool Definitions as Protocol)： 工具的定义不仅仅是供人类阅读的文档，更是一份与Agent达成的、精确的“通信协议”。它使用JSON Schema等结构化格式，明确规定了每个工具的名称、用途、参数、调用条件及相互关系。详尽且有约束力的工具描述，其对任务成功率的影响甚至可能超过升级模型版本本身。

2.2 架构约束（Architectural Constraints）

这是Harness的“规则层”，其核心目标是确保Agent的产出严格遵守预定义的系统边界和质量要求，从而解决“行为”的问题。

核心机制：
- 确定性护栏 (Deterministic Guardrails)： 这是实现强制约束的核心机制，也是Harness工程区别于传统提示词工程的最显著特征。它意味着将期望的系统行为和规则，从模糊的自然语言提示词，转化为由确定性代码（如Linter、CI脚本、预处理钩子）执行的硬性检查。例如，与其在提示词中说“请不要在Controller层写业务逻辑”，不如编写一个自定义Linter规则，自动扫描并拦截任何违反此架构原则的代码提交。
- 双轨校验系统 (Two-Tiered Validation System)：
  1. Tier 1: 确定性Linter： 用于执行那些可以被形式化规则清晰定义的约束（如代码风格、导入路径限制、API调用规范）。其关键在于，错误输出信息被专门设计为“对Agent友好”，即结构化、包含具体的修复建议，使Agent能够立即理解问题并自主进行修复。
  2. Tier 2: 基于LLM的审计Agent： 用于检查那些更为复杂、隐性的语义规则，这些规则难以用形式化语法表达（如“系统分层之间的依赖方向”、“关键业务逻辑的合规性”）。由一个独立的LLM Agent来扮演“架构审查员”的角色，对主Agent的产出进行二次评估。
- 最小权限原则 (Principle of Least Privilege)： 为Agent提供完成任务所必需的最小工具集，是降低复杂性和减少错误的有效策略。一项实验表明，将工具数量从20个减少到3个，可以使命中率提升约34%，因为更少的选择意味着更少的决策干扰和更少的出错机会。

2.3 熵管理（Entropy Management）

这是Harness的“维护层”，其核心目标是确保整个Harness系统自身能够随着时间推移而持续保持健康，从而解决系统的“长期可持续性”问题。

核心机制：
- Harness的自愈 (Harness Self-Healing)： 熵，在这里具体表现为Harness内部文档的腐化、约束规则的过时与矛盾。如果Harness自身变得混乱，Agent的产出也将不可避免地混乱。因此，必须设计专门的“清理Agent”或自动化流程，定期扫描整个系统，检测和修复诸如文档内容与代码库实际状态不符（文档漂移）、存在相互冲突的指令、工具定义发生变化但未更新协议等问题。

Böckeler的三位一体框架揭示了一个深刻的逻辑链条，完美地诠释了从“赋能”到“控制”，再到“维持”的完整系统设计思维：

上下文工程回答“做什么”（What）： 它确保Agent拥有理解任务和执行任务所需的所有正确信息。
架构约束规范“怎么做”和“不能做什么”（How/What not）： 它在信息充足的基础上，设立明确的边界和规则，确保Agent的行动在安全和质量的框架内进行。
熵管理保障“长期有效地做”（Sustain）： 它通过维护规则和信息本身的长期健康，确保了整个系统不会随着时间而退化，使其具备可持续性。

这三者共同构成了一个完整的、自我维持的AI工程系统。缺少任何一环，系统都会在复杂性、失控或退化中走向失败。这个框架的价值在于，它将模糊的“如何更好地使用AI”的问题，转化为了一系列具体、可操作的工程实践。

三、实践中的Harness：行业案例研究

理论框架的价值最终体现在其在真实世界中的验证。Harness Engineering虽然是一个新兴概念，但其核心实践已在多家顶尖科技公司的内部项目中得到检验，并取得了令人瞩目的成果。这些案例不仅证明了其可行性，更揭示了其在不同应用场景下的强大威力。

3.1 OpenAI的内部实验

OpenAI于2026年2月发布的实验报告是Harness Engineering领域的奠基性文献，它通过一个极具挑战性的极限实验，全面展示了这一新范式的潜力。

实验设定： 一个最初仅有3名工程师的团队，在5个月的时间内，仅使用Codex Agent（一个AI编程智能体），从空的Git仓库开始，构建了一个拥有超过100万行代码的完整内部产品。此实验的核心规则是“零人类手写代码”，其目的正是为了倒逼团队开发出能支持Agent大规模工作的工程基础设施，即一个完备的Harness。
数据亮点：
- 代码产出： 超过100万行代码。
- 吞吐量： 平均每名工程师每天合并3.5个拉取请求（PR）。
- 效率提升： 据估计，该团队的产出速度是传统开发模式的10倍。
Harness架构拆解： 这份报告详细地记录了该团队构建的Harness的各个组成部分，为我们提供了宝贵的实践参考。
- 上下文工程方面： 团队建立了一个由88个、每个不超过60行的精简AGENTS.md文件组成的“目录”体系，取代了臃肿的单文件指令。该体系与结构化的docs/目录相结合，实现了对Agent的渐进式信息披露。此外，团队还接入了可观测性栈（日志、指标、追踪），甚至集成了Chrome DevTools协议，让Agent能够直接与UI交互，实现真正意义上的端到端验证和调试。
- 架构约束方面： 团队定义了严格的、分层的代码依赖流向（如Types -> Config -> Repo -> Service -> Runtime -> UI），并编写了自定义Linter来强制执行这些规则。尤为关键的是，Linter的错误信息输出格式被专门设计为“对Agent友好”，使其能直接理解并自动修复问题，从而在Agent内部形成了“违规->检测->修复”的闭环。
- 熵管理方面： 团队部署了专门的“清理Agent”，这些Agent会定期扫描代码库，主动识别并修复文档与代码脱节、模式违规等问题，起到了代码库“垃圾回收”的作用，以对抗技术债务的指数级累积。

3.2 LangChain的性能飞跃

如果说OpenAI的实验展示了Harness Engineering在极限条件下的巨大产能，那么LangChain的实验则为“环境优于模型”这一核心论点提供了强有力的、干净的实证支持。

实验设定： LangChain团队进行了一项对照实验，他们在不修改底层模型任何参数的前提下，仅对其编码Agent的运行环境（即Harness）进行了优化。
数据亮点：
- 性能提升： 在Terminal Bench 2.0这一权威的代理编码基准测试中，该Agent的得分从52.8%飙升至66.5%。
- 排名变化： 排名从全球第30位跃升至第5位。
关键启示： 这个案例完美地诠释了Harness Engineering的本质——环境比模型更重要（the environment is more important than the model）。它雄辩地证明，通过精心的环境设计，即优化文档结构、验证回路和追踪系统，可以带来远超模型升级所带来的性能飞跃。这并非否定模型进步的价值，而是强调在模型能力达到一定阈值后，优化运行环境是提升系统整体效能的最大杠杆。

3.3 其他先驱采用者

除了上述两个标志性案例，其他头部公司也已开始将Harness Engineering的理念付诸实践。

Stripe： 支付巨头Stripe构建了一个名为“Minions”的工业化Harness系统，每周能够合并超过1,300个完全由AI编写的代码PR，且仅需人类工程师进行最终审查。Stripe的架构特色在于其混合模式的“蓝图”设计：可预测的任务（如推送代码、运行Linter、触发CI）均由确定性代码处理，而将LLM仅用于需要判断和创造力的环节。这种设计将非确定性的AI限制在了一个“可控的盒子”中，极大地提升了整个系统的可预测性和稳定性。
Anthropic： 在其内部工程文档中，Anthropic已将Claude Code定位为一种“灵活的Agent线束”（flexible agent harness）。这表明，构建Harness的理念正在从最终用户应用层，向上游的工具供应商产品设计思路渗透，预示着整个行业对AI工程化的理解正在趋于一致。

这些案例共同指向一个共同的结论：Harness Engineering是当前AI时代最具杠杆效应的工程投资方向。在大型模型的基础能力快速进步并趋于同质化的背景下，模型本身的差异已经不再是决定成败的关键因素。未来的技术竞争，将越来越依赖于企业是否能够构建更强大、更精细、更可靠的Harness系统。

这种趋势的深层影响在于，它将AI领域的竞争维度从“数据飞轮”（Data Flywheel）提升到了“系统飞轮”（System Flywheel）的层面。在一个成熟的Harness系统中，每一次Agent的成功或失败，都不仅仅是单次任务的完成或报错，更是对整个系统的一次反馈和学习机会。这些经验会被自动地编码到上下文文档、架构约束规则和熵管理策略中，从而使得Harness本身随着时间推移而不断进化，形成一个自我强化的良性循环。因此，一个公司的竞争优势不再仅仅取决于其数据量或模型参数，而越来越取决于其Harness的质量和进化速度，即其将经验转化为系统性规则的能力。这预示着软件工程的核心竞争力，将从代码实现的速度，彻底转向系统设计的质量和迭代效率。

四、工程师角色的转变

Harness Engineering的兴起，并非仅仅引入了一套新的技术工具，它正在根本性地重塑软件工程师的工作内容、技能要求以及团队协作模式。这场变革的核心，是工程师角色的“元升级”——从“代码实现者”转变为“AI系统设计师”。

4.1 新职责

在新的范式下，工程师的核心职责发生了显著转移，从编写具体的功能代码转向设计和维护AI工作的底层系统。

代码生成器的架构师： 工程师的核心任务不再是亲手编写每一行代码，而是设计一个能让AI高效、正确地生成代码的系统。这包括设计清晰、可发现的文档结构，编写能够被AI理解和响应的自定义Linter规则，以及搭建能让AI进行自我验证的自动化流水线。
意图的翻译官： 工程师扮演了将模糊的人类业务需求（如“提升代码质量”）转化为精确、可被机器执行的规则和指令的角色。这个过程要求工程师具备更强的抽象思维和形式化表达能力，能够将业务目标拆解为一系列具体的、可验证的系统约束。
系统园丁： 与传统的“救火队员”不同，Harness工程师更像是一位园丁，其主要职责是预防问题的发生。他们通过构建强大的自动化护栏、验证机制和清理流程，主动地对抗系统的混乱（熵），确保整个AI工程生态系统长期保持健康和生产力。

4.2 新技能

角色的转变必然带来技能要求的更新迭代。未来的工程师需要掌握一套全新的、以系统设计为核心的能力组合。

系统思维 > 代码速度： 对复杂系统的理解深度，以及如何设计一个具有反馈回路的控制系统，其重要性已经远远超过手写代码的速度和熟练度。核心竞争力在于“架构即控制”的思维模式。
形式化逻辑表达： 能够熟练地将非正式的规则和需求（如“保持模块解耦”），使用形式化的逻辑语言（如Linter规则、类型定义、断言）表达出来，以便让确定性的自动化工具去执行。
概率性系统调试： 调试一个由AI驱动的概率性系统，与调试传统软件有着本质区别。工程师需要学会分析Agent的行为日志、理解其在工具使用和信息处理上的决策逻辑，并设计出能够复现和收敛概率性错误的验证方法，这是一项全新且至关重要的技能。
AI行为心理学： 工程师需要深入理解所选AI模型的“思维”习惯、优势和缺陷。例如，知道模型在长上下文中容易“迷失”，因此需要采用渐进式披露；知道模型的注意力可以被特定的格式化标签引导，因此需要设计结构化的输出协议。这是一种关于如何与AI有效“沟通”和“协作”的元知识。

4.3 新的协作模式

Harness Engineering正在催生更加扁平化、人机协作更紧密的新型团队结构。

扁平化的组织结构： 由于Harness极大地提升了个体生产力，传统的大规模、多层级软件工程团队正在被更小、更精简的单元取代。OpenAI的实验团队仅3-7人就完成了百万行代码的产出，Stripe的工程师可以同时指导多个Agent并行工作，这些都预示着未来“完整生命周期拥有者”的单人团队或两人团队可能成为常态。
人机共生工作流： 人类的精力被解放出来，专注于高层次的架构设计、复杂问题攻关和关键决策；而AI Agent则承担起大量的代码起草、测试编写、文档更新等常规性、高重复性的任务。人类与AI之间的界限变得模糊，协作更加无缝和交融。
涌现出的“学徒缺口”问题： 这种模式的转变也带来了一个深刻的潜在风险，即“学徒缺口”（Apprentice Gap）。如果初级开发者一入行就沉浸在由AI生成的、结构完美的代码库中，并直接使用高度封装的Harness工具，他们可能会错过通过“亲手写代码”、“调试晦涩错误”、“在没有Linter帮助的情况下理解性能”等过程所获得的宝贵直觉和深层系统理解。长此以往，整个行业可能面临下一代工程师基本功缺失的危机。因此，如何设计新的学习路径，在享受AI生产力的同时，保留并传承传统开发中积累的深度经验，将成为一个严峻的挑战。

五、挑战与未来之路

尽管Harness Engineering展现了巨大的潜力，并为AI工程化提供了强大的新范式，但它并非一个万能的解决方案。这一领域仍面临着诸多严峻挑战，并引发了一些深刻的行业辩论。对这些问题的深入思考，是确保Harness Engineering能够健康、可持续发展的关键。

5.1 实施障碍

将Harness Engineering从理论蓝图或实验项目，推广到大规模的企业级应用中，存在显著的实践障碍。

遗留代码库改造困境： 现有的大多数成功案例如OpenAI、Stripe，均是从零开始的绿地项目（Greenfield）。如何将这些项目中的Harness最佳实践，有效移植到庞大、复杂且历史悠久的遗留代码库中，是一个巨大的挑战。在一个从未实施过严格静态分析的老旧代码库中突然启用全面的Linter规则，可能会产生海量的错误，导致系统瘫痪，这使得渐进式的、兼容性的改造之路异常艰难。
功能正确性验证的“验对难”问题： Harness Engineering在防止Agent“做错”（防错）方面表现出色，但在确保Agent“做对”（验对）方面仍存在根本性困难。架构约束和Linter可以有效阻止坏的代码风格或错误的依赖关系，但它们很难验证一个功能在业务逻辑上的正确性。一个被AI生成的功能，可能完全符合代码规范，但其实现的业务逻辑却可能与初衷南辕北辙。解决这个问题，可能需要更先进的测试技术，如利用AI生成基于自然语言需求的测试用例，或构建能够模拟真实用户行为的、更智能的端到端测试Agent，但这本身就是一个极其复杂的任务。
长期技术债务的未知模式： AI生成代码的模式与人类不同，它可能会无意识地复现并扩散代码库中已有的坏模式，从而以一种新的、可能更隐蔽的方式积累技术债务。这种由AI驱动的熵增规律尚不完全清楚，如何有效地量化、追踪和管理这种新型技术债务，将是未来DevOps和SRE（站点可靠性工程）面临的核心课题。

5.2 未解决的争论

Harness Engineering的兴起，也引发了行业内关于未来发展方向的两大核心辩论。

大模型 vs. 大Harness： 这是当前最激烈的辩论之一。一方观点认为，未来的决定性因素依然是更庞大、更智能的基础模型；另一方则认为，当模型能力达到一定水平后，真正决定成败的是其外围的Harness系统。
一种有影响力的分析认为，这并非一个非此即彼的问题，而是一个关于任务复杂度与时间跨度的函数。对于短期的、简单的任务，投资一个更强大的模型是更高效的选择。然而，随着任务复杂度和时间跨度的增加，Harness的价值呈指数级增长。在长期、复杂的长期项目中，一个优秀的Harness变得不可或缺。这预示着行业的未来可能会出现分工：基础模型公司专注于提升模型能力的“天花板”，而应用层公司和开发者则专注于构建实现可靠交付的“地板”（即Harness）。
人机关系的哲学分歧： 关于人类在Harness时代应扮演的角色，存在两种对立的哲学。
- “人类掌舵，AI执行”派： 以OpenAI的实践为代表，主张人类应退居幕后，专注于高层次的战略规划和系统设计，将执行细节完全交给Agent。
- “人类作为反馈源”派： 另一些实践者认为，人类最有价值的输入应是对AI输出的直接反馈——即评分和修正。从这个角度看，最佳的人机协作模式，是人类作为“教师”不断训练AI，而非作为“管理者”监督AI。
  这两种哲学将导向截然不同的Harness架构设计，其核心在于人类介入（Human-in-the-loop）机制的设计。这将是未来研究和实践中需要持续探索和权衡的关键点。

5.3 未来的轨迹

尽管挑战重重，Harness Engineering的未来发展方向已经初现端倪。

从“一次性脚手架”到“长期服务平台”： Harness的理念正在向更广泛的领域渗透。人们开始将Kubernetes等复杂系统视为一个供AI使用的“服务”，其YAML配置文件和API不再是给人看的，而是给AI的交互界面。未来的平台工程，将需要考虑“AI友好性”（AI-friendliness），即为AI构建自动化的服务目录、声明式API和自助式内部开发者平台（IDP）。
AI原生应用架构的兴起： 随着Harness Engineering的成熟，一种全新的应用架构风格正在形成。这类架构的设计原则包括：以Agent为核心、通过约束定义信任、依赖生成式UI以及基于反馈循环进行演化。这标志着软件设计范式从面向对象或面向服务的架构，向面向智能体的架构的根本性转变。
标准化与工具生态的爆发： 如同历史上的每一次技术浪潮，一个新兴领域的成熟必然伴随着标准和工具生态的繁荣。可以预见，未来将出现开源的Harness框架、通用的可观测性标准以及用于构建自定义Linter和护栏的SDK。这些工具的普及将进一步降低AI工程化的门槛，推动整个行业的工业化进程。

六、从理论到实践：构建您的第一个Harness

为了将前述的理论和案例转化为 actionable 的指南，本节提供一个简明的、分阶段的实践路线图，旨在帮助个人开发者、技术团队和组织领导者从零开始构建他们的第一个Harness系统。这借鉴了HashiCorp联合创始人Mitchell Hashimoto提出的六阶段采用旅程，并将其梳理为一个更结构化的成熟度模型。

6.1 第一级（个人）

这是Harness Engineering的入门阶段，目标是建立个人与AI协作的最佳实践。

AGENTS.md 地图： 从为个人项目创建一个精简的AGENTS.md文件开始。这份文件不是百科全书，而应是一份“地图”，包含项目核心架构、常用命令（运行测试、Lint）、以及Agent绝对不能触碰的关键部分。
模式识别与规则化： 在日常工作流中，留意那些反复出现的、耗费你时间的小问题。例如，每次写完一小段代码后都要手动运行格式化工具。将这些重复性的“摩擦点”自动化，例如配置一个 pre-commit Git 钩子来自动运行 Linter 和 Formatter。这是从“自己动手”到“设计系统”的初步思维转变。
信任的建立： 通过“手动做一遍，然后让AI做一遍”的方式，来建立你对AI能力的直觉和信任边界。先自己手动完成一个任务，再让Agent尝试完成同样的任务。这个过程能帮助你深刻理解AI的优势和短板，为后续更复杂的任务授权提供基础。

6.2 第二级（团队）

当实践扩展到团队协作时，重点转向建立标准化、可共享的工程惯例。

共享的 Harness 库： 将第一级中成功的AGENTS.md和自动化脚本进行标准化和模块化，创建为团队共享的Harness库。这个库可以作为一个独立的Git仓库，或者集成到团队的项目模板中。
强制执行核心护栏： 在团队的CI/CD流水线中，集成强制性的基础检查。必须包括至少一种确定性的Linter（如ESLint、Pylint、Checkstyle）和一套自动化测试（单元测试、集成测试）。这是确保代码质量底线、防止低级错误进入主分支的基石。
文档即协议： 将项目中最重要的接口、数据流和架构决策，使用清晰、无歧义的语言写进docs/目录。这份文档不仅是为新成员准备的入职手册，更是为Agent准备的、需要严格遵守的交互协议。

6.3 第三级（组织）

在组织层面，Harness Engineering的落地需要制度化的支持和更高级的自动化。

可观测性即上下文： 构建一个统一的可观测性平台，将日志、指标和链路追踪集中起来。最关键的一步是，确保这个平台对AI Agent是可查询的。为Agent提供能够检索和分析运行时数据的工具，这是实现高级自我验证和调试的前提。
AI驱动的垃圾回收： 部署一个定期（例如每天或每周）运行的自动化任务。该任务负责扫描整个代码库，执行诸如清理无用代码、更新过时文档、识别代码坏味道、以及确保架构约束规则本身的一致性等操作。这是对抗组织级熵增、维持系统长期健康的关键。
评估与持续改进： 建立一个持续的、系统化的评估机制（Evals）。通过定期抽样检查Agent产出的代码质量、功能正确性和架构合规性，获得量化数据，从而有针对性地改进Harness的各部分（如优化提示词、增加缺失的Linter规则、修复错误的测试用例）。

6.4 HRSS成熟度模型

为了更系统地评估和指导实施过程，以下提出一个“HRSS（Harness成熟度模型）”。该模型旨在帮助组织诊断当前所处的阶段，并明确向下一阶段演进所需的关键行动。

表2：Harness成熟度模型（HRSS）

维度	级别1：无（Ad-hoc）	级别2：有（Basic）	级别3：已定义（Defined）	级别4：已管理（Managed）	级别5：优化中（Optimizing）
上下文管理	无结构化指导；信息杂乱，导致AI频繁误解需求。	存在简单的AGENTS.md或README文件，但内容可能臃肿或过时。	结构化的docs/和AGENTS.md“地图”，实施渐进式信息披露；Agent能访问静态文档。	动态可观测性数据（日志、指标）对Agent可查询；Agent具备基本的UI验证能力。	系统能够自动为Agent生成和推送最相关的上下文；上下文系统具备自我学习和优化能力。
架构约束	无自动化约束；仅依赖人工Code Review，瓶颈明显。	基础Linter（如代码风格检查）在CI中运行；无Agent友好的错误输出。	自定义Linter规则强制执行关键架构边界；Linter错误信息被Agent理解。	实施双轨验证：确定性Linter + 基于LLM的架构审计Agent。	约束规则库高度成熟，覆盖广泛；系统能够自动从错误中生成新的约束规则。
熵管理	无清理机制；技术债务随AI产出同步高速增长。	人工偶尔进行文档和代码清理；无固定节奏。	定期（如每周）运行“清理Agent”任务，扫描和报告文档漂移、坏模式。	清理任务自动化运行并提交修复PR；熵增得到显著抑制。	熵管理成为核心竞争力；系统能够预测熵增模式并主动进行重构。
评估（Evals）	无系统性评估；质量依赖运气。	人工进行随机抽查。	定义了基础的、自动化的代码质量评估（如测试覆盖率、复杂度）。	实施多维度的Evals（功能正确性、性能、安全性）；结果用于报告。	Evals覆盖业务逻辑正确性；评估结果直接驱动Harness的持续迭代和优化。

这个成熟度模型为组织提供了一个清晰的评估框架和战略路线图。它帮助管理者识别当前的短板，并理解要达到更高生产力水平和可靠性，需要在哪些关键领域进行投资。从“有”到“已定义”，再到“已管理”和最终的“优化中”，每个阶段的提升都对应着Harness系统自主性、可靠性和智能化水平的飞跃。

结论

Harness Engineering 不仅仅是一种新工具或新技术，它标志着软件工程领域一个根本性的范式转移。随着 AI 模型的能力曲线趋于平缓，竞争的焦点正在从“模型能做什么”转向“我们如何引导模型 reliably 地完成工作”。

本报告的分析表明，未来的软件系统将越来越多地以“概率性核心”（AI模型）与“确定性外壳”（Harness）的架构形式存在。工程师的核心价值将从编写优秀的代码，转向设计优秀的系统规则。那些能够最早理解并掌握 Harness Engineering 原则的组织，将在 AI 时代的软件生产力竞赛中占据主导地位。

Harness Engineering 的兴起，并非将工程师推向了边缘，而是将他们推向了更高的战略层面。通过承担系统设计师、规则翻译官和生态园丁的新角色，工程师将从繁琐的重复性劳动中解放出来，更专注于最具创造性和战略性的工作。可以预见，在未来几年内，Harness Engineering 将成为软件工程师教育和职业发展中的核心内容，它所倡导的系统化、约束化的设计理念，也将深远地影响平台工程、DevOps 乃至整个技术产业的未来走向。