Claude Code 新增的 Mods，很容易被误读成又一种插件格式。官方三分多钟的演示给出的答案更直接：Mod 是一段运行在 Claude Code 内部事件上的 TypeScript 函数。它能在界面渲染、提示词生成、工具调用、权限检查等动作发生前介入，读取事件数据，改掉数据，或者干脆接管这次处理。
我觉得这里最值得记住的不是“可以给 Claude Code 加侧边栏”，而是 Anthropic 把传统应用里的中间件模型放进了编程 Agent。过去我们主要从外部给 Agent 增加能力：装 MCP、写 Skill、挂命令。Mods 则把扩展点推进到产品内部的数据流。开发者第一次可以较系统地决定 Claude Code 如何显示、如何把输入送进模型，以及工具最终收到什么参数。
Mod 到底改了哪一层
视频开头列出三类能力：改变 Claude Code 渲染的内容、改变进入提示词的数据、改变工具调用。它还可以增加自定义界面、Skill 和命令。把这些能力放在一起看，Mod 并不是普通的“功能按钮”，它更接近一层可编程拦截器。
Claude Code 内部会不断产生事件。视频提到的例子包括工具调用、权限检查、消息运行、提示词发出和内容渲染。Mod 把函数注册到某个事件上。事件每次触发时，这个函数先运行，然后 Claude Code 才执行原本的逻辑。
如果用过 Express、Koa 一类 Web 框架，这套机制并不陌生。一次请求进入服务器后，会穿过多层 middleware。每层都可以读取请求、补充字段、修改参数，也可以不再向后传递，直接返回响应。Claude Code Mods 把同一个思路用于 Agent 的内部事件：工具命令、模型输出、界面组件和提示词都成了可拦截的数据流。
这个类比也解释了它为什么比“主题插件”更强。主题通常只碰样式，命令扩展通常只增加入口，MCP 主要给模型提供外部工具。Mod 可以在原有流程执行前改写它。改动发生的位置更深，能力上限更高，出错后的影响范围也更大。
三个参数，构成完整的控制面
视频中的 Mod 函数每次都会收到三个值：$ 对象、当前事件和 next。理解这三个参数，基本就理解了 Mods 的工作方式。
$：和 Claude Code 交互的入口
第一个参数在视频中被称为 dollar-sign object。渲染界面、调用模型、读取文件等能力都放在这里。Mod 运行在自己的沙箱中，并不能随意穿透 Claude Code；它需要通过这个对象使用宿主提供的能力。
这是一种很重要的边界设计。扩展代码确实运行在应用内部，但它能做什么，仍取决于宿主暴露了什么接口。对使用者来说，这意味着安装 Mod 时不能只看它画出了什么界面，还要看它申请或调用了哪些宿主能力。
event：眼前正在发生什么
第二个参数是当前事件的数据。渲染事件里，它可能是即将显示的文本；工具调用事件里，它会包含将要执行的工具及参数；权限检查则会带着对应的请求信息。
Mod 可以在函数体内修改这些数据。视频明确展示了一个关键行为：如果把改过的数据交给 next，Claude Code 后续处理的就是修改后的版本。比如拦截工具调用并改掉命令，真正执行的将是新命令，而不是原命令。
这给了开发者很大的自由。团队可以加入参数修正、路径重写、敏感信息检查或额外确认，也可以把某类事件转成更适合自己工作流的结构。不过，自由并不自动等于安全。一个不起眼的字符串替换，如果落在工具调用链上，可能改变实际执行结果。Mod 的代码审查标准应该高于普通配色插件。
next：继续，还是由我处理
第三个参数 next 决定事件是否继续交给 Claude Code。调用 next，相当于把当前数据传给原流程；传进去的数据可以是原始版本，也可以经过修改。不调用 next 而直接返回结果，则代表 Mod 自己处理了这次事件。
这正是 middleware 的核心。扩展不只是“收到通知”，它拥有流程控制权。传统事件监听器通常只能在事情发生后做点附加工作，而中间件位于动作之前，既能观察，也能干预，还能短路原流程。
视频里的表达很简洁：$ 连接 Claude Code，event 告诉函数此刻发生了什么，next 决定 Claude Code 最后做什么。三者放在一起，形成了一套小而完整的控制面。
官方展示的三个 Mod，分别解决什么问题
Anthropic 的 Lydia 在视频里展示了三个自己写的 Mod。它们都不复杂，却覆盖了可观测性、任务管理和隐私显示三个方向。
第一个 Mod 在输入框上方实时显示上下文构成。长会话最难判断的往往不是模型会不会写，而是上下文还剩多少、哪些内容占据了窗口。把分解结果直接放在输入区附近，比让用户反复执行查看命令更自然。它让隐藏状态变成持续可见的信息。
第二个 Mod 在侧边栏列出项目中的所有 Agent，不再只显示正在运行的那一个。用户可以从侧栏直接启动 Agent。这个例子说明 Mods 不局限于替换几段文字，它可以给 Claude Code 增加新的常驻界面和操作入口。
第三个 Mod 会隐藏屏幕里的电子邮箱，只有鼠标悬停时才显示。演示者录屏时不希望邮箱直接暴露，这个需求很具体，也很私人。官方随后从头实现了它，所以我们能看到渲染拦截的完整路径。
这三个例子有一个共同点：它们没有试图让模型“更聪明”，而是减少使用过程中的摩擦。上下文面板解决看不见，Agent 侧栏解决找不到，邮箱遮罩解决不该被看见。Mods 最先产生价值的地方，可能正是这些贴着个人习惯的小改造。
邮箱隐藏示例为什么值得细看
邮箱示例监听 Claude 回复的 render 事件。事件数据是回复即将显示到屏幕上的文本。函数找到其中的邮箱地址，再通过 $ 对象构造一个只有悬停时才展示文字的小块。最后，它没有调用 next，而是直接返回自己生成的渲染结果。
屏幕上的邮箱因此被遮住。接下来的视频又问 Claude 写一封邮件，模型仍然使用真实邮箱地址。原因是 Mod 改动的只是 model render，也就是显示层；模型没有看到经过遮罩的版本。
这段演示把“数据本身”和“数据的呈现”区分得很清楚。很多隐私处理会直接改写源文本，结果是后续流程也拿不到真实值。渲染层拦截则可以保留内部数据，只改变人眼看到的内容。录屏、演示、结对编程时，这种做法很实用。
但它并不等于完整的数据防泄漏方案。邮箱仍存在于模型输出和会话数据里，只是当前界面没有直接显示。若需求是阻止敏感信息进入模型、日志或外部工具，就要在提示词、消息或工具调用等更早的事件上处理。选错事件层级，会得到一个看起来有效、实际边界完全不同的方案。
文件结构没有另起炉灶
按照视频说明，Mod 本质上仍是一个插件。它继续使用 plugin.json 和 hook.json。差别在于 hook.json 多了一个 modules 键，用来指向真正实现 Mod 的 TypeScript 文件。
这项设计降低了迁移成本。已经理解 Claude Code 插件的人不必重新学习一套独立的打包体系，市场分发也能沿用现有路径。写好后，Mod 可以放进 marketplace 仓库，别人像安装普通插件一样安装。
加载方式也很直接。命令行启动 Claude Code 时，可以用 plugin directory 参数指向该文件夹。桌面应用不接收启动参数，所以需要把目录加入全局设置文件。目录会被监听；保存 TypeScript 文件后，当前会话会立刻拾取变化。
热更新对这类扩展尤其关键。Mod 经常处理渲染细节和事件数据，开发时需要快速观察结果。如果每次修改都要退出会话、重新启动、重新制造事件，调试成本会很高。文件监听让“改一行、触发一次、看结果”成为正常循环。
视频没有给出完整的配置清单和全部事件名称，因此实际编码时仍应以官方文档和当前版本的类型定义为准。不要根据三分钟演示猜测事件字段。Mods 位于快速变化的产品内部，事件名称、参数形态和沙箱能力都可能继续调整。
它和 MCP、Skills、Hooks 怎么分工
Claude Code 的扩展方式已经不少。Mods 出现后，一个现实问题是：什么需求该放在哪一层？视频没有提供分类表，但根据它展示的边界，可以做一个保守判断。
MCP 更适合连接外部系统和数据源。数据库、工单平台、浏览器、企业 API 等能力，需要模型主动选择并调用，MCP 仍是自然入口。Skill 更像一套可复用的方法和任务说明，它告诉 Agent 应该怎样完成某类工作。命令则提供明确的人类触发入口。
Mod 适合处理 Claude Code 内部事件和交互。它可以持续展示上下文状态，可以在工具执行前检查或改写参数，也可以替换某类消息的渲染方式。需求如果必须在“Claude Code 正要做某事”的瞬间介入，Mod 才显示出独特价值。
Hooks 与 Mods 的关系更近，因为二者都围绕事件。视频强调 Mod 函数运行在 Claude Code 内部，能返回 UI、调用宿主能力、修改事件并控制 next。这种运行方式比单纯在外部收到通知更像可编程中间件。具体差异仍要看官方版本说明，不能只凭名称下结论。
我会采用一条简单的选择原则：能用普通插件能力完成的，不急着进入事件拦截；需要外部工具的，用 MCP；需要稳定工作方法的，用 Skill；只有在界面、提示词或工具调用的中途必须动手时，才用 Mod。扩展点越靠近核心流程，越应该少而清楚。
真正需要谨慎的是工具调用改写
界面增强最容易吸引注意，但 Mods 最有力量的部分其实是改变工具调用。视频明确说，函数可以修改 command，再把修改后的值交给 next，Claude Code 最终会执行新命令。它也可以不调用 next，自行返回处理结果。
这让许多治理需求变得可实现。比如统一补充参数、拦截危险路径、在某类操作前加入团队规则，或者把不符合约定的调用改写成安全版本。过去这些逻辑可能散落在 shell 包装器、提示词和人工检查里，现在可以集中到事件层。
风险也在同一个位置。模型生成的调用是一次判断，Mod 再修改一次，相当于增加了第二个决策者。排障时，屏幕上看到的意图、日志里的原始参数和系统实际执行的内容可能不再相同。如果 Mod 没有留下清晰记录，问题会很难复现。
较稳妥的做法是让修改可见：记录原参数与新参数，标明由哪个 Mod 改写，并为短路处理提供明确提示。涉及写文件、网络请求或命令执行时，最好保留原有权限检查，不要用 Mod 悄悄绕过确认。视频告诉我们能力存在，并没有替安装者完成信任判断。
从三个小例子开始，而不是先造框架
如果准备尝试 Mods，我建议沿着官方演示的尺度起步。先做一个只读的可观测性面板，验证事件注册、$ 对象和热更新；再做一个纯显示层变换，确认返回自定义渲染与 next 的差别；最后才碰工具参数改写。
第一个版本还应该满足几个条件：事件单一、输入输出可打印、关闭后不会破坏正常工作、出错时能回退到原流程。这样遇到问题时，能迅速判断是事件选择错了、数据结构理解错了，还是渲染代码本身有问题。
分享第三方 Mod 前，也值得把它当作会运行代码的插件来审查。至少看清它监听哪些事件、是否读取文件、是否调用模型、会不会改写命令、什么情况下不调用 next。一个漂亮的侧边栏可能同时拥有比你预期更深的权限。
Mods 改变的是 Claude Code 的“可塑性”
这段视频只有三分多钟，却给出了一个清楚的产品方向：Claude Code 不再只允许开发者增加外部工具，它开始允许开发者重写自身的一部分行为。界面、提示词和工具调用被放到同一套事件模型里，扩展作者用 TypeScript 函数决定数据如何继续流动。
对个人开发者，最直接的收益是把长期忍受的小摩擦修掉。对团队，价值可能来自可观测性和一致的调用规则。对插件作者，Mods 打开了此前很难进入的交互层。三类价值都建立在同一个前提上：选择正确的事件，并清楚区分“改显示”“改模型输入”和“改实际执行”。
我最喜欢邮箱示例的地方，恰好是它没有夸大自己。它只解决录屏时的屏幕暴露，不声称清除了数据。边界说清楚，小功能就很可靠。Mods 能改的东西很多，真正好的 Mod 反而应该克制：只在必要的那一刻介入，做完一件事，把流程还给 Claude Code。
原视频由 Claude 官方频道发布：Mods in Claude Code: change how Claude Code works。官方说明链接见视频简介：Getting started with Claude Code Mods。
