Andrej Karpathy在红杉的炉边谈话指出，LLM的价值远超提速——它能实现图像到图像的端到端处理、用自然语言替代脚本安装、构建传统代码无法处理的知识库。但Agent在生产中的循环问题暴露了框架之外的根本挑战，这与CVE制度对AI漏洞的失效形成共振，揭示出新范式需要的不是旧规则，而是全新的治理逻辑。

核心观点：LLM的真正革命不是加速已有任务，而是开创了全新功能范式，但代理经济学的核心挑战在于如何管理‘锯齿状’能力分布与避免循环陷阱。

当我们谈论大语言模型（LLM）的能力时，最常见的叙事莫过于“加速”——它能让程序员写代码更快，让内容创作者更高效，甚至让企业级软件部署周期缩短数周。这种叙事并非错误，但它严重低估了LLM真正带来的范式转变。Andrej Karpathy在红杉资本2026年炉边谈话中的发言，为我们撕开了一个更清醒的视角：LLM的深刻之处，不在于它能让旧有事物运转得更快，而在于它让某些东西从根本上是“新”的，甚至是一度被认为“不可能”的。

Karpathy列举的三个例子堪称精妙。第一个是menugen——一个完全由LLM“吞噬”的App，从输入图像到输出图像，全程无需一行经典代码。这不是传统意义上的“代码生成”或“低代码平台”，而是一种计算范式的彻底交替：模型直接处理像素到像素的映射，绕过了一切符号逻辑。第二个例子是“install.md技能替代install.sh脚本”。想象一下，你不再需要为不同操作系统编写复杂、易错的Bash脚本，而是写一份自然语言说明文档，交给LLM去理解并执行。这种转变意味着软件安装从“确定性执行”进入了“智能解读”阶段——LLM可以在上下文中调试、适应你的环境、甚至处理意料之外的错误栈。第三个例子是LLM知识库，它能够对任意格式、任意来源的非结构化数据进行计算——这在经典软件工程中是不可实现的，因为它要求对“含义”而非“结构”进行操作。

这些例子的共同点在于：它们不是在改进已有的做事方式，而是在定义全新的事。把这三点结合起来，我们能看到一个关于LLM真正潜力的核心命题：它正在从“工具”变为“环境”。传统软件环境由操作系统、高级语言编译器、硬件架构组成，而LLM提供的是一个以自然语言为交互界面、以模型权重为执行引擎的“语义计算环境”。在这个环境中，“编程”不再是写代码，而是写意图。

然而，这个新环境并不完美，它存在一个致命的“锯齿状”特征。Karpathy毫不回避地指出，同一个模型既能重构十万行代码库，也可能建议你“步行去洗车”。这种能力分布的不均匀性，根源在于两个因素：领域的可验证性和经济性。

可验证性指的是某些任务（如数学证明、代码编译）天然有明确的对错标准，模型在这些领域经过强化学习（RL）训练后，表现可以接近“飞行状态”。而其他领域（如常识推理、文化判断）则缺乏这种刚性反馈，模型在此处只能像“在丛林中用砍刀辟路”一样挣扎。

经济性则是更隐蔽的决定因素。模型在RL过程中，训练数据的分布并非均匀覆盖所有人类知识，而是由商业价值驱动。那些有巨大潜在市场、有明确商业回报的领域（如代码生成、客服系统、金融分析）会获得更密集的“轨道铺设”，从而让模型在此类任务上表现优异。相反，那些利基、小众或难以货币化的领域，则会被边缘化。这带来的结果是一个能力极不均匀的智能体：它在某些方面是专家，在另一些方面是盲人。

这种“锯齿状”能力分布，直接影响了AI代理（Agent）在生产环境中的表现。近期Reddit上一位运营了30个Agent超过6个月的用户总结出一个残酷的经验：框架选择（LangChain、CrewAI、AutoGen等）几乎不是决定性因素。真正杀死Agent的是循环——它不断调用同一个工具，反复执行同一个错误路径，直到资源耗尽或产生灾难性后果。这与Karpathy所指出的“从软件1.0到3.0的范式转换”一脉相承：传统软件通过明确的逻辑控制流避免循环，而Agent依赖模型的概率判断，这种判断在缺乏人类监督的闭环中极易退化。

循环问题的根源，恰恰在于LLM的锯齿状能力。当Agent进入一个高可验证性领域时，它运行顺畅；一旦遇到低反馈、低经济价值的边缘情况，它就像迷路的小孩。框架无法解决这个问题，因为它不涉及数据的分布或RL的训练策略。真正的解决方案，或许在于重新思考Agent的架构：引入更明确的状态机来约束探索范围，或者通过混合系统（即经典控制逻辑与LLM判断交替）来划清“轨道内”与“丛林”的边界。

与此同时，AI安全领域的漏洞识别机制也在面临类似的范式冲突。传统的CVE（公共漏洞和暴露）系统，是为软件缺陷（如缓冲区溢出、SQL注入）设计的，漏洞编号仅标识具体实例，不提供攻击类、风险评分或修复建议。但AI Agent的安全问题具有本质不同：攻击可能发生在自然语言提示词中，体现在模型输出的隐含偏见里，甚至存在于知识检索时的上下文污染中。CVE的编号体系无法描述这些威胁的类与模式。

有研究者提出了AVE（AI漏洞枚举）的概念，试图为AI系统建立专门的漏洞分类和评分体系。这正是对Karpathy所言“经济性决定RL数据分布”的某种逆向证明：当Agent安全成为一个有商业价值的市场时，相关的标准化工作才会被推进。否则，漏洞管理只能停留在研究论文的层面，无法进入工程实践。

但反方观点同样有力。有人会质疑：我们是否在过分夸大LLM的“新”？毕竟，无论是menugen还是install.md，在本质上都可以被理解为“自动化”的某种高级形式。循环问题也不仅仅是Agent独有，传统软件中同样存在死锁和无限循环——只是过去我们用更硬的逻辑来控制。这种观点认为，LLM只是软件工程演化中的一个阶段，而非范式断裂。

我认为这种反驳有一定道理，但它忽视了“语义计算”的质变。传统软件的循环基于状态机，是可预测、可调试的；而LLM的循环基于概率分布，其路径依赖于训练数据的微妙偏差，甚至开发者自己也难以完全理解。循环的结果可能不是简单的资源耗尽，而是一个充满偏见、误导性信息的输出，其危害远大于传统死锁。更重要的是，传统软件的安全漏洞通过补丁可修复，而Agent的漏洞可能藏在模型权重里，无法被简单“打补丁”——这恰恰是AVE试图解决的难题。

回到经济学的视角，AI Agent的生产环境面临的核心矛盾是：资本市场和风险投资要求Agent规模化部署，但锯齿状能力分布和循环问题使得规模化充满不确定性。那些成功运营Agent的公司，往往不是选择了最好的框架，而是建立了严格的监控和人工介入机制——在关键决策点引入人类判断，将LLM限制在“轨道内”任务。这种妥协，虽然缓解了循环问题，但也模糊了“自动化”的真正边界。

或许，我们正在目睹一个“智能代理经济学”的雏形：不是所有任务都值得用Agent来执行，只有那些高可验证性、高经济回报、且任务边界清晰的领域，才是Agent的最佳落点。而其他领域，仍需要人类与机器的混合模式。这一认识，比任何框架选择都更重要——它不仅关乎技术选型，更关乎我们对“智能”本身的假设。

当Karpathy说“我们仍然在建立一个准确的LLM能力模型”时，他其实在提醒整个行业：我们还没有完全理解自己创造的东西。在这个“锯齿状”的智能景观中，真正的前沿不是技术本身，而是我们如何管理与这种不均匀性共存的方式——包括接受它偶尔的愚蠢，警惕它隐藏的偏见，以及设计出适应这种模糊性的治理体系。

这或许是LLM时代最深刻的教训：新范式需要的不仅是新技术，更是新规则、新经济学、以及新的人机分工哲学。而那些试图用旧规则来套用新工具的人，最终只会被循环吞噬。