有了指标和 Trace，Agent 的问题为什么仍难看清问题？
一个 Agent 上线后，调用量、耗时、错误率和 Token 消耗等监控指标，可以帮助研发和运维团队发现运行变化。但发现波动只是排查的起点：单凭汇总指标，往往难以判断变化集中在哪类用户任务，也难以解释背后的原因。
例如，总 Token 消耗上涨，可能是请求量增加，也可能是代码分析等复杂任务变多，还可能来自重复调用或上下文冗余。不同任务对资源和时延的要求并不相同，把它们混在一起统计，很难区分业务需求变化与执行效率问题。即使整体指标保持稳定，某一类任务的耗时增加或体验变差，也可能被平均值掩盖。
要进一步解释这些变化，团队通常需要逐条打开 Trace，查看输入输出、模型和工具调用；遇到多轮任务，还要沿着 Session 串联上下文，理解用户原本要完成什么、在哪一步反复纠正或要求重做。这种方式能够核对个别问题，但随着交互规模增长，人工翻查和对比的成本也随之增加，更难判断同类问题出现得有多普遍、应该优先优化哪一类场景。
因此，需要把运行指标与用户实际执行的任务联系起来。先将相近请求和任务归纳为主题，再按主题观察规模、资源消耗和交互表现，团队就能从整体波动收敛到具体场景，再下钻相关 Trace 和 Session 核对问题，减少在大量交互记录中逐条查找的负担。
围绕这一需求，云监控 2.0 的 AI Agent 可观测新增智能聚类能力，帮助研发、运维团队从具体使用场景理解 Agent 的运行表现：
- Trace 执行意图聚类：识别单次请求的执行意图，将相近请求归纳为主题，帮助团队按场景分析耗时、Token 与模型和工具调用。
- Session 用户任务拆分与聚类：结合多轮对话，从语义上识别和拆分用户任务，再按共同目标聚类，观察任务推进情况与交互中的问题。
- 主题维度的综合分析：汇总请求或任务规模、用户覆盖与资源消耗，并支持下钻原始 Trace 和会话，筛选值得优化的场景、核对具体问题。
结合预定义主题、定时分析与归因分析，团队可以持续观察同类需求的变化，比较异常请求的执行特征，为性能优化、体验改善和版本验证提供依据。
从交互到主题，智能聚类如何实现
要看清这些需求，首先需要从交互中提炼出用户的目标。一次 Agent 执行可能包含历史消息、工具调用和大量中间结果，直接按原始文本分组，容易让执行细节掩盖真正的需求。分析与聚类因此分为几个相互衔接的环节。
组装分析数据。 系统先从采集到的交互记录中整理请求、响应与相关上下文：按 Trace 关联本次请求，按 Session 串联多轮对话，为理解用户目标准备输入，并保留关联执行数据的标识。
提取意图与任务。 模型基于组装后的数据理解交互：Trace 分析概括本次请求要完成什么；Session 分析结合多轮对话，识别和拆分围绕不同目标展开的用户任务。两者都将用户目标整理为简洁的描述，作为后续聚类的输入。
转换为语义向量。 Embedding 模型将这些描述转换为向量，使目标相近、措辞不同的请求能够被比较。例如，“把这段介绍写得更简洁”和“帮我精简这段产品文案”，都可能指向文案润色的需求。
发现相近任务的分组。 系统通过 PCA、UMAP 降维，再用 HDBSCAN 根据向量的聚集情况形成任务簇。聚类不需要预先指定簇的数量；未满足归类条件的零散样本会保留为未归类，供后续分析。
归纳主题并合并重叠。 每个簇中选取代表性任务，由模型提炼共同目标，生成主题名称与说明，例如“文案润色优化”。随后再对各簇的主题进行整体比较，减少主题重叠，使分类粒度更一致。
图 1：Trace 与 Session 分别提取请求意图和用户任务，各自复用语义聚类与主题归纳流程，形成独立的分析结果。
Trace 与 Session 分别形成各自的主题结果，复用相同的语义聚类方法。聚类依据是提取后的意图或任务目标；耗时、Token 和工具调用等执行指标用于主题形成后的分析。系统保留主题与原始 Trace、任务的关联，支持从分布概览继续下钻到具体执行过程。
Trace 聚类：理解单次请求的执行意图
产品设计时设想的用途，往往只是实际用法的一部分。上线后，有人用 Agent 润色文案，有人请它提炼文档，还有人开始追问代码和架构。即使使用相同的模型与工具，这些请求也代表着不同的需求。
Trace 聚类从一条 Trace 所承载的本次请求中识别执行意图，将相近请求归纳为主题。一条 Trace 可以包含多次模型或工具调用，这里的分析对象是本次请求的目标。
下面的聚类结果中，系统自动归纳出行情查询、网页信息总结、技术文案改写，以及 Agent 机制分析等不同主题。结合请求规模与用户覆盖，团队可以了解哪些需求较为常见、哪些用法集中在特定用户群体，并据此选择值得进一步分析的场景。
图 2：算法自动生成请求主题，结合 Trace 数、Token 消耗与用户覆盖，呈现不同使用场景的分布。
这张分布图也展示了请求规模与资源消耗之间的差异。“Agent系统底层机制与代码审计”的请求量并非最多，总 Token 消耗却较为突出；文案改写和网页信息总结的请求较多，消耗相对较低。代码与机制分析可能需要更长的上下文和更多执行步骤。团队可以先关注这些高消耗场景，再结合具体 Trace 判断消耗来自任务本身的复杂度，还是存在重复调用、上下文冗余等优化空间。
主题还把业务需求与执行过程联系起来。团队可以进一步了解某类请求依赖哪些模型和工具、消耗集中在哪里、出现了哪些错误，并回到具体 Trace 核对。下图以另一批分析结果中的“系统架构审计”主题为例，展示主题详情如何提供这些排查线索。
图 3：“系统架构审计”主题详情示例
按主题组织 Trace 后，研发和运维团队可以先找到高耗时、高 Token 消耗或错误较集中的场景，再检查相关调用链。用户意图为执行指标补充了业务上下文，有助于缩小排查范围，也为判断优化优先级提供依据。
Session 聚类：理解用户实际要完成的任务
用户通常带着一个完整目标而来，例如整理一份年报摘要、分析一次渠道销售下滑，或搭建一个网站。这样一项具有明确目标的工作，就是一个用户任务。为了完成它，用户可能连续补充要求、核对结果和调整表达，也可能在同一段会话中提出另一个独立目标。
Session 聚类能够结合多轮对话的上下文，从语义上识别并拆分用户任务。 系统分析每轮交互要推进的目标，将服务于同一目标的查询、补充、确认和修正归入同一任务，并识别会话中出现的独立新任务，为每项任务提炼目标、关联相应轮次与 Trace。由此，一个 Session 可以拆分出多个任务，一项任务也可以覆盖多条 Trace。
下面用一个简化示意说明任务拆分：围绕年报摘要的内容补充、数字核对和表达调整，归入“整理年报摘要”任务；随后提出的渠道销售分析及其补充要求，则属于另一项任务。多轮交互因此可以按共同目标组织，让需求统计更贴近用户实际要完成的工作。
图 4：用户任务拆分示意。同一会话中的多轮交互，可以围绕不同的独立目标归为不同任务。
完成任务识别后，系统再将不同会话中目标相近的任务聚合为主题，并按主题汇总任务规模、用户覆盖、交互轮次与 Token 等指标。任务对应具体会话中要完成的工作，主题则归纳一类相近任务，帮助团队避免把围绕同一目标的反复追问当成多份独立需求。
团队由此可以了解用户主要把哪些工作交给 Agent，并按任务观察用户覆盖、交互轮次、累计执行耗时与 Token 消耗。任务耗时汇总关联 Trace 的执行时间，不包含用户两次交互之间的等待或思考时间。下面的结果展示了系统从会话中自动归纳出的任务主题。
图 5：自动归纳出的文本优化、网页信息处理、代码项目分析等任务主题，帮助团队同时观察任务规模与 Token 消耗。
在这批结果中，文本风格优化和网页信息处理较为常见；代码项目分析与开发指南生成的任务相对较少，Token 消耗却较为突出。按用户任务观察这些差异，有助于团队确定重点分析范围，再结合任务目标与执行过程评估优化空间。
任务粒度也让体验中的问题更容易被看见。模型和工具调用没有报错，用户任务仍可能推进不顺。 用户可能反复纠正同一个理解偏差，或要求 Agent 重做已有结果。这些交互为发现体验问题提供了线索。
系统将用户纠正、要求重做，以及 Agent 明确表示无法继续等信号标记为“交互摩擦”；普通需求补充和必要澄清不自动计入。摩擦反映交互过程中的阻碍，不等同于任务失败。下图以另一批会话分析结果中的“文档与数据处理”主题为例，团队可以从被标记的任务入手，检查需求理解、执行过程或交付方式中的问题。
图 6：“文档与数据处理”主题详情示例，展示交互摩擦与任务推进情况，帮助团队筛选需要进一步检查的会话。
该主题下的一条年报摘要会话提供了更具体的例子，与前面的任务拆分示意属于不同案例。用户希望得到管理层会议材料，却在过程中与 Agent 反复确认年报文件是否已提供、是否为正确文件。分析结果标记了发生用户纠正的轮次，以及对话中出现的困惑、受挫信号，帮助团队定位需要核对的交互。
图 7：从完整任务回到发生摩擦的具体轮次，结合原始对话核对原因。
这个例子提示团队检查文件识别、上下文理解，以及 Agent 如何向用户解释自己的判断。结合发生纠正的轮次与原始 Trace，研发可以进一步核对输入、上下文和执行记录，确认问题原因。
Session 分析能够从分析范围内的会话中识别值得关注的交互，让人工检查集中在更有代表性的任务上。模型识别出的任务状态和摩擦信号可用于筛选样本，具体结论仍需结合原始对话与执行记录核对。
用同一套主题，持续观察需求变化
知道用户今天在做什么，只是开始。团队还需要了解：哪些需求正在扩大？新增能力有没有被使用？同一类任务的资源投入是否发生变化？
这些问题需要稳定的分类口径。探索阶段可以通过自动聚类认识真实用法；当某类需求的边界逐渐清晰后，再将它沉淀为预定义主题，持续归集相近请求。暂时无法归入已有主题的样本，则为发现新需求保留了空间。
定时分析将这套分类口径应用到持续产生的数据上，帮助研发和运维团队按同一类场景观察请求量、执行耗时、错误和 Token 的变化。用户覆盖统计依赖采集到的用户标识，比较时也需要保持数据范围和覆盖口径一致。
图 8：“Agent 开发指南”主题的会话、用户、调用与 Token 趋势，将同一类需求放在时间维度上观察。
以“Agent 开发指南”为例，团队可以同时关注有多少用户在使用这项能力、产生了多少交互，以及模型调用和 Token 如何变化。如果资源消耗上升，就可以结合需求规模与具体任务进一步判断，是更多用户开始使用，还是同类请求需要更多执行步骤。
在调整提示词、模型或工具后，团队可以在相同主题下对比改动前后的执行表现，检查消耗和时延是否变化、错误是否减少。比较时应保持主题定义和分析范围一致，并结合样本中的任务复杂度判断变化，避免把工作负载差异当作优化效果。
从需求洞察到 Agent 的持续改进
看清需求分布和变化之后，团队可以进一步确定改进优先级：哪些任务值得加强，哪些执行环节需要排查，改动上线后又该如何验证。下面用一个具体场景串联这些分析。
以电商经营分析助手为例，它的服务范围已经明确，但范围内仍有不同的具体需求：查看商品表现、分析渠道差异，或解释某个商品的转化率为什么下降。围绕“商品转化率下降分析”这项任务，可以把需求发现、问题定位、能力改进与上线后的验证联系起来。
图 9：围绕商品转化率下降分析持续改进，按稳定主题观察线上指标，并结合会话抽查与回归评测验证交付质量。
发现需求，确定值得投入的具体任务。 如果线上交互中反复出现“某商品转化率为什么下降”“这款商品的访问用户中，下单比例为什么降低了”等请求，聚类分析可以帮助团队识别目标相近的任务。结合用户覆盖、需求规模和变化趋势，判断是否需要加强这类分析能力。只有原有主题尚未覆盖、且边界逐渐清晰的需求，才需要考虑新增分类。
定位问题，核对分析与执行中的缺口。 假设用户希望解释转化率下降，Agent 却只返回整体指标，用户随后追问“具体是哪个渠道下降？”。团队需要结合原始目标，检查这属于正常补充要求，还是遗漏了必要分析，并核对 Agent 是否进行了渠道拆解、工具是否返回了所需数据、指标口径是否一致。对于高耗时或高 Token 消耗的请求，还可以在同一主题内框选异常 Trace，与当前范围内的其他 Trace 比较，检查模型、工具、调用次数、错误和上下文规模等差异。归因结果提供排查线索，具体原因仍需回到调用链验证。
改进能力，将发现转化为具体改动和评测。 确认原因后，团队可以在提示词或分析流程中补充渠道拆解方法，在知识库或指标定义中明确转化率的计算口径，并为工具接入所需的分渠道数据。将典型会话整理为回归评测案例，检查 Agent 能否定位下降的渠道、提供相应数据依据，同时保留原有任务样本，验证改动是否影响已有能力。
持续验证，结合线上观测与质量评测。 改动上线后，沿着“商品转化率下降分析”这一主题持续归集任务：已有主题沿用原分类，新发现且确认的需求纳入预定义主题。在任务范围和数据覆盖口径一致的前提下，观察交互摩擦、累计执行耗时与 Token 消耗的变化；再结合典型会话抽查和回归评测，检查渠道分析是否完整、数据依据是否充分。交互减少或消耗下降，也需要结合任务结果核对，避免把用户提前放弃误认为效率改善。
智能聚类将分散的 Trace 和会话组织为可分析的使用场景，帮助研发、运维团队找到值得关注的请求，沿调用链核对问题，并持续观察改动后的表现。线上交互也由此成为发现需求、优化执行和积累评测样本的依据。
