夜雨聆风
从软件工程到 Harness:AI Agent 正在重写工程治理
一、软件工程到底解决了什么问题？
1968 年，NATO 会议上第一次正式使用”软件工程”这个词。那次会议要解决的问题不是”怎么写更好的代码”，而是”为什么大型软件项目总是失控”。代码写得出来，但项目交不了；功能做得出来，但系统跑不稳；个人能力够强，但团队协作崩溃。
软件工程从一开始就不是编程技巧的集合。它是一套治理方法——治理的对象是”人写的软件”在整个生命周期中产生的复杂度。这种复杂度来自三个方向：系统本身的规模复杂度、多人协作的组织复杂度、以及软件从开发到运行全过程的流程复杂度。
理解这个起点很重要。软件工程不等于编程语言、不等于设计模式、不等于敏捷或瀑布。它是一个不断演化的治理体系，核心使命只有一件事：让人类能够持续、可靠地构建和运行复杂软件系统。
二、软件工程是如何治理复杂度的？
回顾五十多年的演化，软件工程的治理手段沿着一条清晰的路径展开：
管代码——版本控制、模块化、接口规范。解决的是”代码本身会失控”的问题。从 CVS 到 Git，本质上都是让代码的变更可追溯、可回退、可并行。
管协作——代码评审、分支策略、权限模型。解决的是”多人同时改一个系统会互相破坏”的问题。Pull Request 不只是技术流程，它是组织治理的最小单元。
管交付——持续集成、持续部署、自动化测试。解决的是”从代码到可运行系统之间的鸿沟”的问题。CI/CD 管道把人工判断替换为自动化门禁。
管运行——监控、告警、可观测性、SRE 体系。解决的是”系统上线之后会以不可预期的方式出错”的问题。
每一次扩展，治理的边界都在外推：从源码文件，到团队流程，到交付管道，到生产环境。但有一个前提始终没变——被治理的对象是”人写的、按确定逻辑执行的软件”。代码被部署之后，它的行为边界是确定的。它不会自己决定调用一个新的 API，不会自己判断该不该执行某个操作，不会在运行时改变自己的目标。
软件工程的全部治理手段，都建立在这个确定性假设之上。
三、AI Agent 为什么改变了这件事？
AI Agent 打破了这个假设。
一个被部署的 Agent，它的行为边界在部署时是不完全确定的。它接收目标，自主规划步骤，调用工具，根据中间结果调整策略，甚至在必要时改变执行路径。它不是在执行一段预先写好的逻辑，而是在运行时持续做出决策。
换句话说，软件工程过去主要管理的是人写的软件；现在，工程体系开始面对会自主行动的软件。
这不是程度上的变化，而是性质上的变化。传统软件的复杂度来自”人写的逻辑太多太复杂”；Agent 的复杂度来自”系统本身在运行时生成新的逻辑”。
具体而言，Agent 带来了三类传统软件工程没有处理过的治理挑战：
行为不可完全预测。 同一个 Agent 面对相似输入，可能产生不同的执行路径。你无法像审查代码那样审查它”将要做什么”，因为它的行为在运行前并不完全存在。
自主性带来的权限问题。 Agent 能调用工具、访问数据、触发外部系统。它不是被动等待指令的函数，而是主动寻找达成目标路径的实体。传统的静态权限模型——”这个服务可以访问这个数据库”——不足以约束一个会自主决定”要不要访问”的系统。
目标与手段的分离。 传统软件的”目标”就是它的代码逻辑本身；Agent 的目标是外部给定的，手段是它自己选择的。这意味着你需要治理的不再只是”它能做什么”，还包括”它选择做什么”以及”它为什么这样选择”。
传统软件工程的治理模型——在开发阶段通过流程和规范约束行为、在部署后通过监控观察状态——面对 Agent 出现了结构性的缺口。你需要一种能在运行时实时介入、动态约束、持续评估的治理方式。
四、Harness 为什么会出现？
Harness 这个概念的出现，正是对这个结构性缺口的回应。
需要先说明：截至目前，Harness 并没有一个行业统一的严格定义。不同的团队和文献对它的边界描述不尽相同。OpenAI 在其工程博客中将其描述为”围绕 Agent 构建的工程基础设施层”；Martin Fowler 的团队将其定位为”coding agent 用户需要掌握的工程实践”；学术文献中则更多使用”runtime governance”或”governance-by-architecture”等术语来指代相近的问题域。
但这些不同表述指向的是同一个工程事实：当被管理的对象从”确定性执行的代码”变成”自主决策的 Agent”时，你需要一套新的治理基础设施。这套基础设施不是替代软件工程，而是在软件工程的演化路径上，接续处理新一类复杂度。
如果说软件工程的演化是”管代码 → 管协作 → 管交付 → 管运行”，那么 Harness 所处理的是下一个环节：管 Agent 的运行时行为。
它不是一个产品功能，不是一组 Prompt 编写技巧，不是某个具体的工具或协议，也不是一个可以独立存在的热词。它是软件工程面对新治理对象时，正在生长出来的一层工程能力。
五、Harness 与软件工程，到底哪里像？
理解 Harness 最有效的方式，是看它与传统软件工程在结构上的对应关系。两者解决的都是”治理复杂系统”的问题，但治理对象和治理方式发生了系统性的位移：
| 维度 | 软件工程 | Harness |
|---|---|---|
| 治理对象 | 开发者（人） | Agent（自主系统） |
| 治理位置 | 外部流程（开发、评审、部署） | 内部运行时（Agent 执行过程中） |
| 执行模型 | 人编写代码，系统执行代码 | 人设定目标，Agent 执行目标 |
| 规则形态 | 静态规则（规范、流程、门禁） | 动态 runtime policy（运行时策略） |
| 治理层级 | 组织治理（团队、流程、制度） | 系统治理（架构、约束、边界） |
| 监督方式 | 人类监督（评审、审批、巡检） | 自动监督（实时检测、动态干预） |
| 复杂度类型 | 协作复杂度（多人、多团队） | 自治复杂度（多 Agent、自主决策） |
这张表不是简单的类比，而是揭示了一个结构性的事实：Harness 处理的每一个问题，都能在软件工程中找到对应的前身。它不是凭空发明的新学科，而是软件工程在新条件下的自然延伸。
逐行展开来看：
从管理开发者到管理 Agent。 软件工程的大量实践——代码规范、评审制度、权限分级——本质上是在管理”写代码的人”的行为。Harness 面对的是类似的问题：如何确保一个自主行动的 Agent 不会越界、不会犯错、不会产生不可接受的后果。对象变了，但”约束行为主体”这个治理需求没变。
从外部流程到内部运行时。 传统治理发生在代码执行之前（评审）或之后（监控）。但 Agent 的关键决策发生在运行过程中——它在执行时才决定下一步做什么。因此治理必须嵌入运行时本身，而不能只靠事前规范和事后观察。
从静态规则到动态策略。 “所有 PR 必须两人审批”是静态规则；”当 Agent 试图访问生产数据库时，根据当前上下文和历史行为决定是否允许”是动态策略。后者需要在运行时根据实际情况做出判断，而不是预先穷举所有可能场景。
从人类监督到自动监督。 当 Agent 的决策频率远超人类反应速度时，逐一人工审批不再可行。你需要自动化的监督机制——能实时评估 Agent 行为、在必要时自动干预、事后提供完整的决策审计轨迹。
六、为什么 Harness 会越来越重要？
有一个简单的判断标准：如果 Agent 只是偶尔被使用的辅助工具，Harness 的优先级不会太高；如果 Agent 正在成为软件系统的核心执行组件，运行时治理就会变成必须补上的工程基础设施。
当前的趋势明确指向后者。Agent 正在从”辅助人类完成任务”演变为”独立承担任务”。它们不再只是回答问题或生成代码片段，而是在执行完整的工作流：自主调试、自主部署、自主与其他系统交互。当多个 Agent 协同工作时，系统的复杂度不是线性增长，而是组合爆炸。
这正是软件工程在 1968 年面对的相同处境：个体能力不是瓶颈，系统性的治理缺失才是。当年的答案是建立软件工程学科；今天面对 Agent 系统，答案的结构是相似的——你需要一套系统性的治理方法，而不只是零散的最佳实践。
Harness 会越来越重要，还有一个更根本的原因：信任问题。 人类愿意把多大的自主权交给 Agent，取决于是否存在可靠的约束和监督机制。没有 Harness，Agent 的能力越强，人类越不敢放手；有了 Harness，能力和信任才能同步增长。这与软件工程中”测试覆盖率越高，重构越大胆”的逻辑完全一致。
从组织层面看，Harness 还将影响责任归属。当 Agent 做出一个错误决策导致生产事故，谁负责？如果没有运行时的策略记录、决策轨迹、约束日志，这个问题无法回答。Harness 提供的不只是技术约束，还是责任可追溯性的基础设施。
七、Harness 会不会成为下一代软件工程？
这个问题现在回答为时过早。
可以确定的是：Harness 所处理的问题是真实的、结构性的、不会随某个具体技术方案的更迭而消失。只要 Agent 具备自主性，运行时治理就是必需的。这个需求不依赖于任何特定的模型架构、框架选择或产品形态。
也可以确定的是：Harness 目前仍处于早期。它的概念边界尚未稳定，最佳实践尚未沉淀，工具生态尚未成熟。它今天的状态，大约相当于 DevOps 在 2009 年、或者微服务在 2012 年的阶段——问题已经被识别，方向已经清晰，但具体的方法论和工程标准还在形成过程中。
不能确定的是：Harness 最终会以什么形态稳定下来。它可能成为软件工程的一个新分支，像 SRE 之于运维那样获得独立的学科地位；也可能被吸收进软件工程的主干，成为每个工程师默认掌握的基础能力；还可能分化为多个子领域，分别处理 Agent 安全、Agent 可观测性、Agent 协作治理等不同维度的问题。
但有一件事是清楚的：软件工程的演化从未停止。它始终在追赶”被治理对象”的复杂度增长。从管代码到管协作，从管交付到管运行，每一次扩展都是因为出现了新的复杂度来源。AI Agent 就是当前这一代新的复杂度来源，而 Harness 是软件工程对此做出的回应。
这个回应是否足够、是否正确、是否会被更好的方案替代——这些问题需要时间和实践来回答。但”需要回应”这件事本身，已经不是问题。
参考资料
- 1. OpenAI. Harness Engineering. https://openai.com/index/harness-engineering/
- 2. Martin Fowler / Thoughtworks. Harness Engineering for Coding Agent Users. https://martinfowler.com/articles/harness-engineering.html
- 3. arXiv. Runtime Governance for AI Agents. https://arxiv.org/abs/2603.16586
- 4. arXiv. SARC: A Governance-by-Architecture Framework for Agentic AI Systems. https://arxiv.org/abs/2605.07728