先给一句定义：Harness Engineering 是为 Agent 重写工程执行环境

如果把 Coding Agent 理解成“会写代码的模型”，那你最后得到的通常只是一个更快的代码生成器；如果把它理解成“要在真实项目里长期工作的执行者”，你就会自然走到另一个问题上：这个执行者到底在什么样的工程环境里工作，它读什么，能做什么，哪里会被拦住，出了错怎样被纠偏。

我更愿意把 Harness Engineering 理解为一门新的工程实践：它不是优化模型本身，而是设计、约束和运营 Agent 的工作环境，让仓库结构、工具接口、验证门禁、审批边界和反馈回路一起构成一个可执行系统。Agent 不再直接面对一团混乱的代码和流程，而是在一个被整理过、可导航、可验证的环境里工作。

越来越多一线实践都在强调同一件事：Agent 真正进入生产，起点往往不是更复杂的 prompting，而是更好的工程脚手架。OpenAI、Anthropic 和 AWS 的近期材料，分别从执行、评测和 guardrails 三个角度，把这个判断写得越来越明确。

flowchart TD
  A["系统可读性"] --> B["执行约束"]
  B --> C["自动反馈"]
  C --> D["评测与回放"]
  D --> A

这个定义里有三个关键词。

• 它是一层执行环境，而不是一个模型技巧。
• 它要服务长期运行，而不是只服务一次性演示。
• 它必须能够被度量、回放和持续改进，而不是只靠感觉判断“这次好像写得不错”。

它的范围到底有多大：从仓库表面一直延伸到组织治理

很多团队第一次听到 Harness Engineering，会把它缩小成“给 Agent 写个 AGENTS.md”或者“在 CI 里多加几条规则”。这些动作当然重要，但它们只是最表层的入口。真正的 Harness，至少覆盖四层范围。

第一层是仓库可读性。也就是 Agent 进入系统后，能不能快速看懂模块边界、目录职责、关键文档、代码约定和历史决策。这里包括 AGENTS.md、架构文档、领域词汇表、目录约束、脚本入口和少量结构化上下文。

第二层是执行外壳。也就是 Agent 实际如何读文件、改代码、跑测试、查日志、调用 API、访问数据库、使用浏览器、保存产物。这里的关键不是“工具越多越好”，而是接口是否稳定、参数是否清晰、权限是否可控、结果是否可追踪。

第三层是交付回路。也就是任务如何从 issue、spec 或工单进入系统，如何被拆解、执行、验证、评审、发布和回溯。Agent 是否能提交分支、是否能创建 PR、什么时候必须人工确认、失败后是否自动进入修复循环，都属于这一层。

第四层是组织治理。也就是预算、权限、合规、审计、值班、异常升级、质量指标和团队分工。没有这一层，前面三层最多只是“好用的个人工具”；有了这一层，Agent 才开始变成团队和组织的生产能力。

flowchart TB
  A["组织治理"] --> B["交付回路"]
  B --> C["执行外壳"]
  C --> D["仓库可读性"]

如果把范围说得更直接一点，Harness Engineering 处理的不是“AI 怎么回答”，而是“AI 怎么在真实工程系统里工作”。这也是它和常见 prompt engineering 最大的区别。

为什么它在 2026 年突然变成一个独立议题

原因并不神秘。模型能力足够强之后，瓶颈自然会从“会不会生成”转到“能不能稳定交付”。Anthropic 在《Building effective agents》里反复提醒，真正有效的 agent 系统通常建立在简单、可组合的模式上，而不是一开始就追求复杂的多 Agent 编排。OpenAI 在实践指南里也把工具、指令和 human intervention 放在了很前的位置，意思很明确：Agent 的问题从来不只是模型推理。

一旦 Agent 从 demo 进入代码仓库，它马上会碰到人类工程体系的隐性假设。很多规则没有写出来，很多接口只适合人类手工操作，很多关键判断靠口头经验传递，很多评审问题依赖资深工程师在最后一刻发现。人类可以在模糊地带工作很久，Agent 不行。

所以 Harness Engineering 变成独立议题，不是因为它发明了全新理论，而是因为它把原来分散在软件工程、DevOps、测试工程、平台治理里的要求，重新围绕 Agent 的执行方式组织了一遍。它本质上是一种重新编排已有工程能力的方法。

个人实践应该从哪里开始：先把自己的仓库变成 Agent 能工作的地方

个人实践最容易走偏的地方，是一上来先选框架、接模型、做 UI，然后才发现仓库本身根本不适合 Agent 进入。更有效的顺序通常相反：先修环境，再谈自治。

以开源仓库 phodal/routa 这类多 Agent 协作项目为例，最值得学习的不是“它用了多少 Agent”，而是它把工程规范显式写进了仓库：README 把平台定位、工作流和协作方式公开化，AGENTS.md 则把执行授权、测试要求、Git 纪律和 AI 参与约定收成明确规则。这个动作看起来朴素，但它解决的是 Agent 最难获得的那部分隐性知识。

从个人实践看，Harness Engineering 的第一步通常不是“让 Agent 更强”，而是让它更少误解。你至少要把下面几件事先补起来。

• 给仓库写一份真正可执行的 AGENTS.md，不要只写愿景口号。
• 把常用动作收成稳定脚本，例如测试、编译、格式化、启动和发布检查。
• 让错误信息尽量结构化，至少让 Agent 能看出失败发生在哪一层。
• 给关键目录写边界说明，避免 Agent 在陌生区域自由扩散。
• 明确哪些文件可以直接改，哪些动作必须停下来等人确认。

当这些基础工作完成后，你才会发现个人实践的真正收益，并不只是“改代码更快”，而是 Agent 开始具备一种稳定的工作姿态。它知道先看哪里，知道该用什么命令，知道失败后要从什么线索继续，也知道何时该停。

我对个人 Harness 的一个更实际判断

个人仓库里的 Harness，目标不是把自己彻底替换掉，而是把高频、低风险、可验证的工作尽量变成机械闭环。你可以把它理解成给自己的工程环境加了一层“可委托性”。

这里最容易见效的，不是需求定义和产品判断，而是那些原本就有清晰成功标准的工作，例如修一类已知测试失败、把一套改动同步到多个文件、补回归测试、做 API 升级、整理文档索引、跑脚本生成产物、收敛 lint 报错。Harness 一旦成立，这些任务会明显加速。

但反过来说，个人实践里也要尽早承认边界。只要任务涉及系统边界重构、关键安全策略、业务目标变化或者高风险数据迁移，人仍然应该在回路里。Harness Engineering 不是鼓励盲目自动化，它真正鼓励的是精确委托。

团队实践和个人实践最大的区别：你要开始设计责任边界

个人仓库的问题，更多是“能不能让 Agent 工作起来”；团队仓库的问题，则会迅速变成“出了问题谁负责，怎么回放，怎样避免下次再犯”。这就是为什么团队实践不能只复制个人技巧，而要补上流程、角色和治理。

从公开材料看，当前比较成熟的团队实践正在形成一套相似结构。GitHub 把 Copilot coding agent 的价值主张放在“从 issue 到代码变更”的执行链条上；Anthropic 和 OpenAI 则都在强调 eval、人工介入和工具边界；AWS 进一步把输入验证、权限控制和 guardrails 写成显式基础设施。这几条线拼在一起，基本就是今天团队级 Harness 的主干。

flowchart LR
  A["Issue / Spec / Ticket"] --> B["任务拆解与上下文准备"]
  B --> C["Agent 执行"]
  C --> D["本地与 CI 验证"]
  D --> E{"通过门禁?"}
  E -- "否" --> F["结构化反馈与自动修复"]
  F --> C
  E -- "是" --> G["人工评审与审批"]
  G --> H["合并、发布与监控"]
  H --> I["事故回放与 Eval 更新"]
  I --> B

在团队里，Harness 至少要回答六个问题。

• 任务是谁创建的，谁有权把它交给 Agent。
• Agent 能动哪些工具，能访问哪些上下文，哪些资源必须隔离。
• 什么叫“这次完成了”，通过标准是测试、快照、评审，还是业务指标。
• 失败后自动修几次，超过几次以后必须转人工。
• PR、部署、数据库写入、外部调用这些高风险动作，哪些需要审批。
• 运行日志、输入、输出、工具轨迹和关键决策，能不能完整回放。

这六个问题如果没有写清楚，团队里的 Agent 很快就会从“加速器”变成“事故放大器”。

团队落地时，最值得优先建立的三条基线

第一条基线是仓库基线。每个团队仓库都应该有最小可读性包：AGENTS.md、架构入口文档、测试入口、开发命令、目录职责和重要约束。不要默认 Agent 会自己推断这些东西。

第二条基线是验证基线。Agent 改动进入评审前，至少要经过一组稳定的自动化门禁，包括单测、静态检查、必要的集成测试和结构化失败输出。这里的关键不是测试数量，而是结果是否足够明确，能够驱动下一轮修复。

第三条基线是审批基线。不是所有动作都要审批，而是所有高后果动作都要审批，例如删除生产数据、修改计费逻辑、放开安全策略、推生产配置、重写核心边界。Harness Engineering 的成熟，不是减少审批，而是把审批用在真正该用的地方。

流程与规则应该怎么设计：先定义“可运行流程”，再谈“自治程度”

很多团队谈 Agent 落地时，喜欢先问“能不能全自动”。这个问题太早了。更有用的做法，是先把一条最小可运行流程设计出来，再决定每一步的自动化程度。

一套可执行的 Harness 流程，通常至少包含六段。

任务进入

任务进入时，要有清晰的任务类型、完成定义、风险等级和上下文入口。不要把一句模糊需求直接扔给 Agent。最好在进入执行前就把背景文档、相关代码路径、限制条件和期望产物整理好。

上下文装配

上下文不是越多越好，而是越准越好。Anthropic 的经验很明确：简单、可组合的工作流往往更稳。对于 Harness 来说，这意味着上下文应该按任务装配，而不是每次都把全仓库、全知识库、全历史对话一起丢进去。

执行动作

执行阶段要让工具调用尽量标准化。读文件、跑命令、编辑代码、生成补丁、调用 API、查询数据，这些动作最好都走稳定接口，而不是依赖 UI 或手工步骤。执行阶段还要记录动作轨迹，否则你无法判断 Agent 到底是“推理错了”还是“工具用错了”。

验证与修复

这是 Harness 最容易体现价值的地方。只要失败输出足够结构化，Agent 就可以把编译错误、测试失败、lint 报错、快照变更、回归断言等信号重新吃回去，进入自动修复循环。R2E-Gym 这类研究之所以值得关注，正是因为它把验证器而不是提示词，放到了提升编码 agent 的核心位置。

评审与审批

通过自动化门禁，不等于可以直接进生产。评审阶段要把“结果是否可接受”和“过程是否可信”分开看。前者看改动本身，后者看 Agent 是否遵守了边界、是否绕过了约束、是否留下了足够证据。

发布与回放

真正的 Harness 一定有回放意识。一次任务结束之后，不只是看合没合、发没发，还要看失败链路有没有被加入 eval 集，新的坑有没有沉淀成规则，哪个环节的成本和延迟开始不合理。

什么样的规则值得写进 Harness

不是所有规则都值得显式化，但下面这些规则通常值得尽早写出来。

• 仓库级规则：目录边界、命名约定、测试要求、禁止改动区域。
• 执行级规则：默认命令入口、超时、重试、并发和资源配额。
• 权限级规则：可读、可写、可调用、可发布和需审批动作。
• 质量级规则：必须通过的测试、允许降级为 warning 的项、失败后的处理顺序。
• 证据级规则：必须产出的 diff、日志、测试结果、截图或审计记录。
• 升级级规则：何时自动修复，何时转人工，何时直接中止。

规则写得越像可执行文档，Harness 的收益越大；规则写得越像理念宣言，Agent 越难真正遵守。

Harness Engineering 是什么，不是什么

这个概念现在还在快速收敛，所以把边界说清楚很重要。

它是什么

Harness Engineering 是一套围绕 Agent 执行环境展开的工程方法。它把代码仓库、工具层、验证器、审批流、评测集和运行观测连接起来，目的是让 Agent 能在复杂系统里稳定工作。

它也是一种新的平台视角。过去平台工程主要服务人类开发者，今天平台工程要开始同时服务 Agent。凡是能让任务更可读、更可调用、更可验证、更可回放的建设，都正在进入 Harness 的范围。

它还是一种组织能力。因为一旦 Agent 参与正式交付，团队就必须重新分配责任、审批和治理，而这已经超出单纯技术实现的范围。

它不是什么

它不是 prompt engineering 的高级版。Prompt 当然仍然重要，但 Harness 关注的是环境和边界，而不是单轮对话措辞。

它不是某个框架的别名。LangGraph、Agents SDK、Bedrock AgentCore、Copilot、Claude Code 都可能成为 Harness 的组成部分，但没有任何一个框架本身等于 Harness。

它也不是“让 Agent 完全自治”的同义词。很多成熟 Harness 恰恰会把人工介入、审批门禁和回滚路径设计得更明确。

最后，它不是只属于大公司。个人仓库、开源项目、小团队内部工具，同样可以从 Harness 思路里受益。差别只在深度和治理强度。

有没有其他选择：有，而且有些场景根本不该先上 Harness

Harness Engineering 不是唯一道路。它适合的是“任务有一定开放性，但又需要稳定交付”的地带。如果你的问题不在这个地带，别的方案可能更划算。

一个很重要的判断是：如果任务可以被严格规格化、流程稳定、状态明确，那么确定性系统通常比 Agent 更便宜、更可靠。这个提醒非常有价值，因为今天很多团队会把“能用 Agent 做”误解成“应该用 Agent 做”。

flowchart TD
  A["待自动化任务"] --> B{"规则稳定且可完全显式化?"}
  B -- "是" --> C["优先确定性工作流"]
  B -- "否" --> D{"需要跨上下文推理与多步修复?"}
  D -- "否" --> E["优先 Copilot 或半自动工具"]
  D -- "是" --> F{"失败后果可控且可验证?"}
  F -- "否" --> G["先保留人工主导"]
  F -- "是" --> H["进入 Harness Engineering 设计"]

现实里常见的替代方案大概有四种。

• 纯确定性工作流：适合规则稳定、变动小、可完全规格化的任务。
• Copilot 式辅助：适合提效单点环节，但不急着让 Agent 自主串完整流程。
• Spec-driven 开发：适合先把需求和约束沉淀清楚，再决定是否交给 Agent 执行。
• 纯人工高密度评审：适合高风险早期探索期，先收集失败模式，再决定自动化边界。

我自己的判断是，Harness Engineering 最适合作为第二阶段建设。第一阶段先让团队明确任务和规则，第二阶段再把这些规则封装进可执行环境，第三阶段才去追求更高自治和更低人工介入。

工具和平台支持现在已经到哪一步了

如果只从产品名录看，今天的工具已经很多了；但如果从 Harness 的角度看，真正值得关心的是它们分别补哪一层能力。

OpenAI 的 Agents 相关实践更偏向“从模型、工具、指令和人工介入出发”去搭建可交付 agent。LangGraph 的定位更明确，它强调低层编排、持久状态和人工控制点，适合那些要把流程图和状态机做得很清楚的团队。AWS 的 Bedrock AgentCore 更像偏企业基础设施的一层，关注运行时、会话、身份、长期任务和企业集成。MCP 则在工具协议层提供了更统一的思路，让 Agent 和外部工具之间的连接不必每次都重新发明。

如果从交付入口看，GitHub Copilot coding agent 这一类产品正在把 issue、代码变更、PR 和平台门禁连得更紧，这说明主流代码托管平台也开始把 Agent 当成正式参与者，而不再只是代码补全功能。

flowchart TB
  A["交付入口层"] --> B["编排与运行时层"]
  B --> C["工具协议层"]
  C --> D["验证与治理层"]
  D --> E["观测与评测层"]

如果按建设顺序来排，我更建议这样看工具栈。

• 第一类是入口工具，负责把任务带进来，例如代码托管平台、工单系统、知识库和命令入口。
• 第二类是运行时工具，负责状态、编排、重试、持久化和人工接管。
• 第三类是工具协议，负责把内部系统、浏览器、CLI、数据库、文件系统暴露给 Agent。
• 第四类是验证和治理工具，负责测试、策略、审批、权限和审计。
• 第五类是评测和观测工具，负责回放、trace、数据集、成本和成功率监控。

真正成熟的 Harness 往往不是押注单一平台，而是把这五类能力串起来。平台是加速器，不是替代品。

效能评估应该怎么看：不要只看 benchmark，更不要只看一次 demo

一谈评估，很多团队就会立刻去看 benchmark 分数。这当然是必要信息，但绝对不够。越来越多团队已经意识到，单一 benchmark 很容易让人把局部能力误当成真实生产力；更稳妥的做法，是把模型能力和 harness 表现拆开度量。

更现实的评估方法，应该至少分成三层。

第一层是任务层，也就是这件事到底有没有被完成。对于编码任务，可以看任务成功率、回归通过率、人工接管率、失败后修复成功率、首次通过率。对于知识工作任务，可以看答案可用率、需要返工的比例、完成时间和审批通过率。

第二层是系统层，也就是 Harness 本身跑得怎么样。这里更值得看的是重试深度、工具失败率、超时率、上下文装配失败率、平均回放成本、审计可追溯性和单位任务成本。

第三层是组织层，也就是团队是否真的因此变快变稳。这里可以看需求到 PR 的周期、从 PR 到 merge 的周期、逃逸缺陷、审查负担变化、重复性工作占比下降、夜间告警和人工兜底成本。

flowchart TB
  A["组织层指标"] --> B["系统层指标"]
  B --> C["任务层指标"]
  C --> D["模型与基准层"]

研究基准仍然有价值，只是要放在正确位置。SWE-bench 仍然适合观察软件修复任务的整体趋势，WorkArena 这类 benchmark 适合观察知识工作场景里的网页任务完成能力，OSWorld-Human 则提醒我们“会做”和“高效完成”并不是一回事，OS-Harm 又进一步说明安全问题不能被默认忽略。

我更建议把效能评估做成一张组合表心智模型。

• 基准分数回答的是“理论上有没有能力”。
• 任务指标回答的是“在你的系统里能不能完成”。
• 系统指标回答的是“这个 Harness 跑得是否稳定”。
• 组织指标回答的是“团队是否真的因此受益”。

只看第一层，容易自嗨；四层一起看，才像工程评估。

未来展望：Harness 会从工程技巧，逐渐变成组织操作系统的一部分

接下来两三年，我认为 Harness Engineering 至少会沿着五条线继续演进。

第一条线是协议化。MCP 这样的工具协议，只是一个开始。未来更多系统接口、权限描述、事件语义和工具返回格式会被标准化，Agent 不再需要每次为新系统重新学习交互方式。

第二条线是运行时化。今天很多 Agent 还像一次性脚本，明天它们会越来越像长任务进程，具备持久状态、可恢复执行、预算管理、审批挂起、异步回调和跨系统跟踪。这也是为什么 AgentCore、LangGraph 这类偏运行时的能力开始更重要。

第三条线是验证器前移。随着 Agent 生成速度越来越快，验证器会比生成器更稀缺。未来最有价值的不只是“更强模型”，而是“更强 verifier、simulator、policy checker 和 replay system”。

第四条线是组织分工重写。人不会消失，但人的位置会继续上移。从亲自完成每一步，转向定义边界、设计规则、批准高风险动作、维护评测集和处理真正复杂的异常。

第五条线是经济性优化。到某个阶段以后，团队竞争的重点不再是“有没有 Agent”，而是“同样质量下谁能更便宜、更快、更稳定地让 Agent 跑起来”。这时候，Harness 就会像 CI/CD、平台工程、测试工程一样，变成基础设施竞争。

最后收成一个落地清单

如果要把这篇文章压缩成一份可执行清单，我会建议从下面十步开始。

• 先选一个高频、低风险、可验证的真实任务，不要从最复杂场景开局。
• 给仓库补齐 AGENTS.md、架构入口和命令入口，让 Agent 先看得懂。
• 把读、改、测、查这些动作收成稳定接口，不要依赖手工流程。
• 先建最小自动化门禁，再追求更高自治。
• 把高风险动作单独列出来，明确审批和禁止规则。
• 记录失败案例，把它们变成回归集，而不是在聊天记录里蒸发。
• 不要把 benchmark 当真相，把它当信号。
• 把日志、trace、diff、测试结果和关键决策都留痕。
• 每隔一段时间回看 Harness 本身，而不是只回看模型版本。
• 让团队逐步形成共识：我们优化的不是一次生成，而是整个执行系统。

Harness Engineering 最有价值的地方，不是让 Agent 看起来更像人，而是让软件工程系统开始真正适应 Agent。等这一步做成之后，AI 才不是一个挂在 IDE 侧边栏里的能力，而是一种可以被组织放心委托的生产方式。