近日，玄派品牌正式推出了玄机16 2026笔记本电脑，这款产品精准定位于专业设计师、视频创作者等需要高强度使用的群体，旨在提供无短板、超流畅的顶级性能体验，满足他们在复杂项目中的苛刻需求。

玄机16 2026配备了一块16英寸的显示屏，分辨率达到2560×1600，并支持180Hz的高刷新率，为用户带来丝滑流畅的操作手感。同时，屏幕覆盖100% sRGB色域，能够满足专业创作中对色彩准确性的严格要求。500尼特的高亮度设计使其在户外强光环境下也能清晰可见，无论是日常观影还是游戏娱乐，都能提供沉浸式的视觉享受。

在机身材质方面，玄机16 2026采用了金属与复合材料的组合，既确保了出色的质感，又增强了整体的耐用性。机身厚度为24.9毫米，重量控制在2.4千克，在旗舰级配置的机型中实现了便携性与高性能之间的巧妙平衡，外出携带时不会显得过于笨重，非常适合需要经常移动办公的专业人士。

性能核心上，玄机16 2026搭载了AMD锐龙AI Max+ 395处理器，这款芯片是AMD移动端的旗舰AI产品，集成了强大的AI算力和卓越的多核性能，可以轻松应对4K视频剪辑、3D建模等高强度任务。标准配置包括128GB LPDDR5X-8000高频内存和2TB PCIe 4.0固态硬盘，读写速度出众，彻底解决了多任务处理时的卡顿问题和存储容量焦虑。

散热系统方面，玄机16 2026采用双风扇设计，能够快速导出机身内部的热量，确保在长时间高负载运行下保持稳定，避免因过热导致性能降频，从而影响用户体验。此外，内置99Wh大容量电池和Wi-Fi 6E高速网卡，使续航时间更持久、网络连接更流畅，轻松满足户外移动办公、出差旅行等多种场景的需求。

接口配置上，玄机16 2026提供了2个USB-C接口、3个USB-A接口、1个HDMI 2.1接口、1个TF卡插槽、1个2.5G网口、1个Oculink接口以及1个3.5mm音频接口。接口种类齐全，覆盖了大多数外接设备的需求，用户无需额外购买扩展坞即可方便地连接各类 peripherals。

玄机16 2026的128GB内存加2TB存储版本首发价格为22999元。结合其拉满的硬件配置与全面的功能表现，这款产品在高端旗舰笔记本电脑中展现了突出的性价比，非常适合那些追求顶级性能的专业用户考虑入手。

目前，玄派玄机16 2026已经全面开售。以22999元的首发价，搭配顶级的硬件配置，它在性能、便携性与扩展性之间取得了良好平衡，能够适配各类专业场景的复杂需求。这款产品堪称2026年高端专业笔记本电脑市场的标杆之作，诚意十足，值得追求顶级体验的专业用户重点关注并考虑入手。

在构建AI智能体（Agent）的领域，业界长期以来围绕三种主要架构路径展开讨论：SDK、Frameworks和Scaffolding。这三种方式分别代表了灵活性与结构性光谱上的不同位置，各自拥有其独特的适用场景。

然而，进入2026年，一种全新的第四种模式悄然兴起，它直接构建在上述三种架构之上——它被称为 Harness。OpenAI和Anthropic等领先机构都已正式采用这一术语。Martin Fowler曾撰文深入分析，arXiv上亦有论文给出了其形式化定义。这并非一个凭空炒作的流行词，而是那个长期缺位、却最终决定AI智能体能否在生产环境中稳健运行的核心架构层。

重新定义：Harness的本质是什么？

首先需要明确一个关键点：Harness并非智能体本身。

它是管理智能体如何运行的一整套软件系统，负责处理其完整的生命周期——包括工具调用、内存管理、失败重试、人工审批介入、上下文工程优化以及子智能体的调度等。它的存在让大语言模型能够专注于其最擅长的推理工作，而将所有繁杂的“后勤”事务交由Harness处理。

Philipp Schmid使用了一个非常贴切的计算机类比来解释这一概念：

在这个比喻中，大模型相当于原始的CPU处理能力，上下文窗口是有限的工作内存（RAM），而Harness则扮演着操作系统的角色——负责管理上下文切换、初始化任务序列、驱动标准工具接口。智能体则是运行在这一整套基础架构之上的最终应用程序。这个比喻精准地厘清了各组件之间的层次关系。

厘清关系：Harness如何补全技术栈？

SDK、Scaffolding和Framework共同回答了一个核心问题：如何将AI智能体构建出来？

Harness则面向一个截然不同的问题：智能体构建完成之后，如何确保它能够安全、稳定、高效地持续运行？

这两者并非替代关系，而是互补共存。你完全可以使用Framework来构建一个Harness系统，它们处于技术栈的不同层次。这四种方式的对比如下图所示：

核心架构：Harness的六大组件

根据parallel.ai团队的梳理，并结合OpenAI与Anthropic官方发布的内容，一个成熟的Harness系统通常包含以下六个核心组件：

1. 工具集成层：通过预定义的协议，将大模型与外部API、数据库、代码执行环境及各类自定义工具无缝连接起来。
2. 内存与状态管理：构建多层记忆体系，包括工作上下文、会话状态和长期记忆，实现在单个上下文窗口之外的持久化状态管理。例如，Anthropic采用“进度文件”和git历史记录来桥接不同会话，确保智能体在任务切换后仍能知晓自身所处位置和已完成进度。
3. 上下文工程与提示管理：超越静态的提示模板，能够根据当前任务状态动态决策每次调用模型时应注入哪些信息，实现信息的主动筛选与优化。
4. 规划与任务分解：引导模型将复杂目标拆解为结构化的任务序列，逐步推进，而非试图一次性解决所有问题。
5. 验证与防护：集成格式验证、安全过滤及自我纠错循环。当智能体运行陷入停滞时，Harness将其视为一种需要补充信息的信号，而非直接抛出错误导致进程崩溃。
6. 模块化与可扩展性：所有组件均采用插拔式设计，支持独立启用、关闭或替换，确保系统各部分修改互不影响，具备高度的灵活性。

实践洞察：生产环境中的Harness形态

Claude Code 便是一个典型的Harness实例。它负责读取整个代码库、管理文件系统访问权限、调度子智能体、编排工具调用、维护跨会话记忆，并内置了多种防护机制。开发者得以聚焦于核心编程任务，所有复杂的基础设施问题均由Harness妥善处理。

OpenAI Codex 的成功同样依赖于Harness工程方法。其团队运用这套架构，搭建了超过百万行代码的庞大项目，全程无需手动编码。Harness作为主要接口，当智能体遇到障碍时，反馈信息会直接回流至代码库，驱动上下文工程和架构约束的持续演进与优化。

在OpenAI的CUA（计算机使用）示例应用中，其Runner管理器处理的正是“截取屏幕 → 执行操作 → 验证结果 → 进入下一循环”的完整工作流闭环。模型专注于决策“做什么”，而Harness则确保这些决策能够被安全、准确地执行。

趋势演进：Framework层功能的分化与吸收

当前出现了一个显著趋势：传统Framework所处理的许多职责，正逐渐被模型自身能力所吸纳。

诸如智能体定义、消息路由、任务生命周期管理、依赖关系处理以及工作进程生成等功能，在过去需要开发者借助Framework实现，如今约80%已可由模型原生支持。剩余的20%——包括状态持久化、确定性重放、成本精细化控制、系统可观测性以及错误恢复机制——则恰好是Harness专注的领域。

因此，Framework层不仅在缩减，更在发生本质上的分化：智能与决策能力上移至模型层，而可靠的基础设施支撑则下沉至Harness层。

Harness与Framework的核心区别变得非常清晰：Framework指导开发者如何构建应用程序，而Harness则指导智能体如何安全运行。使用Framework时，开发者编写编排逻辑；使用Harness时，模型自主制定计划，Harness则作为安全护栏确保其不偏离轨道。

范式转变：AI智能体构建的新问题域

过去，业界核心问题是：应该选择哪个Framework？

如今，更为关键的问题演变为：我们的Harness应该设计成什么样子？

Harness的质量直接决定了智能体项目的成败。一个优秀的Harness能够有效管理人工审批流程、控制文件系统访问权限、编排工具链、调度子智能体、优化提示工程并维护完整的生命周期，以最少的干预避免灾难性失败的发生。

实施路径也愈加清晰务实：从构建稳定可靠的原子化工具开始，放手让模型进行任务规划，随后逐步引入防护机制、重试策略以及验证流程。这正是Harness工程化的基本演进思路。

特别形态：轻量级Markdown/Prompt Harness

值得一提的是 Markdown/Prompt Harness 这一特殊形态，例如Anthropic的CLAUDE.md技能文件。它将编排指令直接嵌入系统提示词或结构化的Markdown文档中。

在这种模式下，大语言模型自身充当了循环控制器——它读取并解析Harness中定义的规则，然后自主执行。当模型能力足够强大，能够进行有效的自我引导，且项目需要快速迭代、避免频繁修改底层代码时，这是一种极具吸引力的轻量级解决方案。

01

Harness 概念详解：模型与系统的桥梁

Harness 工程的核心在于围绕模型构建系统，将其转化为能够实际运作的引擎。模型本身承载智能，而 Harness 则使这种智能得以有效应用。本文将首先明确定义 Harness 的概念，然后从模型这一基础出发，系统地推导出当前阶段以及未来 Agent 所需的核心组成部分。

02

Harness 的必要性：弥补模型的内在局限

Agent 的许多期望功能，模型本身并不具备，这正是 Harness 存在的主要意义。在绝大多数场景中，模型仅能接收文本、图像、音频或视频等输入，并输出文本或结构化调用结果。默认情况下，它无法实现以下能力：

• 在多次交互之间维持持久化状态
• 直接执行代码或程序
• 获取实时更新的信息
• 自主搭建运行环境并安装所需依赖

所有这些能力都归属于 Harness 层的职责。大语言模型的结构决定了，必须有一层外部机制对其进行封装，才能使其参与到真实的工作流程中。一个简单的例子是，为了实现流畅的聊天体验，我们通常使用一个 while 循环来维护历史消息记录，并不断追加新的用户输入。这种广泛采用的形式本质上就是一种 Harness 实现，其作用是将期望的 Agent 行为转化为具体的系统逻辑。

03

从目标行为到Harness设计：逆向工程思维

Harness 工程的核心作用，是协助人类注入有效的先验知识，从而引导和塑造 Agent 的行为模式。随着模型能力的持续提升，Harness 也逐渐被用于以更精细的方式扩展或修正模型，使其能够胜任以往难以完成的任务。本文并不试图穷举所有可能的 Harness 功能，而是从“让模型能够完成实际工作”这一根本目标出发，推导出一组关键能力。其基本思路是：我们期望实现（或需要修正）的特定行为 → 对应的 Harness 设计方案。

04

文件系统：持久化存储与上下文管理的基础

我们希望 Agent 具备持久化存储能力，用以处理真实世界的数据、转移超出上下文窗口容量的信息，并在不同的工作会话之间保持连续性。然而，模型只能直接处理其上下文窗口内的信息。在引入文件系统抽象之前，用户只能通过手动复制粘贴的方式向模型提供内容，这种方式效率低下，且完全不适用于自动化运行的 Agent。

现实世界的工作本身便是通过文件系统来组织的，而模型在其训练过程中也已学习了这种模式。因此，一个自然而高效的解决方案是：由 Harness 层提供文件系统抽象以及相关的操作工具。文件系统堪称最基础的 Harness 原语之一，它赋予了 Agent 多项关键能力：

• Agent 拥有一个专属的工作空间，可以读取数据、代码和文档。
• 信息能够被逐步写入或转移，避免了所有内容都必须堆积在有限的上下文中。
• 中间结果可以被保存下来，从而实现跨会话的状态维持。

文件系统同时也构成了一个天然的协作界面，多个 Agent 或人与 Agent 之间可以通过共享文件进行协同工作，例如 Agent Teams 这类架构便高度依赖于此。再结合 Git 版本控制系统，文件系统进一步获得了版本追踪能力，使得 Agent 可以跟踪进度、回滚错误操作并进行分支实验。后文还将再次提及文件系统，因为它实际上是许多其他高级能力得以实现的基石。

年初，OpenAI的架构师Bill Chen与Brian Fioca在一次演讲中详细剖析了构建Codex所克服的挑战，并探讨了Coding Agent新兴的应用模式。他们指出，一个Coding Agent主要由三部分构成：用户界面、模型以及Harness。

用户界面是显而易见的交互入口，可能表现为命令行工具、集成开发环境，或是云端及后台的Agent。模型部分则较为直白，例如OpenAI的GPT-5.1系列或其他供应商的模型。至于Harness，则是一个相对复杂的核心组件，它直接与模型进行交互。在最简化的视角下，可以将其视为由一系列提示（Prompts）和工具组合而成的核心Agent循环，负责为模型提供输入并处理其输出。

Harness本质上是模型的接口层，充当着模型与用户、与代码世界之间的交互媒介。它集成了模型在多轮对话中工作、调用工具、最终编写代码并解读用户意图所需的所有组件。对于某些产品而言，Harness甚至是其实现价值的关键所在。

日前，Anthropic发布了一篇题为《Harness design for long-running application development》的博客文章。文中明确，Harness指的是一种用以支撑复杂AI智能体（Agent）长期稳定运行的外部框架、控制结构与编排系统。它并非单一算法，而是一整套工程化的“脚手架”，其核心目的在于管理和放大AI模型的内在能力。

Harness是构建在提示词工程（Prompt Engineering）之上的更高层级抽象。如果说提示词决定了单次对话交互的质量，那么Harness则决定了多轮对话、多智能体协作以及长时任务的执行流程与整体可靠性。

Harness的核心作用在于解决AI在执行复杂、耗时任务时可能出现的“失控”问题（Go off the rails），通过外部的控制机制来弥补模型自身可能存在的内在缺陷，例如对上下文长度的焦虑或倾向于自我美化的倾向。

无论是OpenAI还是Anthropic，都明确认定Harness是实现Coding Agent落地的关键环节。然而，这两家顶尖AI巨头在理念上产生了显著分歧：究竟应该将Harness设计得强大而厚重，还是应该追求其轻薄与轻量？

理念分野：Harness框架的厚薄之争

行业内部似乎正在形成一种新的共识：决定AI编程能力上限的，已不再是模型单次生成代码的质量，而是Harness Engineering的水平。

在Anthropic近期的工程分享中，展示了对“长时运行智能体”的深度探索。为了解决AI在长时间任务中容易“脱轨”的问题，他们构建了一套极其严密和复杂的Harness体系：

• 结构化交接：强制要求AI在上下文耗尽前生成“进度文件”，将任务状态外置保存。
• 多智能体分工协作：引入规划器、生成器、评估器等不同角色的智能体进行分工。
• 上下文重置机制：为避免“上下文焦虑”，直接清空对话历史，仅保留结构化的任务产物，为接手的智能体提供一张干净的“白板”。

这种设计思路的本质是 “把Harness做强、做厚” 。Anthropic认为，只要外部框架足够健壮和精密，就能支撑起最复杂的开发任务，确保过程的可靠与可控。

然而，OpenAI Codex的开源负责人Michael Bolin近日在一次访谈中，释放出了与Anthropic截然相反的信号。这场对话围绕一个核心议题展开：在AI编码时代，真正改变软件开发范式的，究竟是“大模型本身”的能力飞跃，还是围绕模型构建的“Harness”工程体系？

Michael在访谈中明确提出，Harness不应该无限膨胀。他基于Codex的构建理念，阐述了一个被他们观察到的重要趋势：在理想状态下，harness应当“尽可能小”，而模型的能力应“尽可能强”。Codex的设计哲学致力于减少专用工具的数量、避免对模型进行过度干预，转而让模型在更接近真实计算环境（例如终端）的空间中自主探索解决方案。这种“AGI导向”的思路，本质上是在减少人为制定的规则对模型的束缚，将更多的决策权交还给模型本身。当然，Michael也强调，在这一过程中，安全性（security）和隔离性（sandboxing）是不可妥协的底线，这也构成了Harness不可替代的核心职责。

Codex的理念更倾向于 “把Harness做薄、做轻” ，具体表现在以下几个方面：

• 最小化工具依赖：刻意减少专用工具，鼓励模型直接使用通用的终端（Terminal）来解决问题。
• 提供环境而非框架：Harness仅提供必要的沙箱安全环境和基础接口，不过多进行流程控制。
• 能力回归模型本身：将探索、决策和执行的主要逻辑，尽量交由模型自身通过学习和推理来完成，而不是依靠外部编排框架进行硬编码。

这种思路背后隐含的担忧是，过于复杂的Harness反而可能限制模型的创造性，将其“教傻”，或者带来沉重的工程负担，拖慢整个系统的迭代与进化速度。

OpenAI与Anthropic的两种路径选择，给所有AI从业者提出了一个必须深思的问题：Harness，究竟是AI编程的终极形态，还是一个正在被快速放大、终将被模型能力内化的中间状态？

这个问题的答案，将在根本上决定未来AI编程产品的形态：

• 如果Harness是终局：那么未来的竞争将是“框架之战”。谁能够打造出最健壮、最通用的Harness（例如Anthropic展示的多智能体架构），谁就能主导未来的开发流程。AI编程将演变为一场“系统工程与AI能力”的结合竞赛。
• 如果Harness是中间态：那么当前复杂的框架设计，主要是为了弥补现有模型的能力短板。随着模型能力（如记忆、长上下文、推理能力）的指数级提升，这些外部编排逻辑最终会被模型内化吸收。到那时，Harness将退化为一个简单的运行环境（Sandbox），而核心竞争力将再次回归到基座模型本身的能力上。

深入对话：Codex负责人的轻量化哲学

以下是经整理的Michael Bolin访谈要点，探讨了AI编码与Harness工程的未来。

关于AI编码的核心与Harness Engineering的重要性

主持人：在构建智能体的团队中，有人认为真正的变革在于围绕模型设计环境（Harness），而非仅仅是模型写代码的能力。你如何看待？

Michael：模型无疑主导着整体体验。但我们发现，在Harness这一层仍然存在巨大的创新空间。这不仅仅是一个研究课题，对我们团队而言，关键在于工程与研究的协同——共同开发智能体，确保Harness能够让其发挥最佳能力。同时，还要为智能体提供“合适”的工具，并确保这些工具在模型的训练阶段就已经被“见过并练习过”，这样在真实产品中调用时，模型才不会感到“陌生”或容易出错。

主持人：能否具体定义一下Harness，以及它为何变得如此关键？

Michael：Harness有时也被称为Agent循环（Agent loop）。它负责调用模型、进行采样，并提供上下文：包括任务目标、可用工具以及下一步指示。接着，模型返回响应——通常是一个工具调用指令。有些工具很简单，比如运行一个可执行文件并返回结果。我们也实验过更复杂的工具，例如控制整台机器、操作用户的笔记本（更像交互式终端），或是执行网络搜索。

对于Codex这样的编码Agent，我们极度重视安全与沙箱机制。因此，Harness的一项核心工作就是从模型接收Shell命令或计算机操作指令，并确保它们在沙箱中安全执行，或遵循用户设定的策略。这部分实际上非常复杂。关键在于，既要充分释放模型的全部能力，又要确保其在用户机器上安全、受控地运行。

Codex的发展轨迹与安全实践

主持人：自Codex推出以来，它的发展情况如何？

Michael：反响非常积极，使用量相比年初增长了大约五倍。我们在2025年4月随o3和o4 mini模型一同发布，当时模型在工具调用和指令遵循方面还不够完善。8月GPT-5发布后，我们更新了CLI，这是一个关键转折点。随后推出的VS Code插件用户增长极快，甚至超过了CLI。今年初上线的独立应用也迅速流行起来。我认为它在很多方面都是开创性的。

主持人：在你看来，这个应用最主要的创新点是什么？

Michael：开发者历来大部分时间都花在IDE中，因此我们进入VS Code、JetBrains等环境是顺理成章的选择。但通过Codex应用，我们实际上建立了一个全新的界面。我将其视为一个“任务控制中心”，可以同时管理和协作多个对话。它保留了IDE的核心功能，比如查看代码差异、用快捷键打开终端，而无需切换窗口。它真正打破了“必须时刻将所有代码置于眼前”的传统观念。对许多人来说，能够同时组织并推进多个Agent任务更具价值，这正是我们努力实现的核心功能。

编码Agent如何重塑开发工作流

主持人：像Codex这样的编码代理，如何改变开发者的日常工作？

Michael：最显著的变化是吞吐量的大幅提升。你可以并行推进多项任务。这当然会带来上下文切换的成本，并非所有人都喜欢，但如果运用得当，效率将非常高。我个人就同时维护着大约五个Codex代码库的副本，并经常在它们之间切换。

最近在技术社群的讨论中，“Harness”一词的出现频率陡然升高。从OpenAI的官方博客到Martin Fowler的技术文章，再到各类AI智能体（Agent）开发团队的口头禅，“Harness Engineering”似乎成了新的焦点。查阅字典，其本意是“马具”，这与人工智能有何关联？

本质上，Harness可以被理解为套在AI模型外部、用以管理和约束其行为的一整套系统。模型核心负责“思考”与生成，而Harness则负责“管控”——决定模型能调用哪些工具、可以访问哪些数据、如何对输出进行验证，以及在出现错误时如何提供安全兜底。

这套管控层并非全新概念，过去它常以“脚手架”（Scaffolding）或“包装器”（Wrapper）等名称出现。直至今年二月，OpenAI在一篇博文中正式使用并阐述了“Harness”这一术语，随即被行业广泛采纳与讨论。

那么，这套外围系统究竟有多关键？

同一模型，性能差异可达一倍

其重要性可以通过一个事实直观体现：使用完全相同的AI模型，仅更换或优化其外部的Harness系统，在基准测试中的得分差距可能高达一倍。

例如，LangChain团队上个月进行了一项实验。他们开发的代码生成智能体在Terminal Bench 2.0基准测试中最初得分为52.8%，排名在30名开外。随后，团队对其Harness进行了三项关键改进：

1. 在提示词中引入了“自验证循环”，要求智能体生成代码后必须自行运行测试。
2. 编写了一个中间件，用于检测并阻止智能体陷入对同一文件进行数十次无效修改的死循环。
3. 在任务启动时，预先将工作目录的环境信息注入上下文。

模型本身并未更换，仍是GPT-4（此处原文“GPT-5.2-Codex”疑为笔误，根据上下文修正为业内已知模型）。经过上述Harness优化后，得分跃升至66.5%，排名一举进入前五。

团队在博客中揭示了一个核心发现：智能体最常见的失败模式是，生成代码后仅进行“肉眼检查”，认为无误后便提交，而忽略了实际运行测试。引入强制性的自验证环节后，失败则必须修正，仅此一项改变就弥补了大部分的性能差距。

另一组由Nate B Jones在三月发布的数据更为直接：同一模型、同一套测试题目，在更换运行环境（即Harness）后，得分从42%提升至78%。

三人团队的构建实践

认识到Harness的重要性后，如何构建它呢？OpenAI内部提供了一个极为前沿的实践案例。

其Codex团队曾立下一个极端规则：整个代码库从零开始，必须完全由AI智能体生成。仓库结构、持续集成（CI）配置、代码格式规范等，全部由Codex编写，没有任何人类编写的代码作为初始锚点。最终，3名工程师在5个月内，通过大约1500次代码合并请求（PR），管理了约100万行由AI生成的代码。

这三位工程师的日常工作是什么？他们主要专注于：搭建初始仓库结构、编写约束规则、配置代码检查工具（Linter）、以及建立有效的反馈循环。当智能体工作卡顿时，他们思考的是：智能体缺失了哪种能力？如何让它理解并执行某项任务？随后，他们会引导Codex将所需的改进方案自行编写并提交回代码库。

可以说，他们的核心工作正是在构建和完善一套高效的Harness系统。

实践中的三个关键教训

构建Harness过程中最具价值的经验，往往来自踩过的“坑”。OpenAI团队总结了三点核心教训：

1. 配置文件应简洁精炼。 初期，他们创建了一份冗长的AGENTS.md文件，试图将所有规则塞入其中。结果却导致智能体因上下文过长而难以抓住重点，有效指令空间被规则文件挤占。后来他们改为维护一份约100行的核心规则索引，将详细内容移至docs/目录下，智能体仅在需要时按索引查询。

2. 代码质量需主动治理。 AI智能体会模仿仓库中现有的代码模式，包括不良实践。久而久之，冗余和低质代码会逐渐累积。团队起初每周花费20%的时间手动清理，但不堪重负。最终，他们将清理标准编码为自动化规则，交由Codex定期扫描并自动发起修复PR。

3. 规则必须被自动化执行。 将架构约束仅写在文档中，智能体未必遵守。后来，团队把关键分层规则嵌入持续集成（CI）流程，违反规则的PR会被自动阻断。这确保了规则的执行依靠系统机制，而非智能体的“自觉”。

工具数量：少即是多

构建Harness还有一个反直觉的经验：提供给智能体的工具并非越多越好，适度精简反而能提升其表现。

Vercel团队曾开发一个内部数据查询智能体，起初为其配备了17个专用工具。然而成功率仅80%，平均每次查询耗时近5分钟，最差情况甚至运行12分钟后仍告失败。

（图为Vercel博客中引用的内部Slack截图）

随后，团队将工具数量大幅削减至仅剩2个核心工具。结果，成功率提升至100%，且平均处理速度加快了3.5倍。

GitHub的Copilot项目也有类似发现：当工具数量从40多个减少到13个时，其任务准确率从19%大幅跃升至72%。

工具过多时，智能体需要在“选择使用哪个工具”上耗费决策时间，选错则易导致任务路径迂回。减少选项，反而能让其行动路径更直接、高效。

行业共识：一个核心配置文件

目前，Anthropic的Claude Code在仓库中放置了CLAUDE.md，OpenAI使用AGENTS.md，Vercel也在测试AGENTS.md的效果。这三家公司不约而同地走向了同一种实践：创建一个专门的配置文件，用以集中定义和传达对AI智能体的各项“规矩”。

至于这个文件的最佳长度、应包含的内容范畴以及如何持续更新，整个行业仍在共同探索与优化中。

参考资料：

1. OpenAI 官方博客：Harness Engineering
2. Martin Fowler 博客文章：Exploring Harness Engineering in Generative AI
3. LangChain 博客：Improving Deep Agents with Harness Engineering
4. Vercel 博客：How We Improved Our Agent by Removing 80% of Its Tools
5. Terminal Bench 2.0 排行榜

本报告对Harness Engineering（驾驭工程）在项目中的落地方法、核心原理及企业级应用进行了深入剖析。研究结合了OpenAI、Anthropic、LangChain等前沿机构的实践案例，系统性地阐述了从理论到实践的完整路径。核心发现包括：Harness Engineering是继Prompt Engineering和Context Engineering之后的第三次AI工程范式跃迁，其本质是通过构建外部控制系统来提升AI Agent的可靠性；由六大工程支柱（上下文架构、架构约束、自验证循环、上下文隔离、熵治理、可拆卸性）构成的完整技术框架；企业级实践表明，通过实施Harness Engineering可实现高达10倍的效率提升，同时将变更失败率从15%显著降低至3%以下。

从Prompt到Harness：三代AI工程范式的演进

Prompt Engineering（提示词工程）：聚焦于优化单次交互的指令设计，核心在于“怎么问”。其关注点是如何通过精心设计的提示词来引导模型产生期望的输出结果。

Context Engineering（上下文工程）：致力于管理模型可见的上下文信息，核心在于“给什么”。重点在于如何高效地组织、筛选和呈现信息，以避免上下文窗口过载导致的性能下降。

Harness Engineering（驾驭工程）：将控制范围扩展到整个运行环境，核心在于“系统怎么搭”。其核心理念是不直接优化模型本身，而是通过构建约束机制、反馈回路、工作流控制和持续改进循环来优化模型运行的“环境”，从而将不可预测的AI模型转变为可靠的企业级智能体。

核心定义与哲学

Harness Engineering可以理解为一种为AI Agent设计“缰绳 + 马鞍 + 跑道护栏 + 反馈镜子”的综合性工程方法。

用公式表示为：Agent = Model + Harness

• Model：指底层的AI模型能力。
• Harness：指外部的控制系统，包括约束、验证、反馈和隔离等机制。

其核心哲学可以概括为八个字：人类掌舵，智能体执行。这强调了人类在高层规划和监督中的核心作用，而AI则负责具体任务的执行。

Harness Engineering核心原理深度解析

构建可靠Agent的三大架构支柱

基于OpenAI、Anthropic、LangChain等行业先驱及Martin Fowler的实践，Harness Engineering可归纳为三个核心组件，如同为Agent设置的三重护栏：

1. 可读性：让Agent理解系统规则 确保Agent能够准确理解其操作环境和任务要求。

• AGENTS.md文件：为Agent量身定制的项目说明书，明确技术栈、开发命令、代码规范及验证流程。
• 渐进式披露：避免一次性信息过载，仅提供执行当前任务所需的关键规则，详细文档支持按需查阅。
• 分层结构：在Monorepo等复杂项目中，可为不同子目录配置独立的AGENTS.md文件，实现精细化管理。

2. 防御机制：实施硬约束而非软约束 通过系统和工具层面的强制规则，确保Agent行为在安全可控的边界内。

• 状态机控制任务阶段：例如，强制遵循Research（研究）→ Plan（规划）→ Execute（执行）→ Verify（验证）的流程，防止Agent跳跃或无序执行。
• 权限边界：明确禁止写入敏感目录（如.env、secrets/）。
• 防“伪完成”检测：检查工具调用记录，若Agent声称完成任务但无实际调用记录，则强制其回滚或重试。
• 循环失败检测：引入类似熔断器的机制，当检测到重复错误时，自动切换执行路径或上报。

3. 反馈回路：实现持续改进 建立自动化、结构化的反馈机制，使Agent能够从错误中学习并持续优化。

• 自动化验证：在代码修改后自动运行类型检查、代码规范检查（Lint）和单元测试。
• 执行与评审分离：由独立的Agent或会话进行代码审查，避免执行者自我评估带来的偏差。
• 错误经验持久化：将典型的错误模式及修复方案记录在.harness/lessons-learned.md等知识库中，形成从错误发现到规则优化的闭环。

六大工程支柱详解

2.2.1 上下文架构 核心理念：精准控制进入模型上下文的信息量与质量，避免信息过载导致的性能衰退。研究表明，上下文窗口利用率超过40%时，模型性能开始显著下降。 具体实现：

• 信息优先级分层：动态裁剪对话历史中的低优先级信息。
• 滚动窗口与摘要压缩：结合滑动窗口与关键信息摘要，平衡细节与记忆。
• 结构化上下文：使用分隔符、XML标签等方式清晰组织不同的上下文块。
• 延迟加载：仅在工具调用需要时，才加载相关资源（如文件、API文档）的描述。
• 健康监控：实时追踪Token使用量，达到预设阈值时触发自动清理。

2.2.2 架构约束 核心理念：利用工具和代码强制执行业务与安全规则，彻底取代Prompt中的“软”约束。 具体实现：

自2026年初以来，“harness engineering”这个概念以病毒般的速度席卷了整个AI工程领域。Mitchell Hashimoto为它命名，OpenAI通过一个百万行代码零手写的项目为它做了最佳广告，Stripe则以每周处理1300个AI拉取请求的实践为其背书。一时间，行业中似乎形成了一种共识：不讨论harness，就不配称为真正的AI工程师。

然而，当最初的狂热逐渐退去，一些根本性问题值得我们冷静审视。

harness究竟是什么？

“Harness”一词源自马术装备——缰绳、马鞍、嚼子——即一套用于引导强壮却不可预测的马匹走向正确方向的全套器具。在AI智能体语境中，harness就是包裹在模型外部的一系列基础设施，包括约束机制、反馈循环、文档体系、工具编排以及人工审批流程等。

模型是马，人是骑手，harness就是缰绳与辔头。没有harness约束的智能体，如同一匹在旷野上肆意奔驰的纯血马——速度惊人，姿态优雅，却难以产生任何实际价值。

这个词的中文翻译也面临挑战。“约束工程”定义过窄，因为harness的功能不仅是限制，还包括引导和赋能。“驾驭工程”在语义上较为接近，但仍存在微妙偏差——harness本质是装备（名词），而“驾驭”是一个动作（动词）。因此，中文技术圈目前基本直接沿用英文术语，仅在首次出现时附加括号说明。

有哪些真实的落地案例？

将现有案例按成熟度排序，可以清晰地看到实践路径：

Stripe Minions 是目前最为扎实的生产级应用。他们的Minions是完全自主的编码智能体，每周合并超过1300个拉取请求，且无需人工手写一行代码。其harness是一个五层管道，从Slack消息处理一直延伸到生产级PR的生成。每个Minion运行在隔离的devbox环境中，拥有完整的Shell权限，但无法触及生产系统。其智能体harness深度分叉自Block开源的Goose项目，并针对无人值守场景进行了大量改造。最关键的是，它连接了Stripe内部的集中式工具服务器，暴露了近500个工具，不同智能体按需请求工具子集。

OpenAI内部Codex项目 是“harness工程”这一术语的起源。仅凭3名工程师，在5个月内完成了百万行代码的项目，全程零手写。他们的核心洞见是：庞大的AGENTS.md文件不能当作百科全书使用。大文件会挤占宝贵的上下文窗口、内容会快速过时、且难以进行机械化验证。因此，他们将AGENTS.md缩减至约100行，仅作为“目录”使用，真正的知识库则存放在结构化的docs/目录中。

Anthropic 完成了两项引人注目的实践。一是利用16个智能体从零开始编写了一个能够编译Linux内核的C语言编译器，共计10万行Rust代码，消耗了约两万美元的API费用。其二是在近期发表的一篇文章中，他们将生成对抗网络（GAN）的思路引入harness设计——生成器负责编写代码，评估器则通过实际操作应用来打分，这种职责分离有效解决了“智能体为自己的作品打高分”的问题。

LangChain DeepAgents 是开源社区中最具系统性的实践。他们通过纯粹的harness优化，在不更换模型的情况下，将Terminal Bench 2.0的得分从52.8%提升至66.5%，排名从30名开外一跃进入前五。

一个有趣的观察是，尽管这些项目的规模与风险承受能力差异巨大，但它们却得出了高度相似的结论。

harness的八大核心组件

梳理成功实践，一个完整的harness系统大致需要包含以下组件：

上下文工程 —— 不仅仅是“写好文档”，而是设计一套上下文注入策略：决定在何时、以何种方式将信息注入模型的上下文窗口。OpenAI采用了三级架构：全局AGENTS.md（始终加载、极其简短、作为目录使用）→ 目录级规则文件（根据智能体工作位置自动加载）→ skill/docs/目录下的内容（按需延迟加载）。

测试驱动开发与静态分析 —— 确保智能体的每次修改都能被机械化验证。但这里有一个关键细节：测试本身必须为智能体设计，而非人类。测试harness不能输出数千行无用信息，以免污染上下文窗口。

可观测性集成 —— 整合开放遥测、日志系统与仪表板访问权限，使智能体能够“看见”系统的运行时状态信息。

架构约束强制执行 —— 使用ArchUnit、depguard等工具机械化地强制分层规则，而不是在文档中简单写下“不要违反分层架构”的标语。

执行环境隔离 —— 沙盒是所有其他约束层的物理保障。没有它，上层约束都只是“君子协定”。Stripe为每个Minion分配一个一次性的开发环境，任务完成后立即销毁。

工具集的精准裁剪 —— 并非将所有可用工具都暴露给智能体。Vercel的实践表明，在砍掉80%的工具后，智能体的表现反而更佳。工具过多意味着决策空间过大，智能体更容易做出错误选择。

重试与升级策略 —— 当智能体任务卡住时如何处理？Stripe的设计是：CI流程失败最多重试两次，第三次则直接标记为需要人工介入。LangChain则开发了循环检测中间件，用于识别并跳出死循环。

熵值治理机制 —— 智能体生成的代码会以不同于人类的方式积累技术债务。需要定期运行“垃圾回收”智能体，来扫描文档漂移、命名不一致以及死代码堆积等问题。

关于AGENTS.md的重要教训

OpenAI曾尝试过“一个庞大的AGENTS.md文件”方案，但以失败告终。原因非常直观：上下文窗口是稀缺资源，大文件会挤占任务描述和代码本身的空间；当所有内容都被标记为“重要”时，实际上没有任何内容是真正重要的；单体文件最终会腐烂成过时规则的坟场。

苏黎世联邦理工学院最近的研究也发现，由大语言模型生成的AGENTS.md文件对任务成功率有轻微的负面影响。智能体确实会遵循指令——因此会运行更多测试、阅读更多文件、执行更多搜索——但这些行为对于解决具体任务而言往往并非必要。

Stripe的做法更进一步——他们采用目录级规则文件，智能体在遍历文件系统时会根据所在目录自动加载相应的上下文内容。他们还兼容了Cursor的规则文件格式，从而在Minions、Cursor和Claude Code三套智能体系统之间实现同步。

因此，核心原则是：AGENTS.md文件越简短越好，只应包含智能体不可能自行推断出的关键信息。

AI编码是否需要测试驱动开发？

围绕这个问题存在讨论，但结论并不统一。

支持测试驱动开发的核心论点是：如果让智能体同时编写代码和测试，它倾向于编写“同义反复”的测试——这些测试只验证“代码实际做了什么”，而非“代码应该做什么”。让测试先行于实现，就切断了这条作弊路径。

然而，一项反直觉的实验发现被记录在TDAD论文中。单纯地给予智能体“先写测试再实现”的指令，不仅没有减少回归错误，反而将回归率从6.08%提高到了9.94%——效果比不提供任何指令更差。原因是：智能体并不需要被告知“如何进行测试驱动开发”，它需要知道的是“应该检查哪些测试”。测试驱动开发的流程本身对智能体并非关键，关键在于基于依赖关系感知的测试选择。

回顾主流的关于harness的论述，几乎没有人明确提到测试驱动开发。OpenAI的做法是“设置最少的阻塞性合并关卡，保持较短的拉取请求生命周期，测试的偶发性失败通过后续运行来解决”——这与测试驱动开发“先写测试再实现”的理念完全相反。Stripe也类似——智能体编写代码后运行测试，若持续集成失败则重试两次，第三次则请求人工介入。

实际做法大致可分为三种流派：

人类编写测试，智能体实现功能 —— 这是最受推荐的方式，测试作为刚性合约存在，但本质上是将“定义何为正确”这一最具挑战性的工作留给了人类。

快速反馈循环 —— OpenAI和Stripe所采用的方法，不追求“一次成功”，而追求“快速收敛到正确结果”。

提供测试驱动开发的上下文，而非流程 —— 不告诉智能体“先写测试再写代码”，而是为其提供一张依赖关系图，使其明确知晓“修改会影响哪些测试”。

什么是Harness？

Harness是AI Agent的控制框架，其概念类似于骑马时使用的缰绳，用以引导方向并维持稳定节奏。特别针对长时间运行的AI Agent，Harness提供了一套“缰绳”系统，确保它们能够持续、可靠地完成复杂任务，OpenAI团队正式将这一机制命名为"Harness"。
当前优秀的Harness实例包括：superpowers、deer-flow以及claude code。

为什么需要Harness？

现阶段，绝大多数大型语言模型（LLM）的“记忆”能力，即上下文窗口，相对有限，导致模型在工作一段时间后便彻底遗忘先前内容。
AI在实际应用中主要面临两大困境：

• 中途失忆：上下文窗口迅速饱和，造成关键信息丢失；
• 半途而废：为避免窗口溢出，任务被迫提前草率结束。

为了保障AI Agent在长线程任务中维持工作质量与稳定性，在记忆问题获得根本性解决之前，必须借助工程化的控制与优化策略，以此扬长避短，充分发挥现有技术潜力。

Harness如何工作？

Anthropic公司提出了一套基于任务拆解、工作交接与工作验收的解决方案：

第一步：项目经理（Plan Agent）
将整体任务拆解为若干细粒度子任务，确保每个子任务均在单个Agent记忆容量内可完成，同时构建清晰的项目框架，并详细编写“工作交接手册”。

第二步：轮班工人（Work Agent）
严格遵循手册执行具体工作：

• 每次仅聚焦于完成一个独立子任务；
• 完成任务后必须“打扫现场”：保持代码结构整洁、添加必要注释、杜绝遗留bug；
• 在“交接手册”中准确记录当前进度与关键信息，方便后续接手的工人无缝继续工作。

第三步：严格验收（Review Agent）

• 模拟真实用户场景进行全面测试；
• 一旦发现bug即刻进行修复，确保成果质量。

Harness带来的益处

总体而言，Harness为AI应用带来了以下显著优势：

• 使得模型的理论能力得以在实际场景中有效落地；
• 支持长时间处理复杂多线程任务，同时保持输出质量不受影响；
• 将AI从类似抽卡游戏的随机输出模式，转变为能够稳定交付可靠成果的高效生产力工具。

🤔 从一个问题开始

假设你招聘了一位毕业于哈佛大学的顶尖实习生。

他具备全方位的才能：

编写代码、撰写文章、分析问题
通晓法律、医学、编程知识
反应迅速，能够全天候工作

然而，你却发现一个令人困惑的现象：

当你要求他“帮我分析一下上周的销售数据”时，他回答：

“抱歉，我无法访问您的文件。”

当你指令他“运行一个测试看看”时，他表示：

“抱歉，我无法执行代码。”

当你希望他“明天继续跟进这个项目”时，他解释道：

“抱歉，我记不住昨天的事情（上下文容量已满）。”

问题并非出在这位实习生身上，而是你未能为他配备合适的“工作台”。

🔧 Harness的本质：赋予AI能力的工作台

Harness，字面意为“马具”。 正如为马匹套上鞍具，它才能拉车、供人骑行。

AI Harness = 为大型语言模型配备“工作台”，使其能够真正开展工作。

这个“工作台”具体包含哪些组件？

1️⃣ 一双手（工具集成能力） 使模型能够：

访问您的文件系统
执行代码片段
调用外部API接口
操作网页浏览器

缺乏这双手，模型就只是一个“空谈者”——能言却不能行。

2️⃣ 一个笔记本（记忆系统） 使模型能够：

记住您的个人偏好
记录项目的历史状态
回顾之前的对话内容

没有这个笔记本，模型便如同“金鱼”——只有短暂的记忆。

3️⃣ 一位项目经理（任务编排引擎） 将宏大的目标分解为可执行的步骤：

“撰写一篇文章” → 寻找热点 → 搜集资料 → 拟定大纲 → 完成初稿 → 优化润色 → 发布上线
每一步自动推进，无需人工持续监督

缺少项目经理，模型就如同“临时工”——缺乏主动性，推一步才动一步。

4️⃣ 一个保险箱（沙箱隔离环境） 防止模型产生下列风险行为：

误删系统的关键文件
执行具有危害性的指令
泄露敏感的机密信息

失去保险箱的保护，模型就像“擅长拆家的哈士奇”——能力虽强却潜藏危险。

🧪 测试人员的共鸣：这不就是测试框架吗？

如果您曾从事自动化测试开发，那么上述概念听起来会无比熟悉。

概念对比

以pytest/Junit为例： 它们的作用是将“测试代码”封装起来，使其能够：

当大模型的潜力已经强大到可以一气呵成编写数万行代码时，我们是否仍在为如何撰写提示词而烦恼？

当AI智能体已经能够自主执行包含多个步骤的复杂任务时，我们是否还仅仅将其视为对话框中的一个辅助工具？

过去两年行业吹起的泡沫正在逐渐破灭：仅依靠封装大模型的对话产品用户留存率不足5%，仅擅长调整提示词的工程师和产品经理开始面临职业发展的挑战。人们突然意识到，大模型越聪明，我们构建的产品反而越容易失控。

破局的关键并非等待更强大的模型出现，而是彻底转变玩法。今天我们要探讨的“Harness Engineering”（常译为“驭缰工程”或“驾驭工程”），正是AI原生时代席卷行业的一种全新开发范式——其核心不是让人工智能辅助人类写代码，而是由人类为AI设计一套能够稳定、可靠工作的系统。

驾驭工程的整体架构是怎样的？

从提示词到缰绳：行业经历了怎样的演进？

要理解Harness为何会成为必然，我们需要梳理近几年AI开发的演进路径。

2023至2024年，大模型刚刚破圈，最热门的是提示词工程。核心议题是“如何与AI沟通，它才能准确理解我的意图”。那时，精通Prompt编写就能获得高薪，整个行业沉浸在“提示词工匠”的狂欢中。

2025年，焦点转向了上下文工程。问题演变为“应该给AI提供哪些信息”，RAG（检索增强生成）、记忆管理、信息流组织成为技术核心。

步入2026年，两股力量彻底重塑了格局：一方面，大模型的基础能力持续增强，已在诸多领域超越普通人的平均水平；另一方面，AI智能体已能自主执行包含多步骤的长期任务。

于是，一个新的根本性问题浮出水面：如何让智能体在真实的生产任务中稳定运行而不“翻车”？

模型能力足够强大，但在执行长任务时仍易失控：上下文窗口被填满后便开始遗忘，出现错误时不知如何回退，自我评估总是趋于乐观，产出的结果可能杂乱无章且不符合要求。

这些问题并非源于模型本身，而是执行环境和工程化的缺失。Harness Engineering 正是为解决这些问题而生。

究竟什么是Harness Engineering？一个比喻讲透本质

“Harness”直译为“马具”或“挽具”，这个翻译极其精准地传达了其内涵。

试想一匹骏马：它天生拥有力量，能够奔跑、拉车。马具本身并不提供动力，它只专注于四件事：管理方向、控制节奏、保障安全、确保马匹在高速奔跑中不会失控。

一匹未被驯服、没有马具的野马，力量再大你也无法驾驭，更无法让它按照指定路线完成任务，反而可能被它掀翻在地。

将此映射到AI领域：AI智能体是那匹充满力量的野马，而Harness就是套在它身上的缰绳与鞍具。

一个更工程化的定义是：Harness是包裹在AI模型周围的一层基础设施，专门用于管理AI的长期复杂任务。它并非智能体本身，而是架设在智能体框架之上的更高层架构，负责为智能体提供预设的上下文环境、标准化的工具调用接口、生命周期管理，以及开箱即用的任务规划、文件访问、子智能体管理等能力。

用一个操作系统的类比来理解：智能体是运行中的进程，而Harness就是操作系统的内核调度系统。一个进程能成就何事，并非完全由进程自身的代码决定——内存如何分配、I/O如何调度、崩溃后如何处理，这些都是内核调度器的职责。没有调度管理的“裸奔”程序或许能快速启动，但功能极其有限，一次错误便可能导致全盘崩溃。

Harness解决的正是智能体领域的“裸奔”问题：上下文长度不足、自我评估偏差、跨任务状态丢失、长任务中途失控……这些棘手难题都交由Harness来系统化处理。

疯狂的实践：AI如何自主写出百万行代码？

空谈概念不如实战案例。行业领军者已运用这套方法论取得了惊人成果。

OpenAI案例：三人团队，五个月，零人工代码产出百万行

2026年2月，OpenAI发布的一篇博客震惊了整个技术圈：他们使用Codex智能体从零开始构建了一个软件产品。从第一次Git提交算起，历时五个月，产出约一百万行代码——没有任何一行由人工直接编写。

让我们审视这项实验的关键数据：

• 开发周期：5个月
• 初始团队：3名工程师
• 最终团队：7名工程师
• 总代码量：约100万行
• 人工编写代码：0行
• 处理PR数量：约1500个
• 效率对比：较传统手写代码模式提升近10倍
• 产品状态：已上线，拥有真实的内部日活用户并进行外部Alpha测试

最引人深思的是团队扩张后的效应。传统软件工程奉行布鲁克斯法则——“向进度落后的项目中增加人手，只会使项目更加滞后”，因为沟通成本呈指数级增长。但在Harness模式下，团队从3人扩充至7人，产能不仅未下降，反而持续增长。

原因何在？因为人与人之间消除了代码层面的直接依赖。曾经的矛盾是“我写的代码是否会与你写的冲突”，现在的问题变为“我设计的环境与你设计的环境是否兼容”——后者的耦合度天然低得多。

在整个过程中，人类工程师只专注于一件事：设计出让AI高效工作的环境，然后监督其运行。工程师的角色从“代码编写者”转变为“规则设计者”。

Anthropic案例：AI自主迭代引发的创意飞跃

Anthropic团队进行了一项更有趣的实验：他们让Claude智能体在无人干预的情况下，自主迭代开发一个前端网站。

智能体执行复杂任务时常有两个通病：第一，上下文越跑越长，直至窗口被填满，导致连贯性丢失，甚至出现“上下文焦虑”——临近限制时便草草收工；第二，自我评估往往过于乐观，无论产出质量如何，都倾向于认为“做得很好”，这在设计类等主观性较强的任务中尤为突出。

Harness如何破解这些难题？工程师为智能体添加了两大约束： 第一，实施明确的上下文切割与管理，避免无关信息堆满工作窗口。 第二，制定四项清晰的评分标准，要求智能体每次迭代后依此自行打分：

1. 设计质量：整体是否呈现连贯、统一的视觉风格？
2. 原创性：是简单套用模板，还是做出了自定义的创意决策？
3. 工艺细节：排版、间距、色彩等基础执行是否到位？
4. 功能性：用户能否直观理解界面并顺利完成操作？

这套方法效果显著。到第九次迭代时，智能体已产出一个符合要求的、虚构博物馆的深色主题着陆页，视觉效果相当精致。

第十次迭代则更为惊人：智能体完全推翻了之前的所有设计，给出了一个人类未曾预料的创意方案——将整个网站重构为一种空间体验：利用CSS透视变换渲染出带有棋盘格地板的3D房间，艺术品自由悬挂于墙面，导航通过“门廊”切换画廊房间来实现，而非传统的滚动与点击。这便是一次超越人类预设的、真正的创意飞跃。

Harness工程的核心：必须做好哪三件事？

通过案例分析，我们可以拆解Harness Engineering的核心工作，归结为三件事，其精髓可概括为：人类负责掌舵，智能体负责划桨。工程师的职责从编写代码，转向设计环境、明确意图、构建反馈循环。

核心一：设计智能体的运行环境

在传统软件工程中，“环境”通常指IDE、编译器、依赖包等。但在Harness范式下，“环境”的范畴广阔得多：你的整个代码仓库结构、架构约束、代码检查规则、文档规范、持续集成流水线……所有这些构成了智能体的运行环境。

智能体并非“在你的代码库中帮你写代码”，而是“在你精心设计的环境里，自主完成整个开发任务”。环境设计优良，智能体产出的代码自然规范统一；环境设计粗糙，智能体便会“四处乱撞”，产出难以整合的碎片化成果。

这好比城市规划：规划者无需亲手建造每一栋楼，但必须划定道路红线、规定容积率、制定建筑规范。楼房由开发商（智能体）建造，但城市的整体风貌与功能，则由规划师（工程师）的设计所决定。

核心二：将模糊意图拆解为可执行的明确任务

在传统开发流程中，产品经理撰写PRD，工程师理解需求后编码实现。在Harness模式下，工程师的工作更接近产品经理：将一个模糊的宏观目标，层层拆解为智能体能够逐步执行的具体任务。

OpenAI团队将此方法称为“深度优先工作法”，其逻辑清晰：

1. 将大型功能拆分为多个独立模块。
2. 每个模块进一步分解为设计、编码、测试、评审四个步骤。
3. 为每一步明确界定输入、输出和验收标准。
4. 引导智能体逐个模块完成构建。

这里需要强调：这并非仅仅是撰写更优质的提示词。这是整个思维模式的迁移：从思考“我如何实现这个功能”，转变为思考“我如何描述这个功能，才能让智能体独立地实现它”。两者所处的抽象层次截然不同。

核心三：构建能够快速纠错的反馈回路

这是Harness最核心的环节，也是许多人理解存在偏差的地方。