Roadmap

dbbot 当前首先是面向 MySQL 生态圈的自动化运维工具，重点是把确定性的数据库动作标准化、文档化、可回放。Roadmap 的目标不是做一个会聊天的壳，而是逐步把底层剧本、变量、校验和审批能力沉淀成可复用的操作系统。

1. 当前阶段：dbbot for MySQL

当前版本的核心能力仍然是 dbbot for MySQL：

用 Playbook 固化单机、主从、MGR、InnoDB Cluster、备份、恢复、监控接入等流程。
用统一 inventory、变量文件和文档降低操作漂移。
用标准化验收手段保证部署成功不只是“任务跑完”，而是结果可验证。

这一阶段的重点是把 MySQL 生态相关的高频运维动作做成稳定、可审计、可复现的基础设施。

2. 下一阶段：把高频动作沉淀成 Skills

在 Playbook 之上，dbbot 会继续把常见运维动作抽象成更小、更稳定的 skills。每个 skill 都应具备：

明确输入：拓扑、实例端口、变量、边界条件。
明确输出：部署结果、状态检查、验收结论。
明确前置校验：版本、主机组、路径、权限、依赖包。
明确失败处理：回滚、重试、补救建议。

适合沉淀成 skills 的动作包括：

新建 MySQL 实例或主从拓扑
为已有实例安装 exporter 并注册进监控
执行备份、恢复和恢复后数据核对
给 InnoDB Cluster 或 ClickHouse 集群做标准化巡检

这一步的目标是减少“人脑记步骤”，把运行知识转换成可组合、可调用的能力单元。

3. 未来阶段：AI Agent 自然语言操作

在 skills 基础稳定后，dbbot 未来会引入 AI agent 入口，但这个入口不是直接替代底层 Playbook，而是作为受控的编排层。

预期的工作方式是：

用户用自然语言描述目标，例如“为 192.168.199.131/132/133 部署一套 8.4 MGR，并接入监控”。
AI agent 将意图解析为具体 skills 和参数。
系统生成执行计划、变量草案和风险提示。
用户确认后，再调用 dbbot 底层 Playbook 执行。
执行完成后返回校验结果、关键输出和补充建议。

这里的关键原则是：

AI 负责理解意图与生成计划。
dbbot 负责执行受控、可验证的底层动作。
高风险变更必须保留人工确认和审计信息。

4. 为什么先做 Skills，再谈 Agent

如果底层动作本身不稳定、变量不清晰、验收口径不一致，那么自然语言只会把问题隐藏得更深。先沉淀 skills，有三个直接价值：

让 AI agent 不必直接拼装大量低层参数。
让同一个动作可以被文档、命令行、Web 和 Agent 共用。
让未来的自然语言能力建立在可验证、可审计的执行单元之上。

5. 当前对外承诺

当前公开版本里，AI agent 自然语言操作 dbbot for MySQL 仍属于 roadmap，不应被理解为已经正式交付的功能。当前正式能力仍以文档站公开的 Playbook、变量约定和操作流程为准。

如果你要从今天开始使用 dbbot，建议按以下顺序理解它：

先把 dbbot for MySQL 的 Playbook 和变量体系用顺。
再把 ClickHouse、Prometheus 等配套能力纳入统一交付流程。
最后再考虑把这些标准动作封装进更高层的 skills 和 agent 入口。