AI编排框架为何逐渐淡出视野?

在当前的AI发展历程中，新技术的迭代速度之快，让人应接不暇——“还没开始学习，就已经过时了”。今天我们就来探讨一下——

agent编排框架是如何逐渐被遗忘的。

其实这并不是很久以前的事情，在2024年，多智能体编排框架曾是技术圈的热门话题。LangChain+LangGraph、CrewAI、MetaGPT等名字一度被视为AI协同工作的最佳选择。

按照当时的设想，只需一句话，一个由AI产品经理、架构师、程序员和测试员组成的虚拟团队就能自动运行，生成完整的软件项目。

这种“多智能体协作”的愿景几乎代表了人们对AI应用形态的最高期待。尽管当时对agent的定义尚不统一，但人人都在谈论它，却没人敢说自己真正见过AIagent。

然而，随着2025年上半年AI coding agent的兴起，尤其是cursoragentmode和claude code展现出的自主设计、开发和调试能力，人们不禁感叹——

“哇~这才是真正的agent啊~”

同时，人们也意识到一个问题：

“如果claude code这样的表现才叫agent，那LangChain、CrewAI这些编排框架，编排的是什么？”

从LangChain到claudecode，期间究竟发生了什么变化？

答案其实很简单。那些曾经备受期待的框架，本质上还是用APP时代的思维去约束AI。

它们将大模型视为“API工人”，用软件工程、微服务和工作流引擎的逻辑去定义角色、拆解任务和规定步骤。

LinkedIn用LangGraph做的多智能体招聘系统，Trellix的安全日志分析，CrewAI的“研究团队”Demo，MetaGPT的“一句话生成项目”——这些案例虽然听起来很酷，但大多数都停留在“demo”阶段，难以规模化应用。

造成这种情况的原因在于，agent编排框架对模型能力和上下文窗口有极高的依赖。

当你好不容易用一版prompt组合打造了一个可用的工作流，一旦换了模型或云端服务降级，就会导致意图偏离、上下文丢失和产生幻觉，最终输出结果的质量无法保证。

此外，agent编排框架对token的消耗巨大，且执行过程的可观测性和可审计性不足，这使得在企业应用场景中很难落地。

2025年初，主流基模的上下文窗口能力显著提升，deepseek的推理成本也大幅降低。

当时使用agent编排框架的真实体验可能是：

基于LangAgent搞cosplay，用LangGraph控制状态流转，让agent模拟各种人设协同工作，跑一份行业报告，看起来“研究员+分析师+写手”各司其职，基于happypath的demo效果惊艳。

但实际上，prompt需要长时间联调才能输出可用结果，调试过程如同玄学炼丹；稍微复杂一点的任务就容易陷入无限聊天、无法得出结果。

2024年的认知，部分已被证伪或不再有效

再者，agent编排框架对模型选型要求很高。

例如，使用MetaGPT框架模拟一个软件研发组织，如果背后的模型没有针对代码生成进行专项增强，自动生成的代码可能语法错误、逻辑不通，人工调试bug的时间比自己编写还多。

2025年上半年AI coding agent的爆发，恰恰证明了这一点。当拥有足够强大的AIagent时，它可以直接理解你的意图、自主规划步骤、调用工具和迭代调试——

你不再需要先找“产品经理Agent”写PRD，再交给“架构师Agent”设计，再转给“程序员Agent”写代码。一个足够聪明的大语言模型本身就具备足够的意图识别、推理和思维链追溯能力，在其上下文窗口内就能完成所有工作，而且更快、更自然、更少出错。

前agent时代人们对agent工作模式的理解

更重要的是，AI coding agent兴起后，开发一个多智能体编排框架已经没有任何门槛。你可以用自然语言让AI帮你写一个CrewAI的克隆版，甚至比原版更贴合需求。

当“造轮子”的成本趋近于零，这类框架就不再具有稀缺性。古法编程时代，应用开发框架的价值在于封装复杂度和提供标准化方案；现在，AI本身就是那个“能随时为你定制框架”的超级能力。

于是agent编排框架迅速归于沉寂，从“主流创新”变成了少数坚持开发独立agent的小众技术栈。

这反映了APP时代与AI时代对智能体编排框架认知的差异

当模型不够智能时，我们需要框架来兜底；但当模型足够智能后，框架反而成了束缚手脚的枷锁。

cursor是一个有利于AI agent工作的生态系统

在古法编程时代，开发能力是稀缺资源，掌握一个应用开发框架意味着掌握一套成熟的生产力方法论。但在AI时代，框架变成了“可随时生成的中间产物”，其价值被大幅稀释。

可以笃定地说：基于应用思维的应用框架，未来可能不会再有古法编程时代的那种辉煌了。

那么在AI时代，一个AI-native的编排框架应该是什么样子？

我们不妨对比一下：

Agent编排框架（app应用思路）

固定角色分工

明确的任务拆解 & 顺序执行

明确的功能边界 & 交互协议

强制消息传递 & 调度

限制：AI泛化能力受限于过程精准控制，信息衰减严重，智能表现下降

AI-native Agent（智能中枢思路）

agent = LLM + 人设+ 工具+记忆 // 上下文窗口是稀缺资源

强调SSOT，明确每个行动阶段的意图与验收条件

行为准则遵循ReAct，自主感知、规划、执行

执行过程存在随机性（暴力试错），需要容错与高可用

优势：全局整体性与过程创造性

这两种思路的本质差异在于服务规模化与模型自由度之间的冲突。传统框架追求可控、可审计和可复现，宁愿牺牲AI的“聪明”也要保证流程的确定性；而AI-native的思路则是把大模型当作真正的大脑，让它自主决定如何拆解问题、调用工具和动态调整策略。

用过claudecode的朋友会直观感受到一个agent“全局思考、自动规划、自动纠错、跨领域联想”的能力。但一旦将LLM塞进固定的角色分工中，就必须按步骤走、等调度、用固定格式交流——LLM智能泛化的强项就这样被精准控制的流程结构削弱了。

回到LLM模型调用层面，function calling全过程

用LangChain开发多智能体应用，就好比试图把一条“AI剑鱼”塞进一个精心设计的“智能体编排鱼缸”里游泳，这不可能让AI发挥真正的能力。面对AI，我们要做的不是更多控制，而是学会放手，让AI这条生猛的剑鱼在广阔的数字海洋中自由驰骋。

如今我们可以断言，agent编排框架的技术尝试，是在对AI能力认知不足的历史时期的一次艰难试错（毕竟两年前的推理成本依然很高）。

AI时代下的AI-native应用，不会是APP时代思路的延续，而是从底层为“智能涌现”而生的新物种。

至于那些还在用旧框架规训AI的项目，或许只能成为技术演进史中一段令人唏嘘的注脚了。