Langmanus多智能体框架详解：架构原理与Agent扩展实战

为什么需要多智能体框架

在AI应用开发中，单一大模型往往难以胜任复杂的端到端任务。一个典型场景可能需要先搜索信息、再分析规划、然后编写代码、最后生成报告——这些环节各有侧重，仅靠一条提示词很难全部搞定。

多智能体系统（Multi-Agent System, MAS）的概念最早源于分布式人工智能研究，在2023-2024年随着大语言模型能力的飞跃而迎来爆发。斯坦福大学的"生成式智能体"实验、AutoGPT的开源热潮、以及微软AutoGen框架的发布，共同推动了这一范式的普及。其核心思想是：与其让一个模型承担所有职责，不如让多个专精的智能体各司其职、协同完成任务——这与软件工程中的微服务架构理念高度一致。

Langmanus正是为解决这一痛点而生的多智能体框架。它由字节跳动团队开发（后因各种原因从TikTok下架），基于LangGraph构建，将多个AI智能体编排成一张协作图，实现任务的自动分解、分发和执行。虽然项目经历了一些波折，但其架构设计和编排理念依然值得深入学习。

LangGraph基础：理解图编排的核心概念

一切皆是图

Langmanus的底层框架是LangGraph，其核心思想非常直观——将整个运行流程编排成一张有向图。

LangGraph是LangChain团队于2024年推出的智能体编排框架，它解决了早期LangChain链式调用（Chain）在处理复杂分支和循环时的局限性。LangGraph借鉴了有限状态机（FSM）和数据流编程的思想，将智能体的执行流程抽象为有向图。与传统的DAG（有向无环图）工作流引擎不同，LangGraph显式支持环路（cycle），这使得智能体可以反复迭代、自我修正，直到达成目标——这正是ReAct（Reasoning + Acting）模式所需要的基础设施。

图中有两个特殊节点：起始节点（Start） 和 结束节点（End）。任务从起始节点出发，依次经过各个功能节点，最终到达结束节点。每个节点可以是一个简单函数、一个AI Agent，甚至是另一张嵌套的子图。

图中的边分为两种类型：

• 实线边：确定性的唯一路径，从A必定走到B
• 条件边（虚线）：由大模型根据当前数据判断走向，实现动态路由

由于是有向图，节点之间默认是单向流动的，但可以通过显式定义实现回环，从而构建出网状、监督型、阶梯型等各种拓扑结构。

State：流转的信息载体

LangGraph中有一个关键概念叫State（状态），它本质上是一个字典数据结构。每个节点接收State、处理数据、将结果追加到State中，然后传递给下一个节点。

State的设计借鉴了Redux等前端状态管理库的理念，采用不可变数据流的思想。每个节点对State的修改并非直接覆盖，而是通过Reducer函数进行合并——例如，消息列表类型的字段默认采用追加（append）策略，而非替换。这种设计确保了多节点并发执行时的数据一致性，同时也为实现检查点（Checkpoint）和时间旅行调试提供了基础。State还支持Channel机制，允许不同节点之间选择性地共享或隔离数据。

State充当了整个图中信息流转的载体，包含用户输入、规划步骤、中间结果等所有关键信息。可以把它理解为在流水线上传递的"工单"，每个工位（节点）在上面填写自己负责的部分。

Langmanus架构详解：六大角色如何协同工作

Langmanus在LangGraph之上设计了一套通用的多智能体架构，能够覆盖大量实际任务场景。下面逐一拆解其核心角色。

协调员（Coordinator）：任务的第一道关卡

协调员类似于公司的前台，负责初步判断用户请求的性质。如果是简单的闲聊（比如"你好，你是谁"），直接礼貌回复并结束；如果是需要多智能体协作的复杂任务，则将请求转交给规划器。

这一设计避免了简单问题也走完整流程的资源浪费。在实际生产环境中，这种"意图识别+快速短路"的模式非常常见——类似于客服系统中的IVR（交互式语音应答）分流机制，先用低成本的方式过滤掉简单请求，只让真正需要深度处理的任务进入复杂流程。

规划器（Planner）：任务的大脑

规划器使用推理模型（如QWQ-32B）对任务进行深度分析和步骤拆解。它还支持一个巧妙的配置——Search Before Planning，即在规划之前先联网搜索背景信息，让规划更加精准。

例如，当用户询问"介绍一下缅甸地震的相关新闻并写成报告"时，规划器会拆解为：

1. 搜索收集地震基本信息
2. 搜索地震成因和影响
3. 整合信息生成研究报告

需要注意的一个坑：规划器输出的步骤顺序，在实际执行时未必严格遵循，某些步骤甚至可能被跳过。这是因为监督员在调度时会根据当前State中已有的信息动态判断哪些步骤仍然必要，这种"弹性执行"虽然增加了灵活性，但也给调试带来了一定挑战。

监督员（Supervisor）：任务的调度中心

监督员相当于项目组长，负责将规划好的步骤逐一分配给具体的执行智能体。它通过结构化JSON输出来决定下一步调用哪个节点，这种设计让路由判断变得精确可控。

结构化输出（Structured Output）是大模型应用工程中的关键技术。传统的自然语言输出存在格式不确定性，难以被下游程序可靠解析。通过Function Calling、JSON Mode或Pydantic Schema约束等机制，可以强制模型输出符合预定义格式的JSON数据。在Langmanus中，监督员使用结构化输出来指定下一个执行节点的名称，这比从自由文本中提取路由信息要可靠得多，大幅降低了因模型输出格式错误导致的流程中断风险。

执行层智能体：各司其职的专业选手

执行层包含多个专业智能体，各自承担不同的任务类型：

• 研究员（Researcher）：配备搜索引擎和爬虫两个工具，支持反复调用直到任务完成。研究员本身也是一张子图（通过create_react_agent创建），体现了"图中有图"的嵌套设计。create_react_agent所创建的是基于ReAct范式的智能体——ReAct（Reasoning and Acting）由谷歌研究团队在2022年提出，其核心思想是让大模型在执行任务时交替进行"推理"和"行动"：模型先思考当前应该做什么（Thought），然后调用外部工具执行操作（Action），观察返回结果（Observation），再决定下一步行动。这个循环会持续进行，直到模型认为已经收集到足够的信息来给出最终答案，特别适合需要多轮信息检索和验证的场景
• 程序员（Coder）：配备Python代码编写和Bash脚本执行工具，弥补大模型计算能力的不足。大语言模型在精确数学计算、数据处理等方面存在天然短板，通过让模型生成代码并实际执行，可以将"近似推理"转化为"精确计算"，这也是当前AI Agent领域广泛采用的Code Interpreter模式
• 浏览器（Browser）：使用Vision模型处理图片相关信息
• 报告员（Reporter）：负责最终的报告撰写和输出

模型配置策略：按角色分配不同模型

Langmanus的一个精妙之处在于按角色差异化分配模型，而不是所有节点都用同一个大模型：

模型类型	具体模型	适用角色
推理模型	QWQ-32B	规划器（需要深度思考）
基础模型	千问-32B	协调员、监督员、研究员等
Vision模型	视觉模型	浏览器（处理图片）

这种差异化配置既保证了关键环节的推理质量，又有效控制了整体的API调用成本。在生产环境中，API调用成本是多智能体系统必须面对的现实问题。以OpenAI为例，GPT-4o的调用成本约为GPT-4o-mini的15-20倍。如果所有节点都使用最强模型，一次复杂任务可能涉及数十次API调用，成本会迅速攀升。Langmanus的差异化配置策略本质上是一种"计算资源的合理分配"：只在真正需要深度推理的环节（如规划）使用高性能模型，而在路由判断、信息整合等相对简单的环节使用轻量模型。这种思路在工业界被称为"模型级联"（Model Cascading），是大模型应用降本增效的核心策略之一。

实战扩展：添加自定义天气智能体

框架的真正价值在于可扩展性。下面以添加天气查询智能体为例，演示如何在Langmanus中扩展新的Agent节点。

第一步：创建外部智能体服务

在阿里云百炼平台上，利用高德地图提供的MCP服务创建天气查询智能体：

1. 进入百炼平台，选择MCP服务中的高德地图
2. 为智能体配置大模型、提示词和MCP工具
3. 发布后获取应用ID，即可通过API调用

MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议，旨在标准化大模型与外部工具和数据源之间的交互方式。在MCP出现之前，每个工具集成都需要编写专门的适配代码；而MCP定义了统一的通信规范，使得工具提供方只需实现一次MCP Server，任何支持MCP的客户端都能直接调用。阿里云百炼平台集成的高德地图MCP服务就是这一生态的典型应用——开发者无需了解高德API的具体细节，通过MCP协议即可让智能体获得地理信息查询能力。

第二步：在图中注册新节点

在Graph配置中添加weather节点，定义其调用逻辑（调用阿里云智能体服务）和返回路径（返回监督员进行下一步调度）。

第三步：通过提示词通知相关角色

这是最关键也最优雅的一步——只需修改提示词，无需改动框架核心代码：

• 在规划器的提示词中添加："用weather节点去查询天气信息"
• 在监督员的提示词中添加weather作为可选的下游节点

整个扩展过程仅通过添加节点和调整提示词即可完成，体现了Langmanus提示词驱动、轻量化扩展的设计哲学。这种设计与传统软件工程中的"开闭原则"（对扩展开放、对修改关闭）不谋而合——新增功能不需要修改已有的核心逻辑，只需在外围进行声明式的配置变更。

验证扩展效果

将联网搜索关闭（设为false），避免研究员直接通过网页搜索获取天气信息。当询问"查一下北京的天气"时，规划器会自动识别并调用weather智能体，最终生成天气报告。

总结与思考

Langmanus的核心价值不仅在于它提供了一套可用的多智能体框架，更在于它展示了一种通用的AI应用编排思想：

1. 图编排让流程可视化：复杂的多步骤任务变得清晰可控
2. 智能体三件套（提示词+模型+工具） 是构建每个Agent节点的标准范式
3. 提示词驱动的扩展机制让系统具备了极强的灵活性
4. 嵌套图设计（图中有图）实现了真正的多层级智能体协作

对于AI应用开发者而言，理解这套架构思想比使用框架本身更重要。无论是用LangGraph还是其他编排工具（如微软的AutoGen、CrewAI、或者基于Temporal/Prefect等工作流引擎的自研方案），协调-规划-监督-执行的分层模式都是构建复杂多智能体应用的有效范式。值得关注的是，这一领域正在快速演进——从早期的简单链式调用，到如今的图编排和动态路由，再到未来可能出现的自适应拓扑结构和智能体自主进化，多智能体系统的架构模式仍有巨大的探索空间。如果你正在探索AI Agent的落地方案，Langmanus的设计思路值得作为参考起点。