阿里云刚发布的 AgentLoop 是什么？

Agent 优化，为何要观测先行？

我们无法优化看不见的东西。

传统应用的线上问题是相对确定的，例如一段慢查询、一个内存泄漏、一次超时的 RPC 调用。工程师可以通过 APM 工具定位到具体的代码行，修复后重新部署，问题通常就能解决。这种"发现问题、定位根因、修复、验证"的工作流，是建立在系统行为可预测的前提之上的。

Agent 应用打破了这个前提。一个用户请求到达 Agent 之后，系统会经历一段不确定的执行过程：模型可能选择调用工具 A 而非工具 B，可能因为检索到的上下文不同而生成截然不同的回答，也可能在多轮推理中陷入死循环。同一段 Prompt、同一个模型，在不同时间输入时的行为路径都不完全一样。

因此，Agent 观测的往往不是某个指标是否报错，而是关注输出效果，包括答案的准确度和丰富性、推理和行动规划的合理性，甚至 token 消耗的合理性等。

没有观测，这些问题就是黑箱。当我们无法观测 Agent 到底表现如何时，就谈不上如何优化了。因此先把 Agent 的推理路径（Trajectory）完整地记录下来，形成可分析、可回溯的数据基础，然后才能谈评估和优化。

Agent 应用的观测有什么不同？

上一节我们讲到 Agent 应用，观测的对象变了，并引入一个新名词：Trajectory（Agent 的推理路径）。

Agent 从接收任务到完成任务，中间经历了哪些思考步骤、调用了哪些工具、检索了哪些知识、做了哪些决策，形成了 Trajectory，这条轨迹不是预先编排的，而是 Agent 在运行时自主决定的。

打个比方：传统应用的观测像调试一台自动售货机，投币、选品、出货，每个环节是确定性的流水线。问题是确定性的，根因是可定位的，修复是可验证的。Agent 的观测像复盘一个棋手的对局。面对同一个对手下两盘棋，走出来的局面可能完全不同。你不能说"第 17 手走错了所以输了"，因为第 17 手的选择可能取决于第 12 手的布局，第 12 手又受第 8 手的战略意图影响。

观测的维度变了。

传统观测关注的维度是标准化的，包括延迟、错误率、吞吐量和资源利用率等。Agent 观测需要关注的维度则更加多元，至少包括：推理步骤的合理性（Agent 的规划是否正确）、工具调用的准确性（是否调对了工具、参数是否正确）、检索结果的相关性（检索到的文档是否真正有用）、模型输出的质量（回答是否准确、是否产生了幻觉）、以及 token 消耗与成本效率等。这些都会成为评估器。

这些维度中，有些是可以直接度量的（如 token 数、延迟），有些则需要更复杂的评估方法（如输出质量、推理合理性）。比如阿里云 AgentLoop 是通过引入评估 Agent 来评估，即所谓的 Agent as a Judge。

观测的数据粒度也变了。

传统链路追踪的粒度通常是应用、服务、接口级别。Agent 观测的粒度则是一次对话 sessionId，一次端到端的调用 traceId、一次请求 requestId。每次对话，包含多次端到端调用，一次端到端调用包含多次请求，一次请求又会涉及多个环境变量，包括知识库、工具、上下文、记忆等。要把这些细粒度的数据组织成有意义的观测视图，需要全新的数据建模方法。阿里云 AgentLoop 基于 UModel 自动发现 Agent、Tool、Model 等上下游实体拓扑关系，构建 Agent Ontology 全栈拓扑视图，来还原完整的 Agent 推理路径 Trajectory。

LLM 优化和 Agent 优化，是一套方法论么？

模型优化有一套相对成熟的方法论：准备训练数据、微调或 RLHF、在 benchmark 上评估效果。这套方法论的假设是，模型能力是决定系统表现的唯一变量。但随着 Agent = Model + Harness 深入人心，在 Agent 场景下，这个假设就不再成立了。（之前我们在《阿里云上长出的约束基建》，分享过 Harness 的构成，欢迎点击了解更多）

一个 Agent 的最终表现，是模型能力、prompt 设计、工具定义、知识库质量、编排逻辑、记忆策略等多个因素共同作用的结果。同一个模型，在不同的 Agent 配置下，表现可能天差地别。反过来，一个精心设计的 Agent 系统，即使用能力稍弱的模型，也可能在实际业务场景中表现优异。

Agent 的行为具有三个特点：

• 第一，Agent 的任务通常是开放式的，没有唯一正确答案。一个客服 Agent 回答用户问题，只要信息准确、表达得体、解决了问题，就算合格，但"标准答案"是什么？这很难预先定义。
• 第二，Agent 的执行路径是动态的，同一个任务可能走出完全不同的推理轨迹。你无法用一组固定的测试用例覆盖所有可能的路径组合。
• 第三，Agent 的表现高度依赖上下文。在 A 场景下表现良好的配置，换到 B 场景可能完全失效。这意味着评估必须在具体的业务场景中进行，不能脱离上下文谈好坏。

这些差异决定了 Agent 优化需要一套独立的方法论，而不是简单地复用模型优化的 benchmark 思路。阿里云 AgentLoop 提出了一套更契合 Agent 评估的方法论：MVP 闭环，驱动 Agent 持续进化。（将在本文第五章展开）

Agent 优化的挑战有哪些？

前面三节，我们已经提到了一些 Agent 优化的挑战，这里我们做一个汇总。

第一个层面：数据从哪来？

优化需要数据，需要知道 Agent 在哪些场景下表现好、哪些场景下表现差、具体差在哪里。但在生产环境中，这些数据并不会自动出现。传统的 APM 数据（延迟、错误率）只能告诉你系统有没有出问题，不能告诉你 Agent 的回答质量如何。要获取 Agent 的行为数据，需要对推理过程进行完整的采集和结构化存储，这在技术上并不简单。

Agent 的推理轨迹数据量大、结构复杂、语义丰富。一次典型的 Agent 任务执行可能产生数十 KB 甚至数 MB 的轨迹数据，包含模型输入输出、工具调用参数与返回、检索结果、中间推理步骤等。如何高效采集、存储和检索这些数据，并形成高质量的评测数据集，要提升自动化的程度，也是一个技术挑战。

第二个层面：怎么评？

即使有了数据，如何评估 Agent 表现仍然是一个开放问题。目前业界常见的做法包括：人工评估（成本高、不可持续）、规则评估（覆盖面有限）、模型评估（LLM-as-a-Judge，并不适用于带有 Harness 工程的 Agent）。

要评估这种行为序列的质量，需要一个同样具备 Agent 能力的评估者：它能理解任务目标、能分析推理路径的合理性、能判断工具调用是否恰当、能评估最终结果是否真正解决了用户问题。这就是 Agent-as-a-Judge 的核心思路，用 Agent 来评估 Agent。

第三个层面：怎么改？

发现问题和评估问题之后，最终要回到如何改进。但 Agent 系统的参数空间非常大：prompt 怎么写、工具怎么定义、知识库怎么组织、编排逻辑怎么设计、模型怎么选择。每一个维度都有大量的调整空间，而且这些维度之间还存在复杂的耦合关系。调了 prompt 可能影响工具调用的准确性，改了知识库可能影响回答的完整性，换了模型可能影响整个推理路径。

这种高维、耦合的优化空间，使得 Agent 优化很难靠"拍脑袋"完成，需要系统化的实验方法，包括控制变量、对比实验、量化评估、迭代优化。

这三个层面的挑战，对应着 AgentLoop 产品设计的三个核心模块：全栈观测与审计、评估与实验、资产管理与持续优化。

AgentLoop 如何优化智能体？

AgentLoop 是阿里云面向企业级智能体推出的一站式自进化平台。定位非常明确，不是一个 Agent 开发框架，也不是一个模型训练平台，而是帮助企业把 Agent 从能用提升到好用的工程平台。

从产品能力来看，AgentLoop 通过 MVP 五环来实现智能体的进化：

第一环：Agent 观测与审计。这是所有优化的起点。

AgentLoop 支持 Dify、LangChain/LangGraph、AgentScope 等主流开发框架，以及 OpenClaw、Hermes、Qoder、Claude Code、Codex、Cursor 等客户端，通过无侵入的数据采集方式，获取 Agent 在生产环境中的 Trace 和 Log 数据，不需要修改 Agent 的代码，不需要嵌入额外的 SDK。采集到的数据不只是用户的输入和 Agent 的最终输出，还包括模型调用、工具执行、知识检索、token 消耗等详细记录。

第二环：Agent 轨迹分析。 有了原始数据，下一步是理解数据。

AgentLoop 以 ATIF（Agent Trajectory Interchange Format）为标准格式，对 Agent 的推理轨迹进行结构化分析。轨迹分析不是简单的日志查看，而是对 Agent 推理路径的语义解读，即 Agent 在哪个环节做了决策？决策的依据是什么？工具调用的参数是否合理？检索命中的文档是否相关？这一环的核心工程能力是 Pipeline 数据处理管线。用户可以指定一个数据集和一套清洗模板，例如"Trace QA 问答对提取"，配置数据窗口和触发方式，Pipeline 就会自动批量处理轨迹数据，将非结构化的推理轨迹转化为结构化的评估样本。

AgentLoop Pipeline 支持按小时级数据窗口滚动执行，每次执行处理数千行轨迹数据，平均耗时在秒级，成功率接近 100%。这意味着，生产环境中每天产生的海量轨迹数据，可以通过 Pipeline 自动化地清洗、转化、入库，持续为基准集/测试集输送高质量的评估样本。同时，轨迹分析还支撑在线持续评估，即通过智能采样（无需 Ground Truth）对线上 Agent 的表现进行实时监控。

第三环：Agent 效果评估。

AgentLoop 采用 Agent-as-a-Judge 机制，并提供了 20+在主流业务场景下、经过工程实战的开箱即用的评估器 Agent，基于完整推理轨迹进行深度判断。效果评估覆盖两种场景：线上评估（无 GT），对生产环境中运行的 Agent 进行持续质量监控，通过智能采样发现异常和低分样本；实验评估（有 GT），在受控环境下用标注好的测试集对 Agent 进行量化评分。低分样本会自动回流到基准集，形成数据闭环。评估的维度涵盖任务完成度、推理路径合理性、工具调用成功率、检索相关性、幻觉检测等。

第四环：Agent 实验回测。评估定位了问题、调优产生了新版本之后，需要验证改进效果。

AgentLoop 的实验回测模块提供两种测试模式：CI/CD 基线测试，在每次 Agent 资产变更时自动运行回归测试，确保新变更不会引入退化；场景化测试，针对特定业务场景构造测试用例，验证 Agent 在关键场景下的表现。实验样本从基准集输入，实验结果以多维指标分析报告的形式输出，支持多版本对比。

JOTO 企业落地观察

• AgentLoop 将观测粒度从服务/接口级下沉至单次对话、单次请求、单次工具调用，这对企业部署 RAG 知识工程提出了更高要求——知识片段的召回、重排序、注入时机必须与 Agent 的推理路径强对齐，否则评估器无法归因检索失效的具体环节。
• Agent-as-a-Judge 机制依赖评估 Agent 的稳定性与泛化性，企业在构建自有评估体系时，需警惕其自身也成为新的黑箱。JOTO 在 FDE 驻场共创中发现，客户常忽略评估 Agent 的 prompt 可维护性与版本管理，导致评估结果漂移却难以溯源。
• MVP 闭环强调“实验回测”，但企业真实场景中，基线测试常受限于标注数据稀缺。这要求团队在智能体工程初期即建立轻量级反馈通道（如用户显式评分、隐式行为埋点），而非依赖后期补全，否则闭环将失速。
• AgentLoop 的无侵入采集能力降低了接入门槛，但企业若已存在异构 Agent 架构（如部分基于 LangChain、部分基于自研框架），其统一拓扑建模（UModel）能否覆盖所有 Harness 组件的语义解析，将直接影响 Agent Ontology 视图的完整性与可信度。

JOTO 企业落地观察

• AgentLoop 将观测粒度从服务/接口级下沉至单次对话、单次请求、单次工具调用，这对企业部署 RAG 知识工程提出了更高要求——知识片段的召回、重排序、注入时机必须与 Agent 的推理路径强对齐，否则评估器无法归因检索失效的具体环节。
• Agent-as-a-Judge 机制依赖评估 Agent 的稳定性与泛化性，企业在构建自有评估体系时，需警惕其自身也成为新的黑箱。团队需关注评估 Agent 的 prompt 可维护性与版本管理，避免评估结果漂移却难以溯源。
• MVP 闭环强调“实验回测”，但企业真实场景中，基线测试常受限于标注数据稀缺。这要求团队在智能体工程初期即建立轻量级反馈通道（如用户显式评分、隐式行为埋点），而非依赖后期补全，否则闭环将失速。
• AgentLoop 的无侵入采集能力降低了接入门槛，但企业若已存在异构 Agent 架构（如部分基于 LangChain、部分基于自研框架），其统一拓扑建模（UModel）能否覆盖所有 Harness 组件的语义解析，将直接影响 Agent Ontology 视图的完整性与可信度。