基于观测云数据的 AI 大屏开发实践
本文通过实战展示如何利用自然语言构建观测云可视化大屏。结合 AI Agent、OWL 与 Func MCP Coding,实现数据查询、接口开发、页面生成与即时预览,并通过 AI 核验确保数据准确可追溯,减少开发沟通成本,提升大屏建设与迭代效率。
大屏可视化的业务诉求与交付难点
在监控中心、应急指挥和业务运行分析等场景中,大屏需要把分散的数据组织成清晰的主题、布局和交互。业务人员关注的是哪些信息值得突出、不同视图如何联动、页面能否准确反映当前状态。建设诉求往往同时涉及视觉风格、指标定义、筛选维度和展示方式,并在看到页面后继续变化。
传统大屏开发的主要难点在于需求需要经过多轮沟通与转译。业务人员描述目标,设计人员形成视觉方案,开发人员再落实布局、查询和接口,对“突出重点”“调整层级”“增加联动”的理解容易在交接中产生偏差。修改意见往往要再次经过确认、编码和联调,开发流程因此拉长,业务人员也难以在提出调整后及时看到效果。
现在通过自然语言构建观测云大屏,支持把需求表达、页面生成和反馈调整放入同一个协作过程。使用者提供业务目标与参考页面,Agent 协调数据查询、接口开发和前端实现,生成可预览的结果,使用者再围绕实际页面提出修改,Agent 沿原有上下文继续调整。以可见结果作为沟通依据,有助于减少反复解释和跨环节传递中的信息损耗,缩短需求到下一次预览的反馈路径。
本文从大屏可视化的基础搭建流程出发,讨论自然语言如何连接业务需求、轻量化开发和 AI 核验。CPU 总量卡片用于说明其中一条数据接入与核验链路,同样的方法可用于其他指标卡片、趋势、排行和明细组件。文中的脚本集、接口和资源路径采用示例名称。
观测云与整体架构
| 组成 | 在大屏建设中的作用 |
|---|---|
| AI Agent | 理解需求、拆解指标、生成前后端代码、调用工具并完成联调。 |
| OWL | 接入观测云,探索真实数据、验证字段和查询,提供核对依据。 |
| Func MCP Coding | 将 Agent 连接到 Func,开发、调试和发布数据处理函数。 |
| Func 运行环境 | 持续执行查询与加工,按需定时缓存,提供大屏调用的函数 API。 |
| 大屏页面 | 呈现数字卡片、趋势图、资源明细及二维、三维或 GIS 场景。 |
观测云提供指标、日志和应用性能等可观测数据的采集、查询与分析能力。在本方案中,它既是资源指标的数据来源,也是核对业务结果的分析入口:大屏中的容量、使用率与资源明细,都应能够追溯到目标工作空间中的字段、标签和查询范围。[1]
架构上,OWL 与 Func MCP Coding 属于开发协作层:OWL 帮助 Agent 发现与验证数据,Func MCP 将脚本编辑、草稿执行和发布能力开放给 Agent。运行阶段由 Func API 承接页面请求,并读取按约定更新的数据快照,页面刷新不依赖一次新的自然语言对话。[2]

这套架构将业务表达与数据、代码和页面连接在同一任务上下文中。Agent 可以结合参考设计生成布局,再根据已验证的接口完成组件绑定,当使用者提出调整时,相关需求与实现依据仍可沿用,减少重复交接和重新解释。观测云原生仪表板继续提供查询分析能力,自定义大屏则承载更具体的主题布局与交互。
轻量化来自现有能力的复用与清晰分工。观测云提供数据,OWL 支持探索与验证,Func 封装业务接口,前端使用已有框架、组件和设计素材完成呈现。建设可以先形成可预览的页面和少量核心数据链路,再逐步完善其他组件。示例中的快照适用于约定周期更新的数据,为接口读取提供稳定的数据依据。
自然语言驱动的大屏实践
实践从业务人员对页面的整体表达开始:展示什么主题,哪些指标需要突出,筛选条件如何影响视图,参考样式应保留哪些特点。Agent 结合这些信息生成页面与数据连接,再通过预览承接下一轮反馈。下文以 CPU 总量卡片示范数据探索、服务封装和结果核验,前端目录与脚本集分别使用 dashboard_web/front/ 和 dashboard_demo。
让 Agent 同时连接 OWL 与 Func MCP
协作环境与权限边界
完整的开发协作需要 Agent 同时具备终端执行、MCP 工具调用和前端项目编辑能力。目标观测云工作空间、Func 环境和前端目录构成任务范围,Agent 与 Func Worker 的网络可达性则分别影响开发验证与服务运行。
OWL 连接数据工作空间
OWL 接入涉及站点地址 OWL_REGISTRY_ENDPOINT 与短期授权码 OWL_TEMP_CODE。前者决定工具连接的数据环境,后者用于完成授权,临时授权码可在观测云控制台的「个人 API 密钥」入口生成。

站点 Endpoint 与工作空间所属环境保持一致,私有部署采用实际提供的地址。连接地址使用 Endpoint 根路径,避免重复追加 API 路径。以下任务示例保留了安装与连接验证的必要约束,已有环境则以检查认证和同步工具目录为主。
阅读 https://static.guance.com/owl/skill.md,按官方说明安装和配置 OWL CLI 与基础 Skill owl-diagnostics。
OWL_REGISTRY_ENDPOINT="<工作空间所属站点的 Endpoint>"
OWL_TEMP_CODE="<临时授权码>"
完成后验证 CLI、认证和工具目录同步,列出当前可用的数据查询与 DQL 校验能力。仅检查连接,不修改工作空间资源。
Func MCP 连接开发环境
Func MCP Coding 通过专用 Access Token 建立开发入口,权限以项目脚本集为边界,并按读取、修改、执行和发布等动作分别授予。专用凭据与明确的资源范围,使 Agent 的开发能力能够对应到具体任务。[2]


MCP 客户端的配置语法随客户端而异,连接语义则保持一致:服务地址、认证请求头与资源权限共同确定 Agent 可以访问的 Func 能力。下表列出核心配置要素。
| 配置项 | 填写内容 |
|---|---|
| 服务地址 | https://<Func 访问域名>/mcp/coding |
| 认证请求头 | X-Dff-Access-Token: <专用 Access Token> |
| 权限范围 | 本项目脚本集,开发需要读写和执行,发布按任务授权 |
工具清单与脚本集访问结果共同反映当前会话的权限范围,以下界面展示这类检查信息。

连接验证与能力确认
连接验证关注实际可访问的工作空间和资源范围,而不止于服务是否响应。OWL 的查询能力与 Func MCP 的脚本读写、草稿执行、发布和 API 管理能力分别核对后,数据探索与服务开发才能在同一任务上下文中衔接。
以 CPU 卡片为例核实数据口径
数据验证以具体组件为单位展开。对于 CPU 总量卡片,Agent 从工作空间中的真实字段和标签发现容量指标,例如 system.n_cpus,并与 cpu.usage_total 所代表的负载含义区分。中心、主机和可用区等筛选维度对应实际资源标签。这一过程演示如何把组件需求转化为有数据依据的查询,而非限定大屏只围绕某一项指标建设。
M::system:(last(n_cpus) as cpu_total) [1h] BY host, region, zone_id SORDER BY cpu_total DESC SLIMIT 100
库存指标表达某一时点的资源规模,不能直接累加时间窗口内的全部采样值。示例查询取每项资源在约定窗口中的最近有效值,再按资源标识处理重复记录并汇总。结果完整性还受标签缺失、分页与条数上限影响,因此语法校验只能证明查询可执行,业务口径仍需要通过结果核对确认。
快照作为数据与服务之间的契约
快照将查询证据与业务记录一起保存,包括工作空间、字段和标签、实际时间范围、时区、查询语句、原始结果与聚合规则。数据资源与刷新状态分别存储,例如 dashboard_demo/ecs_inventory_snapshot.json 与 ecs_inventory_refresh_status.json,使服务能够读取同一份数据依据。
这种设计将采集加工与页面读取解耦。快照记录数据时间、指标单位和资源明细,刷新状态记录采集尝试与最后成功时间。更新成功时写入新数据,异常时保留最近成功结果并携带错误状态,避免把一次查询的业务数值固化为页面或函数中的常量。


Func 数据服务与接口契约
Func 将快照转化为适合页面消费的业务接口。示例脚本 dashboard_demo__ecs_inventory 中的 ecs_inventory_cards 通过 DFF.RSRC 读取资源,依据有效参数筛选记录,再生成数字卡片与明细。center 映射到 region,参数只有获得真实标签或查询能力支持,才能具备有效的筛选语义。
接口同时表达数据内容与数据状态:status、data_state、data.cards、data.resources、query_range、last_success_at、refresh_status 和 stale 构成核心契约。卡片携带 value、unit 与 data_time,趋势组件则需要独立的时间点与指标值序列。有效零值、空数据、执行异常和过期结果具有不同含义,不能在展示层合并为同一种状态。
Agent 对开发结果的核验以可执行的对照为依据:在相同筛选条件和时间口径下比较 OWL 查询、快照与草稿函数,检查汇总值、单位和资源明细是否一致,并覆盖空数据、有效零值与异常状态。发布后的代码读回、函数入口绑定和实际 API 调用继续核对版本与请求响应。示例 API 为 dashboard_demo.ecs_inventory.cards,这套核验方式也适用于其他组件的数据服务。
POST /api/v1/func-api/dashboard_demo.ecs_inventory.cards
{"kwargs":{"center":"<中心标签值>"}}
前端依据接口地址、请求封装、有效参数、鉴权方式、单位与响应样例完成绑定。密码、OWL 授权码和 MCP Token 由受控配置管理,页面仅访问业务数据服务,正式访问通过 HTTPS 与适当的服务端鉴权机制承载。

页面生成与即时预览
页面生成同时依据业务需求、参考设计和接口契约。Agent 在 dashboard_web/front/ 中组织页面、逻辑与样式文件,将主题布局、字体、图标、信息层级和响应式要求落实到组件,再绑定已验证的数据接口。CPU 总量卡片只是其中一个示例,趋势、排行和明细视图各自使用对应的数据结构。
可预览页面成为下一轮沟通的载体。使用者可以直接提出“把关键指标移到顶部”“缩小标题占用空间”“让筛选影响相关图表”等调整,Agent 据此更新布局或交互,并再次预览。组件单位、时间和状态仍沿用接口语义,涉及数据变化时,预览与核验同步推进,保持修改后的页面与服务结果一致。
| 组件 | 接口数据约定 | 页面行为 |
|---|---|---|
| CPU 总量卡片 | value、unit、data_time | 展示总量、单位与更新时间 |
| 中心和集群筛选 | 允许的参数及取值范围 | 重新请求关联组件 |
| 趋势图 | 时间点与指标值序列 | 只在历史数据可用时生成 |
| 资源明细表 | 资源标识、名称、容量等已验证字段 | 支持约定的排序和分页 |
| 状态提示 | status、错误说明或过期标记 | 区分无数据、失败与历史缓存 |
页面验证同时覆盖展示与数据行为。目标分辨率和窄屏布局决定内容是否可读,接口请求、字段映射和筛选联动决定结果是否准确,初次连接、轮询更新与异常响应共同影响大屏在持续使用中的可用性。
刷新机制与运行一致性
数据源刷新与页面轮询是两个独立周期。数据源刷新负责生成新快照并更新状态,页面轮询负责重新读取 API,后者频率更高,并不意味着源数据更新更快。采用 OWL 自动化时,刷新链路覆盖查询、资源上传与状态更新,采用 Func 定时任务时,调度入口对应实际更新缓存的函数。

运行验收关注部署后的完整访问链路。Web 文件服务承载前端资源,Func API 提供业务数据,网络与鉴权连接两者。页面访问、接口调用和跨刷新周期的数据变化需要在脱离开发会话的条件下仍保持一致,才能形成独立运行的应用。
自然语言需求示例
完整的大屏需求可以用自然语言同时表达主题、参考风格、指标范围、交互方式和交付约束。Agent 将这些信息连接到页面生成与数据开发,使用者则通过预览判断需求是否被正确理解。下面为任务示例原文。
后续迭代继续采用相同的表达方式。对于布局和视觉调整,Agent 更新页面并提供新的预览,对于筛选联动或指标调整,Agent 沿接口与数据口径检查受影响的部分。需求、反馈和核验始终处于连续上下文中,使自然语言成为大屏建设全过程的协作入口。
使用 dataflux-func-mcp-coding 制作一个完整的大屏,样式如image下的设计稿.png所示,代码放在 demo_website/front/ 下。
使用 OWL 读取观测云数据,打通“ ECS 集群资源库存 — 主中心 CPU 库存 — CPU 总量 ”数字卡片。
通过 Func MCP Coding 开发后端服务,在函数 API 中生成指标接口。
先核实数据来源、字段、统计口径和工具权限,再输出页面布局与接口约定。按已有授权开发和调试,发布前给出可预览页面、接口验证结果和待发布清单。
大屏界面需要符合以下效果:
- 大屏页面色系需要和设计稿保持一致
- 字体大小和设计稿的字体大小保持一致
- 数字和英文使用font-style下的DIN Condensed Bold.TTF字体,中文用鸿蒙文件夹下的字体
- 指标名称前的 icon ,可以从设计稿中的截图下来使用
- 数据使用 Func 函数 API 里对应的指标接口
- 前端使用合适的框架、第三方库实现,并通过文件管理 / 服务提供
开始前先根据 help 文档获取相关信息并确认必要权限
如果权限不满足,返回所需要的权限配置文本
权限满足后,开始创建应用
下图为系统实际 Demo 页面,采用自然语言需求沟通,ui自动生成大屏布局与监控组件,包括 CPU 与 ECS 资源概览,以及 MySQL、Nginx 的数值和趋势视图。

可视化交付效果与方案特色
本方案围绕大屏可视化形成“表达需求—生成页面—预览反馈—调整核验”的闭环。业务人员能够以页面判断信息层级、视觉效果和交互是否符合场景,开发过程则围绕具体反馈继续推进。其价值体现在沟通路径更短、修改结果更易查看,以及展示数据有可核对的依据。

减少需求转译与沟通损耗
业务目标、参考样式和修改意见由自然语言统一表达,Agent 在同一任务上下文中协调查询、后端和前端。可见页面帮助各方更快形成共同理解,减少抽象需求在多次转述中的偏差,后续反馈可以基于当前结果直接提出,降低重复整理需求与重新交接的成本。
缩短修改到预览的反馈路径
Agent 的页面开发与预览能力让调整意见能够连续转化为新的可见结果。布局、色系、字体和组件位置等展示变更可以进入快速迭代,业务人员在看到效果后继续修正,涉及接口或指标的变更则同步完成相应核验。这样既支持更及时的即改即看,也使页面迭代与数据正确性保持衔接。
AI 核验与结果可追溯
AI 核验贯穿查询、函数和页面绑定:对照相同条件下的源数据与函数输出,检查单位、聚合规则、时间范围及字段映射。展示结果保留来源、资源明细和刷新状态,使某个数值或图表能够追溯到查询与处理依据。使用者由此可以同时评估“页面是否符合需求”和“内容是否有数据支撑”。
复用现有能力保持轻量化
方案组合观测云、OWL、Func 与前端已有组件,将首次建设范围控制在可预览页面和核心数据链路上,再按反馈扩展其他模块。公共查询、接口契约、布局和素材可以继续复用,自然语言则组织每一轮新增与调整。轻量化体现为增量建设与减少重复转换,数据核验和运行验证持续为交付质量提供依据。
总结
大屏可视化的建设需要在业务表达、页面效果与数据依据之间持续建立共同理解。自然语言驱动的协作将需求提出、页面生成、预览反馈和后续修改连接起来,减少反复沟通中的信息损耗,并缩短从调整意见到可见结果的路径。
观测云提供数据与分析基础,OWL 和 Func MCP Coding 帮助 Agent 完成数据验证与服务开发,前端预览承接业务反馈。CPU 总量卡片展示了其中一条数据核验链路,更广泛的价值是让各类大屏组件在快速迭代中保持来源可追溯、结果可核对,形成自然语言驱动、能力复用的轻量化可视化建设方式。
参考资料
- [1] 观测云文档 https://docs.guance.com/
- [2] DataFlux Func MCP 编程 https://func.guance.com/doc/mcp-guide-mcp-coding/
- [3] 观测云仪表板 https://docs.guance.com/scene/dashboard/


