开启Harness Engineering探索之旅¶

Ch05.067 开启Harness Engineering探索之旅¶

📊 Level ⭐⭐ | 9.4KB | entities/harness-engineering-exploration-tencent-tech.md

开启Harness Engineering探索之旅¶

Source：腾讯技术工程，发布于 2026-06-29。本文是对腾讯技术工程关于 Harness Engineering 实践的系统整理。

核心洞察¶

腾讯技术工程团队对 Harness Engineering 的实践探索，涵盖 Agent = Model + Harness 的核心架构定义、研发全链路的轨道设计（需求澄清→方案→实现→测试→部署→归档）、协议层/执行层/反馈层的三层设计，以及状态机与质量门禁的工程实践。

详细内容¶

开启Harness Engineering探索之旅¶

作者：fanniemeng

过去两年，AI Coding 从"能写出能跑的代码"走到"能放手让它写一整段功能"。但把这个能力放进真实业务、放进多人协作、放进存量系统里跑时我们发现一件怪事——AI 写得越快，整体节奏并没有同步加快。盘点下来，单看"AI 写出来的代码占比"这个数字一路走高，可真正落到版本节奏上，提效却远没有这个数字好看。出码率和提效之间，裂开了一道缝。从 OpenAI Codex 团队那篇 Harness 工程博客里反复强调的一个观察——"早期进展比预期慢，并不是因为 Codex 不具备相应的能力，而是因为环境的规范不够明确"——开始，整个行业都在补同一件事：给模型搭一套能稳定干活的"工作环境"。这一层最近被业界命名为 Harness Engineering——它不是教模型怎么回答，而是设计模型怎么工作。在这里，也分享下我们的探索之旅，是踩过的坑、做过的取舍、和到现在还没解决的问题。

关键特征¶

来源为腾讯技术工程的技术实践分享
涵盖 Harness Engineering / Agent 框架的设计与工程落地
包含实际代码架构与工程经验沉淀

深度分析¶

Harness Engineering 的概念结晶过程¶

腾讯技术工程团队的文章系统梳理了 Harness Engineering 概念从实践到命名的结晶过程：2025 年 8 月起 Open AI Codex 团队验证环境设计决定 Agent 稳定性 → 2026 年 2 月 Mitchell Hashimoto 定义「发现 Agent 犯错后用工程手段让它不再犯同类错误」→ LangChain 明确 Agent = Model + Harness 边界 → Böckeler / Thoughtworks 拆解为 guides 与 sensors → 学界开始用 ETCLOVG 七层分类做系统化梳理。

这一概念线的核心转变是：工程关注点从「模型这一句说得对不对」挪到了「模型这一整段活干得稳不稳」。Prompt Engineering（2022-2024）关心单次调用质量，Context Engineering（2025）关心每一步的信息供给，Harness Engineering（2026）关心整个任务周期的工程化框架。三层不是替代关系而是层层叠加——Harness 时代到来意味着前两层已经基本成熟。

腾讯的「出码率与提效裂开一道缝」洞察¶

腾讯团队的核心发现是：单看 AI 写出来的代码占比一路走高，但版本节奏的提效远没有这个数字好看。他们分析出三个根因：

研发本质从来不是「写代码」这一个环节。Brooks 在《人月神话》中将软件难题拆分为附属复杂度（语法、工具、平台）和本质复杂度（概念结构的构造）。AI 砍掉的是附属那一层，本质复杂度一分没少——甚至因为代码产出更多，下游的对齐、review、维护反而更重了。
局部加速只会让瓶颈转移。把「写」这一环踩到十倍速，理解、对齐、验证、沉淀这些环节一步没动——整条链的总时长由没被加速的部分决定。
AI 看不见工程体系里的隐性约束。团队规范、领域知识、历史依赖等没有被显式喂给 AI 的东西，AI 一概看不见。

这三个根因直接定义了腾讯的 Harness 设计目标：为 AI 搭建可执行、可约束、可验证、可反馈的工程环境。

两轨道 + 长期记忆的系统架构¶

腾讯的实践方案拆解为 2 条轨道 + 1 个长期记忆：

轨道 1：研发端到端交付（SpecWorker）——将「需求→上线」标准化为 6+1 阶段（P0 brainstorming → P1 需求 → P2 设计 → P3 实现 → P4 测试 → P5 部署 → P6 归档），每个阶段有明确的契约模板、SubAgent 分工和质量门禁。

架构分三层： - 协议层：定义 AI 每一步的输入输出契约——格式必须标准化、内容可校验、历史可追溯 - 管线层：标准化整条链路工序，确保长链过程中不丢失上下文、证据和纪律 - 纪律层：硬编码质量门禁——TDD 先写测试再写代码、Debug 先做根因分析、Verify 必须提供运行证据、Review 逐项比对契约、Evaluate 用独立 SubAgent 评分（总分 ≥ 95 才可通过）

轨道 2：线上运营——代码上线后的告警响应闭环：告警触发 → 清洗合并 → 采集证据 → 根因分析 → AI/人工修复 → 回归验证 → 归档回写。与轨道 1 共享同一套知识库、trace-id 检索 SOP 和评分门槛。

长期记忆（知识库）：项目级 specs/（产品长期资产）与变更级 knowledge-spec/（每次需求的增量沉淀）两套并存，通过 5 类目录分层（business/ → frontend/ + backend/ → common/ → changes/）实现依赖严格单向向下，确保模型检索时「先定位到目录，再定位到篇」。

关于 AI 不确定性的系统治理¶

文章中反复出现的一个核心判断是：AI Coding 的工程化，本质是对「不确定性」的系统治理。模型本身是概率的、注意力是衰减的、上下文是会被压缩的、输出是会自动合理化的——这些不是 bug，是 LLM 的「物理常数」。Harness Engineering 之所以成立，是因为承认这些常数无法消除，只能在它周围搭一套确定性的骨架兜住它。

具体的治理手段包括：Fixed Flow 编排（替代 AI 自由发挥）、程序化门禁检查（不依赖 AI 自我判断）、对抗式纪律（独立评估 + 行为铁律）、状态持久化（共享文件而非 Agent 间传递上下文）以及上下文控制（按需读取 + 新会话独立执行）。

关键的工程教训与未尽问题¶

文章坦率地列出了六个尚未解决的问题：评分机制与下游真实消耗的耦合尚未打通、知识库的自动治理（老化与淘汰）还在演进、运营轨道的告警闭环还在补全、多模型评估与跨项目知识迁移尚待研究、历史业务复杂的旧项目适配难、AI 测试的可靠性（覆盖不足/断言偏弱）仍需持续探索。

实践启示¶

出码率不等于提效：AI 写代码的速度再快，也只是整个研发链条中的一环。真正的瓶颈在于理解、对齐、追溯、沉淀、验证这些非编码环节。在引入 AI Coding 时，应优先评估瓶颈环节而非出码率。
Harness 不是理论先行而是踩坑反哺：腾讯的经验表明，这套体系的纪律点、评分门槛全部是 AI 在真实工程里翻车一次、留下一道防线。团队应建立「AI 事故 → 工程加固」的闭环机制，而非试图从零设计完美框架。
SubAgent 并非节省上下文的银弹：SubAgent 的上下文是独立计费的，看似把负担甩出去，实际是另起了一份账。关键优化是「优先读 git diff + 关键片段」，仅在 diff 过大或上下文不足时才读全文件。
纪律层必须硬编码而非建议：AI 有天然的偷懒倾向——跳过测试、猜修复方案、没验证就说已完成。针对每一种偷懒模式设计对应的纪律防线（TDD / Debug / Verify / Review / Evaluate），且必须是硬编码的门禁而非软建议。
知识库是复利的基础设施：没有知识库，每次需求 AI 都要从零理解上下文。关键设计原则包括：依赖单向向下、两级查找（index.md → spec）、单点事实来源（概念只在 glossary 定义一次）、原位增量更新而非全量复制。

原文存档¶

→ 原文存档

开启Harness Engineering探索之旅¶

Ch05.067 开启Harness Engineering探索之旅¶

开启Harness Engineering探索之旅¶

核心洞察¶

详细内容¶

开启Harness Engineering探索之旅¶

关键特征¶

深度分析¶

Harness Engineering 的概念结晶过程¶

腾讯的「出码率与提效裂开一道缝」洞察¶

两轨道 + 长期记忆的系统架构¶

关于 AI 不确定性的系统治理¶

关键的工程教训与未尽问题¶

实践启示¶

相关实体¶

原文存档¶