【笔记】Harness Engineering（驾驭工程）
内容提要
Harness Engineering是2026年AI智能体参与软件生产后的工程方法，核心是设计环境、约束、验证和反馈系统，让智能体稳定可控地完成任务。它强调从写代码转向设计生产系统，优先建设自动验证层，将失败沉淀为规则和测试，并产品化最佳实践。相比Prompt和Context Engineering，它关注系统级长期稳定性，是AI编码时代软件工程的重心迁移。
延伸解读
从“写代码”到“设计生产系统”
文章指出，当AI智能体参与生产后，工程师的核心工作不再是逐行编写代码，而是设计环境、约束、验证和反馈系统。这意味着角色从“实现者”转变为“系统设计者”，需要定义目标、边界和验收标准，并通过工具链让智能体执行。这种转变要求工程师具备更全面的系统思维，而不仅仅是编码能力。
验证比生成更重要
文章强调，Harness Engineering的第一性原则是“更好验证”而非“更聪明”。当AI生成速度超过人工审查速度时，必须将主观判断转化为客观的pass/fail，并压缩验证成本。因此，测试、lint、策略校验等传统工程能力变得更为关键。这提醒团队，在引入AI编码时，应优先投资自动化验证层，以确保产出可靠。
失败是复利资产
文章提出，智能体犯错不应被视为一次性事件，而应转化为规则、测试或文档等可复用资产。这种“错误模式→规则/工具/测试→永久收益”的复利工程，能系统性减少同类错误。团队应建立机制，将每次失败沉淀为系统改进，从而持续提升智能体的稳定性。
警惕反模式：文档过厚与权限过大
文章列举了常见反模式，包括文档越写越厚导致信息腐烂、人工review作为主防线、工具权限过大带来安全风险、缺乏垃圾回收导致仓库熵增，以及将问题简单归因于模型。这些风险提示团队在落地Harness Engineering时，需保持文档精简、权限最小化，并建立持续清理机制。
Q&A
什么是 Harness Engineering？
Harness Engineering 是当 AI 智能体参与真实软件生产后，工程师不再主要亲手写代码，而是设计一整套环境、约束、验证和反馈系统，让智能体稳定可控地完成任务。它强调从写代码转向设计生产系统，优先建设自动验证层，将失败沉淀为规则和测试，并产品化最佳实践。
为什么 Harness Engineering 在 2026 年突然变热？
因为 AI 生成代码的速度已经明显快过人类逐行审查和验证代码的速度，软件工程的主要瓶颈从“写得慢”变成了“不能快速信任产出”。团队需要解决如何让智能体拿到正确上下文、限制权限、自动验证结果、快速纠偏以及工程化消灭同类错误等问题，这些问题的总和就是 Harness Engineering。
Harness Engineering 与 Prompt Engineering、Context Engineering 有什么区别？
Prompt Engineering 关注提示词本身，优化单次交互；Context Engineering 关注给模型看的内容，优化当前任务的输入组织；Harness Engineering 关注系统级控制与反馈闭环，负责整个系统的长期稳定性、质量和治理。三者是递进关系。
一个完整的 Harness 通常包含哪些组成部分？
一个完整的 Harness 通常包含：上下文与知识系统（如 AGENTS.md、结构化 docs）、工具与运行环境（文件读写、Shell、测试等）、护栏与约束系统（依赖方向检查、自定义 lint、Policy-as-Code 等）、验证与反馈闭环（单元测试、集成测试、静态分析等）、可观测性与评估（trace、日志、指标）。
为什么 AGENTS.md 很重要，但不能变成“大部头手册”？
AGENTS.md 很重要，因为它提供入口级说明，但巨大的、包打天下的说明文件通常会失败，因为上下文窗口有限、信息容易腐烂、智能体无法判断过期内容、大量规则混在一起可执行性差。更好的做法是用 AGENTS.md 作为地图，用拆分良好的 docs/ 作为知识主体，并用 lint、CI 或定期维护机制检查文档有效性。
Harness Engineering 和传统软件工程是什么关系？
Harness Engineering 不是对传统软件工程的替代，而是重心迁移。它把 DevOps、SRE、Platform Engineering、测试工程和安全工程的原则重新放到智能体参与生产的新背景下组织，继承自动化、可重复性、可验证性、可追踪性、最小权限和持续改进等经典原则，但过去这些机制主要为人服务，现在必须同时为智能体服务。
团队如何落地 Harness Engineering？
落地步骤包括：先做最小闭环，让 1 到 2 个仓库具备最小可用 harness；优先建设自动验证层，如单测、集成测试、自定义 lint、架构边界检查等；把失败模式沉淀成资产，如新规则、测试、脚本；把可观测性开放给智能体，让它能观察日志、指标、trace；最终把最佳实践产品化，形成标准仓库模板、CI 流水线、规则集等 golden path。
Harness Engineering 有哪些常见反模式和风险？
常见反模式包括：把文档越写越厚而没有结构和校验；继续把人工 review 当成主防线；工具权限过大，缺乏隔离与审批；只有生成没有垃圾回收，导致仓库熵增；把问题都归因于模型，而忽略上下文不完整、工具接口差、验证信号慢、规则没机械化、失败信息不清晰等。
