序章：为什么企业级应用需要 Harness Engineering
本文是「企业级应用中 Harness Engineering 的实践与思考」系列的开篇。
什么是 Harness
在讨论 AI Agent 时，注意力很容易被放在大模型本身：模型是否足够聪明，代码能力是否足够强，上下文窗口是否足够大，推理能力是否足够稳定。
但在真实软件工程中，Agent 的能力并不只来自模型。模型之外，还有一整套东西在决定它能看到什么、能做什么、应该怎么做、做到什么程度，以及失败之后如何恢复。
这部分可以被称为 Harness。
Harness = Agent - Model
也就是说，一个 Agent 中除大模型以外的所有工程化部分，都是 Harness 的一部分。
例如：AGENTS.md、rules、skills、MCP、工具权限、脚本、工作流文档、任务状态、审查机制、上下文注入方式、命令执行环境、测试与验证流程。这些东西本质上都在做同一件事：控制、约束、引导和扩展大模型，使它能够在真实工程环境中完成可持续、可验证的工作。
所以 Harness 不是某一个单独的工具，也不是某一段提示词。它是围绕大模型建立起来的执行环境和治理系统。
企业级应用为什么不一样
随着大模型能力越来越强，网上常常能看到这样的文章：不会写代码的人，用一个下午 vibe coding 出了一个网站、一个小游戏，或者一个看起来已经可以使用的产品原型。它们给人的感觉是，一个大模型可以解决一切软件问题的时代似乎已经到来。
不可否认，今天的大模型已经足够强。很多时候，只要给出一个模糊的需求，它就能生成一个看起来还不错的 demo：页面能打开，按钮能点击，流程大致能跑通，甚至视觉效果也不差。
但 demo 和企业级应用是两件完全不同的事情。
企业级应用不是一次性的展示结果，而是一个需要长期演进的工程系统。它通常有复杂的业务规则、历史遗留代码、权限与数据边界、多人协作流程、测试和发布要求、线上稳定性压力，以及大量没有写在需求文档里的组织知识。更重要的是，它的需求往往不是一句自然语言描述就能完整表达的，而是伴随着明确的业务规则、交互边界、数据约束、权限控制、异常处理和验收标准。它不仅要"看起来能用"，还要在真实用户、真实数据、真实异常和真实变更中持续工作，并且能够被测试、审查和追溯。
这也是为什么，单纯依赖大模型本身的能力，很难做好企业级应用。模型可以生成代码，也可以解释代码，但企业级应用需要的不只是生成能力，而是围绕生成能力建立起来的上下文、约束、验证、协作和治理。
从 Prompt Engineering 到 Harness Engineering
短短几年里，AI 参与软件开发的方式已经发生了好几次变化。
最早的时候，人们更多是在和 ChatGPT 这样的对话式 AI 聊问题：把需求、报错、代码片段复制进去，再把 AI 生成的解释或代码复制回代码库。那个阶段的核心问题是：如何把问题说清楚，如何让 AI 更好地理解人的意图。于是 Prompt Engineering 成为一个重要话题。
随后，AI 开始更直接地进入开发现场。它不再只是一个聊天窗口里的回答者，而是逐渐成为一个可以和人协作开发代码的 Agent。AI 开始拥有"眼睛"和"手"：它可以直接阅读代码库，而不是只依赖人类在 prompt 里转述上下文；它也可以直接修改文件、运行命令，而不是让人把答案复制回项目。
这带来了新的问题。一次 session 里的 AI 也许可以理解当前任务，但真实项目不会只存在于一次对话中。项目有长期目标、历史决策、当前进度、团队约定、技术边界和未完成的工作。于是 Context Engineering 开始变得重要：跨 session 的记忆需要被管理，项目知识需要被组织，必要上下文需要被注入，工具和环境也需要以更稳定的方式交给 AI。
但对于企业级应用来说，只有 prompt 和 context 仍然不够。
当 AI 不只是回答问题，不只是读取上下文，而是开始参与真实项目的持续开发时，更完整的工程系统就变得必要。任务如何拆解，状态如何流转，什么时候必须停下来等待人确认，哪些命令可以执行，哪些文件可以修改，结果如何验证，失败如何回收，多 Agent 如何协作，这些都不是模型本身能单独解决的问题。
这就是 Harness Engineering 出现的地方。
Prompt Engineering 解决的是"如何把问题告诉 AI"；Context Engineering 解决的是"如何让 AI 获得和保持上下文"；Harness Engineering 解决的是"如何让 AI 在真实工程系统中持续、可控、可验证地工作"。
所以 Harness Engineering 不是对过去方法的颠覆，也不是一个凭空出现的新概念。它是当 AI 从对话对象变成工程参与者之后，软件工程自然长出的下一层实践。它继承了 Prompt Engineering 和 Context Engineering 的经验，也继承了软件工程长期积累下来的协作机制、质量保障、权限边界、任务拆解和反馈流程，只是这些经验现在需要被重新应用到 AI Agent 这个新的执行体上。
为什么需要 Harness Engineers
Harness 这个词本身就很有意思。
一匹能力很强的马，可以跑得非常快。但如果没有马具，没有缰绳，没有方向控制，它的速度未必是助力，反而可能是一场灾难。方向错了，跑得越快，偏得越远；力量越大，失控时造成的破坏也越大。
但人类并不是通过否定马的力量来使用马。恰恰相反，人类通过 harness 把马的力量连接到明确的方向、边界和任务上。马没有取代人，但在被正确驾驭之后，它极大地扩展了人的行动能力。
AI 参与软件开发也是类似的关系。
Harness Engineering 的目标并不是制造一种可以完全取代人的 AI 开发系统。至少在当前实践中，它不是这样被设计的。真正的问题不是"如何让 AI 替代工程师"，而是"如何让 AI 的能力被工程师稳定、可控、可验证地使用"。
大模型已经具备很强的生成、理解和推理能力。但在企业级应用开发中，如果没有合适的 harness，这种能力很容易变成另一种风险：它可能误解需求，遗漏上下文，越权修改文件，跳过验证流程，在错误方向上快速产出大量看起来合理的代码。
这时就需要 Harness Engineers。
Harness Engineer 要做的不是训练一个更聪明的模型，而是设计模型之外的工程系统：如何拆解任务，如何组织上下文，如何定义状态流转，如何设置人类确认点，如何限制工具权限，如何接入测试和审查，如何让 AI 在失败时能够停下来、回退或重新分析。
换句话说，Harness Engineer 负责设计 AI Agent 的工作环境。它让 AI 不只是"能做事"，而是能在真实工程约束下做正确的事。
基于真实企业级应用开发实践的思考
这个系列的文章，正是基于真实企业级应用中落地 Harness Engineering 的实践过程。
它不是关于某个工具的介绍，而是一组围绕 AI 如何进入企业级应用开发现场的实践复盘。真正关注的，不只是 AI 如何生成代码，而是 AI 如何进入企业级应用的开发、迁移、协作、验证和交付流程。
因此，这个系列记录的不是理想化 demo 中推演出来的概念，而是真实落地过程中不断遇到的问题、取舍和思考：哪些上下文必须被保存，哪些流程必须被显式化，哪些动作必须设置人类确认点，哪些结果必须被测试和审查，以及 AI Agent 如何在工程约束中真正成为开发工作的助力。