Claude Code各组件的协同方式：Skills、子智能体、MCP、钩子、插件。

从架构角度理解 Claude Code 是什么

若将 Claude Code 视为智能软件工程编排系统而非需要通过提示语驱动的代码生成工具，其功能才能得到最佳发挥。它会收集项目相关背景信息，判断所需操作，运用各类工具，将任务分配给专门的子智能体，与外部系统交互，执行相应操作，检查结果，如有问题则重新处理。

简而言之，它的运作模式是一个收集背景信息、执行操作并验证结果的循环过程。语言模型仅是其中的一个组成部分，围绕它的还有上下文管理、可复用的工作流、专用处理模块、各类工具、集成功能、确定性自动化机制以及结果验证系统。

比较这两种流程。传统的编码助手是接收提示、生成代码、返回结果。而基于智能体的架构则是接收需求、理解上下文、选择功能、执行操作、验证结果、迭代优化，最终交付成果。以生成测试文件为例，智能体工作流可以浏览代码库，找出现有的测试规范，定位受影响的API，编写测试用例并运行它们，分析哪些测试失败，修改实现代码，再次进行验证，最后给出总结。最大的变化在于从生成代码转变为执行与验证任务。

CLAUDE.md：持久化的项目上下文

CLAUDE.md 是该项目的持久化上下文层。其中存储了编码规范、架构决策、仓库结构、构建与测试命令、测试标准、安全规则以及何为完成的工作等内容。其中一部分内容可能如下所示：

• 框架：基于 TypeScript 的 Playwright
• UI 测试通过 npm run test:e2e 执行，API 测试通过 npm run test:api 执行
• 凭证绝不会以硬编码形式存在
• 每个新的 API 接口都需要对应的负向测试

这样就能让工程师不必反复解释相同的规范。可以把这个文件视为对“这个项目是如何运作的？”这一问题的解答。

该文件应包含Claude反复需要使用的稳定知识：代码库规范、测试要求、架构原则、构建命令、命名规则、安全要求以及团队习惯。它不应变成一本涵盖所有可能任务的繁琐步骤手册。一个实用的区分标准是：CLAUDE.md记载Claude应了解的关于项目的内容，而“技能”则说明如何完成特定类型的工作。将二者分开有助于简化维护并保持上下文的一致性。

技能：可复用的专业知识

技能是将可重复使用的专业知识以工作流形式呈现。它可包含针对特定任务的说明、脚本及辅助资源，这些任务包括 API 测试、代码审查、安全审查、代码重构、文档生成或回归测试等。只需编写一次工作流，就无需反复向 Claude 解释同一任务。技能旨在说明这类工作应如何完成。

例如，一个 API 测试技能可以按以下顺序执行这些步骤：

1. 确定 API 接口规范。
2. 检查现有的测试用例。
3. 生成正向测试场景。
4. 生成负向测试场景。
5. 生成边界条件测试场景。
6. 执行测试。
7. 分析测试失败原因。
8. 生成测试报告。

当收到诸如“为支付API增加回归测试覆盖”这样的请求时，该技能并不会直接开始编写测试代码。它会采用标准的测试方法，确保每个API都按照相同的组织标准进行测试。

CLAUDE.md与Skills的区别

两者的区别在于上下文与流程。CLAUDE.md描述的是项目要求：API测试使用Playwright，每个接口都需要进行负面测试，凭证来自环境变量。而API测试技能描述的是具体流程：检查接口契约，生成正面、负面及边界测试用例，运行这些测试并分类失败情况。前者说明代理需要了解哪些信息，后者则说明它应如何执行任务。

子代理：分配特定任务

子代理是专业工作者，它们在自身职责范围内执行特定任务，然后将结果反馈给主代理。主代理可能会将任务分配给UI测试子代理、API测试子代理和安全子代理。每个子代理独立处理各自的领域，主代理再将它们的输出整合为最终结果。

为何不使用一个大型代理？

复杂的工程任务通常涉及多个独立的方面。一个新的支付功能可能需要UI验证、API回归测试、安全分析以及数据库检查。虽然一个代理可以尝试处理所有这些任务，但上下文会变得过于复杂，且无关信息也会混杂在一起。子代理具有以下四点优势：

• 上下文隔离：每个子代理仅接收与其相关的信息。
• 专业化：每个组件可遵循不同的指令。
• 并行调查：独立的任务可以分别进行分析。
• 更整洁的主上下文：中间日志无需保留在协调器的主上下文中。

技能与子代理

技能描述的是工作应如何完成，而子代理则是负责其中特定部分工作的人或实体。API测试技能明确了组织的工作方法。API测试子代理会接收某个特定的API，并使用相应的指令和工具对其进行分析。

子代理与上下文窗口

代理任务会生成大量中间输出结果。安全审查可能会产生依赖关系分析、身份认证与授权问题发现、安全日志、代码搜索结果以及测试输出。将所有这些内容都输入到主代理中，会随着时间推移增加协调难度。安全子代理可以独立完成相关分析，并返回简洁的结果，例如两项严重问题、四项中等问题、建议的修改方案以及所需的测试。主代理只需获取最终结果，而无需了解整个处理过程。因此，上下文隔离既是架构上的优势，也是一种便利。

MCP与工具

MCP是什么

MCP即模型上下文协议，它是智能体与外部系统及数据源进行交互的集成机制。Claude Code位于一端，另一端则是GitHub、Jira、数据库、API、浏览器以及监控系统。这样一来，智能体便能超越本地编码环境，接入整个开发生命周期中使用的各类系统。

软件工程很少仅局限于编辑器内部。开发者可能需要Jira来管理需求，使用GitHub存储代码并提交拉取请求，借助数据库进行验证，依靠监控系统检测生产环境中的错误，同时利用API了解应用程序的行为表现。通过MCP，工作流可以读取Jira任务，查看相关代码库，确定对应的API，生成测试用例并运行它们，最后提交拉取请求。这样一来，编码智能体便成为了更广泛工程流程的一部分。

MCP与各类工具的对比

它们并非同一概念。MCP是协议或集成层，而工具则是智能体可以调用的具体功能。一个Jira MCP服务器可能会提供get_issue()、search_issues()和create_comment()这些功能。这些函数就是工具，而MCP则是让它们可以被调用的方式。简而言之，MCP是智能体进行连接的手段，工具则是它能够执行的功能。

工具能为智能体提供什么

工具让智能体能够执行操作。没有工具的话，大型语言模型主要只能进行推理和生成文本；而有了工具，它就可以读取文件以理解实现方式，搜索代码库以找到相关代码，编辑文件以改变行为，运行命令以执行测试，读取输出结果以诊断故障，再次编辑以修复问题，最后重新运行验证以确认结果。工具将一个仅能生成响应的实体转变成了工程工作中的主动参与者。

工具类型

Claude Code具备读取和编辑文件、搜索代码、运行命令、与资源交互以及启动专用子代理工作流的功能。MCP还能提供更多功能。按用途对它们进行分类会很有帮助：

• 观察工具用于读取、搜索和检查。
• 操作工具用于写入、编辑和执行。
• 集成工具用于连接外部平台。
• 委托工具用于调用专用代理。

这些工具共同使系统能够观察环境、做出决策、执行操作并检查结果。

钩子、命令和插件

钩子

钩子提供了确定性、事件驱动的自动化功能。某个技能可以在测试 API 时指示 Claude 执行回归测试。而钩子的运作方式不同：每当特定事件发生时，就会自动运行验证流程。例如，在修改代码后，钩子可以触发格式化工具，接着进行代码检查，再执行针对性测试，并返回验证结果。当某些工程控制措施必须每次都执行时，这种机制非常有用。

技能是模型可以使用的流程，而钩子则是由事件触发的自动化功能。技能描述了代码审查的推荐流程；钩子则在任何文件被修改后立即执行代码检查验证。技能帮助模型理解工作方式，而钩子则确保在特定事件发生时能执行关键操作。

为什么钩子在生产环境中如此重要

生成式人工智能具有概率性，因此团队不应依赖模型来决定某个重要控制流程是否执行。如果每项更改都必须经过格式检查、代码检查、安全扫描和单元测试，这些步骤应当由确定性自动化处理，而非交由模型判断。其原则是运用人工智能进行灵活决策，同时用确定性自动化处理强制性的控制流程，而在企业环境中这种区分尤为重要。

命令

命令是明确触发的工作流，例如 /review、/test 和 /debug。输入 /review 即会刻意启动预定义的代码审查工作流。命令的含义就是“我明确希望执行此工作流。”

命令是由用户发起的，而钩子则是由事件触发的。输入 /test 即属于明确的命令操作。源代码发生变化后自动运行测试，则属于基于事件的自动化处理。因此，命令由人类触发，而钩子由事件触发。

命令与技能也存在重叠之处，因为可重用的技能可能会提供人们主动调用的工作流程。审核功能就可以存在于某个技能中，并通过 /review 命令来启动。不过，技能所包含的内容远不止提示语：还包括指令、辅助资源、脚本，以及围绕该可重用功能而设计的配置。

插件

插件用于打包和分发扩展功能。想象一下，某个测试机构已经开发出了API测试功能、安全测试功能、API子代理、安全子代理、验证钩子以及MCP集成功能。这样一来，无需每位开发者都重新构建同样的环境，这些组件就可以作为一个插件一起提供。

这就是插件对企业如此重要的原因。它们将代理式工程从个人生产力工具提升为组织级能力。如果没有统一的打包机制，每位工程师最终都会以不同的方式配置AI环境。而标准的插件能够整合工程标准、测试方法、专用代理、自动化规则以及各种集成功能，从而使每个项目都能拥有相同的能力。从架构角度而言，插件属于治理与标准化层。

各组件如何协同工作

通过一个简洁的框架，可为每个组件分配特定任务：

• CLAUDE.md 负责了解项目整体情况。
• 技能模块负责明确工作方式。
• 子代理负责执行分配给它们的专业任务。
• 工具模块负责执行具体操作。
• MCP负责与外部系统连接。
• 钩子功能用于自动化生命周期事件。
• 命令可根据需求触发工作流。
• 插件用于打包和分发各种功能。

Claude Code位于核心位置，负责协调所有组件。它们解决不同的架构问题，彼此并非可互换的功能。

从开始到结束的完整工作流

以“为新的支付API添加回归测试覆盖”这一需求为例，其可能的执行流程如下：

1. 需求提出。 Claude Code接收该请求。
2. 项目背景。 CLAUDE.md规定了测试标准、命令、代码库规范以及安全要求。
3. 技能选择。 API测试相关的技能为组织提供相应的方法论。
4. 任务分配。 专门的子代理负责分析API的功能、安全问题以及回归测试的影响。
5. 集成。 通过MCP连接的系统可访问相关的外部平台。
6. 工具。 Claude Code能够读取代码、搜索文件、编写测试用例并执行命令。
7. 验证。 Hook机制会执行代码检查、格式化处理、针对性测试或其他验证操作。
8. 确认。 Claude会评估测试结果，判断是否还需要进一步处理。
9. 最终输出。智能体会将测试用例、测试结果、相关文档以及工作总结交还给用户。

这是一个完整的智能体工程工作流，远非简单的代码生成那么简单。

智能体循环

重申核心模型：收集上下文、执行操作、验证结果。收集阶段包括理解需求、代码库结构、架构规范、惯例、依赖关系以及当前的实现情况。执行阶段涉及使用工具进行搜索、修改、运行、集成或委托任务。验证阶段则包括运行测试、查看输出结果、识别故障，并判断需求是否真正得到满足。如果验证失败，系统会重新回到收集或执行阶段。

在实际操作中，流程更接近于上下文分析、操作执行、验证、修正、再次验证，最后完成任务。正是这种迭代机制使得可靠的智能体区别于一次性代码生成工具。

设计人工智能测试工程环境

Claude Code上强大的SDET架构可以整合以下要素：

• CLAUDE.md，其中包含测试框架、架构设计、测试规范、安全规则以及任务完成标准。
• API测试、界面测试、回归测试及故障分析相关的技能。
• 用于处理界面测试、API测试、安全测试及回归测试的子智能体。
• 用于仓库搜索、文件编辑、命令执行及测试运行的工具。
• 连接GitHub、Jira、数据库、API及监控系统的MCP接口。
• 在代码变更后自动执行格式化、代码检查、测试及验证操作的钩子功能。

/api-test、/regression、/security-review 和 /debug 等命令。

一个可将所有组件打包起来的插件，以便多个工程团队重复使用。

协调器会根据需求来统筹这些组件。

选择合适的机制

五个问题有助于确定合适的构建模块。

• 这是关于执行任务的可复用知识吗？使用 Skill。
• 需要专门的独立工作节点吗？使用 Subagent。
• 该代理需要执行特定操作吗？使用 Tool。
• 该操作依赖于外部平台或数据源吗？考虑使用 MCP。
• 每当生命周期事件触发时是否需要自动运行某些内容？使用 Hook。

最后一个问题涉及分发方式：如果该功能需要被打包并共享，应使用插件。这一框架体现了对各层职责的清晰理解，正因如此它才会出现在架构讨论中。

核心要点

成功的智能体工程并非仅仅取决于更大或更聪明的大型语言模型。一个可运行的系统需要多种功能相互协调：

• 上下文，使智能体能够理解项目需求。
• 技能，以实现可重复的专业操作。
• 任务分配，因为复杂任务可能需要专门的执行者。
• 工具，让智能体能够采取行动。
• 集成，以便接入外部工程系统。
• 自动化，确保必要流程能够可靠运行。

验证，用于确认相关操作是否真正生效。

封装，以便各团队能够重复使用这些功能。

其发展脉络为：AI聊天机器人、AI编程助手、AI智能体、智能体驱动的工程工作流，最终形成智能体驱动的软件工程平台。