从单体智能体到智能体网络：构建下一代AI应用的技术实践

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

如果你是一名开发者，最近可能被各种“AI Agent”和“大模型应用”刷屏，但内心却充满困惑：为什么除了ChatGPT和Copilot，我们似乎还没看到一个真正能像微信、淘宝那样改变我们数字生活的“AI超级应用”？为什么今天绝大多数AI应用，看起来都像是大模型能力的简单包装，或者一个更聪明的聊天机器人？

问题的核心，可能不在于模型不够强，而在于我们正处在一个错误的“范式”里。回顾历史，真正的颠覆性应用，从来不是诞生在“平台为王”的时代，而是诞生在“网络效应”爆发的节点。PC时代的Windows吞噬一切，应用只能在夹缝中生存；直到互联网出现，打破了单机的边界，才催生了谷歌、Facebook、微信这样的超级应用。

今天，以大模型为核心的AI浪潮，正重演着“Windows时代”的故事。OpenAI、Anthropic等巨头正在构建新的“通用计算平台”，它们不断扩展边界，将编码、搜索、图像生成等功能集成到基础模型中，让无数垂直AI应用变得脆弱不堪。AI时代的“天”，依然压得很低。

那么，属于AI的“网络时代”何时到来？答案很可能指向一个正在酝酿中的新范式：Agent Network（智能体网络）。这不是一个简单的API调用，而是一个由无数专业化、自治的AI智能体（Agent）通过标准化协议相互协作、竞争、交易而形成的M2M（机器对机器）网络。这将是继人际网络（H2H）、人机网络（H2M）之后的第三代网络形态。

本文将为你深入拆解这个正在发生的范式转移。我们不仅会探讨其背后的历史逻辑和商业判断，更重要的是，作为一名技术实践者，我会带你从零开始，动手搭建一个最简单的多Agent协作系统，并分析其核心的技术栈、通信协议和面临的工程挑战。你会看到，AI超级应用的基石，可能就藏在今天这些看似简陋的Agent框架代码之中。

1. 这篇文章真正要解决的问题：为什么今天的AI应用“不太行”？

几乎所有开发者都体验过GPT-4或Claude 3的强大，也尝试过基于它们API构建的各种应用。但一个普遍的共识是：大多数AI应用缺乏“护城河”。一个精心设计的提示词工程（Prompt Engineering）应用，可能因为大模型一次版本更新而效果大打折扣；一个解决特定领域问题的微调模型，也可能被通用大模型新推出的某个插件功能所替代。

这背后的根本原因，是当前AI应用的发展范式，本质上仍处于“单机时代”。

• 平台集中化：能力高度集中于少数几个基础大模型（如GPT-4、Claude、Gemini），它们扮演着类似当年Windows操作系统的角色，掌控着最核心的“计算”能力。
• 应用依附性：上层应用严重依赖底层模型的API，自身不产生独特的、不可替代的网络价值。它们更像是系统功能的“外挂”或“皮肤”。
• 价值天花板低：应用的价值上限被单一模型的能力边界所框定。无论应用逻辑多精巧，其核心的认知、生成、推理能力都受制于所调用模型的性能。

这种模式下，难以诞生真正的“超级应用”。超级应用的核心特征是网络效应：用户越多，价值越大；连接越多，系统越强。微信的价值在于十亿用户的社交关系网，淘宝的价值在于数百万商家和数亿买家构成的交易网络。这些价值是平台本身无法简单复制的。

因此，本文要探讨的核心问题是：在AI时代，如何突破“大模型即平台”的单机范式，构建出具有网络效应的新应用形态？而“Agent网络”是目前最被看好的答案之一。对于开发者而言，这意味着我们的关注点需要从“如何更好地调用单个大模型”，转向“如何设计能让多个AI智能体高效协作的系统”。

2. 基础概念与核心原理：从单体Agent到Agent网络

在深入实践之前，我们必须厘清几个关键概念。

2.1 什么是Agent（智能体）？

在AI语境下，Agent不是一个新词。简单来说，一个AI Agent是一个能够感知环境、自主决策并执行行动以实现目标的系统。与单纯完成一次对话的Chatbot不同，一个典型的Agent应具备以下核心组件：

1. 规划（Planning）：将复杂目标分解为可执行的子任务序列。
2. 记忆（Memory）：短期记忆（上下文）和长期记忆（向量数据库等），用于存储对话、知识和经验。
3. 工具使用（Tool Use）：能够调用外部工具、API或函数来获取信息或执行操作（如搜索网页、查询数据库、执行代码）。
4. 行动（Action）：根据规划和工具调用结果，执行具体的输出或操作。

一个简单的天气预报Agent，其工作流程可能是：接收用户查询（“北京明天天气如何？”） -> 规划（需要调用天气API） -> 使用工具（调用某天气接口） -> 行动（将API返回的信息组织成自然语言回复给用户）。

2.2 为什么单体Agent不够？网络化的必然性

单个Agent的能力存在物理和逻辑极限。

• 能力边界：一个Agent很难精通所有领域。让一个Agent同时精通法律条文、医疗诊断、金融建模和诗歌创作，既不经济也不现实。
• 数据与权限隔离：现实世界的数据和权限是分散的。公司的财务数据、个人的健康档案、公开的科研论文，分别存储在不同的、有权限控制的系统中。
• 复杂任务需求：一个“为我规划一次包含学术会议、景点观光和本地美食的日本深度游，并完成机票酒店预订”的任务，涉及信息检索、行程优化、跨平台比价、支付等多个环节，需要多个专业Agent协作。

因此，专业化分工与协作成为必然。就像人类社会的经济体系一样，会出现专注于特定领域的Agent：数据检索Agent、代码生成Agent、文案润色Agent、交易执行Agent等。

2.3 Agent网络（Agent Network）是什么？

Agent网络是指多个自治的AI智能体，通过一套标准的通信协议、发现机制和协作规则，相互连接、协同工作的分布式系统。它不再是中心化的“大脑”，而是一个去中心化的“社会”。

在这个网络中：

• 每个Agent是独立的服务：拥有明确的职责、能力描述和调用接口。
• 通信是标准化的：可能基于HTTP/gRPC，并使用类似OpenAI的Function Calling规范或更高级的Agent协议（如LangGraph的持久化多Agent状态）来描述能力和交换信息。
• 存在协调者（Orchestrator）：一个主Agent或专门的协调服务，负责接收用户请求，分解任务，并在网络中寻找、调度和组合最适合的子Agent来共同完成任务。
• 可能演化出经济模型：Agent之间可能需要为彼此的服务进行“支付”或“激励”，形成初步的Agent经济（Agent Economy）。

从H2H（人人互联）到H2M（人机互联），再到M2M（机机互联），Agent网络代表着交互主体的根本性变化。

3. 环境准备与前置条件

理论讲完了，我们动手搭建一个演示性的多Agent协作系统。我们将创建一个简单的“旅行规划助手”，它由三个Agent组成：一个主协调Agent、一个信息检索Agent和一个文案生成Agent。

技术栈选择：

• 框架：我们使用LangChain和LangGraph。LangChain是当前构建AI应用最流行的框架之一，而LangGraph特别适合描述多Agent之间的工作流和状态转移。
• 大模型：使用 OpenAI GPT-4 或 GPT-3.5-Turbo 的API。你也可以替换为其他兼容OpenAI API的模型（如通义千问、DeepSeek等）。
• 编程语言：Python 3.10+
• 关键库：
  • langchain: 核心框架
  • langchain-openai: OpenAI模型集成
  • langgraph: 构建多Agent工作流
  • langchain-community: 社区工具（可选，用于搜索等）
  • python-dotenv: 管理环境变量

环境配置步骤：

1. 创建项目目录并初始化虚拟环境（推荐）：

   mkdir agent-network-demo && cd agent-network-demo python -m venv venv # Windows venv\Scripts\activate # macOS/Linux source venv/bin/activate

2. 安装依赖库：

   pip install langchain langchain-openai langgraph langchain-community python-dotenv

3. 配置OpenAI API密钥： 在项目根目录创建.env文件，填入你的OpenAI API Key。

   # .env 文件 OPENAI_API_KEY=sk-your-actual-api-key-here

   重要安全提醒：永远不要将API密钥硬编码在代码中或提交到版本控制系统（如Git）。.env文件应被添加到.gitignore中。

4. 核心流程拆解：构建一个三Agent协作系统

我们的目标是构建一个系统，当用户提出“帮我规划一个上海的三日游行程”时：

1. 主协调Agent理解任务，并将其分解为“信息收集”和“行程文案生成”两个子任务。
2. 信息检索Agent负责从预设知识库或网络（演示中我们用模拟数据）中获取上海的景点、美食、交通等信息。
3. 文案生成Agent根据检索到的信息，生成一份格式优美、人性化的三日游行程规划。
4. 主协调Agent汇总结果并返回给用户。

我们将使用LangGraph来定义这个工作流。LangGraph的核心思想是将工作流建模为状态图（StateGraph），每个节点是一个处理函数（Agent），边定义了状态如何在不同节点间流转。

5. 完整示例与代码实现

5.1 定义共享状态和Agent

首先，我们定义整个工作流共享的状态结构，并创建三个Agent函数。

# main.py import os from typing import TypedDict, Annotated, List from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage, SystemMessage from dotenv import load_dotenv # 加载环境变量 load_dotenv() # 1. 定义工作流状态结构 class AgentState(TypedDict): """所有Agent共享和传递的消息状态""" # 用户原始输入 user_input: str # 任务分解后的子任务列表 sub_tasks: List[str] # 信息检索Agent收集到的原始数据 retrieved_info: str # 文案生成Agent产生的最终文案 final_itinerary: str # 用于在节点间传递消息的列表 messages: Annotated[List, "append"] # 2. 初始化大模型 llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.7, api_key=os.getenv("OPENAI_API_KEY")) # 3. 定义主协调Agent节点函数 def orchestrator_agent(state: AgentState): """接收用户输入，分解任务，并决定下一步是检索信息还是生成文案。""" user_query = state["user_input"] # 系统提示词，指导模型进行任务分解 system_prompt = """你是一个旅行规划系统的总协调员。你的职责是： 1. 理解用户的旅行规划请求。 2. 将复杂请求分解为具体的子任务。 3. 目前你只有两个下属Agent可用： - 信息检索Agent：负责查找目的地（如上海）的景点、美食、交通、天气等实用信息。 - 文案生成Agent：负责将收集到的信息整合成一份详细、生动、结构清晰的旅行日程文案。 请根据用户请求，判断是否需要调用这两个Agent，并输出你的任务分解计划。""" messages = [ SystemMessage(content=system_prompt), HumanMessage(content=f"用户请求：{user_query}\n请生成你的任务分解计划。") ] response = llm.invoke(messages) plan = response.content # 简化处理：这里我们假设所有旅行规划都需要先检索信息。 # 在实际复杂系统中，你可以让LLM判断并动态决定下一个节点。 new_sub_tasks = ["检索目的地信息", "生成行程文案"] # 更新状态 return { "sub_tasks": new_sub_tasks, "messages": state["messages"] + [HumanMessage(content=f"协调员计划：{plan}")], # 明确指示下一个节点是 `retrieval_agent` "next": "retrieval_agent" } # 4. 定义信息检索Agent节点函数 def retrieval_agent(state: AgentState): """模拟从知识库或网络检索信息。""" # 在实际应用中，这里可以连接向量数据库、调用搜索API等。 # 此处我们使用模拟数据。 destination = "上海" # 简单从输入中提取，实际应用需用NLU解析 simulated_data = f""" **{destination} 旅行信息摘要**： - **经典景点**：外滩、东方明珠、豫园、南京路步行街、迪士尼乐园、田子坊。 - **美食推荐**：小笼包、生煎、白斩鸡、红烧肉、鲜肉月饼、本帮菜。 - **交通建议**：地铁网络发达，建议使用“Metro大都会”APP。浦东机场和虹桥机场连接市区。 - **天气贴士**：夏季炎热多雨，冬季阴冷。春秋两季是最佳旅行时间。 - **文化体验**：参观上海博物馆，观看一场沪剧或杂技。 """ return { "retrieved_info": simulated_data, "messages": state["messages"] + [HumanMessage(content=f"检索员已获取信息：{simulated_data[:100]}...")], "next": "writing_agent" # 检索完成后，自动流向文案生成Agent } # 5. 定义文案生成Agent节点函数 def writing_agent(state: AgentState): """根据检索到的信息，生成最终的行程文案。""" user_query = state["user_input"] info = state["retrieved_info"] system_prompt = """你是一位专业的旅行文案撰写人。请根据提供的目的地信息，为用户创作一份详细、吸引人、实用性高的旅行行程规划。 要求： 1. 格式清晰，按天划分。 2. 包含景点、餐饮、交通、住宿建议（可模拟）。 3. 语言生动，有代入感。 4. 在最后给出一些通用旅行提醒。""" messages = [ SystemMessage(content=system_prompt), HumanMessage(content=f"用户原始请求：{user_query}\n\n可用的目的地信息：\n{info}\n\n请生成完整的旅行行程规划：") ] response = llm.invoke(messages) final_output = response.content return { "final_itinerary": final_output, "messages": state["messages"] + [HumanMessage(content=f"文案员已完成创作。")], "next": END # 工作流结束 }

5.2 构建并运行工作流图

接下来，我们用LangGraph将这三个Agent函数组合成一个有向工作流。

# main.py (续) # 6. 构建LangGraph工作流 def build_agent_workflow(): # 创建状态图，指定状态类型为AgentState workflow = StateGraph(AgentState) # 添加三个节点，将我们定义的函数绑定到节点名 workflow.add_node("orchestrator_agent", orchestrator_agent) workflow.add_node("retrieval_agent", retrieval_agent) workflow.add_node("writing_agent", writing_agent) # 设置入口点 workflow.set_entry_point("orchestrator_agent") # 定义边（路由逻辑） # 从协调员到检索员：我们通过在`orchestrator_agent`返回的state中设置"next"字段来动态路由。 # 这里我们使用一个条件路由函数。 def route_after_orchestrator(state): # 检查state中是否有“next”指示，没有则默认去检索 return state.get("next", "retrieval_agent") workflow.add_conditional_edges( "orchestrator_agent", route_after_orchestrator, { "retrieval_agent": "retrieval_agent", # 未来可以扩展其他分支，例如直接结束 END: END } ) # 从检索员到文案员是固定的 workflow.add_edge("retrieval_agent", "writing_agent") # 文案员执行完毕后，工作流结束 workflow.add_edge("writing_agent", END) # 编译图 return workflow.compile() # 7. 运行工作流 if __name__ == "__main__": # 编译工作流 app = build_agent_workflow() # 定义初始状态 initial_state: AgentState = { "user_input": "帮我规划一个上海的三日游行程，要包含经典景点和本地美食。", "sub_tasks": [], "retrieved_info": "", "final_itinerary": "", "messages": [] } print("开始执行多Agent旅行规划工作流...\n") print(f"用户输入：{initial_state['user_input']}\n") print("-" * 50) # 执行图 final_state = app.invoke(initial_state) print("\n" + "="*50) print("工作流执行完成！") print("="*50) print("\n【最终生成的行程规划】\n") print(final_state["final_itinerary"]) print("\n" + "="*50) print("【工作流执行消息记录】") for msg in final_state["messages"]: print(f"- {msg.content}")

5.3 代码解析与关键点

1. 状态管理（AgentState）：我们使用TypedDict定义了一个共享状态对象。这是LangGraph的核心，所有Agent节点都读取和修改这个状态，从而实现信息传递。Annotated[List, "append"]是一个特殊注解，表示messages字段在多个节点修改时会自动追加，而不是覆盖。
2. 条件路由：在orchestrator_agent之后，我们使用了add_conditional_edges。这允许工作流根据当前状态动态决定下一步走向，这是实现复杂、灵活决策逻辑的基础。在本例中，我们简化了逻辑，直接指向retrieval_agent。
3. 节点的独立性：每个Agent函数（节点）只关心自己的输入（state）和输出（更新后的state）。它们不知道其他节点的具体实现，只通过共享状态进行通信。这种松耦合设计是构建可扩展Agent网络的关键。
4. 模拟与真实：retrieval_agent中我们使用了模拟数据。在实际系统中，这里应替换为真实的工具调用，例如：

   # 示例：使用LangChain的SerpAPI工具进行真实网络搜索 from langchain_community.tools import SerpAPIWrapper search = SerpAPIWrapper() real_info = search.run(f"{destination} 旅游攻略 2024")

6. 运行结果与效果验证

运行上述main.py脚本，你将看到类似以下的输出（具体文案因模型随机性而异）：

开始执行多Agent旅行规划工作流... 用户输入：帮我规划一个上海的三日游行程，要包含经典景点和本地美食。 -------------------------------------------------- ================================================== 工作流执行完成！ ================================================== 【最终生成的行程规划】 **上海三日经典美食文化之旅** **第一天：外滩风云与都市印象** * **上午**：抵达上海，入住南京东路附近酒店。漫步【南京路步行街】，感受“中华商业第一街”的繁华。 * **中午**：在【老正兴菜馆】品尝正宗本帮菜，推荐草头圈子、油爆虾。 * **下午**：游览【外滩】，欣赏万国建筑博览群，远眺陆家嘴金融中心。乘坐跨江轮渡，体验浦江风光。 * **晚上**：登顶【东方明珠】或【上海中心大厦】观光厅，俯瞰璀璨夜景。晚餐可在陆家嘴的正大广场解决。 * **住宿**：南京东路/人民广场区域。 **第二天：豫园古韵与迪士尼奇梦** * **上午**：参观【豫园】，领略江南古典园林的精致。在城隍庙商圈品尝【南翔馒头店】的小笼包。 * **下午**：前往【上海迪士尼乐园】，沉浸于童话世界（需全天时间，此为选项，也可替换为其他景点）。 * **晚上**：迪士尼内观看烟花秀，或返回市区在【田子坊】的艺术小巷中寻找特色餐厅。 * **住宿**：同上。 **第三天：文艺漫步与告别** * **上午**：游览【上海博物馆】（需预约），深入了解中国历史与艺术。或去【新天地】，感受石库门建筑与现代商业的融合。 * **中午**：在【大壶春】或【小杨生煎】享用一顿生煎盛宴。 * **下午**：前往【武康路】或【安福路】，逛特色书店、买手店，喝一杯精品咖啡。 * **晚上**：根据航班或火车时间，前往机场/车站。可在机场购买【沈大成】的鲜肉月饼作为伴手礼。 **通用旅行提醒**： 1. 交通：下载“Metro大都会”APP扫码乘地铁，非常方便。 2. 天气：出行前查看天气预报，夏季备雨具，冬季备保暖衣物。 3. 预订：迪士尼、热门餐厅建议提前在线预订。 4. 支付：大部分场所支持支付宝/微信支付，备少量现金即可。 ================================================== 【工作流执行消息记录】 - 协调员计划：用户请求规划上海三日游行程，需包含经典景点和本地美食。需要调用信息检索Agent获取上海的景点、美食、交通等详细信息，然后调用文案生成Agent根据这些信息生成详细行程。 - 检索员已获取信息：**上海 旅行信息摘要**：... - 文案员已完成创作。

如何验证成功？

1. 流程完整性：检查控制台输出，确认三个Agent节点（协调员、检索员、文案员）都被依次触发，并且有相应的消息记录。
2. 结果相关性：最终生成的行程应直接回应用户请求（上海三日游、经典景点、本地美食），并且内容结构清晰、信息具体。
3. 状态流转：检查final_state字典，确认retrieved_info和final_itinerary字段都被正确填充。

如果运行失败，请按以下顺序排查：

1. API密钥：确认.env文件中的OPENAI_API_KEY设置正确，且网络可以访问OpenAI API。
2. 依赖安装：确认langchain、langchain-openai、langgraph等库已正确安装。
3. 代码缩进：Python对缩进敏感，请确保代码块缩进正确。

7. 常见问题与排查思路

在构建和运行此类多Agent系统时，你会遇到一些典型问题。

8. 最佳实践与工程建议

将演示项目推向生产级Agent网络，需要考虑更多工程化问题。

8.1 设计模式与架构

• 清晰的Agent职责边界：每个Agent应像微服务一样，有单一、明确的职责（Single Responsibility）。例如，专门负责SQL查询的Agent、专门负责发送邮件的Agent等。
• 标准化通信协议：除了使用LangGraph的状态管理，考虑采用更通用的标准，如基于HTTP的RESTful API或gRPC，并使用OpenAPI/Swagger进行描述。这为不同技术栈的Agent互联奠定了基础。
• 引入“路由器（Router）Agent”：对于复杂任务，主协调Agent可以演化为一个专门的“路由器”。它维护一个Agent技能注册表，根据用户请求，动态选择并调用最合适的Agent组合。这类似于服务发现。

# 技能注册表示例（简化） agent_registry = { “weather_agent”: {“description”: “提供城市天气查询”, “endpoint”: “http://localhost:8001/weather”}, “flight_agent”: {“description”: “查询和预订航班”, “endpoint”: “http://localhost:8002/flights”}, “calendar_agent”: {“description”: “管理个人日历事件”, “endpoint”: “http://localhost:8003/calendar”}, }

8.2 稳定性与可靠性

• 错误处理与重试：网络调用必然失败。为每个Agent间的调用添加重试机制（如指数退避）和超时设置。使用try...except捕获异常，并设计降级策略（例如，检索失败时使用缓存数据或返回友好提示）。
• 状态持久化：LangGraph支持将工作流状态持久化到数据库（如Redis、PostgreSQL）。这对于处理长时间运行的任务至关重要，即使进程重启，也能从断点恢复。
• 监控与可观测性：为每个Agent调用记录详细的日志（输入、输出、耗时、错误）。集成像Prometheus和Grafana这样的监控工具，跟踪关键指标，如请求量、延迟、错误率。

8.3 性能与成本优化

• 异步与非阻塞：当多个Agent可以并行执行时（例如，同时查询天气和航班），使用异步编程（asyncio）可以大幅减少整体延迟。LangGraph支持异步节点。
• 缓存策略：对于频繁且结果变化不快的查询（如城市基本信息），引入缓存层（Redis、Memcached），避免重复调用大模型或外部API，节省成本和时间。
• 模型选择：并非所有任务都需要GPT-4。根据任务复杂度，混合使用不同规模和成本的模型（如GPT-3.5-Turbo用于简单分类，GPT-4用于复杂推理）。

8.4 安全与权限

• 输入验证与净化：对所有用户输入和Agent间传递的数据进行严格的验证和净化，防止提示词注入（Prompt Injection）攻击。
• 工具调用沙箱化：对于可以执行代码或访问敏感系统的Agent工具（如ShellTool），必须在严格的沙箱环境中运行，限制其权限和资源访问。
• 权限与认证：在真正的分布式Agent网络中，必须实现服务间认证（如API密钥、JWT令牌），确保只有授权的Agent才能调用特定服务。

9. 总结与后续学习方向

我们从一个历史与商业的宏观问题切入——AI超级应用为何难产，最终落地到一个具体的技术实现——用LangGraph构建一个多Agent协作系统。这个旅程揭示了当前AI应用发展的一个关键瓶颈：单一模型的能力垄断，以及破局的关键路径：走向基于专业化分工与协作的Agent网络。

本文的实践部分为你展示了构建Agent网络的最小可行原型（MVP）。你学会了：

1. 使用LangGraph定义多Agent工作流，通过状态图管理复杂的协作逻辑。
2. 设计具有明确职责的Agent，并通过共享状态进行通信。
3. 实现条件路由，使工作流具备基本的决策能力。

但这仅仅是起点。要构建真正强大、可扩展的Agent网络，你还需要深入以下方向：

• 深入研究高级框架：LangGraph只是选择之一。AutoGen（微软）、CrewAI等框架提供了不同的多Agent协作范式（如基于聊天的协作、角色扮演）。了解它们的优劣，选择最适合你场景的。
• 掌握Agent核心组件：深入理解并实践更强大的规划器（Planner）、记忆系统（向量数据库、长期记忆）、工具调用（复杂函数、API集成）。
• 探索通信与发现协议：关注像Agent Protocol（一个正在兴起的开放标准）这样的项目，它旨在为不同框架开发的Agent提供统一的互操作接口。
• 考虑去中心化与经济模型：展望未来，Agent网络可能演化为一个去中心化市场。学习一些区块链和智能合约的基本概念，思考如何为Agent的服务设计激励和结算机制。

AI的未来，很可能不是一个“超级大脑”，而是一个由无数个“专业大脑”通过高效网络紧密协作构成的“超级社会”。作为开发者，我们现在学习设计和构建这些“专业大脑”及其协作规则，正是在为那个即将到来的、由M2M网络驱动的AI超级应用时代，打下第一块基石。

建议将本文的代码作为实验起点，尝试增加更多的Agent（如酒店预订Agent、预算规划Agent），连接真实的API，并引入更复杂的路由逻辑。当你亲手让多个AI智能体像团队一样为你解决问题时，你会对“Agent网络”的力量有更直观和深刻的认识。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度