企业级智能体评测体系建设：从离线基准测试到生产环境全链路监控

很多企业在智能体项目立项时，会把模型在通用基准上的得分当作可行性证据；到了试点演示阶段，效果也确实说得过去。真正的问题出现在接入生产系统之后：涉及跨系统查询、权限校验、多轮澄清的任务开始频繁中断，业务侧统计的任务完成率明显低于演示时的观感，而失败方式又极不稳定——同一个问题，今天能办成，明天可能卡在第三步工具调用上。

这正是企业级智能体评测要解决的核心矛盾。通用跑分衡量的是“回答得像不像”，企业真正需要回答的是另外三个问题：任务有没有办成，系统调用是否稳定可复现，出错之后能不能被及时发现并兜住。把这三个问题纳入同一套可量化、可回归、可持续运营的机制，才是评测体系建设的起点，而不是给它加一个更漂亮的分数看板。

跑分与业务成功率之间隔着什么

从通用基准到业务成功率，中间至少有三处结构性断裂，任何一处没有单独评测，都会让上线决策失去依据。

第一处是意图与业务语义的偏差。 通用测试集里的问题通常表述完整、上下文干净；企业真实入口里的输入往往夹杂简称、错别字、历史工单编号和口语化的省略。模型能理解“帮我查一下订单”，不代表它能稳定区分“查订单状态”和“修改收货地址”这类在权限与流程上完全不同的意图。

第二处是工具契约的不匹配。 智能体和企业系统的交界不是自然语言，而是接口参数、枚举值、必填字段和鉴权上下文。模型选对了工具，却传了错误的枚举值或漏了必填参数，在业务侧就是一次失败调用。这类问题在通用跑分里几乎不可见。

第三处是多步决策的非确定性。 智能体每多一步工具调用，路径分支就多一层。即使单步准确率很高，串联之后的端到端成功率也会被显著稀释。这意味着评测不能只看最终答案，必须看执行轨迹。

由此可以给智能体场景下的“幻觉”一个更工程化的定义：它不只是说了不存在的知识，更常见的是用看似合理的参数调用了正确的工具，或者在工具返回异常时编造了一个成功结果。前者制造脏数据，后者制造业务风险，二者都比“答错一句话”更难被发现。

三层评测架构：离线、影子、在线

一套完整的企业智能体评测体系，通常需要三层能力并存。三层不是替代关系，而是分别回答不同阶段的不同问题。

三层之间需要共享同一套指标定义和同一份用例资产，否则离线通过、线上翻车的割裂会反复出现。行业实践中一个被反复验证的判断是：发布前跑一遍测试集只是一种快照式保障，随着流量模式变化、检索文档过期、新的边缘案例出现，质量会在生产环境中自然衰减。持续监控不是可选项，而是评测体系的一部分。

离线阶段：把业务契约变成可回归的用例集

离线评测的价值不在于“跑一次”，而在于“可重复跑”。这就要求把业务规则和执行契约翻译成机器可判定的断言，而不是依赖人工观看输出。

意图与槽位基准

用例应按业务动作组织，而不是按问法组织。同一个“申请退款”意图，至少应覆盖标准表述、口语化表述、含歧义表述、带前置条件（如已发货、超时）的表述四类。评分不只看意图是否命中，还要看关键槽位是否抽全、是否抽对。

工具契约测试

这是企业场景中最值得投入、也最容易被忽略的一层。做法是把工具替换为可断言的桩，直接校验调用序列和参数。

cases = load_cases("contracts/refund.yaml")

for case in cases:
    trace = run_agent(case.input, tools=stub_tools(case.mocks))
    assert trace.calls[0].name == "query_order"
    assert trace.calls[0].args["order_id"] == case.expected.order_id
    assert trace.calls[-1].name == "submit_refund"
    assert trace.calls[-1].args["reason_code"] in case.expected.allowed_codes
    assert trace.final_state == "submitted"

这类测试能抓住大量通用跑分完全无法暴露的问题：参数类型错误、枚举越界、在错误的分支上调用了高副作用接口、以及在工具返回失败后没有重试或降级而是直接编造结果。

轨迹级断言

对于多步任务，评测对象应是整条轨迹而非最终文本。需要显式检查：关键步骤是否遗漏、是否存在多余的高成本调用、中途的护栏判定是否被触发、以及出现异常时的降级路径是否符合预期。轨迹断言的粒度需要权衡——断言太细会把合理的行为差异误判为失败，太粗则抓不住问题，通常建议只对业务上不可妥协的节点做强断言。

上线门槛：把“感觉可以”变成放行条件

没有量化门槛的评测，最终会退化为意见讨论。门槛应当分层设定，因为不同任务的风险等级差异很大。

两个容易被低估的维度值得单独强调。一是成本必须按“每个成功任务”计算，而不是按每次调用计算。 一个正确率高但重试频繁的智能体，其单次成功成本可能远高于表面数字。二是时延本身就是功能的一部分。 一个耗时过长才完成的任务，在很多业务场景里等同于失败，因此时延预算应当和准确率一起进入门槛，而不是作为上线后的优化项。

门槛的判定方式同样重要。采用逐项拦断而非加权总分，可以避免“某项极差但被平均分掩盖”的情况；对于高风险任务，建议设置独立的红线项，任一项不达标即不放行。

生产环境：轨迹追踪、异常告警与人工接管

线上阶段的核心资产是轨迹。一条完整的轨迹应当记录一次运行的模型调用、工具调用及其参数与返回、护栏判定结果和交接动作，它既是排查依据，也是后续用例回流的原料。没有轨迹，线上问题就只能靠用户投诉来描述。

告警设计上，建议区分三类信号，避免把所有异常压成一个“错误率”。

• 结果类信号：任务未达成终态、用户重复提问、会话以转人工结束。这类信号最贴近业务体感，应作为主告警。
• 过程类信号：工具报错率上升、参数校验失败率上升、护栏拦截率突变、平均步数异常增长。这类信号通常先于结果类信号出现，是提前预警窗口。
• 成本与时延类信号：单任务调用次数、token 消耗、端到端时延的分位数变化。这类信号适合做趋势监控而非即时告警，防止成本在不知不觉中失控。

人工接管机制需要在系统设计阶段就定义清楚，而不是等出事再补。常见做法包括：对高副作用操作设置前置确认；当模型置信度或关键槽位完整度低于阈值时主动转人工；当工具连续失败达到次数上限时终止并升级，禁止模型自行“想办法绕过”。接管率本身也是一个重要运营指标，长期偏高说明能力边界没划清，长期为零则可能意味着兜底机制根本没有生效。

灰度发布是把风险控制在可承受范围内的常规手段：先在影子模式下用真实流量对比新旧版本差异，指标稳定后再按小比例分流并逐步放量。关键在于放量过程中保持对上述三类信号的同频观测，而不是放完再回头看。

运营闭环：让每一次告警都变成一条用例

评测体系能否长期有效，取决于失败样本能否稳定回流。建议建立一条固定路径：线上异常轨迹经脱敏与标注后进入候选用例池，评审通过后并入离线用例集，并绑定到对应的回归门禁上。这样每一次生产问题都会转化为一道防止复发的检查，用例集随运营时间增厚，而不是停留在项目初期的那一版。

配套需要两件事：一是用例集的版本管理，让“这次发布比上次差在哪”可以精确回答；二是把评测接入发布流水线，使关键门槛成为合并或上线的自动检查项，而不是一份需要人工确认的文档。

适用条件与几个常见误区

这套体系有明确的适用边界。任务链路短、副作用低、失败可即时人工补救的场景，可以只保留轻量的离线回归加结果类监控；而当智能体开始接触订单、资金、权限、对外沟通等高副作用动作时，轨迹级评测与接管机制就接近于必需。

实践中反复出现的误区有几个：把平均分当作唯一决策依据，掩盖了长尾任务的系统性失败；只评测最终回答，不评测执行过程，导致问题定位成本极高；用例集一次性建成后长期不更新，逐渐与真实流量脱节；以及过早追求自动评分模型的完备性，而忽略了人工标注在小规模高风险样本上的不可替代性。

回到最初的问题：企业智能体的可行性，不应该由模型在通用基准上的排名来证明，而应该由一组与业务终态直接挂钩、可重复验证、可持续观测的指标来证明。把评测从发布前的一道关卡，扩展为覆盖离线基准、灰度验证和线上监控的持续机制，把任务完成率和调用稳定性放在分数之前，智能体才真正具备进入核心业务链路的条件。