基于 AI 的线上维护机器人
提现功能是怎么实现的，它有没有调用风控的接口？ 可否统计一下最近我们对 A 服务商的接口有多少次失败调用？ xx 订单已经是特殊渠道订单，为什么还是出现在审核列表？ ……
这些悬在开发同学头上的一个个「魔咒」，一大半其实可以交给 AI 来分担。
上一篇《飞书与 Cursor 互通》讲的是怎么在 IM 里远程写代码；这篇换了一个场景——问题从 IM 来，答案在系统里，同样用 cc-connect 把 Agent 接到聊天框对面。
三类问题，本质一样
系统维护里的「问答题」，万变不离三类：
| 类型 | 典型场景 | 答案来源 |
|---|---|---|
| 逻辑咨询 | 「提现功能怎么实现的？」「这个接口谁调用的？」 | 代码库 |
| 数据统计 | 「今天失败订单有多少？」「某用户最近几笔交易？」 | 数据库 |
| 问题排查 | 「支付失败了帮看下」「这个报错什么原因？」 | 日志 → 库 → 代码 |
三类问题看起来不同，本质上是一样的：基于已有数据做归纳和分析，最终得到答案——而这恰恰是 AI 的强项。
整体方案
聊天框里发一条消息 → cc-connect 长连接转发 → Agent 搜代码、查库、查日志 → 结果回到对话框。
为什么还是 IM？
运营 @ 你、产品私聊、告警群里喊一声——问题本来就在 IM 里。如果每次都要「稍等，我回去查一下」，IM 和系统之间就断了一截。把排查能力接到 IM 上，问在群里，答也在群里，上下文不用在脑子里来回搬。
功能说明
- IM（入口）：飞书、钉钉、企微等聊天工具，让问题在对话里就得到解决
- cc-connect（连接器）：维护 IM 与 Agent 之间的长连接，消息双向转发；详见前篇《飞书与 Cursor 互通》
- Agent（打工仔）：借助 Cursor / Claude / Codex 等成熟 AI Agent，把查日志、查库、搜代码串成一条对话
- 数据端：代码库、数据库、日志三路数据源
如何保证代码是最新的？
Agent 搜代码，前提是本地仓库别落后太多。cc-connect Web 里有一个定时任务菜单，可以用提示词让 AI 定期拉代码、更新索引。参考提示词：
进入
/path/to/your-repo目录，执行git pull origin master，完成后更新 codegraph 索引。如有冲突或 pull 失败，把错误信息汇总返回，不要强行覆盖本地改动。
产品咨询、运营查错都依赖代码检索——索引过期，答出来的实现逻辑可能就是旧版。
AI 读生产数据和日志
查库、查日志不必事先写好固定脚本，让 Agent 自己封装 Skill 就行。需要时在对话里发一条提示词，Agent 会按需创建并在后续排查中自主调用。参考提示词：
创建一个 skill：使用 xxx 用户名和 xxx 密码，通过 SQL Plus 只读连接 xxx 数据库从库；单次查询结果不超过 1000 条，禁止 DDL/DML。再创建一个 skill：使用 xxx 只读账号登录 Kibana，按 traceId 或关键字检索最近 24 小时的应用日志。
Skills 建好后，故障排查、数据统计类问题 Agent 就能自己决定「先查日志还是先查库」。
信息安全
在方便与安全之间，每个团队总会有自己的取舍。下面是我实际落地时的几层防范，供大家参考。
提示词围栏
在工作空间根目录，我通过 AGENTS.md 给 Agent 的行为做了背景限定。大致配置如下：
# 线上维护助手
## 你可以
- 搜索代码库，只读查询数据库和日志
- 在 IM 对话中回答排查结论，并说明依据
## 你不可以
- 修改、提交或推送代码
- 执行 DDL/DML、删除文件等危险命令
- 在回复中输出手机号、身份证、银行卡等完整敏感信息
## 回复原则
- 给结论 + 必要字段，明细数据做脱敏
- 涉及资金、对外口径的结论，标注「建议人工确认后再转发」
这是第一道软约束：Agent 理解自己「能干什么、不能干什么」，比事后拦截更省心。
数据账号权限
- Git：个人开发账号，本地只拉取受保护的 master 分支，不能直接提交代码
- 数据库：类似 Yearning 的审计平台，只读权限，查从库，单次最多 1000 条
- 日志：只读 Kibana 账号，限定索引范围
IM 对话权限
- 排查机器人只加在小范围产研群，没有开放到业务群
- cc-connect Web 里可以配置有权限跟机器人对话的 userId，白名单之外的消息直接忽略：
Agent 权限
以 Cursor CLI 为例，配置文件里可以设置 Agent 可执行命令的黑白名单，用来兜底——允许 query-db、query-log，禁止 rm、任意写文件等：
总结
cc-connect 不只是远程写代码的桥梁，也可以变成 IM 里的维护机器人：逻辑咨询、数据统计、问题排查，三类问题共用同一套「IM → Agent → 数据端」架构。
搭起来不需要重写业务代码——连接器、Agent、Skills 都是现成的积木；真正要花心思的是权限和脱敏：查得方便，也要查得可控。边界事先约定好，这套方案才适合长期放在生产环境里用。
如果你已经按前篇搭好了 cc-connect，不妨从一个小群、一两个 Skill 开始试：让运营的一个常见问题，第一次在 IM 里直接拿到带来源的答案。