MCP on 魔都水滴

AI 怎么学会“用手”的？从只会聊天到会查、会写、会操作

Sun, 19 Jul 2026 22:00:00 +0800

先说结论

AI 并不是突然长出了手。它只是学会了一个非常关键的动作：先判断自己需要什么工具，再用结构化参数请求工具，等工具返回真实结果，最后把结果翻译成人话。

这套机制通常叫 Tool Calling（工具调用）；在不同平台上也会看到 Function Calling、Tools API 等名字。MCP（Model Context Protocol，模型上下文协议）则像一套“统一插座”，让不同的 AI 应用可以用相似的方式发现和调用文件、数据库、搜索、工单、浏览器等能力。

本文不把 AI 神化成“会自己做事的数字员工”，而是把一次调用拆开给你看：模型到底做了什么、真正执行动作的是谁、为什么 MCP 会火、权限应该放在哪里，以及为什么“能调用工具”不等于“可以随便给它钥匙”。文中截图来自 OpenAI 与 MCP 官方页面，命令输出图为本文根据真实调用流程制作的示意证据；文章不包含任何真实内网地址或主机名。

别再让 AI 猜故障了：MySQL + Prometheus + Loki + Grafana 四件套接入 Agent 全自动实战

Sat, 11 Jul 2026 08:30:00 +0800

很多团队已经把 MySQL、Prometheus、Loki 和 Grafana 装起来了，但线上报警之后，值班人员仍然要在四个窗口之间来回切换：先看仪表盘，再写 PromQL，然后去日志里搜索 trace_id，最后登录数据库核对业务记录。这就像医院明明有体温计、病历、化验单和监护大屏，医生却仍要自己跑四个房间抄数据。AI Agent 真正有价值的地方，不是替医生“猜病”，而是拿着受限制的工具，自动把四处证据取回来，再把“现象、证据、根因和建议”分开说明。本文不是概念拼贴。我实际启动了一套隔离环境，使用 MySQL 8.4、Prometheus 3.13、mysqld_exporter 0.19、Loki 3.7 和 Grafana 13.1，注入了一次带统一 trace_id 的慢查询故障，然后通过自建只读 MCP Bridge 完成协议初始化、工具发现、PromQL 查询、LogQL 查询、MySQL 只读查询和 Grafana 数据源审计。先说结论：四件套接入 Agent，不等于把四套管理员密码交给 AI 正确的架构应该满足下面几条： MySQL 仍然保存业务事实，Agent 只能使用专门的只读账号； Prometheus 负责保存数字随时间的变化，例如连接数、QPS 和缓存命中率； Loki 保存“发生了什么”的日志，并通过标签、时间和 trace_id 关联事件； Grafana 继续承担人工观察、仪表盘、数据源管理和结果复核； MCP Bridge 把查询包装成边界明确的工具，而不是开放任意 Shell； Agent 先调用工具取证，再总结答案，不能把语言模型的推测冒充事实。换句话说，Agent 拿到的应该是一串“只能打开指定抽屉的钥匙”，而不是整栋楼的万能钥匙。四件套分别是什么？用小学生也能懂的方式解释 MySQL：学校老师手里的成绩册 MySQL 保存订单、用户、库存、付款状态等业务事实。你问“这个订单到底有没有支付”，最终应该以数据库记录为准。它像成绩册：里面写着谁参加了考试、得了多少分。成绩册擅长回答具体事实，却不适合每隔五秒画一次“全校平均分变化曲线”。 Prometheus：每隔几秒自动测一次体温 Prometheus 会定时抓取指标，并保存时间序列。借助 mysqld_exporter，MySQL 的连接数、查询数、线程状态等数据会被翻译成 Prometheus 能理解的格式。它像自动体温计：一次读数只能告诉你现在是 38℃，连续读数才能告诉你温度是突然升高、持续升高，还是已经恢复。下面是真实实验中的 Prometheus Targets 页面。mysql 抓取目标显示为 UP，说明 exporter 与 Prometheus 的链路已经打通。

别再人工翻日志了：ELK 三件套接入 AI Agent，从部署到自动排障的手把手教程

Sat, 11 Jul 2026 03:30:00 +0800

过去，线上报警后的标准动作通常是：打开 Kibana、选择时间范围、输入查询语句、翻几十页日志、复制错误堆栈，再把零散证据拼成结论。系统一多，这件事很像在一座没有导购员的巨大仓库里找一颗螺丝。现在可以换一种方式：让 ELK 继续负责可靠地收集、整理和搜索日志，再给它加一座 MCP “翻译桥”，让 AI Agent 用工具读取证据。于是你可以直接问：最近 15 分钟哪个服务的 5xx 最多？请列出证据、关联 trace_id，并给出下一步排查建议。 Agent 不再只靠语言模型“猜”，而是先调用 Elasticsearch 查询，再根据返回的数据组织答案。本文不是概念拼贴。我实际启动了 Elasticsearch、Logstash、Kibana 和 Elasticsearch MCP Server，导入一组脱敏故障日志，完成 MCP 协议握手与查询，并记录了中途踩到的权限问题。先说结论：真正有价值的不是“让 AI 看日志”，而是让它有边界地查日志接入后的合理架构是： Logstash 负责接收、解析、清洗和补充字段； Elasticsearch 负责索引、搜索、聚合与保存； Kibana 负责人工可视化、验证和审计； MCP Server 把查询能力包装成 Agent 能理解的工具； AI Agent 负责拆解问题、调用工具、总结证据，但默认不拥有删除和写入权限。这与“把所有日志复制给聊天机器人”完全不同。后者既容易泄密，也会受上下文长度限制；前者让数据留在自己的 ELK 中，Agent 只取当前问题需要的少量结果。如果给小学生解释，可以把它想成一座图书馆：Logstash 是收书和贴标签的工作人员，Elasticsearch 是记住每本书放在哪里的图书管理员，Kibana 是墙上的查询大屏，MCP 是翻译员，AI Agent 是会帮你办事的值班同学。你问“哪一类事故最多”，值班同学不会凭印象回答，而是让翻译员去问图书管理员，然后把查到的书名和页码一起交给你。 ELK 三件套到底是什么 Elasticsearch：不是数据库替代品，而是搜索与分析引擎 Elasticsearch 将文档建立倒排索引，擅长全文检索、时间范围过滤、多条件查询和聚合统计。日志场景中，一条日志通常是一份 JSON 文档，包含时间、服务、级别、消息、状态码、耗时、链路标识等字段。它最像一本超级厚的词典。普通数据库像按页码翻书；倒排索引则像先做“关键词 → 出现位置”的目录。因此当日志达到百万甚至亿级时，仍然可以快速回答“过去 10 分钟 payment 服务出现了多少次 504”。

别再手点虚拟机了：Proxmox VE 接入 AI Agent 手把手教程，默认只读也能自动巡检

Sat, 11 Jul 2026 02:30:00 +0800

很多人第一次听到“让 AI 管 Proxmox VE”，脑子里出现的画面是：对 AI 说一句话，它就能创建虚拟机、扩容磁盘、重启服务，甚至自动修复故障。这个方向没有错，但真正安全的起点不是“把管理员密码交给 AI”，而是给 AI 一张只读、可撤销、可限制范围的门禁卡。本文会从零解释 Proxmox VE、API Token、MCP 和 AI Agent 的关系，给出人工配置与 Agent 自动配置两条路线，并提供 Windows 11、Ubuntu 26.04、macOS 26 三套一键脚本。图：本文自制题图。AI Agent 不应拿到机房“万能钥匙”，而应通过受限 Token 和 MCP 桥接访问 Proxmox VE。先说结论如果你只想记住最重要的内容，请记住下面几句话： Proxmox VE 是一套开源虚拟化管理平台，可以集中管理物理节点、KVM 虚拟机、LXC 容器、存储、网络、备份与集群。 AI Agent 不能凭空理解 Proxmox VE，它需要一个“翻译员”。本文使用本地运行的 MCP Server，把 Agent 的工具调用翻译成 Proxmox REST API 请求。第一阶段只授予 PVEAuditor，并保持 PROXMOX_ALLOW_ELEVATED=false。此时 AI 可以盘点和巡检，但不能开关机、删除或修改资源。 API Token 要单独创建、单独授权、随时可撤销，不要把 root 密码写进 Agent 配置。接入成功的标准不是“配置文件没报错”，而是 Agent 能列出工具、Proxmox 返回合法数据、权限边界符合预期，而且写操作确实被拒绝。 Proxmox VE 到底是什么 Proxmox Virtual Environment，通常简称 Proxmox VE 或 PVE，是一套面向服务器虚拟化的开源平台。它把几个原本需要分别维护的能力放进同一个管理平面：

MCP 明明没配错，为什么一启动就挂？一次 Codex MCP 故障的完整拆解

Sat, 23 May 2026 06:10:00 +0800

先说结论

这次故障最容易误判的地方，是表面错误写着 “MCP Client 启动失败”“MCP Server 握手失败”，于是人很自然会去怀疑 MCP 配置、插件开关、网络、Token、JSON 格式、stdio 协议，甚至怀疑 Codex 本身挂了。但真正的根因并不在 MCP 协议层：某个 MCP Server 对应的本地二进制在启动瞬间就被 macOS 动态链接器杀掉了，根本没有机会完成 initialize 握手。Client 看到的只是连接提前关闭，Server 端真正留下的线索是 dyld: Symbol not found，缺的是 Swift Concurrency runtime 里的一个符号。

换句话说：MCP 没有来得及失败，Server 进程先死了。

这篇文章记录一次很典型、也很容易绕远路的 Agent 工具链故障：Codex 里 MCP Client / MCP Server 启动异常。它不是一个“修改配置就好”的问题，而是一个从应用层错误一路追到本地二进制、动态链接器、Swift runtime 兼容性的排障过程。

为了避免泄露任何隐私信息，本文不包含真实内网地址、真实用户名、真实会话 ID、真实本机绝对路径、Token、私有仓库地址或任何业务系统名称。文中路径都使用 ~、<USER_HOME>、<PLUGIN_DIR>、<PROJECT> 等占位符表示；命令输出也只保留与判断根因有关的公开技术字段。