轨迹比答案难评：阿里云把 Agent 评测拆成步骤、路径和结果

轨迹比答案难评：阿里云把 Agent 评测拆成步骤、路径和结果

阿里云云原生社区在 2026 年 7 月 1 日写了企业 Agent 为什么用得越多却没有变聪明。AgentLoop 是阿里云的 Agent 自进化平台，把观测、评测和资产回流放在一条飞轮上。这篇的评测方法比产品介绍更具体：轨迹怎么收、什么叫好样本、评分要分三层，以及一组可以对照的外部数字。文末写明当时仍是 beta。

企业 Agent 停在人工调，个人助手却能靠使用变好

作者把进化分成两类。个人效率助手靠记忆和用户画像变好。文中引用 Anthropic Economic Index：长期使用 Claude 的人，成功率比新用户高 3% 到 5%。企业里的客服或内部数据分析 Agent 则停在人工盯盘和人工优化，机构经验积不下来。全文只处理后一类。

飞轮被分成四步：采集、建数据集、评效果、沉淀进化资产。模型和 Agent 的流水线看起来像，影响行为的因素更多。模型任务是一次调用，输入和输出各一份。Agent 任务是一张拓扑：检索、规划、工具、浏览器、中间状态、反思、回滚，还有并行子任务。LLM-as-Judge（让模型直接给答案打分）对付不了这些新困难。

四道难关：元组、好轨迹、单点分、资产没容器

第一，采集从元组变成拓扑。LLM-as-Judge 收的是（prompt，completion），记日志就够。Agent 要收整条轨迹，每一步形状不同：检索是片段列表，工具是 JSON，浏览器是 DOM 碎片，模型是 token 流。还要按时间和因果关系串起来，保留中间状态和父子调用，外加 token、时延和错误码。存储和追踪成本被写成比 LLM-as-Judge 高数十倍。OpenTelemetry 的 GenAI 语义约定当时仍是草案，没有事实标准，企业多在重复造轮子。

第二，什么叫好轨迹说不清。一条轨迹至少包括：任务怎么拆成子目标；检索了哪些文件和关键词；每次 git、grep、测试的输入、输出和耗时；每步之后对任务的理解更新了什么；在哪一步改了主意以及为什么；每次模型调用的 prompt、响应和 token；最后提交的 diff。结果对了、中间错了三步，或者结果错了、前五步推理是对的，这五步要不要单独当训练信号，人工很难定。轨迹里还有订单、客户名和内部接口返回，脱敏不能只做字符串替换，进数据集前要做结构化清洗。

第三，评分不能只打一个点。Agent 要同时看三层：步骤级，每一步工具调用对不对；轨迹级，整条路径是否合理，有没有绕路、回滚或死循环；结果级，最终交付是否满足要求。三层结论可以完全不一致。

第四，资产没有统一容器。模型侧的资产形态清楚：SFT 数据、DPO 配对、LoRA 权重。Agent 侧还在发散：可以回流去改提示词，收成 few-shot 经验库，做成情景记忆，或抽成可复用 Skill 和子流程。每种消化轨迹的方式不同，没有类似权重的统一容器。前三步做完，资产落在哪、谁来用，经常仍是悬案。于是 Agent 已经在服务更多用户，企业手里的进化资产却未必增加。

观测先补齐轨迹，而不是再记一条问答日志

AgentLoop 用开源的 LoongSuite 自动插桩，把采集对象从元组改成完整 Trajectory。语义叠了三层：OTel GenAI 社区标准（含阿里贡献的 STEP / MCP span 扩展）、AgentLoop 自己的数据契约，以及采集层对 session、turn、step、cost 的扩展字段，合计 55 个 GenAI 语义字段。和第三方源码逐行对比后，LoongSuite 的有效字段覆盖率是 84%，对照产品最高 51%。原文没有公布对照产品的名字，不能把 51% 安到某一家头上。

轨迹提供四种互相核对的视图：调用树看每段 span 的时延占比；推理轨迹还原 ReAct 的思考、工具、观察，用来抓无效循环；时间线区分串行、并行和阻塞等待；追踪拓扑恢复全局调用关系。文中的例子是：把四种视图对上之后，一段 23 秒的时延可以定位到多余的 LLM 循环调用。这是诊断例子，不是平台的平均时延。

只有轨迹还不够，span 仍然是散的。AgentLoop 在轨迹之上用 UModel 建 Agent Ontology：自动发现 Agent、Tool、Model 之间的实体关系，标出哪一步是关键决策、哪一步只是辅助。运维和算法可以按 Agent 看问题，不必在扁平日志里找。

Ontology 上面再接 Trace2Dataset。线上全量轨迹经过接入、降维（过滤、去重、采样）、抽特征（意图、难度、场景标签）、AI 复核和改写，写入目标集，自动形成 Golden Dataset（高质量经典样本）和 BadCase Dataset（典型失败）。整体被写成可省下超过 90% 的 Token 和时间成本。原文没有给出节省前后的绝对 Token 数。

评测用 Agent 看轨迹，不用单点模型分代替

作者引用论文《Agent-as-a-Judge: Evaluate Agents with Agents》。Meta AI 和 KAUST 做了 DevAI：55 个真实 AI 开发任务、365 条分层用户需求。评估器不能只看最终交付，还要检查每一步是否满足结构化要求。同一基准上同时跑人类专家、LLM-as-a-Judge 和 Agent-as-a-Judge。与人类专家的一致性从 LLM-Judge 的约 65% 升到 Agent-Judge 的 90%。文中还写美国人工评估大约 86 美元一小时，Agent-as-a-Judge 的成本只有人工的 1/30。这些是论文数字，不是 AgentLoop 在阿里云业务上复测出来的一致率。

AgentLoop 把这种评法产品化：评估器自己也是 Agent，会规划、调工具、回放轨迹，根据中间状态做多步判断。平台给出 13 个标准评估器，正文点名的包括任务完成、回答的证据支持和工具调用成功率，并允许自定义。支持的检查面是：多轮事实核对和幻觉；工具调用链和结果；复杂任务的目标是否达成；授权、敏感信息和有害内容；跨轮记忆和状态；以及用自定义 Prompt、Skill、Tool 做业务评估器。13 个的完整名单没有逐条列出，不能把上面六类当成十三个名字。

采集、本体、数据集流水线和这套评估器合在一起，被写成持续评测的基础设施。分数本身还不是进化。后面拆成两条路。

第一条是数据驱动调优：从评测结果自动收 BadCase，聚类失败模式，和业务一起改 Prompt、Skill 和工具链，再用回归测试验证。见效快，但节奏仍跟人走。

第二条是轨迹驱动的自进化：运行时记下完整调用和上下文，从成功和失败轨迹抽可复用经验规则，需要时再注入上下文，评注入之后的表现，并继续改经验库。

对应两个组件。记忆库有四种策略：fact、episode、summary 和自定义，把偏好和历史放进可检索的长期层，下次遇到相近请求再注入。经验库抽成功模式，和行业专家一起收成长期记忆或 Skill，相似场景再自动激活。文中点名对照的业界做法是 Hermes 的轨迹自反思、DreamGym 用强化学习合成经验回放，以及 Reflexion 把失败经验喂回去。这些是参照，不是 AgentLoop 的对照实验分数。

没有飞轮时，上线本身会变成退步

作者认为飞轮还不成熟，评测结果要变成资产又很依赖行业经验，所以多数企业 Agent 一上线就开始掉队，做不到越用越聪明。

两组外部调查被用来说明缺口，同样不是阿里云自己的线上成绩。LangChain《State of Agent Engineering》：22.8% 的生产团队完全不做评测；离线评测覆盖率只有 52.4%；在线评测只有 37.3%；32% 的团队把质量列为生产环境的第一障碍。Databricks《State of AI Agents》：采用评测的企业数量，只有采用治理的企业数量的 17%。恶性循环被写成：没有飞轮就不敢放量，不放量就没有观测数据，没有数据就不能进化。

AgentLoop 当时处于 beta，申请入口是钉钉群 168330022816。读这篇时要分开三类数字：3% 到 5%、65% 到 90%、86 美元和 1/30 来自外部索引或论文；84% 对 51%、55 个字段、23 秒、超过 90% 是阿里云对 LoongSuite 和流水线的自述，没有第三方复测，也没有对照产品名称；22.8%、52.4%、37.3%、32% 和 17% 是两份行业调查。13 个评估器只公开了一部分名称。

出处：阿里云，阿里云原生社区，The Second Half of the Enterprise Agent Era: How to Make Agents Smarter the More They Are Used?，2026-07-01，https://www.alibabacloud.com/blog/the-second-half-of-the-enterprise-agent-era-how-to-make-agents-smarter-the-more-they-are-used_603319