跳转至

云监控 2.0 智能聚类：Trace 意图聚类与 Session 任务聚类的 Agent 可观测分析层

📊 Level ⭐⭐⭐ | 16.0KB

阿里云云原生「云监控 2.0」AI Agent 可观测推出的智能聚类能力，解决的核心问题是：指标与 Trace 已具备，但单凭汇总指标难以定位变化集中在哪类用户任务、难以解释原因——总 Token 上涨可能是请求量增加、复杂任务变多或重复调用/上下文冗余，混在一起统计无法区分业务需求变化与执行效率问题，且某一类任务的恶化会被平均值掩盖。该能力把运行指标与用户实际执行的任务联系起来，先归纳主题、再按主题观察规模/资源/交互表现，从整体波动收敛到具体场景后下钻 Trace 与 Session。

双层聚类架构：Trace 意图层与 Session 任务层

分析流水线分五个相互衔接的环节，Trace 与 Session 两条线各自复用同一套语义聚类与主题归纳流程，形成独立分析结果：

  1. 组装分析数据：按 Trace 关联本次请求、按 Session 串联多轮对话，为理解用户目标准备输入并保留执行数据关联标识。
  2. 提取意图与任务：Trace 分析概括单次请求要完成什么；Session 分析结合多轮对话识别并拆分围绕不同目标展开的用户任务——两者都把用户目标整理为简洁描述。
  3. 语义向量化：Embedding 模型将描述转为向量，使目标相近、措辞不同的请求可比较（如"写得更简洁"与"精简产品文案"同指文案润色）。
  4. 聚类分组：PCA/UMAP 降维后用 HDBSCAN 按向量聚集情况形成任务簇，无需预指定簇数；未满足归类条件的零散样本保留为"未归类"。
  5. 主题归纳与合并：每簇选取代表性任务由模型提炼共同目标生成主题名称/说明，再对各簇主题整体比较以减少重叠、统一分类粒度。

关键设计：聚类依据是提取后的意图/任务目标，而非执行指标——耗时、Token、工具调用等执行指标用于主题形成后的分析维度；系统保留主题与原始 Trace/任务的关联，支持从分布概览下钻到具体执行过程。

Trace 聚类：单次请求执行意图

分析对象是一条 Trace 承载的本次请求目标（一条 Trace 可含多次模型/工具调用）。系统自动归纳出"行情查询/网页信息总结/技术文案改写/Agent 机制分析"等主题，结合请求规模、Token 消耗与用户覆盖呈现使用场景分布。实测发现请求规模与资源消耗错位：代码/机制分析类请求量不高但 Token 消耗突出（更长上下文+更多执行步骤），文案改写/网页总结请求多而消耗低——团队可优先锁定高消耗场景，区分任务本身复杂度与重复调用/上下文冗余的优化空间。

Session 聚类：用户任务拆分与交互摩擦

Session 层的核心概念是用户任务：一项有明确目标的工作（如整理年报摘要），可能横跨多轮交互，一个 Session 可拆出多个任务、一项任务可覆盖多条 Trace。系统分析每轮交互要推进的目标，将服务于同一目标的查询/补充/确认/修正归入同一任务，并识别会话中出现的独立新任务。

交互摩擦（friction）信号是该层最有辨识度的设计：将用户纠正、要求重做、Agent 明确表示无法继续等信号标记为摩擦，普通需求补充与必要澄清不自动计入；摩擦反映交互阻碍，不等同于任务失败——模型和工具调用没有报错，任务仍可能推进不顺。配合任务状态与摩擦信号筛选样本，人工检查得以集中在有代表性的任务上；摩擦轮次定位后回溯原始对话与 Trace 核对输入/上下文/执行记录。任务耗时只汇总关联 Trace 的执行时间，不含用户两次交互间的等待/思考时间。

稳定主题与持续观察

探索阶段用自动聚类认识真实用法；某类需求边界清晰后沉淀为预定义主题，持续归集相近请求，无法归入已有主题的样本为发现新需求保留空间。定时分析按同一分类口径观察请求量/耗时/错误/Token 的变化趋势（如"Agent 开发指南"主题的会话/用户/调用/Token 四线趋势）；改动提示词、模型或工具后，可在相同主题下对比改动前后执行表现——前提是保持主题定义、分析范围与数据覆盖口径一致，并结合任务复杂度判断，避免把工作负载差异当作优化效果、把用户提前放弃误认为效率改善。

闭环改进工作流：以电商转化率分析为例

文章用"商品转化率下降分析"任务串联四步闭环，与 Close the Loop 方法论 的闭环思想一致：

  • 发现需求：聚类识别目标相近的重复请求（"某商品转化率为什么下降"），结合用户覆盖/规模/趋势判断是否值得投入；只有原有主题未覆盖且边界清晰的需求才新增分类。
  • 定位问题：用户追问"具体哪个渠道"而 Agent 只返回整体指标时，核对是正常补充还是遗漏分析——是否做了渠道拆解、工具是否返回所需数据、指标口径是否一致；高消耗请求可在同一主题内框选异常 Trace 对比模型/工具/调用次数/错误/上下文规模差异。
  • 改进能力：在提示词或分析流程补充渠道拆解方法、在知识库明确指标口径、为工具接入分渠道数据；将典型会话整理为回归评测案例，同时保留原有任务样本验证改动不伤已有能力。
  • 持续验证：上线后沿稳定主题归集任务，观察交互摩擦/耗时/Token 变化，结合会话抽查与回归评测检查交付质量。

深度分析

  • 语义抽象先于统计：聚类对象是"提取后的意图"而非原始文本或执行指标。流水线先把请求/任务提炼为简洁描述再做 Embedding 与 HDBSCAN，执行指标（耗时、Token、工具调用）只在主题形成后作为分析维度——直接对原始交互文本分组会让历史消息、工具调用等执行细节掩盖真正的需求，也避免 Token 量等表面特征主导簇的形成。 这与 AgentLoop 数据飞轮 中失败模式聚类的辅助定位不同：聚类在此被前置为可观测的独立分析层，而非优化环节的附属。
  • 开放式分类体系是主题可演化的关键。HDBSCAN 免预指定簇数，未满足归类条件的样本保留为"未归类"而非强制归簇；需求边界清晰后沉淀为预定义主题，无法归入已有主题的样本又为发现新需求留出空间——主题体系随真实用法演化（自动发现→沉淀→持续归集），而不是一次性的静态标签集。
  • 摩擦信号填补了"技术成功"与"任务成功"之间的观测盲区：模型和工具调用没有报错，用户任务仍可能推进不顺——用户反复纠正同一理解偏差、要求重做已有结果，这些都被错误率指标漏掉。系统只把纠正、要求重做、Agent 明确无法继续标记为摩擦，普通补充与必要澄清不计入，且明确摩擦不等同于任务失败。 年报摘要会话的例子表明，摩擦轮次定位后回溯原始对话，能落到"文件识别、上下文理解、Agent 如何解释判断"这类可核查的具体环节。
  • 请求规模与资源消耗错位是常态而非异常：代码/机制分析类请求量不高但 Token 消耗突出（更长上下文+更多执行步骤），文案改写/网页总结请求多而消耗低；Session 层同样观察到代码项目分析任务少而 Token 突出。这意味着按请求量做容量规划会系统性低估分析型工作负载，平均值也会掩盖某一类任务的恶化。
  • 聚类的本质是把可观测的"分母"从请求换成用户任务：总 Token 上涨可能是请求量增加、复杂任务变多或重复调用/上下文冗余，混在一起统计无法区分业务需求变化与执行效率问题；按意图/任务双层组织后，执行指标获得了业务语义，"高频低耗"与"低频高耗"场景得以分开排优先级。 这也解释了为什么逐条翻查 Trace 的人工方式难以规模化：它只能核对个别问题，无法判断同类问题有多普遍、该优先优化哪类场景。

实践启示

  • 按主题而非总量看消耗：先锁定高消耗主题（而非高请求量），再在同一主题内框选异常 Trace，对比模型/工具/调用次数/错误/上下文规模差异，区分任务本身复杂度与重复调用、上下文冗余。
  • 把摩擦信号做成分级筛而非失败标签：只标记用户纠正、要求重做、Agent 无法继续三类信号，用摩擦轮次定位后回溯原始对话与 Trace 核对输入/上下文/执行记录，让人工抽查集中在有代表性的任务上。
  • 对比改动效果前先冻结口径：保持主题定义、分析范围与数据覆盖口径一致，并结合任务复杂度判断变化——否则容易把工作负载差异当作优化效果、把用户提前放弃误认为效率改善；用户覆盖比较同样依赖采集到的用户标识一致。
  • 把典型会话沉淀为回归评测案例：改进上线后将典型会话整理为回归用例（如"能否定位下降渠道并给出数据依据"），同时保留原有任务样本验证改动不伤已有能力——线上交互由此成为评测资产的积累来源。
  • 只有边界清晰且未被覆盖的需求才新增分类：聚类识别出目标相近的重复请求后，结合用户覆盖/规模/趋势判断是否值得投入，避免主题体系被零散需求稀释；指标口径分歧（如转化率计算口径）应回到知识库/指标定义中修正，而非在提示词里打补丁。

定位与评价

这是阿里云 AgentOps 版图上可观测分析层的产品化能力：700+ 开发者摸底 显示 46.7% 团队没有专门可观测工具、52.6% 无数据回灌闭环，智能聚类正是"观测→定位→改进→验证"闭环中把原始轨迹变成可分析场景的中间层。与阿里自家 AgentLoop 数据飞轮（失败模式聚类是优化路径一的环节）相比，本文把聚类从优化侧的辅助环节独立为可观测产品能力，并给出意图/任务双层 + 交互摩擦信号的完整方法栈；HDBSCAN 免指定簇数的设计使主题体系可随需求演化（自动发现→沉淀预定义主题）而非静态标签集。→ 原文存档

云栖升级：云监控 2.0 Agentic Observability 平台级全景（阿里云云原生 2026-10-15，/54 SUPP）

云栖大会实录把本 entity 的聚类能力放回平台级底座：云监控 2.0 双含义框架——Observability by Agents（让 Agent 看懂系统）+ Observability of Agents（看懂 Agent），因果起点 = IDC 预测 2029 年活跃 Agent 超 10 亿、token/API 负载增 1000 倍（读数主体变了需要 by，Agent 自己成为新故障来源需要 of）。

  • by Agents：展示系统→事实供给系统（零覆盖）：三问题=看得全看得真/看得懂（语义与依赖从人脑沉淀到平台）/拿得到用得了（任务级机器接口）；责任边界="事实和接口属于云监控 2.0，模型和执行编排属于外部 Agent"。接入 500+ 组件（+150%）多云全栈（含 AI Agent 场景 OpenClaw/Hermes/Codex/Qoder/Claude Code 直连）；意图式接入五步闭环（描述目标→智能发现→生成方案→Preview 授权[变更前可见]→真实样本验证才算接入完成）；数据治理 Pipeline（统一接入/治理加工/成本路由）产出 Actionable Telemetry。
  • UModel 扩容（零覆盖）：内置 3,300+ 模型定义（10 观测域/214 分组，+85%）、数据源自定义建模、结合 STAROps 智能建模（AI 自动识别数据源/预填语义/推荐关系，人工确认一键发布）；五维语义网络（实体/数据/关系/知识/操作）。
  • 三大入口（零覆盖）：Skill（方法层，怎么做）/ CMS2 CLI（执行层，本地确定性调用可审计）/ Cloud MCP（连接层，标准协议托管）——200+ 工具/21 一级域/覆盖 95% 功能。
  • of Agents：故障不会尖叫（零覆盖）：三困难=链路难贯通/全绿不等于正确/根因在 GPU 层；AI 全栈五层（用户端→Runtime→推理→PaaS→Infra）；四个串联功能=Session Replay 现场还原/端到端轨迹+全栈拓扑（任意一跳下钻到 GPU）/多维分析（Token 用量/成本/模型性能，工具/技能/记忆/RAG 开箱大盘）/智能聚类归因（语义聚类+四类归因——即本 entity 原有能力在平台中的位置）。本文与原聚类能力=平台底座与其中一环的关系。

→ 原文存档