"历史不会重复，但总是押韵。" —— 马克·吐温
引言：失控的秩序
1764 年，英国兰开夏郡的木匠詹姆斯·哈格里夫斯发明了珍妮纺纱机。这台看似简单的机器——一个人可以同时操作 8 根纱锭，而不是传统纺车的 1 根——并没有立即改变世界。真正改变世界的，是它引发的组织混乱。
家庭作坊无法容纳越来越大的机器，工匠们发现自己的技艺突然贬值，雇主们不知道如何管理几十台同时运转的机器，工人们不知道该如何适应新的劳动节奏。技术带来了产能的飞跃，但也带来了前所未有的失控。
260 年后的 2024 年，AI 领域正在经历相似的时刻。
大语言模型（LLM）的能力每隔几个月就翻一番，prompt 工程师们像当年的纺纱工匠一样，凭借个人技艺让 AI "听话"。但当企业试图将 AI 应用规模化时，他们发现：prompt 技巧无法复制，上下文管理一团糟，AI 输出质量飘忽不定，成本失控，错误难以追溯。
技术的进步再次超越了组织的承载能力。
这就是为什么 2026 年 2 月，当 Mitchell Hashimoto、Martin Fowler、OpenAI 的工程师们几乎同时提出 "harness engineering"（驾驭工程 / 挽具工程）这个概念时，它迅速在 AI 社区引发共鸣。因为这个概念回答了一个迫切的问题：
如何让 AI 从"个人魔法"变成"工业化生产"？
这不是第一次人类面对这个问题。珍妮纺纱机催生了工厂制度，软件危机催生了软件工程。每一次，答案都不是更好的工具，而是重建秩序的方式。
第一幕：1870 年的伯明翰 vs. 2024 年的硅谷
镜像一：产能过剩后的困惑
1870 年，英国伯明翰
纺织厂老板约翰·布莱特站在车间里，看着 50 台珍妮纺纱机同时运转。产量是 10 年前的 20 倍，但利润却没有相应增长。问题出在哪里？
- 机器经常闲置，因为没人知道如何协调原料供应
- 工人们各自为政，有人拼命干活，有人偷懒摸鱼
- 产品质量参差不齐，客户投诉不断
- 每次机器故障，整条生产线都要停摆
布莱特意识到：机器不是问题，如何让机器持续为我工作才是问题。
他开始尝试： - 引入轮班制，让机器 24 小时运转 - 设立监工，监督工人的劳动纪律 - 制定标准操作流程，每个工序都有明确规范 - 建立质检环节，不合格产品不出厂
这些创新后来有了一个名字：工厂管理制度。
2024 年，美国硅谷
AI 创业公司 Acme 的 CTO Sarah 盯着监控面板，看着 GPT-4 的 API 调用量飙升。模型能力是一年前的 10 倍，但产品质量却没有相应提升。问题出在哪里？
- AI 经常"幻觉"，生成错误信息却无法追溯
- 不同工程师写的 prompt 风格迥异，效果飘忽不定
- 上下文管理混乱，AI 有时看到太多信息，有时又看不到关键信息
- 每次模型更新，整个应用都要重新调试
Sarah 意识到：模型不是问题，如何让模型持续为业务服务才是问题。
她开始尝试： - 引入循环机制（Loop），让 AI 持续观察-决策-行动-验证 - 设立验证层（Verification），AI 输出必须通过质量门禁 - 制定上下文策略（Context Management），控制 AI 接收什么信息 - 建立约束系统（Constraints），限制成本、超时、权限
这些创新后来有了一个名字：Harness 工程。
镜像的启示
两个时代，相同的困境：
| 困境 | 1870 年工厂 | 2024 年 AI 应用 |
|---|---|---|
| 核心问题 | 如何让机器持续工作？ | 如何让 AI 持续服务？ |
| 表面症状 | 产能高但利润低 | 能力强但质量差 |
| 根本原因 | 缺乏组织协调机制 | 缺乏工程化框架 |
| 解决方案 | 工厂管理制度 | Harness 工程 |
历史告诉我们：技术工具的引入，必然要求相应的组织创新。忽视这一点，技术效益将无法实现。
第二幕：软件工程的本质——驾驭复杂性
镜像二：1968 年的焦油坑
1968 年，德国加米施
NATO 软件工程会议上，50 位计算机科学家面面相觑。IBM OS/360 项目的惨败让所有人意识到：软件开发已经失控了。
Fred Brooks 后来在《人月神话》中这样描述：
"大型系统编程在过去十年中一直是一个焦油坑，许多强大的野兽在其中剧烈挣扎……但同时发生和相互作用的因素积累，带来越来越慢的运动。"
OS/360 项目的数据触目惊心： - 投入 5000 人年，耗资 5 亿美元（相当于曼哈顿计划的 1/4） - 进度一再延迟，质量低下，维护成本飙升 - 程序员各自为政，代码像"意大利面条"一样混乱 - 没人能理解整个系统，修改一处就引发连锁崩溃
会议上首次提出了"软件工程"这个概念。但更重要的是，Brooks 在随后的思考中揭示了一个深刻洞察：
"软件的复杂性是本质属性，而非偶然属性。"
没有银弹：本质复杂性无法消除
1986 年，Brooks 发表了著名论文《没有银弹》，区分了两种复杂性：
本质复杂性（Essential Complexity）： - 软件必须解决的内在难题 - 理解要构建什么、为什么构建 - 在相互冲突的需求之间做权衡 - 这是无法消除的
偶然复杂性（Accidental Complexity）： - 由于工具、流程不当造成的混乱 - 编译错误、部署困难、环境配置 - 这是可以消除的
Brooks 的核心论断：
"不存在任何技术或管理手段，能够在十年内将软件生产力提高一个数量级。"
这意味着什么？
意味着无论工具多么强大——从汇编到高级语言，从瀑布到敏捷，从人工到 AI——本质复杂性永远存在。工程的任务不是消除复杂性，而是驾驭复杂性。
这正是 harness 工程的核心理念。
概念完整性：约束的首要性
Brooks 将"概念完整性"置于系统设计的最高位置：
"我认为概念完整性是系统设计中最重要的考虑因素。一个系统省略某些异常功能和特性，但拥有清晰一致的概念，要好于拥有许多好的但相互独立、不协调的想法。"
在 OS/360 项目中，Brooks 观察到： - 各团队优化自己的子系统，而非考虑整体用户体验 - 功能不断膨胀，但系统越来越难用 - 缺乏统一的概念框架，复杂性失控
这揭示了一个反直觉的洞察：好的设计不是添加功能，而是施加约束。
概念完整性 = 统一的约束框架。这与 harness 工程的"约束"组件完全对应。
软件工程即约束系统
让我们用控制论重新理解软件工程：
| 控制论组件 | 软件工程对应 | Harness 工程对应 |
|---|---|---|
| 控制器 | 架构设计 | Harness 架构 |
| 传感器 | 测试/监控 | Verification 层 |
| 比较器 | 断言/验收条件 | 质量门禁 |
| 执行器 | CI/CD 流水线 | 自动化部署 |
| 负反馈 | 回归测试 | 持续验证 |
三个反直觉洞察：
- 测试不是"发现 bug"，而是维持负反馈——防止系统偏离设计意图
- 架构不是"蓝图"，而是控制器的参数空间——决定系统对扰动的响应方式
- Bug 本质是"系统行为跨过了约束边界"——测试的作用是重新收紧边界
从 TDD 到 CI/CD：验证的自动化
Kent Beck 的 TDD：
"Clean code that works"（可工作的清洁代码）
TDD 的红-绿-重构循环：
Red（写失败的测试）→ Green（快速让测试通过）→ Refactor（消除重复）
关键洞察：测试先行本身就是一种设计活动。当你写测试时，你正在用代码形式描述系统应该如何行为——测试即规格说明。
Martin Fowler 的 CI：
"持续集成没有自测代码就无法工作。"
CI/CD 的本质不是"自动化部署"，而是持续验证——每次代码变更都触发验证，快速反馈正确性。
这与 harness 工程的"Loop"组件完全对应：观察 → 决策 → 行动 → 验证 → 更新。
软件架构：结构化约束
软件架构的本质不是"蓝图"，而是约束的集合。每个架构决策都是对某种约束的响应。
分层架构的约束机制：
┌─────────────────────────────────────┐
│ Presentation Layer │ ← UI 约束
├─────────────────────────────────────┤
│ Application Layer │ ← 工作流约束
├─────────────────────────────────────┤
│ Domain Layer │ ← 业务逻辑约束
├─────────────────────────────────────┤
│ Infrastructure Layer │ ← 技术依赖约束
└─────────────────────────────────────┘
每层只能访问下层，禁止跨层调用。这通过结构化约束控制复杂性。
质量属性 = 可验证的约束：
Bass 等人在《软件架构实践》中提出的质量属性场景（QAS）框架，本质是可验证的约束——不是模糊的"系统要快"，而是精确的"99% 请求在 2 秒内响应"。
软件工程的演进 = 约束的显式化
| 阶段 | 时间 | 核心问题 | 约束机制 | 本质 |
|---|---|---|---|---|
| 结构化编程 | 1970s | 控制流混乱 | 废除 goto，引入顺序/选择/循环 | 控制流约束 |
| 面向对象 | 1980s | 数据与行为分离 | 封装、继承、多态 | 访问约束 |
| 敏捷/TDD | 2000s | 需求变化快 | 测试先行、迭代反馈 | 行为约束 |
| DevOps | 2010s | 开发运维断裂 | CI/CD、基础设施即代码 | 流程约束 |
| Harness 工程 | 2020s | AI 不可控 | 完整的约束-验证-控制系统 | 系统约束 |
模式识别：每十年，软件工程都在把隐式约束变成显式约束，把个体约束变成系统约束。
顶尖大学如何教授"驾驭复杂性"
MIT 6.031 的核心哲学：
"如何编写安全无 bug、易于理解、易于修改的软件"
注意：不是"如何编写代码"，而是"如何编写安全、易懂、易改的软件"。
Stanford CS 190（John Ousterhout）：
"最重要的焦点是复杂性：我们如何构建尽可能简单、但仍然足够强大的系统？"
"将精英程序员与普通程序员区分开的，是设计清洁简单软件的非凡能力。"
MIT 6.170（Daniel Jackson）：
"编写代码不是构建软件的全部。事实上，它只是其中很小的一部分。我们需要比代码更好的方式来谈论软件。"
这些课程揭示了什么？
软件工程教育的核心不是"如何写代码"，而是如何设计约束系统——通过概念框架、模块边界、接口契约来驾驭复杂性。
2024 年的 AI 危机
2024 年，AI 社区
当 OpenAI 宣布他们用 AI 智能体自主生成了 100 万行代码时，整个行业震惊了。但更震惊的是他们透露的细节：
- 前 3 个月，AI 生成的代码有 60% 无法通过测试
- Prompt 工程师每天花 8 小时调试 prompt，效果仍然飘忽不定
- 上下文管理混乱，AI 经常"遗忘"关键信息
- 没有系统化的验证机制，错误难以追溯
OpenAI 的解决方案是：构建一套完整的 harness 系统。
他们的 harness 包含三大支柱： 1. Context Engineering：持续增强的知识库 + 动态上下文 2. Architectural Constraints：自定义 linter + 结构化测试 3. "Garbage Collection"：定期运行的智能体，清理文档不一致性
这与软件工程的实践完全对应：
| OpenAI Harness | 软件工程对应 |
|---|---|
| Context Engineering | 需求文档、设计文档 |
| Architectural Constraints | 架构模式、代码规范 |
| Garbage Collection | 技术债务清理、重构 |
结果：5 个月后，代码质量从 40% 提升到接近人类水平。
AI 工程的当前位置
如果把 AI 工程的发展对照软件工程的历史：
-
Prompt Engineering（2022-2023） ≈ 早期编程（1950s-1960s）
特征：依赖个人技巧，"艺术"多于"工程" -
Context Engineering（2024-2025） ≈ 结构化编程（1970s）
特征：开始系统化管理信息，但仍缺乏整体框架 -
Harness Engineering（2026+） ≈ 面向对象 + 敏捷（1980s-2000s）
特征：完整的工程化体系，可复制、可验证、可扩展
我们正处于 AI 工程的"1968 年"——从混沌走向秩序的临界点。
软件工程用了 60 年才形成完整的方法论体系。但 AI 工程有历史的镜鉴，演进可能会更快。核心规律不会变：复杂性无法消除，只能驾驭。
第三幕：什么是 Harness 工程？
定义：不只是工具，而是秩序
Martin Fowler 在 2026 年 2 月的文章中给出了这样的定义：
"Harness 工程是设计、构建和运营约束、验证和修正 AI 智能体的基础设施的学科。它包含模型之外的一切：上下文组装、工具编排、验证、成本控制和可观察性。"
用一个隐喻来理解：
- 模型 = 引擎（提供动力）
- Harness = 整车（底盘、变速箱、刹车、燃油系统）
没有人会直接使用一台裸露的引擎上路，但这正是当前大多数 AI 应用的状态——直接调用模型 API，缺乏系统化的"车身"。
三层概念的演进
Harness 工程不是凭空出现的，它是 AI 工程化的第三个阶段：
| 层级 | 核心问题 | 设计目标 | 范围 | 影响上限 |
|---|---|---|---|---|
| Prompt Engineering | "我该说什么？" | 优化指令文本 | 单次调用 | 5-15% 提升 |
| Context Engineering | "模型应该看到什么？" | 推理时的信息 | 单次上下文增强 | 20-40% 提升 |
| Harness Engineering | "整个环境如何设计？" | 约束-验证-控制系统 | 多步骤系统 | 50-300% 提升 |
层级包含关系：Prompt ⊂ Context ⊂ Harness
Harness 的六大核心组件
根据 AI 社区的实践总结，一个完整的 harness 系统包含六个层级：
| 层级 | 功能 | 类比 |
|---|---|---|
| 1. Loop（循环） | 观察 → 决策 → 行动 → 验证 → 更新 | 工厂的生产循环 |
| 2. Tools（工具） | 赋予 AI 超出对话的能力 | 工人的工具箱 |
| 3. Context（上下文） | 控制模型接收什么信息 | 工人的工作指令 |
| 4. Persistence（持久化） | 状态管理，跨会话保持信息 | 工厂的库存系统 |
| 5. Verification（验证） | 输出验证、质量门禁 | 质检环节 |
| 6. Constraints（约束） | Guardrails、成本控制、超时、权限 | 安全规范和预算控制 |
这六个层级共同构成了一个可控、可验证、可扩展的 AI 应用系统。
第四幕：为什么 Harness 比模型更重要？
证据一：OpenAI 的 100 万行代码实验
2026 年 2 月，OpenAI 公布了一个震撼性的实验结果：
- 时间：2025 年 8 月 - 2026 年 2 月（5 个月）
- 规模：100 万+ 行代码
- 零手写代码：每一行都由 Codex 智能体生成
- 速度：约人类开发时间的 1/10
- 产出：拥有真实用户的产品
"我们的成功不是因为模型更好，而是因为我们建立了一套让 AI 可靠工作的系统。" —— Ryan Lopopolo, OpenAI
证据二：LangChain 的 Harness 优化
2026 年初，LangChain 团队做了一个对照实验：
- 相同模型：GPT-4
- 唯一变量：Harness 设计
- 结果：52.8% → 66.5%（26% 绝对提升）
优化内容：精简工具集（15 个 → 2 个）、改进上下文管理、增强验证机制
证据三：Vercel 的工具精简实验
- 工具数量：从 15 个 → 2 个
- 准确率：从 80% → 100%
反直觉的洞察：更多工具 ≠ 更强能力。Harness 设计的核心是约束，而非赋能。
"两支使用相同模型的团队，任务完成率可以是 60% 对 98%，完全取决于 harness 质量。" —— Kai Renner
核心洞察：Harness > Model
这些证据指向一个颠覆性的结论：
在生产环境中，harness 的质量比模型的能力更重要。
| 维度 | 模型能力 | Harness 质量 |
|---|---|---|
| 影响范围 | 单次输出质量 | 系统整体可靠性 |
| 可控性 | 低（黑盒） | 高（可设计） |
| 改进成本 | 高（需要重新训练） | 低（调整架构） |
| 效果上限 | 受限于模型本身 | 可提升 2-5 倍 |
这就像工业革命的教训：珍妮纺纱机不是最重要的，工厂制度才是。
这就像软件工程的教训：编程语言不是最重要的，工程方法论才是。
第五幕：历史的回声——卢德运动与 AI 焦虑
1811 年的卢德运动
当珍妮纺纱机和动力织机开始普及时，英国纺织工人发起了一场激烈的抗议运动——卢德运动（Luddite Movement）。
历史书常常将他们描述为"反对技术进步的愚昧者"，但真相更复杂：
卢德分子的真实诉求： - 不是反对机器本身（他们中许多人是熟练工人） - 而是抗议雇主利用机器削减工资、降低工作条件、贬值技艺 - 他们批评机器生产的产品质量低劣 - 他们要求维护行业标准劳动实践
"卢德分子作为熟练的手工艺人，对自己的工作感到自豪，他们批评使用新技术生产的低质量商品。" —— Gavin Mueller, 阿姆斯特丹大学
2024 年的 AI 焦虑
今天，当 AI 开始"替代"程序员、设计师、作家时，我们看到了相似的焦虑：
- 不是反对 AI 本身
- 而是担心 AI 被用来降低职业标准、压低薪酬、贬值专业技能
- 批评 AI 生成内容的质量问题（幻觉、错误、缺乏创意）
- 呼吁建立 AI 使用的伦理规范
历史的教训
卢德运动最终失败了，但它留下了重要的教训：
技术变革不会自动惠及所有人。关键在于： 1. 利益分配机制：技术效率提升的收益如何分配？ 2. 技能转型支持：被替代的劳动者如何获得新技能？ 3. 质量标准维护：如何防止"劣币驱逐良币"？ 4. 话语权保障：劳动者在技术变革中有多少发言权？
Harness 工程的社会意义：
如果说 prompt 工程是"个人魔法"，那么 harness 工程就是"制度建设"。它不仅是技术框架，更是：
- 质量保障机制：通过验证层确保 AI 输出质量
- 可追溯性：明确责任归属，不让 AI 成为"甩锅"工具
- 成本控制：防止 AI 使用失控
- 伦理约束：通过 constraints 层实现价值观对齐
Harness 工程是 AI 时代的"劳动保护法"——它保护的不仅是企业利益，也是专业标准和职业尊严。
第六幕：工具-流程-组织的协同演化
历史规律：三位一体的变革
技术史学家发现，每一次重大技术革命都遵循相同的模式：
| 技术革命 | 核心工具 | 流程创新 | 组织形态 |
|---|---|---|---|
| 工业革命 | 珍妮纺纱机 + 蒸汽机 | 标准化流程、质检 | 工厂制度、监工体系 |
| 电气革命 | 电力 + 流水线 | 科学管理（泰勒制） | 大规模生产企业 |
| 信息革命 | 计算机 + 互联网 | 敏捷开发、DevOps | 扁平化组织、远程协作 |
| AI 革命 | LLM + Agent | Harness 工程 | ？（正在形成中） |
核心洞察：工具变革从不孤立发生，它必然伴随流程重构和组织创新。
AI 时代的组织变革
Harness 工程正在催生新的组织角色和分工：
新角色的出现： - Harness 架构师：设计 AI 应用的整体框架（类比：软件架构师） - Context 工程师：管理知识库和上下文策略（类比：数据工程师） - Verification 工程师：设计验证和测试机制（类比：QA 工程师） - AI Ops 工程师：监控、优化 AI 系统运行（类比：DevOps 工程师）
组织形态的变化： - 从"AI 团队"到"AI-Native 团队" - 从"集中式 AI 部门"到"分布式 AI 能力" - 从"模型调优"到"系统工程"
这不是简单的"增加一个岗位"，而是整个组织运作方式的重构。
第七幕：AI 工程的未来——基于历史规律的预测
我们正处于哪个历史时刻？
| 维度 | 工业革命（1760s-1840s） | 软件工程（1968-2000s） | AI 工程（2020s-？） |
|---|---|---|---|
| 触发事件 | 珍妮纺纱机 | 软件危机 | LLM 突破 |
| 核心问题 | 如何管理机器？ | 如何管理代码？ | 如何管理 AI？ |
| 早期特征 | 家庭作坊式生产 | 个人编程艺术 | Prompt 工程技巧 |
| 转折标志 | 工厂制度确立 | 软件工程学科诞生 | Harness 工程兴起 |
| 成熟标志 | 科学管理运动 | DevOps 普及 | ？（尚未到来） |
| 时间跨度 | 约 80 年 | 约 40 年 | ？（刚刚开始） |
我们的位置：2026 年的 AI 工程 ≈ 1968 年的软件工程 ≈ 1780 年的工业革命
未来 10 年的五个预测
基于工业革命和软件工程的演进规律，我们可以对 AI 工程的未来做出以下预测：
预测一：标准化浪潮（2026-2028）
就像 1970 年代的结构化编程运动，AI 工程将经历一场标准化浪潮：
- Harness 模式库：类似设计模式，出现标准化的 harness 架构模式
- 质量标准：行业组织制定 AI 应用的质量基准（类似 ISO 标准）
- 认证体系：Harness 架构师认证（类似软件架构师认证）
预测二：工具链整合（2028-2030）
就像 2000 年代的 IDE 整合，AI 工程工具将从碎片化走向整合：
- 统一 Harness 平台：集成 Context、Verification、Constraints 的一站式平台
- 可视化设计：拖拽式 harness 设计工具（类似低代码平台）
- 开源生态：类似 Kubernetes 的 harness 编排系统
预测三：教育体系成熟（2028-2032）
就像软件工程进入大学课程，AI 工程将成为独立学科：
- AI 工程学位：独立于计算机科学的 AI Engineering 专业
- 核心课程：Harness 设计、Context 工程、AI 系统架构
- 实践项目：真实 AI 应用的 harness 设计与实现
预测四：监管框架确立（2030-2035）
就像工业革命催生劳动法，AI 革命将催生 AI 治理框架：
- AI 应用审计：强制性的 harness 质量审计（类似财务审计）
- 责任归属：明确 AI 错误的责任链（通过 harness 的可追溯性）
- 伦理约束：法律强制的 constraints 层（类似 GDPR）
预测五：组织范式转变（2035+）
就像 DevOps 改变了软件组织，Harness 工程将重塑 AI 组织：
- AI-Native 企业：所有业务流程都由 AI + Harness 驱动
- 人机协作新模式：人类负责 harness 设计，AI 负责执行
- 分布式 AI 能力：每个团队都有自己的 harness 架构师
关键转折点：何时 AI 工程走向成熟？
参考软件工程的历史，从"软件危机"（1968）到 DevOps 普及（2010s）用了约 40 年。
AI 工程可能更快，因为： 1. 有软件工程的镜鉴，不需要从零摸索 2. 技术迭代速度更快 3. 全球协作更紧密
预计时间线： - 2026-2030：标准化和工具整合（类似 1970s-1980s） - 2030-2035：教育体系和监管框架（类似 1990s-2000s） - 2035-2040：组织范式转变和全面普及（类似 2010s）
标志性事件：当"Harness 架构师"成为主流职位，当大学普遍开设 AI 工程专业，当监管要求强制 harness 审计——那时，AI 工程才算真正成熟。
2026 年最新数据与实战案例
三大玩家的 Harness 架构对比
2026 年 Q1，OpenAI、Cursor、Anthropic 三家头部公司几乎同时公开了各自的 Harness 实践，但它们解决的是三个完全不同的 Scaling 维度：
| 维度 | 公司 | 核心方案 | 关键数据 |
|---|---|---|---|
| 交互 Scaling | OpenAI | Symphony + Linear 作为 Agent Job Scheduler | 三人团队 5 个月合并 ~1500 PR，平均每人每天 3.5 个 |
| 空间 Scaling | Cursor | 递归 Planner-Worker 架构，Worker 在独立 repo 副本工作 | 峰值 1000 commits/hour |
| 时间 Scaling | Anthropic | 独立 Evaluator + Playwright 验证运行中应用 | 解决 4 小时以上 agent 方向漂移问题 |
三家的高度共识：约束比指令有效。OpenAI 用自定义 linter 强制执行架构不变量，Cursor 发现"no TODOs, no partial implementations"比"remember to finish"有效得多。
企业级实践数据
- Stripe：使用 Claude Code + Minions 架构，每周生成 1,300+ PR
- LangChain：通过优化 Harness（精简工具集 15→2），SWE-bench 排名从 Top 30 升至 Top 5
- OpenClaw：单月 6,600+ commits，验证了本地 Agent + Harness 的规模化可行性
- ETH Zurich 研究：测试了 138 个 agentfiles，发现 LLM 生成的 agentfile 会损害性能，人工编写的仅带来约 4% 改进，但 Agent 消耗的推理 tokens 增加了 14-22%
实操：AGENTS.md 模板
以下是一个实际可用的 AGENTS.md 模板，基于 Mitchell Hashimoto 的 Ghostty 项目实践：
# 项目名称
## 架构概述
简要描述项目的模块结构和依赖关系。
## 代码规范
- 使用 [语言] 的标准格式化工具
- 变量命名采用 camelCase / snake_case
- 错误处理不允许空 catch 块
## 约束（关键）
- 禁止引入新的全局依赖，除非经过团队评审
- 所有 public 函数必须有文档注释
- 测试覆盖率不低于 80%
- 禁止使用 `as any` 或 `@ts-ignore`
## 工作流
1. 先读相关模块的测试文件，理解预期行为
2. 修改代码，运行测试
3. 确保 lint 通过
4. 提交 PR，描述变更原因和影响范围
## 已知问题
- [列出当前的技术债务和已知限制]
实操：自定义 Linter 作为约束
OpenAI 在 Symphony 项目中用自定义 linter 强制执行架构不变量。lint 错误信息本身就是给 agent 的修复指引：
# .lint/rules/no_cross_layer_import.py
"""禁止跨层调用：Service 层不能直接导入 Data 层"""
def check_cross_layer_import(tree, filename):
violations = []
if "/service/" in filename:
for node in tree.find({"type": "import_statement"}):
if "/data/" in node.import_path:
violations.append({
"message": (
f"Service 层禁止直接导入 Data 层。"
f"请通过 Repository 接口间接访问。"
f"参见：docs/architecture.md#layer-rules"
),
"line": node.line
})
return violations
关键洞察：错误信息不仅仅是"你做错了"，而是"你该怎么做"。这是 Harness 的设计哲学——约束即指引。
常见问题（FAQ）
什么是 Harness Engineering？
Harness Engineering 是设计和构建 AI Agent 运行环境的工程学科。它不关注模型本身（写更好的 prompt），而是关注模型之外的一切：上下文组装、工具编排、验证机制、成本控制和可观测性。类比：模型是引擎，Harness 是整车（底盘、变速箱、刹车、仪表盘）。
Harness Engineering 和 Prompt Engineering 有什么区别？
| 维度 | Prompt Engineering | Harness Engineering |
|---|---|---|
| 核心问题 | "我该对 AI 说什么？" | "AI 的整个运行环境怎么设计？" |
| 范围 | 单次调用 | 多步骤系统 |
| 效果上限 | 5-15% 提升 | 50-300% 提升 |
| 可复制性 | 低（依赖个人技巧） | 高（系统化框架） |
Prompt Engineering 是 Harness Engineering 的子集。好的 Harness 包含好的 Prompt，但不止于此。
哪些工具在使用 Harness Engineering？
2026 年主要践行者： - OpenAI Codex / Symphony：用 Linear 作为 Agent Job Scheduler - Cursor：递归 Planner-Worker 架构 - Claude Code：AGENTS.md + Hooks + Skills 三层体系 - OpenCode：多 Agent 编排 + Skill 系统 - Cline / Aider：终端 Agent，各有不同的 Harness 设计
如何开始实践 Harness Engineering？
- 写 AGENTS.md：给你的项目创建一个上下文文件，描述架构、规范、约束
- 建立验证循环：确保 agent 的每个输出都经过测试/类型检查
- 精简工具集：从 2-3 个精心设计的工具开始，而非 15 个泛化工具
- 设计约束而非指令：写"不要做什么"比"记得做什么"更有效
- 迭代 Harness：观察 agent 的失败模式，针对性加强约束
Harness Engineering 的"约束比指令有效"是什么意思？
与其告诉 AI"请写高质量的代码"，不如设置约束："所有函数必须有类型标注"、"测试覆盖率不低于 80%"、"lint 必须通过"。约束是可检查的、可自动化的、不会遗忘的。指令是模糊的、依赖记忆的、容易遗漏的。
这个原则与软件工程的历史一脉相承：TDD 的"测试先行"就是一种约束，CI/CD 的"合并前必须通过所有测试"也是一种约束。
结语：秩序的重建
回到文章开头的问题：如何让 AI 从"个人魔法"变成"工业化生产"？
历史给出了清晰的答案：
1. 承认混乱是必然的
珍妮纺纱机引发了 50 年的组织混乱，软件危机持续了 30 年，AI 的混乱期才刚刚开始。不要期待快速的解决方案。
2. 工具不是答案，秩序才是
更强的模型不会自动解决问题，就像更快的纺纱机不会自动创造工厂制度，更强的编程语言不会自动创造软件工程。我们需要的是系统化的工程框架。
3. 工程化是协同演化的过程
Harness 工程不仅是技术框架，它会催生新的角色、新的流程、新的组织形态。准备好迎接整个工作方式的重构。
4. 关注人的维度
卢德运动的教训提醒我们：技术变革必须考虑利益分配、技能转型、质量标准、话语权保障。Harness 工程不仅是效率工具，也是社会契约。
最后的隐喻
Harness 这个词在英语中有两个含义：
- 马具：驾驭马的力量，让其为人类工作
- 安全带：保护人类免受失控力量的伤害
这正是 harness 工程的双重使命：
- 驾驭 AI 的能力，让其可靠地为业务服务
- 约束 AI 的风险，防止其失控造成伤害
260 年前，珍妮纺纱机开启了工业革命，但真正改变世界的是工厂制度。
60 年前，软件危机催生了软件工程，但真正改变行业的是从结构化编程到 DevOps 的完整方法论。
今天，LLM 开启了 AI 革命，但真正改变未来的，将是 harness 工程。
历史不会重复，但总是押韵。
我们正站在新一轮组织革命的起点。这一次，我们有历史的镜鉴，有前人的教训，有更清晰的路径。
秩序的重建，从现在开始。
参考文献
Harness 工程核心文献
- Martin Fowler, "Harness Engineering", 2026-02-17
- Mitchell Hashimoto, "Harness Engineering for AI Agents", 2026-02-05
- OpenAI, "Harness engineering: leveraging Codex in an agent-first world", 2026-02-11
- AI Magicx, "Harness Engineering: Why the Way You Wrap AI Matters More Than Your Prompts in 2026", 2026-03-23
- Louis Bouchard, "Harness Engineering: The Missing Layer Behind AI Agents", 2026-03-24
- Epsilla, "Why Harness Engineering Replaced Prompting in 2026", 2026-03-25
- HumanLayer, "Skill Issue: Harness Engineering for Coding Agents", 2026-03-12
- Artificial Ignorance, "The Emerging Harness Engineering Playbook", 2026-02-22
- Charlie Guo, "The Engineer's Job Is Splitting In Two", Artificial Ignorance, 2026
2026 年最新研究
- ETH Zurich, "Agentfiles Study: 138 agentfiles tested", 2026
- OpenAI, "Symphony: Agent orchestration with Linear", 2026-03 (GitHub: openai/symphony)
- Stripe, "Minions: 1,300+ PRs per week with AI agents", 2026
- LangChain, "From Top 30 to Top 5 via tool simplification", 2026
- Cobus Greyling, "The Rise of AI Harness Engineering", Substack, 2026-03-12
软件工程经典著作
- Fred Brooks, 《人月神话》（The Mythical Man-Month, 1975）
- Fred Brooks, 《没有银弹》（No Silver Bullet, 1986）
- Kent Beck, 《测试驱动开发》（Test-Driven Development: By Example, 2002）
- Bass, Clements, Kazman, 《软件架构实践》（Software Architecture in Practice, 4th Ed.）
- Martin Fowler, 《企业应用架构模式》（Patterns of Enterprise Application Architecture）
- John Ousterhout, 《A Philosophy of Software Design》
软件工程实践
- Martin Fowler, "Continuous Integration"
- Martin Fowler, "SelfTestingCode"
- Edsger Dijkstra, 《goto 语句有害论》（Go To Statement Considered Harmful, 1968）
大学课程
- MIT 6.031 (Software Construction)
- MIT 6.170 (Software Studio) - Daniel Jackson
- Stanford CS 190 (Software Design Studio) - John Ousterhout
- CMU 17-313 (Foundations of Software Engineering)
- Berkeley CS 169 (Software Engineering)
工业革命与组织变革
- Wikipedia, "Factory system", "Spinning Jenny", "Luddite"
- Britannica, "Factory system"
- History.com, "The Original Luddites Raged Against the Machine"
- Adler, "The Evolution of Management Models: A Neo-Schumpeterian Theory"
作者注：本文写作于 2026 年 3 月，正值 harness 工程概念提出一个月后。文中对 AI 工程未来的预测基于历史类比和当前趋势，实际发展可能会有所不同。但历史的规律告诉我们：从混沌到秩序的路径，总是相似的。复杂性无法消除，只能驾驭。