为什么 Harness?

"在 2026 年，大模型的智力是公共品，Harness 才是护城河。"

一、引言：为什么是 Harness？

2026 年的软件工程正在经历一场不可逆的范式转移。这场转移的核心不在于模型变得更聪明——GPT-5.1、Claude Opus 4.6、Gemini 2.5 的智力已经是公共品——而在于谁能为 AI Agent 构建最严密的"物理法则"，让它在百万行代码库中不发疯、不遗忘、不破坏。

这套"物理法则"有一个精确的工程术语：Harness Engineering（脚手架工程 / 工程化治理）。

"Harness" 这个词的原意是"马具/挽具"——不是马本身，也不是骑手的技术，而是套在马身上、让马的力量可控且有方向的物理装置。这个隐喻精准地描述了我们与大模型之间的关系：模型是那匹力量无穷的马，而工程师的工作，是设计让这匹马跑得快、跑得准、不翻车的挽具系统。

本文将从概念溯源、理论框架、工业级实证、五层解剖、安全治理、多 Agent 协作等维度，全面解析 Harness Engineering 在 2026 年的最新范式。

二、概念溯源：从 Prompt Engineering 到 Harness Engineering 的三阶段演进

AI 工程的发展并非简单的替代，而是层层递进的嵌套关系。理解 Harness Engineering 的定位，必须先理解它在范式演进光谱上的坐标。

2.1 第一阶段：Prompt Engineering（提示词工程）

核心关注："怎么说"。 通过角色扮演、思维链（Chain of Thought）、Few-Shot 等技巧优化单次对话质量。这是 2023-2024 年的主流范式。

局限性： 存在根本性天花板——不稳定、不可扩展、缺乏记忆和系统观。换个场景，精心调优的 Prompt 可能就失效了。正如 Gartner 在 2025 年 10 月的报告中所述："提示工程正逐渐淡出并被工具和模板所取代，企业面临更深层的问题：如何赋予 AI 正确的情境感知能力。"¹

2.2 第二阶段：Context Engineering（上下文工程）

核心关注："给什么信息"。 通过 RAG（检索增强生成）、历史对话管理、工具调用（Tool Use）、MCP（Model Context Protocol）等，动态组装信息，让 AI 获取当前任务所需的知识。

Gartner 将其定义为：

设计和构建相关的数据、工作流和环境，使 AI 系统能够理解意图、做出更好的决策，并交付符合企业情境的预期结果——而无需依赖手动提示。¹

局限性： 虽然解决了"知道什么"，但无法阻止 AI "做不该做的事"。Agent 缺乏约束，容易在执行中走偏、过度操作。上下文工程解决了信息供给，但没有解决行为控制。

2.3 第三阶段：Harness Engineering（脚手架工程）

核心关注："在什么环境下做事"。 不再局限于语言或知识，而是构建一个包含约束、反馈、可观测性和反熵机制的完整运行时系统。这是 2026 年最高的演进层次。

这个术语在 2025 年底由 HashiCorp 创始人 Mitchell Hashimoto 率先提出（"Engineer the harness, not the model"），随后被 OpenAI Codex 团队在 2026 年 2 月 11 日发布的技术博客 "Harness engineering: leveraging Codex in an agent-first world" 中正式系统化[^{2]。Thoughtworks 的 Distinguished Engineer Birgitta Böckeler 随即在 Martin Fowler 网站上发表了深度分析，将其归纳为三大支柱：上下文工程、架构约束和反熵垃圾回收[}3]。

三者的关系是嵌套而非替代：Harness Engineering 包含 Context Engineering，Context Engineering 包含 Prompt Engineering。真正的高手不是在某一层做到极致，而是在三层之间游刃有余。

三、理论框架：Birgitta Böckeler 的三大支柱

Thoughtworks Distinguished Engineer Birgitta Böckeler 在 2026 年 2 月 17 日于 Martin Fowler 网站上发表的深度分析²，将 OpenAI 的实践归纳为三个混合了确定性方法（传统编程）和 LLM 方法（大模型）的支柱。这是目前业界对 Harness Engineering 最权威、最系统的理论框架。

支柱一：上下文工程（Context Engineering）

这不是简单的"写个好 Prompt"，而是构建一个持续增强的知识基础设施。核心洞察是：代码设计本身就是最重要的上下文。

上下文工程的目标是确保 AI Agent 在决策时拥有最全面、最新的情境信息。它包含两个维度：

静态上下文——项目的不变法则（技术栈约束、架构分层规则、命名规范等），锁定在 Context Window 顶部以命中 Prompt Cache。

动态上下文——当前任务的进度、运行态信号（日志、指标、浏览器截屏、DOM 快照等），按需注入。

把所有东西塞进一个文件（2025 年的常见做法）会导致严重的"Token 肥大症"和缓存失效。

支柱二：架构约束（Architectural Constraints）

这是 Harness 最"硬核"的部分。通过双重监控机制来强制执行架构规则：

LLM 智能体监控——利用 AI 检查代码是否符合架构意图。

确定性自定义 Linter——编写传统的、规则明确的代码检查工具（不依赖概率模型）。

结构性测试——使用如 ArchUnit 等框架，测试代码的架构结构（模块依赖、分层规则）。

Böckeler 指出，为了获得可信赖的、大规模的 AI 生成代码，必须牺牲"生成任何东西"的灵活性，将解决方案空间收缩到特定的架构模式内。未来可能会出现专门为了易于被 AI 维护而设计的代码库结构——"AI 友好的拓扑结构"。

支柱三：反熵垃圾回收（Anti-Entropy Garbage Collection）

AI Agent 有一个致命弱点：它会复制代码库中已有的模式，包括坏模式。一个不优雅的写法如果在代码库中出现过，Agent 就会不断复制它，导致代码腐化加速。

Böckeler 将第三大支柱定义为"对抗熵增"——通过自动化机制持续修复文档不一致和架构违规，防止代码库随时间推移而腐化。这就像编程语言中的垃圾回收（GC）：技术债务像高息贷款，小额持续偿还比痛苦地一次性解决要好。

Phodal 的 Fitness Function 体系

Phodal 在 2026 年 3 月的实践中进一步将架构约束具体化为 Fitness Function（适应度函数）体系³——这不是传统的架构质量检查，而是控制 Agent Loop 退出条件的核心机制。

核心问题： 在 Agent Loop 中，Agent 只能理解局部信号（命令成功、无报错），但无法判断系统层面的"真正完成"。功能路径可以跑通，但负向路径没有覆盖；接口已经修改，但契约没有同步；测试数量增加了，但关键不变量并没有被验证。

Fitness Function 的解法：

规则即代码——Fitness 规则以 Markdown Frontmatter 编写，存放在 docs/fitness/*.md，兼顾人机可读。示例如下：

---
dimension: testability
weight: 14
threshold:
  pass: 80
  warn: 70
metrics:
  - name: ts_test_pass
    command: npm run test:run 2>&1
    pattern: "Tests\\s+(\\d+)\\s+passed"
    hard_gate: true
  - name: rust_test_pass
    command: cargo test --workspace 2>&1
    pattern: "test result: ok"
    hard_gate: true
---

统一执行器——fitness.py 扫描规则文件，解析配置，运行命令，根据输出模式判断通过/失败。收回了规则的解释权，消除了"偶发问题"或"临时忽略"的模糊空间。

证据文件——记录验证状态（VERIFIED / TODO / BLOCKED），覆盖场景（CRUD 闭环、边界条件等），充当"工程账本"。

硬门禁——与评分体系不同，Hard Gate 失败会直接阻断流程。这是 AI 时代的 Definition of Done，明确区分"质量折损"和"流程终止"，防止 Agent 将"还不错"误解为"可以结束"。

防 API 语义漂移——在多后端系统（如 Next.js + Rust/Axum）中，Agent 容易导致各实现间失去同构关系。解决方案是将 OpenAPI 文件作为单一事实来源，所有实现必须围绕同一组 endpoint 收敛，通过 api_parity_check 进行契约一致性校验。

反熵垃圾回收的工程实现

为什么需要反熵？

软件开发中自然倾向于混乱（熵增）。AI Agent 的参与非但没有缓解，反而加速了这一过程：Agent 会复现代码仓库中已存在的模式，包括那些不均衡或不理想的模式。一个"还凑合"的写法如果在代码库中出现过，Agent 就会不断复制它，形成"AI 生成残渣"。

OpenAI 团队的早期做法是每周五（占 20% 时间）手动清理这些残渣，但很快发现这无法扩展⁴。

黄金原则的编码化

OpenAI 的解决方案是将带有主观意见的机械规则编码到仓库中，形成"黄金原则"：

• 倾向于使用共享实用程序包而非手写辅助工具。
• 禁止"YOLO 式"数据探测，必须验证边界或使用类型化 SDK。
• 所有结构性重复必须收敛为抽象。

然后设置后台 Codex 任务定期自动运行：扫描偏差、更新质量等级、发起有针对性的重构 PR。大多数清理 PR 可以在一分钟内完成审查并自动合并。

Böckeler 将其总结为一个精妙的类比²：

这就像编程语言中的垃圾回收（GC）。你不需要手动管理内存，但你需要设计一套自动化的回收机制来防止泄漏。在 AI 时代，"泄漏"的不是内存，而是架构意图和代码品味。

文档维护的自动化

OpenAI 的知识库不是一次性写完就束之高阁的。他们使用 CI 和 Linter 检查文档新鲜度，定期运行"doc-gardening"Agent 自动扫描并修复过时或废弃的文档。这种机制确保了代码库的"记录系统"——所有隐性知识的显性化存储——始终保持准确和可导航。

对未来的六个判断

基于以上全部分析，我对 Harness Engineering 的未来做出以下判断：

判断一：技术栈将收敛

Böckeler 预测 AI 会推动行业向数量更少的技术栈和拓扑结构收敛²。选择技术的标准将不再仅仅是开发者偏好，而是框架的"AI 友好程度"以及是否有成熟的 Harness 可用。未来可能会出现针对常见应用拓扑的"Harness 模板"（类比今天的 Golden Path 服务模板），成为新项目的起点。

判断二：工程师角色不可逆转型

从"出租车司机"（关注怎么走这条路）转变为"城市规划师"（关注怎么把路修好）。核心工作的三要素变为：拆解目标、构建脚手架、建立反馈回路。OpenAI 的实践表明，AI 的自主度不是自然涌现的，而是工程师通过设计特定的结构和工具一点点"解锁"出来的。

判断三：严谨性重定位

工程的严谨性将从人工代码审查转移到环境设计、控制系统构建和自动化护栏编写上。纠错成本低于等待成本——这是 Harness 哲学的底层经济学原理。

判断四：新旧世界的鸿沟

对于从头构建的"后 AI 应用"，Harness 体系效果最好。对于遗留代码（旧应用），尝试"改造"一套 Harness 可能并不划算——旧的代码库往往充满了非标准化和混乱，就像在一个从未运行过静态分析工具的项目上突然开启它一样，会被警报淹没。

判断五："学徒缺口"将成为行业隐忧

如果初级工程师跳过手动开发直接用 AI 生成代码，虽然短期内效率高，但长期看会丧失建立架构直觉和判断代码质量的能力。没有踩过坑的人，无法设计出管住 AI 的环境。 Harness 的设计者必须是有深厚技术功底的资深工程师，这可能在未来几年形成人才断层。

判断六：Harness 即护城河

Sam Altman 预言过"一个人的十亿美元公司"。在 Harness Engineering 的视角下，这个预言的前提条件变得清晰了：那个"一个人"不是一个更快的代码工人，而是一个能设计出工业级 Harness 系统的能力架构师——一个能让 16 个 Agent 并行运转两周而不崩溃的系统设计者。

一句话总结

Harness Engineering 的本质，是用确定性约束驯服概率性智能。 它不信任 Prompt 的祈祷，只信任 Lint 的阻断；不依赖模型的"常识"，只依赖架构的物理定律。在 2026 年，大模型本身的智力已经不是壁垒——谁能为 Agent 构建最严密的马具系统，谁就掌握了 Agentic Engineering 的制高点。

参考文献