Harness Engineering长程自动化AI开发最佳实践

2026-06-11阅读 0热度 0

skill

这篇文章要聊的，是AI Agent自主演进背后的一套核心工程体系——Harness Engineering。说人话就是，通过约束机制、反馈闭环、工作流编排，再加上一套结构化的评估方法，让Agent在长时间运行的过程中，能够自己迭代自己、自己优化自己，不用人一直盯着。

先亮个结论，再慢慢展开。

01 Harness Engineering 是什么？

Harness Engineering，本质上是在给Agent搭建一个能持续感知、持续获得反馈、持续自我优化的环境。

它通过约束、反馈闭环、工作流编排、效果评估以及持续的优化循环，把Agent的运行变成一个可观察、可控制、可迭代的系统工程。它的目标是，在那些长流程、复杂场景下，Agent不光能干活，还能自己感知到干得怎么样、哪儿能改进，然后调整策略，把结果越做越好。

Harness Engineering 和 Prompt Engineering、Context Engineering 不是非要二选一的关系。它们更像是一个发展阶段和嵌套关系的问题——随着AI能力越来越强、基础设施越来越完善，大家关注的重心自然而然就升维了。

02 Harness Engineering 聚焦方向

目前，Harness Engineering 的主要实践集中在AI Coding领域（当然，任何一个AI应用都自带某种形式的Harness）。2026年2月底开始，这个话题热度上来了，OpenAI、Anthropic、Stripe这些团队在2、3月份都分享过一些实践。总结下来，大家主要聚焦在这么几个方向：

上下文控制：Agent得能刚刚好拿到自己需要的上下文，不多不少。
专业Agent分工协作：让不同的Agent专注于自己的领域，只看自己需要的上下文，比用一个通用Agent包办所有链路要靠谱得多。
评估反馈：真正拉开差距的，是给Agent配一个足够挑剔、能感知运行环境的评估模块。它得清楚目标是什么，还得知道怎么客观、结构化地去评估结果。
结构化执行回路：适度编排Agent的工作流，在关键节点加入人工审查，重点看看目标和结果对不对。
应用环境对Agent的可读性：持续把应用本身（比如UI、日志）暴露给Agent，让它能检查、能验证、能修改。

03 我们的实践

我们在AI Coding和Skills开发这两个方向上做了探索，设定了两个核心目标：

目标一：让Agents能长时间自主运行，自己反馈、自己改进，产出稳定可靠。

更深入的自动化来处理复杂任务，让反馈和优化的循环真正转起来（3小时以上不中断），这样才能实现“睡前设定目标，醒来验收成果”。否则，如果Agent动不动就中断，需要人类介入，那就很难同时处理多个任务，变成大家调侃的那个状态：一边刷手机，一边时不时抬头看看屏幕，心里犯嘀咕——“它还在干活吗？我是不是该插手了？”

目标二：人类只需要深度参与设定目标和验收结果，不用100%掌控过程，更多是去检查约束是不是被遵守了。

长时间运行的自主Agent，产出量会很大，人类的工作负荷根本不可能去校验每一项产出。所以，人类应该集中精力确认最初的目标和最终的结果是否正确。过程里的细节校验，交给专门的Agent去干，它们给出报告，然后人类更多地去检查约束的遵循情况，比如架构规范有没有被遵守、接口规范对不对。

这其实很像人类团队里管理和执行的模式：管理者关注任务的两头，偶尔看看过程。如果员工是个新手，就多看几眼；要是老手了，就少盯着点。这就意味着，人类得转变思维，学会做Agents的“管理者”，放弃一部分对过程的掌控感。

举个例子，代码审查。AI能在很短时间内写出100%的代码，我们要是逐行去review，几乎不可能。人类的阅读速度是线性的，AI的生成速度是指数级的，还像以前那样review，我们无疑会成为人机协作中的瓶颈。回想一下，大模型时代之前，我们为什么总是强调code review？不就是因为它老做不好吗？为什么做不好？因为读别人写的代码太费脑子了。读懂别人的代码，相当于跟着他的思路在自己脑子里重新写一遍。很多时候，开发者花了好长时间想出来的一个巧妙解法（就那么几行让人费解的代码），不仔细讲一遍，别人几乎理解不了。没有背景对齐，review就只能流于表面。

这么一想，也没别的办法，只能让另外几个Review Agents，根据需求文档、架构规范、性能和安全知识去做review，我们负责检查综合的review报告，以及关键的分层和业务逻辑。

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

04 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的实践也是按这个三环节来，设置三个独立职责的Agent。再增加别的Agent，只会增加复杂度，让任务变得更不可控。“能不协同就不协同”，其实是一个很好的经验判断依据。
第二，信息传递要充分且必要。信息不足，Agent会猜测，产生幻觉；信息多了，反倒会误导任务。比如，“目标要求信息”每个Agent都要知道，得在它们之间传递。但端到端评估的Agent，不需要知道开发的实现思路文档，多了反倒干扰它做评估。这跟我们实际工作很像，如果QA同学过多了解开发同学的实现思路和代码逻辑，端到端测试很容易被带偏，他们更关注PRD才是合理的。

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

上下文控制

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

首先，不应该尝试给AI构建一个大而全的产品文档或技术文档，作为全局知识让它去关注。上下文是稀缺资源，大文档会挤掉真正重要的信息。什么都想强调，等于什么都没强调。

另一个坏处是，大而全的文档很难长期维护，很容易腐化，然后和代码的实际逻辑脱节。一旦信息失真，AI就会基于错误的信息出问题，这种误导比没有文档还危险。

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

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

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

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

专业Agent分工协作

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

Agent专业化：

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

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

上下文清零：Context reset。每个专家携带更少的无关信息，让每个Agent运行在上下文的“甜区”（大约是上下文窗口的40%）。这样可以消除所谓的“上下文焦虑”——当Agent觉得自己快到上下文极限时，会过早地开始收尾。

每个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任务完成质量达到基准线。但需求研究和产品规划，偏目标性质，需要更受控，会执行严格的人工审查。而执行过程，比如自测、代码审查、端到端测试，就交给AI去检查，人类只对最终的交付结果做审查。

结构化的执行回路，就是研发工作流的控制。它为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
│── gitcommit闭环（精确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：

初期，整个流程很难完整跑下来，基本一轮就结束了。分析原因有两个：一是没有显式指定一定要执行反馈迭代循环；二是遇到环境操作问题，Agent会放弃评估。

迭代2：

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

在主Agent的指令中，增加显式指定，开启反馈迭代循环。要么达到要求的循环轮次，要么AI在多轮判断后认为达到了目标。
遇到环境问题，比如登录中断，在plan测试用例阶段，增加AI主动向用户询问补充信息的流程，比如“有没有测试登录账号需要提供？”，在任务开启前把环境准备好。

改进后的效果：可以多轮迭代循环自动化跑起来了，复杂任务基本能维持2小时的长时运行。但是，产出的交互效果并不令人满意，Agent更多地关注了基础功能的实现，UI交互都很原始。有时候甚至觉得，还不如不用这套流程，直接提需求给AI开发来得快。分析原因：我们对测试要达成的效果，没有结构化的评测标准，更多是AI基于需求生成的测试用例来测试，AI缺少可量化的基准判断，完全是自己主观发挥。

迭代3：

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

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

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

原则一：基于专家知识。 Rubric必须反映领域专家的判断标准，捕捉正确性所需的关键事实、推理步骤和结论。在AI Coding领域，我们自己就是专家。
原则二：全面覆盖。 Rubric应该涵盖生成质量的多个维度，比如事实准确性、逻辑连贯性、完整性、风格、安全性等，还要包括负向标准（Pitfall），用来识别常见或高风险的错误。
原则三：分级权重。
- Essential（关键）：必须满足的核心要求，如事实准确性（权重1）。
- Important（重要）：应当满足的质量要求，如逻辑完整性（权重0.7）。
- Optional（可选）：锦上添花的额外加分项，如风格优雅（权重0.3）。
- Pitfall（陷阱）：必须规避的严重错误，如合规风险（权重0.9）。
原则四：自包含可评判。 每条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	输入<script>alert(1)</script>是否会触发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

改进后的效果：

我们在一个完整的评测问卷系统上做了实测，具体功能包括：用户注册、问卷创建、问卷管理、问卷反馈、问卷统计。问卷支持单选题、多选题、文本题、矩阵题（需要支持配置）、打分题（显示星星效果，支持半分）、NPS。题目之间支持题目联动（根据选项进行题目的显隐）。

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

第一轮评估改进： 评分3.35，全方位都比较差，还白屏。

第二轮评估改进： 评分提升到了4.11，功能和UI维度提升明显。

第三轮评估改进： 评分提升到了4.52，每个维度继续小幅提升。

第四轮评估改进： 评分提升到了4.66，边际效果已经很低，可以退出循环。

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

迭代4：

针对迭代3交互UI丑的问题，我们分析原因：

目标端： Agent“知道了要做什么”，但不知道“要做成什么样子”。
- 生成的PRD里只定义了做什么，没有定义“做到什么级别”。
- 没有参照物机制，developer不知道“好看”长什么样。
- 对于创新或设计类需求，没有“品味共创”的过程。
评估端： 虽然有Rubric框架，但不够挑剔和细致。
- 偏向功能性验收，缺乏品质性验收。
- 评估粒度不够，比如“布局合理”这种条目太模糊，无法驱动有效改进。
- 缺少锚点评估，没有和目标锚点的对比机制。

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

目标端： 增加品质保证机制。在需求澄清阶段增加“品质锚定”环节，让developer开工前就有具象化的品质标杆。新增了quality-vision.md产物。
- 定义品质定位：MVP / 精打磨 / 生产级。
- 定义参考锚点：正面参考的截图/URL/竞品 + 注解“好在哪”；反面参考的不想要的风格/模式 + 注解“为什么不好”。
- 设计意图：风格关键词、配色方向、信息密度、交互范式等。
评估端： 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亿命中了缓存。初步达到了我们设定的两个目标。

跟之前用纯Vibe Coding方式开发的桌面App相比，Vibe Coding基本上是一次开发一个特性（而这次是一次把一个完整的产品开发好）。一个特性从需求到开发到测试修复bug完毕，大约需要2到4个小时（看需求大小）。完整体量的App开发大概耗费了30到40个小时（当然，因为人在一步步调试，所以成品比这次实践的要精致）。

这次实践基于Cursor，主Agent用的旗舰模型，每个子Agent（包括Planner、Developer、Evaluator）用的都是Cursor自己微调的Composer 2模型。这侧面说明了一个问题：当模型能力达到一定水平后，Agent效果的发挥，Harness会占非常大的权重。

05 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分钟。同样的效果，相当于原来测试和开发各投入半人日的工作，提效非常明显。

06 总结

我们的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的核心价值所在。