AI 控制工程：面向编程 Agent 的 Harness 体系

AI 控制工程面向编程 Agent 的 Harness 体系原文的核心观点是软件开发正在从“AI 辅助人写代码”转向“人辅助 Agent 完成软件工程”原来服务于人的基础设施、测试、质量、安全和管理能力也必须被重新设计为服务 Agent 的控制体系。本文将这套体系统称为Agent Harness中文可理解为“面向 Agent 的工程控制与保障系统”。一、核心判断程序员职业并不是简单地被 AI 替代而是在发生角色迁移。过去的软件生产方式大致经历了三个阶段人工编程阶段需求理解、方案设计、编码、测试和修复主要由人完成工具只是执行人的明确指令。AI 辅助编程阶段人仍是主要责任主体AI 用于补全代码、解释错误、生成测试或提供局部建议。Agent 主导执行阶段人负责目标、边界、资源、验收标准和最终决策Agent 承担大部分检索、修改、运行、验证和迭代工作。第三阶段的关键变化不是“代码由谁敲出来”而是软件工程的主要服务对象发生了改变。过去代码规范、脚手架、文档平台、测试流水线、监控告警和权限制度主要帮助人提高效率、减少错误现在这些能力还要能被 Agent 理解、调用并形成自动反馈闭环。因此基础架构、可观测性、自动化测试、质量保障和安全测试不会消失反而会变得更重要。变化在于使用者从人扩展为 Agent信息从“便于人阅读”升级为“既便于人理解也便于机器检索和执行”规则从口头约定升级为可检查、可执行的约束验收从开发结束后的人工检查前移为 Agent 每一步都可获得的反馈管理由盯住具体操作转向控制目标、权限、风险和交付结果。这就是 Harness 出现的背景。二、什么是 HarnessHarness 原意是“挽具、背带、控制装置”。在 Agent 工程语境中它不是某一个单独产品也不只是任务编排器而是一整套让 Agent 能够稳定完成工作的外部条件。可以把一个编程 Agent 想象成刚加入团队、执行力很强但不了解项目的新人。仅仅告诉它“把这个功能做完”通常不够还需要同时提供清楚的目标和验收条件项目背景、术语、架构和历史决策可以使用的工具和操作方法允许修改的范围及禁止触碰的边界编码、测试、安全和发布规则能快速判断结果是否正确的验证机制出错后的反馈、回退与升级路径。围绕这些内容建立起来的运行环境、工具链、规则集、监测系统和管理机制就是 Agent Harness。更完整的定义是Agent Harness 是围绕智能 Agent 构建的工程控制系统。它把任务目标、上下文、工具、权限、规则、验证、观测和反馈组织成闭环使 Agent 的行动可执行、可约束、可验证、可追踪并最终对交付结果负责。原文将其概括为“Agent 任务编排、监测、验证设计框架”这个说法抓住了重点但如果用于工程落地还应补上上下文供给、工具接入、权限安全和人工治理四个部分。三、Harness 不是什么为了避免概念泛化需要明确几个边界。1. Harness 不等于大模型模型决定 Agent 的基础理解、推理和生成能力Harness 决定这些能力在具体组织和项目中如何被调用、限制和验证。同一个模型在不同 Harness 下可能表现出完全不同的可靠性。2. Harness 不等于提示词提示词只是任务说明和上下文的一种载体。一个完整 Harness 还包括代码库、知识检索、工具接口、沙箱、权限、测试、监控、审计和人工审批。3. Harness 不等于工作流编排编排解决“先做什么、后做什么、失败后走哪条分支”Harness 还要回答“允许做什么、依据什么做、如何判断做对了、出了问题如何追责和恢复”。4. Harness 不等于完全自动化Harness 的目标不是无条件取消人工参与而是把人放在最有价值的位置。低风险、可验证的操作可以自动执行高风险、不可逆或责任重大的操作应保留人工审批。5. Harness 不是严格统一的行业标准“Harness”更像一个正在形成中的工程概念不同团队的定义范围可能不同。有的强调运行时与工具调用有的强调评测与安全有的把上下文工程也纳入其中。因此实际沟通时应说明本团队所指的具体模块避免只讲新名词、不讲能力边界。四、完整体系的八个组成部分1. 目标与任务定义Agent 首先需要知道要解决什么问题而不只是收到一句模糊指令。高质量任务定义通常包含背景为什么要做目标最终要产生什么结果范围哪些模块在任务内哪些不在约束技术栈、兼容性、性能、安全、时间等要求验收标准怎样才算完成风险等级是否允许自动执行、是否需要审批交付物代码、测试、文档、报告或部署结果。任务定义越可验证Agent 越容易自主闭环。模糊任务会把大量不确定性推到执行阶段使 Agent 频繁猜测或产生看似合理但偏离目标的结果。2. 上下文与知识供给Agent 的失败往往不是因为不会写代码而是不知道本项目的真实约束。Harness 需要按需提供项目结构和关键入口架构说明和依赖关系业务术语与领域规则编码规范和示例API、数据库及配置说明历史决策、已知问题和禁用方案与当前任务最相关的代码和文档。这里的关键不是“把所有资料一次性塞给 Agent”而是建立可检索、可定位、可更新的上下文系统。信息过少会导致误判信息过多则会稀释重点、增加冲突和成本。3. 工具与执行环境Agent 要从“会回答”变成“会完成任务”必须拥有可调用的工具例如文件搜索、读取与修改编译、测试、静态检查和格式化代码搜索、版本控制与差异审查日志、指标和链路查询数据库只读查询浏览器或界面自动化构建、制品生成和受控部署。工具接口应尽量结构化输入、输出和错误状态要清晰。执行环境最好隔离避免 Agent 的错误操作直接影响生产系统或用户数据。4. 规则与权限控制Agent 不仅要知道“怎么做”还必须知道“什么不能做”。控制项包括可读、可写目录可调用的服务与接口网络访问范围凭据和敏感信息的使用方式可自动执行的命令需要人工批准的操作删除、覆盖、发布等高风险动作的限制最大执行时间、调用次数和成本预算。权限设计应遵循最小权限原则并根据任务动态授予。不要因为 Agent 最终可能需要某种能力就在任务开始时一次性开放所有权限。5. 任务编排与状态管理复杂任务需要被拆分为可执行、可检查的步骤。典型状态包括待处理、执行中、等待输入、验证中、失败重试、需要审批和已完成。编排层负责将大目标拆成阶段和子任务记录当前进度与中间产物管理依赖关系设置重试、超时和终止条件在必要时切换工具或策略遇到关键不确定性时请求人工决策在上下文中断后恢复任务。状态必须外部化不能只存在于一次模型对话中否则任务容易因上下文压缩、进程中断或模型切换而丢失。6. 验证与质量门禁验证是 Harness 最核心的部分之一。没有验证Agent 只能“生成一个看起来像答案的结果”有了验证才可能形成真正的工程闭环。验证可分为多个层次语法与格式检查编译和类型检查单元测试、集成测试和端到端测试静态分析、依赖漏洞和密钥扫描性能、兼容性和稳定性测试需求验收检查代码差异审查生产前人工审批。重要原则是验证标准应尽量独立于生成过程。如果 Agent 自己提出方案、自己实现又仅凭自己的文字判断“已经完成”很容易形成自我确认偏差。测试、规则引擎、外部观测和人工复核可以提供相对独立的证据。7. 可观测性与审计Agent 系统需要回答的不只是“成功还是失败”还包括接收了什么目标和上下文做过哪些计划与关键决策调用了哪些工具修改了哪些文件或数据哪一步失败、为什么失败消耗了多少时间、Token 和外部资源哪些操作经过了人工批准最终结果由哪些证据支持。建议至少保留任务日志、工具调用记录、代码差异、测试结果、审批记录和最终交付摘要。对于敏感信息应做脱敏和访问控制不能为了可观测性而无限制记录隐私或凭据。8. 反馈、恢复与人工治理真正可靠的系统必须允许失败并能从失败中恢复。Harness 应提供可理解的错误反馈有上限的自动重试检查点和断点恢复变更回滚降级到安全模式无法判断时向人升级根据成功与失败数据改进规则、工具和提示。人工治理并不意味着每一步都要人批准。更合理的方式是按风险分层低风险任务自动完成并留痕中风险任务在关键节点抽查高风险任务必须审批后执行。五、运行闭环一个典型的 Agent 工程任务可以形成如下闭环接收目标读取任务背景、范围、约束和验收标准。收集上下文定位相关代码、文档、配置和历史信息。风险判断识别是否涉及敏感数据、外部系统、删除、发布等高风险动作。制定计划拆分步骤确定工具、验证方式和人工检查点。受控执行在允许的环境和权限内修改、运行或查询。持续验证每完成一部分就进行局部检查避免错误积累到最后。异常处理根据错误证据修正方案超过重试阈值则停止并升级。综合验收运行完整测试和质量门禁确认满足任务定义。交付与留痕输出结果、变更摘要、验证证据、风险提示和后续建议。经验回流把新发现的规则、故障模式和项目知识更新到 Harness。这个闭环可以概括为目标输入 → 上下文供给 → 计划编排 → 权限控制 → 工具执行 → 自动验证 → 观测反馈 → 修正或升级 → 结果交付六、人和 Agent 的职责重新分配当 Agent 承担大部分编码工作时人类工程师的价值会更多集中在以下方面人负责的内容定义真正值得解决的问题澄清业务目标和优先级设计系统边界和关键架构制定安全、质量与合规标准建设 Harness 和验证基础设施处理跨团队冲突和模糊决策审批高风险操作对最终结果承担责任。Agent 适合负责的内容检索代码和资料执行明确的修改任务生成样板代码和测试运行工具并分析错误完成重复性迁移和批量修改汇总变更、测试和风险信息在清晰规则下持续迭代。这意味着优秀程序员不再只以“亲手写了多少代码”衡量价值还要看他能否把模糊需求转化为可执行目标能否建立可靠的上下文和验证系统以及能否让多个 Agent 在安全边界内稳定交付。七、衡量 Harness 是否有效不能只看 Agent 生成了多少代码或节省了多少输入时间。建议从以下维度衡量交付效果任务一次通过率从接收任务到可验收结果的周期人工返工次数需求偏离率变更上线后的缺陷率。自主程度无需人工干预即可完成的任务比例每个任务的人工介入次数因信息不足而暂停的比例从失败中自动恢复的比例。质量与安全自动测试覆盖及通过情况安全扫描问题数量越权或高风险操作拦截次数回滚率审计记录完整度。效率与成本单个成功任务的模型和工具成本平均执行时间无效重试次数上下文读取量与有效信息命中率人工节省时间。最重要的指标不是“Agent 调用了多少次”而是“在可接受风险和成本内产生了多少可验证、可交付的结果”。八、常见失败模式1. 只换模型不建设工程环境问题表现模型能力很强但经常不理解项目、改错位置或无法完成验证。改进方向优先补齐项目说明、工具接入、测试反馈和权限边界而不是把所有问题都归因于模型不够聪明。2. 上下文堆积过多问题表现一次性提供大量文档和代码信息互相冲突Agent 反而抓不住重点。改进方向建立分层索引和按需检索优先提供与当前任务直接相关、最新且有权威性的内容。3. 任务描述无法验收问题表现目标只有“优化一下”“做得更智能”“修好这个功能”等模糊表述。改进方向把期望行为转化为可观察结果并给出示例、边界条件和明确的完成标准。4. 工具很多但接口不稳定问题表现Agent 能调用大量系统却经常因为参数含糊、错误信息不清或环境不一致而失败。改进方向减少重复工具统一输入输出提供明确的错误码、使用示例和幂等机制。5. 验证由 Agent 自说自话问题表现Agent 在没有运行测试或查看真实结果时直接宣布完成。改进方向要求交付必须附带可复查证据将测试、扫描和差异审查做成强制门禁。6. 权限一次性开放过大问题表现为了减少审批给 Agent 提供生产写权限、全库修改权或无限网络访问。改进方向按任务动态授权默认只读在明确需要时逐步增加权限对不可逆操作设置审批和回滚预案。7. 追求完全无人化问题表现把“没有人工参与”当成最高目标导致复杂或高风险任务也被强行自动执行。改进方向把优化目标改为“最少但有效的人工介入”让人专注于真正需要判断和担责的节点。九、分阶段建设路线第一阶段让 Agent 看得懂项目目标是解决“信息不清”的问题。整理项目结构、启动方式和常用命令明确编码规范和禁止事项补齐核心业务术语与架构说明建立高质量任务模板保证文档与代码版本同步。第二阶段让 Agent 能安全执行目标是解决“会建议但不能完成”的问题。接入文件、代码搜索、构建和测试工具建立隔离执行环境设置目录、命令、网络和凭据权限对删除、发布、数据修改等动作增加审批保存完整变更差异。第三阶段让结果能够自动验证目标是解决“看起来完成但无法证明”的问题。补齐自动化测试增加类型、规范、安全和依赖检查将验收条件转化为可执行检查建立失败分类和反馈格式交付时强制附带验证证据。第四阶段形成可观测的任务闭环目标是解决“过程不可控、失败难复盘”的问题。记录计划、工具调用、变更和验证结果建立任务状态、超时、重试和恢复机制统计成功率、返工率、成本和人工介入率对典型失败建立评测集定期复盘并更新规则与知识。第五阶段实现规模化治理目标是让 Harness 从单个项目能力变成组织能力。统一风险分级和审批策略建立可复用工具、规则和任务模板区分组织级知识与项目级知识建立 Agent 变更的审计和责任机制对不同模型、工具和流程进行持续评测防止局部效率提升换来系统性安全风险。十、最小可用 Harness 清单如果团队刚开始实践不需要一上来建设庞大平台。最小可用版本至少应具备一份清晰的项目说明一套结构化任务模板可搜索的代码与文档隔离且可重复的执行环境明确的读写权限和禁止事项可由 Agent 调用的构建、测试和检查命令对高风险动作的人工审批任务过程、代码差异和测试结果留痕失败后可停止、恢复或回滚最终交付包含结果、证据、风险和未完成事项。一个简单但闭环的 Harness通常比功能很多却没有验证和边界的复杂平台更有价值。十一、对管理和组织的影响Harness 不只是技术工具也会改变团队管理方式。1. 从管理工作量转向管理结果当大量代码由 Agent 生成后提交次数、代码行数和工作时长更难代表真实价值。管理应更加关注交付质量、验证证据、缺陷率、风险和业务效果。2. 工程资产的重要性上升过去容易被忽视的文档、测试、规范、脚手架、可观测性和自动化流程会直接决定 Agent 的工作上限。它们不再只是辅助资产而是组织生产能力的一部分。3. 隐性经验需要显性化资深工程师脑中的“这个模块不能这样改”“这个接口有历史兼容要求”如果没有进入规则、文档或测试Agent 就无法稳定遵守。组织需要把关键经验转化为可检索、可执行、可验证的知识。4. 责任不能交给模型Agent 可以执行任务但不能承担法律、伦理和组织责任。谁定义目标、谁批准高风险动作、谁验收和发布必须有明确制度。十二、为什么新概念会不断出现原文还提出了一个值得保留的观察技术快速变化时新词会不断出现。创造一个术语的积极作用是把复杂的一组实践压缩成一个便于讨论和传播的符号。“Harness”让人们可以快速指代任务编排、上下文、工具、权限、验证、监测和治理这一整套问题。但新词也有风险不同人使用同一术语时实际指向不同概念传播速度可能快于工程实践团队容易把改名当成能力升级厂商或个人可能通过命名争夺话语权。因此对待新概念最实用的态度是理解它压缩了哪些真实问题再将其拆回可落地的模块、流程、指标和责任而不是停留在术语本身。十三、总结Harness 的本质不是给 AI 再包装一个新名词而是承认一个工程事实当 Agent 成为软件开发的主要执行者时原来围绕人建立的软件工程体系必须重新适配 Agent并用更清晰的目标、更结构化的上下文、更受控的工具、更严格的权限、更自动化的验证和更完整的观测反馈来保证交付。从通俗角度看Harness 就是带一个能力很强但不熟悉环境的“新人”干活时为它准备的方法、资料、工具、规则、检查和管理机制。从工程角度看Harness 是连接模型能力与真实生产结果的中间层。模型决定 Agent “可能会做什么”Harness 决定它“在这个项目里能够安全、稳定、可验证地做成什么”。未来程序员的重要能力之一将不只是亲自编写代码而是设计目标、组织上下文、构建工具、设置边界、建立验证并持续改进这套让 Agent 可靠工作的工程系统。这可以称为AI 控制工程也可以称为Agent Harness 工程。名字可以变化但其核心始终是把不确定的智能能力转化为可控、可验收的生产能力。