数据库接入智能体，先收紧 MCP 权限

把 AI agent 接上数据库之前，作者先做了一件事：收紧权限。Build Buddy 第 4 天的记录里，agent 最终没能查到在线数据，却通过日志定位了连接问题，并明确说明改用了本地文件。

这篇短文的价值不在于展示 agent 能操作多少工具，而在于给出一个可借鉴的接入顺序：先限制能力，再验证连接，最后检查分析结果。即使 agent 如实报告了失败，也不能省掉人工核对。

只读权限为什么要在连接前设置

作者在 MLH Global Hack Week: Builders Week 的前一天，已经把 Build Buddy 的基准测试结果写进 Tiger Data 的超表（hypertable）。第 4 天，他通过 MCP（Model Context Protocol，模型上下文协议）把 AI agent 接到数据库服务。

这里的权限范围比「查几条 SQL」大得多。Tiger 的 MCP server 既能列出服务、读取日志和指标，也提供删除服务、重置密码等工具。如果直接接入，agent 获得的能力可能超出当前任务所需。

作者先执行了这条命令：

tiger config set read_only all

要留意最后的 all：按原文描述，这项设置会让删除、重置密码、创建、调整容量等写入工具不被注册。agent 看不到这些工具，也就无法调用它们。

还有另一层限制。作者援引 Tiger CLI 文档称，数据库会话也会以 Tiger Cloud 的只读模式打开，由服务端拒绝数据写入和数据库结构变更。

限制应当落在工具和数据库权限上，而不能只靠提示词要求 agent 自觉遵守。

查不到在线数据，怎样才算处理得合格

连接后，agent 能正常列出服务，却无法查询 build_results 表。作者所在网络阻断了数据库端口，直接 SQL 连接超时。

agent 随后通过 Tiger API 读取服务的实时日志，发现没有客户端连接到达。这一步很有用：数据库查询通道受阻时，管理 API 仍然提供了排查线索。

但日志不会自动变成查询结果。agent 明确告诉作者，它无法实时查询表，接下来使用的是本地结果文件，没有把文件中的数字包装成在线查询所得。

分析本地文件时，它找到了两处值得回看的信息：

• 作者第 3 天文章里的两次热启动 CS0029 耗时实际是 7.7 s 和 7.6 s，并非两次都是 7.6 s。
• 排除冷启动后，即使模型已经预热，CS0161 仍是最慢的错误，各次耗时落在 10.4–12.9 s。

不过，agent 自己也犯了错：它把 Alberta 标成了 Central Time。作者用这个小错误提醒读者，agent 能检查人的记录，人也需要检查 agent 的输出。

我的判断

我赞成作者的接入顺序。相比把所有工具交给 agent，再用提示词约束操作，只读配置提供了更直接的权限边界；工具层隐藏写入能力，数据库层拒绝写入，也让限制有了两处落点。

但这篇记录证明的是一次具体使用过程，不能据此判断 agent 排查数据库故障有多可靠。原文没有给出完整调用记录、分析提示词，也没有说明本地文件与数据库数据是否完全一致。

CS0161 的结论也应限定在作者这批运行结果里。它值得继续调查，却不足以说明其他模型或项目同样如此。

agent 坦诚报告数据来源，是结果可检查的前提，不是结果正确的保证。

作者最后计划处理 Build Buddy 的行为检查，即 issue #1：修复不仅要构建通过，还要保持行为一致。这是下一步目标，原文没有展示它已经完成。

能拿来做什么

• 给日常 AI 编程助手接入数据库时，先使用平台提供的只读权限；使用 Tiger 时，可以参考原文命令，并检查实际暴露的工具范围。
• 遇到查询超时，先区分连接是否到达服务端，再检查 SQL 和表结构。原文中，通过 Tiger API 读取日志提供了关键线索。
• 让 agent 分析构建耗时或错误记录时，要求它注明数据来自实时查询还是本地文件，并人工复核关键数字及比较条件。
• 检查 AI 提交的修复时，把构建通过与行为符合预期分别验证。作者提出了这个方向，但具体检查方法还需要团队自行落实。