生成式 AI 正在快速进入软件开发的核心流程。从最初的代码补全工具，到能够生成完整模块的 Coding Agent，再到可以自主修复 Bug、执行测试甚至生成 Pull Request 的智能体，软件开发的生产方式正在发生明显变化。许多团队已经开始尝试将 AI 引入开发流程，例如让 Agent 分析 Issue、生成实现代码，并根据 CI 反馈不断修复问题。

然而，当 AI 开始在真实项目中承担更多工作时，一个现实问题很快浮现出来：AI 写代码的速度，远远超过团队能够控制系统复杂度的能力 。 开发者很快会发现，AI 可以在几分钟内生成数千行代码，但这些代码并不一定理解系统架构、历史设计决策或领域规则。如果缺乏工程约束，AI 很容易绕过既有结构，引入新的依赖关系，甚至悄悄改变系统边界。

很多团队最初会把这些问题归因于模型能力，但随着实践深入，一个更清晰的结论逐渐浮现出来：问题并不在模型，而在软件工程系统本身 。 我们今天的大多数工程体系——代码结构、开发工具、流程设计——都是围绕人类开发者构建的。这些系统默认开发者理解上下文、遵守约定，并在评审过程中发现问题。 但 AI 并不具备这样的隐性知识。

如果 AI 将成为软件开发流程中的长期参与者，那么软件工程系统本身也需要进化。这正是 Harness Engineering 试图解决的问题。

从 Human-first 到 Agent-aware

传统的软件工程体系是围绕人类开发者设计的。代码仓库的结构、开发工具的界面、CI/CD 的操作方式，都假设使用者是人类。例如，很多开发工具依赖图形界面或隐含约定，而不是机器接口；许多关键知识存在于团队经验或历史文档中，而不是结构化数据。

当 AI 进入开发流程时，这些假设开始失效。AI 并不能像人类一样通过阅读零散文档理解系统，也无法从团队经验中获得隐性知识。如果没有明确表达系统结构和规则，AI 生成的代码往往会偏离设计意图。

因此，AI Coding 的关键并不是简单地把模型接入开发工具，而是要将软件工程系统从 Human-first system 转变为 Agent-aware system。这意味着工程系统需要被重新设计，使其能够被机器理解、调用和验证。

Harness Engineering 正是在这样的背景下提出的一种工程实践。

Harness Engineering Capability Model

在实践中，团队通常需要在三个层面重新设计工程系统。为了理解这些能力之间的关系，可以用一个简单的模型来描述：

          反馈回路
               ▲
               │
系统可读性 ─── 防御机制 ─── 自动化反馈

这个模型的含义并不复杂。系统首先需要具备足够的可读性，使 AI 能够理解结构和上下文；在此基础上，工程系统需要提供明确的边界，以限制 AI 的行为范围；最后，系统还必须持续向 AI 提供反馈，使其能够不断修正行为并改进结果。

这三个能力共同构成了 Harness Engineering 的核心。

可读性：让系统能够被 AI 理解

在很多软件项目中，系统知识往往分散在不同位置。代码中包含实现细节，文档记录部分设计，而真正的领域规则和架构意图往往存在于团队经验之中。对于人类开发者来说， 这些信息可以通过交流逐渐理解，但 AI 并没有这样的能力。

如果希望 AI 能够可靠地生成代码，就必须逐渐将这些隐性知识显性化。系统的结构、架构原则和领域概念需要被明确表达，并以机器可读的形式组织起来。 代码仓库在这种环境中不再只是代码存储空间，而更像是一张可导航的知识地图。AI 可以从高层架构文档进入系统，然后逐步探索模块结构、领域模型以及实现细节。

另一个重要变化是上下文提供方式。复杂系统往往包含大量信息，如果一次性提供全部文档，反而会增加推理的不稳定性。更有效的方式是逐步披露上下文，使 AI 根据任务逐渐获取所需信息。这样一来，AI 的理解过程更接近人类开发者探索系统的方式。

同时，工程工具本身也需要调整。许多开发工具最初是为人类界面设计的，例如 Web UI 或交互式流程。对于 AI 来说，这些接口并不友好。将系统能力暴露为 CLI 或 API，使其可以通过机器接口访问，是构建 Agent-aware 系统的重要一步。

防御：收敛 AI 的行动空间

在传统开发流程中，系统通常依赖开发者的经验来避免架构问题。例如，当代码评审发现不合理的依赖关系时，团队会手动修正。然而，当代码生成速度大幅提高时，这种方式很难维持系统稳定。

AI 的生成能力非常强，如果缺乏约束，它可能在系统中引入新的复杂度。例如重复实现已有逻辑、绕过既有模块边界，或者创建新的隐式依赖关系。这些变化在短期内可能并不明显， 但随着时间推移，系统结构会逐渐腐化。

因此，在 AI Coding 环境中，工程系统需要承担更多防御职责。许多团队已经在持续交付实践中使用类似机制，例如静态分析、自动化测试和架构验证。但在 AI Coding 环境中，这些机制的意义发生了变化。它们不再只是质量保障手段，而是系统边界的一部分。

换句话说，这些工程约束就像系统的“物理定律”。AI 可以自由探索解决方案，但无法突破这些规则。通过自动化工具持续执行这些约束， 团队可以确保系统在高频修改的情况下仍然保持结构稳定。

反馈：让系统能够持续学习

如果说工程约束为 AI 提供了边界，那么反馈系统则为 AI 提供了方向。在传统开发流程中，开发者通过编译错误、测试结果和代码评审不断调整实现方式。AI Coding 其实需要类似的机制，只不过这一循环可以发生得更快。

在一个设计良好的工程系统中，AI 每完成一次修改都会立即获得反馈。开发环境中的静态分析和测试可以提供第一层信号，而代码提交后，CI 系统又会产生新的验证结果。当系统上线后，监控数据和运行日志则提供了更长期的反馈。

当这些信号能够被统一收集并提供给 AI 时，软件开发就逐渐从线性流程演变为循环系统。AI 不再只是一次性生成代码，而是在反馈驱动下不断调整实现方式，直到系统达到稳定状态。

这种模式与传统 DevOps 的持续交付理念非常相似。不同之处在于，在 AI Coding 环境中，这些循环往往可以在更短时间内完成。

Harness Engineering 在现实中的实践

一些公司已经开始在真实环境中尝试类似的工程体系。例如 Stripe 在其 Agent Engineering 实践中构建了一套完整的执行循环：工程师通过 Slack 或 CLI 触发任务，Agent 负责生成实现代码并运行测试，如果 CI 失败，系统会自动进入修复循环，直到代码满足基本质量标准后再生成 Pull Request。人类工程师的角色更多是进行最终评审，而不是逐行编写代码。

另外一个典型案例是 Routa.js——一个多 Agent 协作平台。它的核心特点是：整个项目既是 AI Agent 的工作环境，也依赖 AI Agent 自身参与开发。 多种 AI Agent（Kiro、GitHub Copilot、Augment、Claude Code 等）必须协作在同一代码库中，同时遵循统一的工程规范和质量门禁。

系统可读性

• 工程规范文档 AGENTS.md 定义编码标准、测试策略、Git 纪律以及 AI 提交的 Co-Author 格式。
• Specialist 配置明确各 Agent 角色和职责边界，保证 Developer、Verifier 等角色按流程执行。

工程防御机制

• 双层 Git Hooks：Pre-commit 快速检查，Pre-push 提供结构化错误反馈；
• Lint 策略允许部分规则降级为警告，确保多 Agent 协作顺利，同时记录问题便于后续跟踪。

自动化反馈回路

• Issue Enricher 为新 Issue 准备上下文并提出解决方案；
• Copilot Complete Handler 将 Draft PR 转为 Ready for Review，触发 Augment Agent 审查；
• Issue Garbage Collector 定期清理过期 Issue，本地 Issue 文件提供持久上下文；
• Kanban 系统触发 Agent 任务，并要求提供可验证 artifacts，如测试结果或代码 diff。

这些案例说明了一件重要的事情：AI Coding 的突破往往来自工程系统，而不仅仅是模型能力。

软件开发正在变成循环系统

随着 AI 的加入，软件开发的结构也在发生变化。Kief Morris 曾提出一个有趣的观点：未来的软件开发将运行在两个不同的循环中。一个循环关注“为什么要做”，也就是业务目标和产品价值，这一部分仍然主要由人类主导； 另一个循环关注“如何实现”，也就是代码生成、测试、修复和验证，这一部分越来越多地由 AI 执行。

在这样的系统中，人类开发者的角色开始发生变化。他们不再只是编写代码，而是设计系统、制定规则，并管理这些工程循环。从某种意义上说，人类负责构建系统杠杆，而 AI 则负责放大这些杠杆。

结语

当 AI 成为软件开发的重要参与者时，软件工程系统也需要随之演进。Harness Engineering 提供了一种新的视角：通过提升系统可读性、建立工程防御机制以及构建高频反馈回路，我们可以让 Coding Agent 在复杂系统中安全运行，并持续提升软件开发效率。

AI Coding 的未来并不是完全自动化的软件开发，而是一个 Human 与 Agent 共同运行的软件工程系统。Harness Engineering，正是这一系统的工程基础设施。