1. 项目概述：从单体智能到协同作战的架构演进

最近和几个做AI应用落地的朋友聊天，大家普遍有个感觉：Claude 3系列模型能力确实强，但真要把一个复杂的商业需求从头到尾跑通，光靠一个“超级大脑”指令式地干活，越来越力不从心了。比如你想做一个智能数据分析助手，它可能需要先理解你的自然语言问题，然后去数据库查数据，接着用Python做清洗和可视化，最后还得生成一份带解读的报告。这个过程涉及查询、编程、解释等多种能力，让一个模型频繁切换“人格”和上下文，不仅效率低，还容易出错。

这正是“Claude Code”背后那套五层架构要解决的核心问题。它不是一个具体的产品，而是一套由Anthropic及其社区提出的，用于构建复杂、可靠、可扩展AI智能体的设计范式与协作框架。这套框架把一个大任务，拆解成由不同专长“智能体”组成的团队，通过清晰的职责划分和通信机制来协同完成。今天，我就结合自己搭建几个智能体系统的经验，把这五层——MCP（模型上下文协议）、Skills（技能）、Agent（智能体）、Subagents（子智能体）、Agent Teams（智能体团队）——是怎么环环相扣、协同工作的，给大家掰开揉碎了讲清楚。无论你是想自己动手搭建一个自动化流程，还是评估现有的AI应用架构，理解这套协作逻辑都至关重要。

2. 架构核心：五层协作模型全解析

2.1 基石：MCP（Model Context Protocol）—— 智能体的“感官”与“手脚”

你可以把MCP理解为智能体与外部世界交互的标准化“插槽”或“驱动程序”。一个智能体再聪明，如果看不见、听不着、摸不到，也什么都做不了。MCP就是为解决这个问题而生，它定义了智能体如何安全、统一地访问工具、数据和计算资源。

MCP的核心是“资源”（Resources）和“工具”（Tools）的抽象。

  • 资源 ：代表智能体可以读取的信息源，比如一个数据库连接、一个API端点、一个本地文件夹，甚至是一个实时数据流。MCP协议规定了如何列出、描述和读取这些资源。
  • 工具 ：代表智能体可以执行的操作，比如执行一个Shell命令、调用一个函数、发送一封邮件。MCP协议规定了如何列出、描述和调用这些工具，并处理返回结果或错误。

为什么MCP如此关键？它解决了三个痛点：

  1. 安全性 ：智能体不再需要直接获得数据库密码或服务器SSH密钥。通过MCP服务器，你可以实现权限的精细控制。例如，一个负责数据分析的子智能体，通过MCP只能访问特定的、只读的数据视图，而无法执行删除操作。
  2. 标准化 ：无论底层是PostgreSQL、Google Sheets还是一个硬件传感器，只要实现了对应的MCP服务器，对上层智能体来说，调用方式都是一样的。这极大地降低了集成复杂度。
  3. 可组合性 ：不同的技能或智能体可以共享同一个MCP服务器提供的资源，避免了重复配置和连接。

实操心得 ：在项目初期，不要急于让智能体直接去连生产数据库。先用MCP包装一个模拟数据接口或一个测试数据库，让智能体在这个安全的环境里跑通流程。这能避免很多因数据格式或权限问题导致的初期挫折。

2.2 能力单元：Skills（技能）—— 可复用的“专业动作包”

如果说MCP提供了“刀枪剑戟”，那么Skill就是一套套成熟的“剑法”或“枪术”。Skill是一个封装好的、可重复使用的功能单元，它内部包含了调用MCP工具/资源的逻辑，以及处理相关错误的策略。

一个典型的Skill结构包括：

  • 目标描述 ：用自然语言清晰定义这个技能是干什么的。例如：“从指定的数据库表中，根据查询条件提取过去30天的销售数据。”
  • 输入/输出规范 ：明确需要哪些参数（如数据库连接名、表名、时间范围），以及返回数据的格式（如JSON数组、CSV字符串）。
  • 执行逻辑 ：内部封装了对一个或多个MCP工具的调用序列，可能还包括一些简单的数据转换或验证。
  • 错误处理 ：定义当MCP工具调用失败、数据为空或格式异常时，应该如何应对（如重试、返回默认值、抛出特定错误信息）。

Skill的价值在于“封装”和“复用”。 在数据分析团队的例子中，我们可以创建多个Skill：

  • query_sales_data ：查询销售数据。
  • generate_chart ：根据数据生成图表图片。
  • write_summary_paragraph ：根据图表和数据撰写一段文字总结。 这样，不同的智能体在需要完成类似任务时，可以直接调用这些Skill，而不必每次都重新编写和调试底层的MCP调用代码。

2.3 执行主体：Agent（智能体）—— 拥有“大脑”的独立工作者

Agent是拥有自主决策能力的核心单元。它通常由一个大型语言模型驱动，具备以下核心职责：

  1. 任务理解与规划 ：解析用户或上级智能体下达的复杂指令，将其分解为一系列有序的步骤。
  2. 技能调度 ：根据规划，选择合适的Skill来执行每个步骤。
  3. 上下文管理 ：维护整个任务执行过程中的对话历史和中间结果，确保决策的连贯性。
  4. 决策与判断 ：处理Skill执行中的异常，根据结果决定下一步是继续、重试还是终止。

一个Agent的内部工作流可以简化为： 

接收任务 -> 分析任务（思考/规划）-> 选择并执行Skill -> 评估结果 -> 继续下一步或结束

这个循环中，“思考/规划”是关键。好的Agent会输出它的“思考过程”，例如：“用户需要一份销售报告。这需要我先获取数据，然后分析关键指标并可视化，最后组织成文。我将依次调用 query_sales_data , analyze_metrics , generate_chart , compile_report 这四个技能。”

2.4 职能分解：Subagents（子智能体）—— 团队内部的“专家”

当单个Agent面临的任务过于复杂或需要高度专业化的知识时，就该Subagents登场了。Subagent本质上也是一个Agent，但它被设计用来负责一个更具体、更专业的子领域。

引入Subagents通常基于以下考量：

  • 复杂度隔离 ：主Agent（或称Orchestrator Agent）的职责被简化为任务分解和协调，不再需要了解所有细节。
  • 专业优化 ：可以为特定子任务定制更专业的提示词、配置更合适的模型（比如数据分析用Claude 3 Opus，代码生成用Claude 3 Sonnet），甚至连接专属的MCP资源。
  • 并行处理 ：某些子任务可以独立并行执行，由不同的Subagent同时处理，提升效率。

在我们的案例中，主Agent（报告协调员）在收到“生成月度销售报告”的指令后，可能会创建三个Subagent：

  • 数据工程师Subagent ：专精于数据查询与清洗，调用 query_sales_data 和 clean_data 技能。
  • 分析师Subagent ：专精于计算指标和生成图表，调用 calculate_kpis 和 generate_chart 技能。
  • 文案Subagent ：专精于组织语言和格式，调用 write_summary 和 format_report 技能。

主Agent的工作变成了：分配任务、收集各Subagent的结果、进行最终整合。这种架构让系统的可维护性和可扩展性大大增强。

2.5 协同网络：Agent Teams（智能体团队）—— 有机的“组织架构”

Agent Team是最高层的抽象，它定义了多个Agent/Subagent之间稳定的协作关系、通信协议和组织原则。它不仅仅是一次性的任务分解，而是形成了一个可持续运作的虚拟团队。

一个团队架构需要考虑：

  • 角色定义 ：每个成员（Agent）的固定职责是什么？（如：产品经理、后端开发、测试工程师）。
  • 协作流程 ：成员之间如何传递信息？是链式（A做完给B）还是星型（所有人和中心协调者沟通）或网状（彼此直接通信）？
  • 冲突解决 ：当不同成员的输出有冲突时（比如开发说实现了功能，测试说发现了bug），由谁或何种机制来仲裁？
  • 知识共享 ：团队是否有共享的上下文或记忆库，避免重复工作和信息孤岛？

一个经典的Agent Team例子是“软件开发生命周期团队”，可能由以下角色组成：

  1. 产品负责人Agent ：理解用户需求，编写用户故事。
  2. 系统架构师Agent ：根据故事设计技术方案和API。
  3. 开发Agent ：根据方案编写代码。
  4. 测试Agent ：编写并执行测试用例。
  5. 部署Agent ：负责代码集成与发布。

这个团队可以基于Git（通过MCP连接）进行协作，围绕同一个代码库，按照敏捷流程自动化地处理一个个需求卡片。

3. 实战推演：搭建一个智能数据分析团队

现在，让我们把这五层架构应用到一个具体场景：搭建一个能自动处理临时数据查询需求的“智能数据分析团队”。

3.1 需求分析与架构设计

需求 ：业务人员经常在聊天工具中提出诸如“帮我看看上周华北区A产品的销量，和去年同期对比一下，要个趋势图”的临时性数据请求。我们希望有一个AI助手能自动理解需求、执行分析并返回结果。

传统单智能体方案的局限 ：一个智能体需要同时具备：自然语言理解、SQL知识、数据分析逻辑、图表生成知识、报告编排能力。这会导致提示词极其复杂，上下文窗口压力大，且任何一个环节出错都可能需要从头开始。

五层架构设计 ：

  1. MCP层 ：部署两个MCP服务器。
    • 数据MCP服务器 ：提供对公司数据仓库的只读查询接口（Tool），以及访问数据字典（Resource）。
    • 工具MCP服务器 ：提供Python执行环境（Tool，用于运行pandas绘图代码）、文件读写（Tool，用于保存图表）和发送消息（Tool，用于将结果回传至聊天工具）。
  2. Skill层 ：开发四个核心技能。
    • nlq_to_sql ：将自然语言问题转换为安全的SQL查询语句。
    • execute_data_query ：调用数据MCP，执行SQL并返回数据。
    • analyze_and_visualize ：调用工具MCP，用Python进行数据分析和图表生成。
    • format_response ：将数据结果和图表组织成易于阅读的文本和图片回复。
  3. Agent与Subagents层 ：设计一个主Agent和三个子Agent。
    • 主Agent（需求协调员） ：负责与用户对话，理解整体需求，并调度子Agent。
    • 子Agent A（SQL专家） ：专精于 nlq_to_sql 技能，负责生成准确、优化的SQL。
    • 子Agent B（数据分析师） ：专精于 execute_data_query 和 analyze_and_visualize 技能，负责获取数据并产出图表。
    • 子Agent C（报告编辑） ：专精于 format_response 技能，负责整合最终答案。
  4. Team层 ：定义团队协作规则。采用“流水线”协作模式：用户请求先到主Agent -> 主Agent将问题抛给SQL专家 -> SQL专家返回SQL给主Agent -> 主Agent将SQL交给数据分析师 -> 数据分析师返回图表和数据给主Agent -> 主Agent将材料交给报告编辑 -> 报告编辑返回最终答案给主Agent -> 主Agent回复用户。过程中任何环节失败，错误信息会沿原路返回，由主Agent决定重试或向用户澄清。

3.2 关键实现细节与配置

MCP服务器的配置要点 ： 数据MCP服务器的配置必须极其严格。SQL查询工具应强制启用“最大行数限制”（如10000行）和“查询超时设置”，并且所有查询应在只读副本上执行。这能有效防止智能体意外触发一个消耗大量资源的查询，影响线上业务。

Skill的提示词工程 ： 以 nlq_to_sql 技能为例，给子Agent A的提示词不能只是“把问题变成SQL”。必须包含：

  • 数据模式上下文 ：提供相关表的结构（字段名、类型、关系）。
  • 业务规则 ：例如，“销售额”字段需要从订单表中汇总计算，“去年同期”指的是日期减去365天。
  • 安全与性能规范 ：例如，“必须包含WHERE条件限制查询范围”，“禁止使用SELECT *”，“优先使用索引字段”。
  • 输出格式 ：要求输出纯净的SQL语句，不要任何解释。

Agent间的通信协议 ： 子Agent之间不直接通信，均通过主Agent中转。传递的消息需要结构化。例如，主Agent给SQL专家的消息模板是：

{
  “task_id”: “req_123”,
  “task_type”: “generate_sql”,
  “user_query”: “上周华北区A产品的销量，和去年同期对比”,
  “context”: {
    “date_range”: {“start”: “2024-05-20”, “end”: “2024-05-26”},
    “target_region”: “华北”,
    “target_product”: “产品A”
  }
}

这种结构化的通信减少了歧义，也使日志记录和问题追踪变得非常清晰。

3.3 工作流串联与效果评估

当用户提问后，整个系统的工作流如下：

  1. 用户消息触发主Agent。
  2. 主Agent解析出核心实体（时间、区域、产品、对比维度），创建任务ID，然后调用SQL专家子Agent。
  3. SQL专家利用其专业提示词和技能，生成SQL，返回给主Agent。 主Agent此时可以做一个简单校验 ，比如检查SQL中是否包含了必要的安全限制。
  4. 主Agent调用数据分析师子Agent，附上SQL。
  5. 数据分析师通过MCP执行SQL，获取数据，调用Python生成对比趋势图，将图表文件路径和数据摘要返回。
  6. 主Agent调用报告编辑子Agent，附上图表路径和数据摘要。
  7. 报告编辑组织语言，生成最终回复文本，返回给主Agent。
  8. 主Agent通过工具MCP的消息发送功能，将文本和图表图片一并回复给用户。

效果对比 ：相比单体智能体，这个团队架构的优势立刻显现：

  • 可靠性提升 ：SQL生成错误只会影响第一步，数据分析师拿到错误SQL后可能执行失败，但错误会被捕获并反馈，系统不会产生误导性的“正确图表”。
  • 效率提升 ：每个子Agent上下文专注，思考质量高，且未来可以针对SQL生成或图表生成单独优化模型或提示词。
  • 可维护性提升 ：业务规则变更（如“华北区”的定义改变）只需更新SQL专家的提示词或相关Skill，不影响其他模块。

4. 架构演进中的挑战与应对策略

4.1 性能瓶颈与优化思路

在五层架构中，每一次Agent间的调用都意味着一次LLM的推理请求，这可能会带来延迟和成本问题。

挑战一：调用链路过长，延迟累加。 如果每个步骤都同步等待，用户可能需要等待数十秒。 应对策略 是引入异步处理和“乐观推进”机制。例如，主Agent在收到SQL后，可以立即将其交给数据分析师，同时让报告编辑子Agent开始准备报告模板（基于任务类型）。这样，当数据分析师产出图表时，报告模板已经就绪，可以立即填充内容。

挑战二：上下文重复，Token消耗大。 每个子Agent的提示词中都可能包含重复的系统指令和数据模式描述。 应对策略 是建立团队的“共享记忆”。可以设计一个轻量的团队级记忆存储，将公共信息（如数据字典、常用业务逻辑）存储其中。每个子Agent在初始化时，只需从共享记忆中按需加载自己所需的部分，而不是全量携带。

4.2 错误处理与团队韧性

在单体智能体中，错误处理逻辑可以写在一个提示词里。但在多智能体团队中，错误可能在任意环节发生，并且需要跨Agent传递和处理。

设计一个分级的错误处理策略至关重要：

  1. 技能级重试 ：对于网络超时、API瞬时失败等临时性错误，在Skill内部实现指数退避重试。
  2. 子Agent级降级 ：当子Agent任务失败时，它应返回结构化的错误信息，并尽可能提供部分结果或替代方案。例如，SQL专家如果无法生成复杂JOIN的SQL，是否可以生成一个简化版的、只查询核心表的SQL？
  3. 主Agent级协调与澄清 ：主Agent是错误处理的最终决策者。它需要根据错误类型决定：
    • 重试 ：换一个子Agent实例重试同一任务。
    • 降级 ：接受一个不完美但可用的结果，继续流程。
    • 澄清 ：向用户提问，获取更明确的信息（例如，“您说的‘华北区’具体包含哪几个城市？”）。
    • 终止 ：对于无法处理的错误，友好地告知用户失败原因。

**实现一个“团队状态看板”**非常有帮助。主Agent维护一个共享的任务状态对象，所有子Agent在开始、成功、失败时都更新这个状态。这样，任何一个Agent都能了解整体进度，避免做无用功。

4.3 成本控制与资源管理

多智能体意味着多份LLM调用开销。必须精细化管理。

成本控制策略：

  • 模型选型差异化 ：对逻辑复杂的规划、创意生成等任务使用能力最强但最贵的模型（如Claude 3 Opus）。对格式固定、执行简单的技能调用、结果格式化等任务，使用更小、更快的模型（如Claude 3 Haiku）。MCP服务器的工具调用甚至可以使用更轻量的开源模型。
  • 上下文精简 ：严格设计每个Agent的提示词，只传递必要信息。使用摘要技术，将长篇的中间结果（如大段数据）总结成关键要点后再传递给下一个Agent。
  • 缓存机制 ：对于常见、结果不变或变化缓慢的查询（如“公司有哪些部门”），建立缓存。当Skill被调用时，先检查缓存，命中则直接返回，避免不必要的LLM推理和MCP调用。

5. 从理论到实践：启动你的第一个智能体团队项目

如果你已经被这套架构吸引，想动手试试，我建议从一个超小的、但能完整跑通五层架构的“玩具项目”开始。

项目构想：智能天气穿搭助手团队

  • 目标 ：用户输入城市，获得穿衣建议。
  • 五层实现 ：
    1. MCP层 ：创建一个“天气MCP服务器”，它提供一个Tool： get_weather(city) ，返回该城市的温度、天气状况、风速等。
    2. Skill层 ：创建一个Skill： fetch_weather_data ，内部调用上述MCP工具。
    3. Agent与Subagents层 ：
      • 主Agent ：理解用户请求是“穿衣建议”，调用子Agent。
      • 子Agent A（天气获取员） ：专精于 fetch_weather_data 技能。
      • 子Agent B（穿搭顾问） ：根据天气数据，结合简单的规则（如温度>25度建议短袖，<10度建议羽绒服），生成穿搭建议。
    4. Team层 ：主Agent协调A和B的顺序执行。

技术栈选择建议 ：

  • MCP服务器开发 ：使用官方SDK或社区框架（如 mcp-cli ）可以快速搭建。对于这个简单项目，甚至可以用一个FastAPI服务模拟。
  • Agent运行时 ：可以考虑使用专为多智能体协作设计的框架，如 CrewAI 、 AutoGen 或 LangGraph 。它们内置了Agent定义、通信和流程编排的功能，能让你更专注于业务逻辑，而不是底层通信。
  • 编排与部署 ：对于简单流程，用脚本顺序调用即可。复杂流程可以使用工作流引擎（如Prefect、Airflow）或直接利用上述框架的编排能力。部署时，将每个Agent或MCP服务器容器化，用Docker Compose或Kubernetes管理，是走向生产化的第一步。

最重要的第一步 ：不要追求大而全。先用最笨的方法，在Jupyter Notebook里用函数模拟MCP调用，用几个if-else语句模拟子Agent的逻辑，把整个协作流程手动跑通。当你清晰地看到数据和控制流如何在“团队”中传递时，你就真正理解了这套架构的精髓。之后再逐步替换成真正的LLM调用、实现健壮的MCP服务器，你的智能体团队就会从一个玩具，稳步成长为一个能解决实际问题的可靠系统。

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

更多推荐

cover

Hugging Face Optimum 源码静态评测：模型部署优化框架的工程结构与验证边界

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

[人工智能]SciPy在工程计算中的作用与实践

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

智能软件工程AI4SE（一）——智能需求工程

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