巧用OpenManus开发自动诊断Agent，解决复杂问题

作者：杜振鹏，联通软件研究院 数据库研发工程师

首先为大家推荐这个 OceanBase 开源负责人老纪的公众号 “老纪的技术唠嗑局”，会持续更新和 #数据库、#AI、#技术架构 相关的各种技术内容。欢迎感兴趣的朋友们关注！

在自主可控背景下，联通软件研究院为了应对 MySQL 5.7 停服风险、降低商用依赖以及提升软实力等几方面综合考虑，在三年前选择基于 OceanBase 社区版打造自研分布式 CUDB 产品。同时，聚焦数据库产品生态的补齐和人员能力的提升，引进多款商用数据库产品，形成自研+商用的数据库产品体系，解决数据库核心技术问题，助力集团架构升级，完成内部系统可靠战略。
分布式CUDB将产品的开通、使用、监控、运维全面接入联通云，实现产品资源的一点开通、一点交付、一点监控、一点运维和一点操作，为联通云租户提供易用而专业的一站式服务。
在运维过程中，我们不断探索更便捷、易用的方式。尤其大模型火爆后，各种实用的AI Agent横空出世，我们也在该领域展开尝试。本文分享我们在运维诊断方面基于AI能力和obdiag构建智能诊断运维的经验，思路供大家参考。
项目介绍

由于我们部门承接了联通全部业务的 OceanBase 使用需求，管理的生产集群规模非常大，因此当出现问题时，排查具有一定的难度，主要表现在：

• 数据采集碎片化：需要从多个节点手动收集日志和各种指标数据。
  
• 排查工具复杂多样：一次完整的问题定位，涉及到很多的工具，每个工具的使用和分析方式方法都不一样，举个简单的例子，我们在排查CPU使用率高的时候至少需要用到top、日志、perf、obstack、OCP等等工具。
  
• 人工成本高，排查的过程是在不断的和社区专家交互拿回需要的信息的过程，耗时非常长。
  

基于上述痛点，我们和OceanBase社区共建了 OceanBase 敏捷诊断工具（OceanBase Diagnostic Tool，简称 obdiag），实现了对 OceanBase 集群进行一键集群巡检、一键分析、一键诊断，以及一键信息收集。obdiag 使排查路径变得明确，先通过一键巡检发现集群问题，再通过一键日志分析或一键根因分析缩小排查范围，最后通过一键信息收集将有效信息交给社区专家进行更深入的分析。

但上述流程仍然存在“最后一公里的问题”未能解决，即每个环节没有打通。例如，通过一键分析收集到的日志错误码，在深入进行一些场景化分析时需要人为判定。为了打通各环节的链路，我们引入了通用型 AI Agent平台Manus的开源复刻版本OpenManus，通过调用工具与外部世界交互，进而解决复杂问题。与传统的聊天机器人不同，该工具不仅能够理解文本，还能执行具体操作，从而使 AI 成为真正的助手。
借助OpenManus的思考和执行能力，以及 obdiag 的诊断能力，通过将二者改造、结合，我们进一步打造了obdiag AI 助手。
技术实现

obdiag AI 助手的代码结构入口为 app.py，走向 main.py，采用单 Agent 形式。其中 run_flow.py 是基于任务流的处理模式，可以和多个 Agent 协作。只不过，我们目前仍采用单 Agent 模式。

• 1. **Agent ****模块**：采用层次化设计，react.py 实现了思考执行模式、新增的 obdiag 智能体模块后续可通过继承现有智能体创建新智能体降低开发难度等。

  复制代码
• 1. **tool 模块（工具箱模块）**：新增了 obdiag 工具、obrag 工具等。

  复制代码
• 1. **Prompt 模块（提示词模块）**：可定义 Agent 角色和权限，指示 Agent 下一步行动。这种设计具有较强的可扩展性，目前已集成 obdiag 诊断工具，后续可快速集成其他工具，且这些模块需搭配使用。

  复制代码

在具体流程中，工具不断循环“思考—执行—观察”的步骤。其本质是：Agent首先分析当前状态和任务需求，随后通过调用工具来执行操作。在工具执行完成后，Agent将执行结果与提示词相结合，进行下一轮的分析。通过持续循环，逐步解决复杂问题。

然而，这种执行方式存在一个问题：大模型给出的响应可能是错误的，存在一定的“幻觉”。为了解决并减少这种幻觉，我们引入了OceanBase知识库 RAG。其工作流程如下：用户输入一个查询（Query）请求，并经过嵌入式（Embedding）模型转换为向量。随后，系统从向量数据库中进行查找，返回若干个最相关的项 Top N，并对这些项进行重排序，最终返回 Top K 项。这些结果与提示词结合后，再交给大模型进行处理。
成果展示

下图模拟了一个小白用户面临的OceanBase诊断问题。用户询问数据库，而非直接询问“我可以使用哪些诊断工具”。结果显示，系统返回了 obdiag 的一些诊断命令，如“日志收集”、“analyze”、“日志分析”、“check 巡检”等。同时，在界面左侧，系统自动调用了浏览器检索工具，打开浏览器检索官方文档。整个过程均由Agent自动执行。

接下来以具体的 obdiag 使用场景为例，目标是巡检 OceanBase 数据库。在某一阶段，系统返回了“obd check”命令。基于该命令，系统会进一步检查 obdiag 是否已经安装等，并最终帮助用户执行该命令。

后续优化

目前，obdiag AI 助手仍有许多待改进之处。后续，我们将优化以下四个方面，进一步提升使用体验。
·       用户界面：丰富界面设计，开发用户友好的界面，减少手动编辑配置文件的需求，提升用户体验。
·       引入用户确认机制：如果执行过程中需要用户裁决，可以引入用户确认机制。例如在执行到某一关键步骤，如执行 OBI 命令时，系统将要求用户确认后才能继续执行，从而确保操作的准确性和安全性。
·       多 Agent 协作：目前，我们的系统采用的是单Agent模式，未来将增强并行任务处理能力，以提高系统的整体效率。
·       根因分析知识溯源：我们将进一步优化知识工程。例如通过参考官网的优秀博客和文档，努力减少系统中的“幻觉”现象，从而提高系统的准确性和可靠性。


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！