智能体评测与传统的软件测试有一个根本差异：被测对象的输出不是确定性的，而是随输入、上下文和模型状态动态变化的。这意味着“测一次通过”几乎没有参考价值，真正需要建立的是持续评测机制——让评测本身成为智能体生命周期里的一等公民，而不是上线前的临时检查。
持续评测的核心，是围绕三个问题构建闭环：能力边界在哪、表现是否稳定、变化是否可控。能力边界对应评测覆盖范围，回答“智能体在什么条件下能做什么、不能做什么”；表现稳定对应回归测试，回答“同样的输入在多次运行中是否给出可接受的结果”；变化可控对应监控与迭代，回答“模型更新、知识调整或流程变更后，行为是否仍在授权范围内”。
评测集的建设是这套机制的基石。它不应只是一批静态问答对，而应包含典型任务样本、边界条件和异常输入三类内容。典型任务样本用于验证主流程是否顺畅，边界条件用于探测超出授权或规则模糊的情况，异常输入则检验智能体在数据缺失、表述歧义或工具调用失败时的兜底表现。评测集需要随业务规则和知识库的更新持续扩充，并保留历史版本，以便追溯表现变化是由哪次调整引起的。
评测方式也需要分层。离线评测用于快速反馈，在发布前用固定样本集验证准确率、完成率和越权风险；线上监控则捕捉真实运行中的失败模式，包括人工接管率、异常识别率和用户反馈。两者互补：离线评测保证“不该错的不能错”，线上监控负责发现“没想到会错的”。如果只依赖其中一种，要么被静态样本的局限性误导，要么被线上噪音淹没，都难以形成可靠的判断依据。
回归测试在智能体场景中尤为关键。模型版本升级、提示词调整、知识库增删、权限配置变化，每一项都可能让原本正常的行为发生偏移。持续评测机制应能在每次变更后自动跑一遍核心评测集，对比变更前后的表现差异。这里要特别警惕一种情况：整体指标没有明显下降，但某些细分场景的行为已经改变。因此评测结果需要按任务类型、风险等级和业务领域拆开看，而不是只看一个综合分数。
与评测机制配套的，是明确的运营责任。评测集由谁维护、异常案例由谁分析、指标变化由谁决策是否回滚，这些都需要在机制建立前就定义清楚。没有责任主体的评测体系，往往在项目初期还能运转，一旦业务节奏加快、变更频繁，就会逐渐荒废，最终退回到“演示环境表现不错”的原始状态。
企业级智能体的成熟度，很大程度上取决于评测机制的成熟度。能力分级描述的是“能做到什么”，而持续评测回答的是“是否一直可靠”。只有把评测嵌入到开发、发布、运营的每个环节，智能体才有可能从试点项目变成真正可规模化、可治理的业务能力。