谁能解释一下 Claude Code 中 Hooks、Skills、Plugins、SKILL.md、CLAUDE.md 与 agents.md 的真正区别？

内容来源：Reddit / r/ClaudeCode。https://www.reddit.com/r/ClaudeCode/comments/1tmq9kz/can_someone_explain_the_real_difference_between/
原题：Can someone explain the real difference between Hooks, Skills, Plugins, SKILL.md, CLAUDE.md and agents.md in Claude Code?
原发布时间：2026-05-25

原始问题

我总在教程和视频中看到这些术语，却从没见过有人给出真正能让人顿悟其差异的具体示例。

大家总会说：

• “为它创建一项 Skill 就行”
• “这里使用 Hook”
• “安装这个 Plugin”
• “把它放进你的 CLAUDE.md”

可当我深入了解时，解释总是很模糊，或者过于理论化。

那些 Markdown 文件也一样——人们提到 CLAUDE.md、SKILL.md 和 agents.md 时，仿佛它们的用途不言自明，却没人解释：

• 每个文件里究竟应该放什么？
• 它们只是文档，还是会主动改变 Claude 的行为？
• Claude 到底会在什么时候读取它们？

我想找的是类似这样的说明：

“如果你考虑的是 X，那多半应该用 Hook；如果考虑的是 Y，那就是 Skill；如果你需要 Z，CLAUDE.md 正是为此准备的。”

如果能提供真实场景中的示例，就太有帮助了。

精选社区回答

caldazar24——最详尽的实践回答

文档中其实都有，但我很享受整理下面这份清单的过程。它迫使我理清了脑中的一些概念，也从侧面说明这些机制的边界有多模糊。

CLAUDE.md——会在会话开始时读取，提供工作方式方面的通用指导，就像新员工第一天入职时，你会告诉他的那些注意事项。

我的 CLAUDE.md 中包括这些内容：“我们这里使用 uv，因此始终运行 uv run python XYZ，而不是 python XYZ”“我们的移动应用目前只有内部测试用户，所以尽管弃用或破坏旧端点”和“当我说 prod 时，是指使用只读的 Render MCP 查询生产日志”。

Skill——解释如何完成某件事的 Markdown 文件。基本上就是一份保存起来以后再用的提示词；Claude 能看到这些文件并自行决定何时使用，你也可以通过斜杠命令显式调用。需要设计 UI 时，我有一套非常详细的指令，说明布局应该是什么样、设计系统又放在哪里。这些内容位于 Skill 文件中，因此每次描述新的前端任务时，我只需引用它，不必不断重复。

我还有一份每周指标报告，需要查询 SQL、解析 CSV，并为邮件整理一张 HTML 表格。描述这些步骤的提示词位于一份 Markdown 文件中，我通过 /weekly-report 调用。这些文件就是详尽的提示词：它们提醒 Claude 我喜欢怎样完成工作，也免去了复制粘贴。

Hook——当 Skills 太随意，而我希望获得严格的程序化确定性时使用：X 事件发生，就执行这条明确的命令。在 Claude 移动应用还不够好用时，我设置过一个 Hook；Claude 每次完成任务，它就会调用一份 Bash 脚本，向我的手机和桌面设备发送推送通知。我可以交给 Claude 一项耗时任务，然后起身去做家务，等任务完成后再收到提醒。

Plugins——添加到 Claude 中的第三方扩展。Plugin 可以只包含一项实用 Skill，也可以把多项 Skills 与一个 MCP 打成包。在 Claude in Chrome 推出前，我安装过 Playwright Plugin，其中包括用于控制无头浏览器的 Playwright、让 Claude 能与浏览器交互并截屏的 MCP，以及调用相关功能的 Skills。

Agent——最模糊、最像流行词的术语。它基本上是指一套以 LLM 为基础、能够完成某件事的程序；通常会编写代码并运行 Bash 命令，而不只是聊天。Claude Code 是智能体，监控收件箱并回复消息的程序也是智能体。

ipreuss——AGENTS.md 与子智能体

再补充一点：AGENTS.md 与 CLAUDE.md 类似，但供其他智能体使用。Claude 会忽略它。

子智能体与 Skills 类似，但使用自己的上下文。就像把工作委派给另一个智能体：“替我完成这件事，然后带着结果回来。”它们可以使用不同模型，也可以多个并行运行。

cornovum77 与 evangelism2——让多个工具共享同一份指令文件

可以在 CLAUDE.md 中使用 @AGENTS.md，让 Claude 读取它。

我就是这么做的。我的每个代码库都有一份 CLAUDE.md，其中只有一行指向 AGENTS.md，所有实质内容都放在 AGENTS.md 中。

evangelism2——让始终载入的上下文保持精简，以及后续更正

CLAUDE.md 与 Skill 的重要区别在于，CLAUDE.md 属于启动上下文，而 Skill 的描述会让 Claude 判断是否应该为当前提示词载入 Skill 的其余内容。可以把 Skills 理解为 CLAUDE.md 的扩展，其中包含 Claude 并非每项任务都需要的信息。

Hooks 更具确定性。Claude 会以非确定性方式决定是否触发 Skills，但对于匹配的 Hook，它没有决定权。

CLAUDE.md 应该精简、清晰，只包含无法立刻从代码库看出、且普遍适用的事实。凡是无须为每条提示词理解的内容，多半都应该放进 Skill 或斜杠命令。

**该讨论中的后续更正：**Claude 会在对话开始时读取 CLAUDE.md 和可用 Skill 的元数据，而不是每轮都从磁盘重新读取 CLAUDE.md。不过，避免始终载入的文件过于庞大，仍是一项有效的实践建议。

Diacred——存在争议的内部载入说法

根据泄露的 Claude Code 源码，CLAUDE.md 与 Skill 索引会在第一轮进入对话，而不是像 UserPromptSubmit Hook 那样每轮重新注入。这位评论者因此认为，长对话可能会降低模型对指令的遵循程度。

这只是对泄露实现细节的一种解读，并非官方说法，也没有得到独立验证。

caldazar24——一套具体的通知 Hook 实现

Pushover 是一项带手机应用的服务，提供发送推送通知的 REST 端点。我设置了一个 Hook，让它调用一份只有两行的 Bash 脚本，再由脚本把 Claude 的上一条响应发送给 Pushover。

一个小麻烦是，通知不会深度链接到 Claude。它会打开 Pushover，然后你还得找到触发通知的那段对话。不过，它确实完成了提醒我的任务。

tonyboi76——一套简洁实用的层级

我的实际用法是：

• CLAUDE.md = 每次会话都需要的规则，例如“使用 pnpm，不要使用 npm”或“身份验证代码位于 lib/auth”。
• Skill = 当相关主题出现时载入的 Runbook，就像架子上的多份操作指南之一。
• Hook = 围绕 Claude Code 事件自动执行的强制措施。我的 Hook 会在每次 Edit 后运行 Prettier，因此我永远不会看到格式差异。
• Plugin = 把 Skills、Hooks 与 Commands 一起分发的工具包。
• AGENTS.md = CLAUDE.md 的跨工具版本；使用 Import 或符号链接，只维护一份文件即可。

我最后采用的实用层级是：从 CLAUDE.md 开始；内容变得臃肿时，把主题拆成 Skills；如果发现自己不断手动应用同一项修复，就添加 Hook。

magicdoorai 与 fixitchris——策略、Runbook、强制执行与上下文

让我真正理解这些概念的心智模型是：CLAUDE.md/AGENTS.md 是策略，Skills 是 Runbook，Hooks 是强制执行，Plugins 是打包。文件应保持朴素：如果 AGENTS.md 变成什么都往里扔的垃圾场，智能体就会开始遵守早已过时的荒唐规则。

另一名评论者则把它重新表述为上下文管理：CLAUDE.md 是始终存在的上下文，Skills 是按需载入的上下文，Hooks 是围绕生命周期事件触发的副作用。如果你想改变 Claude 知道什么，请使用指令文件；如果某件事无论模型如何判断都必须发生，请使用 Hooks 或权限等强制机制。

50-3——提示词上下文与硬性验证

CLAUDE.md 提供项目上下文。Skills 可以显式调用，也可以由 Claude 根据描述自行选择。Hooks 可以强制执行程序化检查：例如测试 Hook 可以在测试未运行或未通过时拒绝接受工作。请小心，不要只是询问智能体“是否通过”，把硬性检查变成软性确认。

Agent 文件为委派给独立智能体的工作提供针对性指令。Plugins 是 Skills、工具、Hooks、智能体及相关配置的软件包；不同 Plugin 可能存在很大差异。

Sensitive-Cycle3775——逐组件心智模型

我的心智模型是：

• CLAUDE.md / AGENTS.md = 持久的项目指令与约定
• Skills / SKILL.md = Claude 可以在任务匹配时载入的打包流程
• MCP = 外部工具与数据访问
• Hooks = 能够运行命令的生命周期自动化
• Plugins = 上述部分机制的分发包
• 子智能体/智能体 = 由谁或哪个角色完成委派的工作

陷阱是把这一切都当作记忆。Hooks 与 MCP 是执行边界，Skills 是可复用的任务上下文，而 CLAUDE.md/AGENTS.md 更接近代码库策略。

为团队搭建环境时，请要求一键安装程序在修改代码库前展示计划：它会改动哪些文件、配置哪些 MCP 服务器和 Hooks、如何备份、需要哪些网络/环境访问，以及是否已经开始写入。这能让配置过程具备可审计性，而不是留下来源不明的神秘状态。

Kevin_Xiang——队友、Runbook 与确定性经验法则

对我而言，实用划分是：

• CLAUDE.md 是代码库级的操作上下文：命令、边界、约定与注意事项。
• Skills 是可复用的任务操作手册，拥有自己的步骤与参考资料。
• Hooks 是围绕运行过程的确定性护栏，例如格式化、测试、日志记录或阻止危险命令。
• 子智能体用于隔离工作，你希望它在独立上下文中完成任务，再返回明确的产物。
• 当 Codex、OpenCode 或其他智能体也会操作代码库时，AGENTS.md 是代码库指令的跨工具形式。

经验法则：如果某件事只需向每位新队友交代一次，就把它放入 CLAUDE.md 或 AGENTS.md；如果它是一套可重复的工作流，就做成 Skill；如果无论模型如何判断都必须每次发生，就做成 Hook。

Traditional_Fix111——作用于模型，还是在模型旁边运行

真正让我弄明白的，是判断每个组件究竟作用于模型，还是在模型旁边运行。

Hooks 是运行框架在 Stop、PreToolUse、PostToolUse 与 UserPromptSubmit 等生命周期节点执行的处理程序。某件事必须在准确事件发生时执行，就用它。Skills 是 Claude 在上下文匹配时读取的提示词扩展，会改变 Claude 处理工作的方式。CLAUDE.md 是为工作区载入的项目级指导。AGENTS.md 在多个工具之间承载同类代码库指导。Plugins 主要用于打包 Hooks、Skills、智能体与 MCP 服务器。MCP 则向模型暴露工具或外部数据。

你可以这样问自己：我是要让 Claude 以不同方式处理任务（Skills/CLAUDE.md），在生命周期边界围绕 Claude 运行某件事（Hooks），给 Claude 新工具（MCP），还是分发一个包含这些组件的软件包（Plugins）？

OpinionsRdumb——刻意保持简单的替代方案

作为 Claude 的长期用户，我发现只要用自然语言描述期望行为，Claude 通常就能创建适合的文件：保存一项持久事实、以后绝不再做某件事，或记住一套可复用流程。

对技术背景较弱的用户来说，过度设计记忆文件会造成不必要的臃肿。先直接描述想要的结果，只有当某项重复行为确实值得时，再把它正式固化。