一个 MCP Server 能跑起来，和一个扩展能被人持续使用，中间隔着一整套没人愿意写的脏活。

9 月 25 日，Anthropic 开放了 Claude 插件目录的开发者提交入口。表面看，这是一个分发渠道更新。开发者可以提交远程 MCP Server，或者提交一个打包了 MCP、Skills 的 GitHub 仓库，审核通过后出现在 Claude Directory。

但我盯着公告里另外几句看了很久。提交时自动校验和安全扫描。审核状态和修改反馈。上架后能看安装量、版本分布、搜索词和页面浏览量。

这不是给 MCP 加了一个下载页。

它在把 Agent 扩展从一个能跑的 Demo，推向一个需要被运营、被审查、被维护的软件产品。

过去一年，MCP 的问题从来不只是协议

如果你做过一点 Agent 集成，大概率见过这个场景。某个仓库 README 写得很兴奋，三条命令启动一个 server，工具定义也很漂亮。你把它塞进 Claude Code 或自己的 Agent，第一次调用成功，感觉非常好。

第二天换了台机器，环境变量没配。第三天 token 过期。再过一周，上游接口改了字段，工具描述还停在旧版本。真正难受的部分开始出现。

协议解决的是连接问题。它让模型知道有哪些工具、工具接收什么参数、调用后会拿到什么结果。MCP 在这一层确实做得很干净，尤其适合把内部的知识库、工单、Git 平台、数据库能力暴露给 Agent。

但一个组织愿意把扩展装进日常工作流，看的不会只有 schema。

它还得问一串非常现实的问题。

这个服务是谁维护的。它会读到哪些数据。OAuth token 放在哪里。升级会不会中断现有任务。一个 Skill 会不会每次都占上下文。工具失败时谁来排障。员工安装的第三方扩展，是否绕过了 IT 的权限边界。

这些问题不性感，却决定了扩展有没有资格进入生产环境。

很多团队把 MCP 当作 API 的新壳子，这个理解不算错，但少了一半。API 接进系统之后，有网关、鉴权、版本、监控、文档、SDK、应用市场。Agent 的工具层迟早也会长出同一类基础设施。不是因为行业喜欢堆概念，而是调用方变成了会自主组合工具的 Agent，失控成本变高了。

Plugin 打包的不是功能，而是一个运行时边界

Anthropic 对 Plugin 的定义很直接。它可以打包 MCP connector、Agent Skills，或者两者一起。到了 Claude Code 里，还能带上 LSP、commands、hooks 和 agents。

这组东西放在一起看，才知道它不是普通的插件压缩包。

MCP Server 提供外部动作。Skill 告诉 Agent 在什么情况下、按什么流程使用这些动作。Agent 可以承担一段更专门的子任务。Hook 会在特定生命周期节点执行命令。LSP 则把代码理解能力接进编辑与开发流程。

它们合在一起，近似于一个面向 Agent 的小型应用运行时。

举个贴近 Java 团队的例子。你想做一个 Spring 服务排障扩展，单独暴露 Elasticsearch、Kubernetes、Grafana 的 MCP tools 并不难。可真正好用的版本，还应该包含一个 Skill，约束排障路径先读错误率，再读最近发布，再查 pod 与 trace，不要一上来就重启。它可能还需要一个专用 Agent 做日志归纳，一个 Hook 在修改 deployment 前写审计记录。

此时用户安装的不是四个工具。

他安装的是一套会动的工作方法。

这也是我觉得 Plugin 比单个 connector 更值得关注的地方。它让能力和操作规程可以一起交付。过去团队最常见的失败，是工具接进去了，但每个成员调用方式不同，模型提示词散落在聊天记录里，经验没法随仓库迁移。Plugin 给了这件事一个标准容器。

当然，容器不是安全边界。很多人会在这里高估它。

官方文档明确提醒，启用的 Plugin 里的 MCP server 会在会话期间运行，Hook 会在相应事件触发，而且它们以用户身份执行。Skill、Agent 和 command 的名称、描述会进入每次会话的上下文，只有完整内容按需加载。这个设计很务实，也把代价写在台面上，功能越多，常驻上下文、后台进程和权限面就越大。

所以，Plugin 不是把一堆能力装进 zip 就能获得信任。它是在要求作者为边界负责。

一个目录，先补上的其实是信任链

MCP 生态已经有很多市场和聚合站。它们很有用，解决了发现问题。可当企业用户准备接入 Slack、Notion、GitHub、生产数据库时，发现只是第一步，后面还有一条更难走的信任链。

谁提交的。提交的版本是不是实际运行的版本。扫描发现了什么。为什么被拒。谁批准上架。出问题后能不能下线。装的人多不多。新版是否造成了使用量断崖。

Anthropic 这次把自动校验、安全扫描、审核反馈与发布控制放进同一个提交门户，又把安装量和搜索词回流给作者。每个点单独看都不新鲜，拼起来却说明平台开始承担分发治理。

我一直觉得，目录的价值不在于页面里多了多少 logo。真正的门槛是它能否把不确定性压低到一个团队敢装的程度。

这件事和 Maven Central、npm Registry 的演化有点像。早期大家会为能下载安装到依赖而高兴，后来才慢慢学会关心维护者身份、供应链投毒、弃用包、版本兼容与下载量异常。Agent 扩展甚至更麻烦，因为依赖包通常在编译或运行时被你的程序调用，Agent 扩展却可能主动读取上下文、请求远端服务、执行命令。

你想想看，一个 hooks 写得很短的插件，放错位置时，影响的不是一段业务逻辑，而是开发者整台机器上的工作流。

这话听着有点刺耳但，目录审核并不能替用户完成安全判断。安全扫描适合拦住已知问题，不能自动理解你公司的数据分级、网络策略和审批要求。平台给的是可验证的起点，不是安全背书的终点。

先别急着打包，三个账要提前算

对正在做 LangGraph、Claude Code 或内部 Agent 平台的团队，我的建议不是立刻把所有东西 Plugin 化。先把三笔账算清。

权限账

把每个组件能读、能写、能调用、能联网的范围列出来。不要只写 MCP Server 访问了什么 API，还要写 Skill 会引导模型做什么，Hook 在什么事件触发，Agent 有没有 Shell 权限。

一个简单的清单至少要回答这些问题。

  • 它读取的数据源有哪些，是否包含客户数据、代码或凭据
  • 它向外发送请求的域名有哪些，是否允许代理或重定向
  • 它会执行哪些命令，是否允许写文件、提交 Git、修改云资源
  • 哪些动作需要用户确认，哪些动作可在只读模式自动执行
  • 调用日志放在哪里，异常操作如何追溯

很多朋友可能觉得这会拖慢交付。站在赶进度的团队角度，这个感受完全合理。一个临时的只读查询工具，写完权限矩阵再评审，确实比本地跑通慢。

可一旦它被安装给十个人，临时就会变成事实标准。到那时再补权限模型，往往得推倒 API、提示词和部署方式。早点写清，反而是少返工。

上下文账

Plugin 带来的消耗不止 token 费用。Claude 的文档提到，能被自动调用的 Skill、Agent 和 command 的名称及描述，会出现在每一轮对话的上下文里。插件装得越多，模型每次判断该用什么的候选集就越长。

这块很容易被忽略，因为它不像一次 API 调用那样立即报错。它先表现为 Agent 有点迟疑，开始选错工具，或者在长任务后半段忘记了重要约束。然后团队把问题归咎于模型不够聪明。

其实吧，很多时候不是模型变笨，而是我们给它的操作台塞得太满。

我会把 Plugin 拆成三层。默认启用的只保留高频、低风险、描述足够短的能力。项目级能力放进仓库配置，让使用范围跟着代码库走。高权限或低频能力采用按需启用，任务完成就关掉。

官方文档也给出了 user、project、local 三种 scope。这个划分非常适合借来做治理。全局安装不能只是图省事，特别是和生产账号、文件系统、代码提交有关的扩展。

维护账

上架不是完成，而是开始背 SLA。

有了安装量和版本数据，作者终于能看到一个过去常被忽略的信号。某个版本安装很多但几乎没人继续用，可能不是市场不够大，而是 onboarding、权限申请、错误恢复或工具描述出了问题。搜索词也一样，它能告诉你用户以为你解决什么问题。

这对内部平台尤其重要。假设团队搜索的是「发布回滚」，你提供的是「Kubernetes 运维助手」。前者是任务语言，后者是技术语言。两者看起来相关，实际会把用户带去完全不同的使用路径。

把这些数据放回 backlog，Plugin 才能从一个工程师自嗨的集成，变成能迭代的产品。

我自己也还在摸索怎样给 Agent 扩展设定健康指标，不过有四个指标很值得先记下来。

  • 成功完成任务的比例，而不是只看调用次数
  • 首次安装到首次成功的时间
  • 权限拒绝和人工确认的分布
  • 升级后错误率与回退率

安装量高不等于价值高。一个从不被调用的连接器，可能只是大家都不敢点它。

对内部 Agent 平台，这是一次架构提醒

Channing 这类有 Java/Spring 服务、内部知识库和 Agent 工作流的团队，往往已经有两种资产。一种是能调用的系统能力。另一种是老工程师脑子里的排障顺序、审批习惯和风险判断。

前者容易被包装成 MCP。后者才是 Skill 和 Agent 真正该承接的部分。

别把经验全塞进一个两千行 system prompt。那会让能力难测试、难复用，也很难知道某次行为是模型自由发挥还是规则生效。更好的方式是按任务把流程拆成可检查的模块，把连接器、Skill、评估样例和权限声明放在同一个版本库里。

例如一个数据库诊断 Plugin，可以固定包含只读查询 connector、异常 SQL 识别 Skill、脱敏输出规则、针对慢查询和连接池耗尽的 eval cases。等它在研发环境跑稳定，再决定是否给生产环境加一条受确认保护的操作路径。

这比让一个万能 Agent 拿着管理员 token 试试看，要笨一点，也可靠得多。

回到公告本身，Anthropic 说现有的 skill、connector 或 plugin 不需要为了迁移而立即改动，未来会逐步在 Claude 与 Claude Code 之间形成统一的发现体验。这个节奏是对的。生态最怕强迫作者为了一个新名词重打包一遍。

但对于新项目，命名已经不重要了。该问的是，你交付给 Agent 的，到底是一根能调用的管子，还是一项能够被安装、约束、观测和撤销的能力。

前者能让 Demo 跑起来。

后者才能留在团队里。

参考资料