从Reddit上一位手写Agent循环的开发者吐槽，到Karpathy关于LLM能力'崎岖性'的演讲，再到AI记忆存储股的突然暴涨——我们正站在一个十字路口：Agent框架究竟是必要的抽象，还是新的认知税？

核心观点：当前AI Agent框架泛滥的核心问题，不是技术能力不足，而是它们试图用抽象层解决本应由工程师判断的'何时需要框架'这一决策问题，导致大多数项目在框架中得不偿失。

过去半年，AI Agent框架从一个技术小众话题，迅速膨胀为整个行业的显学。LangChain、AutoGPT、CrewAI、Semantic Kernel……几乎每周都有新框架诞生，声称能让你用几行代码就构建出智能体。但真实情况是什么？Reddit上一位开发者说出了许多人的心声：他在被LangChain连续吞噬多个调试周后，毅然回归手写Agent循环，发现代码量虽然增加了，但追踪路径变得清晰，发布周期反而更快。这句话像一根刺，扎进了AI工程社区最敏感的神经——我们是否在用框架解决框架本身制造的问题？

要理解这个悖论，必须先承认一个或许令框架作者们不悦的事实：Agent框架的效用边界远比想象中狭窄。那位Reddit用户给出了一个经验性判断——在“带记忆的多步检索”以下复杂度，无框架的轻量方案反而更加高效。这不是孤立个案。Karpathy在红杉资本Ascent 2026的炉边谈话中，提出了一个更深刻的理论框架来解释这种现象：LLM的能力呈现一种“崎岖性”（jaggedness）。同一套模型，可以在重构10万行代码库时表现出令人惊叹的连贯性，却同时在“走路去洗车”这样的常识任务上犯低级错误。Karpathy将此归因于两个因素——领域的可验证性，以及更隐秘的经济学力量：收入和市场总量决定了前沿实验室选择将哪些内容打包进RL训练数据分布。当任务落在数据分布之内（即处于RL电路的轨道上），模型表现犹如神助；一旦偏离轨道，它就变成拿着砍刀在丛林里开路的探险家，每一步都可能踩空。

如果Karpathy的分析成立，那么Agent框架的承诺——用一个统一的抽象层来管理这种崎岖性——本质上就是在试图驯服一头尚未被完全理解的野兽。框架作者们假设存在一个通用的“智能体模式”，可以适用于从简单查询到复杂工作流的各类场景。但现实是，当任务复杂度跨越了不同的数据分布区域时，框架要么变得笨重不堪（试图覆盖所有可能的边缘情况），要么过于脆弱（只优化了少数路径）。那位Reddit用户的经历就是最好的例证：他之所以能通过手写循环获得更好的体验，恰恰因为他可以针对特定任务的“数据分布”进行精确优化，而无需承受框架为通用性付出的性能税。

但问题不止于此。Agent框架的流行反映了一个更深层的行业焦虑：我们急于找到“下一个大东西”的终极形态，以至于忽略了工程实践中那些缓慢而扎实的积累。Karpathy的演讲中提到了一个耐人寻重的概念——“Agent原生经济”（agent-native economy）。他预测产品和服务将被分解为传感器、执行器和逻辑三层，分布在1.0（经典计算）、2.0（神经网络）和3.0（智能体）三种计算范式之间。这个愿景当然宏大，但它隐含了一个前提：我们需要先搞清楚每层应该做什么，而不是盲目地让Agent框架去接管一切。现实是，许多团队在连“如何让LLM可靠地调用一个API”这样的基础问题都没解决的情况下，就匆忙引入框架来管理多Agent协作。结果正如那位Reddit用户所言——调试周被吞噬，追踪路径混乱，发布周期反而变慢。

这让我想起了软件工程历史上一个经典教训：抽象层的诅咒。每一次技术范式转移，都会催生一批试图“简化复杂性”的框架。OO时代的EJB，Web 2.0时代的各种MVC框架，移动时代的跨平台工具……它们无一例外地承诺让开发者更高效，但最终都留下了大量“框架债务”——你学会了框架的抽象，却失去了对底层逻辑的理解。当框架遇到你的特定场景时，你不得不在框架的迂回和手写的直接之间做出痛苦抉择。今天的Agent框架正在重蹈覆辙。它们试图用“智能体”、“记忆”、“工具使用”这些宏大的概念来掩盖一个尚未解决的问题：我们仍然没有一套成熟的理论来描述LLM的崎岖性，更不用说用框架来驯服它。

那么，Agent框架究竟有没有价值？答案是有，但必须在正确的场景中使用。那位Reddit用户自己也承认，在“多步检索带记忆”之上，他还没有实验过，不确定框架是否更有优势。这恰恰说明了问题的关键——我们需要一个清晰的“复杂度断点”，而不是笼统地假设框架总是更好。Karpathy的演讲中提到的三个例子——menugen（完全由LLM原生处理的图像应用）、.md技能安装（替代bash脚本的文本描述安装）、LLM知识库（经典代码无法实现的无结构数据计算）——展示了LLM真正闪光的地方：那些要么在经典范式下完全不可能实现、要么本就不需要复杂软件的任务。在这些场景中，Agent框架可能确实有意义，因为任务本身就处于LLM能力的数据分布之内。但当任务涉及到与外部系统的复杂交互、状态管理、错误恢复等经典软件工程问题，框架的效用就会急剧下降。

另一个被忽视的问题是在工程文化层面。Reddit上那位开发者的故事，实际上是无数AI工程师正在经历的文化冲突。一方面，开源社区和资本都在狂热地推动“Agent原生”叙事，声称不采用框架就会落后于时代。另一方面，一线工程师在每天的实际工作中反复碰壁，发现框架不仅没有提升效率，反而引入了新的复杂性。这种张力在AI记忆存储股的突然暴涨中得到了某种隐喻式的回应——当市场意识到AI训练和推理正在遭遇“内存瓶颈”时，人们开始关注基础设施，而不是上层框架。Micron的HBM供应在2026年已售罄，AI数据中心预计将消耗大部分NAND闪存和SSD产能——这些信号告诉我们，真正的瓶颈不在框架层，而在算力和存储的物理极限。如果连底层硬件都难以满足需求，一个抽象框架又如何能凭空创造出效率？

这并不是要全盘否定Agent框架的努力。正如Karpathy所言，我们正在进入一个“Agent原生经济”的早期阶段，产品和服务正在被重新分解。但在这个转型期，最重要的不是追逐最热门的框架，而是培养一种判断力——知道什么时候该用框架，什么时候该手写。那些在框架和手写之间来回切换的工程师，或许比那些忠诚于单一框架的人更具优势，因为他们对LLM的崎岖性有更直接的理解。那位Reddit用户说他的手写循环“trace is sane and ship cycle is faster”，这不是因为手写本身更好，而是因为他对自己的任务复杂度有清晰的认知，并且选择了最适合的工具。

归根结底，Agent框架的流行揭示了一个更广泛的行业现象：我们总是倾向于用工具替代判断力。但AI工程的现实是，在LLM能力的崎岖性没有被完全理解之前，任何声称能“一键构建智能体”的框架都可能是幻觉。真正的进步来自于那些愿意花时间理解LLM能力边界、并在框架和手写之间做出明智选择的工程师，而不是那些盲目拥抱最新抽象层的人。正如Karpathy所说，构建LLM能力的准确模型是实际利用其力量并避免陷阱的关键。而这个模型，不是任何框架能替你建立的。