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%。
模型没变,变的是它外面那套系统。68% 的跳变，靠系统不靠模型？
这个数字直接证明了 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 通过最小化上下文,规避了这个瓶颈。专属 Agent 的解法，管用吗？
3. 知识库鲜度自检
腾讯应用宝的另一个亮点,是给每个 Agent 配置了”知识库鲜度自检”能力。
具体来说,每个 Agent 在执行任务前,会自动检查自己依赖的文档、API 定义、依赖版本是否过期。
如果发现过期信息,会先触发更新流程,再用最新的知识执行任务。
这个机制解决了一个长期困扰工业界的问题:LLM 训练数据有截止日期,而工程体系的代码、文档、依赖几乎每天都在变化。
如果 Agent 沿用陈旧知识做决策,产生的方案在落地时就可能因为”对不上当前代码”而失败。
鲜度自检相当于给每个 Agent 装了一个”知识保鲜”机制。
4. 专家 Agent 各司其职
整套体系被命名为”专家 Agent 各司其职”的多 Agent 协作框架,这套框架下,不同 Agent 之间的通信、任务分发、结果聚合。
由一个编排层(Orchestrator)负责。编排层这设计，够清晰吗？
编排层的设计,沿用了业界对 Agent 体系的标准抽象:Harness 驱动单个模型走执行循环。标准抽象这层，你认可吗？
Orchestrator 把 Agent 当作单元来管理,每个 Agent 跑自己的 Harness。Orchestrator 思路，学到了吗？
腾讯应用宝的实践,是在这个抽象下,把”专家化分工”做到了微服务级别。
值得一提的是,这种”专家化分工”的设计哲学,和传统微服务架构里的”单一职责”原则高度一致。单一职责类比，贴切吗？
每个 Agent 只关注自己领域的微服务和文档,不需要了解整个系统的全貌。
这种设计天然适合大规模工程体系——当系统规模继续增长时,只需要增加新的专家 Agent,而不需要改造现有的 Agent。
这种横向扩展能力,是 Harness Engineering 在工业级场景下能落地的关键支撑。
四、概念厘清:Harness 与 Scaffolding 的边界
北大《驯服 Agent》报告里特别花了篇幅厘清 Harness 和 Scaffolding(脚手架)的边界。
因为这是过去一年业界讨论中最容易混淆的一对概念。Harness 和脚手架，你分得清吗？
报告给出的判断标准是:
- 脚手架是信息,模型能看到——它包括系统提示词、工具描述、输出格式约束
- Harness 是逻辑,模型看不到但驱动它运行——它包括调用循环、错误处理、状态管理、反馈回路
一个简单的比喻:脚手架是剧本和道具,Harness 是导演和舞台监督,负责把一切串起来执行。
这个区分在工程实践里很关键——如果把 Harness 当成”超级 Prompt”塞进上下文,反而会让 Agent 跑偏。
正确的做法是把 Harness 写成模型看不到的代码逻辑,而脚手架才以 Prompt 形式暴露给模型。
五、”代码从被凝视变被消费”:工业实践带来的范式转变
腾讯应用宝这次发布里,有一个被广泛传播的判断:”代码从被凝视变被消费”。
在传统的工程文化里,代码是工程师智慧的结晶,需要被仔细 review、反复打磨、谨慎提交。
代码 review 是工程质量的护城河,也是工程师之间知识传递的核心机制。
但在 Harness Engineering 范式下,代码的角色发生了根本转变——它不再是”需要被凝视的工艺品”,而是”Agent 消费的产品”。
Agent 不需要欣赏代码的美感,只需要代码能跑、接口对得上、依赖没过期。代码 review 的重心,从”风格好不好”转移到”契约对不对”。
这种转变对工程文化的冲击是深远的。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 等业界公开实践整理)
同类工具挑花眼的时候，可以看AI 办公工具这个合集按用途分好了，可以直接对比。
