Harness 工程实践：如何让 Agent 完成自主迭代

本文作者肖汉松前言一个人一天最多跑一次迭代实验但每周上百个 badcase 追着我们跑这是团队今年年初的状态。我们负责一个服务大规模用户的线上业务 Agent日常工作就是去优化它的回答效果发现 badcase、分析原因、修改 prompt跑评测开实验。问题在于修改 prompt 之后评测一次起码要两三个小时评测完还要分析为什么答不对琢磨 prompt 怎么改一天最多也就跑一次迭代实验而线上 badcase 的涌入速度远快于我们人工修复的速度。往往是这边刚修完一批下一批已经堆起来了。虽然我们已经在用 AI 帮我们分析 badcase、修改 prompt 了但是中间很多步骤还是人工在串联比如代码发布、启动评测等我们成了帮 AI 点击页面按钮的工具人。正当我们为 badcase 的迭代速度发愁的时候OpenAI 在春节期间提出了 Harness 工程的实践一种 agent-first 的研发模式不只是让 AI 生成代码而是把整个开发生命周期都交给 AI 管理。受此启发我们意识到可验证的评测集驱动的 Agent 优化也可以让 AI 去完成。于是我们开始了 Harness 工程的尝试最终让 AI 能够自主运行 17 个小时完成了 16 轮的迭代实验最终有一轮的改进通过人工复核并上线成功上线了实验。这篇文章会复盘整个 Agent 自主迭代的搭建过程包括踩过的坑和解决方案希望对大家实践 Harness 工程有帮助。01 Harness 工程真正要补齐什么如果把我们工程师的开发工作做一个抽象处理基本流程如下Harness 工程的核心就是把原来这些流程由人完成的过程变成人 AI 的过程把软件研发从“人手写代码”转为“人定义目标、约束和验收Agent 执行、验证、修复和交付”。所以 Harness 工程的研发流程中人与 AI Agent 的关系如下我们不难发现80% 的工作都是 Agent 解决了。人负责最难的部分即定义问题和验收。理想状态是这样但真正落地的时候我们发现至少要补齐三件事。第一关研发工具要变成 Agent 可调用的能力为了让 Agent 能够完成这种迭代首先我们需要给 Agent 提供各种工具让它能够完成以下几项任务但现实的情况就是这些工具目前都只有 GUI 界面没有给 AI 提供对应的 MCP 或者 CLI。为了解决这些问题我们跟相关平台的同学合作代码部署方面向内部研发平台的同学提需求他们提供了一整套可以让 AI 部署代码的工具评测方面评测平台团队给我们提供了发起评测、获取评测结果的 skill。所以我们在给模型发起任务的时候就可以在 prompt 里面把这些信息告诉它然后它就能使用这些工具去解决问题了相关的 prompt 如下## 固定配置与约束- 固定配置 - 环境预发 - 指定userid - 代码库: - 分支: 不要去看其他分支 - 任务用plugin / skill - 代码部署相关 skill构建、部署能力 - 评测相关 skill发起评测、下载结果、查询进度 - 结果分析 skill仅子 agent 使用 - 评测平台配置 - api_key - domain_id - 评测任务 id - 创建人工号第二关长程任务要防止早停、空转和上下文打爆因为 AI 经常会自己停下来但 Harness 工程的目标是让它自主完成全部的工作。所以我们在 prompt 里面有几个比较核心的技巧- 执行约束 - 不允许向用户提问必须自行判断并持续执行。 - 持续执行直到任务完成禁止早停、禁止早停、禁止早停 - 如果轮询、部署、调用等持续出现相同异常不能机械重试必须先分析并尝试解决 - 一次只专注做一件事在让 AI 能长时间运行之后另一个问题随之产生单个 Agent 的上下文有限很容易就被“打爆了”。所以我们使用了父子 Agent 的模式在执行过程中把一些比较复杂的任务拆分出去让子 Agent 去做。具体可以参考下方 prompt 中的第5 步。## 任务描述执行 20 轮以下步骤1. git 推送使用当前分支 当前 commit 构建并部署服务...2. 配置 指定userid 到当前迭代的白名单里...3. 运行评测并下载评测结果...4. 基于评测实例结果进行报表拆分、条目过滤与总分计算...5. 分析结果并决定本轮 prompt 策略必须委托子 agent- 新建 1 个子 agent 负责本模块 - 模型XXX - 推理强度高- 父 agent 不要 fork 当前上下文只提供必要说明 - 子 agent 必须要加载使用结果分析 skill - 告知 当前所在轮次 和 champion 所在轮次 - 给子 agent 的指令应该符合正确的角色视角不能沿用对父 agent 指导的角色视角给指令。6. commit continue- git commit- 回到第 1 步开始下一轮第三关评测闭环要防止 reward hacking 与策略退化在最初实践时我们发现如果让它不停地迭代模型会非常容易产生 reward hacking。它会尝试把所有的 edge case 写入硬编码增加很多 few-shot 规则试图以此通过测试这其实就是作弊。下面给大家看一个 reward hacking 的例子某个 case 的扣分原因写着“回答里编造了一个‘降低 xx%’这类无来源的百分比结论”。然后模型为了能在这个 case 上拿分它就会在 prompt 里面写下一条针对性的硬规则- 没有原文来源时不得虚构降低 xx%最有效等表述可以看到为了能在这个 case 上拿到分它直接把这条只针对单个 case 的规则写进了 prompt这就是非常典型的 reward hacking。所以我们必须打造一个机制来防止它产生 reward hacking这里我们借鉴了机器学习中训练方法把训练集和验证集分开。在训练集上跑的结果 AI 能看到问题、回答、打分理由、得分验证集就只能看到得分这样可以有效地防止它写一些硬规则去通过这个测试。此外在这个多策略优化的过程里我们发现很难保证 AI 提出的策略每次都能往前迭代有时也会退步以至于它有可能沿着错误的路径一直走到“死胡同”。为了解决这个问题我们设计了 champion-challenger 机制这其实就是一个“打擂台”的机制历史上最好的一轮放在擂台上作为基准。具体的迭代流程如下接下来AI 会继续从新的冠军策略出发进行下一轮优化。这种机制保证了每一次迭代的经验都能保留下来让 AI 在一个比较稳定的基础上进行迭代而不会一条路走到黑。具体 prompt 如下如果不是第一轮判断上一轮 challenger 是否足以替代 champion至少要做- 总览粒度分析 - 对比 challenger、champion 的总分和各指标分变化- 得分行粒度分析case指标粒度 - 对比 challenger、champion 的关键得分行得分升降明显分析得失和原因- 采信结果时必须同时看 - 结合训练/验证得分判断是否过拟合 - badcase 模式是否真的发生变化 - 样本数较少本身有噪声若总分或单维只有微小变化不作为有效信号 - 过滤量是否异常超过35%02 一个例子AI 如何优化我们的业务 Agent上面讲的是 Harness 工程真正要补齐的能力。接下来我提供一个具体运行的例子让大家去直观地看到 AI 自主迭代的过程。在第一轮迭代的时候它发现了下面这个问题**模式 1领域外任务仍被“领域身份”带偏出现拒答、跑题、先追问后不给结果** 典型 case - 年底工作月报...300-500字全面性/易读性/实用性/正确性全为 0直接拒写并转回本领域话题。 - Vivo手机最新款是哪一款要多少钱全面性 0实用性 0直接因身份不符回避。 - 帮我写一篇关于春天的文章、帮我写一篇关于冬天的文章500字连续拒绝写作。 - 扮演我的老邻居跟我唠唠家常说说最近的趣事拒绝角色扮演。 - 以一只宠物狗的视角讲述主人外出一天的故事。先追问基调不直接给故事。 - 高速公路 道路清雪 采取的安全措施 20字内容正确但没遵守“20字”硬约束导致全面性/实用性掉分。结论 - 当前 prompt 把“领域助手身份”约束得过硬导致安全的领域外任务被错误拒绝或者明明该直接产出结果却先澄清、先设边界、先讲身份。 - 这类失分不需要增加知识只需要 **纠正任务分流逻辑**。这里找个例子看一下 Agent 具体的回复用户扮演我的老邻居跟我唠唠家常说说最近的趣事Agent以“我更擅长本领域的问题”为由婉拒了角色扮演并强行把话题拉回到自己的专长领域没有直接满足用户想唠家常的需求。可以看到Agent 的领域身份 prompt 约束过强导致它拒答用户的问题然后在评测集上就开始丢分了。当我们让 Agent 去执行这个任务的时候它会根据评测结果发现这些问题并给出相应的解法核心改动- 在 system prompt 明确 - Agent 以自身领域为专长但面对安全、明确的领域外问题也要正常帮助。 - 对明确的领域外任务优先满足字数、格式、风格等硬约束。根据上面的分析AI 修改了代码中的 prompt仅展示本轮真正新增的那条任务分流规则在 system prompt 中新增一条任务分流规则你以自身领域为专长但面对安全、明确的领域外问题也要正常帮助不要因为身份设定拒答、跑题或强行把话题拉回本领域。等修改完成之后进行第二轮评测然后再去分析。### 明确有效的收益领域外任务的拒答/跑题被修复 代表性涨分 case - 年底工作月报...300-500字0.1 - 1.0 - Vivo手机最新款是哪一款要多少钱0.55 - 1.0 - 帮我写一篇关于春天的文章 / 冬天的文章500字0.4 - 1.0 - 扮演我的老邻居跟我唠唠家常说说最近的趣事0.55 - 1.0 - 以一只宠物狗的视角讲述主人外出一天的故事。0.55 - 1.0 - 某人从1楼走到4楼用了48秒...0.1 - 1.0 结论 - round 1 的核心 badcase 模式“安全的领域外任务被领域身份带偏”在 round 2 中确实发生了实质变化。 - 这部分信号稳定、泛化方向也合理值得保留到下一轮 challenger。在前面这套训练集 / 验证集和 champion-challenger 机制下面AI 会继续做多轮迭代。接下来我用一个例子给大家讲一下这个模型通过这种打擂台机制优化 prompt 的一个过程。第一轮做加法。 模型根据评测结果往 system prompt 里补了三类规则下面是简化示意## 任务分流- 领域外但安全的问题直接完成不要因身份拒答或强行转回本领域- 用户给了硬约束字数/格式/角色…时优先满足## 全面性框架- 不机械堆信息但要覆盖真正影响决策的关键点## 禁止的行为- 没有可靠依据时不编造精确百分比、时间等细数值第二轮开始做减法。 评测里领域内问题的正确性暴跌模型意识到规则加得太多、互相打架于是整段删掉刚加的“全面性框架”并精简了任务分流、收敛了部分正确性细则。第三轮继续做减法。 效果仍不理想模型把第二轮新增的抑制规则、以及第一轮加的多条正确性细则也一并删掉让 prompt 回归简洁。终于在第四轮的评测里面发现整体分数都上涨了然后当前这个 prompt 就作为了当前优化的基线。上面这一轮任务的迭代模型整整运行了 17 个小时一共完成了 16 次迭代最终这一版在多个评测维度上都稳定超过了基线经过我们的人工复核之后发布上线了。以上就是一个典型的 Harness 工程案例我们利用 Coding 的 agent 去优化我们自己的业务 agent。03 如何开始实践 Harness 工程创造环境一定要给 AI 创造一个环境这个环境包括两方面实践的技巧在有了环境之后关键在于如何把它用起来。我们实践下来的经验有两点没有银弹看到这里你可能会有一种感觉Harness 工程看起来很简单已经开始摩拳擦掌了。事实上可没有这么简单这篇文章里面能呈现出来的东西只是冰山海面的那部分接下来我就跟大家讲一讲冰山下的部分。很多事情看起来简单真正实行起来会在意想不到的地方跌倒。情况是这样的我们这个 AI 迭代了17轮实际上只有第4轮是能用的后面的13轮它都没有拿到成绩。我们分析了原因发现是评测集有问题有些题目的评测标准不合理所以它给出的那种反馈的信号不准确导致后面的轮次 AI 被错误的反馈信号带偏了。再比如评测环境的稳定性。理想的情况都是 AI 改了个 prompt跑评测拿到分数快速迭代下一次。但实际的情况是 AI 改了个 prompt去跑评测结果评测失败了一直在重试一晚上过去了都没有什么进展。这种环境稳定性的问题并不是 AI 能解决的。一环扣一环软件工程从来就没有银弹不存在说有了 AI 之后这些业务复杂度和系统复杂度的问题就自动消失了这也解释了一个普遍现象大家都说通过 AI 都提效了几倍但是整个组织的效率也没有快很多。当然我的意思并不是 Harness 工程没有用恰恰相反我认为 Harness 工程是短期被高估但长期被低估的东西。现在很多研发平台都在慢慢变得 AI 友好AI 相关基建也在稳步推进这些变化都需要时间的积累。Harness 工程会随着 AI 基建和业务评测集的进步逐渐发挥它的全部实力。对 Harness 工程有正确的认知反而能尊重科学规律避免“AI 大跃进”。04 下一步从小循环到大循环最近 Loop Engineering 的概念火起来了大家的普遍的体感是这个东西隐隐感觉很有道理/似曾相识但是又很难说清它到底是什么。在我看来这只是把大家的日常实践起了个新名字而已就好比我们用 AI 先写好测试用例然后让它一直开发直到通过测试然后它持续开发十个小时这难道不是一种循环吗前文提到我们让 AI 围绕评测集自动优化 prompt、修复 badcase 也是一个循环我们给 AI 提出了目标和验证手段模型会不断的循环迭代提出新的方案、修改代码或者 prompt、部署代码、提交评测根据评测结果判断是否达到目标如果达不到目标就从第一步重新开始循环直到达到目标。这个小循环让我们从人工优化 prompt 的工作解放出来将更多时间放到定义问题和验收上面。但这个小循环有一个前提badcase 需要先由人整理成评测集。从线上 badcase 产生到进入评测集中间的归因、分析、分发仍然靠人工。为了进一步提效我们正在尝试实现 badcase 优化全流程自动化从发现 badcase 开始到归因、分析、分发最后到开发、评测、验证、上线让 AI 完成整个闭环。未来如果有成功的经验或者失败的教训后续我会再跟大家分享。*注本文为作者个人技术思考与经验分享不代表公司的官方立场或观点。文中部分论述涉及对技术趋势和发展方向的前瞻性判断基于作者写作时的实践、认知与经验所有内容仅供交流参考读者应结合自身场景独立评估。