在 LangGraph 中基于结构化数据源构建
在 LangGraph 中构建不同的 agent 系统 | Image by author
对于希望构建不同智能体系统的开发者而言，一个有效的切入点是深入比较单智能体工作流与多智能体工作流，这本质上是评估系统设计的灵活性与可控性之间的权衡。
本文旨在阐明 Agentic AI 的核心概念，并演示如何利用 LangGraph 和 LangSmith Studio 来构建智能体系统。
我们将通过实现两种不同架构的研究员智能体，来对比其性能与结果，从而判断哪种架构更适合特定场景。
本文涉及的代码与资源可在此处获取。运行过程基本免费，主要消耗来自 OpenAI 的 API 调用。
使用场景
为了进行具体对比，我们将构建一个科技研究智能体。其核心功能是识别过去一天或一周内的科技趋势，并判断哪些信息值得形成报告。
在信息汇总与研究收集这类任务上，Agentic AI 展现出显著优势。
本文将利用一个 API 来汇总科技领域的热门讨论与分享内容，然后让智能体系统基于预设的用户画像，评估信息的重要性并生成摘要。
数据源提供了结构化数据，agentic 系统可以据此工作
该智能体不会在输出中直接添加引用，我们的关注点在于：对比仅设置单智能体与设置多个协同智能体两种方案下，系统所能覆盖的信息广度与深度。
因此，本文的重点在于智能体系统的构建方法论，而非数据源本身。
我们的多智能体系统在 LangSmith Studio 中的样子，运行需要几分钟
我们将首先构建一个简单的单智能体系统（该智能体可访问多个 API 端点），随后将其扩展为一个包含多个团队、更多工具的复杂系统，以对比两者在输出质量上的差异。
在开始构建之前，将对核心概念进行简要回顾。如果您已熟悉智能体系统，可以跳过此部分。
Agentic AI 与 LLMs
Agentic AI 的核心是利用自然语言进行编程。不同于编写固定、明确的代码逻辑，它通过自然语言指令驱动大语言模型（LLMs）来负责数据路由和动作调用，从而实现自动化。
在工作流中使用自然语言并非全新概念，我们已使用自然语言处理技术进行数据抽取和处理多年。
新的突破在于，我们现在能够赋予语言模型更高的自由度，使其能够处理模糊性并做出动态决策。
然而，LLMs 能够理解复杂语言，并不意味着它们天生具备事实核查或保证数据完整性的能力。
我更倾向于将它们视为一个沟通层（至少在现阶段），位于结构化系统与现有数据源之上。
我常向非技术背景的同事这样解释：它们有点像我们人类。如果没有干净、结构化的数据，我们也会开始“编造”。LLMs 也是如此。
因此，就像人类一样，它们会尽力而为。若想获得更优的输出，就必须为它们构建能够提供可靠数据或可操作系统的环境。
所以，在 Agentic 系统中，我们会为 LLMs 接入各种数据源、工具和系统。
当然，即便我们_能够_在更多场景中使用更大的模型，也不意味着我们总是_应该_这么做。LLMs 在处理细腻的自然语言理解任务时表现出色，例如客服、研究或人机协同场景。
但对于高度结构化的任务（例如提取特定数字并发送到指定位置），应优先考虑传统方法与自动化脚本。
LLMs 并不比计算器更擅长算术。因此，正确的做法不是让 LLM 直接计算，而是赋予 LLM 调用计算器工具的能力。
因此，只要工作流的某些部分_可以_通过程序化方式构建，这通常是更优的选择。
尽管如此，LLMs 擅长适应现实世界中“不干净”的输入和理解模糊指令，将程序化方法与 LLMs 的灵活性相结合，是构建强大系统的有效途径。
如果您是初学者，对此仍感困惑，可以参考更详细的入门资料。当我们开始动手搭建时，概念会变得更加清晰。
Agentic 框架与 LangGraph
许多开发者在初次构建智能体时，会直接选择 CrewAI 或 AutoGen 等框架，但实际上我们有多种选择。
LangGraph 是一个技术性更强、也更复杂的框架，它是基于 LangChain 的图式框架。因其强大的表达能力和灵活性，深受许多开发者偏爱，值得深入学习。
虽然我个人目前更倾向于无框架的定制化方案，但会借鉴各框架中的优秀设计思想，因此学习它们依然具有很高价值。
不过，LangGraph 包含不少抽象层，您可能会希望重构部分代码以获得更好的控制力和可理解性。
本文不会深入展开 LangGraph 的所有细节，但为需要复习的读者准备了单独的简明指南。
在本用例中，您甚至可以在不编写代码的情况下运行工作流，但如果您旨在学习，也可以借此机会理解 LangGraph 的工作机制。
单智能体 vs 多智能体系统
在开始构建之前，先明确单智能体与多智能体系统的核心差异。
如果您围绕一个 LLM 并为其配备一系列工具来构建系统，这就是一个单智能体工作流。它的优势在于速度快，对于 Agentic AI 新手而言，可能会认为模型“应该能自行处理所有事情”。
但归根结底，这些工作流也是一种系统设计。
就像任何软件项目一样，您需要规划流程、定义步骤、组织逻辑，并决定每个部分的行为方式。
这就是多智能体工作流的用武之地。
并非所有多智能体系统都是层级式或线性的，有些是协作式的。协作式工作流通常更灵活，但在当前的技术能力下，这类工作流相对更难精确控制。
不过，协作式工作流同样会将不同功能拆解为独立的模块。
当您处于试验和探索阶段时，协作式工作流非常合适，但它不一定能提供完成实际生产任务所需的高度精确性。
在本文将要搭建的工作流中，我们已经明确知道如何使用这些 APIs，因此需要引导系统以正确的方式使用它们。
我们将对比一个单智能体设置与一个层级式多智能体系统：后者由一个主控智能体将任务分发给一个小型团队。通过实践，您将能直观看到它们在行为上的差异。
构建单智能体
构建单智能体时，我们使用一个 LLM、一个系统提示词，并赋予其访问若干工具的权限。
智能体将基于用户的问题，自行决定使用哪个工具、在何时使用。
单智能体面临的主要挑战在于“可控性”。
无论系统提示词写得多么详细，模型都可能不按预期执行（即使在更受控的环境中也是如此）。如果我们提供过多的工具或选项，它很可能不会全部使用，甚至可能用错。
仅通过指令来强制其“照做”的空间是有限的。
为了说明这一点，我们将构建一个科技新闻智能体，它能访问多个基于自定义数据的 API 端点，并且工具中包含多种可选参数。
由智能体自行决定使用多少工具、以及如何组织最终的摘要。
请注意，我是使用 LangGraph 来构建这些工作流的。这里不会深入讲解 LangGraph 本身，如果您想学习基础知识以便修改代码，可以参考这份指南。
您可以在此处找到单智能体工作流的代码。要运行它，您需要一个 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 key。这个单智能体我们将使用 Gemini 模型。
GOOGLE_API_KEY=KEY_HERE
然后创建 Python 虚拟环境：
python3.11 -m venv venv_py311
source venv_py311/bin/activate
安装 LangGraph CLI：
pip install -U "langgraph-cli[inmem]"
my_agent 文件夹下的 requirements.txt 也需要安装：
pip install -r my_agent/requirements.txt
安装完成后，您可以在 LangSmith Studio 中打开并运行这个单智能体工作流：
langgraph dev
此命令会自动在浏览器中打开 LangSmith Studio。
接下来需要创建一个助手（Assistant），默认选项是 Anthropic 模型，而我们的智能体使用 Gemini。
点击左下角按钮管理助手。
请确保创建一个模型为“gemini”的新 assistant，并点击“create new assistant” | Image by author
会出现类似上图的弹窗。将模型设置为“gemini”，然后点击“Create New Assistant”。
回到主界面后，您可以设置起始消息。
例如，告诉智能体您的身份、以及希望获取每日/每周/每月的信息。
{"messages": ["I'm a tech investor, give me what's up in tech for the last week"]}
在 LangSmith Studio 中的显示效果如下：
点击提交，结果会很快返回，因为我们是单智能体。
它会先在 3 个不同类别下检查一些趋势关键词，然后针对其中几个关键词进一步查看相关的讨论内容。
如果您想了解这些工具是如何创建的，可以查看代码，其本质就是封装了 API 调用。
最终输出结果类似如下（具体内容取决于您运行的时间，信息每天都会变化）：
Here's a summary of the trending tech topics from the past week:
Companies:
Apple: Apple is facing scrutiny over its App Store practices, including a UK monopoly case and concerns about attention to detail. There are also reports of reduced iPhone Air production and its potential move to include ads in the Maps app.
Meta: Meta is undergoing layoffs in its AI division, which has generated negative sentiment. There is also discussion around a mod that disables the recording light on Meta's Ray-Ban glasses, raising privacy concerns.
GM: GM's decision to ditch Apple CarPlay and Android Auto in future vehicles has sparked controversy and negative reactions from users.
Samsung: Samsung is planning to introduce ads on its smart fridges, drawing criticism. There's also news about the upcoming Galaxy XR event and a new chief design officer.
[...]
如果您不想自己运行智能体，可以在此处查看完整结果示例。结果尚可，但您会发现其信息挖掘的深度有限。
当然，我们可以继续向它追问，但可以想象，如果任务更加复杂，它可能会在工作流中开始走捷径。
关键在于：智能体系统不会“自动按照我们脑海中的完美方式思考”，我们必须通过精心设计的工作流来编排它，使其按照我们的意图工作。
在有人类参与循环（Human-in-the-loop）的场景下，例如问答对话，单智能体可以工作得很好。
但在深度研究场景中，我们需要更复杂的系统。这可以通过工作流式（每个节点负责一项明确任务）实现，也可以尝试构建层级式系统，让每个智能体（或团队）对特定子任务负责。
测试多智能体工作流
构建多智能体系统远比为一个单智能体配备多个工具要复杂。
您需要在此之前仔细规划系统架构，并明确数据在不同智能体之间如何流动。
这里我搭建的多智能体工作流使用了两个团队（研究团队和编辑团队），每个团队下包含若干智能体。
我们多智能体系统中的团队/agents 架构示意 | Image by author
每个智能体只能访问特定的一小组工具（数量不宜过多），并拥有清晰、专一的指令。
这种对每个智能体职责的明确收敛，对于能力相对较弱的LLM（例如Gemini Flash 2.0）尤为有益。不过，在需要更高理解与概括能力的环节，我仍然倾向于使用更强的模型。在本例中，我们使用GPT-5作为专门的“摘要智能体”。
我们引入了一些新机制来优化协作。例如，一个作为共享空间的“研究便笺”，允许一个团队写入研究发现，供另一个团队读取。最终，摘要智能体会读取所有经过研究和编辑的内容来生成报告。
作为“研究便笺”的替代方案，也可以在状态中为每个团队或智能体设置独立的“草稿区”来存储短期记忆。但这要求我们仔细设计每个智能体应记住哪些信息。
此外，我决定预先提供更丰富的工具集，让智能体在初期就能获得更充实的数据，从而避免对每个关键词都进行独立的网络检索。这里的关键在于：如果能用常规编程逻辑预先处理或获取数据，就优先使用它，这通常比依赖LLM反复调用工具更高效。
运行多智能体工作流
准备工作与单智能体类似。首先，在项目根目录的 .env 文件中配置必要的API密钥：
GOOGLE_API_KEY=YOUR_KEY_HERE
OPENAI_API_KEY=YOUR_KEY_HERE
ANTHROPIC_API_KEY=YOUR_KEY_HERE
其中，ANTHROPIC_API_KEY 仅在需要尝试更换为Claude模型作为智能体时才需设置。如果未设置且工作流配置中包含了Anthropic模型，可能会报错；此时可以创建一个仅使用Gemini模型的助手配置来避免。
环境配置完成后，安装依赖并启动LangGraph开发服务器：
langgraph dev
启动后，你将在浏览器中看到可视化的工作流图。与单智能体系统相比，多智能体工作流的架构明显复杂得多。
一个主要区别在于，多智能体系统中的路由（边）是动态决定的，而非像单智能体那样手动静态配置，这从代码层面看也会更加复杂。
运行时，同样需要向工作流发送一个初始消息。本次示例中，我使用了更详细的提示词来引导任务，你可以尝试简化它以观察效果：
{"messages": [{"role": "user", "content": "I‘m an investor and I‘m interested in getting an update for what has happened within the week in tech, and what people are talking about (this means categories like companies, people, websites and subjects are interesting). Please also track these specific keywords: AI, Google, Microsoft, and Large Language Models"}]}
为了进行公平的性能对比，建议使用与测试单智能体时相同或相似的提示词。
启动运行后，由于多智能体系统涉及更复杂的工具调用与协作，处理时间会显著更长，可能需要数分钟。
例如，“趋势关键词智能体”可用的工具比单智能体版本更复杂，因此其单个响应也较慢。总体而言，这类多步骤、多智能体的研究系统需要时间来收集和处理信息，这是其架构特点决定的。
运行结束后，你可以在项目根目录下的 notes 文件夹中找到各智能体收集的中间笔记。最终的摘要报告会整合所有这些信息。
以下是一份运行结果摘要的示例片段：
FINAL RESEARCH SUMMARY
Tech Research Summary
Weekly Tech Investor Brief (week ending Oct 28, 2025)
Key Happenings
Oct 27: ICE signed a $5.7M contract for AI-powered social media surveillance (Reddit: r/technology)
Oct 27: "Windows 10 deadline boosts Mac sales" thread trended, highlighting OS/device churn (Hacker News)
Oct 26: Microsoft 365 Copilot arbitrary data exfiltration via Mermaid diagrams disclosed (Hacker News)
Oct 26: "It‘s insulting to read AI-generated blog posts" topped HN, reflecting AI content fatigue (Hacker News)
[...]
Why It Matters
AI demand is moving from hype to operational scrutiny. Government adoption (e.g., ICE‘s Oct 27 contract) signals durable budgets for AI monitoring and analytics, but also heightens regulatory and civil liberties overhang—an opening for compliant AI, privacy-tech, and auditing vendors...
Platform competition intensified. Google‘s Oct 23 Earth AI updates and Google AI Studio "vibe coding" push indicate a bid to reduce time-to-production for AI apps...
Consumer backlash is shaping product roadmaps. GM‘s removal of CarPlay/Android Auto is trending because it challenges perceived table-stakes features, risking brand equity and sales...
[...]
请注意，生成的新闻内容会因运行时间不同而变化。此示例报告基于10月28日的运行结果。
关于多智能体系统与单智能体系统在过程控制、输出质量与复杂度上的权衡，留待读者自行评估。
总结与优化方向
本次实验的成功在很大程度上依赖于使用了质量较高、结构相对清晰的数据源。如果没有这一点，就需要引入大量额外的错误处理逻辑，这会使系统运行更慢。
干净、结构化的数据是关键。 缺乏这一点，LLM的能力将大打折扣。即便数据可靠，系统也远非完美，仍需持续优化，例如：
* 查询解析：将用户查询更结构化地解析为子任务。
* 智能体约束：为智能体添加“护栏”，确保其按预期使用工具。
* 摘要优化：提升最终摘要的有效性，确保研究文档简洁、切题。
* 错误处理：实现更健壮的错误处理与重试机制。
* 记忆管理：引入“长期记忆”机制，以更好地理解用户的历史偏好和真实需求。在优化性能与成本时，对状态（短期记忆）的管理尤为重要。当前系统简单地将所有消息存入状态供所有智能体访问，这并非最佳实践。理想情况下，应按团队或角色隔离状态。在本案例中尚未实现，但你可以尝试在状态模式中引入独立的“草稿区”来隔离各团队的知识。
希望通过这个从单智能体到多智能体的构建与对比过程，能帮助你更具体地理解不同智能体架构所能带来的结果与挑战。
关注“鲸栖”小程序，掌握最新AI资讯
本文由鲸栖原创发布，未经许可，请勿转载。转载请注明出处：http://www.itsolotime.com/archives/13732