扩展性架构

“好的架构不是预知未来，而是让未来的变化变得廉价。” —— Robert C. Martin 14.1 问题引入：当能力边界需要不断外扩 一个 Agent 系统在发布后必然面临一个根本性矛盾：用户需求是无限的，而核心代码的变更是昂贵的。每一次向核心代码中添加新功能，都意味着更高的耦合度、更大的回归测试面积、更长的发布周期。 Claude Code 从第一天起就面对这个问题。它需要支持数十种斜杠命令、允许社区贡献新的技能、让每个用户拥有个性化的"记忆"，还要让企业能通过插件定制整个工作流——所有这些都不应该要求修改一行核心代码。 这就是扩展性架构要解决的问题。本章我们将剖析 Claude Code 源码中三个核心扩展子系统——插件系统、技能框架和 Memory 系统——背后的算法设计，揭示一个工业级 Agent 是如何在"对扩展开放、对修改封闭"的原则下，实现能力的无限外扩。 14.2 算法思想 14.2.1 插件发现算法：多源汇聚的声明式发现 Claude Code 的插件发现不是简单地扫描某个目录。它采用了一种多源声明式发现算法，插件来源按优先级排列： Marketplace 插件（plugin@marketplace 格式声明于 settings 文件） 会话插件（--plugin-dir CLI 参数或 SDK 内联注入） 内置插件（编译进二进制的 builtin plugins） 发现算法的核心在 assemblePluginLoadResult 函数中： assemblePluginLoadResult(marketplaceLoader): // 阶段1: 并行加载各来源 [marketplaceResult, sessionResult] = await Promise.all([ marketplaceLoader(), // marketplace 插件 loadSessionOnlyPlugins(inlinePlugins) // 会话插件 ]) builtinResult = getBuiltinPlugins() // 内置插件 // 阶段2: 多源合并（冲突解决） allPlugins = mergePluginSources({ session: sessionResult.plugins, marketplace: marketplaceResult.plugins, builtin: builtinResult, managedNames: getManagedPluginNames() // 企业策略锁定 }) // 阶段3: 依赖验证与降级 { demoted, errors } = verifyAndDemote(allPlugins) for p in allPlugins: if demoted.has(p.source): p.enabled = false // 阶段4: 缓存插件设置以供同步访问 cachePluginSettings(enabledPlugins) return { enabled, disabled, errors } 这个算法的关键设计决策有三个： ...