多智能体系统不仅需要提示词，更需要结构。在本书中，你将学习如何使用LangGraph构建工作流、通过MCP访问工具与数据、以及运用A2A协议实现智能体间的协调。Sandeep将带你构建可投入生产环境、具备可扩展性的智能体流水线。https://freecodecamp.org/news/how-to-build-a-multi-agent-ai-system-with-langgraph-mcp-and-a2a-full-book/…

如何使用LangGraph、MCP与A2A构建多智能体AI系统【完整书籍】

来源：https://www.freecodecamp.org/news/how-to-build-a-multi-agent-ai-system-with-langgraph-mcp-and-a2a-full-book/

构建一个能够回答问题或执行搜索的单一AI智能体早已不是难题。只需少量教程和几小时的工作即可实现。然而大多数教程跳过了关键的工程层——正是这一层使得多智能体系统能够可靠地在生产环境中运行。如何处理进程崩溃后的状态恢复？如何为智能体提供标准化工具访问接口，而无需为每个集成编写专用适配器？如何协调基于不同框架构建的智能体？如何检测智能体输出质量的下降？这些都是基础设施层面的问题，本书将通过可运行的代码为你解答。无需云账户，无需API密钥，零持续成本。
你将接触四种在协议层面解决这些问题的技术：

1. LangGraph 用于有状态的多智能体编排
2. MCP（模型上下文协议） 用于标准化工具集成
3. A2A（智能体间协议） 用于跨框架智能体协调
4. Ollama 用于本地大语言模型推理

为使每个概念具体化，你将在全书中构建一个真实系统：学习加速器。它能规划学习路线、基于个人笔记解释主题、运行测验并根据结果动态调整。使用场景仅作为教学载体，架构设计才是真正的重点。这种架构模式（通过开放协议协调的专业化智能体）如今已在生产环境中广泛应用：销售赋能（帮助销售代表入职并适配培训路径的智能体）、合规培训（指导员工完成监管课程的智能体）、客户支持（构建知识库并跟踪问题升级的智能体）以及工程师入职（引导新员工熟悉代码库的智能体）。领域会变，基础设施模式不变。

📦获取完整代码

本书配套的完整可运行代码库已发布在GitHub：
http://github.com/sandeepmb/freecodecamp-multi-agent-ai-system
可克隆仓库跟随操作，或在阅读时作为参考实现。

目录

• 引言
• 第一章：何时使用多智能体
• 第二章：使用LangGraph进行有状态编排
• 第三章：通过MCP实现标准化工具访问
• 第四章：构建四智能体系统
• 第五章：状态持久化与人工监督
• 第六章：使用Langfuse实现可观测性
• 第七章：使用DeepEval评估智能体质量
• 第八章：通过A2A实现跨框架协调
• 第九章：完整系统与未来展望
• 结语
• 附录A：框架对比
• 附录B：模型选择指南
• 附录C：生产环境加固清单

引言

你将构建的系统

该系统包含四个由LangGraph协调的智能体、两个为智能体提供外部工具访问权限的MCP服务器、两个支持跨框架智能体委托的A2A服务、捕获完整追踪信息的Langfuse，以及执行自动化质量检查的DeepEval。以下是端到端架构示意图：
学习加速器架构展示五层结构：左侧用户层输入学习目标、审批响应和测验答案至编排层；编排层包含具有五个节点（课程规划器、人工审批、讲解器、测验生成器、进度教练）的LangGraph工作流，连接SQLite检查点存储；下方工具层包含智能体可读写的MCP文件系统服务器和MCP内存服务器；底层推理层显示所有四个智能体连接至本地运行的Ollama（端口11434，使用qwen2.5模型）；右侧A2A层显示端口9001的测验生成器A2A服务和端口9002的CrewAI学习伙伴，通过JSON-RPC 2.0通信；右侧可观测层显示Langfuse通过回调追踪捕获所有LLM调用、工具调用和节点执行。

图1. 完整系统架构。LangGraph编排四个智能体，每个智能体通过MCP访问工具。进度教练通过A2A调用外部智能体（包括完全不同的CrewAI智能体）。Ollama本地执行所有推理，Langfuse捕获所有追踪信息。

你将逐层构建该系统。待系统完成后，你将不仅学会如何连接这些技术，更将理解每种技术存在的意义及其预防的生产环境故障模式。

技术栈

前置要求

你需要熟悉以下内容：

• Python 3.11或更高版本：类型提示、数据类、异步/await基础
• LLM基础概念：提示词、补全、工具调用
• 命令行操作：创建虚拟环境、运行脚本

无需具备LangGraph、MCP、A2A或任何智能体框架的先验经验。本手册将从第一性原理开始构建。

硬件要求

💡 模型规模对智能体的重要性

智能体通过生成结构化JSON参数来调用工具。若模型产生工具名称幻觉或参数格式错误，工具调用将静默失败：调用不执行、智能体循环运行，最终在无明确错误的情况下触发迭代限制。7B以下参数模型频繁出现此类JSON格式错误。7-9B模型是生产环境中可靠工具调用的最低可行层级。

第一章：何时使用多智能体

在编写代码前，你应先解答多数多智能体教程完全跳过的问题：你的问题真的需要多智能体吗？这至关重要，因为增加智能体会产生成本。更多智能体意味着更多组件、更多潜在故障点、可能从多方向被破坏的共享状态，以及需要跨进程边界追踪的调试过程。配备优秀工具的单一智能体往往是更简单、更快速、更可靠的解决方案。

因此问题并非“我应该使用多智能体吗？“——仿佛多智能体天生优越。真正的问题是：“我的问题是否具有需要协调开销的特性？”

1.1 何时单一智能体是正确答案

当问题的主要任务可在一个上下文窗口内完成时，单一智能体通常是最佳架构。例如：

• 研究主题并总结的智能体：单一任务，单一上下文窗口，单一智能体
• 审查拉取请求并评论的智能体：单一任务
• 从知识库回答客户问题的智能体：单一任务
• 从文档提取结构化数据的智能体：单一任务

在这些情况下，添加第二个智能体不会简化问题，反而会增加协调层、共享状态协议、新的故障面和调试复杂性，却无架构收益。单一智能体就能完成全部工作，配备好工具即可运行。

单一智能体的模型非常直接：

用户输入 → 智能体（配备工具） → 响应

智能体可能循环调用工具（搜索、读取、写入、验证），但单一LLM配合正确工具访问即可处理完整任务。这是多数AI自动化工作的正确起点，通常也是终点。

1.2 多智能体的真正评判标准

当问题存在真正不同的专业化分工时，才值得采用多智能体：子任务在工具、LLM调用模式、温度要求或故障模式上差异显著，将其整合至单一智能体会产生更多问题。以下是需要协调开销的具体条件：

不同子任务需不同工具

若工作流中一部分需文件系统访问，另一部分需数据库写入，第三部分需调用外部API，这自然形成了智能体分离的边界。每个智能体仅使用所需工具，使其更易独立测试和分析。

不同LLM调用模式

某些任务需要temperature=0的单次结构化输出调用。其他任务则需要多轮工具调用循环，直至LLM判断上下文充分。将这些模式混合在单一智能体中，会导致函数承担过多不同功能，并因执行路径不同而以不同方式失败。

不同温度与模型需求

结构化规划输出需要低温保证一致性。创造性解释需要稍高温度获取多样性。评分需要低温保证分析一致性。若这三个任务共享单一温度设置的智能体，你将在每个方向做出妥协。

故障隔离需求

若某个子任务失败可不影响其他任务，你需要在其间设置边界。规划课程的智能体即使在测验评分服务临时故障时也能成功。若它们共享同一进程和故障面，评分错误会连带导致规划失败。

独立部署需求

若系统不同部分可能需要不同规模运行、独立更新，或由不同团队使用不同框架开发，智能体分离对应着部署分离。A2A协议（第八章）使这成为现实。

跨框架协作

若想针对不同任务使用CrewAI和LangGraph智能体（因不同框架有不同优势），你需要通信协议。这就是A2A的作用。

这些条件中任一单独存在不必然要求多智能体。两项组合可能已足够。全部满足则论证强烈。

1.3 你支付的代价

在采用多智能体架构前，请明确你为之付出的成本：
**共享状态复杂性：**每个智能体读写共享状态对象。若两个智能体写入同一字段，需合并策略。若一个智能体写入错误数据，后续智能体都将获得错误输入。状态定义成为所有智能体必须遵守的契约，对契约的修改需更新每个智能体。
**调试更困难：**单一智能体的故障显示在单个堆栈跟踪中。多智能体系统的故障可能源于三步前的错误输出，该输出保存在状态中传递给第二个智能体，导致当前可见的故障。因果链跨越智能体边界。
**延迟倍增：**每个智能体至少进行一次LLM调用。四智能体系统每会话最少四次LLM调用，当智能体循环使用工具时往往更多。每次Ollama调用耗时2-5秒，总耗时快速累积。
**更多基础设施：**多智能体系统受益于状态持久化、可观测性、评估和人工监督，这些都需要时间搭建。单一智能体通常无需这些。生产环境的多智能体系统则真正无法缺少它们。采用多智能体架构时应清楚认识这些成本，并能明确说明带来的具体收益。

1.4 为何本系统采用四个智能体

学习加速器使用四个智能体。以下是每个分离的真实技术理由——并非因为多智能体更好，而是因为这四个任务差异足够大，任何两个的组合都会降低整体效果。