企业智能体的下半场，如何让智能体越用越聪明？

先交代一下背景。要让一个企业智能体越用越聪明，核心在于构建一套高效的进化飞轮机制。今天这篇文章，想重点聊聊业务场景下的Agent，也就是那些真正承担客服、数据分析等生产任务的智能体。剖析一下它的进化难点，以及工程落地时的一些实践思路。 先说几个核心判断。Agent进化目前常见的有两类场景：一类是员工办公场景，比如Coding Agent或者通用型的助手，通过记忆用户偏好、协作风格来持续优化体验，这类场景的“越用越聪明”已经看到了一些效果。另一类就是企业对外提供的客服Agent、对内做智能分析的Data Agent。有意思的是，Anthropic发布的Economic Index数据显示，使用Claude超过6个月的老用户，对话成功率比新用户高出3-5个百分点。可以看出，通用Agent的进化路径已经比较清晰。但业务场景Agent呢？目前大多还是企业各自手搓观测、评估、优化，各家的实践经验零零散散。今天要讲的，是后者。

01 企业手搓Agent进化飞轮的现状

进化飞轮通常分为四个环节：数据采集、数据集构建、效果评估、进化资产沉淀。乍一看，和模型进化飞轮的流水线差不多，但影响Agent行为的因素可复杂得多。 模型任务，不过是一次模型调用，输入输出就一对。Agent任务呢？是一条带拓扑结构的线，甚至是一张网络图——除了模型调用，还有检索、规划、工具调用、浏览器访问、中间状态、反思决策、回退，甚至多个并行子任务。因素多了，以前的LLM-as-Judge范式就有点招架不住了。

数据采集难：单点变拓扑，schema不再稳定

LLM-as-Judge用起来挺舒服，采集个(prompt, completion)二元组就行，schema干净，日志一存就完事。但Agent行为评估要采集的是trajectory（执行轨迹）——每一步的输入输出形状都不一样。检索回来的可能是chunk列表，工具返回的是结构化JSON，浏览器返回DOM片段，模型返回token流。要把这些异构事件按时间顺序、因果关系串起来，还不能丢中间状态、不能丢父子调用关系，再加上token用量、延迟、错误码……存储和埋点成本直接翻了几十倍。而且，OpenTelemetry的GenAI semconv现在还处于草案阶段，没有行业标准，企业基本都在自己造轮子。

数据集构建难：一条轨迹是不是好样本，定义更难

LLM-as-Judge从日志里挑prompt-completion对，按token长度、置信度、人工反馈筛一筛就行。但Agent的一条trajectory呢？它包括：规划（如何拆分任务）、检索（搜了哪些文件、关键词）、工具调用（每次git/grep/测试的入参、出参、耗时）、中间状态（每一步对任务理解的变化）、反思/决策分支（哪一步改了主意，为什么改）、模型调用（每次调LLM的prompt、response、token消耗）、最终输出。这一整串顺序串起来，才叫一次任务的Trajectory。 但问题来了：“这条轨迹算优质样本吗？”人肉定义非常棘手。比如最终结果正确，但中间走了三个错误的工具。或者最终结果错了，但前5步推理全对——这5步要不要单独拎出来当训练信号？更麻烦的是，trajectory里包含真实的业务数据（订单、客户名、内部接口响应），脱敏根本不是简单的字符串替换，得做结构化脱敏才能进入数据集。

效果评估难：单点打分失效，需要分层

LLM-as-Judge对一个点打分就行。Agent时代得分成三层来评：step-level（每一步的工具调用是否正确）、trajectory-level（整条路径是否合理，有没有绕路、回退、死循环）、outcome-level（最终交付是否满足要求）。而且，三层结论可能完全不一致——举个例子，最终结果对了，但路径很绕，工具调用也有瑕疵，算好还是算坏？

沉淀进化资产难：经验很难被标准化

模型的资产形态很明确：SFT数据、DPO pair、LoRA权重，行业有共识，工具链也成熟。但Agent时代的资产形态呢？还在分化期：可以回流成prompt改进，可以构造成few-shot经验库，可以做episodic memory，还可以抽成可复用的skill或子流程。每一种形态消化trajectory的方式都不一样，也都没有像模型权重那样的统一容器。结果就是，企业把前三步都做完了，最后一步资产应该落到哪、谁来消费，往往还是个未知数。 所以，Agent上线了、服务的用户越来越多，但企业真正能用来进化的资产可能并没有变多。这就是目前企业智能体进化的真实处境。

02 阿里云AgentLoop的实践

针对上述难题，阿里云推出了AgentLoop——一个面向企业级智能体的一站式自进化平台。它能提供全栈观测与审计、评估与实验、资产管理与持续优化等能力，帮助构建智能体进化飞轮。

第一环：全栈观测分析——完整的Trajectory执行轨迹

AgentLoop通过LoongSuite开源自动插桩框架，把采集对象从二元组升级成完整的Trajectory。 LoongSuite融合了三层语义规范：OTel GenAI社区标准（含阿里贡献的STEP/MCP span扩展）、AgentLoop产品侧数据契约、采集层自有扩展（session/turn/step/cost专属字段），总共覆盖55个GenAI语义字段。在第三方源码逐行对比中，LoongSuite有效字段覆盖率达到84%，而竞品最高只有51%。 LoongSuite采集到的Trajectory提供了四类交叉印证的诊断视图：调用树（逐层下钻Span耗时占比）、推理轨迹（还原ReAct思考-工具-观察序列，检测无效循环）、时序线（区分串行/并行与阻塞等待）、链路拓扑图（还原全局调用关系）。 举个例子，一条23秒的慢请求，通过这四层视图交叉定位，可以精确到“某一轮LLM的多步冗余循环调用”这个粒度。

第二环：Agent Ontology + Pipeline，让观测数据图谱化，自动构建高质量数据集

有Trajectory还不够，否则观测数据仍然是孤立的元数据——一条条互不关联的span。 AgentLoop在Trajectory之上做了第二件事：基于UModel构建面向Agent实体关系的拓扑，称为Agent Ontology。它的作用是把采集到的观测数据图谱化，自动发现Agent → Tool → Model之间的实体关系拓扑，打破数据孤岛，实现确定性的关联与推理分析。 有了Agent Ontology，每一条Trajectory就是一张有拓扑结构的关系图。哪个Agent调了哪些工具、哪些工具背后调了哪个模型、哪一步是关键决策节点——运维和算法团队能直接用Agent视角看问题，不用在扁平日志里大海捞针。 在Ontology之上，AgentLoop再叠加了一条自动化Pipeline：Trace2Dataset。逻辑很清晰：线上全量运行时数据（Trajectory）经过Pipeline编排——数据源接入 → 数据降维（过滤/去重/采样） → 特征提取（意图/难度/场景标签） → AI审核与改写 → 写入目标数据集，自动构建成Golden Dataset（高质量经典样本）和BadCase Dataset（典型失败案例）。整体上，Pipeline能节省90%以上的Token消耗与时间成本。

第三环：内置标准化评估器，准确评价每个Agent的真实表现

数据采集了、数据集构建了，接下来就是评估。Meta AI与KAUST团队在《Agent-as-a-Judge: Evaluate Agents with Agents》论文中构造了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采用了Agent-as-a-Judge评估器——把这一范式产品化了。评估器本身就是一个Agent，基于大模型做规划、调用工具、回放轨迹、并基于中间状态做多步推理来做出判断。 AgentLoop提供了13个标准评估器，包括Agent任务完成度、回答证据支持度、工具调用成功率等，还支持自定义模式。 这些评估器覆盖了：问答准确性（多轮事实核验+幻觉检测）、Skill执行质量（工具调用链验证与结果校验）、意图达成度（复杂任务目标满足评估）、安全合规（越权/敏感信息/有害内容检测）、上下文一致性（跨轮次记忆与状态追踪）、业务自定义（用户通过自定义Prompt+Skill+Tool构建特定场景评估器）。 总的来看，AgentLoop通过全量自动化数据采集、Agent Ontology、自动化构建数据集的Pipeline、Agent-as-a-Judge范式的评估Agent，实现了持续评估——这就是进化飞轮的基础设施。

第四环：记忆库与经验库，智能体进化的上下文工程

但话说回来，全栈数据采集、拓扑认知、评估，本质只是给Agent效果打个分。真正让飞轮转起来的，是把评估结果转化成进化资产来提升实际效果。 AgentLoop把这个问题拆成两条路径： 路径一：数据驱动的Agent调优。从评估结果中自动收集BadCase → 失败模式聚类 → Agent端到端改写（Prompt/Skill/工具链协同改写） → 回归测试验证提升。这是“快速拉升基线”的路径，见效快，但依赖人工迭代节奏。 路径二：Trajectory驱动的自进化闭环。Agent运行时自动记录完整调用轨迹与上下文 → 从成功/失败Trajectory中自动提取可复用经验规则 → 经验规则按需注入Agent上下文（Just-in-Time加载） → 评估注入后效果，持续迭代优化经验库。 要将这两条路径产品化，AgentLoop提供了记忆库与经验库两个独立组件。记忆库覆盖事实、情节、摘要和自定义四种策略，把用户偏好和历史上下文沉淀到长期可检索层中，下次遇到类似请求时自动注入。经验库则聚焦成功模式的提取与复用，通过与各行业业务专家共建，泛化成经验规则，归纳为长期记忆或Skill，相似场景出现时自动激活。 AgentLoop的记忆库和经验库，参考了业内在自进化领域的成功实践，包括Hermes的轨迹自我反思[2]、DreamGym合成经验回放的RL训练框架[3]、Reflexion的episodic reflection（失败经验回灌机制）[4]。 所以，全栈观测采集完整Trajectory、Agent Ontology让数据图谱化、Pipeline自动构建数据集、标准化评估器准确评价真实表现、记忆库/经验库把好的经验反哺回去——这就构成了一个自进化的完整飞轮。

03 进化飞轮，是企业智能体下半场的发令枪

进化飞轮的基础设施还不成熟，评估结果转化为智能体进化资产还依赖行业经验，导致大部分企业智能体出现“上线即落后”的窘境——越用越聪明的预期很难实现。 LangChain的《State of Agent Engineering》报告显示，有22.8%的生产团队完全不做评估，离线评估覆盖只有52.4%，线上评估更是只有37.3%，32%的团队把“质量”列为生产环境的头号障碍。Databricks的《State of AI Agents》给出了另一组数据：接入评估的企业数量，仅有接入治理的企业数量的17%。 大部分企业面临的现实困境是：缺少进化飞轮基础设施，不敢放量；不放量就没有观测数据；没有数据就无法进化——这正是典型的恶性循环。 阿里云AgentLoop希望用完善的进化飞轮基础设施，携手企业开启企业智能体的下半场。 **相关链接：** [1]《Agent-as-a-Judge: Evaluate Agents with Agents》https://arxiv.org/abs/2410.10934 [2] Hermes的轨迹自我反思 https://hermes-agent.nousresearch.com/docs/ [3] DreamGym合成经验回放的RL训练框架 https://www.emergentmind.com/papers/2511.03773 [4] Reflexion的episodic reflection（失败经验回灌机制）https://arxiv.org/abs/2303.11366