Claude 最新的 mods 有什么用？对 Agent 开发有什么启示？

回复 群友 607： 先说 mods 到底是什么。它是 Claude Code 的插件形态扩展，用 JavaScript 或 TypeScript 写事件处理函数（官方叫 hook），跑在 Claude Code 进程内部。跟以前的 settings hook 区别在这：settings hook 是你在配置文件里挂个外部脚本、HTTP 请求或提示词，是从外面进来的；mod 的 hook 是进程内的函数，所以它能做前者做不到的事。要求 Claude Code v2.1.287 以上，现在默认开，早期测试用的 CLAUDE_CODE_ENABLE_FUNCTION_HOOKS 环境变量已经失效了。 它能做四类事： 一、画界面。可以在对话记录旁边加一个 pane，或者输入框上方加一条 band，里面放 tab、按钮、输入框；还能重绘 Claude Code 自己画的东西，比如工具调用那一行、spinner、提问对话框。内置的 /diff 就是个 mod，一个 diff 面板。 二、拦住一次工具调用或一次请求。比如把工具调用先挂住去问用户、不真的执行直接给结果、或者把某一次请求发给另一个模型。hook 面对事件有三个选择：看着它过去（observe）、改掉它再放行（rewrite）、自己接管（后续默认行为不跑，等于拒绝或代答）。 三、加命令。注册一个 /command 直接跑你的函数，不经过 Claude 的一轮对话，甚至 Claude 正在干活的时候也能跑。 四、hook 之间共享状态。同一个文件里的变量是共享的，所以一个 hook 统计工具调用次数、另一个把次数画在 spinner 旁边——文档给的完整例子就是这个，屏幕上是 "Thinking · tool calls: 3…"。 内置的 mod 有几个，顺手认识下：cc-plugin-agents-md 把 AGENTS.md 读成项目指令，cc-plugin-diff 就是那个 diff 面板，cc-plugin-sec-default 保护组织托管配置不被用户自己装的插件改，cc-plugin-telemetry 发分析记录，还有个默认关闭的 cc-plugin-you-should-know——跑一个旁路 agent 盯着你的长任务，发现你可能会漏掉的事就写一行提示在输入框上方。 它不替代 skill、MCP、settings hook。skill 是教模型知道什么，MCP 是给模型外部工具，settings hook 是外部脚本做决策，mod 改的是 harness 运行时本身。官方自己也写了：如果 skill、hook 或 MCP 已经能满足需求，先别写 mod。一个插件里可以四种一起打包。 对 Agent 开发的启示，我觉得有六点值得拿出来说： 第一，harness 本身变成了可编程面。以前你想让 agent 循环里多一个动作——每轮看一眼 context 占了多少、工具调用前把敏感数据过滤掉、某个工具调用换个便宜模型——要么 fork 框架源码，要么在外面包一层。mod 把「事件 + 中间件」这个模式搬进了 harness 内部，而且动作分得很干净：观察、改写、接管。自己写 agent 框架的话这套事件模型值得照抄：事件名稳定（tool.call、ui.render）、handler 拿到事件和引擎接口 $、再用 next 决定要不要往后传。 第二，顺序和组合是新的复杂度来源。多个 handler 串起来之后，谁负责拒绝、重试会不会重复产生副作用、next 有没有被正确调用，每个 handler 单看都对，组合起来照样出问题。官方提醒 TypeScript 编译通过不等于交互逻辑正确，还专门给了不带会话的自动化测试入口。设计扩展点的时候，执行顺序得写清楚，测试入口得留出来。 第三，界面和可观测性是一等公民，不是事后接个日志。pane、band 能直接把 token 消耗、diff、工具调用计数画在你眼皮底下。这给做 agent 产品的启示是：可观测性别只做成日志导出，要作为 harness 的一部分开放给使用者自己扩。 第四，权限模型必须显式。mod 以你的权限运行，不沙箱化，能读写你能碰的任何文件、能读环境变量和 settings 里的 API key、能看你每一句 prompt 和每一次工具调用、能替你把工具调用批了——包括那些本来会被 ask 规则或 PreToolUse hook 拦下的调用。所以官方设计了两件事：装之前能静态列出这个 mod hook 了哪些事件、要干哪些危险动作（claude plugin validate）；以及 mod 重绘不了权限确认框，也就是扩展没法伪装成权限提示。这两条都值得抄进自己的平台。 第五，组织和个人边界会提前找上门。sec-default 和 allowManagedModsOnly 说明企业场景下托管配置得压得住用户自己装的东西。你自己做平台迟早会遇到：装的扩展能不能覆盖管理员策略、扩展挂了谁来兜底。 第六，最小扩展原则。先问 skill / MCP / settings hook / 现有 CI 能不能解决，再考虑写 mod。跟管理 Skill 生命周期是同一个道理，扩展越多，重复、冲突和维护成本越高，模型一升级还得复测一遍。 一句话收：mods 的意义不是「给 Claude Code 加功能」，而是把 agent 的 harness 变成了一个可拦截、可改写、能介入界面的运行时。你做 agent 项目时怎么设计自己的扩展点、扩展能碰什么、谁说了算，就是这一套问题。