Harness Engineering：长程自动化 AI Coding / Skills 开发实践

这是2026年的第21篇文章

本文阅读时间：约20分钟

Harness Engineering 是什么？

Harness Engineering，本质上是在为 Agent 构建一个能够持续感知、持续反馈、持续优化的自主演进环境。

它是通过约束机制、反馈闭环、工作流编排、效果评估以及持续优化循环等能力，将 Agent 的运行过程纳入一个可观测、可控制、可迭代的系统工程框架之中。目标是在长程和复杂场景下，让 Agent 不仅能够执行任务，更能够感知执行状态、评估执行效果、捕捉优化方向，并据此不断调整策略，从而实现自我迭代并交付高质量结果。

Harness Engineering 和 Prompt Engineering、Context Engneering 并不是互斥的概念，而是发展阶段和嵌套关系，更像是随着 AI 能力的提升、基础设施的完善，一种重要性和关注点自然而然地升维。

Harness Engineering 聚焦方向

当前 Harness Engineering 的主要实践基本在 AI Coding （但任何一个 AI 应用本身都包含 harness）领域，2026年2月底开始受到广泛关注，OpenAI 、 Anthropic、Stripe 等在 2、3 月份都做了一些相关实践分享。总结下来，大家的实践重点聚焦以下几个方向：

上下文控制

Agent 应能够恰当的获取需要的上下文，不多不少。

专业 Agent 分工协作

不同 Agent 专注于特定领域、接受特定上下文，优于一个关注全链路的通用 Agent。

评估反馈

真正拉开差距的，是为 agent 配备一个足够挑剔、能够感知运行环境的评估模块，它知道明确目标，同时知道怎么客观结构化的评估结果。

结构化执行回路

适度编排 Agent 执行工作流，在关键节点增加人类审查，重点关注目标和结果的正确性。

应用环境对 Agent 的可读性

持续把应用本身（UI、日志...）暴露给 Agent，变成 Agent 可检查、可验证、可修改的形态。

我们的实践

我们在 AI Coding和Skills 开发两个方向上进行了探索。

设定两个核心目标

1.Agents 长时自主运行，自我反馈、自我改进，产出稳定可靠。

更深入的自动化来处理复杂任务，反馈和优化循环真正转起来（3小时以上不中断），让睡前设定目标醒来验收工作成为可能。否则如果 Agent 经常执行中断，需要人类介入，那人类很难高并发的处理不同的任务，就会落入大家调侃的现象： Agent 运行时刷刷手机，然后不时抬头看看屏幕，检查“它还在干活吗”“要不要介入”。

2.人类只需深度参与设定目标和验收结果；无需过程的100%掌控，更多校验约束的遵循。

长时自任务 Agent 的产能爆炸，人类的工作负荷基本不可能校验 Agent 的每一项产出。人类应集中精力校验最初的目标和最终结果的准确性。过程中的细节校验交给专门的 Agent，给出报告，人类更多校验约束遵循情况，有没有遵循架构规范、接口规范等等。

这很像人类团队协作中管理者和员工的工作模式：管理者关注任务的两端，偶尔看下过程；如果员工是个新手就多看看，员工是成熟的老手就少看看。

这要求人类要转变思维，成为 Agents 的管理者，放弃一些过程掌控感。

比如 code review，AI 几乎短时间编写了100%的代码，我们 review 代码中的每一个细节几乎不可能，人类的阅读理解速度是线性的，而 AI 的生成速度是指数级的，像以前一样去 code review，那我们无疑会成为人 + AI 协作中的瓶颈。

回想一下，大模型时代之前我们为什么总是强调 code review ？就是因为 code review 总做不好；为什么做不好？因为读别人写的代码太耗精力。

读懂别人的代码，相当于跟着别人的思路在我们脑子里再写一遍。很多时候开发者耗时许久才思考出的一个巧妙解法（就几行莫名其妙的代码），作者本人不仔细讲一遍的话，他人几乎理解不了。没有背景对齐，review 只能流于表面（不认真 review 的原因还有一点就是：反正测试会兜底）。

从原理上推断，也没有别的办法，只能让另外几个 Review Agents 根据需求文档 / 架构规范 / 性能和安全等知识进行 review，我们负责检查综合的 review 报告，以及关键的分层和业务逻辑等。

当然，这不是一步到位的，前期还是要深入细节确认这些 Agents 工作质量，确定 Agent 给的“搞定了”不止是一个声明，还是一个证明。

AI Coding Harness 实践

整个实现过程基于 Cursor、Qoder、Claude Code 等 Coding Agent。我们的工作主要聚焦于 Agent 角色设计、各 Agent 的 Skills 编写，以及通过事件触发（Hooks）机制推动流程的流转与任务交接。

整体上看，这种模式与 Claude Code 的 Team 模式较为相似。但从当前体验来看，其真正的长时迭代与循环执行能力仍然有限，大多数场景仍停留在线性流程的一轮执行结束。随着 Agent 能力和基础设施的不断演进，这些 Coding Agent 未来势必会将 Harness 做得越来越完善。

但仍然有很多内容是在它们的控制之外，因为 Coding Harness并不等同于Coding Agent 本身，而是在其之上构建的一套方法论和自定义脚手架——它还涵盖知识管理、需求澄清、评估体系等能力，而这些能力会因具体业务场景和代码仓库的不同而有所差异。因此，Coding Harness 不仅包括 Agent 自身提供的能力，也包括围绕 Agent 构建的上层工程体系。

所以在实践中，我们不去复杂化整个流程，因为随着模型能力的提升，很多复杂化会变得过时，这条经验已经被反复验证了；凭直觉经验觉得必不可少的东西，我们才去构建能力（理性分析总是在模型的迭代中被一次次打脸）。

两条直觉经验：

第一，一条任务精简到最后必不可少三个环节—规划、执行、验证，除此之外的环节可能都是多余的复杂度。

Anthropic 的实践也是按照这个三环节来，设置 3 个独立职责的 agent，除此之外的 agent 设立会增加复杂度，而让任务变得更不可控，“能不协同就不协同” 其实是一个很好的经验判断依据。

第二，充分必要的信息传递，不足的信息会出现猜测幻觉，多余的信息会误导任务。

“目标要求信息”每个 Agent 都要知道，需要在每个 Agent 中传递。但 e2e 评估 Agent 不需要知道开发的实现思路文档，多了反倒干扰其评估执行，这很像我们实际工作中，如果 QA 同学过多了解开发同学实现思路和代码逻辑，e2e 测试就会被带偏，他们更关注 PRD 才是合理的。

下面展开下我们围绕四条共识方向、基于以上两条直觉，具体的实践路径。

上下文控制

这里主要做的是知识管理，记忆和上下文压缩等工作 agent 会内置掉。我们更多的控制 agent 除了关注代码库，还需要注意什么，团队的经验放在哪，哪些经验规则才是 agent 必须关注的。

首先，我们不应该尝试为 AI 构建一个大而全的产品文档或技术文档，作为全局知识让 AI 去注意。上下文是稀缺资源，大文档会挤掉真正重要的相关信息，所有东西都是重点等于没有重点。

另一个弊端在于，大而全的文档不具备长期的可维护性，极易腐化，进而与代码实际逻辑脱节。一旦失真，AI 就会基于错误的信息生成错误的内容，这种误导比没有文档更危险。

我们 Coding Harness 知识管理给出的是工作区的知识摘要，知识摘要会强制进入模型的 prompt，这样每次任务 agent 就不是在没有任何上下文的“零基础”状态的启动。

给出知识地图：一张地图，指向更深层“事实来源”。高度精炼、长期稳定且具备强制性，成为编码 rule 的一部分，让 AI 每次编码时都注意到，成为肌肉记忆。
知识目录和索引：渐进式披露，规范框架知识，而不是大而全的详细的说明书（指导太多等于没有指导），可维护性差，极易腐化，进而与代码实际逻辑脱节。
代码仓库作为单一事实来源：所有需要的信息都可以便捷获取到。好的代码即文档，细节知识不应存在于文档中，而应通过清晰的架构设计、标准化的接口定义和直观的逻辑流沉淀在代码库里。

我们实践项目的代码库中，.workspace 目录下定义了全局前后端规范（前后端架构规范、接口规范、编码规范、组件等等），整个项目的功能概览和关键文件索引（知识目录和索引）。这些框架类内容每次编码时，AI 都会注意到。作为我们整个应用的地图指引。

真正跟本次需求相关的知识文档，在 requirements/ 下，包含了需求文档、设计文档、开发计划、测试用例。所有这些文档都在代码仓库里。

专业 Agent 分工协作

随着模型能力越来越强，工具环境越来越稳定，agent 的 harness 会趋向于简单化。但需求规划，生码，测试反馈，这三个基础环节不会消失。而且每次环节完成后做必要产出物的交接，干净的上下文启动下一个环节工作这个也不会消失。所以我们也是围绕两点为 Agent 构建能力，且越简单越好。

Agent 专业化

将“设定目标”的planner agent******、******“执行工作”的 developer agent 与“判断质量”的 evaluator agent 分离，构建各自的人设，比如，这样的一个好处是开发Agent只管开发，消除它在给自己打分时往往偏正向的倾向，循环中最有用的结构性手段，毫无疑问，就是把“写的人”和“查的人”分开，让制作者远离检查者。

我们参考了 superpowers 的开发技能库，开发每个Agent 的专属技能，但做了一些精简整合，重点增加 skill 自动交接的能力。

上下文 Reset ： context reset，每个专家携带更少的无关信息，让每个 Agent 运行在上下文甜区（约上下文窗口的40%）。消除“上下文焦虑（context anxiety）”，当它们认为自己接近上下文极限时，会过早地开始收尾。

每个 Agent 唤起时拥有全新上下文，且每个子功能任务都会启动全新的 developer 和 evaluator 。基本上一个复杂任务会拆解成 5 到 10 个 task sprint。每个任务创建单独的子agent 开发测试，然后完成后创新的新的子agent 取下一个任务继续循环。

****Agents contract 握手：****通过文件通信，一个 Agent 写文件，另一个 Agent 读取后执行自己的工作，并在新的约定文件中回复，再交回前一个 Agent。developer 以约定好的 contract 为准构建功能，完成后再移交 QA。每个 agent 只关注需要关注的内容。主 agent 负责协议文件的流转和衔接。

每个 Agent 遵循主 Agent 的指令，只关注交接过来的文档和代码库来完成任务。

评估反馈

这非常关键，从实践来看，如果 agent 的产出不能被有效地评估，那么它就没有改进的方向，也就不会去改进。比如 agent 会反馈已经生成了所有功能，其实只是产出了表面的 UI 功能占位，逻辑都是缺失的。就像德鲁克说的“无法衡量的无法改进”。所以真正拉开差距的是增加一个挑剔专业 evaluator，能够基于真实效果给出客观明晰反馈。实践中具体实操是关注两端：

明确的初始目标：首选需求和目标必须是明确的，这个是 evaluator 评估的锚点，如果你追求确定性，那就把需求、设计全部明确掉。如果你追求发散创新，那也需要把你创新的期待、产品的品味具像化为明确的方向；如果实在不明确，可以和 agent 共创一个目标出来。总之，不要让 developer 开始干活时还要猜测你想要什么。
****客观的结果衡量标准：有了明确的目标，不要一句简单的让 evaluator 按照目标自我发挥去评估，要让它先根据目标拆解评估用例，拆解用例也不是自我发挥随意拆解，要给拆解方法，我们采用了 scale.ai 一篇论文里的方法： rubric 原则，下文会重点讲。

结构化执行回路

设计Agent 研发的工作流程： 需求项目规划->执行开发->测试验证，按照顺序逐步推进，控制阶段交付物的复杂度，这也是人类研发的流程，有流程更受控。
****人类审查（控制和放权）：****每个流程环节，人类都进行适度的审查，直到这个环节在 AI 任务完成质量逐步达到基准。但需求研究和产品规划，偏目标性质，需要更受控，会执行严格的人类审查；而执行过程，如自测、cr、端到端测试，交由 AI 检查，人类只对交付结果进行最终的审查。

结构执行回路，就是研发工作流的控制，为 agent 的执行添加约束机制，保障 agent 按照人类预期执行。比如，强行增加对于迭代轮次的要求，避免 Agent 过早结束的倾向；强行增加 developer 工作必须要 evaluator agent 的评估，避免 developer自我评估的自我表扬倾向。

整体控制流程如下：

用户发出需求
    │
    ▼
start-session hook 强制开启harness研发流程
    │
    ▼
主 Agent 创建研发流程状态机
    │
    ▼
Planner ─── clarify-requirements skill ──→ 与用户澄清（10 模块）
    │            write-prd skill
    │            write-tech-design skill
    │            write-dev-plan skill
    │            write-acceptance-criteria skill
    │            编写 test-cases.md / e2e-cases.md
    │
    ▼    ←─────────────── 大循环开始（macro_cycle.current_index++）
Developer（任务 N）
    │── implement-task skill（TDD）
    │── fix-from-report skill（修复时）
    │── systematic-debugging skill（难题时）
    │── verification-before-completion skill
    │── git commit 闭环（精确 add+ SHA 记录）
    │
    ▼
Evaluator（任务级）
    │── api-testing skill
    │── case_id 逐条 PASS/FAIL/SKIP
    │
    ├── FAIL → 回 Developer 修复（小循环，≤50次）
    │
    └── PASS → 主 Agent 校验 SHA → 下一任务
                      │
                      ▼ 所有任务通过
              Evaluator（全量 e2e_testing）
                      │── e2e-testing skill（浏览器 E2E）
                      │── ui_evidence 截图流水线
                      │── 多维度评估 + AI 读图
                      │
                      ├── replan_required=true
                      │       │
                      │       ▼
                      │   Planner sync-overview skill
                      │   → 更新概览 → replanning
                      │   → 回大循环顶部 ────────────────┐
                      │                                   │ 循环
                      └── replan_required=false ──────────┘
                              │
                              ▼
                          phase: done（需求完成）

提升应用环境对 Agent 的可读性

目的是把让 Agent 能感知环境改变环境，如果 agent 不能感知环境，它就不能看到真实的运行结果，也不知道报了什么错误。只能靠用户给的反馈，自己读代码看问题，这也要求****人在深度在回路，****与我们让 Agent 长时自我反馈自我改进的目标是违背的。

****UI 交互：****通过 playwright / puppeteer / CDP 接入 Agent 运行时，让 AI 能够查看执行结果。它能自己截图、查看 dom 快照，去分析交互问题。
****测试数据：****大部分情况下，agent 会自己生成测试数据进行测试。但一些测试账号，测试库的链接环境，需要我们为agent 预设好，比如需要为 agent 准备测试账号，并说明每个账号承担什么角色。
****CI / CD ：****为 Agent 集成测试环境的 devops 工具，让它能够自己完成CI / CD，这样后续自动化的飞轮才能高效的转起来。目前公司内部 devops 平台都陆续开放了 cli 的工具。
****运行过程：****日志、指标、链路追踪通过本地可观测性栈，让 AI 能够检查执行过程，结合测试反馈和日志修复问题。

过程发现的一个问题是，即使我们配置环境工具，agent 不一定每次都会去调用执行，比如我们e2e测试环节让它截图分析交互并和前一轮截图对比，agent 也不能一致遵循，我们就显式提供工具脚本，让 Evaluator 的全量/E2E阶段强制执行。

实际运行效果和问题

迭代1——

初期的时候，整个流程很难完整地跑下来，基本是一轮就结束，分析有以下几个原因：

1.没有显式指定一定要执行反馈迭代循环；

2.遇到环境操作问题会放弃评估。

迭代2——

对迭代1的问题，进行了如下改进：

1.主 agent 的指令中增加显式指定开启反馈迭代循环，要么达到要求的循环轮次，要么 AI 多轮判断后认为达到了目标；

2.遇到环境问题，首先如登录中断，在 plan 测试用例阶段，增加 ai 主动问询用户补充信息，有没有测试登录账号需要提供，在任务开启前把环境准备好。

改进后效果：

可以多轮迭代循环自动化跑起来，复杂任务基本能维持2个小时长时运行；但是产出的交互效果并不令人满意，更多地关注了基础功能实现，UI 交互都很原始。有时候还不如不用这套流程，直接提需求给 AI 开发来得好，分析原因如下：

我们对于测试要达成的效果，没有结构化的评测标准，更多是 AI 基于需求生成的测试用例的顺利执行，AI 缺少可量化的基准判断，自己主观发挥。

迭代3——

针对迭代2的问题，办法就是增加客观的结构化的评测标准。

我们采用了论文 Rubrics as Rewards (Scale AI, 2025) 中的评测方案：**将“好的标准”拆解为可独立评判的检查清单（Rubric）****，再通过 LLM-as-Judge 实现自动化评分。**

Rubric 的系统化评测框架方案基于以下四个原则生成评测维度，显著提升了评测的可解释性和质量，尤其可以应用在主观场景中。

_原则一：基于专家知识（Grounded in Expert Guidance）_

Rubric 必须反映领域专家的判断标准，捕捉正确性所需的关键事实、推理步骤和结论。_作为产研，AI Coding 领域我们本身就是专家。_

_原则二：全面覆盖（Comprehensive Coverage）_

Rubric 应涵盖生成质量的多个维度：事实准确性、逻辑连贯性、完整性、风格、安全性等，以及负向标准（Pitfall）——识别常见或高风险的错误。

_原则三：分级权重（Criterion Importance）_

Essential 关键必须满足的核心要求，如事实准确性 (权重 1)
Important 重要应当满足的质量要求，如逻辑完整性 (权重 0.7)
Optional 可选锦上添花的额外加分项，如风格优雅 (权重 0.3)
Pitfall 陷阱必须规避的严重错误，如合规风险 (权重 0.9)

_原则四：自包含可评判（Self-Contained Evaluation）_

每条 Rubric 应当独立可操作——无论是人类评审还是自动化 Judge，都能在不依赖外部上下文的情况下独立判断该条是否满足。这要求 Rubric 条目的描述足够清晰、具体、无歧义。

e2e 测试的 Rubric **设计：**评测划分为4层，前两层偏功能，后两层偏表现，但它们之间有交叉验证的关系

L1: 功能正确性（核心层）

这是整个评测体系中权重最高的一层，AI 生成的代码是否真正实现了用户请求的业务逻辑。

这一层需要拆解为几个子维度：

数据逻辑——数据的增删改查是否正确。比如用户说“实现一个待办列表”，那添加一条待办后列表数量应该 +1，标记完成后状态应该变更，删除后应该从列表消失。这些是可以通过操作 + 断言来自动验证的。
状态管理——组件间的数据流是否正确。父组件传给子组件的 props 是否生效、全局状态变更后所有订阅组件是否同步更新、表单输入的值是否正确绑定到提交逻辑。
条件逻辑——分支判断是否符合需求。比如“当库存为 0 时禁用购买按钮”，那就需要测试库存 >0 和 =0 两种情况下按钮的行为差异。
API 集成——如果涉及后端交互，请求是否发送了正确的参数、响应数据是否正确渲染、loading/error 状态是否正确处理。

Rubric 设计示例（以「实现一个带筛选的用户管理列表」为例）：

类别	条目
Essential	用户列表是否正确渲染了全部数据（条数一致、字段无缺漏）
Essential	搜索筛选后列表是否只显示匹配项（而非仍显示全量数据）
Essential	新增用户后列表是否自动刷新且包含新记录
Essential	删除操作是否真正从数据源移除了记录（而非仅隐藏 DOM 元素）
Pitfall	连续快速操作（如连续点击删除）是否会导致数据不一致或重复请求
Pitfall	空数据/无搜索结果时是否有合理的兜底展示（而非空白或报错）

自动化方式：浏览器自动化执行操作序列，每步操作后同时检查DOM 状态和底层数据状态（通过 API 或直接读取 store），两者交叉验证。这是和纯 UI 测试最大的区别——不能只看界面变了，还要确认数据真的变了。

L2: 健壮性（防御层）

功能在正常路径上能跑通只是及格，真正的质量差异体现在异常路径上。

边界输入——空字符串、超长文本、特殊字符（XSS payload）、负数、零值、极大值。AI 生成的代码非常容易忽略这些边界情况。
错误处理——网络断开时是否有错误提示而非静默失败、必填字段为空时是否阻止提交并提示、API 返回 500 时页面是否有降级处理。
并发与时序——快速连续点击是否会重复提交、异步操作是否有 race condition、组件卸载后异步回调是否会导致 setState on unmounted component。

Rubric 以 Pitfall 和 Important 为主：

类别	条目
Pitfall	输入\alert(1) 是否会触发 XSS
Pitfall	表单提交按钮在请求进行中是否禁用（防重复提交）
Important	必填字段的校验是否在提交前执行并有明确提示
Important	网络异常时是否展示用户可理解的错误信息

自动化方式：构造异常输入数据 + 模拟网络故障（如拦截请求返回 500），然后检查页面行为。

L3: UI 呈现（表现层）

页面渲染是否正确、布局是否合理、组件是否完整展示。截图交给 LLM，配合 Rubric 评判视觉效果。

类别	条目
Essential	页面完整渲染，无白屏/布局塌陷/元素缺失
Pitfall	无元素重叠遮挡、文字溢出截断
Important	布局层次清晰，信息密度合理
Important	响应式适配（移动端/桌面端均可正常使用）
Optional	视觉风格一致，符合设计规范

L4: 交互体验（体感层）

用户操作的流畅感和符合直觉程度。

类别	条目
Important	关键操作（保存、删除）是否有明确反馈（toast/状态变更）
Important	加载状态是否有 loading 指示（而非页面冻结）
Optional	动画过渡是否平滑、操作是否可撤销
Optional	键盘导航和无障碍访问是否支持

各层之间的关系

四层不是平等权重的，建议的权重分配是：这个根据对产品在不同视角的关注度。如果对交互的创新型要求高，希望AI更多的发挥，就可以增加UI交互的权重。

总分 =  L1(功能正确性) ×0.40
     +L2(健壮性)     ×0.25
     +L3(UI呈现)     ×0.20
     +L4(交互体验)   ×0.15

改进后效果

我们在一个完整的评测问卷系统进行了实测，具体功能包括：

1.用户注册，问卷创建，问卷管理，问卷反馈，问卷统计。

2.问卷支持：单选题，多选题，文本题，矩阵题(需要支持配置)，打分题(显示星星的效果，支持半分)，NPS。

3.题目之间支持，题目联动(根据选项进行题目的显影)。

在Cursor中，从0到1完整自动化跑了5个多小时，4轮评测迭代反馈循环，自动化执行没有中断。Rubric 增加进来后效果明显。

第一轮评估改进评分3.35，全方位都比较差，还白屏	第二轮评估改进评分提升到了4.11，功能和UI维度提升明显

第三轮评估改进评分提升到了4.52，每个维度继续小幅提升	第四轮评估改进评分提升到了4.66，边际效果已经很低，可以退出循环

而最终的效果在交互和完成性方面，已经比迭代2 有了很大的提升。

比如迭代2 虽然 AI 输出反馈功能已实现，其实 50% 是页面上仅做了功能占位，实际逻辑根本没有实际实现；而本轮迭代后，功能逻辑基本都已实现。界面和交互，也比上一迭代有较大提升，但界面样式还是比较丑，有些布局错位，无法达到生产级。

迭代4——

关于迭代3的交互 UI 丑的问题，我们分析有如下原因：

1.目标端-“知道了做什么”但不知道“做成什么样子”

生成的prd里只定义了做什么，没有“做成什么级别”
没有参照物机制，developer不知道“好看”长什么样
对于创新或设计类需求，没有“品味共创”的过程

2.评估端-有 rubric 框架，但不够挑剔和细致

偏向功能性验收，缺乏品质性验收
评估粒度不够，比如“布局合理”这种条目太模糊，无法驱动有效改进
缺少锚点评估，没有和目标锚点的对比机制

我们针对性进行了两端改进：

1.目标端：增加品质保证机制，在需求澄清阶段增加“品质锚定”环节，让developer开工前就有具象化的品质标杆，新增 quality-vision.md产物

定义品质定位：MVP / 精打磨 / 生产级
定义参考锚点：正面参考的截图/URL/竞品 + 注解"好在哪"; 反面参考的不想要的风格/模式 + 注解"为什么不好"
设计意图：风格关键词，配色方向，信息密度，交互范式等等

2.评估端： rubric 精细生成方法论 + 挑剔评估专家，让 rubric 本身足够精准、evaluator 足够挑剔

rubric 从需求拆出具体条目******，******并和 quality-vision.md锚定
增强 evaluator 的挑刺能力******，******增加 UI 设计专家视角、UX 交互专家视角的逐项检查清单。

改进后效果

和迭代3 同样的需求，初版需求发出后，agent 会进行更加更加细致的需求澄清，首轮需求澄清从原来 10 来道增加到了 31 题。

除了基础的目标、功能、业务流程、角色权限、异常/边界外，还涵盖了非功能性的并发、安全合规、多端适配，最关键的包含了品质期待的品质层级、品质红线、参照产品等等，需求更加明确。

对于参照产品，例如我比较喜欢https://fireworks.ai/ 的交互样式，我就把网址给到 agent 作为参照，基本在每个设计文档里都会 fireworks 的解读约束，其中 quality-vision.md 中的约束如下：

第1轮效果：整个问卷的功能和逻辑是基本完备，交互样式也比之前好看了很多，问卷创建、单选多选矩阵等题型选择、问卷预览、问卷发布、答题、统计分析的主链路通畅，其中注册登录和问卷填写页面还实现了移动端适配。

后续进行了7轮评估改进迭代，连续两轮评估评分超过设置0.95目标，整体结束任务。

每轮 evaluator 都会进行 web e2e测试和页面截图进行理解分析。

多轮改进后，页面ui交互上细节有很大改善，如关窗文案、菜单选中样式、答题样式、分析报告、提交后刷新、结果页状态，逻辑上修复软删逻辑、只读分析、提交防重、必填校验等等。

其实从4轮后边际迭代效益已经很低，基本没有大的改善，但还是会耗费很长时间进行改进迭代。这也是后续优化方向，如何在边际成本很低的情况下尽早结束循环，不让 AI 为了改进而改进。

这个案例，AI 全程自动化执行了 7 个小时，除了最初的目标澄清，后续过程人类没有一点参与，消耗 2.2 亿 Token，其中 2.1亿命中 cache，初步达到我设定的两个目标。

和我之前纯 vibe coding 的方式开发的一个桌面 app 比较，vibe coding 基本一次开发一个特性（本实践一次把一个完成产品开发好），一个特性从需求到开发到测试修复 bug 完毕，约需 2～4 个小时（视需求大小），完整体量的 app 开发大概耗费了 30～40 小时（当然因为人在一步步调试，所以成品比本实践要精致）。

_本实践基于的是cursor，主 agent 模型用的是旗舰模型，每个子 agent（包括 planer、developer、evaluator）用的都是 cursor 自己微调 composer 2 模型。侧面说明了：模型能力到达一定水位后，agent 的效果发挥，harness 会占非常大的权重。_

Skills 开发 Harness 实践

Skills 的开发流程跟 AI Coding 本质是类似的，对于像在悟空里提供的官方认证的 Skills ，它包含了 Skill 本体和 Tool 的开发。我们 Skill 开发 Harness是对根据 Skill Prd 生成的 Skill 进行评测改进循环，直到达到设定的目标或循环轮次，基于的 Agent 仍然是Cursor/Qoder/Codex 这些 Coding Agent。

驱动 “Skill 开发” 能持续循环改进的核心要素：

多 agent 协作

单一 agent 很难开启多轮循环，有非常明显的过早结束倾向。
对效果基准和迭代轮次的强制要求

必须“达到多少分”或“至少执行多少轮”，强制避免 AI 过早放弃的倾向。
效果基准的判断科学化

使用 Rubric 评测方法，评估不再凭感觉，强制避免 AI 评估过于正向迎合的倾向。

我们构建了一个简易的平台，来结构化可视管理整个过程：

******发布迭代改进任务：******平台发布评测改进任务，支持设置循环轮次和退出基准。
******Agent 认领任务并执行：******在 agent 中认领任务并执行，agent 将评估改进循环的执行过程上传到平台。
******查看迭代过程信息：******评测报告和改进过程。
******检查最终结果：******查看Skill迭代的版本差异，下载最终 skill 包。

以我们上架悟空的一个 Skill 为例，展开下整个过程：

1.为初版 Skill 创建评测任务

评测平台上，上传 Skill 的 zip包，维护基础评测集（如有），并设置得分阈值目标和迭代轮次，提交后会生成待执行任务。

得分域值和轮次设定，目的是不要让 AI 无休止地迭代下去，达到效果目标，或者 AI 已经过拟合再跑下下去也没法提升，及时结束。评估标准仍然是采用 Rubric 方案。

2.拷贝任务，粘贴到 Agent 对话框执行任务

复制出的内容如下：

_阅读_https://ai-test.xxx.net/skill-eval-setup.md?api_key=yyy，对任务

2f8bf052-ba2a-4ac0-9fea-be123121sss16a 创建评测实例并执行。

贴到Cursor / Qoder / Claude Code等的对话框发送即可开始迭代循环，但切记 Agent 工具要具备可以创建 “子 Agent” 的能力，不然主调度 Agent 和执行 Agent 都是同一个，带来的问题就是同一 agent 评估自己的执行工作，上下文污染，会非常倾向于正向评价，过早结束。

链接中的 skill-eval-setup.md 一套评测驱动的 Skill 迭代开发指令（本身也是一个 Skill），它的核心能力是编排三个角色分离的 Agent 协作完成评测闭环：主 Agent 负责调度编排，执行 Agent 负责装配 Skill 并以真实 Agent 身份处理用户请求，评估 Agent 基于 Rubric 对执行结果独立判分。三者之间严格信息隔离——执行者不可见评测标准，从根本上避免“自出题、自执行、自判卷”导致分数虚高的问题。

整个流程为：Agent 根据 SKILL.md 内容自动生成 12-20 个结构化测试用例（含正样本和 near-miss 负样本），每个用例附带 7-15 条实例级 Rubric 检查项；随后逐个派遣执行者真实运行，评估者独立判定每条 Rubric 的通过与否并给出证据；平台自动聚合评分，未达标时 Agent 根据结构化改进建议优化 SKILL.md，提交新版本进入下一轮循环，直到评分超过阈值或达到最大迭代轮次后自动退出。全程数据实时上报到可视化平台，支持人类随时查看评测详情和版本差异。

3.迭代改进循环完成，通知用户查看报告，并下载最新 Skill 包上架

最终用户在平台查看评测详情、迭代改进详情，迭代循环人类不参与，这是一条非常成熟的链路。

评测概览每轮评估改进用例执行情况、评估情况、以及skill改进版本对比等	user case 的评测细节每条uc在rubric原则下评估详情和加权总得分

Skill 每轮改进的版本对比	最终获得优化后的Skill分发出去

4.最终效果

一次自动化的多轮反馈改进循环，20～30分钟左右，同样效果，相当于原来测试和开发各投入半人日的工作，提效明显。

总结

我们的 Harness Engineering 覆盖的项目主要是新产品的 0 到 1 阶段，以及老产品中新模块的 0 到 1 开发。OpenAI 和 Anthropic 公开分享的案例也大多集中在新项目场景。对于拥有十年以上历史的老项目、遗留代码以及复杂微服务系统，目前行业内还缺乏成熟的成功案例。

不过，新应用以及前后端一体化（或前后端分离但架构相对简单）的项目，在实际业务中仍占据相当大的比例。如果前后端分离仅仅是出于岗位划分的历史原因，而非系统架构的实际需要，建议优先整合为统一代码库；如果现有 DevOps 流程暂时无法支持，也可以在 IDE 开发阶段先进行逻辑层面的统一管理，从而获得接近前后端一体化的开发体验。对于这类项目，Harness Engineering 带来的效率提升非常明显。

与此同时，应用交互层本身也在向更加智能化的交互方式演进。或许可以借助这波 AI 浪潮，不破不立，利用 AI 快速完成陈旧系统的重构，升级为更加 AI 友好的架构。

话说回来，模型和 Agent 的能力迭代速度极快，我们今天构建的部分能力，未来可能很快变得冗余，甚至产生负作用。例如围绕“多轮迭代要求”设计的约束机制，以及一些高度定制化的 Skills。

我们始终认为，Agent Loop 应该越简单越好，尽可能减少人为植入的特定规则。

但无论未来如何演进，以下三点依然至关重要：

第一，为 Agent 提供完善的环境支持，包括工具、充分且必要的数据，让它具备可读、可分析、可操作的能力。

第二，专业化分工。多个职责清晰的 Agent 协同工作，通常优于单个 Agent 在超大上下文中完成全流程任务。

第三，上下文控制。无论 Agent 的记忆管理、上下文传递和压缩能力发展到什么程度，我们提供给 Agent 的初始上下文依然极其关键。

当目前的 Coding Agent 能力尚不足以支撑复杂任务时，我们便可以围绕上述三点构建补偿能力，让 AI 在长时间运行过程中保持稳定性和准确性，而这正是本文所讨论的 Harness Engineering 的核心价值所在。

欢迎留言一起参与讨论~