← #804

无状态 MCP 重新勾起了我的兴趣

文章摘要

Simon Willison 把 2026 年 7 月 28 日称作「无状态 MCP 日」——MCP 2.0（正式名称是 2026-07-28 版模型上下文协议规范）的发布，是 MCP 自诞生以来最重大的一次变更，也重新点燃了他个人对这个协议的兴趣。

他先交代背景：MCP 是 Anthropic 于 2024 年 11 月推出的、向 LLM agent 框架暴露工具的标准方式，在 2025 年大部分时间里热度极高，随后被 Skills（同样出自 Anthropic）盖过了风头——因为大家发现，一个能用终端和 curl 的 agent 框架，可以用更灵活的方式做到 MCP 能做的大部分事情。而他现在正在转回来，理由有两条：第一，给 agent 一个能访问互联网的 shell 环境风险很大，而且需要一个足够强的模型才能有效驱动这种环境；相比之下 MCP 工具更容易审计和控制，简单到能在笔记本上运行的小模型也能把它们用得不错。第二，新的无状态规范大大降低了客户端和服务端的实现复杂度——他一周之内就写了三个。

具体差别在于：旧的有状态 MCP（他称之为「legacy MCP」）需要两次 HTTP 请求，第一次初始化会话拿到 Mcp-Session-Id，第二次才真正调用工具；新的无状态方式只需要一次 POST，通过 MCP-Protocol-Version、Mcp-Method、Mcp-Name 等请求头加上 JSON-RPC 载荷一次搞定，客户端信息挪进了 _meta 字段。这不仅让两端实现都干净得多，也更适合构建可伸缩的 Web 应用——服务端不再需要维护会话 ID 状态，也不用操心把同一会话路由到同一台后端机器。

他随后介绍了自己一周内做出的三个项目。mcp-explorer 是一个无状态的 Python CLI 工具，用来交互式探查 MCP 服务器，通过 uvx 免安装即可试用，支持 list 列出工具、inspect 查看某个工具（包括输入输出的 JSON schema）、call 带参数调用。他认为构建这类 CLI 工具是熟悉一份规范极其高效的方式，哪怕大部分代码是 agent 写的。datasette-mcp 是给任意 Datasette 实例加上 /-/mcp 端点的插件——这已经是他第四次尝试写这个插件，多亏新的无状态规范才终于做出一个自己满意、愿意发布的版本；它只提供三个工具：list_databases()、get_database_schema(database_name) 和 execute_sql(database_name, sql)（目前只读）。接到 agent 或 ChatGPT、Claude 这类聊天工具上，它们就获得了对你托管的 Datasette 实例执行 SQL 查询的能力；他把它跑在自己博客的 Datasette 镜像上，问「Simon 最近关于 MCP 说了什么」时模型跑了 7 条独立 SQL 查询才给出答案。第三个是 llm-mcp-client，给他的 LLM 命令行工具补上官方 MCP 集成的 alpha 版插件，他正考虑把它直接并入 LLM 核心。

文章最后一节的观点值得单独拎出来：MCP 是构建 agent 更安全的方式。他回顾了自己早年写的《模型上下文协议存在提示注入安全问题》一文——当时他指出，让终端用户自由搭配工具的模式，把避免数据外泄攻击的责任推给了用户自己（那时他还没造出「致命三要素 / Lethal Trifecta」这个词，但想的正是这件事）。然而随后拥有任意 shell 和 curl 权限的通用 agent 出现了，那要安全得多难得多。他现在体会到的是：相比在开放网络环境里执行任意命令（今天多数通用 agent 和编码 agent 工具的默认状态），MCP 让推理「agent 有哪些能力、可能出什么错」容易得多。因此在构建敏感应用时，他打算大幅倒向 MCP。

HN 评论精华

讨论区最大的一个主题是「这不就是 REST/RPC 吗」。drdexebtjl 的说法最有代表性：回过头看，有状态 MCP 显然是错的；这个改动本质上把 MCP 变成了另一个 REST API 端点，让你可以复用已有的那套基础设施——负载均衡器、API 网关、渐进式发布等等。pjmlp 顺势感慨：任何做过分布式系统、身上带过几道疤的人都知道无状态服务器总是更好，有状态只在别无他法时才用；他是在 Sun RPC 和「网络就是计算机」的年代学到这一课的，不知为何这件事总是要被反复重新学习。luciana1u 一句话总结了整段历史：「我们发明了一个有状态协议，发现状态难以扩展，把它剥掉，然后抵达了『发个 POST 请求就行』。REST 阵营已经带着优越感等这一刻等了二十年。」不过 senko 和 nesarkvechnep 都出来纠正：载荷里明明写着 jsonrpc，这是 RPC 不是 REST，讨论协议时这个区分是有用的。alansaber 用一句玩笑结束：「MCP 里的 P 就代表 REST。」
ai_critic 的评论最尖锐：「令人惊叹的是，一群年薪几十万美元的人……重新发明了 RPC-over-HTTP/JSON。各位同行 Web 开发者，你们也够聪明去 Anthropic 上班了。我很想看一份正经的工程复盘，讲讲这是怎么发生的。」firasd 给出了相对温和的解释：一部分原因可能是聊天应用流式传输的偏见（他们可能一直在用 SSE）；但也别低估当初在内部为 MCP 这种东西辩护有多难——实验室仍然是科学家主导、专注于在 token 空间里解决一切问题，在 Claude Code 出现之前，「工具使用可能是变革性的」这件事从内部看恐怕并不显然。
firasd 另一条评论精准反击了「直接用 CLI 就行」的阵营，是本帖被引用最多的观点之一：这种说法隐含假设了你 1) 是开发者、2) 在笔记本上、3) 在一个 agent 编码框架里开着 shell、4) 在做一个软件项目。「那大概占 AI 使用的 2%。」另外 98% 是：在地铁上用 ChatGPT iOS 应用提问的人、在 Claude.ai 网页上聊自己日程的人、用 ChatGPT 桌面版总结 Notion 的人、在公司浏览器里用 AI 的非开发者、手机上的语音模式、嵌在某家公司网站里的聊天组件。kristjansson 补了一个安全维度的犀利对照：你自己的消息让你的 LLM 在你电脑上跑 CLI，那叫迷人、刺激、有意思；别人的消息让你的 LLM 在你的（云端）电脑上跑 CLI，那叫恐怖、糟糕、令人作呕、一点都不好玩。acchow 也指出，CLI 派同样主要是在自己的电脑上用 LLM，那里才有他们的 CLI 工具；从 Web、Slack 或 Linear 跟 LLM 对话时，你就需要 MCP 让 LLM 以你的身份使用服务——这才是可移植性。不过 eddythompson80 提出了反向的观察：他知道至少有四个团队在做 ChatGPT/Claude.ai 那样的 Web 界面 agent，这些团队最终都发现，你迟早得给 agent 一个小型沙箱 Linux 环境，才能解锁编码框架所展现的那种「智能」水平——把 CLI 命令的结果用脚本或代码串起来，能让 agent 把文本生成能力转化为可执行逻辑，灵活性大得多；工具调用主要适合执行动作，而不是复杂新颖的问题求解。
上下文膨胀是另一条主线。cheema33 抱怨 MCP 服务器的主要问题是撑爆上下文：Skills 有渐进式披露（progressive disclosure），还能用 disable-model-invocation: true 关掉自动调用，而多数 MCP 服务器即便完全没在用也会占着上下文。SyneRyder 纠正说现代框架已经不这样了，MCP 现在也是渐进式披露——工具描述不再默认包含，需要通过 tool_search 找到；但他觉得这其实是种倒退，模型有时会开始写 Python 脚本，而其实早有现成的 MCP 工具可用。Eldodi 更直接：MCP 上下文膨胀至少从二月起就是已解决的问题，OpenAI 和 Anthropic 都支持客户端 MCP 工具搜索，加载效率已与 Skills 相当；Cloudflare 的 code mode 很好，但在 95% 的场景里已经不必要了。troupo 则对 Skills 的说法泼冷水：「Skills 当然也污染上下文。你真以为存在一个能装下无限技能的魔法口袋？」
rutierut 提出了一个具体而未解的工程问题：以 Linear MCP 为例，它基本上就是想暴露一整个 API 面，于是给了 32 个 MCP 工具；他的 agent 经常撞上可组合性问题，最后回退到它附带的那个「跑任意 GraphQL」的工具，通常要试几次才成。Cloudflare 转向的 code mode 只提供两个工具——search 和 execute，都接受 TS 箭头函数，前者用于以编程方式搜索 TS API 规格，后者用于组合并运行其中的方法。他认为这个思路很有意思，肯定强过直接抛出约 1000 个动作，但效果究竟如何还未定论。cush 也从可组合性角度质疑：MCP 的整个响应最终都会进上下文窗口，而一个像样的框架和 agent 通常会在一条长命令里把多个工具管道串联并过滤，不用额外烧那么多 token。nextaccountic 回应说这是框架的问题而非协议的问题，并举了 maki 的 code_execution 工具为例：它跑一个解释器，把所有其他工具作为异步函数暴露出来，用来过滤/汇总/变换/管道传递数据，全程不进入上下文窗口；实在不行也可以关掉框架原生 MCP，让 agent 用一个调用 MCP 的 CLI 工具，然后就能用普通的 Unix 管道处理输出。
怀疑派的代表是 Foobar8568：「我还是没搞懂 MCP。多半是因为我没认真看，但第一感觉是在为一个本来就不存在的问题制造一个问题。」mmasu 从企业角度回应：在企业里 MCP 让用户能访问那些通过 API 或 CLI 消费起来不安全或不现实的资源，这是个强大的模式，几乎所有客户端都支持，在自定义框架里也容易实现。qalmakka 给出了清晰的边界条件：它主要用于让沙箱化的 AI 应用访问外部功能；一旦 LLM 有了任何形式的 CLI 访问权限，MCP 就不再有意义，因为 LLM 非常擅长 CLI 而且几乎总是更省 token；而且 CLI 工具人也能用，MCP 只服务于 agent。kmarc 则给出了最愤世嫉俗也最好笑的解释：在他看来这基本上是公司政治——你的管理层根本不知道什么是 REST API，但他们在无数 LinkedIn 垃圾内容里见过 MCP，于是你就被允许去做一个，用它把 agent 接到那个 23 年历史、无人维护、全靠拿着超额薪水的 Frank 手动照料才没垮掉的自研 CRM 单体上。
工具生态方面，ameshkov 问为什么不用官方的 mcp-inspector，Simon 亲自回复贴出了两者的等价命令对比，承认「确实挺像的」，只是官方 --cli 模式的文档比较欠缺。hobofan 提醒想尝试的人：上周发布的 2.0.0 版本连一些最常见的连接场景都严重损坏，建议用 2.x 之前的最新版。garazy 推荐了 rmcp.dev（BuiltWith 的 MCP 发现服务），可以扒一遍他们发现的所有远程 MCP 服务器。pianopatrick 提出了一个折中构想：给 agent 一个 CLI 工具而非裸 curl，它只能调用配置文件里指定的 API，而配置文件 agent 改不了——这样既能复用 agent 已有的 shell 知识，又能限制它的网络调用，还不用架服务器。回复中给出了 latchkey 等几个已存在的实现。
SoKamil 对文中「Skills（同样出自 Anthropic 的发明）」这句话提出考据异议：他印象中这是 The Browser Company 的发明——Anthropic 的 Agent Skills 公告是 2025 年 10 月 16 日，而关于 Dia 浏览器 Skills 的文章和 Reddit 帖子在 2025 年 7 月就能找到。
TZubiri 提出了一个刻意天真的替代方案来质疑 MCP 的价值：如果 MCP 的核心增值只是「给 API 提供纯文本而非 HTML 式的文档」，那么我们完全可以 1) 发布一个类似 /docs_url 的知名端点；2) 支持 text/plain 或 text/markdown 之类的 content-type 头（或者干脆用 .txt 扩展名）。「那么请问，MCP 比我这个方案好在哪？是我严重误解了什么，还是我正走在避免数百个工程小时被偶然复杂度吞掉的路上——识别并绕开一个增加供应商锁定而非降低系统复杂度的私人资助协议？」