智能体评测系统架构设计与工程化落地全指南

做了两年多的智能体评测系统，从最早“脚本里塞几十个case跑一跑”到后面按工程化标准把评测做成独立的平台级服务，我最大的感受是：评测系统的复杂度，九成不在写代码，而在于你如何看待它。多数团队一开始都把评测当成临时验证工具，等模型升级、Agent逻辑频繁改动之后才发现，缺少一套可靠的评测系统，产品迭代就像在没黑灯的路上开车——你敢踩油门，但不知道什么时候会撞。

这篇文章想聊的，不是某个评测指标怎么算，也不是某个框架怎么用，而是把“智能体评测系统”当成一个正经的软件工程来做的时候，架构该怎么拆、模块该怎么设计、工程化落地时哪些地方最容易翻车。适合正在做Agent开发、智能体平台、质量保障或AI应用工程化的团队参考。哪怕你还没有系统化的评测平台，读完也可以按里面的思路，先从最小闭环开始搭。

1. 做评测系统之前，先想清楚边界和设计目标

1.1 为什么智能体评测不能“跑一下”就完事

传统接口测试有一个天然优势：输入输出都是结构化数据，断言逻辑非常明确。请求发出去，返回200且body里某个字段等于预期值，这个用例就过了。但智能体评测完全不同。智能体的输入是一段自然语言上下文，输出是多轮对话、工具调用、状态变化交织在一起的复杂结果，很多时候根本不存在“唯一正确答案”。

举个例子，你让一个销售智能体处理“客户说太贵了，想再便宜点”的场景，它可以给出降价方案，也可以强调产品价值，还可以追问客户预算。三种行为方式不同，但可能都是合理的。这种情况下，单一断言式校验根本覆盖不了真实业务需要覆盖的能力范围。

更麻烦的是智能体行为的不确定性。同一个Prompt，模型版本没变、参数没变，跑两次结果都可能不一样。再加上Agent在运行过程中可能调用不同工具、走不同路径，单次运行结果只能反映当次行为，不能代表整体能力。如果评测脚本只是简单地把对话记录下来，人工看一眼说“还行”，那这个评测结果既不可复现，也不可量化，更不可能在团队协作中形成统一标准。

我见过不少团队的评测脚本散落在个人仓库里，标准不统一、数据不共享、结果不可比。A同学说“效果变好了”，B同学反问“哪里变好了”，谁也说服不了谁。这种状态下，评测系统本身就成了一种技术债。所以做系统之前，先要接受一个前提：评测不是测试的附属品，它是一条独立的产品线，要按软件工程的标准来建设。

1.2 评测系统的四个设计底线

我在梳理评测系统架构的时候，最先定下来的不是技术选型，而是四条设计底线。后续所有模块划分、方案取舍，都以这四条为判断依据。

第一，可重复。同一份评测集、同一个被测版本、同样的评测配置，任何时候跑都应该得到一致的结论。这里的“一致”指的是统计意义上可复现，而不是要求每次对话一模一样。如果同一天跑两次，一次显示成功率80%，一次显示60%，那这个评测系统本身是不可信的，谁都不敢用它做决策。

第二，可追踪。每一次评测结果都要能追溯到被测代码版本、模型版本、Prompt版本、评测集版本、评测参数五类信息。任何一个维度缺失，结果出问题时都没法定位。这条底线直接决定了数据模型怎么设计，后面会细说。

第三，可量化。评测输出必须包含结构化指标，而不是只有“看起来不错”。任务成功率、工具调用正确率、平均轮数、Token消耗、安全合规拦截率，这些都要落到数字上。数字不一定代表全部，但没有数字做基准，评测就没有参照系。

第四，可回归。Agent系统是持续演进的，今天改一个系统Prompt，明天换一个模型，后天加一个工具，每次改动都可能影响整体表现。评测系统必须有能力在每次改动后自动跑一遍核心评测集，快速发现哪些能力被改坏了。缺少回归能力，评测系统就只能当“展示板”，起不到质量门禁的作用。

这四条底线看起来简单，实际落地时每条都会牵扯出一堆细节。可重复牵扯出环境隔离和随机性控制，可追踪牵扯出元数据管理和版本关联，可量化牵扯出指标体系设计，可回归牵扯出执行调度和基线管理。架构设计本质上就是在为这四件事兜底。

2. 评测系统的整体架构：三层模型和数据流

2.1 三层拓扑：场景接入层、执行调度层、分析评估层

评测系统的整体架构，我习惯把它分成三层：场景接入层、执行调度层、分析评估层。这个分层方式不是拍脑袋定的，而是踩过几次坑之后梳理出来的。

场景接入层负责“测什么”。它管理评测场景、用例样本、评测数据集，以及用户提交评测任务的入口。这一层本质上是把业务需求翻译成机器可执行的评测任务。你告诉系统“我想测一下销售智能体在客户砍价场景下的表现”，系统需要把它转成一个包含场景定义、样本列表、参数配置的评测任务对象。

执行调度层负责“怎么测”。它接收评测任务，拆解成一个个可独立执行的用例，根据并发和限流策略调度执行，同时处理超时、重试、状态流转。这一层是整个系统的引擎，也是工程化程度要求最高的部分。很多评测系统跑得不稳定，问题都出在这一层——并发控制不好导致被上游限流，超时设置不合理导致大量误判，重试机制不健全导致结果偏差。

分析评估层负责“结果是什么”。它收集执行过程中的所有事件数据，计算各类指标，生成报告，管理回归基线。这一层听起来简单，实际很容易被低估。指标口径稍有差异，同一批执行数据能算出两个截然不同的结论；报告如果只给一个成功率数字，又完全没办法定位问题。

三层结构最核心的价值是隔离。场景接入口径和执行机制无关，调度机制和指标计算无关，指标计算和场景定义无关。这样任何一层升级，其他层都不用跟着重写。我曾经在早期版本把场景定义和执行逻辑写在同一个服务里，后来想支持流式对话场景，只能把执行模块从服务里抽出来，硬生生多花了两个星期重构。

2.2 以事件流为主干的数据链路

评测运行过程中产生的数据，按内容可以分成三类：任务元数据、执行轨迹数据、评估结果数据。其中最关键的是执行轨迹数据，它记录了智能体在评测过程中每一步的行为，包括用户输入、模型输出、工具调用参数、工具返回结果、各阶段耗时、Token消耗等。

这些轨迹数据的特征是：产生顺序性强、格式多样、写入量大。设计数据链路时，我建议以事件流为主干，而不是简单地把一次评测执行当成一个同步请求来处理。原因在于智能体运行天然是多步骤、异步化的。一个Agent从接收用户消息到最终给出回复，中间可能经历多轮模型推理和工具调用，周期长达几十秒甚至几分钟。如果用同步接口等所有步骤跑完再统一返回，执行引擎会被长时间占用，一旦中途超时，之前所有轨迹数据都会丢失。

实际方案是：执行引擎每产生一个行为事件，就立刻写入消息队列或日志管道，评估服务异步消费这些事件。这样执行过程和分析过程解耦，执行引擎不用等指标算完才结束，评估服务也不影响执行稳定性。数据经过清洗、结构化之后，进入指标计算流程和Trace存储。这样即使某次评估计算出现故障，原始事件还在，可以重新计算。

2.3 模块边界与部署形态

基于上面的分层，具体落地时，系统至少包括以下模块：场景中心、样本管理模块、评测任务服务、执行引擎、指标计算服务、报告服务、评测集管理模块。模块之间通过明确的API或消息协议通信，不共享数据库表。

部署形态上，评测系统建议独立部署，不要和业务应用混在一起。一是资源隔离，评测执行时会产生较大的计算和网络开销，混部会影响线上业务；二是稳定性隔离，评测系统出故障不能影响生产环境；三是安全问题，评测系统通常会配置访问第三方模型服务的密钥，独立部署可以更严格地管控权限。

有同事问过，评测系统要不要用微服务架构。我的回答是：模块边界一定分，但物理部署形态看团队规模。小团队前期完全可以把场景中心、任务服务、执行引擎打包成一个服务，指标计算和报告单独放一个服务，两者通过数据库和消息队列解耦。等评测规模大了，再把执行引擎独立出来做水平扩展。上来就拆八、九个微服务，只会增加运维负担，不会带来实际收益。

3. 评测内容工程化：场景、样本与评测集管理

3.1 评测场景的数据建模

评测场景是评测系统里最基础的概念，它描述了一类评测任务要考察的能力范畴。一个场景可能包含以下字段：场景名称、描述、任务目标、允许使用的工具范围、初始上下文（系统Prompt风格约束）、预期行为说明、典型样本示例。

建议直接用JSON Schema建模，这样既能约束字段，又能兼容扩展。举个例子，一个“客户砍价应对”场景的Schema大概是这样的：

{ "scenario_id": "sales_price_negotiation", "name": "客户砍价应对", "description": "考察销售智能体在客户提出价格异议时的应对能力", "objective": "在不损害公司底价的前提下，尽量挽留客户并推进下一步沟通", "allowed_tools": ["price_query", "order_create", "customer_info"], "initial_context": { "customer_tier": "vip", "product_category": "saas_subscription" }, "expected_behaviors": [ "先确认客户需求，再给出价格方案", "触碰底价时必须提示审批", "不得虚假承诺折扣" ], "tags": ["销售", "议价", "高优先级"] }

场景建模的价值一方面在于结构化，更重要的是让不同角色之间有了统一的“沟通语言”。产品经理可以看场景描述，工程师可以看工具约束，评测人员可以看预期行为。缺少这层结构化定义，评测样本就是一堆聊天记录，很难维护，也很难规模化扩展。

3.2 评测集的治理与版本控制

评测集是智能体评测系统的“题库”，它决定了系统在多大程度上能测出真实能力水平。评测集治理是内容工程的核心工作，比写执行代码更耗时，也更容易被忽视。

评测集必须当成代码来管理。我的习惯是把评测集文件放在独立Git仓库里，每一份评测集对应一个目录，里面包含样本文件、标注说明、更新记录。任何样本的增删修改都要走评审流程，不直接在线编辑。这样做的目的是防止“评测集污染”——哪些样本是原始评测集，哪些是后来为了调优模型加进去的，都要能追溯。

评测集的质量控制有几个关键指标。覆盖度方面，要看场景类型是否覆盖了主要业务方向，每个场景的样本量是否足够支撑统计结论；难度分布方面，要有简单、中等、困难三档样本，不能全是“送分题”，也不能全是“极端刁钻”；稳定性方面，评测集更新后要对比新旧评测集在历史版本上的表现，避免样本替换导致结论漂移。

3.3 样本标注的SOP与一致性

样本标注是评测内容生产中最容易出问题的环节。一个样本通常包括：输入消息、期望行为描述、可接受的优秀表现示例、不可接受的失败表现示例。难点在于，多个标注人员对同一个样本的理解可能有差异。

我建议为标注团队制定明确的SOP，核心是两件事。一是定义清晰的评分标准，比如“任务完成度”指标下，什么算完成、什么算部分完成、什么算失败，都要有可对照的示例；二是建立标注一致性校验机制，定期抽取一定比例的样本由不同标注员重标，计算一致性指标，低于阈值的样本要重新讨论。

此外，样本里不能有明显偏见或诱导性表述。评测智能体的目的是考察其真实服务能力，不是“钓鱼执法”。如果故意构造一些容易引发生成不当内容的输入，然后把模型判断为不合格，这种评测集只会让模型被引导到过度保守的状态，反而影响正常场景下的表现。

4. 执行引擎：并发、限流、超时与状态机

4.1 任务模型与状态机

执行引擎是评测系统中工程化含量最高的模块。我先定义清楚任务模型：评测任务（Task）是最外层单元，代表一次完整评测请求；一个Task包含一个或多个评测集（Suite）；每个Suites由若干用例（Case）组成，一个Case对应一条评测样本在指定配置下的一次完整执行。

状态机是执行引擎的核心骨架。一种比较实用的状态定义是：pending（等待执行）、running（执行中）、passed（通过）、failed（未通过）、error（执行异常）、timeout（超时）、cancelled（取消）。状态流转逻辑必须单一路径，例如pending只能流转到running，running只能流转到passed、failed、error、timeout之一。

这个状态机看似简单，实际落地时容易出问题的是“error”和“failed”的区分。我的定义是：failed代表智能体执行了，但结果不符合预期，属于业务层面的失败；error代表执行过程中出现基础设施异常，比如模型服务返回5xx、工具调用网络中断，属于系统层面的失败。两者的处理策略完全不同——failed需要分析语义，error大多可以直接重试。如果混在一起，报告里会看到一堆噪音数据。

4.2 并发度和限流参数怎么算

评测执行通常会调用第三方模型服务或者自建推理服务，并发太高会导致限流报错，并发太低又拉长评测时长。并发度规划其实可以通过简单计算来确定。

假设平均单个用例耗时为15秒（包括模型推理和工具调用），目标是在20分钟内跑完240个用例。每个执行并发单位上单位时间能完成的用例数为1/15个每秒。设需要的并发数为C，则理论上满足240 / 15 = 240 / (C * 15) 即C >= 240 / 15 / (2060/15) = 240 * 15 / (20 * 60) = 3？这里推导有点绕，换个方式理解：单并发20分钟可跑2060/15=80个用例，240个用例需要240/80=3个并发。但这是理想情况，实际还要考虑网络延迟、重试、以及部分用例超时拉长耗时，一般按理想值的1.5倍到2倍预留，也就是并发数至少取5到6。

限流方面，我建议在执行引擎里做两级控制。一级是全局令牌桶，控制整体请求速率，防止瞬间并发过高冲击模型服务；另一级是单任务并发限制，防止多个评测任务同时启动时互相抢资源。限流参数不要拍脑袋设，根据压测结果动态调整——先从小并发起步，逐步加压，找到“执行速度不再明显提升”的拐点，定为并发上限。

4.3 超时、重试与幂等设计

智能体评测执行天然存在不确定性，超时和重试是保证系统稳定性的关键。超时设置要分层次：单次模型调用设置连接超时和读取超时，比如连接超时5秒、读取超时30秒；单个用例设置总超时，通常是正常耗时的3到5倍，比如正常15秒的用例总超时给60秒；整个评测任务也可以设置最长执行时间，防止任务“悬挂”。

重试机制要遵守三条原则。第一，只对可恢复的错误重试，比如上游限流、网络抖动、服务端5xx；对业务失败不重试，因为重试大概率还是同样结果，只会浪费成本。第二，重试必须带退避策略，推荐指数退避加抖动，比如第一次等1秒，第二次等2秒，第三次等4秒，随机加减0到0.5秒。第三，重试要做幂等控制，同一用例的重试执行要生成新的执行ID，但归属到同一个评测任务下，保证数据统计时不会把一次用例的多次尝试重复计数。

5. 指标计算与评估报告：把“感觉变好了”变成数字

5.1 指标分层的设计

评测报告的指标设计，我建议分层梳理，不要只盯一个“成功率”。分层的好处是既能看全局，又能下钻定位问题。我习惯把指标分成三层：结果层、过程层、资源层。

结果层回答“任务最终有没有达成目标”，包括用例通过率、任务完成度、关键行为覆盖率等。过程层回答“这单在执行过程中表现如何”，包括工具调用正确率、上下文利用效率、无效轮数、回复长度合理性、合规拒绝是否正确等。资源层回答“成本花在哪里”，包括平均Token消耗、平均调用次数、单用例执行耗时、超时率等。

指标口径的定义是这层最容易埋坑的地方。举个例子，工具调用正确率，分子是“被判定为正确的工具调用次数”，分母是什么？是总工具调用次数，还是应调用工具的总次数？两个口径算出来结果可能差很多。我踩过这个坑之后，第一件事是给每个指标写清楚“定义文档”，包含计算公式、数据来源、计算时点、示例口径。指标口径没有统一，后面所有对比分析都是空中楼阁。

5.2 自动评估与人工评估怎么结合

智能体评测里最难也最核心的是评估环节：如何判断一个多轮交互结果是否合格。纯粹靠人工评估，代价高、速度慢、难以规模化；纯粹靠自动评估，又容易在复杂语义场景下出现误判。实际工程落地基本是两者结合，按场景类型分配比例。

自动评估可以做三类事情：规则校验、结果比对、模型辅助评分。规则校验适合硬性条件，比如是否提及客服工单号、是否包含必要字段；结果比对适合有明确标准的场景，比如检索类Agent的知识命中率；模型辅助评分（LLM-as-Judge）适合开放场景，但这里有个坑——评估用的模型和被测智能体模型不要用同一个，否则相当于让选手给自己当裁判，结果偏差会很明显。评估模型的参数也要固定，温度设为0，System Prompt固定下来，Prompt本身要纳入版本管理。

人工评估不能省，但可以聚焦。建议对自动评估结果中边界分（比如得分在阈值附近的用例）、争议性强、以及高风险场景的样本，设置至少10%到20%的人工抽检比例。抽检结果反过来可以校准自动评估的阈值，形成持续改进循环。

5.3 报告、回归基线与趋势分析

评测报告的目标不是“生成一个漂亮的PDF”，而是帮助团队回答三个问题：当前版本相比上一版是变好还是变差，变好变差集中在哪些场景，最典型的失败案例是什么。

因此报告要包含以下内容：总体指标摘要表（与基线差值用上下箭头标明）；场景维度拆解（按场景分组展示通过率、平均轮数、Token消耗等），让人一眼看出哪个场景波动最大；失败样例列表，每条样例附上执行轨迹链接，点击即可查看完整对话和工具调用细节；以及自动生成的失败原因初步归类，方便后续人工分析。

回归基线是评测报告最有价值的衍生产物。每次发版后，选一个稳定版本作为基线，后续所有变更都和基线对比。建议基线每月重新校准一次，因为模型能力在持续变化，评测集也在迭代，基线定太久会出现“现在看什么都退步”的错觉。趋势图上我只看三个东西：整体通过率趋势、各场景通过率热力图、失败原因TOP3的变化，其余信息太多反而干扰决策。

6. 工程化落地的关键：环境隔离、可观测性与流水线集成

6.1 环境隔离与依赖固定

评测系统对环境隔离的要求，比普通开发环境严格得多。我早期吃过一次大亏：在开发环境评测一个Agent，结果另一个同事同时在调试同一套服务，两边互相影响，评测结果失真。从那以后，评测环境必须独立，并且每次评测尽量用容器或沙箱形态拉起被测服务。

依赖固定也是同样的逻辑。评测时用的模型版本、Prompt版本、外部服务版本、依赖库版本，全部要显式声明在评测配置里，不能默认拉最新。之前有过Model版本从7B升到13B导致评测集全面通过的“假成功”，实际上是模型版本变了，被测Agent的推理表现也变了，但评测系统没有记录版本号，排查了很久才找到根因。

6.2 Trace与日志：评测过程必须可回溯

评测系统最容易被忽视的工程化模块是可观测性。没有Trace追踪，评测结果一旦出问题，就只能对着一个失败标记干瞪眼。我的经验是：评测任务从创建到完成的整个过程，每一步都要可回溯。

建议评测执行过程中累计三类日志。审计日志：任务谁提交的、评测集版本是什么、被测版本是什么；轨迹日志：智能体每一步的输入、输出、工具调用、状态转换，按用例维度组装；系统日志：执行引擎自身的运行情况、耗时、错误栈。轨迹日志建议采用OpenTelemetry或类似标准埋点，配合日志系统实现按用例ID检索完整链路。

评测报告里给到的每一个失败用例，都应该附上一条可直接点开的Trace链接。这样评测工程师在看到“这个用例失败了”的同时，能立刻看到“失败发生在模型推理的第3轮，当时调用了价格查询工具，返回结果超时”。没有这部分能力，评测系统就只是个自动化跑脚本的工具，谈不上工程化。

6.3 接入CI/CD：评测从“人工操作”变成“自动门禁”

评测系统工程化落地的标志性节点，是把它接到代码提交和发布流程里。我建议分三级跑：

第一级是冒烟评测，代码合入主分支前跑，从评测集里抽最核心的50到100个用例，执行时间控制在10分钟以内，主要目的是发现明显回退。第二级是回归评测，每天定时跑全量核心评测集，生成趋势报告，发现仪式性回退就自动创建追踪问题。第三级是发布门禁，发布候选版本必须通过指定评测集，通过率低于阈值则阻断发布流程。

接入CI/CD的过程中，最需要处理的是“评测集规模”和“执行时间”的矛盾。CI里执行时间太长会拖累开发节奏，所以冒烟评测集一定要精选，优先选代表核心链路和最近改动点的样本；把执行时间控制在用户可接受的范围内。可以先在数据上测算，比如8到10个并发，平均15秒一个用例，全量跑500个用例大概15分钟，核心冒烟集选80个用例大概2到3分钟，这样才适合放在提交阶段跑。

6.4 成本预算与控制

智能体评测跑起来是实打实要花钱的，尤其是调用第三方模型API。成本控制不能等月底账单出来才后悔，要在架构层面提前设计。

成本计算模型很简单。平均100个用例一天跑两次，每个用例平均产生5次模型调用，每次约消耗2000 Token，按每百万Token的价格计算，就能得到单日成本。有了这个基础估算，再定每月预算，反推每天允许跑的用例总量，再分配到各部门的评测任务额度上。具体的一个估算示例如下：

假设某文本模型价格为每百万Token 50元，每个用例平均消耗5000 Token（含输入输出），评测系统每天跑500个用例，则单日Token消耗为500个用例乘以5000 Token等于250万Token，日成本约为125元，月成本约3750元。如果加入人工评估抽检和失败重试，实际成本还会更高，预算至少要预留30%的余量。

成本控制手段包括：评测样本里合理复用上下文减少Token浪费；对长时间运行的Agent设置总步数上限，避免“死循环”烧Token；重试只针对可恢复错误，且限制重试次数；非关键评测任务放到模型服务低峰期执行，降低被限流概率。成本控制做得好，评测系统才有长期跑下去的资源保障。

7. 踩坑实录与排查技巧

7.1 智能体评测典型问题速查表

结合我自己和同行交流的经验，整理了一份高频问题速查表，基本能把评测系统的常见坑覆盖到七八成：

7.2 三个让我印象深刻的坑

第一个坑是评估模型的Prompt污染。最早用LLM-as-Judge时，评估Prompt里给了“AI助手应该表现出积极友好的态度”这类描述，结果所有被测智能体都因为回复不够热情而被打低分，而业务方真正关心的是有没有解决问题。后来把评估Prompt改为只针对目标达成度打分，同时定期拿人工标注结果校准评估Prompt，问题才解决。这个坑的关键在于评估Prompt和被测智能体的Prompt必须完全独立，且有明确的评分维度。

第二个坑是评测环境的“脏状态”。有一次评测报告显示某个场景的通过率从85%掉到60%，排查了很久，最后发现是评测环境里缓存了上一个版本的模型配置，Agent加载到了旧配置。从那以后，每次评测启动前强制清空缓存、校验环境指纹，环境指纹包含被测服务版本、模型版本、依赖锁文件哈希等，不匹配直接拒绝执行。

第三个坑是并发场景下的上下文串台。现象是：某个用例的多轮对话中，突然混入了另一条消息的内容，看起来像“精神分裂”。排查后定位到是执行引擎在压测时共用一个历史消息列表实例，并发写导致数据互相覆盖。修复方式是每个用例的执行上下文一律通过依赖注入创建独立实例，过程中不共享任何可写状态。

7.3 一次成功率下降的排查过程

分享一次典型的排查过程，里面有很多共性经验。当时线上评测报告显示“订单查询Agent”整体通过率一夜之间下降了12%，场景集中在“用户查询多笔订单”相关的样本。

第一步，查报告里的失败用例列表，发现失败集中在同一种表现：智能体只返回了第一笔订单信息，没有列出其余订单。第二步，查看失败用例的执行轨迹，发现工具调用返回的结果里其实包含三笔订单，但模型在最终生成回复时只引用了第一笔。第三步，对照依赖版本信息，确认被测Agent的代码没有变更、Prompt没有变更，唯一变化的是模型版本从前一天的基础模型升到了新版本。

定位到这里，基本能判断是新版本模型在“长列表信息汇总”任务上的指令遵循能力变弱了。后面找模型团队反馈，同时把该场景的评测集单独拆出来，作为新模型版本上线的回归门禁样本。整个过程如果没有Trace追踪和依赖版本记录，这种“隐性回归”很难被发现。

结尾：一点个人体会

评测系统的建设，技术上的难点其实是有限的，难的是把很多流程、规范、细节持续坚持做下去。我自己的体会是，评测系统能不能真正跑起来，关键往往不在执行引擎写得多好，而在于对评测集的态度、对指标口径的较真、对环境隔离的敬畏，这些“脏活累活”才是评测系统稳定可信的地基。

最后分享一个比较实用的小技巧：刚开始没经验的时候，不要急着把几百上千个用例全量放进去跑，先挑五十个有代表性的用例，把从提交评测到出报告的全链路打通，确认指标计算口径正确，再逐步扩充样本量。先把指标做“可信”，再把指标做“好看”，顺序反了，后面全是返工。评测系统这块内容后续能扩展的方向也很多，比如多智能体协作场景的评测编排、评测集自动生成、基于失败样本的自动归因，都是值得继续投入的方向。