GitHub 等三家 MCP 服务器并发写入会静默丢更新
图片来源：Hacker News · AI
2026 年 11 月 10 日，研究机构 IsoKron 发布审计：GitHub、Grafana、PostHog 三家厂商为自己产品发布的 MCP 服务器，并发写入同一对象时都可能丢掉一次更新，而两个调用方都收到成功响应。据 Hacker News AI 版块记录，该研究于当天 22:36 被收录。
三家全中，姿势各异
测法很直接：两个进程同时写同一对象的不同字段，重复多次后读回对账。GitHub 的 MCP server v2.1.0 并发更新同一 issue 的两个字段，30 对丢 19 对；改走 GitHub 官方的按字段更新 API，28 对丢 0。Grafana 的 MCP server v2.2.0 更彻底：30 对面板补丁在 Grafana 13 与 11 上全丢。PostHog 托管 MCP 服务器丢 7/11 对，直连其 API 也丢 6/11 对。
AI 生成的事件示意图，不代表新闻现场照片。
病根各不相同
三家的病根不一样。GitHub 的 MCP 工具改一个字段时，把全部字段读出、合并、整包写回，没有版本校验，两个 agent 各改一个字段就互相覆盖——锅在 MCP 层。Grafana 的 MCP 工具在补丁模式下强制 overwrite，版本检查从未运行；背后的 legacy 保存接口也有并发缺口。Grafana 13 的 Kubernetes 风格 API 没有这个缺口，30 对里每次都拒绝一个保存。PostHog 的丢写出在产品 API 本身，MCP 服务器只是透传——agent 并行干活，更易踩中。
AI 生成的事件示意图，不代表新闻现场照片。
修复进度：一家次日合并，两家在路上
三家均收到 issue 或 PR。PostHog 的 insights 已修：维护者把改动重做成 PR 131620，约 17 小时后合并；cohorts 与 dashboards 的丢写仍未修复。GitHub 记为 issue 3751，修复 PR 3781 开放、未合并，补丁版 12 对丢 0。Grafana 的 PR 1518 待评审：改走 Kubernetes 风格 API 后 Grafana 13 上 60 对丢 0；Grafana 11 只有 legacy 接口，恢复检查后仍丢 14/30。研究自费、AI 辅助写作完成，未获三家委托背书。
真正的漏洞是沉默
IsoKron 交代了局限：每组只有 11 到 30 对样本，写入由脚本故意同时释放，证明的是碰撞必丢，读不出日常发生率；三家也代表不了 MCP 生态。丢掉的改动可以补写回去，在 Grafana 的版本历史里甚至还在。要害是：没有任何提示告诉 agent 或用户需要补写。方法与数据见 IsoKron 研究页面。
一条写入被吞掉，两个调用方都听到“成功”——系统用安静的谎言，换来了表面的和平。
多个 agent 并行编辑同一块看板、同一列 issue，正从例外变成常态，写冲突也随之变成日常磨损。用凯文·凯利的演化视角看，这近乎必然：并行作业的工具体，迟早要长出处理写冲突的神经系统。用乔布斯的标准量：对用户谎报成功的界面谈不上尊重，尊重是把坏消息第一时间说清楚。MCP 的下一课：把“我可能弄丢了你的改动”大声说出来——比更聪明的模型更要紧。