01、最初选择开源, 是为了追求公开和共享。1.这是一个问题, 它被问了又问, 直到最后大家都烦了。回顾过去一年时间范围内, 情况呈现了这样的变化趋势。在集成开发环境这个软件中运行的辅助编码的智能工具出现了。在后台负责维护系统稳定运行的智能机器人出现了。数据分析部门所使用的工具出现了。外部合作单位提供的那个支持快速构建应用系统的平台也出现了。上述各个方面都在发生着变化。一种叫做人工智能自动代理的程序正在试图实现一个目的。这个目的就是要把这些程序通过网络连接手段直接接入到数据库中。不同身份的人群在使用该系统时会提出请求。这些人发起询问的行为模式表现出高度一致性。他们几乎都会发出完全相同的请求语句。我就想问一个事情, 到底能不能让那个人工智能去直接上手操作, 那些都放在阿里云平台上面的数据库。可是啊, 等那个大问题一旦真真切切地砸到某个公有云所提供的、名字叫做 RDS 或者 Tair 这些个不同种类的引擎实例上面的时候的话, 那几乎所有的搞技术的人都会在那个时候停在那一块了, 因为大家都碰到了同一个组的、特别现实的问题上面去了。1.第二部分是瑶池 MCP, 这是一个可以被多个不同的场景集成的, 作为云数据库和 AI 协作层的存在。这次开源的瑶池数据库 AI MCP 包名这个--db-mcp-, 在下文中我们通常把它简称为“瑶池 MCP”, 实际上它就是用来解决前面所有这些问题的工程方面的方案。它做的动作是把四件各自分开的事进行封装, 这四件事分别是实例管理、数据面的执行操作、对命令实施安全层面的管控, 以及让瑶池数据库里面的 Agent 能够顺利接入, 最终是把它们统一打包, 变成了一个标准形态的 MCP也就是 Model。任何支持MCP协议的AI客户端, 比如说在IDE里的Qoder, 还有机器人、内部的Agent平台、低代码工作流这些方面, 都能够利用stdio这种即插即用式的方法来把它挂载进来。这样一来, 自己的AI就能立刻获得操作阿里云数据库的能力了, 同时也能调用瑶池数据库Agent的功能。一句话定位瑶池的 MCP, 等于阿里云数据库提供的 AI 中间层。它使得各类 AI 应用都能通过对话的方式进行操作。这其中包括编码助手、运维助手、数据分析助手以及测试自动化工具等。用户可以通过这种对话方式来完成创建数据库、执行命令等工作。同时, 还可以调用瑶池数据库 Agent来进行诊断与调优。这一机制把瑶池控制台中所具备的 AI 协作者能力开放给了所有上游的 AI 客户端。1.它解决的是在哪些具体场景里所呈现出来的那些问题, 这个情况就是这样的。从瑶池数据库Agent这个工具在管理界面里面积累下来的那些真真切切的问答记录里头可以看出来人工智能程序想要去连接数据库这个问题, 主要是出现在下面这几类场合里面的。瑶池MCP这些平台呢, 就是把这些问题场景里面那些让人头疼的、阻碍进展的关键点, 全都给统一地处理掉并且消除掉了:从本质上来说, 瑶池 MCP 把这个东西给开源了, 这个东西是什么?这个东西是瑶池数据库 Agent 一直在做的, 是从被动响应到主动赋能的这一套过程, 它里面包含了好多内容, 什么 RAG 知识问答, 快捷指令, 工具调用, 智能诊断与调优, 这些都是它的组成部分, 通过这种方式, 把它延展到了很多的上游入口去, 比如像 IDE 平台这些, 还有 Agent 平台这些, 这样一来, “AI 协作者”就不再只是会在阿里云控制台里出现了, 它可以出现在更多的地方了。02、瑶池数据库 MCP 具备哪些能力2.1 系统交互关系当前的运行方式是基于 stdio 的本地进程模式, 在这种情况下, MCP无论是处于 IDE、机器人、内部 Agent 平台或者是脚本当中一旦在启动的时候将其作为子进程进行 fork 处理, 所有的调用操作都要通过 stdin 来进行传递, 这就意味着系统不会监听任何端口, 因此攻击面也就变得极小了, 而且 AK/SK 也不会离开本地。2.2 三类能力概览这些工具能够发挥的作用可以看作是根据“能干什么”这个方面来进行重新评估的, 从而将它们划分成为三个不同的种类, 而在前面所提到的那些多个场景里, 每一类都是有着属于自己的用武之地的。2.第三个亮点能力, 也就是第一个亮点能力, 是关于瑶池数据库 Agent 接入的。将瑶池控制台之中的那个被称为 AI 协作工具的软件功能, 向所有可以使用 MCP 标准协议的客户端软件进行开放。瑶池数据库的 Agent 就是瑶池控制台上那个统一的 AI 服务入口, 它融合了数据库官方文档的知识库, 还联动了各产品的专属 Agent, 像是 Tair 、DTS 等等这些。把它暴露给上游的应用之后, 它带来的就不仅仅是一个能回答问题的那个接口, 而是会带来整整一层可以被自然语言去驱动的能力, 而且这一层能力还是能够持续进行扩展的。这种扩展体现在它是一个 Skill 化的能力集市, 这个市集是靠着瑶池官方沉淀下来的, 而且是会随着控制台的版本一起同步演进的。具体来讲, 任何MCP客户端只需提供一句普通的自然语言描述就可以获得以下这些功能服务。所谓的RAG知识问答功能, 主要是用来利用官方网站上的文档资料, 从而回答那些关于使用方法、配置操作或者技术原理方面的问题。比如大家常问的, “列存索引究竟适合应用在哪些场景下面?以及在写入数据库数据的时候需要特别注意什么事项? ”这些问题, 现在只需要输入一句话, 就可以立刻获取到带有具体文档引用来源的答案了。利用这个工具, 可以用日常的说话方式去做实例里的管理工作, 像是去建立新的、把容量扩大、改一下参数、再去管那个访问名单这些都能做完。只要是写数据或者是改配置这种操作, 系统就会跳出一个小窗口来问你一遍, 让你再确认一下, 而在处理那个访问名单的时候, 还会强硬地要求你去进到安全的那个分类里去进行管理。智能诊断与调优, 并且有着内置的 Skill 来加持: 瑶池数据库 Agent 这一产品里面, 包含了一整批属于产品级别的所谓诊断专家的技能内容, 这些技能能够按照产品线还有对应场景这两个维度进行更加精细化的调用操作, 比如说如下所示这样的情况。关于性能异常的深度诊断, 主要针对的是Tair和Redis实例中存在的响应时间波动以及访问超时问题进行剖析, 系统能够自动地找出问题的根本原因, 并且会提供优化建议。稳定性专家, 这一部分, 包含了一些事情, 比如复制延迟诊断, 这里面包括读写和只读的延迟, 重放延迟, slot的WAL累积, 还有读一致性问题等等同时也包括IO性能诊断, 这指的是高延迟、缓冲池未命中、检查点写入压力大以及磁盘使用率飙升这些情况另外, 它还涉及表健康巡检, 关注XID回卷风险, 表膨胀, 无用索引以及长事务阻塞这些问题。进行资源全景观测的时候, 需要查看 MySQL 实例资源使用率的排列前几名情况, 这里面包括 CPU 的使用情况、内存的使用情况、磁盘输入输出每秒的次数、以及连接的数量, 然后通过一键操作来定位处于区域内的负载较高的实例, 并且将这些实例的资源压力状况进行汇总。我们需要把AI原生能力的开通和解读这件事讲清楚, 这包括了对不同种类的AI应用进行类型的解释以及状态的说明, 比如Agent、Agent Flow、Mem0、Ray等等这些类型, 同时也包含了长记忆服务的讲解, 当然这里括号里是空的, 没有具体内容, 然后还要说明AI编剧助手也就是Drama的相关信息, 最后要把这些一键开通的操作方法和管理的方式都做出来。在进行数据仓库的慢查询分析工作的时候, 我们主要是为了实现对慢速查询的快速定位以及提供相关的优化建议方案。刚才所说的, 仅仅不过是内置的 Skill 里面的一小部分而已。瑶池数据库 Agent 的技能广场, 正在按照不同的产品线进行扩容操作。新增的能力, 会随着控制台的版本更新而自动生效。对于 MCP 的上游来说, 完全不需要修改稿件, 也完全不需要重新进行对接工作。一旦有一个 MCP 客户端发起了调用请求, 那么在后台实际关联和使用的, 就是瑶池数据库 Agent 这个工具, 在管理控制台中给用户提供的这一套完全一样的功能与服务。不管是待在 IDE 里面搞研发的, 弄日常运维的, 还有在 Agent 平台的业务方, 又或者是 CI/CD 里的那套自动化脚本, 都能平起平坐地来用瑶池数据库 Agent 的那个叫“协作者”的体验。这套东西把写库、平时看管、出了事应急、把速度调好、以后多大空间都算好的、开 AI 应用、还有不懂查文档这些好多情况都包圆了。这也是这次开源最关键的差异点瑶池 MCP 不只是一组 CRUD 执行器而是一个能“懂你 帮你想”的 AI 协作层。2.亮点能力当中的第二条, 也就是那种叫做临时账号模式的东西。传统的人工智能程序在操作数据库的时候, 往往要采取两种方式, 要么是直接把那个超级管理员的用户名和密码赤裸裸地传过去, 要么就必须提前人工手动去开通一个专用的账号, 第一种做法存在着很大的安全隐患, 第二种做法又显得不够优雅得体, 无论是需要在集成开发环境里进行自行验证, 还是执行系统维护脚本, 或者是做临时的数据查询与分析工作, 大家普遍都期望能够实现这样一种状态, 那就是不需要长期持有数据库的连接密码, 瑶池模型上下文协议服务器组件把这个具体的执行全过程打造成了完全没有任何凭据的样式, 也做到了无需进行任何配置设置, 并且执行完之后也不会留有半点剩余的痕迹。execute_instance_sql(instance_id, sql, database)├─ 1. 尝试 TCP 直连优先内网 VPC同时探测公网端点├─ 2. [如不通] 自动开通公网│ ├─ 探测本机公网 IP│ ├─ AllocateInstancePublicConnection│ ├─ ModifySecurityIps(当前IP/32, groupmcp_public_access)│ └─ 等待 3s DNS 生效 → 重试连接├─ 3. 自动建库DescribeDatabases → CreateDatabase 如不存在├─ 4. CreateAccount → mcp_CSPRNG 32 位密码├─ 5. GrantAccountPrivilege → ReadWrite on target_db├─ 6. pymysql.connect → 执行 SQL → 返回结果└─ 7. DeleteAccount → 清理临时账号finally 块兜底开发者, 还有运维人员, 以及分析师, 他们在整个过程中, 手里仅仅握着AK和SK这两个东西, 从来就不会接触到数据库的密码白名单设置的是当前机器的IP具体来说是32这种格式, 而不是那种像0.0.0.0/0那样什么都允许的情况账号在每次新建之后, 用完就会立刻被删除, 导致攻击者能够利用的时间窗口, 仅有短短的几秒钟要是出现了异常路径的情况, 也会走兜底的方式来删除账号, 从而不让“僵尸账号”留下隐患无论AI是在IDE里被调用, 还是在自动化脚本里被调用, 所采取的安全姿势都是一样的。2.5 亮点能力 3SQL 命令四级安全分级接着再加四条专门用来绕过防御的硬性限制措施。第一, 如果发现注释符号像双横杠、斜杠、星号这些就直接拒绝。第二, 只要出现多个语句连着的情况就直接拒绝。第三, 用全文的正则表达式去扫描那些危险的关键词。第四, 如果SQL代码的长度超过了一万字符也直接拒绝。与此同时, Redis也会单独维护一个独立黑名单用于处理类似设置这样的命令或者路径。03、这是示例场景的描述内容, 具体的情况是关于利用Vibe系统来实现端到端的协作任务处理的。瑶池 MCP 适用的场景有很多, 运维管理、数据分析、AI 编码、测试搭建以及故障应急等都是它的目标用户。咱们从这些里面挑选一个对开发者来说最具体、最容易跑通的场景——Vibe ——然后把它拆出来给你看, 具体看看在单次对话里, “MCP 工具”和“瑶池数据库 Agent”这两者的协作链路是什么样的。在其余所有的应用场景里面, 调用的方式和前面所说的情况是完全一模一样的, 并没有什么不同之处, 唯一的区别在于作为上游的 AI 客户端工具, 从之前大家熟悉的集成开发环境 IDE, 切换成了其他的平台或者脚本, 具体来说是变成了那些智能体平台或者是专门给运维人员使用的自动化脚本而已。3.第一, 也就是所谓的场景设定。你目前正在使用 Qoder 编写一个电商订单服务, 后端需要实现持久化存储并搭建缓存层, 同时计划摸清新集群的健康状态基线。现在代码已经编写完成, 你想要怎么做。先开一套 MySQL 集群用于存放订单主表, 另外再开一套 Tair 用作缓存接着创建表结构, 并且构建测试数据然后让瑶池数据库 Agent 顺手做一次性能诊断整个过程中不用离开 IDE, 不用输入数据库密码, 也不用手工开白名单。3.从2这一数字开始, 我们进行端到端方面的协作流程。01、优采云人工智能助手, 自然语言。请帮我启动一个 MySQL 数据库集群, 同时另行开启一处 Tair, 将其用作缓存服务。02、人工智能调用MCP工具, 也就是创建集群。AI自动把任务给拆分开, 然后头一步是去把MySQL的连接给拉起来。03、人工智能, 正在调用 MCP 工具, 目的是创建 Tair 实例。等主库准备好之后, 再去开创建 Tair 实例这个操作。04、YOU · 自然语言麻烦您在 XXX实例上面去建一个 order表, 这个表要包含用户 ID、商品 ID、订单金额这些个字段, 并且需要往里面灌入一批测试数据。05、通过人工智能技术来调用MCP工具, 其作用是创建一个数据表。这个调用的过程, 是采用临时账号模式的, 这种模式是不需要密码的。06、YOU · 自然语言我需要去order这张表里面进行查找, 目的是找到那三个消费金额是最高的用户。07、人工智能正在进行操作, 使用MCP工具来处理写入缓存这个环节。调用临时账号模式无需密码08、 DB AGENT · 智能诊断RAG让瑶池数据库 Agent 对数据库实例进行不同类型的诊断整个过程, 包括创建集群, 包括创建表, 包括创建 Tair 缓存, 包括写入测试数据, 包括进行性能诊断, 上游的 AI 只需要去执行一句自然语言就可以了, 全程没有打开过控制台, 也没有手动开启过白名单, 更没有被粘贴过任何数据库密码。这就是瑶池数据库 Agent 提倡的, 想要什么就能得到什么, 从被动响应变成主动赋能。链路是相同的, 把 AI 客户端换成运维平台或者 Agent 工作流, 行为是完全一致的。3.3 五分钟接入不论你所采取的操作是将瑶池 MCP配置到 IDE环境之中, 亦或是接入到机器人系统内部, 又或者是部署于企业内部 Agent平台之上, 其遵循的基本步骤始终是完全一致的。# 1. 克隆 装依赖git clonecd alibabacloud-yaochi-db-mcp-serverpython3 -m venv .venv source .venv/bin/activatepip install .# 2. 配置 AK/SK推荐环境变量export ALIBABA_CLOUD_ACCESS_KEY_ID你的AKexport ALIBABA_CLOUD_ACCESS_KEY_SECRET你的SKexport ALIBABA_CLOUD_REGION_IDcn-hangzhouexport YAOCHI_ENABLE_WRITE_SQLtrueexport YAOCHI_ENABLE_DDL_SQLtrue # 需要建表/改 schema 的场景必开# 3. 验证yaochi-db-mcp-server # 进入 stdio 等待 成功只要将 MCP 客户端重新开启, 接下来的事情, 便只不过是与 AI 进行交谈了。04、就是要让那个智能机器真正地明白你的云平台数据库的情况。瑶池MCP之所以进行开源, 这实际上是瑶池数据库团队针对“在AI大发展的大背景下, 云端管理的数据库产品究竟应当怎样被人工智能系统所调用”这一重要课题, 而给出的一份工程领域的具体回答和解决办法。不管你是在开展Vibe相关工作, 还是在着手搭建运维体系, 亦或是去装配数据分析用的Agent设备, 又或者是给团队构建一整套测试自动化流程, 只要你的应用需要用到阿里云数据库, 那么都欢迎你来。执行拉取代码的操作, 然后将程序运行起来。欢迎大家到那个平台上提交问题讨论或者贡献代码, 以此来告诉我们。让我们把人工智能助手这个功能做到位, 让它真正变成每一个使用云端服务的用户身边的那位懂阿里云数据库的专家人士, 这一条道路, 我们此刻才刚刚起步而已。