验证 Agent 会自我进化，为何最优 Harness 仍留不住？

硬件验证 Agent 可以被自动改进，这件事已经有了比“改一版提示词看看”更扎实的实验。但另一半结果更值得工程团队盯住：找到几套各有优势的运行方案，并不等于能把优点装进一个稳定复用的方案。新近一篇 arXiv 论文把这个问题放到真实的设计验证根因定位任务上，答案相当克制，也更接近真实的工程现场。

论文固定执行任务的底层模型，让外层优化器修改 Agent 的 harness：提示与技能、检索和读取规则、工具调用策略、回合控制、失败恢复以及最终答案提交。作者在 12 个私有任务上观察到完成尝试和至少命中一次的任务数显著提高；但 60 次尝试里答对的次数只从 17 次增至 20 或 21 次。先别急着宣布“进化成功”，这些数字说的是不同的事。

先看清五个数字

设计验证中的根因定位，不是看见某条 assertion 报错就把它当根因。Agent 需要在回归日志、testbench、RTL、C++ 功能模型与仿真状态之间追踪因果链，最终指出引发故障的函数和应改位置。论文的主实验给每个任务五次运行机会；同一个任务的“至少成功一次”、五次中稳定成功，以及总共答对几次，是三种不同能力。

以 Kimi K3 为固定主体模型的对照中，原始 harness 在 60 次尝试里完成 34 次、答对 17 次；加入基于证据的检索规则后，完成 58 次、答对 20 次；进一步加入批量因果搜索后，完成 60 次、答对 21 次。对应的 pass@5 从 5/12 升至 9/12、10/12，首轮成功却是 2/12、6/12、5/12。至少两次成功的任务数分别是 5/12、6/12、5/12。

最容易被标题吞掉的，恰恰是这里的区别：harness 很擅长把尚未交卷的 Agent 拉到“能交卷”，也能让它偶尔触及更多题型；但它尚未让同一题上的正确判断稳定增加。若生产环境只允许一次运行，pass@5 的改善不能直接当作上线成功率。若每次运行都耗费仿真资源，完成率也不能代替诊断准确率。

Harness 究竟改了什么

这里的 harness 是模型外部的运行控制层，负责组织模型与工具的循环、上下文和状态、工具访问、停止与输出。论文把它与底层模型、任务环境、评分器和 Agent 的提示脚手架区分开；实际候选包则连同它加载的脚手架一起演化。所以这项研究的主题是系统配置与运行机制，而非训练出了新的硬件专用大模型。

作者让优化器看到候选的任务分数、运行轨迹和失败类别，再生成新的候选。每个候选放进隔离目录，先验证改动是否真的进入运行时，再做低成本搜索和重复确认。档案保留配置清单、激活证据、任务级分数、轨迹与谱系。失败也没有被揉成一个“没通过”：候选格式错误、规则未激活、服务或环境故障、超时、交了错答案、交了对答案，含义完全不同。

演化出来的改动大多是看得见的工程约束：先定位诊断锚点，再按已观察到的文本做字面检索；限制读文件范围和次数，记录已读证据；要求把故障来源、传播路径与检测位置分开；在预算耗尽前提交一个可评分答案。这些动作未必让模型“更懂 RTL”，却减少了无边界翻文件、凭空猜搜索词和最后来不及回答的损失。

论文有一个特别有价值的自我校验：某候选的规则确实进入了 2.9 万字符左右的实际提示，但一次成功轨迹并未遵守规定的检索声明；另一个成功轨迹确实留下了因果提交记录。前者说明“配置已激活”不能推出“模型照做”，后者说明“模型照做”也不能单凭个例证明某条规则造成了结果。把配置检查、行为轨迹和任务成绩分开，才有可能讨论机制。

为什么优点拼不起来

基于证据的候选在首轮成功和重复成功上较好，加入批量调用与因果提交的后续候选则在任务覆盖和完成率上较好。两个候选合起来覆盖 11/12 题，但任一单体最高只有 10/12 的 pass@5。更大规模的一次分支搜索生成了 990 个分支，其中 958 个接受评估；所有档案候选的命中并集达到 10/12，已晋级主候选却停在 3/12。这是“仓库里有解法”与“一个通用配置稳定会解”之间的距离。

后续候选继承了旧规则，又增加了新规则，仍丢掉部分原先通过的题。公开轨迹不足以判定究竟是优化器挑错、指令相互干扰、底层模型执行不稳，还是五次抽样带来的波动。能确认的是结果层面的未合并：把规则写进同一个 prompt，不保证相应行为在同一批任务里同时出现。更长的提示也增加了模型需要协调的约束；论文里一条后续候选的实际提示约 4.2 万字符，比前一条长约 47%，但这只是伴随现象，不能据此宣称长度导致退化。

晋级规则也有两难。若要求新候选的通过题集严格包含旧候选，一次随机失手就可能挡住真正有用的改动；若只看平均分，新候选可能靠几道容易题的增益掩盖某个稳定能力的流失。一次回放不足以做这样的取舍。候选档案的价值因此不只是“备份旧版”，而是保留可比较的能力分布，供按任务类型路由或重新设计模块时使用。档案并集可以提供线索，却不能冒充组合后的实测成绩。

验证集的短暂高分

作者另外用 8 道搜索题、4 道未进入搜索的验证题挑选候选。某个 DeepSeek 候选在四题验证集上的平均分从 0.375 升到 0.725，看起来相当漂亮。随后将该候选与基线放回含搜索题和验证题的 12 题池，在两次匹配回放里，双方都只解出 2/12；均分差一次微正、一次微负。

这里有两层边界。四题虽然不参与搜索，却用于挑选候选，因此不是完全未触碰的最终测试；十二题回放又包含原搜索和验证题，也不能称为独立泛化证明。它说明所选收益没有在这个更宽的题池里维持，尚不足以推断所有 harness 演化都会过拟合。对企业试点更实用的要求，是把“搜索时看见的题”“用来选版本的题”和“最后才打开的回归题”明确隔离。

另一组更强结果，回答的是另一道题

论文还给出 CVDP 公开基准的交叉案例：固定 GLM-5.2，在 142 个 RTL 生成与修复任务上，一套限定宽度的自动演化修复 harness 通过 61 题，参考验证循环通过 45 题，多 16 题，相对增幅 35.6%。这比前面的诊断实验亮眼，但任务、模型、输出和评分方法都变了。这里要交付可运行的 RTL 产物，并由功能验证器检查；前面的私有任务是跨日志与代码找到根因函数，按规范化标识符精确匹配。

CVDP 修复过程中，主体 Agent 可以使用编译、仿真、testbench 诊断和辅助审阅信号；最终用于计分的功能验证器只在产物完成后运行，没有作为该题修复过程中的反馈。外层优化过程可以利用已完成任务的评价来挑选后续候选。把这些反馈层次拆开，才能准确理解“工具验证”的作用：可执行诊断帮助局部修复，最终测试衡量产物质量，两者不是同一权限。

即便在这条任务链里，部分高分也来自按题型路由和已评分任务工件，不能直接归为一套通用 harness 的胜利。论文没有证明这条 CVDP 路线会使前述私有根因定位任务一并受益，更没有给出真实项目的 sign-off、客户验收或量产部署证据。

给生产团队的升级办法

把论文带回工程现场，更有用的是一份升级清单。第一，给每个候选保存清单、改动差异、激活证明和任务级轨迹；若一条规则根本没进入运行时，分数不应归因给它。第二，完成率、首轮成功、重复成功、任务覆盖和总正确次数分别列账，先定团队最重视哪一项，再设允许退化的预算。第三，用重复运行与独立保留题决定晋级，并把服务故障、超时和错答分开统计。

第四，对搜索、读取、权限、超时、答案提交这类关键约束，能在工具和代码层执行就尽量做成可检查的机制。只把规则堆进提示，既难证明确实执行，也会把相互协调的负担交给模型。第五，保留互补候选，在已知任务族上谨慎路由；路由器本身也要评估误判成本和维护成本，不能把档案并集写成线上成功率。

对 AI+EDA 的落地团队，这意味着模型、企业知识、验证工具和流程记录需要形成可追溯的闭环。中科麒芯关注的研发 Agent 工程化方向，也应接受同样的验收方式：一次建议从证据检索到工具执行、人工复核和版本回归，都能找到对应记录。产品定位可以提出方向，可靠性仍须由项目数据证明。

论文展示了固定模型条件下，外部 harness 的确可以自动演化出更高的完成率与更广的任务触达。它同时提醒我们，生产级升级不能只盯最好的单次分数：发现、合并、晋级和回归是四道不同的门。今天最稳妥的判断标准，是一套候选能否在独立题池、重复运行和真实工具反馈下守住原有能力；做不到这一点，档案里再多漂亮局部结果，也还只是候选。

作者：麒芯
免责声明：本文基于 arXiv:2609.28908v1 预印本。主实验为作者使用的 12 个私有任务，文中数字均为作者报告；不代表第三方复测、项目签核或生产部署。
参考资料：Seyoum 与 Mittur，Automatic Harness Evolution for Hardware Design Verification，arXiv:2609.28908v1。