美团 App 内的 AI 助手「小团」背后，站着一类新软件：AI 智能体（能理解用户指令、自己拆分步骤、调用工具完成任务的人工智能程序）。这类助手好不好用，平台过去很难判断——只看最终结果远远不够。研究团队提出的 ATLAS 评估框架，从「单次任务过程」和「长期交互连续性」两个视角给 AI 助手做诊断，并在美团小团的生产流量上完成验证：在线 A/B 实验（把用户随机分两组、对比新旧方案效果的实验）显示，用户参与度、下游业务指标、人工抽检质量三项同步提升。论文于 2026 年 8 月 31 日提交至 arXiv 预印本平台，编号 2608.30685，全文 25 页。

AI 助手需要专门的评估方式

普通软件好不好用，看功能是否正常即可。AI 智能体不同：它像一位新员工，要理解用户的话、决定先做什么后做什么、调用外部工具（查询订单数据库、下单接口、优惠计算服务），每一步都可能出错，而且没有固定剧本——同样的请求，在不同上下文里可能走出完全不同的流程。

现有的评估大多只看最终结果：订单完成没有、回答对不对。问题在于：结果不好时，无法知道坏在哪一环，是没听懂需求、调用工具失败，还是中途丢失上下文；结果看起来好时，也无法确认是能力真的强，还是恰好走运。缺陷藏在过程里，只看结果是看不见的。

双地平线：一次任务与长期关系分开诊断

ATLAS 把评估拆成两个层面，论文称之为「双地平线」：

  • 请求地平线：以单次用户请求为单位，顺着 AI 助手的执行轨迹（每一步思考、工具调用、回应的完整记录）检查，把缺陷定位到具体环节与对应能力——例如「工具调用环节频繁失败」或者「理解环节出现偏差」。
  • 交互地平线：以单个用户为单位，检查助手在多次、跨时段的持续交互中是否保持响应——是否还记得早前的对话内容、回答是否始终贴合用户的情况。服务不是一次性的：用户上午问过订单，下午可能接着追问。

每个诊断信号都带明确的证据范围与判定边界，即「这个结论基于哪些记录、在什么条件下成立」，避免评估凭感觉下结论。

让大模型当裁判，再把裁判做轻

诊断信号由 LLM（大语言模型，用海量文本训练出来、能理解和生成文字的 AI 程序）充当裁判生成。裁判的判定口径不是拍脑袋定的：团队先用真实业务日志中高置信度的样本校准裁判，对齐「什么算缺陷」的标准。在需要更低延迟、更低成本的场景，再把裁判的能力蒸馏（把大模型学到的判定规则压缩进更小的模型）成轻量诊断模型，让评估跑得更快更便宜。

生产验证：美团小团

团队在美团小团的生产流量上做了两组验证。离线实验检验诊断信号的准确度，并用历史回放（把真实请求记录重放一遍）验证基于诊断的策略改进是否有效；在线 A/B 实验直接对比部署前后的用户侧表现，结果显示用户参与度、下游业务指标、抽样人工审计质量三项同步提升。

对企业部署智能体的启示

这篇文章给出了一条可复制的工程顺序：先建评估，再谈优化。没有过程级的诊断，你不知道该改模型哪一环；没有关系级的诊断，助手忘记老用户的上下文这类问题会悄悄累积，短期指标未必立刻暴露。把评估信号做成可执行、可校准、可轻量化的模块，评估本身就成了可以迭代的工程组件——这对任何把 AI 助手放进生产环境的企业都有参考价值。

一句话带走：AI 服务好不好，不能只看最终结果，要看任务过程和长期连续性；ATLAS 把这两件事做成了可落地执行的诊断方法。