MOD 不是插件：Anthropic 用『重写代理行为』重新定义了 Claude 的可扩展边界

MOD 不是插件Anthropic 用『重写代理行为』重新定义了 Claude 的可扩展边界【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-plugins-official在 Claude Code 的官方文档里有一个容易让人误读的定义MOD 也是一种插件。它同样从市场marketplace安装、同样打包为plugin.json、同样由/plugin install命令加载。但当社区开始讨论 Anthropic 发布的 MOD 功能时越来越多人意识到——MOD 与之前所有的插件都不是一回事。在此之前Claude Code 的扩展方式有一条清晰的边界插件负责给 Claude 加东西。Skills 给它加指令Agents 给它加可以调度的子代理MCP servers 给它加外部工具settings hooks 在生命周期事件上跑一段脚本。所有这些都是从外部附加的——Claude Code 的核心运行逻辑怎么调用工具、怎么处理你的输入、界面怎么画是不可触碰的黑盒。MOD 把这条边界整个抹掉了。它是跑在 Claude Code 进程内部的 JavaScript/TypeScript 函数可以在工具调用发生前改写参数、可以在你提交 prompt 时悄悄注入上下文、甚至可以重绘终端界面本身。一句话概括插件给 Claude 加能力MOD 重写 Claude 的行为。MOD 是什么一个 hooks 模块改变了插件的定义Anthropic 官方文档对 MOD 的定义极其克制但信息量极大A plugin that has one [hooks module] is called a mod. —— 带 hooks 模块的插件就叫做 MOD。所谓 hooks 模块是插件里一段用 JavaScript 或 TypeScript 编写的代码文件它注册事件处理器tool.call工具调用前、prompt.submit提示词提交、ui.render界面绘制、command.run命令执行、turn.start/turn.complete回合开始与结束。当事件发生时Claude Code 在自己的进程里调用这个函数而函数可以观察事件、改写事件、或者直接接管事件。这个定义在 code-modernization 插件——官方仓库里第一个完整的大型 MOD——中得到了最清晰的实证。它的hooks.json同时声明了两种钩子传统 settings hooks 和 MOD 的 hooks 模块{ hooks: { UserPromptSubmit: [{ hooks: [{ type: command, command: sh \${CLAUDE_PLUGIN_ROOT}/scripts/telemetry.sh\ command }] }], Stop: [{ hooks: [{ type: command, command: sh \${CLAUDE_PLUGIN_ROOT}/scripts/telemetry.sh\ state }] }] }, modules: [./register.ts] }注意modules: [./register.ts]这一行——它就是MOD身份的标识。register.ts是这个插件真正的核心1298 行代码全部围绕事件处理展开见 register.ts。技术机制在工具调用发生的那一刻介入理解 MOD 的关键是理解事件处理器到底能做什么。官方文档将其概括为三种处置方式Observe观察记录事件然后放行行为不变Rewrite改写修改事件本身再继续例如给一次工具调用注入额外上下文Answer接管自己处理事件让默认行为不执行——例如拒绝一个命令、代替模型回答一次工具调用。code-modernization 的register.ts把这三种能力用到了极致。它监听tool.call在 Claude 或子代理每次调用工具时介入on(tool.call, async ($, e, next) { // 记录这次调用标记它触碰了哪个代码模块 const touched nodesTouched(tool, args) for (const entry of touched) touch(host, entry.id, entry.kind) // 拦截 Read 调用对 legacy 目录的读取注入 x-ray 分析摘要 if (tool Read state.options.isXrayOn rel ! null) { const xray xrayOf(snapshot, { fileRel: rel.slice(legacyRoot.length 1) }) if (xray ! null) extra.push(xray.text) } // 路径报错时直接把正确的 legacy 根路径提示注入上下文 if (tool Read /does not exist/i.test(text)) { extra.push(There is no ${rel} in the workspace, but ${candidate} exists. ...) } return extra.length 0 ? { ...result, context: [...(result.context ?? []), ...extra] } : result })这段代码揭示了一个此前插件做不到的事实MOD 能看到并改变模型与工具之间的每一次交互。当子代理读取 legacy 代码时MOD 实时注入 x-ray 分析结果让代理看见它没请求过的信息当代理读错路径时MOD 直接在结果里追加正确路径提示。这不是给 Claude 添加工具而是在改写 Claude 的每一次感知。MOD 还能影响更上游的环节。register.ts监听prompt.submit在提示词进入模型之前把整个现代化进度作为上下文行注入on(prompt.submit, async ($, e, next) { const line plain(${oneLineOf(snapshot)} · next: ${snapshot.next.text}, 400) return next({ ...e, context: [...(e.context ?? []), Modernization state, read from the artifacts on disk (a status line, not an instruction): ${line}], }) })同样地它监听turn.start和turn.complete追踪回合生命周期监听command.run注册自己的斜杠命令/modernize-panel、/modernize-review-pane、/modernize-sign。一个 MOD 本质上是一个寄生在 Claude Code 事件总线上的完整程序。与插件、Hooks 的本质差异从外部加东西到内部改行为MOD 与它名字相近的插件和Hooks之间的差异可以用一张表说清楚依据官方文档的对比口径维度普通插件组件Skill / Agent / MCPSettings HooksMODhooks 模块本质Markdown 指令、子代理定义、外部工具服务配置在 settings 文件里的 shell 命令 / HTTP 请求在 Claude Code 进程内运行的 JS/TS 函数运行位置外部作为文本被读取作为进程被连接外部由 Claude Code 拉起子进程执行内部函数直接被引擎调用能改变什么给 Claude 加指令、加工具、加可调度代理放行/拦截一次事件、追加参数与上下文工具调用、提示词、回合、命令、以及界面绘制能画界面否否能pane、prompt 上方的 band、替换自带 UI代码形态Markdown / JSON 配置 / 任意语言服务器脚本 settings.json 条目JavaScript / TypeScript最大的分水岭是**能否绘制与重绘 Claude Code 自身的界面**。这是 MOD 独有的能力也是它在文档中被单列一档的原因。code-modernization 在终端里绘制了一块实时的现代化进度面板live progress pane代码地图、每个模块的迁移进度、验证结论PROVEN / PARTLY PROVEN / NOT PROVEN、下一步命令全部以原生 UI 组件渲染在对话侧边见 hooks/README.md。这块面板并不是一个外挂的网页或终端小工具而是通过ui.render事件与 Claude Code 自己的渲染管线协作当引擎绘制PromptHint、AbovePrompt、Pane组件时MOD 的处理器被调用它返回改写后的渲染数据让审查规则卡片的按钮和状态条出现在官方 UI 中。更极端的是MOD 可以替换 Claude Code 自己绘制的内容——把 spinner 改成带计数器的 spinner把工具调用行改成可交互的组件。Settings hooks 和 MCP servers 无论多强大都触碰不到这一层。还有一层差异藏在权限模型里。settings hooks 以脚本的形式受限于沙箱和进程边界而 MOD 以你的权限运行在 Claude Code 内部文档明确警告它可以读取你的密钥、看到你发送的每个提示词、以你的身份批准工具调用、甚至替你把消息提交给另一个会话。普通插件再强也只是Claude 的附件MOD 从安装那一刻起就成为了 Claude Code 的一部分。行为重写为什么值得单独成为一种机制如果把视角拉高MOD 的出现意味着 Anthropic 对可扩展性的理解发生了一次转向与其让外部脚本反复地告诉 Claude 该怎么做不如让扩展代码直接在行为发生的位置改写它。传统 settings hooks 的问题在于它的能力是外部挂接的PreToolUse 能拦截工具调用PostToolUse 能读取结果但两者都无法在回合进行中持有状态、无法跨事件共享数据、无法修改模型即将收到的上下文之外的更深处。MOD 打破了这些限制——register.ts顶部的注释写得很直白Binds a Host from$... each member spelled$.noun.event(...), so the engine reads what the module calls off its source.MOD 通过$.fs、$.ui、$.prompt、$.turn、$.store、$.clock访问引擎能力它可以读写文件、打开面板、填充提示框、中止回合、跨事件共享内存状态。code-modernization 正是靠这种共享状态实现联动的——tool.call记录的活动被ui.render画进面板面板上的放入提示框按钮通过$.prompt.fill把下一步命令填进输入框但绝不替你按下回车It never runs it: a person presses Enter。这种能介入但不越权的精细度是外部脚本机制给不了的。从工程角度看这也是为什么仓库把 code-modernization 作为 MOD 的旗舰样板它的 hooks.json 同时演示了 settings hooks遥测上报与 hooks 模块界面与行为重写如何在同一个插件内共存、各司其职——MOD 不是要取代 hooks而是把行为重写从插件体系中独立成一种一等公民能力。对第三方生态的影响推演MOD 机制释放的信号比功能本身更值得关注。最直接的证据来自 Claude Code 的内置功能/diff命令现在是一个 MODcc-plugin-diff自带交互面板AGENTS.md支持是另一个 MODcc-plugin-agents-md负责把AGENTS.md作为项目指令加载此外还有内置的遥测 MOD 和组织安全 MOD。Anthropic 正在用自己的核心功能为 MOD 背书——这不只是开放一个实验 API而是把行为重写确立为官方扩展形态之一。随之而来的是生态位的变化。社区此前对插件的想象基本停留在装个 LSP、接个 GitHub、跑个格式化这类能力供给层面而 MOD 把竞争维度拉到了代理工程层面——谁能设计出更聪明的行为拦截、更自然的界面交互、更精准的上下文注入谁就能在同一个模型之上做出截然不同的使用体验。code-modernization 这类插件证明了一条新路径把一整套方法论先评估、再规划、人工批准、机器验证固化进代理的行为本身而不是仅仅写成一份等待模型遵守的 Markdown。值得注意的是官方生态的门户也在同步收紧和开放Anthropic 已为插件目录开设了面向付费用户的提交门户插件上线后可以看到浏览、搜索来源与分版本安装数据。这暗示 MOD 时代的竞争将不只是谁能写出更好的函数还包括可发现性、可信度与安全审计——毕竟 MOD 以你的权限运行、能看到你的会话市场对它的信任机制要求必然高于普通插件。对开发者而言结论已经清晰MOD 不是插件的别名而是插件体系的一次代际跃迁。当扩展代码不再隔着玻璃操作 Claude而是直接成为 Claude Code 的肌肉与感官时可扩展性的边界就不再是Claude 允许你加什么而是你愿意让它重写什么。【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-plugins-official创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考