我在推广Agentic AI的时候经常被问到：“为什么你的所有教程里从来没有看到对Autogen、LangGraph、SmolAgents或者<插入任何流行的Agentic AI框架>的介绍？” 或者“我应该学习哪个框架来入门Agentic AI？” 这篇文章想解释一下为什么我觉得在这个Agentic AI飞速发展的特殊时期，用什么框架并不重要，我们甚至应该避免从框架开始入门Agentic AI。 ## 为什么我们需要技术框架/库 在具体讨论这个问题之前，我们先要理解在其他软件工程领域为什么需要一个框架（framework）或者库（library）。这里面主要有三个层面的好处： 最基本、最底层的好处是，它提供的库函数可以省很多事。举个例子，C语言的数学库提供了开平方根的函数`sqrt`。对于这种基本功能，我们就不用自己再去实现一个牛顿迭代法了。 当我们可以用库函数实现越来越高层的功能时，框架的第二个好处就显现出来了：提供适当的抽象。这可以让我们从更符合人类直觉和商业逻辑的角度进行思考。举个例子，很多GUI的库提供了对话框这个类。我们在用这个类写代码的时候就不用费心思考，这个对话框内在的消息泵是怎么处理的，操作系统是如何对不同的按钮进行重绘的，而可以集中精力在商业逻辑上面——我在这个位置放置这个按钮，用户点击了那个下拉列表后需要展示什么内容。这样从更抽象的角度进行思考，就可以增加我们思考的效率，也让开发更不容易出错。 在此基础上，它的第三个更加抽象和高层的好处是，框架往往可以引入一种思维方式，一种设计哲学，鼓励和引导我们使用领域里面的最佳实践。如果你用XCode写过ObjectiveC/Swift程序的话，就会发现它的默认模板是按照MVC这种设计模式进行配置的。这里并不是强令开发者就一定要使用这种设计模式，但是通过把比如iOS app的工程初始化成这种形式，苹果引导了初学者使用MVC这种在工程实践上被证明非常有效的模式进行思考，从而保证他们的程序的下限不会太低。程序写出来之后易于维护，也方便理解。 这三个好处是相互递进的，甚至可以对应着使用框架的三种不同的方法或者境界。当我们只是把某个框架当作是一套基本的库函数来使用的时候，我们可以实现最大的灵活度——因为我们不用局限于框架特定的思维方式和设计模式。但相应的，我们得到的益处也最少。更高层的应用方式在带来更多好处的同时也会带来枷锁——我们必须要用这个框架的作者同样的视角来看待整个项目。比如说，如果你特别讨厌MVC这个设计模式，那使用XCode的默认模板来写Swift程序就一定会很痛苦，除非你把整个项目框架全部删除，改用自己的设计模式。但在这种情况下，它就从第三种境界退化到了第二种境界。 ## 框架的技术选型意味着什么 Agentic AI 这个领域特殊的地方在于，它实在是太新了，所以大家对它有很多种不同的视角。而当你决定选用一个框架，也就意味着我们对 Agentic AI 的视角基本上就被锁死在这个框架里面了。比如： - AutoGen 的基本思想是LLM 包办所有事，通过很多 agent 之间基于消息的异步协作来完成特别复杂的任务。 - LangGraph 的基本思想是Agentic Workflow可以用一个图来表述。为了解决图的结构是静态的问题，它引入了条件连接，持久层，事件，异步等等更复杂的元素。 - SmolAgents 的基本思想或者假设是，我们调用 agent 的方式不应该是工具调用，而应该把 code 当作中间的媒介，因为它更明确具体。 你可以看到，这些工具都不是一坨库函数就完了，而是都有非常鲜明/重量级的设计哲学，甚至可以称作“世界观”。这对我们开发Agentic AI会带来巨大的好处和限制。如果你理解并且赞同他们的深度视角，开发起来就会如鱼得水。但如果你随着经验的积累或者领域的发展，逐渐发展出了跟他们不同的观点，继续使用这些框架就会非常痛苦。而另一方面，想回头也会特别困难。想象一下从SmolAgents迁移到LangGraph的工作量会有多大——从一个框架迁移到另一个基本思想完全不兼容的框架往往会非常复杂，甚至还不如从头写一个。 从更长远的角度来说，对现在这些Agentic AI框架的技术选型不仅仅是选择一个框架本身，而是选择它们预设的世界观。考虑到Agentic AI正在飞速发展，一个革命性的认知跃变随时可能发生，这个世界观的选择甚至关系到我们能不能在未来的认知革命中及时响应。而这种Agentic AI框架的百花齐放恰恰说明了我们对它的理解还处在盲人摸象的阶段。因此这种世界观是不完整甚至错误的概率极大——看看AutoGen从v0.3到v0.4做了多大更改（基本重写了）就知道。这种情况下过早站队不仅会引入一个不定时催收的技术债，而且也会影响我们对领域的全面理解。 上面主要是从机会成本的角度进行分析，而从收益的角度来看，使用框架也不会带来太多的好处。这主要因为Agentic AI本身刚刚起步，所以整个系统并不复杂。我们在之前的文章中也说过，Agentic AI无非是可以调用工具的LLM + 工具协议 + 多轮迭代的orchestrator，基本上五分钟之内就可以做出一个原型。因此，这些框架能让我们省的事也不是很多。所以对于刚入门Agentic AI这个领域的初学者来说，我们并不建议从框架出发来进行学习，而是可以从最基本的概念出发，在Agentic AI编程工具（比如Cursor）的帮助下，一步步构建自己的系统。这个其实并不会比基于已有框架构建要慢多少，甚至可能成效会更快。 ## 更细节的陷阱 如果你真的用过这些Agentic AI的框架构建过一些App的话，也会发现里面有一些更加细节的坑。 第一是，这些库虽然很多都声称自己low-level、轻量级，但是因为他们用的设计模式比较高层，要想做出能跑的App还是需要学习很多的前置知识。比如LangGraph里面，光是怎么用代码定义一个图，让这个图可以通过编译，本身就是一个不简单的问题。在SmolAgents里面，我们如果想要使用一个自定义的tool，也需要去学习它的具体接口。踩很多坑，才能写出一个正确的不中途崩溃的程序。换言之，使用这些框架其实并不能帮助我们快速地写出一个能用的系统。这和我们最直观的期待其实是有点背道而驰的。 一个自然的问题就是，那为什么我们不用Agentic AI来解决这个问题？毕竟用Agentic AI的库还需要人自己来写代码，这本身就是一件特别奇怪的事情。但是反直觉的是，无论是AutoGen、LangGraph还是SmolAgents，这些流行的Agentic AI框架都没有提供针对AI的prompt文档。换言之，目前还没有一个流行的框架提供了AI-native，甚至哪怕AI-friendly的方法来让Cursor之类的工具利用这些框架快速自主地写出可以运行的代码。这也是我对这些库比较失望的原因。 而第二个坑则是，这些库往往都有过度抽象（over-abstraction）的倾向。LangGraph的非Agentic版本是LangChain。LangChain在这方面臭名昭著。如果你只是想跑一个最简单的toy demo还没有问题，只要用它现成的类就可以直接跑出来。但凡你要对接任何已有接口（比如在企业里落地），做任何自定义的东西，就不可避免地要去给它一些自定义的类，或者改它的内部实现。但这就是噩梦开始的地方。你会发现下面要做的事情是不停地跟进内部类的定义，跳转八百层抽象类接口之后，才会找到需要改的地方。然后在这个基础上逐层改代码，或者把你的实现传进去，才能够实现自定义。 这其实是高速发展领域的框架的典型failure pattern。MVC模式在iOS开发中为什么这么有效，是因为GUI的基本思想和模式经过几十年的发展，已经基本定型了。现在Agentic AI的底层概念都还没有沉淀下来，任何中高度的抽象都注定是脆弱的。换言之，这些过度抽象的框架用架构师的假设替代了构建者（Builder）的直觉，这不仅不是有效的解决方案，反而是问题本身。这很容易造成一种境地是为了跟更多的已有系统对接，开始补丁摞补丁，最后变成屎上雕花干脆全部推倒重写。 ## 小结 所以总的来说，现有的Agentic AI框架往往把技术路线绑定在了一种鲜明的世界观上。在一个领域高速发展的黎明时期，这样的绑定带来的好处有限，但会给我们当下接入已有系统或者未来调头都带来相当大的技术风险。这就是为什么我们从来不介绍具体的Agentic AI框架的原因。而且我们也不建议初学者从已有的流行的框架入手来学习Agentic AI。它们鲜明的世界观会影响我们做出自主的属于自己的判断。我们还是应该回归Builder’s Mindset，从第一性原理出发，先把最基本的概念理解透彻，然后根据自己的特定的需求来灵活实现自己的系统。 不过要注意一点，这只是一个暂时现象。在未来，Agentic AI 的各个组件一定会尘埃落定，收敛出类似Web标准一样的通用接口，那时候的标准框架/库就又有很高的参考和学习价值了。