LLM的锯齿能力图谱:为什么AI既会重构代码又让你去洗车,以及这对Agent原生经济意味着什么
Karpathy在Sequoia Ascent 2026炉边谈话中提出了一个核心问题:为什么同一个AI模型能重构十万行代码,却告诉你应该走路去洗车?这个看似矛盾的现象背后,揭示了LLM能力图谱的锯齿本质,它正在从根本上重新定义我们构建软件、评估安全和设计产品的逻辑。
核心观点:LLM的能力分布并非均匀,而是呈现高度不规则(jagged)的图谱,理解这种不规则性是构建真正可靠、强大的AI原生应用和Agent经济的前提,而传统的软件工程思维和漏洞评估体系(如CVE)已无法适用于这个新范式。
人工智能的发展在2026年进入了一个奇特的阶段。一方面,大语言模型展现出了令人瞠目的能力——它们可以连贯地重构一个十万行代码库,能够根据一张图片生成另一张图片,甚至能够完全替代传统软件中的经典代码逻辑。但另一方面,同一个模型会给出荒谬的建议,比如让你走路去洗车,或者在面对一个需要多步推理的简单问题时表现得像个逻辑混乱的小学生。这种能力上的极端不均衡,被Andrej Karpathy精辟地概括为LLM的“锯齿能力图谱”(jagged pattern)。我们正在经历的,不是一个“AI什么都能做”的时代,而是一个“AI在某些事情上做得极好,在其他事情上却完全不可靠”的时代。理解并接受这种不规则性,是当前所有AI从业者面临的最本质挑战。
Karpathy在红杉资本的炉边谈话中提出,LLM的意义远不止是加速已有的工作流,比如更快的编程。真正的变革在于,LLM使得某些此前不可能存在或完全没有必要存在的应用成为现实。他举了三个例子:menugen,一个完全不需要传统代码、仅靠LLM就能实现“输入图像、输出图像”的应用;用“.md技能”替代“.sh脚本”,比如安装软件时不再需要编写复杂的Bash脚本,而是用自然语言写一份安装说明,让LLM作为高级的英文解释器去智能地执行;以及基于LLM的知识库,它能够对来自任意来源的非结构化数据进行计算,这在经典软件范式下几乎是不可能的。这些例子共同指向一个事实:我们正在从“软件1.0”(经典代码)和“软件2.0”(神经网络)的时代,迈向一个“软件3.0”的混合时代,其中LLM既是核心引擎,也是交互界面。
然而,当我们试图大规模应用这些能力时,锯齿图谱成了最大的障碍。为什么同一个模型能完成如此复杂的任务,却在另一个看似更简单的任务上失败?Karpathy给出的解释触及了问题的核心:这与领域的“可验证性”有关,但更重要的是,它与“经济学”有关。前沿实验室在强化学习阶段,会根据营收和潜在市场规模(TAM)来决定将哪些数据和任务打包进训练分布。因此,当一个任务落在强化学习回路的数据分布内时,模型就像在轨道上飞驰的列车,表现惊人;而一旦脱离这个分布,模型就像在丛林中挥舞砍刀开路,效率急剧下降。这个解释虽然仍不能让人百分之百满意,但它提供了一个极其实用的心智模型。它意味着,我们不能简单地将LLM视为一个统一的智能体,而必须像测绘地图一样,为每个模型绘制出它能力分布的“高地和洼地”。
这种能力的不规则性,直接催生了技术社区的两种截然不同的反应。一种反应是继续沿用旧有的安全评估体系,试图用“CVE”和“CVE编号”来分类和追踪AI Agent的漏洞。然而,正如网络安全社区最近的一篇文章所尖锐指出的,CVE系统是为传统软件漏洞——如缓冲区溢出、SQL注入和内存损坏——而设计的。当攻击对象是一个MCP(Model Context Protocol)工具,其风险涉及“在技能文件中如何检测”或“修复措施是什么”时,一个孤立的CVE编号变得毫无意义。你无法从“CVE-2025-49596”这个编号中读出攻击类别、AI风险评分或检测方法。这些关键信息散落在PDF、博客文章或研究者的GitHub仓库中。CVE框架对AI Agent的失语,正是我们旧有软件思维与新兴现实脱节的又一例证。
而另一种反应,则更具有前瞻性:以开源社区为代表,它们正在构建真正适应Agent世界的工具和思维。例如,Mercury Agent这样的开源项目,它的价值不在于又一个“聊天机器人”,而在于它定义了一个新的工作范式——它是一个私人操作员,能记住上下文,在风险操作前询问,能执行周期性工作,并留下操作记录。这些特性恰恰是对锯齿图谱的回应:正因为我们知道模型可能在哪些方面犯错,所以我们必须在系统架构层面嵌入护栏、审计和验证机制。这不再是“找出bug然后修复”的逻辑,而是“在知道模型会随机犯错的前提下,设计一个容错系统”的逻辑。
从更宏观的角度看,这种锯齿图谱正在催生一个我们称之为“Agent原生经济”的价值体系。Karpathy在谈话中描绘了这幅图景:产品和服务被解构为传感器、执行器和逻辑,而这些组件分布在不同代际的计算范式(1.0、2.0、3.0)中。一个成功的AI原生产品,其核心竞争力不再是单一模型的强大,而是团队对模型锯齿图谱的深刻理解,以及基于此理解而设计的系统架构。它要求开发者知道何时依赖LLM的“轨道上”能力,何时需要引入经典代码作为“应急方案”,以及如何让信息对LLM“最大程度地可读”。
这当然也引来了反方的质疑。乐观主义者可能会认为,随着模型的迭代,能力分布会越来越均匀,锯齿会逐渐被填平。然而,从近两年的实践来看,情况恰恰相反。随着模型能力的增强,其能力分布的“高地和洼地”变得更加陡峭和难以预测。我们看到的不是能力的平均化,而是能力的极端化。一个在数学竞赛中得满分的模型,可能依然无法正确理解一个简单的物理常识。另一个担忧是,过度强调“能力图谱”可能导致对模型的过拟合——我们不是在构建通用的智能,而是在构建一个针对特定“测试集”上的超级专家。这种“应试教育”式的AI发展路径,最终可能会限制其真正的通用性和创造力。
尽管如此,一个不可逆转的事实是,我们正在集体涌入这个新范式。那些试图用旧地图(如CVE)来航行新海域的人,注定会触礁。而那些开始绘制新地图——理解LLM能力的不规则性,并以此为基础设计系统、产品和经济模型——的人,将会定义下一个十年。对于开发者、创业者和政策制定者来说,第一课不是“如何让AI变强”,而是“如何承认并驾驭AI的脆弱与强大并存的不规则本质”。这不仅仅是技术问题,更是一种新的工程哲学。
参考来源
- Fireside chat at Sequoia Ascent 2026 from a ~week ago. Some highlights:
- The first theme I tried to push on is that LLMs are about a lot more than just speeding up what existed before (e.g. coding). Three examples of new horizons:
- 1. menugen: an app that can be fully engulfed by LLMs, with no classical code needed: input an image, output an image and an LLM can natively do the thing.
- 2. install .md skills instead of install .sh scripts. Why create a complex Software 1.0 bash script for e.g. installing a piece of software if you can write the installation out in words and say "just show this to your LLM". The LLM is an advanced interpreter of English and can intelligently target installation to your setup, debug everything inline, etc.
- 3. LLM knowledge bases as an example of something that was *impossible* with classical code because it's computation over unstructured data (knowledge) from arbitrary sources and in arbitrary formats, including simply text articles etc.
- I pushed on these because in every new paradigm change, the obvious things are always in the realm of speeding up or somehow improving what existed, but here we have examples of functionality that either suddenly perhaps shouldn't even exist (1,2), or was fundamentally not possible before (3).
- The second (ongoing) theme is trying to explain the pattern of jaggedness in LLMs. How it can be true that a single artifact will simultaneously 1) coherently refactor a 100,000-line code base *and* 2) tell you to walk to the car wash to wash your car. I previously wrote about the source of this as having to do with verifiability of a domain, here I expand on this as having to also do with economics because revenue/TAM dictates what the frontier labs choose to package into training data distributions during RL. You're either in the data distribution (on the rails of the RL circuits) and flying or you're off-roading in the jungle with a machete, in relative terms. Still not 100% satisfied with this, but it's an ongoing struggle to build an accurate model of LLM capabilities if you wish to practically take advantage of their power while avoiding their pitfalls, which brings me to...
- Last theme is the agent-native economy. The decomposition of products and services into sensors, actuators and logic (split up across all of 1.0/2.0/3.0 computing paradigms), how we can make information maximally legible to LLMs, some words on the quickly emerging agentic engineering and its skill set, related hiring practices, etc., possibly even hints/dreams of fully neural computing handling the vast majority of computation with some help from (classical) CPU coprocessors. - https://nitter.net/karpathy/status/2049903821095354523#m
- Why CVE Does Not Work for AI Agents, but AVE? - https://www.reddit.com/r/cybersecurity/comments/1tnditb/why_cve_does_not_work_for_ai_agents_but_ave/
- Mercury Agent install note: Mercury open-source agent without the setup-only trap - https://www.reddit.com/r/MercuryInstall/comments/1tmp0q1/mercury_agent_install_note_mercury_opensource/