Home

深色模式

Harness Engineering ​

概述 ​

Harness Engineering 研究如何设计模型周围的执行系统，让 Coding Agent 能在真实仓库中持续、可控并且可验证地工作。它处理的对象包括上下文、工具、任务状态、权限、验证、观测和失败恢复，而不局限于一段 prompt。

截至 2026 年 8 月 19 日，这个概念仍在扩散。OpenAI 直接使用 Harness Engineering，Anthropic 更常写 agent harness 或 harness design，Martin Fowler 将它整理成面向 Coding Agent 使用者的工程模型，Gartner 也已经发布实施检查清单。底层实践已经进入产品与团队工作流，但术语边界和岗位定义仍未标准化。

术语现状 ​

当前资料中常见四种说法：

说法常见含义当前状态
harness模型外部、用于引导和约束 Agent 的部分使用最广，但边界因作者而异
agent harness运行 Agent 的指令、编排、状态和工具接入系统产品和 SDK 文档中的常见说法
harness design针对具体模型和任务优化外围系统Anthropic 工程文章采用的说法
Harness Engineering系统建设和维护这些能力的工程实践正在形成，尚无统一规范

Anthropic 在可信 Agent 的讨论中采用较窄口径，将 Agent 系统拆成模型、harness、工具和环境：harness 主要负责指令与护栏，工具和环境单独计算。OpenAI 与 Martin Fowler 的工程语境更宽，往往把仓库文档、工具、检查器和反馈回路都纳入外层 harness。

因此，更准确的理解是：Harness Engineering 负责这几个部分的设计、连接和维护，不必强行把所有组件都叫作 harness。

概念关系 ​

Prompt Engineering 处理输入如何表达，Context Engineering 处理哪些信息进入模型，Harness Engineering 则覆盖 Agent 如何执行、检查和继续推进。三者不是严格的替代关系。在 Coding Agent 场景中，prompt 和上下文设计通常成为整个 harness 的组成部分。

只查询一个 API 时，清楚的 prompt 和必要上下文可能已经足够。任务涉及读仓库、修改文件、执行命令、处理报错并提交证据时，执行系统的质量会直接影响结果。

近期演进 ​

Agent-first 仓库 ​

OpenAI 在 2026 年 2 月公布了一次内部实验：团队从空仓库开始，让 Codex 生成应用代码、测试、CI、文档、观测和内部工具。文章报告该仓库五个月内达到约一百万行代码、约 1500 个合并的 Pull Request，早期由三名工程师驱动，后来扩展到七人。

这组数字不能直接外推到普通项目，但它暴露出一个重要变化：人工投入从逐行编码转向环境设计、意图说明和反馈回路。OpenAI 总结的做法包括：

  • 使用简短的 AGENTS.md 作为索引，而不是塞入完整手册
  • 把结构化的 docs/ 作为仓库知识源
  • 将计划、进度、技术债和决策记录版本化
  • 用 linter 和 CI 检查文档、架构和代码约束
  • 通过持续清理控制 Agent 生成内容带来的熵增

其中一个关键原则是 Agent legibility：对 Agent 不可访问、不可检索或不可验证的信息，在执行时等同于不存在。

长任务 Harness ​

Anthropic 在 2025 年 11 月的长任务实验中使用两段式 harness：初始化 Agent 负责建立任务清单、进度文件和初始环境，后续 Coding Agent 每次只推进一部分工作，并为下一次上下文留下状态。

2026 年 3 月，Anthropic 又公布了 planner、generator 和 evaluator 三 Agent 结构。Planner 把简短目标扩展为产品规格，Generator 负责实现，Evaluator 依据可检查标准审阅结果。该结构把任务分解、跨阶段状态和验证信号放在模型外部，支持持续数小时的应用开发。

这并不意味着 Agent 越多越好。Anthropic 在同一篇文章中强调，模型升级会让部分脚手架失去作用。维护 harness 时应针对真实任务阅读执行轨迹，一次移除一个组件并比较结果，保留仍然承担实际作用的部分。

从实践到研究 ​

2026 年 4 月，Martin Fowler 网站发布面向 Coding Agent 使用者的 Harness Engineering 文章，将控制分成两类：执行前提供方向的 guides，以及执行后帮助纠错的 sensors。两者又可以分为确定性的 computational controls 和依赖模型判断的 inferential controls。

Gartner 在 2026 年 6 月发布了面向 AI Coding Agent 的 Harness Engineering 检查清单。2026 年 5 月的预印本进一步提出任务说明、上下文选择、工具访问、项目记忆、任务状态、可观测性、失败归因、验证、权限、熵审计和人工干预记录等十一项职责。7 月出现的 GPU Kernel 研究则把 harness 用于编译、正确性校验、性能测量和产物归档。

这些资料说明该词仍在扩散，但预印本提出的分类还不是行业标准，不宜当作固定认证体系或成熟岗位定义。

组成部分 ​

一个面向真实项目的 harness 通常需要处理以下问题：

组成部分需要解决的问题常见载体
项目知识Agent 如何找到真实、最新的项目约束AGENTS.md、CLAUDE.md、docs/、架构文档
上下文选择当前任务应该加载哪些信息文件搜索、索引、渐进披露、Skills
工具接入Agent 能执行哪些真实动作Shell、浏览器、MCP、内部 CLI、代码搜索
任务状态跨轮次和上下文如何延续进度计划文件、进度记录、Git 历史、任务系统
权限边界哪些动作允许、询问或禁止sandbox、allow/ask/deny、容器、凭据隔离
验证反馈如何用外部证据判断完成编译、测试、lint、截图、日志、评审 Agent
观测恢复失败原因如何进入下一轮命令输出、Trace、失败归因、回滚点
人工控制何时必须暂停并交回判断审批、计划评审、风险阈值、干预记录

其中验证反馈最容易被忽略。Agent 自己声明“已经完成”只是文本输出；编译器、测试、浏览器和运行日志给出的才是环境证据。

执行回路 ​

Harness 的作用不是一次性准备上下文，而是维持一个能根据真实结果纠错的闭环。

反馈最好优先采用确定性信号，例如编译、类型检查、结构校验和可重复测试。视觉质量、架构合理性或需求语义需要模型评审时，可以增加 inferential checks，但不应让它替代已有的确定性检查。

仓库落地 ​

让说明可导航 ​

仓库级规则文件应保持简短，负责告诉 Agent 去哪里找事实、用什么命令验证、哪些边界不能越过。详细设计放进有明确所有者和更新机制的文档，避免把所有信息堆进一个不断腐化的说明文件。

固定工具入口 ​

构建、格式化、检查、启动和 smoke check 应有稳定命令。高频工作可以封装为脚本、Skills 或 MCP 工具，让 Agent 调用同一个可维护入口，而不是每次临时拼命令。

写清验收证据 ​

任务说明应包含可执行的完成条件，例如：

  • 修改 Go 代码后完成编译
  • 修改前端页面后检查桌面和移动端截图
  • 修改文档站后完成构建并检查死链
  • 修改接口后验证状态码、响应结构和关键日志

验收信号应进入 Agent 的下一轮上下文。失败输出只留在终端里，反馈回路就断了。

保留任务状态 ​

长任务需要显式记录已完成内容、剩余工作、失败原因和验证结果。状态可以放在计划文件、任务系统或版本控制记录中，但必须让下一轮 Agent 能稳定读取，不能只存在于上一段对话里。

控制权限范围 ​

工具越多，权限设计越重要。文件路径、网络、凭据、删除操作和外部写入应分别配置允许、询问和禁止策略。高自主模式仍需要容器或 VM 等环境隔离，模型判断不能替代系统边界。

定期做减法 ​

Harness 中每个组件都隐含了一个判断：模型无法独立完成某件事。模型、代码库和任务分布变化后，这个判断可能失效。应使用代表性任务和固定指标重新评估，逐项删除不再改善结果的提示、Agent、脚本和检查器。

适用场景 ​

以下场景更值得投入 Harness Engineering：

  • 任务跨多轮或多个上下文窗口
  • 需要调用多个工具或外部系统
  • 结果必须经过客观验证或审计
  • 多人共用同一套 Agent 工作流
  • 同类任务高频重复，失败模式可以沉淀
  • Agent 会接触代码仓库、CI、浏览器、工单或生产数据

临时问答不需要复杂 harness。任务越长、动作越多、失败成本越高，外围工程系统的收益越明显。

常见误区 ​

误区结果处理方式
只优化 promptAgent 仍然缺少事实、工具或验证信号先定位失败发生在哪个系统环节
把规则全部塞进一个文件上下文拥挤，规则容易失效使用短索引和渐进披露
接入工具但不限制权限能力和风险同时扩大配置最小权限与环境隔离
让 Agent 自行判断完成容易过早结束或遗漏边界情况使用外部、可重复的验收证据
只增加 Agent 和检查器成本、延迟和故障点持续增加根据真实轨迹逐项验证作用
模型升级后沿用旧 harness旧脚手架可能限制新模型用相同任务重新评估并做减法

参考 ​