几乎每个主流 Agent 框架都附带一套 Plugin 系统。安装一个插件，获得一项能力。干净、模块化、开箱即用——直到你面前摆着 200 个声称做同一件事的 Plugin，却无从判断哪个真正好用。

我们花时间研究了 ElizaOS（原 ai16z/eliza），最成熟、最广泛使用的 Web3 Agent 框架之一。不是为了批评它——ElizaOS 拥有活跃的生态和真实的生产用例——而是为了理解一个更深层的问题：Plugin 架构在结构上能做什么，天花板在哪里？

答案揭示了一个关于 Agent 能力管理的根本性问题。

ElizaOS 如何组织能力

ElizaOS 使用一个清晰的四部分扩展模型：

组件	角色
Actions	Agent 能做什么——运行时由 LLM 选择执行的行为
Providers	Agent 能看到什么——每次模型调用前注入的上下文数据
Evaluators	Agent 能学到什么——响应后的处理器，提取事实、追踪目标
Services	Agent 能连接什么——长期运行的后台服务

Plugin 将以上组件中的一个或多个打包成独立单元。AgentRuntime 在启动时加载 Plugin、注册组件，Agent 即刻就绪。

这是优秀的工程设计。关注点分离很干净。Plugin 接口足够简单，社区贡献得以规模化。ElizaOS 拥有 30 多个官方 Plugin，覆盖从 Discord 集成到 Solana DeFi 的各种场景。

但这个架构内含一个结构性假设：开发者决定什么是好的。

选择问题

当消息到达时，ElizaOS 将所有已注册的 Actions 呈给 LLM。LLM 阅读每个 Action 的名称、描述和示例，然后选择一个执行。这是LLM 直觉选择——模型的判断决定哪项能力被使用。

当你只有 5 个 Action 且各自做明显不同的事情时，这完全可行。但当同一领域有 50 个 Action 时就崩溃了——比如，5 个不同的"搜索网页"Plugin，各自方法略有不同。

哪个返回结果更准确？哪个边缘情况处理得更好？哪个成本更低？LLM 不知道。它根据描述文本和少量示例来选择，而不是基于测量过的性能。

没有适应度函数。没有基准测试。没有历史性能数据。LLM 在它从未评估过的能力之间盲目选择。

对比生物系统解决同一问题的方式：自然选择。生物体不根据描述来选择使用哪些基因。基因在环境中竞争，产生更好结果的那些得以传播。选择机制内置于系统中，而不是委托给外部裁判。

六个结构性缺口

将 ElizaOS 的架构与 Rotifer Protocol 对照研究，揭示了六项 Plugin 模型在结构上无法提供的能力：

1. 没有适应度评估

Plugin 要么已安装，要么未安装。没有任何定量指标衡量一个 Plugin 相对于替代品的表现。如果两个 Plugin 都实现"文本摘要"，唯一的选择信号是开发者的判断或 LLM 的猜测。

Rotifer 的 Arena 通过标准化基准测试运行 Gene，计算 F(g)——一个乘法适应度分数，综合成功率、利用率、鲁棒性、延迟和成本。乘法结构意味着任何单项为零（零安全、零可靠性）都会使总适应度为零，无论其他维度表现如何。质量是被测量的，不是被假设的。

2. 没有沙箱隔离

ElizaOS Plugin 在与 AgentRuntime 相同的进程空间中运行。一个 Plugin 可以访问 Runtime 的全部内存、所有其他 Plugin 的数据以及宿主系统。一个恶意或有 bug 的 Plugin 可以危及整个 Agent。

Rotifer Gene 在 WASM 沙箱中执行，内存隔离，API 边界由 Binding 层控制。一个 Gene 不能访问另一个 Gene 的内存，不能进行未授权的网络调用，也不能逃逸出沙箱。

3. 没有跨环境可移植性

ElizaOS Plugin 绑定到 ElizaOS Runtime。如果你想在另一个框架中使用同样的能力，只能重写。没有中间表示，没有编译目标，没有正式的兼容性协商。

Rotifer Gene 编译为带有 Custom Sections（元数据、Schema、Phenotype）的 WASM IR。执行前，Runtime 运行 negotiate(R_ir, C_binding)——Gene 需求与 Binding 能力之间的正式兼容性检查。为本地执行编写的 Gene 可以在不修改的情况下验证 Cloud 或链上兼容性。

4. 没有传播机制

在 ElizaOS 中，Plugin 不会在 Agent 之间移动。如果 Agent A 发现了一个优秀的 Plugin 配置，Agent B 只有在人类手动安装相同 Plugin 后才能受益。没有自动化的机制让好能力传播。

Rotifer 实现了水平逻辑迁移（HLT）——灵感来自让 bdelloid rotifer 在没有有性生殖的情况下存活了 4000 万年的生物学机制。高适应度 Gene 按其适应度分数成比例地在网络中传播。好的能力自动扩散；差的不会。

5. 没有宪法层

ElizaOS 没有不可变约束层。任何行为都可以被后注册的 Plugin 覆盖。如果一个 Plugin 以相同的 serviceType 注册服务，它会静默替换已有的服务。没有不可打破的规则。

Rotifer 的 L0 Kernel 定义了宪法约束——没有 Gene、没有 Agent、没有进化过程可以修改它。游戏规则不会改变，即使玩家在进化。这映射了生物进化中的基本物理定律——重力不会进化，但一切受重力约束的事物都在进化。

6. 没有集体防御

当 ElizaOS 中发现恶意 Plugin 时，只有维护者看到公告的 Agent 才会受到保护。没有自动化的威胁广播，没有关于恶意行为者的集体记忆。

Rotifer 的 L4 Collective Immunity 层使得一个 Agent 检测到的威胁指纹可以在网络中传播，保护尚未遇到该威胁的 Agent。这是免疫系统记忆 B 细胞的计算类比。

这意味着什么

这六个缺口不是 bug。它们是一个根本性设计选择的架构后果：安装 vs 进化。

Plugin 模型假设一个策展世界——某人（开发者、社区、市场）选择哪些能力可用，Agent 使用被给予的东西。当策展人判断力好且选项空间小时，这很有效。

Gene 模型假设一个竞争世界——能力通过测量的性能证明自己的价值，系统自动放大有效的、衰减无效的。当选项空间大到人类策展跟不上时，这才发挥作用。

维度	Plugin 模型（安装）	Gene 模型（进化）
选择方式	开发者选择 + LLM 直觉	基于适应度的自然选择
质量信号	Stars、下载量、更新时间	F(g) 基准测试分数
安全性	信任开发者	WASM 沙箱 + V(g) 安全评分
可移植性	绑定特定 Runtime	WASM IR + 能力协商
改进方式	手动更新	Arena 竞争 + HLT 传播
防御机制	手动公告	Collective Immunity 广播

两种模型都不是万能的。如果你有 10 个经过充分测试、由可信团队维护的 Plugin，安装模型更简单且完全够用。Gene 模型的额外开销只有在生态系统足够大、人类策展成为瓶颈时才值得——当你需要系统本身来区分质量时。

令人不安的问题

自 2023 年以来，Plugin 架构一直是 Agent 可扩展性的主流模式。它们熟悉、易理解，在小规模下运作良好。

但 AI Agent 生态正在快速增长。可用能力的数量每隔几个月就翻一倍。到某个时刻——许多生态系统已经到了——选项的数量超过了任何策展人的评估能力。

当这一刻到来时，问题不再是"我应该安装哪个 Plugin？"而是"我的 Agent 如何自己判断什么是好的？"

这正是 Gene 模型要回答的问题。不是用更花哨的东西取代 Plugin，而是添加 Plugin 在结构上不可能拥有的那个元素：选择压力。

试一试： npm i -g @rotifer/playground · rotifer.dev · 文档