Harness Engineering 深度:从 OpenAI 100 万行实践看 Agent 工业化

前面两篇文章我们分别从资讯(腾讯应用宝 + 北大定调)和零基础入门(AI Agent 核心概念、LangGraph 实战)的角度讲了 Harness 的概念。今天我们把这个话题推到最深处——从 OpenAI 的工业级实践出发,讲清楚 Harness 到底是什么、为什么关键、怎么在你的 Agent 项目里落地。

Harness Engineering 是 OpenAI 在 2026 年 2 月正式提出的工程范式,核心论点是:

Agent 能不能稳定干活,70% 取决于 Harness,30% 取决于模型。

这个数字听起来夸张,但 OpenAI 自己用 3 个工程师、5 个月时间、产出约 100 万行代码、合并约 1500 个 PR、日均 3.5 个 PR/人的”零手写代码”实践,直接验证了这一点。同样的产出,如果靠传统手写,需要 25-30 名工程师 5 个月。

而腾讯应用宝在 2026 年 7 月披露:它已经把 90+ 微服务、800+ 文档交给 Harness 化的 Agent 系统日常维护,这是 Harness 在中国工业级工程体系里的首次完整跑通。

学完这篇,你不仅能理解 Harness 的核心思想,还能在自己的 Agent 项目里落地一套能跑能演进的 Harness 体系。

一、Harness Engineering 是什么:从概念到本质

Harness 这个词字面意思是”马具、缰绳、驾驭系统”。OpenAI 用它比喻”模型之外的整套工程系统”。

具体来说,Harness 包含所有”让 Agent 能干活、且干得稳”的东西:

系统提示词(System Prompt)
工具调用机制(Tool Use / Function Calling)
文件系统访问(File System)
沙箱执行环境(Sandbox)
记忆机制(Memory)
反馈回路(Feedback Loop)
约束执行机制(Constraint + Recovery)
监控可观测性(Observability)
错误恢复(Error Recovery)

整个公式:Agent = Model + Harness

模型只提供”想”的能力(理解任务、推理路径、生成输出),Harness 提供”做”的能力(执行、纠错、恢复、观测)。这就是为什么我说”Harness 决定 Agent 能不能稳定干活”。

一个直观的比喻:

模型 = CPU(负责计算)
Harness = 操作系统(负责调度、内存管理、设备驱动)

CPU 再强,如果 OS 天天崩,实际体验也不会好。CPU 中等但 OS 稳定,反而可能更强。这跟”Agent 80% 的可靠性来自 Harness”是完全一致的逻辑。

二、OpenAI 的”100 万行代码”实践:工业化的样板

2025-2026 年,OpenAI 内部做了一件引起行业轰动的事:3 名工程师 + 5 个月时间,产出约 100 万行代码、合并约 1500 个 PR、日均 PR/人 3.5、效率提升约 10 倍。

数据指标

指标	数值
团队规模	3 名工程师,后扩至 7 人
持续时间	5 个月,2025 年 8 月起
代码规模	约 100 万行
手写代码	0 行,设计约束
合并 PR 数	约 1,500 个
日均 PR/人	3.5 个
效率提升	约 10 倍

这些数字看起来不可思议,但比数字更重要的是”怎么做”。

关键实践一:给 Agent 一张地图,不要塞一本千页手册

OpenAI 的 AGENTS.md 大约只有 100 行,作用更像目录,指向 docs/ 目录下更深层的设计文档、架构图、执行计划和质量评级。这就是”渐进式披露”——先给最关键的信息,需要更多细节时再加载。

这和到一个新城市很像。你不需要背完整本旅游指南,先给一张地图,告诉你想了解某个景点时去翻哪一页。

Agent Skills 也可以看作渐进式披露的一种实现:它保留少量元数据(名称、描述),详细规则和执行流程只在触发时再加载进上下文。这种模式把”按需加载”标准化了。

关键实践二:架构约束要靠工具执行

OpenAI 给每个业务领域定义了固定分层:Types → Config → Repo → Service → Runtime → UI。

依赖方向不能反过来。怎么保证?

靠自定义 Linter 和结构测试。违反规则时,工具不只是报错,还会告诉 Agent 应该怎么改。Agent 在修错的过程中,也被反复训练成更符合团队规范的写法。

OpenAI 有句原话很直接:“If it cannot be enforced mechanically, agents will deviate.” ——只写在文档里的约束不够,不能机械化执行,Agent 迟早会偏离。

这给我们的启示是:Harness 中”约束”必须机械化、可执行、可验证。文档描述只是辅助,真正的约束必须靠代码(Linter、Schema 校验、自动测试)。

关键实践三:可观测性也要给 Agent 看

他们把 Chrome DevTools Protocol 接进 Agent 运行时,Agent 可以自己抓 DOM 快照和截图。日志、指标、链路追踪也通过本地可观测性栈暴露给 Agent。

这样一来,”把启动时间降到 800ms 以下”就变成了一个 Agent 可以自己测量、自己验证的目标。

这个做法的关键是:Agent 不能只看自己的”输出”,还要能”测量”自己输出的效果。可观测性不是工程师调试用的,要暴露给 Agent,让它能自我评估、自我迭代。

关键实践四:熵不会自己消失

AI 生成的代码越多,低质量实现、重复逻辑、文档不一致也会跟着变多。一开始 OpenAI 团队每周五花 20% 时间手动清理这些生成物。后来这件事被自动化了:后台 Agent 定期扫描文档不一致、架构违规和冗余代码,并自动提交清理 PR。

这个点很现实。生成速度上来了,如果清理速度跟不上,项目迟早会被自己的产物拖垮。”生成 + 清理”必须配套,不能只管生不管收。

关键实践五:知识作为版本控制制品

写在 Slack 讨论或 Google Docs 里的知识,对 Agent 来说并不稳定。OpenAI 的做法是把团队知识作为版本控制制品放进仓库,让仓库成为可追踪、可引用的事实来源。

这跟”文档优先放代码库”的工程实践一致。但 OpenAI 把它推到极致——所有”团队共识”都要进仓库,因为 Agent 只能稳定访问代码库里的东西。

三、腾讯应用宝的”工业级跑通”:中国版本

2026 年 7 月 23 日,腾讯应用宝对外披露:它已经将工程体系中 90+ 个微服务、800+ 篇工程文档的日常维护工作,完整移交给了 Agent 系统接管。

这套系统的设计思路是 Harness Engineering 范式,有 4 个亮点:

亮点 1:子任务拆给专属 Agent

90+ 个微服务的维护任务,被拆解成子任务,交给专属 Agent 处理。每个 Agent 只关注自己负责的微服务或文档领域,携带的上下文尽量精简,留在模型的”高效区”里。

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

亮点 2:知识库鲜度自检

每个 Agent 在执行任务前,会自动检查自己依赖的文档、API 定义、依赖版本是否过期。如果发现过期信息,会先触发更新流程,再用最新的知识执行任务。

这个机制解决了一个长期困扰工业界的问题:LLM 训练数据有截止日期,而工程体系每天都在变化。鲜度自检相当于给每个 Agent 装了”知识保鲜”机制。

亮点 3:专家 Agent 各司其职

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

编排层的设计,沿用了业界对 Agent 体系的标准抽象:Harness 驱动单个模型走执行循环,Orchestrator 把 Agent 当作单元来管理,每个 Agent 跑自己的 Harness。

亮点 4:横向扩展能力

当系统规模继续增长时,只需要增加新的专家 Agent,而不需要改造现有的 Agent。这种横向扩展能力,是 Harness Engineering 在工业级场景下能落地的关键支撑。

腾讯应用宝 + OpenAI 的实践共同验证:Harness 工程化是 2026 年 Agent 工业化的必经之路——单 Agent 最多能做 demo,要做到企业级,必须 Harness。

四、Harness 的六层架构:从设计原则到实施细节

把 Harness 工程化,要按层次来设计。根据业界公开实践,可以总结出相对成熟的六层架构。

L1 信息边界层

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

L1 的关键决策:让 Agent 看到”任务相关”的内容,过滤掉”任务无关”的内容。这跟 Cursor 的 AGENTS.md 设计哲学一致——100 行的目录,而不是 10000 行的手册。

L2 工具系统层

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

L2 的关键决策:工具数量不是越多越好,而是越精准越好。一个 50 个工具但能精准完成任务的 Agent,远胜于 200 个工具但定义模糊的 Agent。

L3 执行编排层

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

L3 的关键决策:让 Agent 在每一步都有”检查点”,出问题时能定位到具体步骤。

L4 记忆与状态层

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

L4 的关键决策:短期记忆和长期记忆分开存储。短期在上下文窗口,长期在外部存储(如 Postgres),按需检索注入。

L5 评估与观测层

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

L5 的关键决策:评估逻辑不能复用 Agent 自己的判断——用 AI 生成的测试来验证 AI 生成的代码,像”用同一双眼睛检查自己的作业”。需要独立的评估机制(Linter + 自动测试 + 人工抽检)。

L6 约束、校验与恢复层

处理出错场景。它预设规则拦截错误,失败时提供重试、回滚或降级。

L6 的关键决策:错误要可恢复,不能只是”失败”。一个 Agent 跑崩了,系统应该能自动重试或切换到降级方案,而不是整个服务挂掉。

不要一次搭齐六层

更现实的做法是先做 L1(信息边界)和 L6(约束恢复),这两层投入不高,但通常最容易见效。中间几层可以随着项目复杂度慢慢补。

OpenAI 的实践也是分阶段——先 AGENTS.md(L1)+ Chrome DevTools(L5)+ Linter(L6),再补 L2-L4。

五、Harness 工程化的实施步骤:从 demo 到生产

把你的 Agent 项目从 demo 推到生产级,大致要走过这 5 步。

步骤 1:把”约束”机械化(P0,1 周可完成)

不要再让 Agent 靠”记忆”遵守规范。把所有约束写成 Linter、Schema 校验、CI 检查。这是 OpenAI “If it cannot be enforced mechanically, agents will deviate” 的直接体现。

具体做法:

写 .eslintrc / pyproject.toml 把风格约束机械化
用 JSON Schema 校验 API 输入输出
把架构规则写成”自动测试”(如”service A 不能直接调 service B”)

步骤 2:AGENTS.md 加 Skills 渐进披露(P0,1 天)

别再让 Agent “读 10000 行文档”了。建一个 AGENTS.md(100 行),做目录;详细规则分到子文档,按需加载。

这是 OpenAI 的核心做法。每个 Agent 启动时,只加载 AGENTS.md 索引,需要时再读子文档。

步骤 3:加记忆分层(P1,3-5 天)

短期记忆放上下文窗口,长期记忆放外部存储(Pinecone、Postgres)。重要决策、用户偏好、项目关键状态,都进长期记忆。

把 Agent 当成”新员工”:它第一次来公司,只带脑子(模型),不带历史(记忆),你要给它”入职培训资料”(AGENTS.md)+ “工作笔记”(长期记忆)。

步骤 4:加评估体系(P1,1 周)

写 50-100 个测试用例,覆盖核心场景。每次 Agent 代码改动后,跑这些用例,验证质量没退化。

评估项包括:

准确性(任务是否完成)
一致性(同样输入,输出是否稳定)
性能(响应时间、token 消耗)
安全性(没有越权操作)

步骤 5:加可观测性 + 自动清理(P2,1-2 周)

让 Agent 能”测量”自己的效果(Chrome DevTools / OpenTelemetry / 自定义埋点)。

后台 Agent 定期扫描代码库,提交”清理 PR”(删除冗余、修复不一致、收紧架构违反)。

OpenAI 后期才开始这一步,但他们发现这是必要的——生成速度上来了,清理速度跟不上,项目迟早崩。

六、常见坑:Harness 实施中最容易踩的 5 个坑

坑 1:过度配置,Agent 反而变笨

症状:AGENTS.md 写了 5000 行、各种规则堆满,Agent 启动时塞满上下文,反而效率降低、决策变差。

修复:严格控制上下文大小。OpenAI 的做法是 AGENTS.md 100 行 + 子文档按需加载,而不是一份”超级手册”。

坑 2:Linter 不能执行,只是文档

症状:架构约束写在 wiki,但 Agent 看不到 → 实际不生效。

修复:约束必须可执行、可验证。任何”应该这样写”的规则,要么变成 Linter,要么变成测试用例。

坑 3:可观测性只对工程师透明,Agent 看不到

症状:Agent 完成一个任务,但不知道自己的代码在生产里跑得怎么样。

修复:OpenTelemetry / 自定义日志必须暴露给 Agent。让 Agent 能”看”自己的服务指标,才能自我评估、自我迭代。

坑 4:没有评估体系,质量靠运气

症状:上线后不知道 Agent 行为是否稳定,出问题只能事后追溯。

修复:建一个固定的测试集(50-100 个 case),每次改动都跑一遍。这是”质量的红绿灯”。

坑 5:熵没清,生成即债务

症状:Agent 生成的代码越来越多,质量参差不齐,文档越来越不一致。

修复:后台 Agent 定期清理,提交”质量改进 PR”。OpenAI 后来开发了专门的清理 Agent 跑这件事。

七、Harness 与 Vibe Coding、RAG、多 Agent 的关系

学到这里,你可能好奇 Harness 跟 Vibe Coding、RAG、多 Agent 这些”周边概念”是什么关系。

Harness 是底层,其他都是上层应用:

Vibe Coding:用 Agent 写应用。Harness 提供”Agent 怎么稳定跑”的工程底座
RAG:给 Agent 接知识库。Harness 提供”记忆怎么分层”的知识管理
多 Agent:多个 Agent 协作。Harness 提供 Orchestrator + 编排层的实现细节

也就是说,Harness 是 2026 年所有 AI 应用的”工程基础设施”——你做任何一个 AI 产品,本质上都在做 Harness 的一部分。

北大 7-23 同日发布的《驯服 Agent》报告,正式给出了这个论断:”Agent = Model + Harness”。这是学术界对过去一年业界实践的总结与定调。

八、Harness 工程化的行业意义

Harness Engineering 不只是一个技术范式,它代表了 AI 时代的”工程思维转变”:

转变 1:从”提示词优化”到”系统优化”

过去一年,大家都在讨论 prompt engineering、context engineering。Harness 把这些讨论统一到”工程系统”层面——不再纠结单个 prompt,转而优化整个 Agent 系统。

转变 2:从”产品 demo”到”工程体系”

过去一年,很多 Agent 项目停留在 demo 阶段,出不了工程化。Harness 提供了一套从 demo 到生产的完整工程体系——AGENTS.md + Linter + 评估 + 可观测性 + 自动清理。

转变 3:从”单 Agent”到”系统化 Agent”

未来 1-2 年,Agent 不会消失,但”裸跑的 Agent”会越来越少。所有的 Agent 都会跑在 Harness 化的系统里,这跟”现代软件不能没有版本控制”是同样的逻辑。

转变 4:从”工程能力”到”产品能力”

Harness 让 Agent 工程的边界从”工程能力”扩展到”产品能力”——谁能搭出好的 Harness,谁就能在 AI 时代快速把想法变成产品。

九、下一步

学完这篇,你的 Harness 知识已经从概念到实践有了完整体系。接下来的几个方向:

方向 1:给自己的 Agent 项目加 Harness

从 P0 开始:写 AGENTS.md + 加 Linter 约束。预计 1 周能完成 P0,质量会立刻有提升。

方向 2:搭企业级 Agent 平台

如果你所在的企业想统一管理 Agent,可以搭一个 Agent 平台,提供:

Agent 模板库
工具管理(MCP Server 集成)
评估系统
可观测性
权限管理

这是个 3-6 个月的项目,但回报很大。

方向 3:基于 LangGraph 搭自定义 Harness

LangGraph 提供了 Agent 编排能力,你可以基于它搭一套”自家版 Harness”,针对你的业务做定制优化。这个方向适合资深工程师。

方向 4:成为 Harness 工程师

未来 1-2 年,最稀缺的不是”会用 Agent 的人”,而是”能搭 Harness 的人”。这个角色的核心能力:

系统设计能力
工具链整合能力
评估与可观测性能力
AI 思维 + 工程思维

如果你有兴趣转型,这是 2026 年最有前景的方向之一。