年初，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最核心的环节，也是许多人理解存在偏差的地方。

近来，人工智能编程领域再度涌现出一个引发讨论的新术语：Harness Engineering。

不得不感叹，AI领域创造新概念的速度确实惊人，许多人尚未完全理解之前的“Vibe Coding”，如今又迎来了需要学习的新理念。

通过翻译工具查询可知，“Harness”这个词的本意是“缰绳”或“马鞍”。初看之下，这个含义似乎与人工智能风马牛不相及，确实令人感到困惑。

因此，有网友将其戏称为“牛码工程”。

!Image

为了厘清这个概念的真实内涵，以及它为何近来频繁被行业专家提及，我进行了一番探究。本文将带你彻底弄明白Harness Engineering。

Harness Engineering 究竟是什么？

这一概念最早由HashiCorp的联合创始人Mitchell Hashimoto于今年二月提出。

其核心思想可以概括为：

每当你发现AI智能体犯了一个错误，就应投入时间设计一套机制，确保它未来永远不会再犯同样的错误。

用更通俗的话来说，就是：不要只专注于让AI执行任务，你必须为它制定明确的规则。

如前所述，“Harness”意为“缰绳”。试想一匹奔跑迅速的骏马，若没有缰绳的控制，则难以驾驭方向。AI智能体就如同那匹马，而“Harness”就是你为它配备的整套控制装备。

它定义了AI能够使用哪些工具、禁止访问哪些文件、出现错误时如何自动修复，以及在哪些环节需要人工介入。

本质上，Harness Engineering旨在设计「AI的工作环境」，使其能在既定约束下高效运作，而非采取一种完全放任自流的自由模式。

如果听起来仍然抽象，那么通过一个实例便能清晰理解。

在开发智能体时，我们常需要调用AI的API。如何确保它按照你预期的格式返回结果呢？仅依赖编写提示词吗？如果它不按此格式返回该怎么办？

例如，你要求AI返回一个JSON对象，但它可能将结果包裹在Markdown代码块中，或者拼错了字段名称。

传统的解决方法是：修改提示词，增加一句“请务必返回纯JSON格式”。这属于**提示词工程（Prompt Engineering）**的范畴。

后来人们发现，仅靠调整提示词并不完全可靠，你还需要为AI提供一些示例或上下文文档。这便进入了**上下文工程（Context Engineering）**的阶段。

然而，在实际生产环境中，即使提示词撰写得再完美、上下文提供得再充分，AI偶尔仍会出现难以预料的错误。

此时该怎么办？

你需要在AI的外围构建一层封装：包括格式验证、自动重试、错误回退机制以及日志记录等。

这一整套“包裹在AI外部的东西”，就构成了Harness。

再举一个更贴近日常开发的例子。

当你使用Claude Code编写项目时，它有时可能会意外修改你并未允许它触碰的文件，或者引入一些不必要的依赖。你即便指出错误，下次它仍可能重蹈覆辙。

但如果你在项目中配置了CLAUDE.md文件来明确规则，设置了ESLint进行自动检查，配置了pre-commit钩子来拦截不合规的提交，并利用Git记录每一次代码改动——那么当AI犯错时，整个系统能够自动将其纠正回来。

这便是Harness的作用。

它并非依靠“口头指令”来约束AI，而是通过一整套“系统机制”来实现约束。

对于个人开发的演示级别项目，缺乏这些机制或许无伤大雅，只要AI大部分时间能正常工作即可。

但对于像Claude Code这类商用级别的产品而言，必须确保其稳定可靠地运行，因此必须将这些外围的“安全保障”工作落实到位。

从提示词、上下文到驾驭机制

如果你持续关注AI领域的发展，会发现近年来大致经历了三代范式的演进。

!Image

2023-2024年属于提示词工程（Prompt Engineering）时代。 其核心聚焦于“如何清晰地表达指令”，通过优化提示词的措辞、结构和示例来获得更佳的模型输出。

2025年进入了上下文工程（Context Engineering）时代。 业界意识到仅凭提示词是不够的，AI需要看到相关的文档、代码片段、历史对话记录等上下文信息，才能给出更准确可靠的答案。

步入2026年，驾驭工程（Harness Engineering）开始兴起。 它与前两者的根本区别在于：

• 提示词工程解决的是“如何提问”。
• 上下文工程解决的是“让AI看到什么信息”。
• 驾驭工程解决的则是“系统能够预防何种错误、度量哪些指标、以及如何修复问题”。

这三者并非替代关系，而是层层递进、相互叠加的。

一个完整的Harness包含哪些部分？

一套完整的Harness并非单一的某个工具或配置文件，而是一个系统性的工程体系。

它大致可以划分为五个组成部分：

1. 输入侧 —— 告知智能体应该执行什么任务。包括项目仓库文档、代码规范、架构说明、任务描述等。这些文档不仅是编写给人看的，更是专门写给AI理解的。

2. 执行侧 —— 为智能体提供完成任务所需的工具。例如命令行访问权限、浏览器控制、数据库连接，以及各种模型上下文协议（MCP）工具等。

3. 约束侧 —— 明确告知智能体哪些行为是被禁止的。包括权限控制系统、目录访问范围限制、允许执行的命令白名单、以及关键操作需要人工确认的流程等。

进入2026年，人工智能领域最热门的概念并非GPT-5或Claude 4，而是一个你可能尚未耳闻的术语：Harness（驾驭层）。

业界知名专家Andrej Karpathy曾发表观点认为：“语境工程（context engineering）比提示工程（prompt engineering）更为重要”，该推文获得了超过230万次阅读。

与此同时，OpenAI仅以3名工程师耗时5个月的配置，便驱动AI生成了高达100万行的生产级别代码。

上述现象的背后，共同指向了同一种核心技术：Harness。

Harness究竟是什么？它为何如此重要？

Harness的本质，是为AI模型套上“缰绳”并部署“操作系统”，使其从仅仅“能够执行任务”跃升为能够“可靠且稳定地完成任务”。

我们可以通过一个简单的对比来理解：

• 提示工程 聚焦于“如何向AI提出问题”。
• 语境工程 专注于“让AI看到哪些信息”。
• 驾驭层工程 则致力于解决“如何让AI系统地、可控地运行”。

Harness解决了哪些核心痛点？

1. 上下文焦虑与信息遗忘

人工智能的上下文窗口存在容量限制。当处理的任务过于冗长时，AI模型就容易产生“敷衍了事”的倾向，仿佛在说：“之前提到的细节？已经记不清了，请您自行查阅吧。”

Harness的应对策略：实施动态的上下文管理与重置机制。在任务的不同阶段交接时，系统会自动将当前工作状态整理成结构清晰、重点明确的摘要文档，确保接手的AI智能体能够无缝衔接，延续工作。

2. 任务目标漂移与焦点迷失

在长周期、多步骤的复杂任务中，AI智能体容易偏离最初设定的目标。例如，本应编写新功能代码，却转向修改无关的旧有缺陷；本应修复特定漏洞，却开始进行非必要的性能优化。

Harness的应对策略：采用结构化的状态管理，结合持续的目标锚定与定期的检查点设定。系统会不断校准AI的行为，确保其每一步都紧密围绕核心目标展开。

3. 重复性错误与缺乏学习

AI模型可能在今天编写的代码中引入某种错误，到了明天处理类似任务时，依然会犯下完全相同的错误，缺乏从错误中学习和改进的闭环。

Harness的应对策略：构建“生成器-评估器”的自动化循环工作流。例如，一个AI负责生成代码，另一个专门的AI则进行审查与测试；若未通过审查，则打回重写，循环迭代直至产出符合质量要求的成果。

4. 输出不可控与合规风险

在企业级应用场景中，原始AI模型的输出可能包含不合规的内容、无意间泄露敏感隐私信息，或产生事实性“幻觉”，这带来了巨大的运营与法律风险。

Harness的应对策略：部署多层“安全护栏”系统。通常在内容生成之后、调用外部工具之前以及最终输出给用户之前，设置多个检查点。任何环节的输出若不符合预设的安全、合规与质量标准，都会被自动拦截并处理。

Harness适用于哪些关键场景？

对于大多数开发者和技术工作者而言，目前关联最紧密、最易上手的场景无疑是 AI辅助编程。

如何在日常工作中应用Harness技术？

方案一：直接使用集成了Harness的成熟产品

快速上手建议：下载安装Claude Code或Cursor，依据其官方文档指引，在项目中配置简单的规则文件（如claude.md），即可立即体验Harness带来的能力提升。

📘 今日核心词汇：harness

• 英式发音：/ˈhɑː.nɪs/
• 美式发音：/ˈhɑːr.nɪs/

🎯 核心释义详解

n. 名词含义

• 马具；挽具：指套在马匹等牲畜身上，用于拉车或承载重物的系列皮带与金属构件。
• 安全带；保护带：泛指用于高空作业、攀岩或儿童保护等场景，起安全固定作用的带状装备。

v. 动词含义

• 利用；驾驭：指有效控制并利用自然资源、能量、技术等抽象或具体的力量，以产生动力或实现特定目标。
• 给……套上挽具：表示为马或其他役用动物装配上挽具的具体动作。

🧠 词汇溯源与记忆诀窍

词源探索：Harness 一词源于古法语中的 harneis，其本义为“军事装备”或“行装”，后来词义逐渐缩小并特指用于驾驭马匹的装备。

💡 高效记忆法：

• 联想串联：将 horse（马）与 harness（马具）关联记忆——为马匹套上马具，本质上是为了控制并利用其力量。
• 意义延伸：从“用马具控制马的力量”这一具体意象，自然引申出“驾驭、利用”各种资源或力量的抽象含义。
• 场景代入：想象风力发电场的场景，风机正是为了 harness（利用）风能并将其转化为电力。
• 高频短语：重点掌握 harness the power of…（利用……的力量）与 harness energy（利用能源）这两个常用表达。

📌 高频实用搭配

• harness the power of… 利用……的力量
• harness energy 利用能源
• harness technology 利用技术
• safety harness 安全带
• harness natural resources 利用自然资源

📚 双语例句赏析

1. Scientists are continuously exploring novel methods to harness solar energy with greater efficiency. （科学家们正不断探索能以更高效率利用太阳能的新方法。）