聊一个近期大家问得比较多的话题：Horizon UI 新加入的 AI Assistant。这玩意儿不是噱头式的“大模型对话框”。它真的能和你的监控系统数据对话——用和 UI 完全相同的图表、拓扑和表格，回答关于 live system 的问题。而且它只读、继承权限、跑在你自己的模型上。

说明一下背景。《Meet Horizon UI》系列本来已经用 17 篇文章完整讲完了 SkyWalking 新控制台的每一个界面：全局侧边栏、自适应 Dashboard、拓扑图、3D 地图、Trace 和 Log 浏览器、性能剖析、告警、操作面、访问控制，以及配置驱动的定制化。这一篇是 Horizon UI 1.0 发布时带来的新章节，也就是内置的 AI Assistant——它让你可以像聊天一样去查询可观测性数据，而不用一层层点进菜单里去找。

能看见的答案，而不是一堵文字墙

核心设计：展示而非描述

Assistant 的核心设计理念是四个字：show, don’t describe。它会先写一两句话，然后画出真实的图形，解释图里实际出现了什么，再进入下一轮分析。每一个 figure 都是真实渲染的，不是截图，也不是编出来的数据。它会根据底层 metric expression 的形状，选择合适的展示方式：折线图、单值卡片、Top-N 列表、带标签的表格、记录列表等等。

画出的每个 block 都带有一个连续递增的 Figure N 编号。所以叙事可以准确指向自己渲染出的图，而不是泛泛地说“这个响应时间图显示了异常”。

不只是画图，还能嵌入完整的视图

更重要的是，它不只是画图。当问题涉及对象之间如何连接，或者某个东西运行在哪里，assistant 会把真实的 feature view 以内联、只读的方式嵌进对话里。它用的就是那些专用页面里相同的组件。具体包括：

• 依赖视图：聚焦单跳拓扑（某个服务直接的 upstream callers 和 downstream dependencies）、跨层层级结构（Smartscape fan，把 service 向上映射到 mesh mirror，向下映射到底层基础设施）、部署图、源到目标对的实例映射、以及 API 依赖链。所有这些视图在对话里都可以缩放和过滤。
• 信号浏览器：真实的 Trace 列表，点击某一行就能看到它的 Span Waterfall（原生 SkyWalking 和 Zipkin tracing 层都支持）；还有存储的日志视图、浏览器应用的错误流和堆栈追踪。

图 1 展示的是：当问题是“服务之间如何连接”时，assistant 直接在对话里画出依赖图，无需跳转，用的也是拓扑页面同一套组件。

基于实时数据，不会编造指标

三类数据来源的组合

这些 figure 之所以可信，是因为 assistant 不是在自由联想你的系统。它把三类来源组合起来回答问题。正是它们之间的相互配合，能把分散的信号变成一张连贯的图：

• 实时数据：它通过 dashboards 使用的同一个 OAP 查询协议读取数据——你看到的就是 dashboards 看到的内容，并且受你的权限和它自己的时间窗口限制。
• 你的 Layer 配置，当作技能使用：layer 和 overview templates 是 assistant 认识每个 layer 的目录：有哪些 curated metrics 和它们的 MQE 表达式、每个 metric 属于哪个实体范围（Service / ServiceInstance / Endpoint）、以及这个 layer 有哪些 components。它会原样渲染这些表达式，而不是临时编造指标名——所以 chat 里的 figure 和 dashboard 是完全对齐的。如果某个 layer 没有 trace component，它也会直接告诉你。
• SkyWalking 的模型：layers、scopes、metric catalog、topology 和 hierarchy。这些是连接不同数据点的组织层，让它能把 metric 绑定到对应实体，并沿着依赖边继续分析。

可扩展的目录

这里带来一个很好的结果：目录来自你自己的配置，也就是在 Layer Dashboards Admin 里编辑的内容。所以它也是你可以控制的扩展点。给一个 layer 加个 metric，或者启用 traces/logs component，下一次 investigation 就会立刻用上。把 layer 配好，本质上就是在扩展 assistant 的能力边界。

图 2 展示的是：在画任何东西之前，assistant 会先用和 UI 完全相同的 building blocks 建立方向感——列出 layers 和 services，浏览 metric catalog。因此，每个 figure 都是基于目录的查询。

有引导的根因分析，也知道何时该停下来

沿着依赖图追踪到源头

当你在对话框里输入 “what’s the root cause”，assistant 不会盲目漫游。它会加载匹配的 investigation playbook：一个主方法，再加上针对延迟、错误率/SLA、饱和度、中间件依赖、Kubernetes 工作负载或服务网格的变体。

当一个 service 看起来不健康时，原因可能在它自己身上，也可能在它依赖的东西上。所以 assistant 会沿着依赖图一路追踪到问题源头，也就是那个 root service，而不是停在第一个症状上。它会区分 service 自身故障和它从被调用的 dependency 继承来的故障。找到根因之后，它继续深入到那个 service 最慢的 instances 和 endpoints，再触及 error stack。当线索离开 application tier，它会沿着跨层层级结构向下进入底层基础设施。数据库、缓存或队列通常是拓扑的叶子节点，没有更下游的服务，所以 investigation 会在那里触底，然后转向它的日志、Kubernetes 层级和网络边缘——因为内存/磁盘/连接压力这类原因，往往就在这些地方。

按需日志与明确停止

对于 Kubernetes 工作负载，它可以拉取 pod container 的按需日志，也就是 error stack，并把获取到的日志行作为只读结果内联展示。这些日志直接从集群流式取来，不会被存储。这个 block 不是实时终端，所以如果需要更新的行，可以再问一次，或者打开专门的 Pod Logs tab 保持 tail。它继承你的 logs:read 权限，并受 OAP 能力控制。如果按需日志功能关闭了，assistant 会直接说明，不会默默地失败。

更关键的是，它知道什么时候该停止。当现有数据和工具无法进一步定位原因时，它会给出有边界、诚实的答案：结论或最佳假设、背后的证据，以及一个编号列表，逐条说明它无法确定什么、为什么无法确定——而不是在随机 pods 和 metrics 之间无限循环。对于 Kubernetes，它甚至会把排查工作交接下去，给出精确的 kubectl 命令，让你执行后把结果贴回来。

图 3 展示的是一次 investigation 的结尾：一份总结，而不是死胡同——哪里出了问题、影响了哪些服务、可能是什么模式，以及接下来如何确认。

只读，以及一个需要你批准的动作

只读优先，权限严格

Assistant 的所有 investigation tools 都是只读的：它只观察和解释，不会修改 configuration、rules 或 dashboards。性能剖析（Profiling）是唯一的例外，而且有两层阀门：当 metrics 和 traces 无法定位原因时，assistant 会把 profiling task 以决策卡片的形式提议出来，里面写清楚它发现了什么、为什么 profiling 有帮助、它预期会看到什么。只有你在弹出窗口里批准，并且你持有 profile:enable 权限时，任务才会实际运行。Profile 收集完成后，你可以在后续的对话轮次里让它分析结果。它不会自己触发任何动作。

这种“只读优先”的姿态贯穿始终。进入 assistant 需要 ai:read 权限（内置 viewer、maintainer、operator 和 admin roles 默认都有），但这只代表能打开 chat 窗口。每个 data tool 在执行前都会重新检查自己的读权限：figures 需要 metrics:read，alarms 需要 alarms:read，graphs 需要 topology:read，当然还有 traces:read、logs:read、browser-errors:read。如果你缺少某个权限，对应的工具会被拒绝，并在对话记录里显示为 denied 标志。assistant 不能看到超出你权限范围的数据。

自带模型接入

不需要前沿大模型

这里决定了你能不能真正跑起来：不需要前沿大模型。Assistant 是 vendor-neutral 的，通过可插拔的传输层访问你的模型，不绑定任何特定供应商。默认支持任何 OpenAI-compatible endpoint（托管模型、自托管或本地模型、AI gateway 都可以）；也支持 Amazon Bedrock。你只需要设置 model id、base URL 和 API key，集成就算完成了。

为什么中等规模模型也能胜任

因为可观测性的专业知识不在模型里，而是在 tools、metric catalog 和内置 playbooks 里。模型的工作是编排这些工具，并叙述结果，而不是从零开始理解 SkyWalking（temperature 固定为 0，以获得稳定的 tool-calling）。实际使用中，一个高性价比、具备 tool-calling 能力的模型通常就足够了——你不需要为了得到可靠的 investigation 而付费使用、或者等待市场上最大的模型。

快速配置

启用它只需要一小段配置。可以写在 horizon.yaml 里，也可以完全通过 HORIZON_AI_* 环境变量配置：

ai:
  enabled: true
  provider: openai-compatible  # 或 bedorck
  model: "your-model-id"
  baseUrl: "https://your-endpoint/v1"
  apiKey: "${HORIZON_AI_API_KEY}"  # 秘密——仅通过环境变量设置，从日志中删除

API key 是秘密：只通过环境变量设置，会从日志中自动删除，并排除在审计追踪之外。浮动的 AI Assistant 启动器会对每个已登录用户显示，让功能容易被发现；但在它被启用并指向模型之前，panel 会以只读方式打开，显示一个简短的“请让管理员配置”提示，而不是聊天输入框。System prompt 和 starter example chips 都带有合理的默认值，也可以被完整替换。Starter 还可以嵌入 或 占位符，打开一个自由文本输入框。你输入接近的名称，模型会在查询时将其解析为真实实体。

天生安全

因为 assistant 会读取不可信的操作数据，比如 service 和 pod 名称、告警消息、日志行、trace 文本，所以它被设计为将 tool 返回的一切都当作待分析的数据，而不是要服从的指令。一行日志如果写着“忽略之前的指令”，它会被引用和调查，而不是被执行。Assistant 被要求留在可观测性任务领域内，不展示自己的配置，也不展示其他用户的数据。这一点，加上默认只读、每个 tool 都重新检查读权限，以及日志和审计追踪中的秘密删除，使得这个 assistant 的设计目标就是可以安全地接到真实的生产后端上。

它在哪里，以及如何开始

使用方式与隐私

你可以从启动器把 assistant 打开为侧边抽屉；需要更多空间时，把它展开成 /ai 全页面；也可以弹出到单独的浏览器标签页。它有自己的时间窗口（chat header 里有时钟图标，默认过去一小时），没有 service picker——直接在问题里写 service 名即可。隐私方面：你的模型凭证只存在于服务器配置中，不会进入浏览器；对话历史保存在浏览器的 local storage 中（有上限，跨标签页同步），你可以从 /ai 的历史侧边栏删除任意对话。

如何开始试用

AI Assistant 随 Horizon UI 1.0 一起发布。要试用它，启用 ai: 配置块，指向一个你已有访问权限的模型，然后问出第一个你原本会手动排查的问题。完整配置说明见 AI Assistant 文档。

如果你刚开始了解 Horizon，可以先读系列开篇《Meet Horizon UI · 1/17》和入门指南。然后回来，让 assistant 带你走一遍你自己的系统。