当你的客厅里来了一条龙,你需要的不是更粗的铁链,而是一套完整的驾驭系统。2026 年 2 月,OpenAI 发布了一篇名为《Harness Engineering: Leveraging Codex in an Agent-First World》的技术博客,披露了一个惊人的实验:一个仅由 3 名工程师(后扩展到 7 人)组成的团队,在 5 个月内用 Codex Agent 生成了超过 100 万行生产级代码,合并了约 1500 个 Pull Request,没有一行代码是人类手写的。但这篇文章真正引爆行业讨论的,不是AI 写了 100 万行代码这个数字本身,而是它提出了一个全新的工程范式——Harness Engineering(驾驭工程)。Harness 是 AI 编程项目的标准基建环境吗?答案是肯定的。就像工业革命需要飞轮调速器和安全阀、信息革命需要操作系统和编程语言一样,AI 革命同样需要一套完整的驾驭系统。Harness Engineering 就是这样一套标准环境,它定义了模型能看到什么、能用什么工具、失败时该怎么办——整个运行环境 管控系统,让 Agent 可靠、安全地完成任务。一、从 Prompt 到 Context 再到 Harness:三层演进提示词工程上下文工程驾驭工程为了更深刻地理解 Harness Engineering,让我们把视野拉长到更宏大的技术史尺度上:提示词工程(2022-2024):核心问题:怎么跟模型说话?人类角色:用户精心雕琢每一句指令的措辞、格式、示例,试图从黑盒中诱导出正确答案。Few-shot、Chain-of-Thought、角色扮演……本质上是在一个固定的对话窗口里做文章。局限:单次交互、无状态、高度依赖个人经验,更像是大师手艺,而非工程。上下文工程(2025):核心问题:模型应该看到什么?人类角色:角色发生了变化,从用户转化到 Agent Builder,Builders 系统性地设计、构建并维护一个动态系统,在 Agent 执行任务的每一步为其提供恰当的上下文,包括知识库、工具调用、记忆管理……关注点从用户应该说什么转向 Builders 让模型看到什么,从而让模型更懂用户。2025 年 6 月,Andrej Karpathy 明确表态:上下文工程比提示工程重要得多。驾驭工程(2026):核心问题:整个环境应该如何运作?人类角色:角色再次从 Agent Builder 手里交还到用户手里。通过设计完整的运行环境,包括约束、反馈回路、自动验证、熵管理、生命周期治理等。深刻洞察:驾驭工程之所以在当下引发强烈共鸣,与 OpenClaw 等项目推动的 AI 主权转移密切相关——权责对等,拥有调试 Agent 的权利,也需要学会 Harness,懂得和 Agent 相处。从时间线看,AI 工程方法已经经历了三次演进,这几层演进背后的共同逻辑是:一旦模型能力过线,瓶颈就会开始外移。而这一次外移的一个标志性事件,是 2025 年 11 月 Claude Opus 4.5 的发布。它意味着模型的 agentic 能力到了一个 tipping point,以至于用好模型的能力,开始比提高模型的能力,更加重要。也就是说,智力本身不再是瓶颈,瓶颈转移到了系统层。二、Harness Engineering 的三大支柱与六维架构1. OpenAI 的三大核心支柱OpenAI 将 Harness Engineering 拆解为三大核心支柱:上下文工程(Context Engineering)确保智能体在正确的时间获得正确的信息:静态上下文:项目规范、代码风格指南、架构文档动态上下文:运行时状态、测试结果、Git 历史工具上下文:可用工具列表、API 签名、使用示例架构约束(Architecture Constraints)限制智能体可以做什么、必须做什么:# 示例:架构约束配置constraints:forbidden_patterns:-直接查询数据库,绕过 Service 层-硬编码魔法数字required_practices:-所有 API 调用必须使用类型化 SDK-边界验证必须显式声明escalation_rules:-超过 3 次编辑同一文件,触发人工介入垃圾回收(Garbage Collection)这是 Agent 时代最独特的概念——代码熵的持续治理:定期运行的清理 Agent,像 GC 回收内存一样回收技术债将品味编码为自动化规则OpenAI 团队曾把每周五 20% 的时间用于清理AI 垃圾,后来发现不可扩展,于是将品味规则化这里的品味包括:更倾向于使用共享的实用程序包,而不是手工编写的辅助工具,以便将不变式集中管理不会使用YOLO 式探测数据,会验证边界,或依赖类型化的 SDK,这样智能体就不会意外地基于猜测的结构进行构建会定期运行一组后台 Codex 任务,扫描偏差、更新质量等级,并发起有针对性的重构 Pull Request2. 深度解析:Harness 的 6 个关键组件综合目前看到的不同实践,我们认为 Harness Engineering 大致包括以下 6 个部分:Memory Context management (记忆与上下文管理)这一层解决的是在当前时刻,Agent 应该看到什么信息。常见做法包括上下文裁剪、压缩、按需检索,以及外部状态存储等。Tools Skills (工具与技能)负责扩展 Agent 的行动能力。工具提供可调用的外部能力,skills 提供可复用的任务方法。Orchestration Coordination (编排与协调)也就是编排整套任务流程,协调每个 agent 的分工,决定何时规划、何时执行、何时交接,让复杂任务能被拆开、推进并收敛。Infra Guardrails (基础设施与保障)负责提供运行环境和边界条件,包括沙箱、权限控制、失败恢复和安全护栏等,确保 Agent 能在真实环境中安全、稳定地运行。Evaluation Verification (评估与验证)对于很多复杂任务来说,决定最终成效的往往不是第一次生成,而是有没有验证闭环。所以很多 harness 内置一套测试、检查和反馈机制,让 Agent 能自行验证自己的工作,并在发现问题后及时修正。Tracing Observability (追踪与观测)负责还原 Agent 的行为过程,让整个黑箱变得尽量透明可见,例如提供执行轨迹、日志、监控和成本分析等能力。只有当这些过程是可见的,系统才是可调试、可优化、可管理的。从完成一项真实任务的视角看,这 6 个组件其实对应着一条很清晰的链路:先准备信息,再推动执行,最后复盘结果。所以顺着这条逻辑,它们又可以进一步归成 3 层:信息层、执行层、反馈层。三、四个实战案例深度解析案例一:一个编辑工具的改变,让 15 个模型同时变强来源:Can Duruk, “I Improved 15 LLMs at Coding in One Afternoon”, 2026.02独立开发者 Can Duruk 发现:Agent 修改代码文件的编辑工具本身就是一个巨大的失败源。问题在哪?——三种现有方案的缺陷想象你让 AI 修改一个代码文件。AI 需要告诉系统我要改什么。但怎么表达这个改,就成了一个大问题。方案一:OpenAI 的apply_patchAI 需要生成一个特定格式的 diff(差异文件):- const x 5; // 旧代码 const x 10; // 新代码问题:格式要求严格,AI 稍微写错格式就失败了。就像你要求别人手写一张支票,但笔迹、格式、金额必须完全精确——很容易出错。方案二:Claude Code 的str_replaceAI 需要这样告诉系统:把这段旧代码: const x 5; const y 10; 替换成: const x 10; const y 20;问题:AI 必须完全精确地复现原文本的每一个字符——包括空格、缩进、换行。如果有一个空格不对,就失败了。这就像你要求 AI 从一堆文字中找出一句话,然后在脑子里完全重现一遍,再替换成新的。非常容易出错。方案三:Cursor 的专用模型需要专门训练一个 70B 的模型来处理代码编辑。问题:训练成本高,而且只有 Cursor 能用。Hashline 方案:给每行代码一个指纹Can Duruk 想到了一个巧妙的办法:与其让 AI 精确复现文本,不如给每一行代码一个指纹(哈希值)。# 带哈希标签的代码abc │ const x5;def│ const y10;ghi │returnxy;AI 修改时只需这样说:把 abc 这一行改成:const x 10;优势:✅ AI 不需要完全复现原文本✅ AI 不需要生成复杂的 diff 格式✅ AI 只需指出这一行,然后提供新内容✅ 系统通过哈希值唯一确定是哪一行结果:同一个模型,十倍提升Grok Code Fast 1 模型: - 使用旧方案(str_replace):成功率只有 6.7% - 使用 Hashline 方案:成功率达到 68.3% - 提升倍数:十倍!这意味着:同一个 AI 模型,仅仅是改变了如何表达修改这个接口,就从几乎没用变成了有用的工具。核心洞察:传统软件工程中,人类用 VS Code 还是 Vim 不影响代码质量。但在 Agent 世界里,模型表达意图的接口设计直接决定了它能否把正确的想法变成正确的代码。这正是 Harness Engineering 的精髓——不是优化模型,而是优化模型工作的环境。Can Duruk 的原话是:“你在怪飞行员,但问题出在起落架上。”案例二:技术债的指数级放大效应来源:Reddit r/ClaudeAI, “52 Days, 350K Lines Solo”, 2026.03一位开发者在 52 天内用 AI Agent 独自构建了 35 万行生产代码,发现了一个传统开发中不存在的现象:技术债会被 Agent 指数级放大。当你做了一个临时妥协(绕过 Service 层直接查数据库),Agent 会把这个模式当作先例,下次生成类似功能时系统性地复用。人类工程师遇到烂代码知道这是地雷,Agent 则把它当作合法方案。一个坏模式Agent 视为先例系统性复制几小时内扩散到整个代码库当好的实践占主导时,Agent 放大好的实践;当捷径占主导时,Agent 放大捷径。传统软件工程中,技术债是线性累积的,一个坏模式可能被几个人模仿,但传播速度受限于团队规模和代码审查。在 Agent 协作开发中,技术债变成了自我复制的病毒:一个坏模式可以在几小时内被 Agent 复制到代码库的每一个角落。更多实际项目中会出现的技术债案例为了加深读者理解,让我们看更多实际项目中会出现的技术债,它们会被 Agent 指数级放大:1. 错误处理模式传统:某个文件用try-catch捕获了异常但不处理,只打印日志。几个开发人员看到后偶尔复制。Agent 放大:Agent 视为标准模式,在几百个函数中都加上同样的静默捕获,系统崩溃时根本看不到堆栈信息。2. 配置硬编码传统:某个环境变量写在代码里,文档标注记得改。少数人记得改,多数人会漏。Agent 放大:生成所有新功能时都复制这个硬编码模式,系统切换环境时几百处配置全部失效。3. 数据库查询模式传统:绕过 ORM 直接写 SQL,几个性能关键点这么用。大家知道这是特殊情况。Agent 放大:认为这是最佳实践,所有查询都手写 SQL,结果数据库索引失效、注入漏洞遍布系统。4. 测试覆盖缺失传统:某个工具函数没写测试,大家知道这个简单,不用测。Agent 放大:生成的几十个工具函数都没有测试,重构时一改就崩溃,根本不知道影响范围。5. 日志级别混乱传统:某个调试日志用了info级别,上线时没改。日志量大但还能忍受。Agent 放大:所有新代码都用info打印调试信息,日志量暴增 10 倍,监控告警被淹没。6. 状态管理反模式传统:某个组件用全局变量存临时状态,文档写了谨慎使用。Agent 放大:几十个组件都用全局状态,状态错乱、竞态条件频发,并发 bug 完全无法排查。7. 依赖版本冲突传统:引入一个包时没锁定版本,偶尔出问题才改。团队记得更新。Agent 放大:所有新项目都不锁定版本,几个月后依赖自动升级,系统一夜之间全面崩溃。8. 安全检查跳过传统:某个接口跳过认证,标注内部使用。开发人员知道不能外露。Agent 放大:认为这是标准模式,新接口统统跳过认证,安全审计发现 50 个未授权访问点。9. API 返回格式不一致传统:某个接口返回{data: {...}},另一个返回data。大家知道要看文档。Agent 放大:每次生成新接口都随机选一个格式,前端调用时完全不知道该怎么解析。10. 内存泄漏模式传统:某个定时任务没清理资源,运行几天后重启。大家接受这个权衡。Agent 放大:所有定时任务都不清理,服务器内存持续上涨,生产环境每天都要重启。应对策略:定期运行后台任务扫描偏差、更新质量等级发起有针对性的重构 PR(类似垃圾回收)人类的品味一旦被编码,就会持续应用于每一行代码技术债务就像一笔高息贷款:不断地以小额贷款的方式偿还债务,总比让债务不断累积,再痛苦地一次解决要好得多。人类的品味一旦被捕捉,就会持续应用于每一行代码。这也促使我们每天去发现并解决不良模式,而不是让它们在代码库中传播数天或数周。案例三:子 Agent 作为上下文防火墙来源:HumanLayer, “Skill Issue: Harness Engineering for Coding Agents”, 2026.03HumanLayer 团队在大量企业级棕地项目中发现了一个核心问题:Agent 的上下文窗口会随着工作推进而腐烂。每一次工具调用、每一次文件读取、每一次 grep 结果,都会在上下文中留下残留。当上下文膨胀到一定程度,Agent 就进入了他们所说的笨蛋区,即使是简单任务也开始出错。实证数据:18 个模型在 Terminal Bench 2.0 测试用例上的表现随上下文长度增加而显著下降,且当上下文中存在低语义相关性的干扰信息时,退化更加陡峭。解决方案——子 Agent 架构:┌─────────────────────────────────────┐ │ 父 Agent(Opus) │ │ 规划 编排,保持在聪明区 │ └──────────────┬──────────────────────┘ │ 高度压缩的结果 源引用 ┌──────────┼──────────┐ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ │子Agent│ │子Agent│ │子Agent│ │Sonnet │ │Sonnet │ │Sonnet │ │隔离上下文│ │隔离上下文│ │隔离上下文│ └───────┘ └───────┘ └───────┘父 Agent 负责规划,使用昂贵的高推理模型子 Agent 在隔离窗口中执行具体任务,使用便宜的快速模型子 Agent 只返回压缩结果,中间过程不污染父 Agent 上下文父 Agent 始终保持在聪明区,可以跨越数十个子任务维持连贯性阿里近期开源的 HiClaw 项目,采用的 Manager-Workers 架构,也可以认为是一种上下文防火墙,由 Manager 下发任务,每个 Worker 承担不同的职责,以避免记忆溢出或被污染,导致 Agent 进入笨蛋区。传统软件工程中,上下文管理是人类大脑自动完成的,我们不需要担心读了太多代码文件后会忘记项目架构。但 LLM 的上下文窗口是一个有限且会退化的资源。子 Agent 或者多 Agent 提供的上下文防火墙模式是一种全新的架构模式,它不是微服务,不是消息队列,不是任何传统分布式系统概念的翻版。它解决的是一个只有在非人类认知体执行任务时才会出现的问题:如何在有限的注意力预算内,完成需要无限注意力的工作。案例四:反馈回路的重新设计来源:HumanLayer 的实践 LangChain “Improving Deep Agents”HumanLayer 团队早期犯了一个看似合理的错误:每次 Agent 修改代码后,都运行完整的测试套件。结果 4000 行通过的测试输出涌入上下文窗口,Agent 开始对刚读到的测试文件产生幻觉,丢失了对实际任务的追踪。他们总结出一条反直觉的原则:成功应该是沉默的,只有失败才应该发出声音。# Hook 脚本示例defpost_edit_hook():resultrun_format_check()run_type_check()ifresult.success:returnNone# 完全静默else:returnresult.errors# 只返回错误LangChain 的实践更进一步:他们设计了PreCompletionChecklistMiddleware,在 Agent 试图交卷时拦截它,强制它对照任务规格做一次验证。同时用LoopDetectionMiddleware追踪对同一文件的重复编辑次数,在 N 次后注入也许你该换个思路的提示,帮助 Agent 跳出死循环。结果是,LangChain 的编码代理在 Terminal Bench 2.0 测试中从前 30 名跃升至前 5 名。传统 CI/CD 的反馈回路是为人类设计的:测试报告越详细越好,因为人类需要理解失败原因。但 Agent 的反馈回路需要对上下文窗口友好,信息量必须精确控制,成功信号要压缩到零,失败信号要精炼到最小可操作单元。更独特的是循环检测和强制验证,而人类工程师是不需要被提醒你已经改了同一个文件 10 次了,也不需要被强制在提交前对照需求文档检查一遍。这些是专门为非人类认知体的行为缺陷设计的补偿机制。五、Harness 工程对个人和企业项目的影响对于个人开发者从用什么模型到如何驾驭模型的思路转变传统开发中,个人开发者关注的是用什么语言、什么框架、什么库。在 AI 编程时代,这个焦点转移到了如何构建一个能让 Agent 高效工作的 Harness。代码规范的重新定义过去我们说的代码规范,往往是一份 STYLE.md,定义了缩进、命名、注释的格式。但在 Harness Engineering 中,代码规范的含义被大大扩展了:行为规范: Agent 应该怎么完成任务,而不是代码应该长什么样例如:所有 API 调用必须使用类型化 SDK是一种行为规范例如:禁止直接查询数据库,绕过 Service 层是一种行为规范完成条件: 什么是做完了的标准传统:编译通过、测试通过Harness:还要满足业务验收标准、性能指标、安全要求失败模式: 出问题了该怎么办传统:报错、人工修复Harness:自动重试、回滚、触发人工介入实践建议个人开发者可以从以下几个方面开始构建自己的 Harness:建立项目级别的 AGENTS.md记录你的偏好、禁忌和期望每次 Agent 做错了什么,都记下来,下次就不会再犯设计渐进式的上下文结构PROJECT.md: 项目基本信息、架构概览AGENTS.md: Agent 行为规范和约束SKILLS/: 按 task 分组的最佳实践DOCS/: 详细的文档、API 说明、示例配置工具集Claude Code 的工具配置限制工具数量,保持精简定期审视,移除不必要的工具对于企业项目从管理开发人员到管理 Agent的范式转移在企业环境中,Harness Engineering 的影响更加深远:1. 代码规范的全面升级传统的代码规范往往只是静态规则,比如:命名规范注释规范文件组织规范而 Harness Engineering 要求的代码规范,是一套完整的、可执行的、可验证的系统:架构约束: 哪些模式是禁止的?哪些是必须的?constraints:forbidden_patterns:-直接查询数据库,绕过 Service 层-硬编码魔法数字required_practices:-所有 API 调用必须使用类型化 SDK-边界验证必须显式声明质量门禁: 什么条件下才能合并代码?quality_gates:code_coverage:80%security_scan:passperformance_test:p99 200ms升级规则: 什么时候需要人工介入?escalation_rules:-超过 3 次编辑同一文件,触发人工介入-测试失败超过 5 次,停止并报警2. 从事后补救到事前预防传统软件工程中,技术债的管理往往是事后补救:发现了 bug,修复它发现了性能问题,优化它发现了安全问题,打补丁而在 Harness Engineering 中,技术债被转化为自动化规则:把不要这样做编码为约束把必须这样做编码为规范让 Agent 在生成代码时就遵守这些规则3. 团队协作方式的变化传统团队协作中:Human → Human: 通过 Code Review,通过文档,通过口头沟通Human → Human → Human: 通过会议,通过 IM,通过项目管理工具在 Agent 协作时代:Agent → Agent: 通过 SKILL.md,通过工具接口Human → Agent: 通过 AGENTS.md,通过反馈回路Agent → Human: 通过质量门禁,通过升级规则4. 知识管理的范式转移传统的知识管理:文档是静态的,需要人工维护最佳实践分散在多个地方,难以统一新人学习曲线陡峭Harness Engineering 中的知识管理:SKILL.md 是可执行的,Agent 可以直接使用最佳实践被编码为自动化规则Agent 通过观察执行轨迹,自动学习和改进5. 成本控制与 FinOps在企业环境中,Token 消耗是一个重要成本:上下文压缩: 频繁压缩,控制在 60% 以下子 Agent 隔离: 避免共享上下文造成的污染和膨胀工具精简: 工具越少,决策成本越低,Token 消耗越少循环检测: 避免死循环造成的无限消耗典型的企业级 Harness 架构一个企业级的 Harness 通常包含以下几个层次:L1 - 基础设施层沙箱环境权限管理失败恢复机制日志与监控L2 - 执行层工具配置SKILL 管理任务编排多 Agent 协调L3 - 约束层架构约束质量门禁安全规则合规要求L4 - 反馈层自动化测试质量验证性能监控成本追踪L5 - 观测层执行轨迹调试工具分析看板报表系统实施建议对于想要引入 Harness Engineering 的企业,建议按照以下步骤:阶段 1: 基础设施 (1-2 周)选择合适的 Agent 平台 (Claude Code, Codex 等)配置基础的沙箱和权限管理建立基本的日志和监控阶段 2: 规范定义 (2-4 周)编写 AGENTS.md,定义行为规范设计架构约束规则配置基础的代码质量门禁阶段 3: 上下文构建 (4-8 周)建立渐进式的上下文结构编写核心 SKILL迁移关键文档到 Agent 可读格式阶段 4: 反馈闭环 (持续)配置自动化测试和验证建立技术债自动清理机制持续优化和迭代阶段 5: 规模化扩展 (按需)多 Agent 协作架构复杂任务编排企业级监控和分析九、总结:同一个模型,不同的 Harness,截然不同的结果Harness Engineering 告诉我们:Agent 的竞争优势不只在于你用了哪个模型,更在于你构建了怎样的 Harness。四个案例揭示的核心洞见:接口设计决定上限:Hashline 让 15 个模型同时变强熵管理是生存问题:技术债会被 Agent 指数级放大上下文是稀缺资源:子 Agent 架构保护父 Agent 的聪明区反馈回路要为 Agent 设计:成功沉默,失败发声Harness 正在成为新的护城河——不只是 Agent Builder 的护城河,更是 Agent User 的护城河。如果把 prompt engineering、context engineering 和 harness engineering 放在一起看,它们其实很像一个初级员工的成长过程。最开始,你只能和他做简单问答;再往后,你可以把完整的业务背景交给他,让他独立完成一轮深入调研;再往后,你开始给他工具、权限和反馈机制,让他自己拆任务、调工具,甚至带着几个 subagents 一起干活。那我们不禁在想,再下一个范式会是什么?在人类现实职场中,大部分人都会有相对明确的 career path:从一名初级员工,逐渐积累经验,甚至升级为一个高管,从执行者变成规划者,带领几十个下属完成一个高度复杂的项目。如果沿着人类员工的经验做一个自然推演,那么下一阶段 Agents 需要达到的,大概也是协调无数 agent / 人类节点共同完成复杂任务。我们或许可以暂且叫做——Coordination Engineering(协同工程)。OpenAI 的工程负责人和产品设计师在 1 月底的一期播客采访里,也多次提到了他们在思考 multi-agent networks。“我不方便讲太多 roadmap,不过有一个挺值得思考的问题是:一旦进入 multi-agent 世界,复杂度会迅速上升,那你怎么才能管理这一切?用户怎么才能始终知道每个 agent 在做什么、执行了哪些动作、流程推进到哪一步,以及中间哪些地方需要自己介入、授权或纠偏?”所以从这个角度看,下一代 AI 产品未必是一个更聪明的小龙虾,而更像一个小龙虾版飞书,本质是一个有效的监工看板 一个能让各种节点有效协作的 im 平台。最终这四个层级叠加起来,可能就构成了 Agentic engineering 的终极范式。它们之间不是一个替代关系,而是一个包含关系,智能的水位涨上来,控制面就开始不断上移:L1 解决问答质量L2 解决认知边界L3 解决执行闭环L4 解决组织协同再往终极推演呢?一切似乎就只剩下了intention engineering(意图工程),人的价值只剩下了设定目标函数,其余 AI 都可自行包揽。到那时候再回头看,所谓的白领工作,可能真的是人类历史走过的一段弯路。参考文献OpenAI: Harness Engineering: Leveraging Codex in an Agent-First WorldCan Duruk: I Improved 15 LLMs at Coding in One AfternoonHumanLayer: Skill Issue: Harness Engineering for Coding AgentsLangChain: Improving Deep Agents with Harness EngineeringHarness驾驭工程是AI平权的必经之路?Harness is the New Dataset:模型智能提升的下一个关键方向