智能体人工智能（Agentic AI）：单智能体系统 vs 多智能体系统

智能体人工智能（Agentic AI）：单智能体系统 vs 多智能体系统

LangGraph中不同智能体系统的构建示意图 |【AI大模型教程】 如果你刚开始构建各类智能体系统，那么一个值得关注的方向便是单智能体工作流与多智能体工作流的差异，或是灵活型系统与受控型系统在使用上的区别。

本文将帮助你理解什么是智能体人工智能（Agentic AI），以及如何借助LangGraph和LangSmith Studio构建智能体系统。

我们将采用两种不同的架构搭建一个科研智能体，通过对比结果来分析哪种架构的表现更优。

你可以在此处获取我们将使用的相关资源。除部分OpenAI令牌费用外，运行这些系统基本是免费的。

需要说明的是，如果你想了解目前主流的开源框架概况，可参考这篇文章。

应用场景

为了让内容更具体，我们将构建一个科技领域的科研智能体，它能够获取昨日或过去一周的科技趋势信息，并筛选出具有新闻价值的内容。

在总结与收集研究资料这类场景中，智能体人工智能的优势尤为突出。

本文将使用一个API来收集科技领域的热门讨论与分享内容，智能体系统需根据预设的用户画像判断信息的重要性，并为我们生成总结报告。

MUw7xC

该数据源为智能体系统提供了可处理的结构化数据
需要注意的是，该智能体不会在文本中添加引用标注，我们重点关注的是：仅部署单智能体时系统的信息覆盖范围，与部署多个协同工作的智能体时的信息覆盖范围存在何种差异。

因此，本文的核心并非数据源本身，而是智能体系统的构建与运行逻辑。

dvBaIo

多智能体系统在LangSmith Studio中的运行示例（完成需耗时数分钟）| 图片由作者提供
我们将先搭建一个简单的智能体系统，使其能够访问多个API接口；之后再扩展系统架构，引入多个智能体团队和更全面的工具，以此对比两种架构在输出质量上的差异。

在开始之前，我会为初学者梳理一些基础概念。如果你已熟悉智能体系统相关知识，可以直接跳过前面的部分。

智能体人工智能（Agentic AI）与大语言模型（LLMs）

智能体人工智能本质上是通过自然语言进行编程。它不再依赖僵化、明确的代码，而是通过自然语言指令引导大语言模型（LLMs）实现数据路由与任务执行，从而完成自动化流程。

在工作流中使用自然语言并非全新概念——多年来，我们一直借助自然语言处理（NLP）技术提取和处理数据。

而如今的突破在于，我们能够给予语言模型更高的自主性，使其能够处理模糊信息并动态做出决策。

但需要注意的是，大语言模型能够理解复杂的语言并不意味着它们天生具备事实验证能力或数据完整性维护能力。

在我看来，至少目前而言，大语言模型更像是一个通信层，搭建在结构化系统与现有数据源之上。

向非技术人员解释时，我通常会这样比喻：大语言模型的工作方式与人类有相似之处。如果无法获取清晰、结构化的数据，人类会开始主观臆断，大语言模型亦是如此。

因此，和人类一样，大语言模型会基于现有资源尽力完成任务。若想获得更优的输出结果，我们需要构建能够为其提供可靠数据或工作支撑的系统。

基于此，在智能体系统中，我们会集成多种机制，让大语言模型能够与不同的数据源、工具及系统进行交互。

不过，即便我们能够在更多场景中使用这些大型模型，也不意味着所有场景都适合使用它们。大语言模型的优势在于解读复杂的自然语言，例如客户服务、科研探索或人机协同等场景。

但对于结构化任务（如提取数值并传输至指定位置），传统的处理方法与自动化技术仍是更优选择。

大语言模型在数学计算上并不比计算器更出色。因此，与其让大语言模型直接进行计算，不如为其配备计算器工具并授予访问权限。

由此可见，只要能够通过编程方式构建工作流的部分模块，这种方式通常仍是更可靠的选择。

尽管如此，大语言模型在适应复杂的真实世界输入、解读模糊指令方面表现出色，因此将传统技术与大语言模型结合，往往能构建出更高效的系统。

如果你是该领域的新手，仍有疑问，可以浏览我的其他文章，其中有更详细的解释。在后续的实际构建过程中，你或许会有更清晰的理解。

智能体框架与LangGraph

我知道很多人在构建第一个智能体时会直接选择CrewAI或AutoGen，但实际上我们有更多选择。本文将为你介绍LangGraph框架。

LangGraph是基于LangChain构建的图结构框架。与其他框架相比，它的技术门槛更高，复杂度也更大。但由于许多开发者将其作为首选框架，因此至少尝试用它构建一个简单系统是很有必要的。

不过，LangGraph包含较多抽象概念，有时你可能需要重新构建部分模块，才能更好地控制和理解整个系统。

本文不会深入探讨LangGraph的细节，因此我专门为需要回顾基础的读者准备了一份快速指南。

如果你想了解主流框架的概况，可以参考这篇文章，该文章的阅读量已超过10万次。

需要说明的是，如今我在构建系统时更倾向于不使用任何框架，但会借鉴不同框架中的优秀设计，因此学习框架的使用方法仍然具有价值。

就本次的应用场景而言，你无需编写代码即可运行工作流；但如果希望深入学习，了解LangGraph的工作原理会更有帮助。

单智能体系统 vs 多智能体系统

在开始构建之前，我们先来梳理单智能体系统与多智能体系统的核心差异。

若你围绕一个大语言模型构建系统，并为其配备多个可用工具，那么你所搭建的就是单智能体工作流。这种系统运行速度快，对于智能体人工智能的新手来说，可能会觉得模型能够自主完成所有决策。

但实际上，这类工作流本质上仍是系统设计的一种形式。

与所有软件项目一样，你需要规划流程、定义步骤、构建逻辑结构，并确定每个模块的行为规则。

这正是多智能体工作流的价值所在。

不过，并非所有多智能体系统都是层级式或线性的，部分系统采用协同式架构。协同式工作流通常属于更灵活的设计方案，但就目前的技术能力而言，这类系统的操作难度相对较大。

尽管如此，协同式工作流仍能将不同功能拆分为独立模块。

在初步探索阶段，协同式工作流是不错的选择，但对于需要高精度执行的实际任务，它们往往难以满足要求。

在本次将构建的工作流中，我已明确API的使用方式，因此我的核心任务是引导系统正确调用这些API。

接下来，我们将对比单智能体系统与层级式多智能体系统的表现——在层级式系统中，一个主导智能体负责向小团队分配任务，通过实际运行你可以清晰看到两种系统的差异。

单智能体系统的构建

构建单智能体系统时，我们会使用一个大语言模型和对应的系统提示词，并为其配备多个工具。

智能体需根据用户的问题，自主决定使用哪些工具以及何时使用这些工具。

qU7N8J

单智能体系统的核心挑战在于控制。

无论系统提示词多么详细，模型仍有可能不遵循指令（即便在受控环境中也可能出现这种情况）。如果为其提供过多工具或选项，模型很可能无法充分利用所有工具，甚至选择错误的工具。

我们在指令中设置的规则，对模型行为的约束能力是有限的。

为了更直观地展示这一点，我们将构建一个科技新闻智能体，它能够访问多个API接口，这些接口包含自定义数据，且工具中设有多个参数选项。

智能体需自主决定使用多少个API接口，以及如何构建最终的总结报告。

需要提醒的是，这些工作流均基于LangGraph构建。本文不会深入讲解LangGraph，如果你希望学习基础操作以修改代码，可以参考这份指南（发布于2025年4月）。

你可以在此处获取单智能体工作流的相关资源。若要运行该系统，你需要拥有LangSmith的账号（以访问LangSmith Studio），并安装Python 3环境。

登录账号后，你可以将单智能体工作流克隆到本地设备。

其文件结构如下：

single-agent-workflow/├─ my_agent/│  ├─ agent.py│  ├─ requirements.txt│  ├─ utils/│     ├─ nodes.py│     ├─ state.py│     └─ tools.py├─ README.md  ├─ langgraph.json

创建一个.env文件，并添加Google API密钥（本单智能体系统将使用Gemini模型）：

GOOGLE_API_KEY=你的密钥

随后创建并激活虚拟环境：

python3.11 -m venv venv_py311source venv_py311/bin/activate

安装LangGraph命令行工具：

pip install -U "langgraph-cli[inmem]"

在my_agent文件夹中可找到依赖列表，执行以下命令安装依赖：

pip install -r my_agent/requirements.txt

依赖安装完成后，在LangSmith Studio中打开单智能体工作流：

langgraph dev

该命令将自动打开LangSmith Studio（此前名为LangGraph Studio）。

此处需要特别注意：你需要手动设置辅助工具（Assistant），因为默认配置使用的是Anthropic模型，而我们的智能体使用的是Gemini模型。

点击左下角的按钮，进入辅助工具管理界面。

确保创建一个名为“gemini”的新辅助工具，并点击“create new assistant” | 图片由作者提供
此时会弹出上述弹窗，将模型设置为“gemini”，然后点击“Create New Assistant”。

返回主界面后，你可以设置启动消息。

在启动消息中，你可以告知智能体你的需求，例如你的身份以及需要获取的信息周期（每日、每周或每月），示例如下：

{"messages": ["我是一名科技投资者，请为我提供过去一周的科技领域动态"]}

在LangSmith Studio中，其显示效果如下：

点击提交后，由于是单智能体系统，结果会快速生成。

该智能体首先会在3个不同类别中查询热门关键词，然后针对部分热门关键词查看相关讨论内容。

如果你想了解这些工具的构建方式，可以查看代码细节，其核心是通过API实现功能。

最终输出结果如下（需注意：结果会随运行时间不同而变化，因为信息具有时效性）：

以下是过去一周科技领域热门话题的总结：

企业动态：

• • 苹果（Apple）：其App Store运营模式正面临审查，包括英国的垄断诉讼以及外界对其细节把控能力的质疑。另有报道称，iPhone Air的产量将缩减，且苹果可能计划在地图应用（Maps）中植入广告。
• • 元宇宙（Meta）：其AI部门正在进行裁员，这引发了负面舆论。此外，有消息称有人开发出可关闭Meta Ray-Ban智能眼镜录音指示灯的模块，这一事件引发了隐私担忧。
• • 通用汽车（GM）：该公司决定在未来车型中取消对Apple CarPlay和Android Auto的支持，这一决策引发了争议和用户的负面反馈。
• • 三星（Samsung）：计划在智能冰箱中添加广告功能，此举遭到批评。另有消息透露，三星即将举办Galaxy XR发布会，并任命了新的首席设计官。
  [...]

若你不想启动智能体也能查看完整总结，可以在此处获取。总体而言，该结果基本满足需求，但显然不够深入。

当然，你可以进一步向智能体提问以获取更多信息，但不难想象，面对更复杂的需求时，系统在工作流中会出现简化步骤的情况。

关键在于，智能体系统并不会完全按照我们的预期思考，因此需要我们进行实际的协调与管控，以确保系统完成预设任务。

如果存在人工介入环节（如问答场景），这种单智能体系统的表现是不错的。

例如，当人类提出明确需求，智能体仅需获取对应信息时，单智能体系统能够高效完成任务。

但对于深度科研任务，我们需要构建更复杂的系统——既可以采用“分工明确”的工作流设计（每个模块负责单一任务），也可以尝试搭建层级式系统（由一个智能体或团队负责特定环节）。

多智能体工作流的测试

构建多智能体系统比搭建“单智能体+多工具”的系统要复杂得多。

要实现这一目标，你需要提前仔细规划系统架构，并明确智能体之间的数据流转方式。

本文将搭建的多智能体工作流包含两个不同的团队（科研团队和编辑团队），每个团队下设有多个智能体。

按回车键或点击即可查看完整尺寸图片

多智能体系统中的团队/智能体架构示例 | 图片由作者提供
每个智能体仅能访问特定的工具集（数量不多），且都有清晰的指令。

这种“限定职责范围”的设计，在使用低级别大语言模型（如Gemini Flash 2.0）时优势明显；不过，我通常会选择更高级的大语言模型来完成总结任务（本文中，我们将使用GPT-5作为总结智能体）。

我们还将引入一些新工具，例如“研究笔记板”——它相当于一个共享空间，科研团队可在其中记录研究成果，编辑团队则可从中获取信息。最后，由一个大语言模型整合所有研究与编辑内容，生成最终总结。

除了研究笔记板，另一种方案是将数据存储在“临时记事本”（scratchpad）中，为每个团队或智能体分配独立的短期记忆空间。但这种方案需要仔细规划每个智能体的记忆内容范围。

此外，我还对工具进行了优化，使其能预先提供更丰富的数据，这样智能体就无需为每个关键词单独获取来源信息。在这一过程中，我采用了常规的编程逻辑——因为这种场景适合传统编程实现。

需要牢记的关键原则：只要能用常规编程逻辑实现，就优先采用编程方式。

你可以在此处获取该工作流的相关资源。在加载系统前，请确保在.env文件中同时添加Google API密钥和OpenAI API密钥：

GOOGLE_API_KEY=你的密钥OPENAI_API_KEY=你的密钥ANTHROPIC_API_KEY=你的密钥

仅当你需要调整智能体配置（例如更换模型）时，才需要设置Anthropic API密钥；若未设置该密钥导致系统报错，只需将辅助工具配置为仅使用Gemini即可。

后续步骤与单智能体系统一致：创建虚拟环境、安装依赖，然后打开工作流：

langgraph dev

打开工作流后，你会发现其界面比单智能体系统复杂得多。

按回车键或点击即可查看完整尺寸图片

在该工作流中，路由（边）是动态配置的，而非像单智能体系统那样手动设置。若你查看代码，会发现其逻辑也更为复杂。

运行系统时，你需要像之前一样输入启动消息。

本文中，我会使用更详细的提示词（这在一定程度上算是“优化手段”，你也可以尝试更简洁的提示词）：

{"messages": ["{\"messages\": [\"我是一名投资者，希望了解过去一周科技领域的动态以及热门讨论话题（重点关注企业、人物、网站和主题等类别）。此外，请特别追踪以下关键词：人工智能（AI）、谷歌（Google）、微软（Microsoft）和大型语言模型（Large Language Models）\"]}"]}

建议保持与单智能体系统相同的输入内容，以便进行对比；当然，你也可以根据需求调整。

系统启动后，需要较长时间运行，你可以暂时离开，几分钟后再返回查看结果。

按回车键或点击即可查看完整尺寸图片

多智能体系统中，热门关键词智能体可访问的工具比单智能体系统更复杂，因此数据返回所需时间更长。

总体而言，这类系统需要一定时间来收集和处理信息，这是我们在使用过程中需要适应的特点。

后续你可以在根目录下的“notes”文件夹中查看系统收集的笔记，此处提供了一个示例供参考。

最终总结报告的格式如下：

最终研究总结

科技领域研究总结

科技投资者每周简报（截至2025年10月28日）

核心动态

• • 10月27日：美国移民与海关执法局（ICE）签署了一份价值570万美元的合同，用于采购AI驱动的社交媒体监控系统（来源：Reddit论坛r/technology板块）
• • 10月27日：“Windows 10终止支持推动Mac销量增长”的话题成为热门，反映出操作系统/设备的更新换代趋势（来源：Hacker News）
• • 10月26日：有消息披露，Microsoft 365 Copilot存在通过Mermaid图表实现任意数据泄露的漏洞（来源：Hacker News）
• • 10月26日：“阅读AI生成的博客文章令人不适”的话题登上Hacker News榜首，体现出人们对AI生成内容的厌倦情绪（来源：Hacker News）
  [...]

关键意义

1. 1. 人工智能需求从“炒作”转向“实际应用审查”：政府部门的采用（如10月27日ICE签署的合同）表明，AI监控与分析领域的预算具有持续性，但同时也加剧了监管与公民自由方面的顾虑——这为合规AI、隐私技术和审计供应商创造了机遇。企业对Microsoft 365 Copilot数据泄露事件及Teams考勤监控功能的讨论表明，短期内买家更关注安全性、治理能力和员工信任度，而非单纯的AI功能。
2. 2. 平台竞争加剧：谷歌在10月23日推出的Earth AI更新，以及Google AI Studio的“氛围编程”（vibe coding）功能，体现出其缩短AI应用开发周期的战略意图——这可能会推动云服务/第三方软件需求增长，并增强开发者粘性。与此同时，社区对开源和自托管技术栈的青睐（如ComfyUI的流行、S3兼容存储的讨论）反映出成本控制与数据自主权的需求，这对混合云供应商和开源核心企业具有重要意义。
3. 3. 消费者反对意见影响产品路线：通用汽车（GM）取消CarPlay/Android Auto支持的决策引发热议，因为该功能被视为用户的基本需求，这一决策可能损害品牌价值并影响销量。苹果计划在地图应用中添加广告、YouTube推出深度伪造内容应对措施等事件，反映出“商业化变现、安全性与用户体验”之间的普遍矛盾——在这些领域，差异化的政策与设计可能成为企业的竞争优势。
      [...]

若你不想运行系统也能查看完整总结，可以在此处获取。

显然，总结内容会随系统运行时间不同而变化。本文中的示例报告基于10月28日的运行结果生成。

至于两种系统的表现差异，以及复杂系统如何让我们更好地控制流程，相信你通过对比会有自己的判断。

结语

本文所使用的数据源质量较高。若缺乏优质数据源，你需要添加更多的错误处理机制，这会进一步降低系统运行速度。

清晰、结构化的数据是系统高效运行的关键。没有优质数据，大语言模型无法发挥最佳性能；即便有了可靠数据，系统也并非完美——你仍需对智能体进行优化，确保其按预期执行任务。

你可能已经注意到，该系统虽能正常运行，但仍有改进空间。例如：将用户查询解析为更结构化的格式、添加约束机制确保智能体始终使用指定工具、优化总结逻辑以保持研究文档的简洁性等。

我们还需要引入更完善的错误处理机制，或许还需添加“长期记忆”功能，以更好地理解用户的实际需求。状态（短期记忆）对于优化系统性能和控制成本尤为重要。

目前，我们将所有消息都存入状态，并允许所有智能体访问——这种方式并不理想。理想情况下，我们应在不同团队之间隔离状态。本文中我尚未实现这一功能，但你可以尝试在状态架构中添加“临时记事本”，以实现团队间的信息隔离。