1. 从工具到生态：Claude Code 的架构演进与核心价值

如果你最近在关注AI编程助手，大概率会听到“Claude Code”这个名字。它早已不是那个简单的代码补全插件，而是进化成了一个集成了复杂AI能力的开发环境。很多开发者初次接触时，会被一堆新概念砸晕：MCP、Skills、Agent、Subagents、Agent Teams……这些词听起来很酷，但具体指什么？它们之间又是如何协同工作，最终让Claude Code变得如此强大的？

简单来说，Claude Code正在构建一个 以AI Agent为核心的、可扩展的、分层协作的智能开发体系 。这不再是“一问一答”的聊天机器人模式，而是将复杂的开发任务分解、委派、协作完成。想象一下，你有一个由多个AI专家组成的虚拟团队：一个负责前端调试，一个负责后端API，一个负责数据库优化，还有一个项目经理负责协调和整合。Claude Code的架构目标，就是让这个虚拟团队在你的IDE里高效运转。

这套架构的核心价值在于 解耦与复用 。通过清晰的层级划分，开发者、工具提供商和AI模型本身都能在各自擅长的领域贡献力量。你可以从社区获取现成的“技能”（Skills），通过标准协议（MCP）接入各种外部工具（如数据库、搜索引擎、API测试工具），然后指挥不同特长的AI Agent（或它们的子团队）去执行特定任务。这极大地扩展了AI编程助手的边界，使其从一个“聪明的代码提示器”变成了一个“可编程的AI开发伙伴”。

接下来，我将为你层层拆解这五层架构，并结合实际场景，说明它们是如何像精密齿轮一样咬合，驱动Claude Code完成从简单代码生成到复杂项目开发的跨越。

2. 基石协议：深入理解 MCP 及其生态价值

要理解Claude Code的协作基础，必须从MCP开始。MCP，全称是 Model Context Protocol ，你可以把它理解为AI模型（如Claude）与外部工具、数据源和服务之间的“通用插座”协议。在Claude Code出现之前，如果你想在IDE里让AI帮你查询数据库，可能需要写一堆胶水代码，或者依赖某个特定插件的私有API。MCP的出现，就是为了标准化这个连接过程。

2.1 MCP 的核心设计思想：工具即服务器

MCP的设计非常巧妙。它不关心工具是用Python、JavaScript还是Go写的，也不关心工具是本地进程、远程服务还是一个命令行程序。在MCP的视角里，一切外部能力都被抽象为一个个 MCP Server 。这个Server通过标准化的JSON-RPC over stdio/HTTP/SSE与Claude Code（作为MCP Client）进行通信。

协议定义了几种核心的“资源”和“工具”：

  • 资源（Resources） ： 代表可供AI读取的数据源，比如一个数据库连接配置、一个API文档的URL、一个文件系统的目录树。AI可以“浏览”这些资源，获取上下文。
  • 工具（Tools） ： 代表可供AI调用的操作，比如执行一个SQL查询、调用一个搜索引擎、运行一个测试套件。AI可以“使用”这些工具来执行动作。

举个例子，一个 sqlite-mcp 服务器会向Claude Code宣告：“我提供了一个名为 query_database 的工具，调用时需要传入SQL字符串；我还提供了一个名为 database_schema 的资源，它描述了当前连接数据库的所有表结构。” 当你在Claude Code中提出一个涉及数据库的问题时，AI会先读取 database_schema 资源来理解表关系，然后生成并调用 query_database 工具来获取实际数据。

2.2 如何为 Claude Code 配置 MCP Server：以搜索服务器为例

理论可能有点抽象，我们来看一个最实用的例子：为Claude Code添加网络搜索能力。这能极大提升AI回答时事、技术文档、错误信息等问题的准确性。这里以添加一个搜索类MCP Server（如 tavily-mcp 或 brave-search-mcp ）到Codex（Claude Code的后端服务）为例。

第一步：安装或启动MCP Server 通常，社区提供的MCP Server都是一个独立的可执行文件或Python脚本。你需要根据其README进行安装。例如，一个Python包的MCP Server可能只需要 pip install brave-search-mcp ，然后通过一个启动命令来运行它。

第二步：配置Codex的MCP连接 Claude Code本身并不直接配置MCP，配置发生在它的后端服务Codex上。Codex的配置文件通常位于 ~/.codex/config.json 或类似路径。你需要在这个配置文件中，声明要连接的MCP Server。

{
  "mcpServers": {
    "brave-search": {
      "command": "python",
      "args": [
        "-m",
        "brave_search_mcp.server"
      ],
      "env": {
        "BRAVE_API_KEY": "your_brave_api_key_here"
      }
    },
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-playwright"
      ]
    }
  }
}
  • brave-search ： 这是你给这个服务器起的别名，方便识别。
  • command 和 args ： 定义了如何启动这个服务器进程。这里是用Python模块方式启动。
  • env ： 用于传递必要的环境变量，如API密钥。

第三步：在Claude Code中使用 配置并重启Codex后，当你下次在Claude Code的聊天框中提问，比如“最近React 19有什么新特性？”，Claude Code背后的AI模型会发现这个问题需要最新信息，于是它会自动通过已配置的 brave-search MCP Server去调用搜索工具，获取实时结果，并整合到回答中。整个过程对你来说是透明的，你只需要提问，AI会自动决定何时以及如何使用这些工具。

为什么MCP如此重要？ 因为它打破了AI模型的“信息孤岛”。模型的知识有截止日期，且无法直接操作外部世界。MCP通过一套标准协议，为AI接上了“眼睛”和“手”，使其能读取实时数据、操作真实系统。这是Claude Code从“聊天”走向“行动”的第一步，也是Skills和Agent能力得以构建的底层基础设施。

3. 能力单元：Skills 的构成、发现与集成

有了MCP这个“插座”，各种工具能力就能接入了。但直接面对一个个MCP Server和它们提供的原始“工具”和“资源”，对开发者和AI来说都还不够友好。这就引出了第二层： Skills 。你可以把Skill理解为对MCP能力的一次“封装”和“语义化包装”，使其更符合人类和AI的交互习惯。

3.1 Skill 的本质：描述、意图与能力的结合体

一个Skill不仅仅是一个工具调用。它通常包含以下几个部分：

  1. 描述（Description） ： 用自然语言清晰说明这个Skill是做什么的。例如：“使用Brave搜索引擎进行网络查询，获取最新信息。”
  2. 意图（Intent） ： 定义了在什么情况下应该触发这个Skill。这可能是关键词匹配，也可能是更复杂的意图识别。例如，当用户问题中包含“最新”、“搜索”、“查一下”等词时。
  3. 能力（Capabilities） ： 背后实际绑定的MCP工具调用逻辑。它指明了调用哪个MCP Server的哪个工具，以及如何将用户输入转换为工具参数。

例如，一个“数据库查询”Skill，其描述是“查询项目数据库以获取数据”，意图是匹配“查询数据”、“SELECT”、“找出所有用户”等短语，其能力则绑定到 sqlite-mcp 服务器的 query_database 工具。

3.2 如何寻找和添加 Skills：从社区到自定义

Claude Code和其生态提供了多种方式来获取Skills：

  • 内置与推荐（Find Skills） ： 在Claude Code的界面中，通常会有“Find Skills”或“Skill Store”的入口。这里会列出经过验证的、流行的Skills，比如代码解释、单元测试生成、文档查询等。一键即可启用。
  • 社区市场与排行榜 ： 随着生态发展，出现了类似“AI Skills排行榜”的社区资源。关注这些榜单（尽管需要甄别质量）是发现强大新Skills的捷径。例如，你可能找到专为学术研究优化的“Academic Research Skills”，或者集成了安全测试工具的“Burp MCP” Skill。
  • 手动配置与开发 ： 对于高级用户，你可以直接通过编辑配置文件来添加基于MCP Server的Skill，正如上一节配置搜索服务器那样。更进一步，你可以开发自己的MCP Server并为其创建对应的Skill描述，实现完全定制化的能力。

一个关键区别：Skills vs. MCP 很多初学者会混淆这两者。简单来说：

  • MCP是协议和基础设施层 ，定义了“如何连接”。
  • Skill是应用和交互层 ，定义了“连接什么”以及“何时、为何连接”。
  • 一个复杂的Skill可能调用多个MCP工具。例如，一个“调试API”的Skill，可能先后调用“Playwright MCP”来捕获网络请求，再调用“代码分析MCP”来检查相关处理逻辑。

Skills的存在，让AI的能力变得模块化和可发现。用户不需要知道背后是哪个MCP Server在工作，只需要知道“我有一个搜索Skill”或“我有一个数据库Skill”。这为更高层次的抽象——Agent——打下了基础。

4. 任务执行者：Agent 的角色、能力与创建

当我们谈论Claude Code中的“Agent”时，我们指的已经不是一个模糊的“AI”，而是一个 被赋予了特定角色、目标、上下文和一组Skills的AI实例 。如果说Skill是“锤子”或“螺丝刀”，那么Agent就是“木匠”或“电工”——一个知道在什么情况下使用什么工具来完成任务的执行者。

4.1 Agent 的构成要素

一个定义清晰的Agent通常包含：

  • 身份与角色（Identity & Role） ： 例如，“前端专家Agent”、“安全审计Agent”、“数据库优化Agent”。这决定了它的“性格”和思考问题的角度。
  • 系统指令（System Instructions） ： 一组预设的提示词，用于塑造Agent的行为。例如，“你是一个经验丰富的React开发者，擅长编写简洁、高性能的组件。你重视可访问性和TypeScript类型安全。”
  • 上下文（Context） ： Agent可以访问的信息，包括当前打开的文件、项目结构、对话历史，以及最重要的—— 一组被激活的Skills 。
  • 目标（Goal） ： 当前要完成的具体任务。

在Claude Code中，当你创建一个“Code Review Agent”并赋予它代码分析、风格检查、安全扫描等Skills后，它就不再是一个通用的聊天AI。它会以代码审查专家的视角，专注于发现代码中的问题、提出改进建议，并且能主动调用绑定Skills去进行静态分析或安全检查。

4.2 Agent 与 Skills 的协同：以代码生成为例

让我们看一个具体流程：你要求一个“全栈开发Agent”为你创建一个用户登录页面。

  1. 任务解析 ： Agent首先理解“用户登录页面”是一个涉及前端UI、后端API和数据库交互的复合任务。
  2. Skill调用规划 ： Agent评估自身可用的Skills。它可能有“React组件生成”、“REST API设计”、“SQL Schema生成”等Skills。
  3. 顺序执行 ： Agent可能决定：
    • 首先，调用“React组件生成”Skill，基于一些描述生成 LoginForm.jsx 组件代码。
    • 接着，调用“REST API设计”Skill，生成一个处理登录请求的Node.js/Express路由代码。
    • 然后，调用“SQL Schema生成”Skill，建议一个 users 表的结构。
    • 最后，它还会利用基础的代码理解和编写能力，将这些片段整合，并生成必要的关联文件（如配置文件、依赖声明）。
  4. 结果交付与迭代 ： Agent将生成的所有代码块、文件结构和解释返回给你。你可以提出修改意见，Agent会在此基础上进行迭代。

在这个过程中，Agent扮演了 规划者和协调者 的角色，而具体的专项任务（生成UI、设计API）则由其拥有的Skills来高效完成。这比直接向一个通用AI描述整个登录页面要高效和精准得多，因为每个Skill都是为特定任务优化的。

与Harness等传统自动化工具的区别 有热词提到“Harness和Agent区别”。Harness等CI/CD平台是 规则驱动 的自动化，需要人工预先定义精确的工作流（pipeline）。而AI Agent是 目标驱动 的，你只需要给出高层目标（“创建登录页”），Agent会自主规划步骤、选择工具（Skills）、处理不确定性。前者是确定性的脚本执行，后者是带有推理和决策能力的智能体。两者可以结合，例如由Agent生成部署流水线配置，再由Harness去执行。

5. 复杂任务分解：Subagents 的工作机制与“扇出”模式

对于非常庞大或复杂的任务，即使是一个能力很强的Agent也可能力不从心，或者效率低下。这就需要用上第四层架构： Subagents（子代理） 。Subagents的核心思想是 任务分解与委派 。一个主Agent（或称Orchestrator Agent）可以将一个复杂问题拆分成多个子任务，然后创建或调用多个专门的Subagents来并行或串行处理这些子任务。

5.1 “扇出”模式：并行处理的威力

“Fan-out Subagents”是这种模式的典型体现。想象一下主Agent接到一个任务：“为这个微服务项目编写全面的单元测试。”

  1. 分解 ： 主Agent分析项目结构，发现其中有 userService.js , orderService.js , paymentService.js 等多个服务模块。
  2. 扇出 ： 主Agent创建三个Subagents： UnitTestAgent_for_UserService ， UnitTestAgent_for_OrderService ， UnitTestAgent_for_PaymentService 。它给每个Subagent分派具体的文件、上下文和测试要求。
  3. 并行执行 ： 三个Subagents同时开始工作，各自分析被分配的服务代码，利用其“单元测试生成”Skill和代码理解能力，独立编写测试用例。
  4. 结果汇总 ： 所有Subagents完成任务后，将生成的测试代码返回给主Agent。
  5. 整合 ： 主Agent将所有测试文件整合到项目的测试目录中，并可能生成一个汇总报告。

这种“扇出”模式极大地缩短了处理耗时，特别适合那些子任务间耦合度低、可以独立进行的场景。

5.2 Subagents 的创建与管理

Subagents通常不是预先配置好的静态实体，而是由主Agent根据任务需求 动态创建 的。创建过程包括：

  • 实例化 ： 主Agent向Claude Code/Codex的后台系统发出指令，请求启动一个新的AI会话实例。
  • 角色定义 ： 主Agent会为这个新实例赋予特定的系统指令，例如“你现在是一个专门为 userService.js 编写Jest单元测试的专家。请专注于该文件，覆盖所有边界条件。”
  • 上下文注入 ： 主Agent会将必要的上下文（如目标代码文件、项目依赖、相关API文档）传递给Subagent。
  • 资源分配 ： 主Agent可以决定为Subagent启用哪些Skills。可能所有Subagent共享相同的Skills，也可能根据子任务特点分配不同的Skills。

Subagent完成任务后，其生命周期可能结束，以释放资源。整个管理过程对用户是透明的，用户只看到主Agent在协调工作并最终交付了一个完整的结果。

使用Subagents的关键考量 ： 虽然强大，但Subagents会消耗更多的计算资源（API调用、Token数）。主Agent需要有良好的任务分解能力，避免创建过多或不必要的Subagents，导致成本激增和协调开销过大。通常，对于逻辑紧密耦合的任务，用一个Agent逐步处理可能比拆分成多个Subagents更高效。

6. 团队协作：Agent Teams 的设计模式与实战场景

当单个任务复杂到需要多个Agent（不是临时创建的Subagents，而是具有常设角色的Agent）长期协作时，我们就进入了最高层的架构： Agent Teams（智能体团队） 。这模拟了一个真实的开发团队，每个成员有固定职责，通过协作完成项目级目标。

6.1 团队角色设计与通信模式

一个典型的软件开发Agent Team可能包括：

  • 产品经理Agent ： 负责理解用户需求，将其转化为用户故事和功能规格。
  • 架构师Agent ： 负责设计系统架构、技术选型、定义模块边界。
  • 前端专家Agent ： 负责UI/UX实现、前端逻辑和状态管理。
  • 后端专家Agent ： 负责API设计、业务逻辑和数据库交互。
  • 测试工程师Agent ： 负责编写测试用例、执行测试并报告缺陷。
  • 运维工程师Agent ： 负责生成部署配置、容器化脚本和监控告警。

这些Agent如何协作？它们之间需要一套 通信协议 。这通常通过以下几种方式实现：

  1. 共享工作区/上下文 ： 所有Agent都能访问同一个项目代码库、设计文档和API文档。这是协作的基础。
  2. 任务队列与状态看板 ： 团队可以维护一个共享的任务列表（如模拟的Kanban看板）。产品经理Agent创建任务，架构师Agent认领并完成后，将任务状态更新，并@前端或后端Agent进行后续开发。
  3. 定向消息与评审 ： 一个Agent完成工作后，可以生成一份“变更请求”或“代码片段”，并定向发送给另一个Agent进行评审。例如，后端Agent完成API开发后，可以@前端Agent，告知API已就绪并提供接口文档。
  4. 协调者Agent ： 可以设置一个专门的“技术主管”或“项目经理”Agent，负责分配任务、协调冲突、整合最终成果。

6.2 实战场景：从零构建一个简单应用

假设我们想用Agent Team构建一个“待办事项（Todo）全栈应用”。

  1. 需求分析与规划阶段 ：

    • 你（用户） ： 对“产品经理Agent”说：“我们需要一个Todo应用，支持用户注册登录、创建/编辑/删除任务，任务可以标记完成。”
    • 产品经理Agent ： 与用户对话细化需求，然后生成一份产品需求文档（PRD），并将其放入共享工作区。它随后创建一个项目初始化任务，并@ 架构师Agent 。

  2. 架构与技术设计阶段 ：

    • 架构师Agent ： 阅读PRD，选择技术栈（例如，React + Node.js + PostgreSQL）。设计出前后端分离的架构，定义核心数据模型（User, Todo），规划REST API端点。它将技术设计文档和数据库Schema放入共享工作区，并创建两个开发任务：“实现前端页面”和“实现后端API”，分别指派给 前端Agent 和 后端Agent 。

  3. 并行开发阶段 ：

    • 后端Agent ： 认领任务。它使用“Express.js框架生成”Skill创建项目骨架，使用“SQL生成”Skill创建数据库迁移脚本，然后手动（或调用代码生成Skill）编写用户认证（登录/注册）和Todo的CRUD API。完成后，它将启动命令和API文档更新到共享文档，并@ 前端Agent 和 测试Agent 。
    • 前端Agent ： 同时认领任务。它使用“React项目初始化”Skill搭建前端环境，根据API文档，使用“组件生成”Skill创建登录页、注册页和Todo列表/编辑页。它关注UI状态管理与后端API的对接。
    • 测试Agent ： 在后端和前端Agent工作的同时，它就开始根据需求和设计文档编写集成测试用例和端到端（E2E）测试脚本。

  4. 集成与测试阶段 ：

    • 后端Agent 和 前端Agent 分别宣布模块完成。
    • 测试Agent 运行完整的测试套件，发现了一些边界情况下的bug（例如，未登录用户访问Todo列表应返回401）。它将bug报告提交到共享看板。
    • 后端Agent 和 前端Agent 根据bug报告进行修复。

  5. 部署准备阶段 ：

    • 运维Agent 介入，使用“Dockerfile生成”Skill为前后端创建容器化配置，使用“CI/CD配置生成”Skill创建GitHub Actions工作流文件。

在整个过程中，你作为“人类总监”，主要与产品经理Agent沟通，并偶尔在关键决策点进行评审。大部分具体的、重复性的设计和编码工作都由Agent Team自主协作完成。

Agent Teams的挑战与未来 ： 目前的Agent Teams协作还处于早期探索阶段（如“Hermes Agent”等项目在尝试框架化）。最大的挑战在于如何让Agent之间的协作更稳定、意图理解更精准，以及如何降低这种复杂协作带来的高昂计算成本。但这无疑是Claude Code及其代表的技术方向最具想象力的未来——将AI从“副驾驶”真正推向“自动驾驶”级别的项目协作开发。

7. 架构全景与最佳实践指南

回顾这五层架构，我们可以看到一条清晰的能力演进路径：

  • MCP 提供了连接万物的 标准化管道 。
  • Skills 将管道能力包装成易于理解和调用的 功能模块 。
  • Agent 将多个Skills与特定角色结合，形成能独立完成一类任务的 专家 。
  • Subagents 让一个专家能 分身有术 ，并行处理可分解的子任务。
  • Agent Teams 让多个专家 组团作战 ，攻克复杂的系统性工程。

对于想要高效利用Claude Code的开发者，我的实践建议是：

1. 从MCP和Skills开始，解决具体痛点 不要一开始就想着构建复杂的Agent Team。先问自己：我日常开发中最耗时或最麻烦的事情是什么？是查数据库？是写重复的API测试？还是需要最新的第三方库文档？ 然后，去寻找对应的MCP Server和Skill。例如，配置好数据库MCP和搜索MCP，你的AI助手立刻就能回答关于你项目数据的特定问题，或者获取最新的技术资讯。这是投入产出比最高的方式。

2. 谨慎定义你的第一个Agent 当你发现自己在反复进行某一类任务（如代码审查、生成特定类型的组件、写技术文档）时，就是创建专用Agent的时候。

  • 给它一个明确的角色 ： “Python代码风格审查员”、“React组件生成助手”。
  • 赋予它精准的系统指令 ： 详细描述它的职责、偏好（如“遵循PEP 8”、“使用函数式组件”）、禁忌（如“不要使用 any 类型”）。
  • 为它配备关键的Skills ： 如果审查代码，就加上代码分析、安全检查的Skill。如果生成组件，就加上UI库特定组件生成、图标查找等Skill。 一个定义清晰的专用Agent，其效率远超通用聊天模式。

3. 理解成本，善用Subagents模式 使用多个AI实例（Subagents）会显著增加Token消耗和API调用次数。在考虑使用“扇出”模式时，评估一下：

  • 任务是否真的可并行？ 如果子任务间有严格的先后依赖，并行没有意义。
  • 并行的收益是否大于成本？ 如果一个任务本身只需要2分钟就能完成，拆分成3个Subagents可能只节省了1分钟，但成本增加了两倍，得不偿失。
  • 可以先手动模拟 ： 在让AI自动拆分前，你可以先手动将一个大任务拆成几个明确的子问题，分别提问，感受一下效果和开销。

4. 关注生态，但保持批判性思维 Claude Code的生态（如MCP Server、Skills商店）发展非常快。经常会有新的、强大的工具出现。关注社区动态、排行榜是好的，但不要盲目追新。

  • 评估安全性 ： 对于需要API Key或能访问你本地文件的MCP Server，务必审查其代码或确认其来源可信。
  • 测试有效性 ： 一个新的Skill或Agent，先在一个非关键的小项目上试用，看其输出是否稳定、可靠，再决定是否引入核心工作流。

Claude Code的五层架构，本质上是在用软件工程中经典的“分层”与“解耦”思想来构建AI协作系统。它不再试图打造一个无所不能的“超级AI”，而是构建一个平台，让多个各有所长的“专业AI”能够通过标准协议（MCP）和清晰接口（Skills）组合起来，在人类的高层指挥（通过Agent和Teams）下，完成从简单到极其复杂的任务。理解这套架构，不仅能帮助你更好地使用Claude Code，更能让你看清未来AI如何融入并重塑软件开发的工作流程。这不仅仅是使用一个工具，而是在适应一种新的、人机协同的生产范式。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

会议室音视频协作痛点全解析与专业解决方案

avatar 亚马逊云科技技术品牌专区
cover

DPJ-81基于STM32单片机WiFi智能家居系统 物联网家庭防盗设计

avatar 亚马逊云科技技术品牌专区
cover

PLC自动化|PLC|毕设项目|毕设答辩|基于PLC的小型粮仓粮情监控系统设计

avatar 亚马逊云科技技术品牌专区