从开发者社群对LangChain的抱怨到Sequoia的创业者对话，一种反框架的浪潮正在兴起。这不仅是技术偏好之争，更揭示了当前AI Agent生态中一个被忽视的真相：框架的复杂化正在扼杀创新，而简单的手写循环可能才是通往实用Agent的最快路径。

核心观点：在AI Agent开发中，过度依赖框架反而会降低效率，真正的突破在于理解何时该抛弃框架，回归手写代码的简单与可控。

在AI Agent的开发世界里，一个看似矛盾的景象正在悄然上演：一方面，各大科技公司和创业团队争相推出越来越复杂的Agent框架，试图将多步骤推理、工具调用、记忆管理等能力打包成开箱即用的解决方案；另一方面，越来越多的一线开发者开始在reddit、技术博客乃至闭门会议上公开质疑——这些框架真的在帮助我们，还是在拖慢我们？

这个问题并非空穴来风。一位自称被LangChain“吃掉了整整一周调试时间”的开发者，在reddit上发出了灵魂拷问：“Agent框架到底在多大程度上是帮助，多大程度上是拖累？”他描述了自己的经历：在放弃框架、手写Agent循环两个月后，虽然需要编写更多胶水代码，但调试链路变得清晰，发布周期也显著加快。这条帖子迅速获得了大量共鸣，评论区充满了类似的故事——有人抱怨框架的抽象层过于厚重，导致性能下降；有人指出框架的文档总是落后于实际开发需求；更有人直言，对于大多数任务来说，框架带来的复杂度远远超过了其价值。

这种不满不是孤立现象。就在不久前，Andrej Karpathy在Sequoia Ascent 2026炉边谈话中，虽然没有直接批评框架，但提出了一个更根本的视角：LLM的能力远不止于加速已有流程，它们正在开启全新可能性，比如完全由LLM驱动的应用、以.md文件取代.sh脚本的安装方式，以及从任意来源任意格式的非结构化数据中进行知识计算。这些新地平线的实现，恰恰需要对底层机制有深刻理解，而不是被框架的抽象层蒙蔽双眼。Karpathy的谈话中隐含着一个关键判断：当开发者过度依赖框架时，他们就失去了对模型能力边界（即所谓的“锯齿状模式”）的直观感知，而这正是做出明智技术决策的前提。

那么，问题来了：Agent框架的价值边界到底在哪里？一位来自生物学和软件工程双重背景的开发者提出了一个耐人寻味的视角。他认为，对Agent记忆和项目连续性的理解，不能脱离生物学中关于记忆形成的隐喻。在他的设想中，一个理想的编码Agent不应该在每个新会话中忘记之前的工作，而是能够像人类一样，在第二天早上被问“我们上周二做了什么？”时，给出一个连贯的总结，并在此基础上继续工作。但这样的功能，是通过框架提供的黑盒记忆模块来实现，还是通过开发者自己设计的、可定制可审计的记忆系统来实现？他的答案是后者。

这种观点与Karpathy提到的“锯齿状模型”不谋而合。Karpathy指出，LLM的能力分布是不均匀的——它可以在同一件作品中完美重构一个10万行代码的代码库，同时建议你“走到洗车店去洗车”。这种不一致性源于训练数据分布中的经济因素：那些有明确市场价值的领域（如代码生成）在强化学习中被重点打包，而偏离这些领域的任务则表现糟糕。一个优秀的Agent开发者，必须对这种锯齿状有清醒的认知，而不是指望框架能自动避开所有陷阱。而当开发者使用框架时，框架的抽象层往往掩盖了这种锯齿状，导致他在任务复杂度超出框架预设范围时，遭遇无法理解的失败。

这引出了一个更激进的观点：或许，对于绝大多数实际应用来说，我们根本不需要框架。那位手写Agent循环的开发者给出了一个经验性的判断标准：当任务复杂度低于“带记忆的多步检索”时，没有框架反而更轻松；当任务高于这一复杂度时，他承认自己还没有经验。这个判断虽然模糊，却指向了一个核心事实——框架的真正价值可能只存在于极少数高复杂度的场景中，而大多数开发者正在为这些用不上的功能付出代价。

反对者会争辩说，框架的意义在于提供标准化的最佳实践，降低团队协作的沟通成本，并为新入行的开发者提供一条学习曲线。这当然有道理。但现实是，Agent开发领域还远未成熟到可以形成“最佳实践”的程度。每个团队、每个任务、每个模型版本都可能需要完全不同的架构。在这种环境下，框架更像是提前施加的约束，而不是解放生产力的工具。那位生物学背景的开发者甚至认为，当前框架的困境与早期生物信息学软件包的问题如出一辙：它们试图在一个快速演变的领域内建立通用标准，最终却被现实超越。

另一个值得注意的信号来自资本市场。近期AI内存和存储类股票的突然暴涨，揭示了AI基础设施的瓶颈正在从计算转向存储和带宽。美光的HBM供应已经售罄，数据中心对NAND闪存和SSD的需求正在指数级增长。这意味着，Agent应用的实际性能瓶颈可能很快就不再是模型本身的推理能力，而是数据流的吞吐量和记忆系统的效率。如果框架在这些底层I/O操作上做了额外的抽象和缓存，反而可能成为性能的拖累。

那么，解决方案是什么？或许不是简单地否定所有框架，而是建立一种更务实的评估标准：在引入框架之前，先问自己三个问题——我真的需要框架提供的所有功能吗？这些功能中有多少是我会实际用到的？如果框架今天消失，我的开发流程会受到多大影响？如果答案不令人满意，那么手写循环可能才是更明智的选择。

Karpathy在谈话最后提到了“Agent原生经济”的概念，即产品和服务被分解为传感器、执行器和逻辑，并跨越1.0/2.0/3.0计算范式分布。在这个愿景中，Agent工程师的核心技能不是熟悉某个特定的框架，而是能够理解整个堆栈，从模型行为到数据流再到系统架构。这需要一种更底层、更灵活的工作方式，而这恰恰是过度依赖框架的工程师所缺乏的。

当前Agent框架的狂热，让我想起了早期的Web框架之战——Rails、Django、Spring，它们都曾宣称是“终极解决方案”，但最终，每个成功的团队都学会了根据自己的需求选择和裁剪。在Agent的世界里，这个教训可能来得更快、更猛烈。因为Web开发的环境相对稳定，而Agent开发的环境——模型的版本、能力、成本——都在以周为单位变化。在这种流动性中，任何固化最佳实践的尝试都可能迅速过时。

最终，也许Agent框架的真正价值不在于它提供了什么，而在于它让我们重新思考：在AI开发中，什么时候复杂是必要的，什么时候简单才是真正的力量？那位开发者的经历给出了一个生动的答案：在被框架折磨了一周后，他选择了一切从零开始，然后发现自己实际上可以走得更快。这不是反智主义，而是对工具本质的清醒认识——当工具本身变成问题，使用工具的勇气就在于放下它。