AgentLoop：先记下轨迹，再谈 Agent 评测和优化

AgentLoop：先记下轨迹，再谈 Agent 评测和优化

阿里云云原生社区在 2026 年 7 月 20 日介绍了 AgentLoop。它不是智能体开发框架，也不是模型训练平台，而是给企业级 Agent 用的一站式工程平台：观察推理轨迹、评测表现，再持续优化。文章把「能用」推到「好用」的方法写成 MVP 五环。对测试来说，这篇值得看的地方是它明确区分了没有标准答案的在线监测，和有标注集的实验评测。

为什么优化必须先观测

传统线上问题相对确定：慢查询、内存泄漏、RPC 超时。用 APM 定位到代码行，修好再部署，通常就能验证。这条「发现、定位、修复、验证」默认系统行为可预测。

Agent 打破这个前提。同一个提示词、同一个模型，路径每次都可以不同：模型可能调工具 A 而不是工具 B，上下文解码不同就给出完全不同的回答，多轮推理还可能死循环。所以观测重点不再是某个基础设施指标报没报错，而是结果质量：回答是否准确、是否够用，推理和行动规划是否合理，以及 token 是否花得有效率。看不见这些，优化就没有对象。文章因此要求先完整记下推理路径，也就是 Trajectory，形成可分析、可追溯的数据，然后才谈评测和优化。

观测对象、粒度和评测器分别变了什么

Trajectory 不是事先编排的流程。它是 Agent 从接到任务到做完，自行决定的思考步骤、工具调用、检索到的知识和决策。作者用自动售货机对比棋局：传统应用像投币出货，故障可定位、修复可验证；Agent 像棋谱，对同一个对手两盘也不一样，不能脱离前面的局面去怪一步棋。

维度也换了。传统看延迟、错误率、吞吐和资源占用。Agent 至少要看五类，而且这些维度本身就会变成评测器：推理步骤是否规划正确；工具是否叫对、参数是否正确；检索到的文档是否真有用；输出是否准确、有没有幻觉；token 消耗和成本是否划算。token 数和延迟可以直接量。输出质量和推理是否合理，要更复杂的评测。AgentLoop 的做法是引入评测 Agent，称为 Agent as a Judge（用一个 Agent 来评判另一个 Agent）。

粒度从应用、服务、接口，改成 Session ID、Trace ID 和 Request ID。一次会话里有多次端到端调用，一次端到端调用里有多次请求，每次请求又带知识库、工具、上下文、记忆等环境变量。AgentLoop 用 UModel 自动映射 Agent、Tool、Model 等上下游实体的依赖，建成全栈 Agent Ontology，用来把整条 Trajectory 重新画出来。

不能把模型基准直接套到 Agent 上

文章认为大模型优化的成熟路径是准备训练数据、微调或 RLHF（基于人类反馈的强化学习），再在基准上评测。这条路径假设模型能力是决定系统表现的唯一变量。Agent = Model + Harness 被接受之后，这个假设不成立。Harness 在文中指向阿里云更早的一篇约束基础设施文章，本篇没有再展开它的组成。

最终表现是模型能力、提示词、工具定义、知识库质量、编排逻辑和记忆策略叠出来的。同一模型换一套 Agent 配置，表现可以差很多；设计得好的系统，即使用稍弱的模型，也可能在具体业务里表现好。

由此写出三个特征，并直接否定「固定测试集盖住所有路径」：

1. 任务通常是开放的，没有唯一正确答案。客服答得准确、表达合适、问题被解决，就算合格，但标准答案很难事先写死。
2. 路径是动态的。同一任务可以走出完全不同的推理轨迹，固定用例盖不住所有路径组合。
3. 表现高度依赖场景。场景 A 里好用的配置，到场景 B 可能完全失败。评测必须放在具体业务里，不能脱离上下文单独打分。

对应的方法是 MVP 闭环，让 Agent 持续进化。产品经理 Yahai 在 2026 中国 AI Agent 大会上分享过这个闭环。文章把挑战收成三层，并对应三个产品模块。

数据从哪来。生产环境里的行为数据不会自动出现。传统 APM 的延迟和错误率只能说明系统有没有故障，不能说明回答质量。一次典型任务的轨迹可以到几十 KB 甚至数 MB，里面有模型输入输出、工具参数和返回、检索结果、中间推理。要采集、存储、检索这些数据，再做成能提高自动化程度的评测集，本身就是工程问题。

怎么评。文中点名三种常见做法及其限制：人工评测成本高、不可持续；规则评测覆盖有限；LLM-as-a-Judge 不被认为适合带 Harness 工程的 Agent。评行为序列，需要评测器自己也具备 Agent 能力：看懂任务目标，分析路径是否合理，判断工具调用是否恰当，并评估最终结果是否真的解决了用户问题。这就是 Agent-as-a-Judge。

怎么改。参数空间很大，而且互相耦合：改提示词可能影响工具调用准确率，改知识库可能影响回答完整度，换模型可能改变整条推理轨迹。不能靠猜，要有控制变量、对比实验、定量评测和迭代。三层分别落到全栈观测与审计、评测与实验、资产管理与持续优化。

MVP 五环：从采集到回测

第一环是观测与审计，也是后面所有优化的起点。接入对象包括 Dify、LangChain / LangGraph、AgentScope，以及 OpenClaw、Hermes、Qoder、Claude Code、Codex、Cursor 这类客户端。采集是非侵入的：不改 Agent 代码，也不额外埋 SDK，拿生产环境里的 Trace 和 Log。记下的不只是用户输入和最终输出，还包括模型调用、工具执行、知识检索和 token 消耗。

第二环是轨迹分析。标准格式叫 ATIF（Agent Trajectory Interchange Format，智能体轨迹交换格式）。分析要回答：在哪一阶段做了决定、依据是什么、工具参数是否合理、命中的文档是否相关。工程核心是 Pipeline。用户指定数据集和清洗模板，例如「Trace QA 问答对抽取」，再配置数据窗口和触发条件，把非结构化轨迹批处理成结构化评测样本。Pipeline 支持按小时滚动窗口执行，每次处理数千行轨迹，平均耗时在秒级，成功率接近 100%。这些样本持续供给基线集和测试集。同一环还支持在线持续评测：没有 Ground Truth（GT，事先标好的标准答案）时，用智能抽样看线上 Agent 的实时表现。

第三环是效果评测。Agent-as-a-Judge，并提供 20 多个开箱评测 Agent，文中说它们在主流业务场景里经过工程实践检验，依据完整推理轨迹做判断。两种场景要分开：在线评测没有 GT，在生产环境里持续监测质量，靠智能抽样发现异常和低分样本；实验评测有 GT，在受控环境里用标注测试集做定量打分。低分样本自动流回基线集，把数据闭环补上。维度覆盖任务完成、推理路径是否合理、工具调用成功率、检索相关性、幻觉检测。文章没有公布这 20 多个评测器各自的权重或一份公开榜单。

第四环是实验回测，用来验证改过的新版本。两种模式：资产一变就自动跑的 CI/CD 基线回归，防止新改动引入回退；以及针对具体业务场景造用例的场景测试。实验样本来自基线集，结果是多维指标分析报告，并支持多个版本对照。

第五环是持续优化，既是飞轮的末端，也是下一圈的起点。当前重点有三块：CLI 和 Claw 形态智能体的 Prompt 与 Skill；AgentScope、LangChain 这类高代码 ReAct 智能体的运行时优化；Coding 智能体的成本优化。调参有两种范式。一种根据评测和实验结果，对 Prompt、Skill 和模型配置做多维调整。另一种从经验库自动抽取。阿里云写道，客服、Coding、数据这几类主流场景积累了进化经验，并与企业客户共创；FDE 场景下的智能体资产会回流到 AgentLoop 经验库。用户可以从高质量 Trajectory 里抽出成功模式，做成可复用的经验片段，再动态注入 Agent 上下文。文章说五环的最佳实践还会继续写，本篇没有给出某一条 Prompt 改动带来的分数变化。

进化不是银弹

模型会幻觉，推理会漂，工具会叫错。这些问题无法在上线前穷举，只能在运行中持续发现和修正。作者同时把进化从「万能药」里拿出来：长远看，它和 Harness 一样，是模型能力还没盖住需求时的工程占位。模型足够强以后，这层外部脚手架会被内化，但那一天还远。

真正替不掉的是长尾：每家企业自己的审批流、每个行业的特殊合规、每家公司攒下的领域经验。通用模型不会、也不准备把这些都枚举完。文章认为进化框架的价值，就是让企业用自己的生产数据，持续练出只属于自己的 Agent 或 Skill。模型在前进，业务场景也在一层层变多。在这道缝合上之前，先把执行、观测、进化的飞轮跑起来的人，才拿到下一代企业软件的入场券。

读的时候要守住的限制：每小时数千行、秒级、成功率接近 100%、轨迹几十 KB 到数 MB、20 多个评测器，都是平台方对产品能力的自述，不是一份第三方基准成绩，也没有公开测试集和标注规范。在线评测明确没有 GT，不能把它的抽样监测写成有标准答案的准确率。LLM-as-a-Judge「不适合带 Harness 的 Agent」是本文的判断，不是一份对照实验的表格。第五环的经验注入还没有在本文里给出效果数字。

出处：阿里云，Alibaba Cloud Native Community，What Is the Newly Released AgentLoop by Alibaba Cloud?，2026-07-20，https://www.alibabacloud.com/blog/what-is-the-newly-released-agentloop-by-alibaba-cloud_603378