让智能体长出能力：MCP 服务与插件体系

2026 年 8–9 月。通用智能体真正缺的不是"更聪明"，而是两样东西：领域能力（看不到你的论文库、连不上你的设计工具）和长期状态（换个会话就忘了上次的结论）。这一组工作都在解决这两个问题。

先说结论

• 能力外置（服务或插件）比写进提示词更可复用；
• 状态外置（记忆与经验）才能在换设备、换框架时保留下来；
• 扩展能力的同时必须保留兜底：新组件不可用时不能拖垮主流程。

一、把领域知识做成 MCP 服务

PaperRAG_MCP 是把个人论文库变成 Agent 可直接调用能力的实践：论文经验 → 向量检索 → 以 MCP 服务形式发布在 Cloudflare Workers 上（向量库与键值存储用平台自带服务），Agent 通过 MCP 协议接入。

选这个形态的原因有三点：无服务器意味着不用维护一台常开的机器；服务与设备解耦，任何一台设备上的 Agent 都能用同一份知识；接口用 MCP 标准，不绑定某一个客户端。

二、把能力与状态做成插件

在自托管的 agent 运行环境里，我按"能力外置、状态外置"的思路做了几个方向：

方向	解决的问题
注入器 × 思维模式路由	把"这次该用哪种思考方式"从提示词里拿出来，变成运行时可选的路由预设
跨设备记忆同步	各台设备上的记忆与经验通过一个私有 Git 仓库互相同步，而不是各自为战
主循环切换	把会话主循环切换到外部 agent CLI，同时保留内置主循环作为兜底
工作流套件插件化	把已经成型的科研工作流套件封装成插件，避免每个新环境重新搭一遍

这几个方向的共同判断是：同一件事写在提示词里，是一次性的；做成插件或服务，是可复用的。

三、一条贯穿的原则：兜底

"主循环切换"这条最典型：切换外部 CLI 能带来更灵活的能力，但一旦外部组件不可用，会话就整体瘫痪。所以实现上保留了内置主循环——扩展能力的同时不取消退路。跨设备记忆同步也一样：同步失败不能影响本地会话，它只能是"额外收益"，不能成为前置依赖。

四、体会

把智能体当作要长期维护的软件系统来看时，很多决策会变化：能力该放服务还是放提示词、状态该放本地还是放仓库、新组件失败时谁来兜底。这些判断与模型能力无关，但与"这套东西能不能用上一年"直接相关。