Harness Engineering(驾驭工程)是 OpenAI 在 2026 年 2 月正式提出的工程范式,核心论点是:Agent 的能力上限,主要不取决于模型本身,而取决于模型外面那套工程系统——也就是 Harness。半年过去,这个范式从概念迅速走向工业落地。

7 月 23 日,腾讯应用宝与北京大学几乎同时放出关于 Harness Engineering 的重磅信息——一边是工业级跑通的工程实践,一边是学术层面的范式定调。两件事相隔不到 12 小时,把过去半年 AI Agent 圈最热的一个工程范式,从概念阶段推到了”可大规模生产部署”的阶段。

腾讯应用宝披露,已将其工程体系中 90+ 个微服务、800+ 篇工程文档的日常维护工作,完整移交给了 Agent 系统接管。这套系统的设计思路是 Harness Engineering:把每个维护任务拆解成子任务,交给专属 Agent;每个 Agent 维护各自领域的知识库,且知识库具备”鲜度自检”能力,过期信息会被自动标记并触发更新;整套体系被命名为”专家 Agent 各司其职”的多 Agent 协作框架。

几乎同一时间,北京大学发布了一份名为《驯服 Agent》的研究报告,正式给出学术界对 Harness Engineering 的定调:Agent = Model + Harness。报告把过去一年业界围绕 Harness、Context Engineering、Scaffolding 的概念混乱,梳理成一条清晰的边界——模型负责推理,模型之外的所有”工程脚手架”统称 Harness,Harness 决定了 Agent 能不能稳定干活。

这次”工业 + 学术”的双重确认,在 AI Agent 工程化进程里具有标志性意义。学术报告给出了范式的概念锚点,工业实践给出了范式的可行性证据,两者结合意味着 Harness Engineering 已经走出实验室,开始具备大规模生产部署的条件。

一、范式锚定:Agent = Model + Harness

要理解腾讯应用宝这次的发布,首先要理解北大《驯服 Agent》报告里给出的核心定义。

报告指出,过去一年业界对 Harness、Context Engineering、Scaffolding、Prompt Engineering 这几个概念的定义一直混乱——很多人把它们当成可以互相替换的同义词,实际上它们处理的问题范围完全不同。

报告给出的层级关系是这样的:

  • Prompt Engineering:关注怎么把指令说清楚,让模型理解意图、减少局部歧义
  • Context Engineering:关注在合适的时机,给模型提供正确且必要的信息
  • Harness Engineering:关注系统怎么持续执行、纠偏、观测和恢复,处理的是长链路任务中的持续正确性

报告给出的核心公式是:Agent = Model + Harness。模型只提供推理和生成能力,Harness 则把状态、工具、反馈、执行环境和安全边界串起来。模型是 CPU,Harness 是操作系统——CPU 再强,OS 天天崩,实际体验也不会好。

报告里有一个被广泛引用的实验数据:同一个模型,只换了文件编辑接口的调用方式,编码基准分数从 6.7% 跳到了 68.3%。模型没变,变的是它外面那套系统。这个数字直接证明了 Harness 工程的投入产出比——提升 Harness 的工程化水平,比单纯升级模型能力更显著。

二、范式细节:Harness 的六层架构

把 Harness 拆开看,根据业界公开实践,可以总结出相对成熟的六层架构:

L1 信息边界层,定义 Agent 该知道什么、不该知道什么。它把任务状态、角色目标、上下文裁剪规则结构化组织起来,是 Agent 的”岗位说明”。

L2 工具系统层,决定 Agent 怎么和外部世界交互。它负责选择工具、控制调用时机、提炼工具结果并反馈给模型。

L3 执行编排层,把多步骤任务串成”理解目标→判断信息→分析→生成→检查”的轨道,确保 Agent 不会跑偏或漏步骤。

L4 记忆与状态层,管理长任务中的中间结果。它把当前任务状态、中间产物和长期记忆分开管理,避免上下文污染。

L5 评估与观测层,让 Agent 能独立判断自己有没有做对。这一层需要建立独立于生成过程的验证机制,包括日志、指标、链路追踪。

L6 约束、校验与恢复层,处理出错场景。它预设规则拦截错误,失败时提供重试、回滚或降级。

业界普遍认为,不必一开始就搭建完整的六层。更现实的做法是先做 L1(信息边界)和 L6(约束恢复),这两层投入不高,但通常最容易见效。

六层架构的工程意义在于,它把 Agent 系统的复杂度做了清晰的纵向切分。每一层都可以独立演进、独立测试、独立替换。比如 L2 工具系统层可以从最初的几个 CLI 命令,逐步扩展到几十个 MCP 工具,不会影响 L3 执行编排层的结构;L5 评估与观测层可以从最基础的日志记录,逐步升级到完整的可观测性栈。这种”分层独立演进”的能力,是传统单体式 Agent 设计难以企及的。

三、工业级跑通:腾讯应用宝的实践细节

腾讯应用宝这次的发布,是 Harness Engineering 在工业级工程体系里的首次完整跑通。

1. 90+ 微服务、800+ 文档的”移交”

腾讯应用宝披露,其工程体系中 90+ 个微服务、800+ 篇工程文档的日常维护工作,已经完整移交给 Agent 系统接管。所谓”日常维护”,包括但不限于:依赖升级、接口对齐、文档同步、Bug 修复、监控告警配置、跨服务调用链梳理等。

在传统的工程组织里,这类工作依赖资深工程师手动处理,常常因为人员流动、文档陈旧、模块耦合度高而积累成技术债。腾讯应用宝的实践,是把这部分工作从”需要人盯”变成”Agent 自己消化”。

2. 子任务拆给专属 Agent

腾讯应用宝的核心机制之一,是把每个微服务的维护任务拆解成子任务,交给专属 Agent 处理。每个 Agent 只关注自己负责的微服务或文档领域,携带的上下文尽量精简,留在模型的”高效区”里。

这种设计的底层逻辑是:Harness 工程化的核心矛盾是上下文管理。一个 Agent 塞太多信息,反而会进入”上下文焦虑”状态——根据业界公开数据,168K token 的上下文窗口,用到大约 40% 时,Agent 输出质量就开始明显下降。专属 Agent 通过最小化上下文,规避了这个瓶颈。

3. 知识库鲜度自检

腾讯应用宝的另一个亮点,是给每个 Agent 配置了”知识库鲜度自检”能力。具体来说,每个 Agent 在执行任务前,会自动检查自己依赖的文档、API 定义、依赖版本是否过期。如果发现过期信息,会先触发更新流程,再用最新的知识执行任务。

这个机制解决了一个长期困扰工业界的问题:LLM 训练数据有截止日期,而工程体系的代码、文档、依赖几乎每天都在变化。如果 Agent 沿用陈旧知识做决策,产生的方案在落地时就可能因为”对不上当前代码”而失败。鲜度自检相当于给每个 Agent 装了一个”知识保鲜”机制。

4. 专家 Agent 各司其职

整套体系被命名为”专家 Agent 各司其职”的多 Agent 协作框架,这套框架下,不同 Agent 之间的通信、任务分发、结果聚合,由一个编排层(Orchestrator)负责。

编排层的设计,沿用了业界对 Agent 体系的标准抽象:Harness 驱动单个模型走执行循环,Orchestrator 把 Agent 当作单元来管理,每个 Agent 跑自己的 Harness。腾讯应用宝的实践,是在这个抽象下,把”专家化分工”做到了微服务级别。

值得一提的是,这种”专家化分工”的设计哲学,和传统微服务架构里的”单一职责”原则高度一致。每个 Agent 只关注自己领域的微服务和文档,不需要了解整个系统的全貌。这种设计天然适合大规模工程体系——当系统规模继续增长时,只需要增加新的专家 Agent,而不需要改造现有的 Agent。这种横向扩展能力,是 Harness Engineering 在工业级场景下能落地的关键支撑。

四、概念厘清:Harness 与 Scaffolding 的边界

北大《驯服 Agent》报告里特别花了篇幅厘清 Harness 和 Scaffolding(脚手架)的边界,因为这是过去一年业界讨论中最容易混淆的一对概念。

报告给出的判断标准是:

  • 脚手架是信息,模型能看到——它包括系统提示词、工具描述、输出格式约束
  • Harness 是逻辑,模型看不到但驱动它运行——它包括调用循环、错误处理、状态管理、反馈回路

一个简单的比喻:脚手架是剧本和道具,Harness 是导演和舞台监督,负责把一切串起来执行。

这个区分在工程实践里很关键——如果把 Harness 当成”超级 Prompt”塞进上下文,反而会让 Agent 跑偏;正确的做法是把 Harness 写成模型看不到的代码逻辑,而脚手架才以 Prompt 形式暴露给模型。

五、”代码从被凝视变被消费”:工业实践带来的范式转变

腾讯应用宝这次发布里,有一个被广泛传播的判断:”代码从被凝视变被消费”。

在传统的工程文化里,代码是工程师智慧的结晶,需要被仔细 review、反复打磨、谨慎提交。代码 review 是工程质量的护城河,也是工程师之间知识传递的核心机制。

但在 Harness Engineering 范式下,代码的角色发生了根本转变——它不再是”需要被凝视的工艺品”,而是”Agent 消费的产品”。Agent 不需要欣赏代码的美感,只需要代码能跑、接口对得上、依赖没过期。代码 review 的重心,从”风格好不好”转移到”契约对不对”。

这种转变对工程文化的冲击是深远的。它不是否定代码 review 的价值,而是把 review 的维度重新组织——人在做高维度决策(架构、契约、安全),Agent 在做中低维度的执行(代码生成、依赖升级、文档同步)。

六、行业意义:从论文到生产环境的最后一公里

腾讯应用宝和北大《驯服 Agent》报告的双重确认,标志着 Harness Engineering 这个工程范式走完了”从论文到生产环境”的最后一公里。

过去一年,Harness Engineering 已经在多个重量级场景跑通:

OpenAI 用 3 名工程师、5 个月时间,产出约 100 万行代码,合并约 1500 个 PR,日均 PR/人 3.5 个,效率提升约 10 倍。Anthropic 用 16 个并行 Claude Opus 实例、约 2000 个 Claude Code 会话,跑出一个 GCC torture test 通过率 99% 的 C 编译器。Stripe 的 Minions 系统每周产出超过 1300 个无人值守 PR。

这些案例的共同点是:模型可能没换太多,但 Harness 的工程化水平决定了产出。腾讯应用宝这次的发布,是这个范式在中国工业级工程体系里的首次完整跑通——90+ 微服务、800+ 文档的规模,意味着它已经不是在跑 demo,而是在跑生产。

七、风险与展望

Harness Engineering 的快速落地,也带来几个需要持续关注的风险。

第一,”熵不会自己消失”。AI 生成的代码越多,低质量实现、重复逻辑、文档不一致也会跟着变多。如果清理速度跟不上生成速度,项目迟早会被自己的产物拖垮。腾讯应用宝的”专家 Agent 各司其职”框架,是把清理责任分摊到了每个专属 Agent,但这种分摊机制能否长期有效,还需要更多生产环境的验证。

第二,棕地项目改造难题。业界公开的成功案例几乎都是绿地项目(从零搭建),而大多数企业面对的是跑了多年的老代码库。Harness 在老代码库上的应用方法论,目前还不成熟。

第三,Harness 该做厚还是做薄。通用 Agent 产品追求 Harness 最小化,特定产品可以高度定制。模型能力提升后,旧的 Harness 保护机制可能变成冗余,Harness 本身也需要定期简化。

北大《驯服 Agent》报告和腾讯应用宝的实践,共同给出了 2026 年下半年 AI Agent 工程化的清晰信号:Agent 能不能稳定干活,越来越取决于 Harness 工程的成熟度,而不是模型本身的能力。模型继续升级,Harness 工程化也需要同步跟进——这场赛跑才刚开始。

对国内大厂而言,腾讯应用宝这次的发布可能只是一个开端。可以预期的是,未来一段时间内,会有更多大厂把 Harness Engineering 引入自己的工程体系。判断一套 Harness 是否真正成熟,关键不在于它用了多复杂的工具或多新颖的架构,而在于它能不能在生产环境里稳定运行——就像腾讯应用宝这次展示的:90+ 微服务、800+ 文档,在没有手写维护代码的情况下,仍然能保持高质量运转。这种”工业级稳定性”,才是 Harness Engineering 真正的护城河。

(来源:综合腾讯应用宝技术披露、北京大学《驯服 Agent》研究报告、OpenAI/Anthropic/Stripe 等业界公开实践整理)