Jason Wei 是那种「把想法说得很直白」的研究者。他在谷歌时期参与过思维链（Chain-of-Thought）那批开创性工作，后来又去了 OpenAI，2025 年 7 月加入 Meta Superintelligence Labs。他经常在 X 上写一些看起来简单、但实际在给整个行业纠偏的帖子。2026 年这一条就是典型：当很多人把「训一个小而精的认知核心，然后外挂一堆工具」当成通往通用智能的省力路线时，他站出来说——事情没这么简单。
这条帖子的价值不在于提出新方法，而在于**指出一个被广泛误读的捷径**。对做 Agent 的团队来说，他的提醒直接关系到技术路线的选择：你到底该把力气花在「把工具接口做得更好」，还是花在「让模型自己真的会做这件事」上。
速览卡：这位大佬和他说了什么
 | 大佬 | Jason Wei |
| 身份 | AI 研究者，思维链（Chain-of-Thought）系列工作作者之一；前 OpenAI、前 Google Brain，2025 年 7 月加入 Meta Superintelligence Labs | |
| 出处 | X（Twitter）个人账号，2026 年 | |
| 时间 | 2026 年 | |
| 核心观点 | 「1B 小模型认知核心 + 工具」不是通往通用能力的捷径；真正难的是把能力冻进权重（freeze capabilities into the weights），靠工具拼出来的能力始终是「外挂」而不是「内化」 |
Jason Wei 说了什么
他的论点建立在一个具体的设想之上。先看他对这整套路线的描述：
“The idea of training a 1B cognitive core… and then just hooking it up to tools.”
（译文）先训一个 1B 参数量的「认知核心」，然后把它接到各种工具上，就完事了——这个想法。
这个设想在圈内流传很广，它的吸引力是显然的：如果智能可以被压缩进一个极小的核心，剩下的一切（算术、检索、执行、记忆）都通过工具外挂，那么训练成本、推理成本、部署成本都会大幅下降。小模型跑在本地，工具接上云端，看起来是一条又便宜又优雅的路。Jason Wei 的回应是直接的否定：
“…but it’s not enough. You need to freeze capabilities into the weights.”
（译文）……但这还不够。你需要把能力冻进权重里。
「冻进权重」这个说法是整条帖子的核心。它指的是一个具体的技术过程：一项能力必须被真正训练进模型的参数里，成为模型「不用外挂就能做出来的事」，而不是依赖外部接口在推理时临时拼装。前者是「会」，后者是「能用工具做到」——这两件事在工程上差别巨大。
为了把这层意思讲清楚，他用了一个运动类比。关于打羽毛球这件事，他的说法是这样的：
“It’s like if you want to be good at badminton, you can’t just buy a nice racket.”
（译文）这就像你想打好羽毛球，光买一把好球拍是不够的。
球拍是工具。买一把顶级球拍，确实能让你在同等水平下打得更好一点，但它不会让你学会正确的步伐、挥拍时机、以及对球路的预判。这些能力必须通过训练长在身体里。工具能放大你已有的能力，但不能替你产生能力。这就是他说的「工具不是能力」。
背景：这条「捷径」为什么吸引人
要理解 Jason Wei 为什么专门出来泼这盆冷水，得先知道这个设想是怎么流行起来的。
过去两年，「Agent」成了行业最热的词。一个典型的 Agent 架构是：一个语言模型作为「大脑」，加上一套工具（搜索、代码执行、数据库、浏览器、文件系统），再加上一层编排逻辑。这套架构在工程上非常成功——它让并不完美的模型，通过工具补足短板，完成了很多原本做不到的任务。于是很自然地，有人开始推演：既然工具能补足这么多，那大脑本身是不是可以很小？如果只保留「推理和决策」这个核心，其余全交给工具，是不是就能得到一个既便宜又强的系统？
这个推演在理论上并非没有道理。它背后的直觉是「分工」：让专业的东西做专业的事，大脑负责指挥，工具负责执行。这在人类组织里是成立的——一个优秀的管理者不需要自己会写代码、会做账、会修水管。所以「1B 认知核心 + 工具」在类比上看起来很合理。
问题出在类比失效的地方。人类的组织分工之所以有效，前提是**每个被分工的成员本身都是完整的智能体**——那个会修水管的人，有自己的认知能力。而工具不是智能体，它是一段确定性的程序。工具能做的是「精确执行你描述好的操作」，做不到的是「在没被描述的情况下自己判断该怎么办」。所以「把任务交给工具」和「把任务交给下属」，在能力要求上完全不同：前者要求大脑把一切细节都想到，后者只需要大脑把目标说清楚。
这正好指向 Jason Wei 论点的核心：**如果大脑不够聪明，它连「该调用什么工具、该怎么描述任务」这件事都做不好**。工具不能弥补认知的不足，反而对认知提出了更高的要求——因为调用工具本身，就是一个需要判断力的动作。
还有一个更现实的原因让这个设想流传得特别快：它非常契合「降本」这个当下最紧迫的商业诉求。当推理成本成为产品能否盈利的关键变量时，「把模型做小」几乎是所有团队都会想到的第一步。而「1B 认知核心」这个数字之所以有吸引力，是因为它已经小到可以跑在手机和笔记本上——这意味着接近于零的边际推理成本。这种商业上的诱惑，往往会让技术判断的边界变得模糊。Jason Wei 的帖子本质上是在这个边界上画了一条线：**省钱是合理目标，但不能用「能力外包」的方式去省，因为那省掉的是能力本身。**
核心观点展开：「冻进权重」到底难在哪
把「能力冻进权重」这句话展开，它包含三层含义，每一层都有对应的现实困难。
**第一层：泛化能力只能来自训练，不能来自接口。** 一个真正「会」某项任务的模型，面对任务的各种变体都能应对：换了表述方式、换了输入格式、换了边界条件，它依然能做对。这种泛化来自训练时在大量数据上学到的分布规律。而一个「靠工具拼出来」的系统，面对分布外的输入时，往往会在「要不要调工具、调哪个工具、参数怎么填」这几个环节上出错。换句话说，工具的加入并没有提升泛化，只是把失败点从「计算」转移到了「判断」。
**第二层：能力的内部化能压缩推理链条。** 一个把技能练进权重的模型，做这件事时可能只需要一步；一个靠工具的系统，需要先生成「我该用什么工具」、再生成「参数是什么」、再等待工具返回、再解析结果、再决定下一步。这个链条里每一个环节都是潜在的失败点，也都消耗 token 和时间。Jason Wei 说的「冻进权重」，本质上是把这些中间步骤压缩掉——让模型直接「做出来」，而不是「想清楚用哪个工具、然后去做」。
**第三层：小容量核心必然要放弃能力。** 这是最硬的一层约束，也是很多「小核心」设想回避的问题。参数量决定了模型能容纳的知识和能力的上限。一个 1B 模型即使训练得再好，它的容量就摆在那里——它不可能同时把语言理解、世界知识、多步推理、代码生成、数学运算都学好。这不是训练技巧问题，是容量问题。所以「1B 认知核心」这个设想的真实含义，是**主动放弃一部分能力，指望工具补上**。而 Jason Wei 的判断是：放弃容易，补上难。
这三层合起来，指向他给出的三条理由：泛化不可外挂、内部化能提效、小容量必须取舍。这三条并不需要新实验来验证，它们来自已经被反复确认的经验事实——这恰恰是这条帖子的分量所在：他不是在争论一个未定论的问题，而是在提醒大家一个被热度掩盖的常识。
行业内的讨论与不同声音
Jason Wei 的这条判断，在行业里引起的共鸣多于反驳，但反驳的方向很值得看，因为它们指向了另一条真实的技术路线。
**支持方的核心论据是 Scaling Law 的历史经验。** 从 GPT-2 到 GPT-4，每一次显著的能力跃升，都伴随着参数量和训练量的上升，而不是「架构变得更精巧」。语言模型在算术上的表现是经典案例：早期的模型即使外挂了计算器，在需要「先判断该算哪一步、再调计算器」的多步问题上依然频繁出错；而当模型规模和训练量上去之后，它自己就能算对很多题，反而不再需要外挂。这个经验支持 Jason Wei 的核心判断——能力得长在模型里。
**反方最有力的论据是「工具即能力扩展」的实证。** 反对者会指出：现实世界里，最强的系统恰恰是「大模型 + 工具」的组合，而不是纯大模型。代码智能体要跑测试、要读文件系统；检索增强要用向量库；数学求解要调符号计算。这些工具带来的提升是真实的、可测的。所以反方的结论不是「工具不重要」，而是「工具有用，但前提是大脑够强」——这句话其实和 Jason Wei 并不冲突，反而是对他论点的补充：工具是放大器，放大器需要先有信号。
**第三条线索来自「小模型 + 蒸馏」这条独立路线。** 近年确实出现了一批能力远超其参数规模的小模型，它们通过从大模型蒸馏、以及在海量高质量数据上训练，做到了「小而能打」。这看起来像是支持「1B 认知核心」的一方。但仔细看，这些成功案例的共同点是：**它们的能力依然来自训练，而不是来自工具**；而且它们在需要广泛知识的任务上，依然明显弱于大模型。这恰好印证了 Jason Wei 的第三层论述——容量上限是真实存在的取舍。
还有一类声音值得单独提：**关于「能力拼装」的安全担忧。** 如果一个系统由「一个较弱的核心 + 一堆强大的工具」组成，那么它的实际能力边界就很难被评估——单独看核心，它不过阈值；单独看工具，它们都是无害的。但组合起来能做什么，没有人能说清楚。这类风险对现有的「单模型评测 + 单模型阈值」监管是天然的盲区。Jason Wei 的这条帖子本身谈的是能力，但它指出的「外挂 vs 内化」这个区分，对安全评估同样适用：外挂出来的能力更难审计。
**还有一个很少被提及但很关键的实践分歧：工具调用的延迟预算。** 一个「外挂式」系统的响应时间，往往由串行的工具调用链路决定：模型生成调用意图（几百毫秒）→ 工具执行（视工具而定，可能是几十毫秒也可能是几秒）→ 模型解析结果并决定下一步（又是几百毫秒）。如果任务需要三五轮工具调用，累积延迟很容易超过十秒。而一个把能力内化的模型，做同一件事可能只需要一次前向推理。在交互式产品里，这个差别直接决定了用户体验是否可用。这也解释了为什么一些看起来「架构很优雅」的多工具 Agent 方案，在真实产品里表现平平——它的瓶颈不在能力，在延迟。
**另一个被忽视的成本是「工具维护」。** 工具的接口会变、依赖会失效、外部服务会限流。一个依赖大量外部工具的 Agent 系统，其稳定性上限由「最不稳定的那个依赖」决定。而内化的能力没有这个外部依赖——模型一旦训练好，它的能力就是自包含的。从长周期看，这两种架构的维护负担差异很大：外挂式系统需要持续投入工程资源去「保持能力不变」，而内化式系统只需要「保持服务可用」。这一点在选择技术路线时常常被低估，因为前者的问题往往在产品上线几个月后才集中暴露。
横向扩展：把这条判断放进更大的技术脉络
把 Jason Wei 的提醒放到更大的背景下，能看到三条更长的线索。
**线索一：工具使用的本质是「推理」，不是「接口调用」。** 很多人把工具使用理解成「模型输出一个 JSON，系统去执行」，这是接口层面的理解。但真正的难点在于：模型要先意识到「我现在的知识不足以回答这个问题」，再判断「哪类工具能补上」，再构造出正确的调用参数。这三个步骤都是推理任务。所以「模型不会用工具」这个问题的根源，往往不在接口设计上，而在模型的元认知能力上——它得知道自己不知道什么。这解释了为什么工具接口做得再漂亮，弱模型依然用不好。
**线索二：训练时学到的「程序性知识」和推理时的「临时拼接」是两种东西。** 认知科学里有一个经典区分：陈述性知识（知道什么）和程序性知识（知道怎么做）。一个能背出游泳要领的人不一定会游泳，因为后者需要身体层面的内化。语言模型的能力也有类似的分层：有些能力表现为「能复述」，有些表现为「能执行」。训练的价值，就是把前者变成后者。而工具能做的，更多是在「能复述」这一层上加辅助，很难直接制造「能执行」。
**线索三：成本结构在变化，但成本不会消失。** 「小核心 + 工具」路线最吸引人的地方是省钱。但真实的成本账要复杂得多：小模型节省的推理成本，可能被「因为判断力不足而需要更多重试」的成本抵消；工具调用的往返延迟，在交互式场景里可能比多花一点算力更贵。更重要的是，训练一个真正「把能力冻进权重」的模型，成本是前置的、一次性的；而依赖工具的系统，维护成本是持续的、随场景增长的。这两笔账在不同业务场景下结论不同，没有普适答案。这也是为什么 Jason Wei 的提醒是「别把工具当捷径」，而不是「别用工具」。
总结与启示
Jason Wei 这条帖子的价值，在于它把一句容易被忽略的常识重新说得响亮：**工具能放大能力，但不能产生能力**。这个区分在技术决策上有直接含义。
对做 Agent 的团队，第一条启示是**先确认失败发生在哪一层**。如果模型失败了，要分清是「它不知道该调什么工具」（认知问题，工具救不了），还是「它知道该调什么但接口不好用」（工程问题，改接口就能解决）。把这两类问题混在一起，会导致团队在错误的方向上投入——比如花大力气优化工具描述，却解决不了模型根本不会规划的问题。
第二条启示是**别用「外挂」掩盖「能力缺口」**。如果一个能力可以被外挂，说明它是确定性的、有明确接口的；这类能力确实适合外包。但如果一项能力需要判断、需要应对变化、需要在模糊情境下做取舍，那么把它外包给工具，只是把失败推迟到了更难发现的地方。
第三条启示是关于**评估**。既然「外挂的能力」和「内化的能力」在稳定性上差别很大，那么评测一个 Agent 时，就不能只看它在标准任务上的成功率。真正该测的是分布外表现：换一种表述、少给一个提示、多一个干扰项，系统还能不能做对。这项测试能直接区分「真的学会了」和「恰好能拼出来」。
回到那个羽毛球的比喻。它其实还有一层更深的含义：职业选手和业余爱好者的差别，不在于球拍好不好，而在于「动作是否已经变成本能」。本能的特征是——不用想，就能做对。Jason Wei 说的「冻进权重」，追求的正是这种「不用想就能做对」的状态。而在通向这个状态的路线上，没有任何一个工具能替代训练本身。
把这条判断再往外推一层，它其实也在回答一个更根本的问题：**我们到底在为什么样的智能做工程？** 如果目标是「做一个能完成特定任务的系统」，那么「小模型 + 精心设计的工具链」是完全可以接受的方案，很多业务场景下甚至是更优解——因为它的行为边界清晰、可控、可测试。但如果目标是「做一个具备通用能力的智能体」，那么把能力寄托在外部工具上，等于把智能的主体从模型转移到了「设计工具的人」身上。后者看起来更省事，但它把难题留给了未来：每一个新场景都需要人来设计新的工具链，系统本身并不会因此变得更聪明。Jason Wei 的提醒，本质上是说清楚了这个分岔口——选择捷径不是错，但要清楚自己在选什么。
还有一点值得强调：这条帖子对「模型能力评估」也提出了隐含要求。如果一个团队要用「1B 认知核心」路线，那么它必须能准确回答「这个核心到底会不会做这件事」。而判断这一点的方法，不是看它在 demo 里跑通了几个案例，而是看它在没有工具辅助时、面对原始输入能做到什么程度——那个数字才是这个核心的真实水平。把「有工具时的表现」当「核心的能力」，是这条路线最容易犯的评估错误。