pgEdge AI DBA Workbench：让 LLM 当你的数据库值班员，但绝不让它直连生产库

预计阅读时间：11 分钟

把数据库运维交给 AI，大多数开发者的第一反应是礼貌点头，然后追问：模型怎么区分一个安静周二的正常快照和黑色星期五的失控事务？pgEdge 团队花了数月时间回答这个问题，答案的核心只有一句话——LLM 永远不直连你的数据库。

四个服务，一个数据存储

Workbench 的架构不复杂：四个 Go/TypeScript 服务共享一个 PostgreSQL 数据存储。

Collector：守护进程，连接每个被监控实例，拉取数十个指标探针——覆盖连接数、查询延迟、复制状态和操作系统级资源使用。每个探针写入独立的时间序列表，按 (server_id, timestamp) 索引，采集频率可按范围配置。
Server：暴露 JSON-RPC 2.0 MCP 和 REST 端点，所有 LLM 与数据库的交互都经它中转。
Alerter：跑异常检测和阈值评估。
Client：React SPA，渲染仪表盘、集群拓扑图，以及 Ellie 住的聊天面板。

你可以把 AI 关掉，纯当监控平台用，完全够格。但团队内部没人愿意这么干了——开着 Ellie 之后的效率差距太明显。

Ellie 的工具循环：模型只发指令，不碰数据

Ellie 不是独立服务，而是客户端里实现的 agentic loop。她对接你选的 LLM 后端——Claude、ChatGPT、本地 Ollama，或任何 OpenAI 兼容 API（LM Studio、EXO 等）。选哪个模型远不如人们以为的那么重要，因为 LLM 从不直接查库。它返回的是 tool calls，客户端把这些调用分发到 Server，Server 在调用者的 bearer token 下、通过 per-token 连接池执行——两个用户绝不共享状态。

Ellie 的工具清单模拟了一个人类 DBA 的排查路径：

工具	作用
`map_database`	映射数据库结构
`metric_catalogue`	查看可用指标目录
`metric_history`	拉取相关历史数据
`alert_log`	遍历告警日志，含确认和误报标记
`maintenance_windows`	查看计划维护窗口
`explain_query`	对拟展示的 SQL 跑实时 planner 验证
`query_plans`	返回执行计划
`search_docs`	语义搜索 PostgreSQL 及扩展的 curated 文档语料库
`memory` 系列	跨对话携带特定集群的 quirks

关键安全门：系统提示词禁止 Ellie 输出任何没经过 explain_query 验证的 SQL 语句。search_docs 让她引用文档而非模型预训练知识。maintenance_windows 确保已知维护窗口内的指标尖峰不被误报为事故。alert_log 同时展示确认和误报标记，让她区分反复噪报和真正新症状。

每个仪表盘面板、图表、告警上都有 AI Analysis 按钮——点击跑一轮 one-shot loop，种子数据是该面板的数据、时间范围、服务器上下文和时间线事件，结果弹进一个模态框，可读可下载为 Markdown，不需要对话。

MCP 服务器：不只是 Ellie 的后端

Workbench 的 MCP 服务器同时也是独立开源项目 pgedge-postgres-mcp，暴露同样的工具目录给任何 HTTP MCP 兼容客户端——Claude Code、Cursor、VS Code Copilot，或你自己写的 agent。想在 IDE 里直接驱动同样的诊断能力，完全可以。

下面是一个实际可跑的示例：用 pgedge-postgres-mcp 作为 MCP 服务器，从 Claude Code 调用数据库诊断工具。

示例：本地启动 MCP 服务器并接入 Claude Code

先克隆仓库并构建：

# 克隆 pgEdge Postgres MCP 服务器
git clone https://github.com/pgEdge/pgedge-postgres-mcp.git
cd pgedge-postgres-mcp

# 构建二进制（需要 Go 1.22+）
go build -o pgedge-mcp-server ./cmd/server

# 设置环境变量——指向你要监控的 Postgres 实例
export PGHOST=127.0.0.1
export PGPORT=5432
export PGUSER=monitor_user
export PGPASSWORD=your_secure_password
export PGDATABASE=your_production_db

# 启动 MCP 服务器（默认监听 :8080）
./pgedg-mcp-server --addr :8080 --tls-cert ./certs/server.crt --tls-key ./certs/server.key

然后在 Claude Code 的配置文件里注册这个 MCP 服务器：

// ~/.claude/mcp_servers.json
{
  "mcpServers": {
    "pgedge-postgres": {
      "transport": "http",
      "url": "https://localhost:8080/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_BEARER_TOKEN"
      }
    }
  }
}

配置完成后，在 Claude Code 里直接提问：

> 帮我查一下 production_db 过去一小时的连接数趋势，有没有异常尖峰？

Claude Code 会通过 MCP 调用 metric_history 和 alert_log 等工具，走 Server 的连接池和 bearer token 鉴权，模型本身不碰数据库连接串。

三层异常检测：便宜优先，贵在后手

Alerter 是没人盯着时真正值钱的部分。三层架构按成本递增排列：

第一层——z-score 滚动基线

用 pg_stat_progress_analyze 等内置函数计算滚动基线，z-score 捕获大部分明显偏差，成本最低。这是你凌晨三点最想要的：便宜、快、覆盖面广。

第二层——pgvector 相似度搜索

把当前指标窗口嵌入，对历史异常做相似度搜索（存在普通 Postgres 表里，你可以自己 SELECT）。上个季度的连接风暴模式如果重现，在症状级联之前就会被标记。

第二层的关键细节：pgvector 依赖是对"用 Postgres 当 AI 的基底而非外挂向量库"的安静背书。Ellie 的记忆、历史分类、嵌入搜索全在你可以直接查询的表里。

第三层——LLM 升级

前两层无法置信分类的残余案例，才交给 LLM，附带相关探针上下文。这一层只在便宜方法不够时才触发。

三层之外还有 26 条阈值规则，按 estate/cluster/server 三级范围配置，通知渠道覆盖 Slack、Mattermost、webhook 和邮件。

示例：直接查询异常嵌入数据

既然所有数据都在 Postgres 表里，你可以自己看：

-- 查看最近被第二层（pgvector）标记的异常模式
SELECT
  anomaly_id,
  detected_at,
  similarity_score,
  matched_historical_anomaly_id,
  metric_probe_name,
  summary
FROM pgedge.anomaly_embeddings
WHERE detection_tier = 'pgvector'
  AND detected_at > now() - interval '7 days'
ORDER BY similarity_score DESC
LIMIT 20;

-- 查看当前滚动基线（第一层 z-score 用的）
SELECT
  metric_name,
  baseline_mean,
  baseline_stddev,
  last_zscore,
  last_evaluated_at
FROM pgedge.metric_baselines
WHERE last_zscore > 2.5  -- 超过两个标准差的指标
ORDER BY last_zscore DESC;

这些查询不需要任何 AI 参与，纯粹是 SQL——但它们让你理解 Ellie 在三层检测中看到的是什么。

复制覆盖面

Collector 对复制的探针覆盖很广：pg_stat_replication、pg_stat_wal_receiver 给流复制；pg_replication_slots 给逻辑复制；加上 Spock（pgEdge 的活跃-活跃扩展）的 spock.node 和 spock.replication_set。

什么时候该试，什么时候该等等

适合上手的场景：

你已经有 Postgres 监控但告警噪音大——三层检测 + alert_log 的误报标记能显著降噪
团队 DBA 人力不足，需要 7×24 值班能力——Ellie 的工具循环覆盖了人类 DBA 的标准排查路径
你在 IDE 里工作，想就地查库诊断——MCP 服务器直接接入 Claude Code/Cursor
你想用 Postgres 本身做向量存储而非另起一套——pgvector 方案已经跑在生产里

需要谨慎的地方：

LLM 后端的延迟和成本——第三层升级只在残余案例触发是好的设计，但如果你选的模型响应慢，one-shot AI Analysis 的体验会打折
bearer token 管理——per-token 连接池隔离了用户状态，但 token 本身的生命周期管理是你的责任
本地 Ollama 模型的能力边界——团队说"选哪个模型远不如人们以为的那么重要"，但这是在工具调用固定、模型不直连的前提下；如果模型理解力不够，tool call 的选择质量会下降

上手清单：

从 GitHub 克隆源码（PostgreSQL Licence），先关掉 AI 纯跑监控，验证 Collector 和 Alerter 对你的实例能正常采集
配一个本地 Ollama 模型作为 Ellie 后端，零 API 成本试跑工具循环
对比同一告警在"三层检测 + Ellie 解释"和"纯阈值规则"下的体验差异
如果你在用 Claude Code 或 Cursor，把 pgedge-postgres-mcp 接入 IDE，在日常开发中用 MCP 工具替代手动 psql 查询
确认你的 monitor_user 权限只覆盖监控所需的最小集合——Ellie 的安全门是系统提示词和 explain_query，但数据库侧的权限边界是最后一道防线

Workbench 已正式发布，源码在 GitHub。先不带 AI 跑一圈，再打开 Ellie——你会对效率差距感到意外。