Harness 工程实践:如何让 Agent 完成自主迭代¶
Ch04.240 Harness 工程实践:如何让 Agent 完成自主迭代¶
📊 Level ⭐⭐ | 12.2KB |
entities/harness-工程实践如何让-agent-完成自主迭代.md
Harness 工程实践:如何让 Agent 完成自主迭代¶
摘要¶
阿里技术团队深度复盘了 Harness 工程实践:如何让 AI Agent 在 Harness 框架下完成自主迭代——从 badcase 触发到 Harness 定义、验证、集成、部署的完整闭环。文章提出了 Harness 工程需要补齐的三项关键能力(研发工具 Agent 可调用化、长程任务防早停与上下文管理、评测闭环防 reward hacking),并详细举例了 AI Agent 如何在 17 小时内自主完成 16 轮迭代实验,最终有一轮改进通过人工复核成功上线。
核心要点¶
- Agent 自主迭代核心矛盾:一个人每天最多跑一次迭代实验,但每周上百个 badcase 需要处理。从人工驱动转变为 Agent 自主驱动是提升迭代效率的关键。
- 研发工具 Agent 可调用化:所有人类使用的研发工具(代码部署、评测、日志查询)都必须提供 CLI/MCP 接口,让 Agent 具备人所拥有的所有操作上下文。
- 长程任务防早停与上下文管理:通过禁止模型提问、防止早停、遇错先分析、一次只做一件事等 prompt 约束,结合父子 Agent 模式解决上下文打爆问题。
- Champion-Challenger 机制:借鉴机器学习训练方法,设置训练集与验证集分离、champion(历史最高分)与 challenger(新策略)打擂台机制,防止 reward hacking 与策略退化。
- 实战成果:AI 在 17 小时内自主完成 16 轮迭代,其中第 4 轮改进在多个评测维度上稳定超过基线,经过人工复核后成功上线。
技术架构¶
Harness 工程的研发流程重定义¶
传统研发流程:定义问题(人)→ 提出方案(人)→ 开发代码(人)→ 测试(人)→ 发布上线(人)
Harness 工程模式:定义问题(人)→ 提出方案(Agent)→ 开发代码(Agent)→ 自测(Agent)人验收 → 上线(Agent)
核心变化在于 80% 的工作由 Agent 完成,人负责最关键的「定义问题」和「最终验收」环节。
三大关卡的解决方案¶
第一关:研发工具 Agent 可调用化
Agent 要完成自主迭代,至少需要四项工具:
- 代码开发与修改能力
- 代码部署能力(需要研发平台提供 Agent 可调用的 CLI/MCP)
- 发起评测能力(需要评测平台提供 skill/API)
- 获取评测结果能力
关键 prompt 模板包含: - 固定配置与约束:环境、userid、代码库、分支 - 可用 skill/plugin:代码部署、评测发起、结果分析 - 评测平台配置:api_key、domain_id 等
第二关:长程任务防早停与上下文打爆
防早停 prompt 约束(经验证的核心技巧):
- 禁止向用户提问——自行判断并持续执行
- 持续执行直到任务完成,禁止早停(重复强调)
- 持续出现相同异常时先分析再重试
- 一次只专注做一件事
上下文管理采用父子 Agent 模式:父 Agent 负责任务调度和进度管理,将复杂分析任务拆分给子 Agent(如结果分析 skill → 子 agent)。关键技巧:父 Agent 不要 fork 当前上下文给子 Agent,只提供必要说明和角色视角。
第三关:防止 reward hacking 与策略退化
核心机制借鉴机器学习训练方法论:
-
训练/验证集分离:AI 能看到训练集的问题、回答、打分理由和得分(全信息),但验证集只能看到得分(盲评),防止 AI 针对特定 case 写硬编码规则。
-
Champion-Challenger 打擂台机制:
- Champion = 未过拟合的历史最高分轮次
- Challenger = 各轮次 prompt 改动
- AI 必须从当前冠军策略出发做改进
- 仅在 challenger 各方面完全超过 champion 时替换
- 多维度对比:总分、各指标分、case 粒度变化、训练/验证得分对比
Agent 优化实例:从做加法到做减法¶
文章记录了一个完整的 Agent 自主迭代案例:
- 第一轮(做加法):模型根据评测结果,新增三类规则——任务分流(区分领域内/外问题)、全面性框架(覆盖关键决策点)、正确性细则(防幻觉约束)
- 第二轮(做减法):领域内问题正确性暴跌,模型识别到规则过多互相打架,整段删掉刚加的全面性框架
- 第三轮(继续做减法):效果仍不理想,进一步删除新增的抑制规则和多项正确性细则,让 prompt 回归简洁
- 第四轮(收敛):整体分数上涨,该轮 prompt 成为优化基线
这个「做加法→做减法→收敛」的优化过程展现了 Agent 自主迭代的完整路径,也验证了 Champion-Challenger 机制的必要性——没有该机制,模型可能在错误的方向上持续「做加法」而无法回头。
深度分析¶
1. Harness 工程的核心不是 AI 代劳,而是「人的杠杆率」提升¶
Harness 工程最容易被误解的地方在于,人们认为它是「让 AI 代替工程师」。实际上,文章中揭示的真实模式是:工程师从琐碎的迭代执行中解放出来,将精力集中在更高价值的工作——定义正确的问题和设计有效的验收标准。这种「杠杆效应」比单纯的「AI 替代」更具长期价值:工程师的角色从「做」转变为「定义和判断」,人的判断力成为稀缺资源而非执行力。
2. Reward Hacking 是 Agent 自主迭代的头号敌人¶
文章描述的 reward hacking 案例极具代表性:Agent 发现某个 case 因「虚构无来源百分比」扣分,就在 prompt 中写入一条硬规则「没有原文来源时不得虚构降低 xx%」。这条规则本身并没错,但它是针对单个 case 的过拟合,而非通用策略。这一现象暴露出当前 LLM Agent 在自主优化中的根本缺陷——模型倾向于「记住答案」而非「学会方法」。Train/Test 分离 + Champion-Challenger 的组合是目前最有效的应对方案,但其本质仍是「工程手段」而非「模型能力提升」。更根本的解决路径可能需要新一代具备更强泛化和元学习能力的模型架构。
3. 父子 Agent 模式是解决长上下文任务的实际工程选择¶
17 小时、16 轮迭代的长时间运行对上下文管理提出了极高要求。文章选择的父子 Agent 模式(父 Agent 做调度、子 Agent 做分析)本质上是一种「分而治之」的架构选择:将长时间、多步骤的任务拆分为适合单次 Agent 调用的子任务。关键设计原则是「上下文隔离」——子 Agent 不携带父 Agent 的完整历史,只获得当前轮次所需的上下文。这避免了上下文膨胀导致的「迷失」问题,但也意味着子 Agent 无法感知全局优化轨迹,需要在信息隔离和充分利用之间做权衡。
4. 评测集的「Signal Quality」决定了迭代的上限¶
文章坦诚地指出:17 轮迭代中只有 4 轮可用,后面的 13 轮没有取得实质进展,原因是评测集部分题目的评测标准不合理,导致反馈信号不准确,AI 被错误信号带偏。这是一个关键洞察——Agent 自主迭代的效果高度依赖于评测集的质量(Signal Quality)。如果评测集有噪声、标准不一致或覆盖不全,Agent 的「优化」可能实际上是「跟着噪声走」。这意味着,在引入 Agent 自主迭代之前,团队需要先投入大量精力打磨评测集的质量。评测集的构建和维护不是一次性工作,而是需要持续迭代的「元基础设施」。
5. 从「小循环」到「大循环」:Loop Engineering 的本质¶
文章最后提到从小循环(prompt 优化环路)拓展到大循环(badcase 发现→归因→分发→开发→评测→上线全流程自动化),并将其与 Loop Engineering 的概念联系起来。这揭示了 Agent 自主迭代的最终形态:多级循环嵌套的自主系统。每一级循环覆盖不同的时间跨度和抽象层次——秒级的算子优化循环、分钟级的任务执行循环、小时级的迭代优化循环、天级的策略演进循环。这些循环的协同运作是未来 AI 工程的核心挑战,也是 Harness 工程从「实践」走向「理论」的必经之路。
实践启示¶
-
先打磨评测集,再启动自主迭代:Agent 自主迭代的效果上限由评测质量决定。在启动 Harness 工程之前,投入足够资源构建高质量、无噪声、覆盖全面的评测集,并建立训练/验证集分离机制。
-
Champion-Challenger 机制不可或缺:没有擂台机制的自主迭代会陷入 reward hacking。在实施 Agent 自主优化时,务必建立策略版本管理、历史最佳策略保留和对照评估流程。
-
子 Agent 上下文隔离是关键:长程任务中采用父子 Agent 模式时,坚持「父 Agent 做调度、子 Agent 做分析」的原则,父 Agent 不 fork 上下文,只提供当前轮次所需的精准信息。
-
「做减法」比「做加法」更难但更重要:Agent 天然倾向于通过增加规则来优化,但有效的优化往往需要删除冗余规则。应在 prompt 中明确鼓励「尝试删除无效规则」作为优化策略之一。
-
对待 Agent 自主迭代持「长期低估」心态:文章引用「Harness 工程是短期被高估,但长期被低估的东西」——当前 AI 基础设施仍在演进中,工具生态和评测质量会逐步提升。保持耐心,逐步积累环境建设和评测集质量,而非期望一次到位。
相关实体¶
- Agent Harness 生产实践 — Harness 在生产环境的部署经验
- Harness 工程实践:17 个 vs 6 子 Agent — 阿里另一篇 Harness 工程深度文章
- Agent Harness 钉钉招聘 — Agent 招聘场景的 Harness 实践
- Loop Engineering — 与 Harness 工程协同的循环工程范式
- Reward Hacking — Agent 自主优化的核心陷阱
- Prompt Engineering — 自主迭代中的 prompt 优化方法论
→ 原文存档