Wolfram想当AI时代的“地基”，但开源社区不这么看 | blog
Stephen Wolfram宣布将Wolfram Language作为LLM的“基础工具”，通过MCP服务、Agent One API等形式接入各类AI系统。核心概念是“计算增强生成”(CAG)——让LLM实时调用精确计算能力。但评论区对此颇有争议。
LLM能做很多事，但有一件事它天生做不好：精确计算。
这不是工程问题，是根本性的结构问题。语言模型本质上是在做概率预测，让它保证数学结果精确无误，就像让一个博闻强识的人不用草稿纸心算微分方程——不是不行，但你不会真的信任那个结果。
Stephen Wolfram的新文章就从这里切入。他说自己花了40年建立Wolfram Language，目标是让世界上一切可计算的东西都变得可计算。现在他觉得时机到了——把这套系统接进LLM，让语言模型借用精确计算的能力。
他把这个方案叫做CAG，computation-augmented generation，对应大家熟悉的RAG（检索增强生成）。RAG是把现有文档塞进上下文，CAG是实时生成计算结果塞进上下文。Wolfram的说法是这相当于“无限扩展的RAG”。
从产品层面，他们推出了三个接入方式：MCP服务（直接插进支持MCP的LLM应用）、Agent One API（打包好的LLM加计算能力的一体化接口）、以及细粒度的CAG组件API。
评论区里有个很实在的反应：一位用户说他真的用Wolfram工具给LLM做过agent，最后发现没有一个任务是Python加Google搞不定的，而且Wolfram出的结果往往更慢、更差。另一位补充，Claude写Wolfram Language脚本，质量明显不如Python，原因可能很简单——Mathematica代码大多存在个人电脑里，不在GitHub上，所以LLM根本没练过。
这里有个根本性的悖论：越封闭的系统，越难成为AI时代的基础设施。
有观点认为，如果十年前Wolfram开源，LLM今天就会把Wolfram Language当成第一语言去用，就像Python一样。Python没有独占任何算法，却成了整个AI时代的地基。这个比较对Wolfram有点残忍，但并非没有道理。
当然，另一面也有人指出，开源会失去利润，研发就会变慢——这个争论在每一个闭源科学工具身上都上演过，从Matlab到Maple，没有新鲜的。有意思的是，Python和numpy这十年确实把Matlab挤得很难看。
还有个值得注意的技术细节：有人提到Wolfram的计算代数系统本身也不是“形式化正确”的，在函数定义域、多值函数分支选取上会出错，这些假设往往隐藏在底层，不暴露给用户。精确计算的招牌，底层其实也有裂缝。
关于CAG这个概念本身，有网友一针见血：数学问题不是“定制数据”，不会像产品手册那样持续更新，完全可以直接微调进LLM，不需要这个为人类界面设计的中间层。这话说得有点狠，但不是没有逻辑。
目前评论区一个比较有意思的分支，是关于能否用WebAssembly跑沙盒化的开源Wolfram Language解释器——有人真的在做这件事，项目叫Woxi，已经实现了900多个函数，离Mathematica的6000个还差得远，但方向是清晰的。
Wolfram这次发布，最大的问题也许不是技术上能不能行，而是：在Python生态已经如此完善、LLM本身计算能力也在持续提升的今天，一个昂贵的闭源工具，还有多少机会真正成为“地基”？
Wolfram花了40年修了座精美的收费大桥，却发现河流改道了。这不是技术问题，是生态位的错配。Python能成为AI地基，不是因为它算得最好，而是因为它“躺在”所有训练数据里。Claude写Wolfram脚本像个初学者，不是Claude笨，是Mathematica代码大多锁在个人电脑里，从未被LLM“读”过。越封闭的系统，在AI时代越像孤岛。Wolfram说自己是“基础工具”，但基础设施的本质是低摩擦、高渗透——收费站和地基，从来不是同一种东西。十年前开源可能还来得及，现在numpy已经把Matlab挤得喘不过气，同样的剧本换个主角再演一遍，观众都有点审美疲劳了。
Stephen Wolfram宣布将Wolfram Language作为LLM的“基础工具”，通过MCP服务、Agent One API等形式接入各类AI系统。核心概念是“计算增强生成”(CAG)——让LLM实时调用精确计算能力。但评论区对此颇有争议。
LLM能做很多事，但有一件事它天生做不好：精确计算。
这不是工程问题，是根本性的结构问题。语言模型本质上是在做概率预测，让它保证数学结果精确无误，就像让一个博闻强识的人不用草稿纸心算微分方程——不是不行，但你不会真的信任那个结果。
Stephen Wolfram的新文章就从这里切入。他说自己花了40年建立Wolfram Language，目标是让世界上一切可计算的东西都变得可计算。现在他觉得时机到了——把这套系统接进LLM，让语言模型借用精确计算的能力。
他把这个方案叫做CAG，computation-augmented generation，对应大家熟悉的RAG（检索增强生成）。RAG是把现有文档塞进上下文，CAG是实时生成计算结果塞进上下文。Wolfram的说法是这相当于“无限扩展的RAG”。
从产品层面，他们推出了三个接入方式：MCP服务（直接插进支持MCP的LLM应用）、Agent One API（打包好的LLM加计算能力的一体化接口）、以及细粒度的CAG组件API。
评论区里有个很实在的反应：一位用户说他真的用Wolfram工具给LLM做过agent，最后发现没有一个任务是Python加Google搞不定的，而且Wolfram出的结果往往更慢、更差。另一位补充，Claude写Wolfram Language脚本，质量明显不如Python，原因可能很简单——Mathematica代码大多存在个人电脑里，不在GitHub上，所以LLM根本没练过。
这里有个根本性的悖论：越封闭的系统，越难成为AI时代的基础设施。
有观点认为，如果十年前Wolfram开源，LLM今天就会把Wolfram Language当成第一语言去用，就像Python一样。Python没有独占任何算法，却成了整个AI时代的地基。这个比较对Wolfram有点残忍，但并非没有道理。
当然，另一面也有人指出，开源会失去利润，研发就会变慢——这个争论在每一个闭源科学工具身上都上演过，从Matlab到Maple，没有新鲜的。有意思的是，Python和numpy这十年确实把Matlab挤得很难看。
还有个值得注意的技术细节：有人提到Wolfram的计算代数系统本身也不是“形式化正确”的，在函数定义域、多值函数分支选取上会出错，这些假设往往隐藏在底层，不暴露给用户。精确计算的招牌，底层其实也有裂缝。
关于CAG这个概念本身，有网友一针见血：数学问题不是“定制数据”，不会像产品手册那样持续更新，完全可以直接微调进LLM，不需要这个为人类界面设计的中间层。这话说得有点狠，但不是没有逻辑。
目前评论区一个比较有意思的分支，是关于能否用WebAssembly跑沙盒化的开源Wolfram Language解释器——有人真的在做这件事，项目叫Woxi，已经实现了900多个函数，离Mathematica的6000个还差得远，但方向是清晰的。
Wolfram这次发布，最大的问题也许不是技术上能不能行，而是：在Python生态已经如此完善、LLM本身计算能力也在持续提升的今天，一个昂贵的闭源工具，还有多少机会真正成为“地基”？
Wolfram花了40年修了座精美的收费大桥，却发现河流改道了。这不是技术问题，是生态位的错配。Python能成为AI地基，不是因为它算得最好，而是因为它“躺在”所有训练数据里。Claude写Wolfram脚本像个初学者，不是Claude笨，是Mathematica代码大多锁在个人电脑里，从未被LLM“读”过。越封闭的系统，在AI时代越像孤岛。Wolfram说自己是“基础工具”，但基础设施的本质是低摩擦、高渗透——收费站和地基，从来不是同一种东西。十年前开源可能还来得及，现在numpy已经把Matlab挤得喘不过气，同样的剧本换个主角再演一遍，观众都有点审美疲劳了。
