从"支持插件"到"一切皆插件"，Agent框架正在经历一次架构范式的跃迁。这背后不只是技术选型，更是对"Agent到底是什么"的回答变了。

1. 先看清楚：插件化有三个深度层级

别把所有"支持插件"的框架都归为一类。按插件能碰多深，市面上的Agent框架其实分三层：

第一层：工具层插件化——代表：MCP生态、传统Function Calling

这是最浅的一层。框架内核不动，外面接什么工具可以换。MCP协议（Model Context Protocol）正在把这一层变成行业标准：Anthropic提出，Claude Code、Cursor、Codex、Windsurf全线支持，GitHub上已经有2.2万+相关仓库。

MCP的本质是给工具接入做了个"USB接口"——工具厂商只要写一套MCP Server，所有支持MCP的Agent都能用。这解决了过去每个模型厂商的Function Calling格式都不一样、每次接新工具都要写适配层的痛点。

但MCP管不了Agent内部的事。规划器怎么工作、记忆怎么存、执行循环怎么跑——这些内核层面的东西，MCP碰不到。

第二层：组件层插件化——代表：LangChain、CrewAI、Hermes

这一层的框架把内部组件拆成了可替换的模块：记忆可以换向量数据库、工具可以插拔、模型后端可以切换。Hermes走得更远一点，支持三层插件发现机制（用户级/项目级/pip入口点），还有Memory Providers和Context Engines两类一等公民插件。

但这些框架的核心循环和调度逻辑是写死的。你可以换零件，但引擎本身不能动。想改Agent的思考流程？只能fork仓库自己维护，从此跟上游渐行渐远。

第三层：运行时层插件化——代表：DeepSeek Harness (Cordis)、DeerFlow

这是目前最深的一层。Harness基于Cordis元框架，把Agent的每一部分都做成了插件：模型适配器是插件、工具注册表是插件、会话日志是插件，连Agent循环本身也是插件。

没有"特权内核"，没有需要打补丁的核心代码。想换整个Agent的执行逻辑？挂一个新插件就行，卸载时注册的东西会干净地自动撤销——Cordis管这个叫"可逆的副作用"。

DeerFlow走的是另一条路线：中间件插件链。把Agent运行时的横向切面能力（输入清洗、沙箱安全、上下文压缩、循环检测等）拆成26个独立中间件，通过@Next/@Prev装饰器精准插入链路位置。

这一层的核心区别是：框架不提供"Agent是什么"，只提供"Agent怎么组装"。

2. 第一个洞见：插件化的真正对手不是另一个框架，是"图编排"

Agent框架的路线之争，表面上看是"谁的插件更多"，本质上是两种完全不同的架构哲学在打架：

图编排路线的优势是可控、可复现、好调试。LangGraph能做到状态持久化、时间旅行、断点恢复，适合生产级工作流。

但它的天花板也很明显：你得先知道Agent应该怎么走，才能画出图来。当任务本身是开放式的（比如"研究一个新领域"），你根本没法预定义所有状态和转移路径。

插件运行时路线则反过来——它承认Agent的行为不可控，所以把架构做成"不管Agent想干什么，我都有对应的能力模块可以接上去"。规划器不行了？换一个。工具不够了？加一个。连整个思考循环都觉得不对？直接换掉循环插件。

这不是谁好谁坏的问题，是适用场景不一样：

• 确定性任务
   → 图编排，省token、快、可审计
• 探索性任务
   → 插件运行时，灵活、可扩展、能应对未知

真正有意思的是，这两条路线会不会合流——未来会不会出现"图式编排 + 节点内插件化"的混合架构？目前看LangGraph已经在往这个方向走了，原生支持MCP节点。

3. 第二个洞见：插件化的终局不是"灵活"，是"自进化"

这才是最值得关注的点，目前几乎没人说透。

当Agent循环本身也是插件的时候，会发生一件事：Agent可以自己开发、测试、替换自己的插件。

Harness官方文档里提到了这个能力的冰山一角："Thanks to Cordis's spatio-temporal composability, plugins support true hot-swap. This makes it possible for the AI itself to develop, test, and replace plugins autonomously."

翻译成人话：AI可以自己给自己装插件。

想一下这个链条意味着什么：

1. Agent发现自己缺某项能力
2. Agent自己写一个插件
3. Agent测试插件能不能用
4. Agent热插拔加载插件
5. 不行就卸载，再来一次

这不是"Agent调用工具"那个层级的事了，这是Agent在改造自身的运行时。就像一个人觉得自己反应不够快，直接给自己换了一套神经系统。

当然，现在这个能力还很早期。Harness才0.1预览版，"AI自主开发插件"更多是架构上的可能性，而不是已落地的功能。但方向是明确的——插件化越深，Agent自进化的空间就越大。

这也是为什么"一切皆插件"不只是工程洁癖，而是有实际的战略意义。架构上留了口子，未来的可能性才出得来。

4. 第三个洞见：插件生态的竞争，核心是"接口设计的颗粒度"

插件生态能不能做起来，不取决于有多少插件，取决于接口设计得好不好。

接口太粗（比如"你只要实现run方法就行"），插件之间没法协作，生态就是一堆各干各的孤岛。
接口太细（每个具体功能一个接口），插件写起来巨麻烦，门槛高到没人愿意贡献。

目前几个框架的接口设计选择很有意思：

MCP——只定义工具、资源、Prompt三类接口，颗粒度极粗。但它的定位就是"工具接入层"，粗是对的。粗才能跨语言跨平台，才有机会成为事实标准。

Cordis (Harness)——用服务(Service)/类型化事件(Typed Events)/生命周期钩子三层机制做接口。服务管共享能力，事件管插件间通信，钩子管时机。颗粒度中等，够灵活但也够复杂。代价是学习曲线陡——1.2万个commit的仓库，心智负担不小。

DeerFlow中间件——颗粒度最细。把Agent执行链拆成26个中间件，每个只干一件事，通过装饰器声明前后依赖。好处是精确，坏处是链路顺序本身就成了新的复杂度来源——26个中间件的排列组合，调试起来不比单体框架简单。

未来生态的胜出者，大概率不是插件最多的那个，而是接口抽象层次刚刚好的那个。好的接口设计应该是：80%的场景用默认配置就能跑，剩下20%的深度定制也有路可走，不用被逼到fork的地步。

5. 最后说几句

插件化Agent框架的趋势已经很明确了，但路还很早。现在的状态更像是"大家都意识到单体架构不行了，但新的标准形态还没长出来"。

可以重点关注三个信号：

• MCP能不能真正成为跨框架的工具层标准——如果是，工具层就不再是竞争点，框架间的比拼会上移
• 有没有第二款"一切皆插件"的主流框架出现——Harness现在是独苗，如果只有一家这么做，就是架构实验而不是行业趋势
• 第一个"Agent自己写插件自己装"的实际落地案例——这才是插件化架构真正的价值验证

说白了，插件化不是目的，让Agent能够持续生长才是目的。