大模型长程 Agent 怎么测？美团工业级评测体系与双环演进实践

导读随着大语言模型原生工具调用与多步推理能力的跃升，智能体正从单轮对话（ChatBot）全面演进为长程智能体（Long-Horizon Agent）。然而，大模型天然的概率随机性与步骤累积误差，让大量长程 Agent 卡在 Demo 与扩量之间。本文结合美团图灵团队与行业顶尖实践，系统拆解长程 Agent 评测的四大模块、离线 Pass@k 回测门禁、Rubric 二元化机评对齐以及驱动系统自进化的“双环演进”体系。

本文 3001 字，阅读约 8 分钟｜从 ChatBot 到长程智能体 → 长程困局 → 离线防守 → 规模破局 → 系统进化 → 评测体系成熟度自查与避坑指南

从 ChatBot 到长程智能体：传统模型评测为什么彻底失效？

过去几年，很多团队在做 Agent 时都经历过类似的过山车：

在本地写好 Prompt、接入几个工具，跑几个精心设计的 Case，Demo 效果惊艳。然而一旦接入真实生产流量、面对真实用户的复杂意图和脏乱数据，各种不可控的失败就会集中爆发。更致命的是，团队既说不清系统具体坏在哪一步，也不敢轻易修改 Prompt 或升级基座模型——因为往往修好了一个已知 Bad Case，却悄悄引发了另外十个未知场景的能力退化。

这种困局的根源，在于我们对 Agent 评测的认知，依然停留在传统的“大模型打榜”思维里。

大语言模型（LLM）能力的演进，推动了智能体形态的本质跃迁。在单轮对话时代，系统的输入输出非常简单：Query -> Answer。评测关注的重点是回答文本的质量、流畅度与相关性，本质上是在做静态文本答案比对。

但在今天以 Claude Code、OpenClaw 或企业级经营分析 Agent 为代表的长程智能体（Long-Horizon Agent）时代，交互链路彻底变成了 Prompt -> Expected Behavior -> Trace：

图片来源：美团技术团队

这决定了：长程 Agent 的评测对象不再是单体模型，而是“模型 + Prompt + Skill 工具链 + 上下文记忆 + 业务流程”的复杂工程系统。评测的关注点必须从“说得好不好”彻底转向“事情做成没有，以及中间是怎么做成的”。

长程困局：大模型与 Harness 协同下的“指数级脆弱性”

为什么长程任务比单轮问答脆弱得多？这直接源于大语言模型本身的概率生成特性以及模型与智能体支架（Agent Harness）之间的协同关系。

1. 连续步骤下的概率累积衰减

大模型本质上是对 Token 概率分布的预测。即使一个基座大模型在单步工具调用（Tool Use）上的准确率高达 95%，当它被放进一个需要连续执行 10 步的长程任务中时，整体端到端不出错的理论概率只有 0.95¹⁰ ≈ 59.8%。

如果在长程链路中没有鲁棒的容错、自愈机制和过程监控，系统很容易在漫长的试错中耗尽 Token 配额或陷入死循环。

2. 状态漂移与长上下文污染

长程 Agent 随着交互轮次增加，外部工具返回的大量结构化/非结构化数据会迅速填满上下文窗口（Context Window）。大模型不仅面临注意力稀释的挑战，还极易受到历史错误输出的诱导，导致后续规划严重偏离原始意图。

3. 模型与 Harness 协同训练（Agentic Post-Training）的绑定效应

在工程实践中，Agent = Agent Harness（支架系统） + LLM（推理大脑）。

当前头部大厂的顶级长程智能体，基座模型通常都在后训练阶段（Agentic Post-Training）使用特定的沙盒轨迹做过强化学习（RL on MDP Trajectories），通过可验证奖励（Verifiable Rewards，如单元测试通过、数据库状态改变）让模型内化了特定的 XML 标签、思考链（<thought>）和工具调用格式。

这意味着脱离系统单独评测模型是没有意义的。基座模型升级或修改一段 Prompt，往往会彻底打破 Harness 与模型原本形成的默契。看不见执行过程，就绝不可能稳定解决工程问题。全链路白盒化的 Trace 观测基建，是长程 Agent 所有评测的绝对地基。

离线防守：对抗概率随机性的“变更门禁”

为了保证每次代码重构、Skill 新增、Prompt 微调或基座模型升级不带来系统劣化，必须在上线前建立严格的离线回测门禁。

图片来源：美团技术团队

1. 为什么不能单次打分？引入 Pass@k 统计

因为大模型输出天然存在非确定性，同一个 Task 跑一次成功，绝不代表上线后就能稳定工作。在离线回测中，通常采用 Pass@k（运行 k 次 Trial 的统计成功率）和 Pass^k（连续 k 次全部成功的严格可靠性）作为评估口径。

2. 端到端评测集与过程评测集分层

面对复杂的长程业务，评测集必须拆分为两类，二者承担完全不同的职责：

端到端评测集（用户视角）：核心职责是回答“事有没有办成”。例如在商家经营分析场景下，100 个生成周报的任务里，有多少个产出了完全符合业务要求的报告。这是业务方的核心体感，决定“要不要拉响警报”。

过程评测集（系统视角）：核心职责是回答“警报响了该找谁、中间哪一步坏了”。重点拆解意图路由准确率、具体 Skill/Tool 的调用成功率、参数提取正确率与数据合并逻辑。

两者的协同价值在于：只有端到端，你会陷入“知道系统坏了但不知道哪一行代码坏了”；只有过程评测，你会陷入“每个模块测试都是绿的，但组合起来用户就是不满意”。

3. 环境高保真度与一票否决门禁

回测的核心是控制变量对比。离线评测环境中的沙箱配置、下游 Mock 数据必须极度贴近生产环境，否则离线分数与线上表现会发生系统性偏离。在门禁策略上，通常对涉及数据合规、资金安全、越权操作的核心项实行“一票否决”，其他体验项设定通过率阈值。没有接入自动化 CI/CD 的评测门禁，本质上只是建议。

规模破局：用 LLM 评测长程 Trace（Rubric 二元化实操）

长程 Agent 一次任务执行产生的完整 Trace 日志（包含提示词、思考链、工具入参、工具返回、重试记录等）往往高达数万 Token。如果全部依赖人工审核，评测成本和周期将直接拖垮整个研发节奏。

走向机评主导（LLM-as-a-Judge）是唯一的规模化出路。但如何驯服大模型裁判自身的幻觉与评分漂移？美团图灵团队在实践中打磨出的核心解法是：Rubric 指标下钻与二元化（0/1/Unknown）。

图片来源：美团技术团队

1. 经典错误示范：打 0～10 分的模糊主观题

如果在 Prompt 里让大模型裁判：“请评估该 Agent 生成的分析报告是否专业，并按照 0 到 10 分打分”，你会发现人与人之间评得不一样，大模型与人评得更不一样，人机一致率往往只有 50%～60%。

2. 改进方案：下钻为可判断的事实依据

通过将大而模糊的概念，拆解为一组客观二元化检查项（是/否/未知）：

通过把主观感受收敛为具体的事实检查，用机器自动化判定二元结果，再通过微调或 Few-Shot 对齐人类核心评测员的标准。在美团的履约与商家数字化业务中，这种二元化拆解成功将人机一致率从 62% 大幅提升并稳定在 90%～99%，让每天几万次线上长程 Trace 的自动化巡检成为可能。

系统进化：线上发现未知与“双环演进”闭环

离线评测做得再精细，也只能覆盖“已知的场景”。真实生产环境中的用户问法、极端异常和数据漂移，必须依靠线上体系来捕获。

一个具备自进化能力的工业级长程 Agent 体系，由两条相互咬合的 Loop 组成：

图片来源：美团技术团队

1. 第一条：Agent 演进 Loop（修代码与模型）

线上通过影子模式、AB 测试、周期性巡检、报警与随机采样捕获真实异常样本；经过 Case 挖掘与白盒 Trace 归因，精确定位是 Prompt 歧义、Skill 描述不清，还是基座模型能力边界问题；研发团队针对性修复代码、优化 Prompt 或使用业务数据对模型进行 DPO / GRPO 微调；修复后通过离线评测集回测，确认没有破坏老功能，再灰度上线。

2. 第二条：评测体系演进 Loop（校准精密量具）

很多团队会犯一个隐蔽的错误：默认“只要评测判错了，一定是 Agent 的问题”。这会导致 Agent 被不断劣化去迎合一个有缺陷的评测规则。

评测体系演进环的作用是校准量具本身：当归因发现“某个线上严重 Bad Case 在评测集里完全没有覆盖”时，立刻将其结构化沉淀为评测集的错题集；当归因发现“Agent 实际上处理得很完美，但被评测规则判成不及格”时，立刻修正 Rubric 指标定义。

这两条 Loop 共享线上真实样本入口，并在评测资产（黄金集/错题集）处紧密咬合，形成了越跑越准、越迭代越强的正向飞轮。

评测体系成熟度自查与避坑指南

在实际业务推进中，团队不需要一开始就盲目追求大而全的庞大基建，更要避免陷入以下三种典型残缺形态：

图片来源：美团技术团队

务实推进路线：

评测是一门实践科学。在长程智能体的大航海时代，谁能率先把看得见问题、说得清标准、跑得动规模、接得上流程的评测飞轮运转起来，谁就能真正把大模型的不确定性，转化为工业级落地的确定性。

参考资料

— THE END —

文章仅做学术分享，如有侵权请联系删除，非常感谢！