拆解小红书存储底座 02｜让 AI 成为团队的一员：存储数据库助理实践
REDtech约 11 分钟导读
小红书的存储与数据库体系覆盖 MySQL、RedKV、Redis、ROS 等产品，DMS、RedDTS 等公共能力分别提供统一管控和数据传输支持。SDBP 是面向存储数据库运维协作的 AI 助理，补充了智能答疑与任务跟进能力。
SDBP 将团队知识、内部代码和业务工具接入 IM，可协助回答咨询、跟进审批和排查问题。上线两个多月，它已服务千余名内部用户，独立解决数千个问题，其中约三成的问题在非工作时间得到解决，为夜间和周末的常见咨询提供补充响应。从日均独立解决的问题数量看，助理达到单名专家的 五倍以上，为团队提供了额外的问题处理能力。本文介绍 SDBP 在共享执行资源、知识获取、访问边界与群聊协作上的建设实践。
上线两个多月，存储数据库助理 SDBP已服务千余名内部用户，独立解决数千个问题。从日均独立解决的问题数量看，助理达到单名专家的 五倍以上，为团队提供了额外的问题处理能力。其中，约三成的问题在非工作时间得到解决，为夜间和周末的常见咨询提供补充响应。有用户把助理“置顶在用”，也有用户反馈“很多问题可以直接给出答案”。这份认可也延伸到了其他团队，吸引近十个团队主动前来取经。从了解技术方案，到带着各自的业务场景讨论如何搭建同类助理，交流的话题逐渐从“这个助理真好用”走向“我们也想做一个”。
这些变化来自我们将专业能力带入团队协作的持续探索。本文从一线值班的实际需求和前期 OpenClaw 尝试出发，介绍共享执行资源、内部知识获取与访问边界的建设，再展开群聊并发、群定时任务和消息触发的实践，最后回到应用成果与持续改进。
01
业务背景：专业答疑背后的重复与等待
存储数据库团队的值班工作，平均每周要处理数百轮咨询与求助，覆盖关系型数据库、非关系型数据库、图数据库、对象存储等多类产品。业务同学通过私聊和群内 @ 发来的请求，既有连接失败、权限异常和工单操作等咨询，也有围绕审批催办与进度确认的沟通：工单提交后，还要找当前审批人、催处理、等反馈。值班同学因此既要解答问题，也要协调人员和跟进流程。
同类问题换一个用户，就要重新解释；知识和经验分散在文档、历史聊天与各领域专家手中，遇到不熟悉的场景，还得先找资料、找人。催审批等请求则需要反复核对状态、联系处理人。我们希望让助理接手常见问题的查证、依规处理与进度跟进，让业务少一些等待，也让专家把更多精力留给故障判断、风险控制和系统优化。
02
前期探索：从个人助理走向团队服务
年初 OpenClaw 的火爆，让更多人看到了 AI 助理从回答问题走向调用工具、执行任务的潜力。我们也尝试把专家的知识和工具接入助理，在 IM 中查证问题、处理请求。但个人助理通常围绕一个人的文件、身份和目标工作；存储数据库服务的提问者众多，同一个群里，不同用户的资源权限也可能完全不同。每次请求都必须明确是在替谁做事、可以访问哪些数据、能够执行哪些操作。
我们考察了两种部署方式：多人共用一个 OpenClaw 实例，需要额外解决身份、文件与权限隔离；每人独立部署一个实例，则面临低频场景下的资源闲置，以及按需启停时的状态恢复问题。
图 1：本项目探索的两种部署方式，以及团队服务需要同时满足的要求。
因此，我们将资源共享、知识获取与访问控制作为底座建设的重点，再进一步支撑群聊中的并发与持续协作。
03
技术实践：构建面向团队的助理底座
1. 运行架构：共享计算资源，保留独立会话
AI 技术快速演进，Claude、Codex、DeepSeek 等生态不断带来新的 Agent 能力。为了持续吸收这些进展，我们实现了统一的 Agent 抽象层，对任务执行、过程事件和会话管理提供统一接口，通过适配器对接不同的底层框架。
这一设计为后续按需引入新框架预留了空间。完成适配与验证后，新框架可以复用 SDBP 已有的知识接入、业务工具和权限控制，让底层执行能力持续演进，也让团队积累的业务能力得以保留。用户通过 IM 或 Web 交互，各产品能力通过 Skill 和 MCP 接入。
团队服务面对大量低频用户，既要及时响应，也要减少资源空转。我们因此将会话状态与执行环境分离，使任务进展不再绑定某个执行节点。
会话与工具调用记录持久化到 PostgreSQL，工作区文件与只读资源放在 NFS 中。执行节点可以替换，工作状态仍可接续。
状态持续保留，算力按需使用。我们以 数十核共享资源，承接面向 数千名用户的低频服务场景，覆盖人数不代表同时在线或并发执行人数。
图 2：会话与文件独立保存，执行资源按需共享。
2. 知识获取：让文档与代码共同支撑回答
围绕存储数据库的日常工作，我们通过 Skill 接入了 MySQL、KV 、对象存储等产品能力，支持资源查询、权限申请、工单处理与问题排查。这些能力能否真正发挥作用，首先取决于对内部业务的理解。内部知识库是助理理解业务、作出判断和正确执行的核心基础。产品约束、操作流程、排障经验和实现细节，都需要来自内部知识的支撑。
大模型熟悉公开知识，却不了解内部系统的实现与流程。更现实的困难是，团队文档库并不完整：一些细节没有记录，一些文档没有跟上功能变化。我们先后尝试了 RAG 和 LLM Wiki，但答疑效果仍不理想——知识整理得再好，也无法补齐源资料中缺失或过时的信息。
于是，我们进一步把代码纳入知识源，在同一组小规模 DMS 代码问答样本上比较三种获取方式。下表概括了它们的工作特点、平均耗时和回答质量；结果仅反映本组样本，不等同于线上问答准确率。
综合测试结果，我们采用代码图谱定位、源码核实的方式，在回答质量与耗时之间取得折中；文档则补充产品说明与操作流程。
代码仓库会定时拉取最新主分支，文档与内部平台同步；Git 提交记录提供相关开发者线索，辅助缺陷排查与人工接手。
图 3：Skill 引导知识获取，图谱定位关联，源码核实细节，提交记录辅助人工接手。
3. 网络防火墙：以用户身份约束执行权限
代码让助理看懂系统，也让它更容易找到相关接口与调用方式。助理会主动寻找可用的工具来推进排障，但工具和接口的使用必须受当前用户权限约束。知道接口怎么调用，并不代表有权调用。
我们在 Agent 与内部系统之间设置出口代理，统一检查服务白名单和当前用户的可信身份，保管并按需注入业务凭据。助理执行环境无需持有业务凭据。
服务白名单限定助理能访问哪里，用户权限决定它能做什么。不同用户不共享授权，文件按范围隔离；涉及审批等操作，业务系统仍需独立校验权限和流程节点，检查失败则停止。
图 4：文件隔离、出口检查与凭据外置，共同约束每一次访问。
04
场景探索：让助理融入日常协作
资源、知识与访问边界构成了服务基础。接下来，我们围绕群聊中交错的问题、需要持续跟进的事项，以及消息到来后的主动响应，探索助理如何进入日常协作。
1. 群聊并发：让多个问题同时推进
群里上一问还在排查，下一问已经到来。日常问答以读取和分析为主，文件写入冲突较少，适合并行推进。我们按“助理＋用户＋群聊”隔离会话，并通过会话分叉与增量合并，让同一用户的新问题也能并发处理。
分支只继承分叉时已保存的历史，执行中的内容不实时共享；完成后持锁合并新增对话与工具调用记录。文件改动与业务操作的冲突另行处理，超出并发上限的请求排队。
图 5：同一会话中的新问题继承已有上下文，独立执行后将新增记录汇回主线。
2. 群定时任务：从一次交代到持续跟进
群里的工作不总能当场结束：工单需要继续跟进，风险需要定期检查，周会前还要收齐进展。我们把这些约定保存为定时任务，让助理到点后重新查看情况，减少人工反复盯进度。现有群聊任务配置中，已经出现了几类典型用法：
工单与事项跟进。按小时检查群内工单，只对超过约定时限且仍未结束的工单提醒；安全加固等专项则定期核对进展，完成后结束跟进。提醒依据最新状态生成，减少对已完成事项的重复催办。
风险巡检与指标监测。定时汇总容量风险，按产品和集群归并重复告警，标记已有的扩容进展；对比 CPU 售卖率、成本核数等指标的变化，按约定阈值识别需要关注的异常，让散落的信息成为可跟进的风险清单。
团队协作与信息汇总。按周公布值班人，会前检查周报填写情况、提醒尚未补齐的事项；也可以定期从群内派活和会议纪要中提取待办，去重录入后继续跟进，减少遗漏。
任务内容、执行计划、所属用户和群聊会被持久保存。到达约定时间后，调度器触发执行，助理按任务约定检查最新情况，并将需要反馈的结果发回原群。执行状态可查询，后续计划可取消，任务也无需依赖某个对话进程一直在线。
图 6：一次约定后，助理每天会后自动提取、去重并登记待办。
3. 消息触发：从显式唤起到主动响应
普通群的自动答疑
只在用户明确 @ 时回答，会漏掉群里已经提出、却还没有人接手的问题。我们在指定业务群中引入消息触发，作为从显式唤起走向主动响应的过渡方案，先明确介入范围与打扰程度。
这套实现周期性检查近期消息，在短暂静默后结合上下文判断：是否是明确的存储数据库问题，是否已有值班同学或其他成员接手，是否已经有机器人回答。只有确实需要补充、且能给出有依据的帮助时，才开展只读查询或代码查证并简短回复；信息不足、已有响应或对话自然推进时，保持静默。这条自动响应路径不直接发起审批、提单等写操作。
基于消息触发的自动审批
审批人本人预先配置适用的工单类型和生效群聊，助理按预授权规则处理后续请求。每次执行仍由业务系统校验当前审批人、操作权限和工单状态。审批人可停用或删除规则，停止后续自动触发；校验不通过、超出授权范围或执行异常时，不继续自动审批，反馈后由人工处理。执行结果回报原群。
图 7：审批人配置与管理规则，助理核验后执行并回报结果。
05
应用成果：从答疑工具到团队成员
助理带来的变化，既体现在更多问题得到及时解决，也体现在团队开始把一些具体工作交给它。从日常答疑到专业协作，它逐渐有了自己的分工。
① 服务业务：让问题少一些等待
对业务同学，SDBP 上线两个多月，已服务千余名内部用户，独立解决数千个问题，其中约三成的问题在非工作时间得到解决，为夜间和周末的常见咨询提供补充响应。从日均独立解决的问题数量看，助理达到单名专家的 五倍以上，补充了团队处理常见问题的能力，让专家能把更多精力放在复杂故障判断、风险控制和系统优化上。
用户的反馈也落在具体的使用体验上：有的问题可以直接得到答案，有的流程能在 IM 内完成，也有人把助理置顶，作为日常求助的入口。
② 融入团队：从回答问题到接手工作
对存储专家，助理参与审批处理、异常排查与缺陷修复：完成 千余单审批，分析定位 数百个产品异常，累计修复 百余个产品缺陷。这些工作覆盖重复核查、专业调查与修复处理；助理承担其中可交付的具体任务，专家负责必要的授权、评审与验证。
下面的 Redis 告警订阅案例展示了这一分工：助理承担代码查证与修复准备，工程师负责授权、评审和验证。
图 8：Redis 告警订阅编辑出现校验异常，助理查证并准备修复，工程师评审后由用户验证。
③ 实践扩散：让更多团队看到复用的可能
这份实践吸引了近十个团队主动前来取经。交流从体验助理、了解设计方案，进一步深入到各自的业务场景，探讨如何搭建同类能力。对其他团队而言，关注点也从“这个助理真好用”，延伸到“我们也想做一个”。
图 9：其他团队主动交流设计方案与接入方式。
06
持续演进：拓展执行能力，沉淀协作经验
从答疑走向持续协作，助理将重点推进三个方向：
拓展运维变更能力：在授权与审批约束下，贯通问题分析、方案制定、执行和验证，扩大可承接的任务范围。
建设全局分层记忆：区分个人与群聊记忆、团队共享经验及变更事实，保留来源、权限和适用条件，及时更新过期内容，支持经验复用。
探索 Skill 自迭代：从真实任务中提炼改进建议，将线上失败案例转化为可复现的评测任务，通过独立评测验证效果，推动经验持续更新。
下一篇，我们将拆解 MySQL 内核线程池的设计与实现，欢迎持续关注「拆解小红书存储底座」系列。
///
作者简介
团长，小红书研发工程师，负责存储数据库管控平台和智能助理建设。
雷内，小红书研发工程师，负责数据库自治可观测性建设和 SDBP 核心模块建设。
瓦稣，小红书研发工程师，负责 SDBP 应用层功能建设和管控平台功能打通。
武藤，小红书研发工程师，负责 SDBP 故障根因定位系统建设和核心指标运营。
陈锦浩，小红书研发工程师实习生，负责 SDBP 的高频 Skill 功能和智能审批建设。
鄢灿锋，小红书研发工程师实习生，负责 SDBP 运营系统建设和数据运营。
部门介绍：
存储&数据库部，为小红书全业务场景打造行业领先的高可用、高可靠、高性能、低成本的存储和数据库类产品技术服务。团队致力于用精英化的组织和行业领先的技术理念，先于业务布局和行动，为公司业务的快速发展提供充足“弹药”，同时也让小红书存储和数据库成为行业该领域的标杆。
///
招聘
精彩回顾：