首页 › trending › 反MCP的投降了,数学家坐不住了

导语: 这两天海外技术社区的两场争论,比任何新模型发布都值得中文圈注意。第一场:那个把“不支持MCP”写在官网首页当荣誉的Pi团队,9月29日正式宣布投降,MCP进核心,还附带一个叫Codemode的新玩法;第二场:普林斯顿高等研究院牵头,九位顶级数学家组建独立委员会,专门管OpenAI声称由内部模型产出的“大批数学成果”该怎么发布。一个关于Agent工具调用的下一步,一个关于AI产出如何进入学术体系,都是半年内会波及你工作方式的事。


一、嘴最硬的反MCP旗手,把MCP搬进了核心

先交代背景。Earendil是一家公益公司(public benefit corporation),他们的主力产品Pi是一个编程Agent,官网pi.dev。过去一年,这个团队是英文圈最出名的“反MCP派”:官网首页挂着“Pi不支持MCP”的声明,上播客就嘲讽MCP,合伙人Mario还专门写过一篇嘲讽文。

然后,北京时间9月29日,他们发了一篇标题就很戏剧性的文章:《"You Said No MCP!"》——你们不是说不用MCP吗?这篇帖子在Hacker News上拿下614分、341条评论,冲上首页前列。

为什么反转?文章给了三层理由,每一层都值得细看:

第一层:MCP本身变了。 原文的原话是“今天的MCP不是去年的MCP”(the MCP of today is not the MCP of yesteryear)。协议这一年迭代了不少,早期那些硬伤被磨掉了一部分。

第二层:改造MCP需要的能力,恰好Pi自己也想要。 他们为接入MCP做的底层改造——延迟工具加载(deferred tool loading)、会话中途插入系统消息、推理等级动态切换——反过来让Pi能更好地适配新一代模型。一鱼两吃。

第三层最有意思,是策略性的: “我们认为对一件事施加正面影响的最好方式,就是拥抱它。”(the best way to positively influence something is to embrace it)翻译一下:与其站在场外骂,不如进场抢话筒。

文章自己承认的MCP三宗罪

这篇反转文最有价值的部分,其实是它作为“资深反对者”给出的批评清单。三条:

  1. 难以组合(hard to compose)——这被点名为MCP至今最大的问题。多个工具调用之间没法像写代码一样自由编排;
  2. Server还在为错误的消费方式设计——很多MCP server仍然假设harness会把所有工具描述一股脑倒进上下文,然后靠返回一大段文本“省token”,这个模式已经过时了;
  3. 发现性差——他们的理想形态是“更接近OpenAPI,加上智能工具发现”:工具应该返回结构化数据,应该能靠文档和描述被Agent按需找到,而不是全量塞进去。

Codemode:比MCP反转更值得抄的东西

文章的后半段才是给开发者的干货。Pi接MCP不是简单加个适配层,而是配了一个叫Codemode的机制:

官方给的例子很直观:让Pi“用codemode通过typesafe/jev找出我们issue tracker上最沮丧的20个评论者”,它会自己组合Linear MCP和Jev数据分析工具完成整个流程,原文的形容是“完全不浪费上下文”(without wasting any context at all)。

一句话总结这个模式:过去是让模型在对话里一步步调用工具,每一步都烧token;现在是让模型写一段编排代码,脏活在沙箱里跑完,只把最终结果交回对话。 原文还特意补了一句:CLI之所以好用,就是因为Agent能用bash高效地把东西串起来,而MCP没有理由做不到——把MCP工具暴露给JS沙箱这件事,Codex等产品也已经在做了。

flowchart TD
    A["Agent 主循环<br/>受信任区"] --> B["Codemode 沙箱<br/>用 JS 编排调用"]
    A --> C["老模式<br/>工具全塞进上下文"]
    B --> D["Linear MCP"]
    B --> E["Jev 分析工具"]
    B --> F["其他 MCP 服务"]
    D --> G["返回结构化数据"]
    E --> G
    F --> G
    G --> H["沙箱内 JS 汇总<br/>只回传最终结果"]
    C --> I["步步烧 Token<br/>上下文爆炸"]

这场争论里的三个阵营,你可以对号入座:协议派认为MCP已是事实标准,生态滚雪球,反对者终将回归(Earendil的投降被不少人视为标志性节点);代码派认为工具编排的终局是“代码即胶水”,上下文只留意图,Codemode是这一派的最新代表作;观望派则指出真正卡脖子的不是协议而是server质量——大量server还在按“倒进上下文”的老假设设计。有意思的是,这三派的观点全部能从这篇“投降书”原文里找到依据,这大概就是它评论区炸出341条讨论的原因。

对中国开发者的启示: 国内做Agent平台和MCP市场的团队,接下来比拼的不再是“接了多少个server”,而是“编排层省了多少token”。挑MCP server时可以直接用Earendil给的两条标准过滤:返回结构化数据吗?能靠文档被按需发现吗?两条都不满足的,尽早换。


二、九位数学大佬出山:AI出的定理,先别急着发

第二场热闹更冷门,但信号更强。

HN首页上有个77分、98条评论的帖子,标题是《Responsible Release of AI-Generated Mathematics》(AI生成数学的负责任发布),指向一个新上线的网站:agmai.org。

这个网站的全称是Advisory Group on Mathematics and Artificial Intelligence(数学与人工智能顾问组),挂在普林斯顿高等研究院(IAS)名下。看成员名单你会明白分量:Edward Witten(IAS,1990年菲尔兹奖得主)、Timothy Gowers(剑桥/法兰西公学院,1998年菲尔兹奖得主)、Martin Hairer(EPFL/帝国理工,2014年菲尔兹奖得主)、Camillo De Lellis、Ravi Vakil(斯坦福)、Melanie Matchett Wood(哈佛)、Ulrike Tillmann(牛津)、Nikhil Srivastava(伯克利)、François Charles(巴黎高师)——一共九人,覆盖数学主要版图。

事情的起因,网站自己写得很坦白:OpenAI主动接触了其中几位数学家,想请他们组成一个外部顾问委员会。数学家们的回应是:可以,但不挂你的牌子。他们转过头自建了一个独立组织,还开放邀请更多人加入,并且明确了三条底线——

  1. 独立且无偿:独立于任何AI公司运作,成员不为此拿钱;
  2. 只建议、不决策:没有在任何AI公司内部的决策权,公司做什么决定,责任归公司;
  3. 公开透明:给AI公司的建议会发布在网站上,任何人可查。

而他们目前的“Current Task”(当前任务)一项写得更直接:正在建议OpenAI如何协调发布“一大批重要数学成果”——注意,网站用的措辞是“他们报告称由内部模型产出”(they report have been produced by their internal model),也就是说,这批成果的数量和分量目前是OpenAI自己的说法,尚未经独立验证。顾问组同时开放了表单,向全球数学社区征集意见,明确说这些意见将直接影响给OpenAI的建议。

flowchart TD
    A["OpenAI 内部模型"] -->|自称产出大量成果| B["数学界面临发布难题"]
    B --> C["OpenAI 想设外部顾问会"]
    C --> D["数学家拒绝挂靠"]
    D --> E["自建独立 AGMAI"]
    E -->|发布建议| F["协调成果发布节奏"]
    E -->|征集意见| G["全球数学社区表单"]

为什么这事在社区里吵起来了?98条评论对77个点赞,评论数接近点赞数——在HN的生态里,这个比例通常意味着严重分歧而非一边倒。争论的焦点其实不难猜,拆开是三个问题:

无论你站哪边,这件事的信号意义都很清晰:当AI产出的学术成果从“零星巧合”变成“批量洪水”,学术共同体开始主动搭建治理接口,而不是等着被冲垮。 数学界抢了第一个身位,而且选了一种很聪明的组织形态——独立、无偿、只输出公开建议,既不替OpenAI背书,也不拒绝接触。

对中国科研人群的启示: 两件事值得马上做。第一,如果你在数学或相邻学科,agmai.org的表单是公开的,意见征集明确写着“尽快”(as soon as possible),现在提交成本最低、影响权重可能最高;第二,盯着这套“独立顾问组”模式——它大概率会成为其他学科跟AI公司打交道的参考模板,谁先在自己的领域复刻这个接口,谁就有定义规则的机会。


三、同一天,最热闹的反而不重要

最后补一个背景板:就在上面两场争论发酵的同一个HN首页,第一名是Google的“Gemini 4 Argon”发布帖(blog.google),958分、652条评论。我尝试抓取官方博客详情,截止发稿该文还没出现在Google博客的Gemini栏目索引里,具体参数、价格、可用范围请以官网为准,这里不做任何转述。

但这个“冷热对比”本身就是本期最有用的视角差:958分的发布帖,一周后价值会归零——参数下周就旧了;而614分的协议反思和77分的学术治理,讨论的东西半年后还在影响你的技术选型和科研环境。 海外社区的真正价值从来不在头条,而在头条下面那些吵得不可开交的二楼三楼。


信息差总结

你可能以为 别人已经知道
MCP还要不要用仍在争论 最硬的反对者已把它搬进核心,争论焦点变成“编排层怎么省token”
Agent调工具只能一步一步来 Codemode模式:写段JS在沙箱里批量编排,上下文几乎零消耗
AI出数学成果是纯喜事 数学界成立独立委员会,专门管“怎么发、何时发、谁验证”
HN第一名就是今天最重要的事 头条是发布会,二楼三楼才是路线图

行动指南

  1. 今天就读原文(10分钟):earendil.com/posts/you-said-no-mcp/,重点看Codemode一节,比二手解读准确十倍;
  2. 审计你的MCP用法:数一数你的Agent上下文里现在塞了多少工具描述token,超过总预算两成的,考虑改造成“代码编排+结构化返回”模式,Claude Code和Codex用户可以直接把多步工具调用改写成一段脚本;
  3. 用两条标准过滤MCP server:是否返回结构化数据、能否靠文档按需发现,不满足的从你的工具链里降级;
  4. 科研读者提交意见:访问agmai.org,通过页面表单向顾问组提交你对“AI数学成果发布”的看法;
  5. 设一个6个月检查点:2027年4月回头验证两件事——代码编排是否成为Agent框架标配、其他学科是否出现类似AGMAI的组织。

延伸思考

这两场争论表面不相干,内核是同一件事:AI的能力增长太快,所有“消费AI能力的接口”都在被迫重构。 Agent领域重构的是工具调用协议,从“堆进上下文”走向“代码编排”;学术界重构的是成果发布流程,从“期刊审稿”走向“公司-共同体谈判”。共同规律是:谁先建接口,谁定规则。Earendil选择进场塑造MCP,数学家选择抢在成果发布前成立顾问组,都是在抢接口的定义权。对个人而言,别把精力花在站队某个协议或某家公司上,把精力花在理解“接口往哪个方向迁移”上——方向对了,具体工具三个月一换都无所谓。


参考来源

  1. Earendil官方博客:《"You Said No MCP!"》(2026-09-29):https://earendil.com/posts/you-said-no-mcp/
  2. AGMAI顾问组官网(含完整成员名单与当前任务):https://agmai.org/
  3. Hacker News首页快照(2026-10-01,"You said no MCP"614分341评论;"Responsible Release of AI-Generated Mathematics"77分98评论;"Gemini 4 Argon"958分652评论):https://news.ycombinator.com/
  4. Google官方博客Gemini栏目(Argon发布详情以此处更新为准):https://blog.google/products/gemini/

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入