插件化 Agent 架构系列 · 1 / 4
基于插件的 Agent 架构：为什么 + 是什么
在 LLM（Large Language Model，大语言模型）推理能力之上，agent 的真正护城河是它的"可扩展骨架"—— 怎么让组件（工具 / 策略 / 记忆 / 子 agent）安全地加进来、必要时安全地卸掉、彼此依赖不出乱子。 本系列从一篇 2026 年形式化论文（北大 + DeepSeek-AI）出发，把这套骨架的设计哲学拆成 4 讲——概念 → 时间维度 → 空间维度 → 范式与落地。
概览
3
核心特征
2
可组合维度
1
统一范式
4000+
案例插件
本系列 4 页速查
第一篇 · 概念入门
第 1 讲 · 1 定义 + 3 特征
什么是 plugin-based agent architecture
"Agent" 不只是 LLM + prompt——它是一个运行时进程，把模型 + 工具 + 策略 + 记忆 + 子 agent 编在一起，让用户提需求时能拿到完整解决方案。"插件化"说的是这个进程的组装方式：每个能力都是独立可插拔单元，运行时可演化，依赖透明。
3 个核心特征（论文 §1 启发的 agent 视角定义）
- 组件化：工具 / 策略 / 记忆 / 子 agent 全部以"组件"形式存在，每个组件是一段独立的可执行单元 + 显式声明的依赖
- 运行时可演化：组件可加可卸，不必重启整个 agent 进程——这是与传统 plugin system 的最大区别
- 依赖透明：组件间依赖显式声明，runtime 反应式协调（不是"我去找"而是"你被通知"）
为什么 agent 特别需要这个：传统 plugin system（VSCode、IntelliJ）的"组件"是开发者写完就不动的；agent 时代，组件自己也会改自己（self-evolving harness）——论文 §1.2.2 直接说"future harness may generate and deploy modifications to its own components while continuously serving requests"。这种"自我改"场景下，没有时空可组合性，每次自我修改 = 一次完整重启，agent 根本撑不住。
第 1 讲 · 2 维度 + 2 图
图 1 · Temporal（可逆性）和 Spatial（反应性）正交——一个管"组件走了之后"，一个管"组件之间怎么连"
两个维度：temporal × spatial（论文 §1.1）
论文把"动态可组合性"切成两个正交的维度。两者独立、各自难、必须同时解决：
对比
| 维度 | 回答什么 | agent 场景实例 |
|---|---|---|
| Temporal （时间） |
组件卸载时能否完全撤销它的所有副作用？ | agent 关闭某个 tool → 释放 file handle、撤销注册的事件、清理缓存 |
| Spatial （空间） |
组件间依赖能不能显式声明 + 反应式协调？ | agent A 依赖 agent B 的能力 → B 升级时 A 自动 reload；B 卸载时 A 自动降级 |
维度关系图
flowchart LR
subgraph Time[Temporal · 时间]
T1[组件加载] --> T2[运行时副作用]
T2 --> T3[组件卸载
撤销所有副作用] end subgraph Space[Spatial · 空间] S1[组件声明依赖] --> S2[运行时依赖变化] S2 --> S3[自动通知所有依赖者] end Time -.正交.-> Space
撤销所有副作用] end subgraph Space[Spatial · 空间] S1[组件声明依赖] --> S2[运行时依赖变化] S2 --> S3[自动通知所有依赖者] end Time -.正交.-> Space
正交意味着：解决 temporal 不会自动解决 spatial，反之亦然。论文的核心贡献就是"同时解决两个"——这正是后面 3 页要展开的。
第 1 讲 · 1 案例 + 1 对比
传统 plugin system 痛点：VSCode 案例（论文 §1.2.1）
VSCode 是大家最熟悉的 plugin system——扩展都通过 VSCode Extension API（API = Application Programming Interface，应用程序接口，这里指宿主暴露给扩展的一组调用入口）接入宿主——但它没有时空可组合性，这就是我们为什么要重新设计。论文用 VSCode 当反面教材。
2 个具体痛点（论文原文数据）
- Temporal 痛点：top 100 扩展中 87 个 包含可执行代码，卸载任何一个都要重启整个 extension host，影响所有加载的扩展。deactivate hook 只在 host 终止时触发，不支持热卸载。
- Spatial 痛点：top 100 扩展中只有 7 个 声明了 extensionDependencies。原因是 VSCode 把扩展绑死在"commands / views / language features"这种固定插槽上，扩展之间几乎不互相依赖——也就没有反应式协调机制。
传统 plugin system vs 论文范式
| 维度 | 传统 plugin（VSCode / OSGi） | 论文范式（Cordis） |
|---|---|---|
| Temporal | 卸载 = 重启 host / 进程 | 卸载 = 自动 LIFO 撤销所有 effect |
| Spatial | 依赖靠手动 / 强制重启 / 重连 | 依赖变化 = 自动通知 + 反应式协调 |
| 资源安全 | 靠开发者记性写 deactivate | runtime 强制追踪所有 effect，忘写就报错 |
| 热替换（HMR） | 需要手写 module.hot.accept | 自动——卸载 = 撤销 effect，重载 = 重新 instantiate |
| 代表性生态 | VSCode ~8700 个含代码扩展 | Koishi 4000+ 社区插件（4 个 9 复用） |
跟 agent 时代的对比：传统 plugin 是"开发者维护"——可以靠"写得仔细"绕开痛点；agent harness 是"AI 自动维护"——靠记性根本不可行。论文的形式化机制不是为了解决"开发者懒"，是为了让"机器生成的组件也能被安全加载/卸载"。
读完去哪儿
本页只搭了"为什么和是什么"的认知地基。形式化机制从 Page 2 开始：
- Page 2 · 时间维度：agent-plugin-2-temporal.html —— Revertible Effects 机制、agent 工具管理的应用
- Page 3 · 空间维度：agent-plugin-3-spatial.html —— Reactive Coeffects 机制、多 agent 协作的应用
- Page 4 · 范式与落地：agent-plugin-4-unified.html —— Context Paradigm + Cordis + 跟本仓 adapter 架构的连接