pganalyze 给 AI 编码工具开了一扇安全的门：Workbooks 让 EXPLAIN ANALYZE 走进 MCP Server
把 AI 编码工具连到生产库，通常是被劝退的：天知道它会干什么，万一搞出可用性问题谁负责。但代价是 AI 工具赖以工作的反馈回路断了，全靠人工介入。放到数据库查询优化上，问题就变得非常具体：“我该怎么在生产环境跑 EXPLAIN ANALYZE？” 人可以靠权限、审批、副本和小心谨慎，AI 工具通常没有这个待遇。pganalyze 的思路是：那就专门造一个安全系统，让 AI 工具在里面跑 EXPLAIN ANALYZE，把执行计划喂回给它，顺便把过程记录下来。10 月 15 日，这个系统进入公开预览：Workbooks 登陆 pganalyze MCP Server，Claude Code、Codex、Cursor 现在可以实测查询改写了。
为什么 AI 修查询需要一个”调优回路”
大多数查询优化走同一条路：用 EXPLAIN (ANALYZE, BUFFERS) 实测慢查询，形成假设，做出改动，再实测一次——慢的淘汰，快的上线。人手工做这个回路，懂数据模型的 Postgres 专家花的时间是”合理量”，不懂的人要磨几个小时甚至几天。这就是为什么生产系统里躺满了没人捡的优化机会。
那 AI 工具为什么不自己跑完这个回路？前半段它们其实很擅长：基于 pganalyze 已经采集的查询指标、统计、执行计划和问题清单，Claude Code 们不用连生产库就能发现”某个索引被嵌套循环扫了几百万次”。但它没法确定自己建议的改写到底有没有变快。没有实测，Agent 要么每一步都停下来找你要 EXPLAIN 结果（以人类速度运行），要么朝着错误方向一路迭代。
所以分工变成：Agent 提出假设，pganalyze 负责测量，结果喂给下一次尝试——这就是原文小标题里说的 AI tuning loop。读工具（4 月就有的那批）覆盖”调查”，Workbooks 覆盖”测试”。
Workbooks 怎么运转
Agent 通过 MCP 客户端走你在 pganalyze 应用里本来就会用的流程，一共 8 个工具：create_workbook、create_workbook_variant、create_workbook_parameter_set、update_workbook、get_workbook_details、sync_workbook、get_insight_rewrite、delete_workbook_item。
流程拆开是：
- 1.
create_workbook为一个慢查询建工作簿，通过采集器工作流跑 基线 EXPLAIN ANALYZE——确认历史慢查询现在还慢，同时跑确定性的 Query Advisor 分析 - 2. 确定性洞察可以通过
get_insight_rewrite变成候选改写，Agent 自选的改写用create_workbook_variant加进来，和基线计划对比 - 3. 规划器参数改动（调
work_mem、调random_page_cost）同样可以测，参数集由人确认，Agent 拿不准时会来问而不是自己填 - 4. 每个变体都记录它在验证什么假设——尝试留在共享工作簿里可回看，而不是散落在聊天记录里
实战演示：188.6 秒 → 3.5 秒
原文给了一段端到端演示（原文附完整录屏），短版五步：
- 1. 发现问题：Query Performance 里出现一条平均 40 秒的新慢查询，占最近 24 小时总运行时间近四分之一，且每次执行时长波动剧烈
- 2. 交给 Claude Code：MCP Server 接好，prompt 里点名这条查询和可疑之处（时长波动、buffer 数远超表本身大小）
- 3. Agent 调查：拉最近的执行计划，发现 buffer 数从不到 100 万到 2.3 亿随参数波动，锁定相关子查询是根因，提出改写，并主动建议在 workbook 里实测而不是猜
- 4. 基线，然后变体：三个参数集跑出三条计划：188 秒、46 秒、2.5 秒；Query Advisor 在基线上标出低效嵌套循环，建议物化 CTE；Claude Code 实测后推荐 MATERIALIZED CTE 改写，最坏情况从 188.6 秒降到 3.5 秒
- 5. 记录进工作簿：试了什么、结果如何、推荐什么、什么没测——下一个打开工作簿的人知道它为什么存在
护栏：故意做窄的权限
这是整件事最关键的设计——Agent 拿不到数据库直连。执行 EXPLAIN ANALYZE 的是跑在你自己环境里的 pganalyze 采集器，而且它只干这一件事：
- – 没有任意 SQL，只跑 EXPLAIN ANALYZE
- – 强制只读事务，超过 60 秒直接中止
- – 权限按 server 粒度划分
- – 因为 EXPLAIN ANALYZE 会真实执行被分析的查询，这批工具单独放在写权限 scope 后面，并要求账号具备 Create Workbooks 权限
开启条件三件套：MCP Server 启用 + Create Workbooks 权限 + 目标库配好采集器工作流，MCP 客户端授权时授予 workbook 写 scope。
4 月以来 MCP Server 还长了什么
Workbooks 是最大的新增，但整个 MCP Server 的工具数已经从公开预览初期的 20 个涨到 30 个：
| 新增 | 内容 |
|---|---|
| Log Insights | get_log_stats 按分类返回日志行时间序列，get_log_lines 返回最近 7 天明细 |
| 系统指标 | get_system_stats 返回 CPU/内存/存储/网络/WAL 的 OS 级时间序列 |
| 集群感知 Index Advisor | run_index_selection 聚合整个集群的扫描数据，每条受影响查询标注来源服务器 |
| 个人访问令牌（早期） | 给脚本和后台 Agent 用的 scoped 凭据，含 workbook 写 scope，支持无人值守运行 |
| 平台扩展 | Enterprise Server v2026.05.0 起支持；OAuth 白名单新增 Composio、Devin 等托管平台 |
下一步计划：把 AI 直接嵌进 pganalyze 自己的流程（advisor 后台常驻不烧 token，发现坏计划时再拉起带 LLM 的调查回路），以及对生产副本/克隆（如 Aurora clone）跑 Workbooks，让索引改动也能像查询改写一样被验证。
小夏点评
- 1. 这篇的真正主题是”AI 进生产的权限模型”——不是给 MCP 多加了几个工具，而是把”Agent 能碰生产”拆成了窄能力+自建通道+强制超时+审计记录四件套。这套模式可以直接抄给任何数据库类 MCP server。
- 2. 188.6 秒到 3.5 秒的演示里，最值钱的是”每个变体记录假设”——AI 优化落地失败大多不是模型不行，是过程不可回看。工作簿把聊天记录变成了审计对象，这是 AI 工程从玩具到生产的分水岭动作。
- 3. 对中国 IT 运维/开发者的启示：国内团队普遍不敢把生产库连接串交给编码 Agent，这篇给了第三条路——不给直连、给”只读+60 秒熔断+按 server 授权”的窄通道，无人值守场景用 scoped 令牌而不是个人凭据。把”AI 工具能实测什么”当成权限设计问题而不是工具接入问题，这套思路比工具本身更值得先落地。
参考链接
- – 原文：https://pganalyze.com/blog/workbooks-mcp-server-public-preview
- – MCP Server 文档：https://pganalyze.com/docs/mcp-server
