从 0 到 1 搭建一个智能分析 OBS 埋点数据的 AI Agent|得物技术

一、背景
某天打开组内的 Grafana 仪表盘,突然好奇我们的埋点从被触发后是如何一步一步变成所展示的各种图表的,于是在我进行一系列的探索之后,总结出了以下链路:
在指标工厂新建指标,确定埋点 key 和埋点元数据。
代码中指定埋点 key 和埋点数据,通过 watchDog 发送 kafka 消息到 obs monitor topic。
为埋点指标新建数据处理任务,将消费到的 kafka 消息落到指定的数据表中。
添加新的仪表盘,编写展示数据背后的 SQL 语句。
痛点:每需要添加一个新的数据分析大盘,就需要人工去分析各个表结构、表与表之间的联系、表各个字段的含义等,在充分理解其含义后再费时费力地编写 SQL 语句,并不断调优。这导致 OBS 埋点数据分析的场景相对固化,并且难以支持灵活的数据查询要求。
二、思考
在分析了当前系统的痛点后,我意识到这是一个典型的可以利用 AI 能力来对现有功能进行扩展的场景。因为:
场景多变,因为你不知道用户可能想查看什么样的数据,无法通过代码穷举;
需要了解业务同时又具备编写复杂数据查询 SQL 的人,并且费时费力;
看到大盘数据后,依赖每个人对业务的理解提炼出一套分析报告,报告质量与个人的理解与表达能力相关。
于是我就开始思考能否构建一个 AI Agent,使其能够根据用户的要求,自主地生成各种各样的 SQL 查询语句,并将查询到的数据形成完整的数据分析报告返回给用户。
为了实现这个方案,有几个明显需要解决的点:
如何让 AI 理解每个表中各字段的含义、各个表的作用、表与表之间的联系,从而生成准确的 SQL?
AI 生成完 SQL 之后,如何打通 AI 与数据平台之间的通路,从而成功执行该 SQL 并拿到数据?因为数据库权限不在我这,我无法直接连接到数据库。
如何充分利用已有资源,减少人力投入?毕竟是个人想法,在不确定效果如何的情况下,不好直接打扰平台方专门为我写一些新功能,同时我个人也只能投入一些零碎的时间来做这件事。
三、方案
有了问题后,就带着问题去找答案。
3.1 查询数据 Tool
首先,我需要一个能够执行查询的端点。那么我就去抓取了大盘中的数据所调用的接口,意外地发现,不同的数据调用的是同一个接口https://xxx.com/api/ds/query,只是入参不同而已,而且发现,查询的逻辑是通过 rawSql 将查询语句直接传过去!
于是我将该 Curl 导入到 ApiFox 中,通过不断修改参数,发现最终与查询结果相关的入参可以精简到简单的几个参数:from、to、query(format,rawSql,intervalMs)
那么针对第一个问题我就想到了很好的办法,把这个查询 API 封装成一个 Tool,描述清楚各个字段的含义,就可以让 AI 生成完整的参数来查询它想要的数据。
说干就干,我立马新建了一个 Spring AI 工程,把 Tool 的功能和需要的参数描述清楚。其中 grafanaService.query()内部逻辑就是通过 Feign 来调用上面那个查询的 API。
3.2 表结构 RAG
有了能够执行查询的 Tool 之后,剩下的就是需要 AI 能够根据用户的 query 生成精准的参数以及查询 SQL。
之前了解到公司部署了 RAGFlow 服务:https://xxx.com/knowledge,既然有了,那就得用起来!
创建知识集,发现支持添加飞书文档。
由于我们是需要完整的表结构,所以把配置修改为使用 table 的格式,一行数据便是一个 chunk,以免出现语义上的中断。(埋点数据一般表都较小,语意较为明确。像一些字段很多的大表可能需要考虑更好的方案。)
创建飞书文档,手动到 OBS 的库中把我们想要 AI 帮助分析的表结构拉出来(验证想法时采取的临时方案),但由于建表时的不规范,很多表没有对表中字段添加 comment,这会导致 AI 不理解每个字段的含义,也就无法准确地生成 SQL。因此,我们手动补充每张表、每个字段的描述,以及与其它表之间的关联关系。
将飞书文档添加到数据集中,完成后点击名称查看切片详情。双击每个块也可以查看块的详情。
会发现 RAGFlow 自动给我们生成了一些关键词和问题,这些内容会对召回准确率产生影响。我自己觉得生成的不太准确,所以结合自己理解手动输入了一些关键词和可能的问题。
完成后,可以到检索测试 tab 测试召回的效果,根据结果确定合适的参数。并可以对 chunk 的内容和关键词等等进行适当的调整。
调优完成后,就需要对接 RAGFlow 的 retrive 接口,来把我们知识库召回的流程做成一个 Tool。
3.3OBS Agent
在我看来,想要构建一个能够 work 的 Agent,需要以下几个要素:
Agent=Architecture(Workflow、ReAct、Plan-Execute、Multi-Agent...)+LLM+Context Engineering(Prompt、Tool、Memory...)
本来是想用 SpringAI Alibaba Graph 或者 LangGraph 来构建一个 WorkFlow 类或者 Graph 类的复杂智能体(ReAct、Plan-Execute、Multi-Agent)。但为了快速验证想法和节省个人时间,并且考虑到目前任务相对简单(PE+工具就足以完成),再加上部门正在试用 Trae 这个工具,所以决定基于 Trae 来构建一个 Agent(可以顺便使用他们的高级模型/doge,也可以分享给其它同事使用)。
接入 Trae 之后,Architecture 自然就是 Trae 的 Agent 架构了,根据我使用下来感觉采用的是基于 ReAct 的 Single-Agent。而 Context Engineering 的部分,对话功能以及长短期记忆,自然是 Trae 天生就具备的。而 Tool 则可以借助其自带的一些工具,另外还可以利用 MCP 来进行扩展,比如得物的 MCP 市场,提供了大量好用的 Server,并且可以很方便的发布自己开发的 Mcp Server。于是,我就把在第一步和第二步做的工具,在得物 Mcp 平台上进行发布,供我自己和其他感兴趣的同学使用。
最后,需要一个专门针对我这个场景的 Prompt 来指引 LLM 顺利完成任务,经过我不断的修改,最终形成这样一段 Prompt:
最终,在 Trae 中构建了一个完整 OBS Agent。
添加智能体:OBS 大盘分析
四、成果
最终生成的报告(截取部分):
五、总结
AI 时代来临,我们应该要善于发现当前系统中的哪些部分能够结合 AI 来进行提升,积极拥抱变化,有了想法就去做,边做边想边解决问题,永远主动向前一步。
本文章只是记录了从产生想法到构建 MVP 验证想法的整个过程,这中间当然有很多可以继续优化的地方,我本人目前有以下几个想法,也欢迎大家积极评论,贡献自己的独到见解。
接入数据库数据,通过动态监听 Binlog 的方式来识别各表之间的联系,比如 select 语句的 join,并将这种关系保存到 Neo4j 这种图向量数据库中来实现表结构的 RAG。
基于 LangGraph 或 SpringAI Alibaba 构建 Multi-Agent System,细化各 Agent 的职责,精炼各 Agent 的 Context 构成,以获得更好的效果。例如:协调者 Agent、表结构搜索 Agent、SQL 生成 Agent、分析报告 Agent 等等。
接入飞书机器人,或者使用 AI Coding 工具生成一个前端页面。使得一些非技术人员,例如产品和运营也能很方便地使用。
往期回顾
数据库 AI 方向探索-MCP 原理解析 &DB 方向实战|得物技术
项目性能优化实践:深入 FMP 算法原理探索|得物技术
Dragonboat 统一存储 LogDB 实现分析|得物技术
从数字到版面:得物数据产品里数字格式化的那些事
一文解析得物自建 Redis 最新技术演进
文 /Neeson
关注得物技术,每周更新技术干货
要是觉得文章对你有帮助的话,欢迎评论转发点赞~
未经得物技术许可严禁转载,否则依法追究法律责任。
版权声明: 本文为 InfoQ 作者【得物技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/303b3bfbd83a769aee70ffd3a】。未经作者许可,禁止转载。







评论