专题演讲嘉宾：张鑫

把 AI Agent 接入企业系统时，主流做法是堆 RAG 或把数据塞进上下文。但可观测数据天然是分散的指标、日志、拓扑、变更——Agent 拿到的是碎片，回答不了“谁影响了谁”“为什么慢”“这次故障谁的锅”。本质问题不是数据不够，而是数据没有“意义”。

本次分享提出一条不同路线：先建一层可观测对象图语义层，把实体、关系、拓扑、指标、日志统一成 Agent 能查询、能多跳推理的上下文，并讲清它与 OpenTelemetry / Prometheus / CMDB 是补充而非替代。技术上覆盖三块：统一的 SPL 查询面（一套契约同时服务人、CLI、Web、REST 与 AI Agent）；通过 MCP 把对象图安全暴露给 Agent；以及专为 Agent 设计的 plan/data 查询契约与紧凑响应信封。

演讲提纲

1. 为什么“更多数据 / 更大模型”解决不了 Agent 的可观测问题（含踩坑）
   • 三种常见失败模式：直接把日志/指标塞进上下文、纯向量 RAG、给 Agent 开一堆领域专用 API
   • 踩坑实录：碎片化导致 Agent 看不到关系、token 爆炸、关系靠 LLM 脑补产生幻觉根因
   • 结论：缺的不是数据量，是“对象图 + 关系语义”这一层
2. 对象图语义层怎么建
   • 核心对象：EntitySet（对象类型）、关系/拓扑、数据集（指标/日志/事件）、存储与字段映射
   • 一套 SPL 查询面（.umodel / .entity / .topo / entity-call）同时服务人和 AI——为什么坚持“单一读取面”而不是领域专用 API
   • 与 OTel / Prometheus / CMDB 的映射姿势：补充而非替代
3. 把对象图接给 AI Agent
   • MCP 工具/资源面设计：默认只读、写操作默认关闭的安全边界
   • plan vs data 范式：开源侧只产出“查询计划”，把执行留给下游 executor，为什么这么设计
   • 踩坑：给人用的响应信封对 Agent 不友好（双层 JSON 嵌套、噪声字段占 ~85% token），如何重做出 ?format=agent 紧凑信封——上下文体积压缩约数倍
4. 真实场景：Agent 走一遍故障定位（开源 demo）
   • 定位 degraded 服务 → 拉自身指标/日志 → 加载 Runbook → 查上游变更 → 排除“红鲱鱼”无关发布 → 跨域发现促销流量放大 → 关联出根因并给建议
   • 关键设计：Runbook 引导的结构化诊断 vs Agent 自由发挥；为什么故意埋一个“看似元凶”的干扰项
5. 落地 tradeoff 与开源共建
   • 建模成本、语义层维护、与现有可观测栈的边界
   • 开源路线：GraphStore Provider / Domain Profile / 一致性验证的共建入口

这样的技术在实践过程中有哪些痛点？

• 前期建模有成本，不是开箱即得：要把“藏在人脑里的系统知识”（谁调用谁、变更影响哪些服务）显式建模出来，初期投入不小。
• 语义层会 rot：对象图必须跟系统演进同步维护，否则会和现实漂移，反而误导 Agent——这是长期维护负担。
• 价值强依赖关系数据质量：关系缺失或错误会让多跳推理走偏；对象图放大了“关系正确性”的重要性。
• 不是银弹：它解决“上下文结构与可推理性”，不解决底层采集质量；与现有可观测栈是补充关系，不能替代。
• plan/data 分离的代价：灵活性换来的是——纯开源侧拿到的是查询计划而非数据，真正取数需要下游 executor 承接。
• 要维护“两套表达”：给人看的响应和给 Agent 看的紧凑信封需要分别设计，多一份契约维护成本。

听众收益

• 一套可复用方法论：如何把分散的指标/日志/拓扑/变更组织成 AI 能推理的对象图语义层，而不是无脑堆 RAG 或换更大的模型——附判断“该不该建、怎么建”的决策依据。
• 面向 Agent 的 API / 契约设计经验：plan vs data 范式、把上下文 token 成本压缩约数倍的响应信封设计，可直接迁移到自己的 Agent 平台。
• 一个开源可复现的 AI 故障定位范式 + 诚实的 tradeoff 清单，帮助技术决策者少踩坑、看清边界。