做 Agent 的团队应该都有过这种经历评测集是从某个开源 benchmark 上拿的跑出来的分数挺好看换个 benchmark 分数就掉一截。两个基准都自称能测对话能力结果互相矛盾最后只能靠感觉判断哪个更可信。arXiv 上最近有篇论文想解决这个问题思路很直接既然基准是用来测 AI 的那基准本身的质量谁来测作者提出一个无需参考基准的评估框架让 LLM 当裁判从一致性、复杂度、策略覆盖度三个维度给对话代理基准打分并给出诊断建议。用AI评判AI的考试卷这个框架的核心假设是一个高质量基准应该让模型在多次运行中表现稳定一致性任务不能太简单也不能太难复杂度并且覆盖足够多的对话策略类型策略覆盖度。三个维度都不需要人类标注纯靠 LLM 评判者打分。论文验证了框架的有效性评估结果和独立的人类标注结论一致而且能稳定区分不同质量等级的基准。以后团队选基准理论上可以先跑一遍这个框架看看手里的评测集质量到底行不行。从实现思路上看这套框架对合成基准和人工编纂的基准都适用。合成基准是当前 Agent 评测的主流生产方式——用大模型批量生成对话场景再人工抽检。这类基准的典型问题是生成质量参差有的题目自相矛盾有的场景太窄。框架给出的三个评分维度正好对应这类基准最容易出问题的环节题目之间的一致性、任务难度的分布、对话策略的覆盖范围。维护者拿到诊断结果就能定位是生成提示词的问题还是抽样策略的问题。这里想多说一句评估维度里的复杂度其实是最难把握的。任务太难所有模型都拿低分基准失去区分度任务太简单大家都拿高分同样没意义。人工设计基准时难度曲线靠经验调经常要跑好几轮才能调到合适。框架用 LLM 直接评估复杂度相当于把这一轮轮试错的过程自动化了。但自动化评估的合适标准本质上还是评估者模型的判断标准——它觉得难模型做不出来不代表任务本身设计有问题。一个绕不开的循环问题但这里有个绕不开的问题用 LLM 评判基准评判者本身也是 LLM。如果评判者模型能力不够或者某个模型的判断风格特别同一个基准可能得到完全不同的评分。论文没有给出不同 LLM 评判者评分差异的量化数据——不同裁判打分差多少直接决定这个框架能不能当工具用。更微妙的是如果基准本身就是用 LLM 生成的再用 LLM 去评判它这里面的循环依赖怎么处理论文也没有展开。框架真正有价值的地方不在评判基准而在诊断基准。一个基准质量差通常不是整体差而是某个维度有问题——比如策略覆盖度不够或者任务难度分布不合理。框架给出的诊断建议能让基准维护者知道该往哪个方向改而不是推倒重来。做评测的团队能拿来干什么做 Agent 评测的团队现在面临一个尴尬的局面评测集越来越多但基准之间的质量差异巨大。有的基准题目有歧义有的难度分布失当有的覆盖场景太窄。选错了基准模型的迭代方向就跑偏。这篇论文提供的思路相当于给评测工作加了一道质检工序。但把它当工具用之前有几个问题需要先想清楚LLM 评判者打分的一致性有没有保障跨任务域的稳定性如何论文没有提供这些验证数据。更现实的做法是把它当参考框架而不是自动化工具——先用它定位基准的问题维度再结合人工抽检确认。毕竟评测这件事最终还是要对自己的业务场景负责。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版