Harness Engineering：AI 编码与安全自动化之间的缺失层

Harness Engineering 不是让自主智能体今天就接管流水线。它是在现在构建结构，让安全自动化在未来成为可能。

大多数企业工程团队的实际位置

咱们先从现实说起。

在大型金融机构，大多数开发者正在用 GitHub Copilot、Cursor 或 Claude 来更快地写代码。一些团队 locally 用这些工具来 scaffold 服务、生成样板代码和起草单元测试。更小的一群人在实验能在 IDE 内规划和执行多步编码任务的 agentic 工具。

这就是 2026 年 3 月大多数企业团队所处的位置。

自主 AI 智能体自行向仓库提交代码、运行流水线或做出部署决策，目前尚未大规模运行。监管、变更管理和 plain 的机构风险承受力让这最早也是 2027 或 2028 年才能聊的事。

但一个真实的问题已经在这里了。

开发者们产出的代码比以前多得多。这些代码流经的是为更慢节奏设计的同一套测试关卡、同一套安全扫描和同一套审批工作流。为每周开 10 个 PR 的团队构建的测试套件，现在要支持每周开 40 个 PR 的团队。安全发现 multiply。评审队列增长。发布经理、应用安全工程师、测试人员和合规团队吸收着额外的负载。

这就是 Harness Engineering 旨在弥合的 gap。

Harness 到底是什么

这个词来自 OpenAI 2026 年 2 月的文章，Harness engineering: leveraging Codex in an agent-first world，关于构建和发布一个「0 行手写代码」的内部 beta 产品。他们的设置很极端：一个小团队在大规模运行高度自动化的智能体工作流。大多数企业工程组织远未达到这个程度。

但核心理念是可以 translate 的。

Harness 是围绕 AI 辅助软件交付构建的一套约束、上下文和反馈循环，让下游的人——测试人员、安全工程师、发布经理和合规团队——不必为 AI 的每个错误买单。

长期优势不会属于拥有最大模型的组织。它将属于围绕该模型拥有最佳运营环境的组织。成败 less 取决于原始模型智能，而更多取决于包裹它的系统的质量。

那个系统不会一下子出现。它分三个阶段发展：基础、增强和自动化。

为什么在受监管环境中这很重要

对于美国金融机构，AI 采用并非发生在监管真空中。银行 largely 被期望将现有控制措施应用于新的 AI 用例：模型风险管理、第三方风险管理，以及在决策影响消费者时的可解释性。Harness Engineering 之所以重要，是因为它把 AI 辅助工作变成更容易治理的东西：有文档记录的输入、有边界的工作流、可追溯的决策和清晰的评审点。

Harness 成熟度的三个阶段

大多数团队将经历相同的 progression。

第一阶段：基础

基础是团队创建 AI 需要才能有用而不制造混乱的结构。仓库上下文开始成形。核心标准被写下来。Spec 开始在实现之前存在。Prompt 模式、pre-commit 检查和工作流纪律成为 shared practice 而非个人习惯。在这个阶段，目标不是自动化任何东西。而是让 AI 辅助开发变得 legible、可重复且更容易治理。

在银行业，这一基础也支持模型风险纪律。团队需要定义预期用途、约束输出、验证高影响行为，并让人类对决策负责。一个好的 harness 让这些控制成为工程工作流的一部分，而非 separate 的事后练习。

第二阶段：增强

一旦结构存在，团队就开始用 AI 来加强交付系统本身。AI 不再只是帮助开发者更快地写代码。它帮助生成测试修复、起草部署文档、解释安全发现、总结风险，并将代码变更连接回标准和 spec。人类仍然 clearly 掌权，但他们的工作流现在在交付摩擦最大的地方被 AI 放大了。

第三阶段：自动化

只有在基础和增强到位之后，自动化才变得安全。智能体开始在定义的权限边界内作用于交付过程。一些修复可以自动完成。一些测试可以自我更新。一些部署可以在没有人类干预的情况下进行。一些回滚决策可以由策略和遥测触发。人类仍然治理系统，但他们不再需要手动执行其中的每一步。

这个顺序很重要。

自动化只在增强已经使工作流结构化和机器可读之后才有效。增强只在基础已经创建了可靠的上下文和标准之后才有效。试图跳过的团队通常会发现，他们缺少的正是自动化所依赖的输入。

知识库：一切之下的层

在测试、部署、安全或合规之前，有一个 foundational 层在它们之下：仓库内部持续维护的知识库。

OpenAI 的团队在同一篇文章中将此确定为他们 harness 的第一个也是最重要的部分。对于企业团队来说，这可能是最高杠杆的起步点。

这也是 Spec-Driven Development 从理论走向 practical 的地方。关于 SDD 的有用概述，参见 Thoughtworks 2025 年 12 月的文章，Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices。

仓库需要知道什么

当 AI 编码工具没有 meaningful 上下文时，它产生的代码看起来 plausible 却不适合周围的系统。它破坏本地模式、忽略服务边界、错过资深工程师记在脑子里的领域特定约束。

那些知识必须活在仓库本身：架构决策、服务边界、数据契约、性能约束、合规要求和批准的模式。不在 Confluence 里。不在 Slack 里。不在资深工程师的记忆里。而是在版本控制文件中，与它们描述的代码生活在一起。

OpenAI 的团队先尝试了显而易见的捷径：一个包含每条规则的大型指令文件。它变成了 stale 规则的 graveyard。当所有东西都被标记为重要时，没有东西是容易使用的。

更好的方法是模块化、可导航的文档。为架构、服务边界、数据契约、部署约束和运营标准准备单独的文件。处理特定任务的智能体应该能找到正确的上下文，而不必吞掉整个仓库。

这就是 Spec-Driven Development 的 practical 价值。Spec 不只是生成代码的 prompt。它们是捕捉意图、约束和设计选择的活 artifact，既服务于人类也服务于 AI。

两种仓库知识

Birgitta Böckeler 在 Martin Fowler 的文章 Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl 中提出了一个有用的区分：记忆库 vs spec。

记忆库是始终开启的层。它包括架构、模块边界、数据分类规则、批准的模式、反模式、性能期望和监管约束。它告诉 AI 它正在处理什么样的系统。

Spec 是任务特定的。它们在代码生成之前描述一个功能应该做什么：输入、输出、边界情况、约束和验收标准。AI 使用 spec 来生成代码，而 spec 留在仓库中作为未来变更的 truth source。

这两个层共同回答了每个 AI 系统都在隐含问的两个问题：

我在什么样的世界里运作？

我到底应该建造什么？

在银行里这看起来是什么样

大型金融机构已经拥有大部分这些知识。只是没有以 AI 能用的形式写下来。

批准的加密套件、PII 处理规则、数据驻留要求、服务所有权、通信模式和变更分类已经存在于某处的政策文档、架构委员会或资深工程师的头脑中。工作就是将其翻译成简短的精确文档，活在仓库里。

一个简单的起始结构可能长这样：

这些文档不需要很长。一份 300 字的安全标准文件，带两个具体例子，比一份 40 页的政策 PDF 更有用。目标不是 completeness。目标是足够的清晰度，让 AI 生成的代码看起来属于这个系统，而不是某个 generic 的示例应用。

应用于知识库的三个阶段

第一阶段：基础

从在几乎每个 AI 编码会话中都有帮助的记忆库文档开始：架构概述、安全标准和性能概况。保持简短并提交到仓库。团队开始为选定的功能编写轻量级 spec，让意图在实现之前存在。目标很简单：创建一个可靠的仓库上下文基础，减少可避免的 AI 错误。

第二阶段：增强

一旦这些文档存在，它们就开始塑造工作流。Spec 在代码生成之前成为 expected。记忆库有明确的负责人和更新期望。Spec 与代码一起被评审，所以团队不仅问代码是否有效，还问它是否符合 spec。当代码变更影响已记录的行为时，AI 可以为人类审批起草文档更新。在这个阶段，知识库成为 load-bearing。流水线引用它。SAST 规则从中提取。合规证据追溯回它。

第三阶段：自动化

后台智能体扫描文档与实现之间的 drift：不再匹配契约的数据模型、超出其文档边界增长的服务、不再匹配行为的 spec。它们打开 PR 来修复不一致，让知识库保持诚实。在这个阶段，spec 不只是文档。它成为自动化的运营输入。

知识库让其他每个领域都更好。更好的上下文改善测试。更好的标准改善安全。更好的映射改善合规。更好的性能概况减少低效的 AI 生成代码。

先构建这一层。

测试

现在的问题

一个开发者用 Cursor 或 Copilot 在两小时内而不是八小时内构建了一个功能。他们开一个 PR。现有测试套件运行。一些测试失败，要么是因为 AI 引入了 bug，要么是因为它改变了测试没预料到的接口。

现在开发者必须调试他们没有写的测试中的失败，而代码也不是他们从头完全手写的。这很慢、很 frustrating，而且越来越常见。

还有另一种模式：AI 生成的代码通常 happy path 处理得好，但错过边界情况。覆盖率可能看起来不错，即使生产风险在上升。

第一阶段：基础

定义用于测试感知编码的共享 prompt 模板。例如：基于 /docs/specs/[feature].md 中的 spec 实现一个功能，并生成覆盖 happy path、null 或空输入以及两种最可能错误条件的单元测试。引用 spec 保持 prompt 简短，并让 spec 成为 truth source。

添加一个 pre-commit hook，当新逻辑出现时检查测试文件。如果开发者添加了一个包含 meaningful 业务逻辑的文件却没有相关的测试文件，在 CI 之前抓住它。

改进测试失败输出，让 AI 能帮助修复它。包括测试验证哪条业务规则、映射到哪个 spec，以及自上次通过以来发生了什么变更。这给开发者提供了结构化的输入，可以反馈回他们的编码工具。

第二阶段：增强

测试成为 AI 加强交付过程的最清晰例子之一。CI 在呈现测试失败的同时，附带 AI 生成的修复建议，追溯回 spec。AI 生成代码中的覆盖率缺口在合并前触发第二次 pass 来生成缺失的边界情况测试。Flaky 测试被自动分类，这样基础设施噪音不会淹没真正的回归。

第三阶段：自动化

测试套件在定义的范围内成为 self-healing。如果 AI 生成的代码变更了一个接口，而 spec 确认行为变更是有意为之，断言可以自动更新。智能体为每个新服务生成基线覆盖率。人类从手写每个测试转变为评审测试策略和批准覆盖率标准。

部署

现在的问题

发布和变更管理流程没有改变，但流经它们的代码量变了。发布经理评审更多变更。审批队列增长。而且与这些变更绑定的文档往往变得更糟，因为使用 AI 生成代码的开发者事后并不总能清晰解释每个实现细节。

第一阶段：基础

从 spec 生成部署文档。Spec 已经解释了变更了什么、为什么变更、哪些契约受到影响以及如何衡量成功。在开 PR 之前，开发者用这些材料生成一份 plain-language 的变更摘要、受影响的服务、回滚计划和测试覆盖率说明。

更新 PR 模板以捕获 AI 使用和 spec 引用。两个问题能起大作用：这个变更中使用了 AI 吗？它实现了哪个 spec？这给评审者提供了上下文，并在意图、实现和批准之间创建了可追溯的链接。

以结构化形式编写部署 runbook。编号的步骤、回滚触发器和显式命令现在更有用，以后也机器可读。

第二阶段：增强

这是 AI 开始改进发布过程而不仅仅是往里面塞更多工作的地方。部署文档从 PR 元数据和链接的 spec 自动生成，然后由人类评审而非从头编写。流水线关卡根据映射到记忆库中标准的 policy-as-code 规则进行验证。AI 生成的风险评级帮助评审者关注 blast radius 和服务影响，而非手动重建变更意图。

第三阶段：自动化

低风险服务在批准的策略边界内自动部署。中风险服务使用自动化金丝雀验证，并在 SLO 违约时回滚。高风险变更仍然需要人类 sign-off，但那个 sign-off 聚焦于判断，而非机械流程。人类拥有政策。智能体处理 volume。

安全

现在的问题

一个应用安全工程师支持 50 个开发者已经是瓶颈了。给这些开发者能让他们更快产出更多代码的 AI 工具，发现量就会随之上升。更糟糕的是，模型会重复训练数据中的常见模式，包括不安全的那些。AppSec 团队最终不得不一遍又一遍地 triage 相同类别的问题。

第一阶段：基础

部署与内部标准绑定的 IDE 集成 SAST。Semgrep、Snyk 或 SonarLint 等工具在根据仓库自身安全文档派生的规则配置时最有用：批准的加密套件、参数化查询要求、PII 处理期望和禁止的模式。如果 AI 生成了不安全的东西，开发者应该立即在编辑器中看到它，并附带返回相关标准的链接。

添加一个 secrets-scanning pre-commit hook。这实现起来很快，并消除了一整类可预防的事件。

保持安全标准简短且可链接。同一份在代码生成期间给 AI 上下文的文档，也应该在扫描器触发时帮助开发者理解和修复问题。

第二阶段：增强

安全是另一个增强应该显而易见的地方。发现在 PR 级别出现，附带 AI 生成的修复建议，既关联到漏洞类型也关联到它违反的内部规则。来自 IDE 工具、pre-commit hook 和 CI 扫描的发现被关联到一个视图中，而不是创建重复的 triage 工作。AppSec 团队花更少时间评审重复错误，花更多时间改进防止它们的规则。

这对第三方风险也很重要。许多银行通过供应商采用 AI，无论是编码助手、模型提供商还是云平台。Harness 让机构对访问、评审、日志记录和证据保留有了更清晰的边界，这让供应商风险在实践中更容易管理。

第三阶段：自动化

定义严重度阈值以下的 well-understood 漏洞类别可以进入自动修复循环。安全标准文档成为智能体在生成代码之前检查的活策略层，而非只是在扫描器抓住问题之后。来自 DAST 和生产环境的运行时信号反馈回知识库，让系统随时间变得更聪明。

合规

现在的问题

开发者正在 AI 聊天会话中做出真实的技术决策：架构权衡、安全选择、实现方法。几乎没有推理过程被 capture。所以当审计师问为什么某物以某种方式实现时，答案可能只存在于几周前就已关闭的工具窗口中。

与此同时，合规证据仍然是事后组装的。已构建内容与文档所说已构建内容之间的差距，是审计 pain 的 recurring 来源。

第一阶段：基础

把 spec 当作决策日志。实现之前编写的 spec 已经记录了意图、约束和选择的方法。与代码一起提交它，你以后就不需要重建推理过程。对于更广泛的架构决策，在 /docs/architecture/ 中使用简短的 ADR。

当 AI 影响面向消费者的决策时，这种可追溯性甚至更重要。CFPB 指导意见明确，使用 AI 或其他复杂模型的贷款人仍需要提供具体且准确的不利行动原因。如果一个团队无法重建系统为什么表现出某种行为，它就还没准备好做受监管的决策。

使用 AI 从 spec 和变更元数据起草合规 artifact。变更工单、数据流描述、影响评估和风险摘要都可以从已有信息开始。AI 起草它们。人类评审并批准它们。

在 PR 标题和描述中强制执行结构化元数据。将变更映射到控制标识符的标题在实现和合规要求之间创建了可追溯的链接。当这些控制映射活在记忆库中时，开发者更可能在整个交付过程中将它们保持在视野内。

第二阶段：增强

合规工作变得 less retrospective 且 less manual。Artifact 从链接的 spec 和 PR 元数据自动生成，然后被评审而非被撰写。控制标识符直接映射进活证据矩阵。文档架构与部署现实之间的 drift 通过流水线数据变得可见，而非在审计准备期间才暴露。

第三阶段：自动化

每个流水线动作在发生时 emit 一个结构化合规事件。报告从该事件流生成。预审计证据包自动组装并由人类在提交前评审。“为什么这东西要以这种方式实现？“现在有一个默认答案，从事件追溯到 PR 再到 spec。

优化

现在的问题

优化仍然是 mostly reactive。东西坏了或变慢了，有人调查，修复被做出，而学习经常消失在 Slack 线程或个人记忆中。

AI 生成的代码在这里添加了特定风险：它通常足够正确能通过，但足够低效会在以后 hurt。模型可能生成一个在功能上有效的数据访问模式，却导致 N+1 查询或不必要的计算，因为它从未被给予性能约束。

第一阶段：基础

把性能概况放进记忆库。对每个服务，捕获预期数据量、延迟 SLO、已知瓶颈和之前导致 incident 的模式。当开发者 prompt AI 工具在该服务中构建时，那个上下文应该随之而来。

用回顾会来改进 harness，而不只是记录经验教训。Incident 之后，问什么规则、测试、检查清单项或 prompt 模板本可以更早抓住问题。然后把它加回系统。Over time，知识库开始反映组织的失败模式，而非 generic 最佳实践。

把 AI 特定检查添加到完成的定义中。变更是否在有正确性能上下文的情况下生成的？PR 是否链接到 spec？本地是否运行了 secrets 扫描？架构选择是否有清晰的决策记录？这就是知识库如何成为工作习惯而非 shelfware。

第二阶段：增强

性能工作变得更 proactive。概况自动包含在相关服务的 AI 上下文中。回顾会生成标准、模板和 linter 规则的候选更新供人类批准。成本异常触发结构化调查，AI 总结来自近期部署历史的可能 contributing 变更，并将它们连接回性能概况。

第三阶段：自动化

可观测性数据、延迟、错误率和基础设施成本与仓库知识库一起成为智能体上下文的一部分。定时清理智能体识别 stale spec、已弃用的功能标志、孤立的资源和过时的文档，然后要么直接修复要么路由项目以供评审。系统保持 current，因为 drift 被积极管理。

回报

这里的重点不是急于奔向自主智能体。而是构建那个 progression，让它们在时机成熟时安全且有用。

基础 创造结构。

增强 减少人类瓶颈。

自动化 变得可能，因为前两个阶段让系统变得 legible。

这就是知识库如此重要的原因。每个领域在 AI 拥有更好上下文时都会改善。

更好的上下文产生更好的测试。

更好的标准产生更好的安全扫描。

更好的映射产生更好的审计轨迹。

更好的性能概况产生更少低效的代码。

其他一切都是它的下游。

等待工具成熟才添加结构的团队，以后转型会更痛苦。Retrofitting 上下文进代码库总是比早期就构建进去更痛苦。组织将在自动化上 struggle，不是因为它们缺乏访问先进模型的能力，而是因为它们没有可靠的东西供那些模型推理。

好消息是，这不需要从大型平台采购或专业 AI 团队开始。

基础几乎对任何 DevOps 组织都是可触及的。从知识库开始。三份文档就够了：架构概述、安全标准和性能概况。保持简短。提交它们。然后挑选 pain 最明显的地方，开始围绕它增强工作流。

Harness 会 compound。

在需要它之前，先构建它。