简介

文章介绍了从零构建企业级多智能体系统的方法，通过Agent、Tool和Crew三个核心模块，不依赖高级编排库实现多智能体协作。相比单智能体，多智能体系统具有开发调试简单、减少"幻觉"、问题解决高效、推理过程透明等优势。文章详细阐述了系统架构、各模块设计思路和代码实现，并提供了完整案例，帮助读者掌握多智能体系统的构建方法，适合企业级AI应用落地。

---

一、前言

本文会从零构建一个企业级多智能体架构与代码级落地实践，不依赖 LangChain 或 CrewAI 这类高层级编排库。我们会把整套逻辑拆解为三个简单且符合逻辑的模块：

• 一个 Agent 类：负责思考、行动，并维护自身的推理循环；
• 一个 Tool 类：智能体可调用的工具，用于与外部世界交互；
• 一个 Crew 类：整合多个智能体，协调它们的工作流程。

通过这种方式，我们能完全掌控智能体的行为，更易优化和排查问题。文中将使用 OpenAI 作为大模型后端，但如果您更倾向于本地部署，也可以用 Ollama（本地运行大模型的开源工具）搭配 Qwen3 等模型。

过程中，我们会讲解多智能体模式的原理、设计 “协作与工具调用交织” 的智能体循环，并实现多个可供智能体调用的工具。最终，您将得到一个基于纯 Python 和大模型后端的可运行多智能体系统，其中的智能体既能独立推理、调用工具，又能在受控流程中传递结果。

下文我们详细剖析之。

二、为什么需要多智能体？

我们已经知道，单个大模型智能体能力很强，但面对复杂的多步骤任务时，它的处理能力会受限。而 “多智能体方案”（用一组专业智能体协作）已成为解决复杂流程的有效方式。

将大问题拆解为多个子任务，分配给专门的智能体处理，这种方式相比 “单体智能体” 有诸多优势：

2.1 开发与调试更简单

每个智能体专注于特定子任务或角色，整体系统的逻辑更清晰。比如修改某个智能体的提示词或逻辑时，不会影响整个系统 —— 其他智能体的角色是独立的（尽管一个智能体的输出可能会被另一个使用）。这种 “职责分离” 意味着：升级某个智能体（比如优化 “调研智能体”）时，不会给其他智能体带来意外影响，就像团队中替换一位专家无需重新培训所有人。

一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

2.2 降低复杂性，减少 “幻觉”

如果让单个智能体用一个超长提示词兼顾所有工具和指令，它很容易混淆或编造信息；而多个 “专注型” 智能体更能保持方向。比如在 “代码助手” 工作流中，我们可以设置三个智能体：“规划智能体” 负责拆解任务、“编码智能体” 负责写代码、“审核智能体” 负责检查代码 —— 每个智能体的提示词和工具都针对自身职责优化，能更高效地运用领域知识或专用工具。

2.3 问题解决更高效

多智能体的 “分布式协作” 能让复杂任务（比如规划旅行）拆解为多个简单子任务：一个智能体查天气、一个找酒店、一个规划路线…… 这些专业智能体协作解决整体问题的效率，远高于单个 “全能型” 智能体。

2.4 推理过程更透明

多智能体系统天然具备 “明确的职责分工”，让推理过程更易追踪。每个智能体通常会 “清晰地思考”（通过 “思维链提示词” 输出推理过程），产生的中间结果也能被其他智能体或开发者查看。甚至，多智能体工作流会鼓励智能体互相验证输出 —— 比如一个智能体生成计划，另一个智能体评价或优化计划，形成可追溯的对话记录。这种 “审计轨迹” 能提升可解释性：您能看到每个 “专家” 的决策依据，而不是单个黑箱模型的输出。

2.5 问题定位更快速

当多智能体流程出错时，更容易定位问题根源。因为任务是分段的，您能通过详细日志判断 “哪个智能体”“哪一步” 产生了错误输出或卡住（比如查看 “调研智能体” 的搜索结果、“撰写智能体” 的草稿摘要）。这比排查 “一个做所有事的巨型智能体” 要简单得多。

2.6 符合人类团队协作逻辑

多智能体模式模仿了人类团队的运作方式，让 AI 工作流的设计更自然。在企业中，人们会分角色协作（分析师、规划师、构建者、审核者）；同理，多智能体系统中，每个智能体就像团队成员，有明确职责，协调者确保它们协同工作。这种映射让设计复杂 AI 方案变得直观 —— 只需思考 “我的团队需要哪些角色的智能体”。比如 “AI 旅行 concierge 服务” 可设计为一组智能体：一个查景点、一个处理交通与天气、一个优化行程，共同响应用户需求。

三、多智能体的内部原理

如前所述，多智能体模式将 AI 工作流设计为 “一组协作的智能体”，每个智能体有明确角色。它不是让一个智能体从头处理任务，而是让多个智能体形成流水线：每个智能体处理任务的一部分，再将结果传递给下一个，最终完成目标。

这种设计通常（但不总是）由 “协调器” 把控 —— 确保智能体按正确顺序运行、共享信息。这就像流水线或接力赛：智能体 A 完成第一步，智能体 B 用 A 的输出做第二步，依此类推直到任务完成。

每个智能体在处理子问题时具备自主性，但会通过定义好的工作流协作解决整体问题。从技术角度看，多智能体中的每个智能体，内部仍遵循 “推理 + 行动” 循环（通常基于我们之前学过的 ReAct 范式）：接收输入（或上下文）→ 思考要做什么（生成 “Thought”）→ 行动（输出结果或调用工具）→ 观察结果→ 继续循环。

关键区别在于：多智能体中的每个智能体 “职责范围有限”—— 它的关注点更窄、工具集更小、目标更明确。比如一个负责 “数据库查询” 的智能体，只会思考 “如何查询数据库” 并执行查询操作，而不会操心 “如何向用户展示最终答案”（这是另一个智能体的工作）。通过限制智能体的职责，我们能让它的提示词更简洁、更有针对性，行为也更可靠。

四、 系统整体架构

为理清多智能体架构的组成部分，我们拆解一下核心模块：

4.1 智能体（Agent）

智能体是 “自主 AI 单元”（通常由大模型 + 提示词构成），能感知输入、推理（通过思维链）、执行行动以完成子任务。每个智能体都会配置特定角色，且只能访问完成该角色所需的工具或信息。

比如，我们可以创建一个 ResearchAgent（调研智能体），它能使用 “网页搜索工具”；再创建一个 SummaryAgent（摘要智能体），它能使用 “文本生成工具”。智能体会循环 “思考→行动”，直到完成自身负责的子任务。由于职责聚焦，它能遵循严格的提示格式或协议（通常由框架定义），确保行为安全、不偏离任务。

4.2 工具（Tool）

工具是智能体可调用的 “外部能力”，用于与现实世界交互或获取信息，比如网页搜索 API、计算器、数据库查询接口、发邮件函数等。在多智能体模式中，工具是智能体可执行的特定行动，且每个智能体的工具集都与自身角色相关。

例如，调研智能体可能有 “网页搜索” 工具，摘要智能体可能有 “知识库查询” 工具。智能体的 ReAct 循环会包含：选择工具→ 给工具输入参数（如搜索关键词）→ 读取工具输出（观察结果）→ 指导下一步思考。这种结构化的工具调用方式，能让智能体的推理和行动更透明、可日志化（比如我们能看到它搜索了什么关键词、得到了什么结果）。

需要注意的是，LangChain 或 CrewAI 这类框架会定义工具接口，并要求智能体遵守格式（如工具输入必须是 JSON），以确保交互可靠。

4.3 协作组（Crew）

Crew 本质是 “协调器”—— 一个（代码中的）类，负责搭建多智能体工作流、管理执行顺序。如果说每个智能体是团队成员，Crew 就是 “团队经理”，掌握整体计划。

在 “顺序流水线” 中，Crew 会把初始输入传给第一个智能体，再把它的输出传给第二个，直到最后一个智能体生成答案。它会定义智能体的运行顺序（有时还会定义每个智能体对数据的具体处理任务）。比如用 CrewAI 库时，我们可以实例化一个 Crew(agents=[智能体1, 智能体2, ...], tasks=[任务1, 任务2, ...], process=Process.sequential)，然后调用 crew.kickoff() 让智能体按顺序运行。

Crew 还会处理协作细节，比如确保每个智能体拿到正确输入、收集或整合输出。在更复杂的场景中，协调器还能实现 “循环逻辑”（重复运行智能体或步骤直到满足条件）或 “分支逻辑”（根据条件选择调用哪个智能体）。

有些架构中，协调器本身也是一个智能体（常被称为 “管理智能体” 或 “监督智能体”），职责是给其他专业智能体分配任务。无论它是显式的类还是管理智能体，这个 “协调角色” 是让多个智能体形成 “统一系统” 而非 “孤立机器人集合” 的关键。

4.4 信息流转方式

多智能体流水线中，信息通常从一个智能体流向另一个。比如一个简单流程：智能体 A 收集数据→ 智能体 B 分析数据→ 智能体 C 撰写报告。Crew 会把初始查询传给智能体 A，A 用工具返回原始数据；数据传给 B，B 生成分析结果；结果再传给 C，C 输出最终报告。每个智能体只处理与自身任务相关的输入，无需关心整体任务 —— 这种 “顺序传递” 就是多智能体模式的核心：多个 “专精型” AI 智能体串联，输出依次传递，直至完成目标。

五、从零实现多智能体系统

前面我们已经了解了多智能体系统在模块化、清晰度和可解释性上的优势。现在，我们动手从零实现一个多智能体系统，不依赖任何外部编排库（如 LangChain 或 CrewAI）。

如前所述，系统将基于三个核心抽象类构建，下面我们逐一详解每个类的原理和实现思路（您可直接下载文末代码使用）：

5.1 工具类（Tool）

Tool 类会封装实际功能（如新闻搜索、文本摘要、统计计算），并以 “智能体可识别、可验证、可调用” 的方式暴露这些功能。每个工具包含：

• 解析后的函数签名（让智能体知道工具的输入要求）；
• 自动输入验证和类型转换（确保智能体传入的参数合法）；
• 标准化调用接口（让智能体调用工具的方式统一）。

通过这种设计，智能体无需硬编码函数调用，就能自主判断 “有哪些工具可用”“如何使用工具”。

5.2 智能体类（Agent）

Agent 类代表单个 AI 智能体，具备以下能力：

• 通过 ReAct 循环思考任务；
• 调用工具与环境交互；
• 将输出传递给下游依赖的智能体。

每个智能体都有独特的 “背景设定、任务目标、输出要求和工具集”，模块化和角色特异性极强。智能体还能定义依赖关系（如 “智能体 A 必须在智能体 B 之前运行”）。内部而言，每个智能体由 ReactAgent 包装器驱动 —— 通过语言模型处理推理循环。

5.3 协作组类（Crew）

Crew 类是 “粘合剂”，负责协调所有组件，主要管理：

• 智能体注册（将智能体加入系统）；
• 依赖解析（用拓扑排序确保智能体按依赖顺序运行）；
• 有序执行（根据依赖关系安排智能体的运行顺序）。

接下来的章节中，我们会详细拆解每个类的实现细节，理解它们的工作原理，以及如何组合成完整的多智能体系统。首先，我们从 Tool 类开始。

六、详细实现：工具类（Tool）

工具是智能体与外部世界交互的 “手”，我们需要让工具满足两个核心要求：智能体能看懂怎么用、调用后能返回可靠结果。下面从设计思路到代码实现，一步步拆解 Tool 类。

6.1 设计核心：让智能体 “清晰认知工具”

智能体没办法直接 “读懂” Python 函数，所以 Tool 类需要把工具的功能、参数格式，转换成自然语言描述 + 结构化签名 —— 比如告诉智能体 “这个工具叫‘新闻搜索’，需要传入‘关键词’和‘时间范围’两个参数，能返回最近相关新闻列表”。

同时，为了避免智能体传错参数（比如把 “时间范围” 写成 “2025” 而不是 “2025-01-01 至 2025-01-10”），Tool 类还要包含输入验证逻辑，自动检查参数合法性，不合法就返回错误提示，让智能体修正后再调用。

6.2 代码实现：基础 Tool 类

我们用 Python 实现一个通用 Tool 类，后续所有具体工具（如新闻搜索、文本摘要）都可以继承它，不用重复写基础逻辑。

from pydantic import BaseModel, ValidationError

有了基础 Tool 类，我们可以快速创建实际能用的工具。比如做一个 “新闻搜索工具”，调用公开的新闻 API（这里用模拟函数演示，实际项目可替换成真实 API）。

from pydantic import Field

七、详细实现：智能体类（Agent）

智能体是 “思考 + 行动” 的主体，核心是ReAct 循环：拿到输入→思考 “该做什么”→决定 “调用工具还是直接输出”→执行→根据结果继续思考，直到完成子任务。

下面我们实现的 Agent 类，会包含 “接收上下文”“生成思考过程”“调用工具”“输出结果” 四个核心能力，并且严格绑定自己的工具集（避免越权调用）。

7.1 设计核心：让智能体 “有角色、会思考、能行动”

1. 角色绑定

   ：每个智能体有明确的 “角色描述”（比如 “新闻调研智能体，负责收集指定主题的最新新闻”），确保思考不偏离职责；

2. 工具限制

   ：智能体只能调用自己被分配的工具，不能用其他工具（比如 “调研智能体” 不能用 “报告生成工具”）；

3. 思考透明

   ：强制智能体输出 “思考过程”（比如 “用户需要 AI 多智能体的最新动态，我应该先调用新闻搜索工具，关键词设为‘AI 多智能体’，时间范围选最近 10 天”），方便调试和追踪；

4. 循环终止

   ：智能体要能判断 “什么时候该停止”（比如 “已经拿到 5 条新闻，足够生成摘要，不需要再搜索了”），避免无限循环。

7.2 代码实现：基础 Agent 类

这里我们用 OpenAI 的 API 作为大模型后端（需要您自己准备 API Key），也可以替换成 Ollama 调用本地模型（修改 generate_thought 方法即可）。

import openai

八、 详细实现：协作组类（Crew）

有了工具和智能体，还需要一个 “协调者” 来管理它们的依赖关系和运行顺序 —— 这就是 Crew 类的作用。比如 “先让调研智能体收集新闻，再让摘要智能体生成总结”，Crew 会确保这个顺序不混乱，还能处理 “某个智能体失败后是否重试” 等逻辑。

8.1 设计核心：让多智能体 “有序协作”

1. 依赖管理

   ：支持智能体间的依赖设置（如 “摘要智能体” 依赖 “调研智能体” 的输出），用拓扑排序确保先运行被依赖的智能体；

2. 顺序执行

   ：按依赖关系依次运行智能体，把前一个智能体的输出作为后一个的输入；

3. 错误处理

   ：某个智能体失败时，可选择 “终止流程” 或 “跳过该智能体”（根据任务重要性配置）；

4. 结果汇总

   ：收集所有智能体的输出，生成最终的整体结果，方便用户查看。

8.2 代码实现：基础 Crew 类

from typing importList, Dict, Optional, Tuple

九、完整实战：多智能体系统运行效果

我们以 “收集 AI 多智能体新闻并总结” 为例，看看整个系统的运行流程和输出结果：

9.1 运行流程（按协作组顺序）

1. 第一步：运行 NewsResearchAgent（调研智能体）

• 输入：用户需求 “收集 2025 年 1 月 1 日至 2025 年 1 月 10 日关于‘AI 多智能体’的 3 条最新新闻”；
• 思考过程：需要调用 news_search 工具，参数设为 keyword="AI多智能体"、time_range="2025-01-01至2025-01-10"、max_results=3；
• 工具输出：3 条模拟新闻（包含标题、摘要、来源）；
• 智能体输出：整理成列表格式的新闻汇总。

2. 第二步：运行 TextSummaryAgent（摘要智能体）

• 输入：原始需求 + 调研智能体的新闻列表；
• 思考过程：需要调用 text_summary 工具，参数设为 text=调研智能体输出、summary_length="中等"；
• 工具输出：中等长度的新闻摘要；
• 智能体输出：结构化的摘要文本。

9.2 最终输出示例

=== 协作组最终结果 ===

十、扩展与优化建议

目前实现的多智能体系统是基础版本，实际项目中可从以下方向扩展：

10.1 支持并行运行

当前 Crew 类是 “顺序执行”，可优化为 “支持并行”—— 比如多个无依赖的智能体（如 “查天气” 和 “找酒店”）可同时运行，提升效率。可基于 Python 的 concurrent.futures 实现并行逻辑。

10.2 增加动态任务分配

让协调器（Crew）具备 “根据前一个智能体的输出，动态选择下一个智能体” 的能力 —— 比如调研智能体发现 “新闻涉及金融场景”，就自动调用 “金融分析智能体”，而不是固定顺序。

10.3 强化日志与监控

增加更详细的日志（如工具调用耗时、智能体思考耗时），甚至对接监控工具（如 Prometheus），方便追踪系统性能瓶颈。

10.4 支持本地模型

将 OpenAI 替换为 Ollama + Llama3 或 Qwen（阿里通义千问开源版），实现 “完全本地部署”，适合对数据隐私敏感的场景（修改 Agent 类的 generate_thought 方法即可）。

10.5 增加安全防护

• 工具调用权限控制：给不同智能体分配不同权限（如 “调研智能体” 只能读工具，不能调用 “发邮件” 等写工具）；
• 输入输出过滤：防止智能体接收恶意输入（如攻击指令）或输出违规内容（如敏感信息）。

十一、总结

本文从零实现了一个多智能体系统，核心是三个模块：

• Tool 类

  ：封装外部功能，让智能体能安全、规范地调用；

• Agent 类

  ：实现 ReAct 循环，让智能体 “会思考、能行动”，且聚焦自身角色；

• Crew 类

  ：通过拓扑排序管理依赖，让多智能体 “有序协作”。

这个系统的优势在于模块化强（修改一个智能体不影响整体）、可解释性高（每个步骤都有日志）、易扩展（新增工具或智能体只需继承基础类）。

无论是处理 “复杂任务拆解”“多场景协作”，还是 “提升 AI 系统可靠性”，多智能体模式都比单智能体更有优势。后续可基于这个基础框架，根据实际需求（如金融分析、医疗诊断、教育辅导）扩展专属的智能体和工具，实现更复杂的 AI 应用。

十二、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

01.大模型风口已至：月薪30K+的AI岗正在批量诞生

2025年大模型应用呈现爆发式增长，根据工信部最新数据：

国内大模型相关岗位缺口达47万

初级工程师平均薪资28K（数据来源：BOSS直聘报告）

70%企业存在"能用模型不会调优"的痛点

真实案例：某二本机械专业学员，通过4个月系统学习，成功拿到某AI医疗公司大模型优化岗offer，薪资直接翻3倍！

02.大模型 AI 学习和面试资料

1️⃣ 提示词工程：把ChatGPT从玩具变成生产工具
2️⃣ RAG系统：让大模型精准输出行业知识
3️⃣ 智能体开发：用AutoGPT打造24小时数字员工

📦熬了三个大夜整理的《AI进化工具包》送你：
✔️ 大厂内部LLM落地手册（含58个真实案例）
✔️ 提示词设计模板库（覆盖12大应用场景）
✔️ 私藏学习路径图（0基础到项目实战仅需90天）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】