详解多智能体架构：以 Open Deep Research 项目为例

                                                                                                                                                <div>

资料来源：火山引擎-开发者社区

背景

业界 AI 大佬们最近对上下文进行了很深入的一番讨论（“争吵”）：
1.Cognition 的看法：反对多智能体，推崇上下文工程

认为当前 LLM 在处理长上下文和主动沟通方面尚不成熟，强行引入 MAS 会导致上下文割裂、决策分散等风险，反而弱化系统可靠性。
主张先构建单体系统并加强上下文工程，再考虑多智能体结构。

2.Anthropic 的看法：探索并行优势，但依赖上下文工程

其多智能体研究系统采用 orchestrator‑worker 模式，多个 Agent 分工并行处理，适合用于大范围信息检索与整合任务。
但强调必须通过上下文工程实现状态共享与记忆同步，否则容易失控。

3.LangChain 的折中立场：灵活架构，任务导向选择

认为共同点是上下文工程的重要性；而多 Agent 在“读取（Read）”型任务中效果更佳，“写入（Write）”型任务仍建议采用单 Agent。
推出 LangGraph 等编排工具，实现对 LLM 调用上下文的精细控制，支持混合架构。

本文就着重用 LangChain 的核心项目 Open Deep Research（ https://github.com/langchain-ai/open\_deep\_research?ref=blog.langchain.com）来讲解下多智能体的架构。

Open Deep Research 的架构演进之路
让我们先从这个项目的发展历程说起，这个演进过程特别有代表性。
第一阶段：单体架构（Simple but Limited）
Open Deep Research 项目最初采用的是单体架构，就像我们大部分 AI 项目的起点一样：

用户查询 → 单个LLM → 工具调用循环 → 生成报告

架构特点：

集中式控制流
紧密耦合的组件
共享内存系统
所有逻辑在一个推理引擎中

这个阶段的代码大概是这样的：

classSimpleResearcher:  
    defresearch(self, query):  
        # 单个LLM处理所有任务  for i in range(max\_iterations):  
            # 生成搜索查询  
            search\_query = self.llm.generate\_query(query, context)  

            # 执行搜索  
            results = self.search\_tool(search\_query)  

            # 分析结果，决定下一步  next\_action = self.llm.analyze\_and\_plan(results, context)  

            if next\_action == "finish":  
                break  

        # 生成最终报告  return self.llm.generate\_report(all\_context)

遇到的问题：
1.上下文爆炸：复杂研究任务很快就达到 token 限制
2.效率低下：只能串行处理，无法并行化
3.质量不稳定：同时处理多个子主题，容易混乱
4.深度不够：为了控制 token，不得不限制研究深度
这些问题让 Langchain 团队意识到：单体架构在处理复杂研究任务时有根本性的局限。
第二阶段：流水线架构（Better Organization）
为了解决单体架构的问题，项目引入了流水线架构：

需求分析 → 信息收集 → 数据分析 → 报告生成

架构改进：

classPipelineResearcher:  
    def\_\_init\_\_(self):  
        self.scoper = ScopeAgent()  
        self.collector = CollectionAgent()    
        self.analyzer = AnalysisAgent()  
        self.writer = WriterAgent()  

    defresearch(self, query):  
        # 阶段1：需求澄清  brief = self.scoper.clarify\_requirements(query)  

        # 阶段2：信息收集  
        raw\_data = self.collector.collect\_information(brief)  

        # 阶段3：数据分析  insights = self.analyzer.analyze(raw\_data)  

        # 阶段4：报告生成  report = self.writer.generate\_report(brief, insights)  

        return report

解决的问题：

清晰的职责分工
标准化的接口
可重用的组件

新的挑战：

仍然是串行处理，效率不高
信息收集阶段仍然受上下文限制
复杂推理任务表现不佳

第三阶段：多智能体架构（Current State）

最终，项目演进到了多智能体架构，这也是本文要重点分析的：

监督者代理 → 多个专家代理并行工作 → 结果整合

关键突破：
1.上下文隔离：每个专家代理有独立的上下文窗口
2.并行处理：多个代理可以同时工作
3.专业化分工：每个代理专注特定领域
4.智能协调：监督者根据任务复杂度动态分配
让我们看看典型的研究场景是如何解决的：
场景：对比 OpenAI、Anthropic、DeepMind 的 AI 安全理念
单体架构时代：

# 所有信息挤在一个上下文里  
search\_queries = [  
    'OpenAI AI safety framework',  
    'Anthropic constitutional AI approach',   
    'DeepMind technical safety research'  
]  

for query in search\_queries:  
    results = search(query)  # 结果越来越多  
    context += results       # 上下文越来越大！  # 上下文污染，token爆炸，质量下降

多智能体时代：

# 每个代理专注一个公司，独立的上下文  
agent\_openai = SpecialistAgent(focus="OpenAI safety")  
agent\_anthropic = SpecialistAgent(focus="Anthropic safety")    
agent\_deepmind = SpecialistAgent(focus="DeepMind safety")  

# 并行执行，各自深度研究  results = await asyncio.gather(  
    agent\_openai.deep\_research(),  
    agent\_anthropic.deep\_research(),   
    agent\_deepmind.deep\_research()  
)  

# 监督者整合结果  
final\_report = supervisor.synthesize\_comparison(results)

这个演进过程给我们一个重要启示：多智能体不是一开始就需要的，而是在单体架构遇到根本性限制时的自然演进。
深入解析：多智能体架构的设计精髓
了解了演进过程后，让我们深入分析当前的多智能体架构是如何设计的。这里体现了很多上下文工程的核心思想。
LangChain 团队在最新版本中设计了一个三阶段架构：
Phase 1: Scope（范围界定）

Scope 需要规划当前处于任务的哪个阶段；

用户需求 → 需求澄清 → 研究简报生成

这个阶段完美体现了上下文工程中的”压缩”策略：
实际案例

这张图很明显的展示了通过聊天模型主动获取缺失信息的过程；

用户："切尔西区排名前十的餐厅有哪些？"  
系统："你是说在曼哈顿还是伦敦？"  
用户："曼哈顿"  
系统："明白了，我来为您生成详细的餐厅简报..."

上下文工程的核心应用：

Write Context：将冗长对话保存为结构化的研究简报
Compress Context：避免 token 浪费，聚焦核心需求
Select Context：为后续研究提供明确的”北极星”

这种设计解决了我们在上下文工程中提到的”上下文爆炸”问题。
Phase 2: Research（研究执行）

这是上下文工程”隔离”策略的完美体现：

研究监督者 → 任务分解 → 多个子代理并行研究 → 结果整合

监督者的职责（智能分配上下文）

classResearchSupervisor:  
    defdelegate\_research(self, brief):  
        # 分析研究简报，判断是否需要并行化  subtopics = self.analyze\_parallelization\_needs(brief)  

        if len(subtopics) > 1:  
            # 创建专门的子代理，每个有独立上下文窗口  
            sub\_agents = [  
                ResearchAgent(topic=topic, focus=focus, isolated\_context=True)   
                for topic, focus in subtopics  
            ]  

            # 并行执行研究，避免上下文冲突  results = self.parallel\_execute(sub\_agents)  
        else:  
            # 单线程深度研究  results = self.single\_thread\_research(brief)  

        return self.evaluate\_completeness(results, brief)

子代理的上下文管理模式

每个子代理都有明确的上下文边界：

专注单一主题：独立的上下文窗口，避免主题间的干扰
工具调用循环：搜索→分析→再搜索，上下文逐步积累
结果清理：最后压缩清理，只返回精华信息

这就是我们在上下文工程中提到的 “Isolate Context”策略的实际应用！
Phase 3: Write（报告生成）

研究简报 + 所有研究发现 → 一次性生成完整报告

这个阶段体现了上下文工程中”Select Context”的智慧：
关键设计思想：

集中式写作：不让子代理各自写片段（避免协调混乱）
精选上下文：只把压缩后的研究发现和原始简报给到写作 LLM
一次性生成：确保报告的逻辑连贯性和风格一致性

这解决了我们之前提到的”上下文冲突”和”协调复杂性”问题。
核心经验：什么时候该用多智能体？
适合多智能体的场景
1.子任务高度独立

对比分析：OpenAI vs Anthropic vs DeepMind的AI安全理念  

子任务分解：  
- Agent A：专门研究OpenAI的安全框架  - Agent B：专门研究Anthropic的Constitutional AI  - Agent C：专门研究DeepMind的技术路线

为什么有效？

每个代理有独立的 context window
避免了”上下文冲突”（context clash）
可以并行执行，提高效率

2.需要不同深度的研究策略

classFlexibleResearchSupervisor:  
    defdecide\_strategy(self, brief):  
        complexity = self.assess\_complexity(brief)  

        if complexity == "simple":  
            return"single\_agent\_quick\_research"  
        elif complexity == "medium":  
            return"parallel\_research\_2\_agents"    
        elif complexity == "complex":  
            return"deep\_parallel\_research\_5\_agents"

比如：用户不希望简单问题等 10 分钟，但复杂问题需要深度挖掘。监督者可以灵活调节研究深度。
不适合多智能体的场景
1.需要紧密协作的任务
LangChain 团队踩过的坑：

❌ 错误做法：让多个子代理分别写报告的不同章节  
结果：章节之间逻辑不连贯，风格不统一  

✅ 正确做法：多代理只负责研究，一个LLM负责写作  
结果：报告逻辑清晰，风格统一

2.简单的单线程任务

用户："GPT-4是什么时候发布的？"

这种问题用多智能体就是杀鸡用牛刀。
实战经验：LangChain 多智能体研究系统
LangChain 的多智能体研究系统：

架构设计

classMultiAgentResearchSystem:  
    def\_\_init\_\_(self):  
        self.supervisor = ResearchSupervisor()  
        self.agent\_pool = AgentPool(max\_agents=5)  
        self.context\_manager = ContextEngineer()  

    defresearch(self, user\_query):  
        # 阶段1：范围界定  brief = self.scope\_phase(user\_query)  

        # 阶段2：智能体研究  
        research\_findings = self.research\_phase(brief)  

        # 阶段3：报告生成    report = self.write\_phase(brief, research\_findings)  

        return report  

    defresearch\_phase(self, brief):  
        # 监督者决定研究策略  strategy = self.supervisor.plan\_research(brief)  

        if strategy.parallel:  
            # 创建专门的子代理  agents = [  
                self.create\_specialist\_agent(subtopic)   
                for subtopic in strategy.subtopics  
            ]  

            # 并行执行  
            raw\_findings = self.parallel\_research(agents)  

            # 上下文工程：清理和压缩结果  
            clean\_findings = [  
                self.context\_manager.compress\_findings(finding)  
                for finding in raw\_findings  
            ]  
        else:  
            # 单代理深度研究  
            clean\_findings = self.single\_agent\_research(brief)  

        return clean\_findings

上下文工程的关键作用
我们发现，多智能体系统最大的挑战不是协调，而是token管理：

classContextEngineer:  
    defcompress\_findings(self, raw\_research):  
        """子代理研究结果压缩"""  
        compression\_prompt = f"""  
        请从以下研究材料中提取最核心的信息：  

        原始材料：{raw\_research}  

        要求：  
        1. 保留关键事实和数据  
        2. 去除重复和无关信息    
        3. 保持引用来源  
        4. 控制在500tokens以内  
        """  

        return self.llm.generate(compression\_prompt)  

    defgenerate\_brief(self, chat\_history):  
        """对话历史压缩成研究简报"""  
        brief\_prompt = f"""  
        基于以下用户对话，生成聚焦的研究简报：  

        对话历史：{chat\_history}  

        研究简报应包含：  
        - 核心研究问题  
        - 具体要求和边界  
        - 期望的输出格式  
        - 成功标准  
        """  

        return self.llm.generate(brief\_prompt)

实际效果数据
根据 GitHub 仓库 langchain‑ai/open_deep_research 的说明（2025 年 8 月 2 日更新）：

在 DeepResearch Bench 排行榜中，Open Deep Research 排名第六。
本次评估其 RACE 总分为 0.4344。
是当前表现最好的完全开源 Deep Research Agent。

踩坑经验：多智能体的陷阱
协调复杂性陷阱
错误做法：

# 让多个代理协作完成一个紧密耦合的任务  
agent1.write\_introduction()    
agent2.write\_analysis()      # 不知道introduction写了什么  
agent3.write\_conclusion()    # 不知道analysis的结果

正确做法：

# 多代理只做独立的研究，集中式整合  findings = parallel\_research([agent1, agent2, agent3])  
report = single\_writer.synthesize(findings)

成本失控陷阱
多智能体系统 token 消耗确实更高，需要精心设计：

classCostOptimizer:  
    defoptimize\_agent\_usage(self, brief):  
        complexity = self.assess\_complexity(brief)  

        if complexity < 0.3:  
            return"single\_agent"# 简单问题不浪费  elif complexity < 0.7:  
            return"2\_agent\_parallel"# 中等复杂度  else:  
            return"full\_multi\_agent"# 复杂问题全力以赴

结果质量不一致
不同子代理可能有不同的”理解偏差”：

classQualityController:  
    defensure\_consistency(self, sub\_findings):  
        # 质量检查点  
        for finding in sub\_findings:  
            ifnot self.meets\_quality\_standard(finding):  
                # 要求子代理重新研究  
                finding = self.request\_refinement(finding)  

        return sub\_findings

设计原则：我们的多智能体最佳实践
1.明确边界原则

✅ 每个代理有清晰的职责边界
✅ 子任务之间相对独立
❌ 让代理处理有依赖关系的任务

2.监督者智能化原则
智能监督者负责

任务分解
路由与协调
并行/串行调度
质量与预算控制
异常重试与升级

3.上下文工程优先原则
在多智能体系统中，上下文工程的重要性 > 协调算法：

研究简报要保持简洁、聚焦
子代理输出需要清理、压缩
避免无效 token 消耗和上下文污染

4.质量控制原则
由「质量闸口」来判断研究结果是否足够深入：

计算研究覆盖度，与目标简报进行对比
如果覆盖度 < 0.8，则触发额外研究
否则通过审核并输出结果

未来展望：多智能体的发展发向
自适应代理分配
根据工作负载智能调整代理数量：

classAdaptiveAgentPool:  
    defauto\_scale\_agents(self, workload):  
        optimal\_agents = self.predict\_optimal\_count(workload)  
        if optimal\_agents > self.current\_agents:  
            self.spawn\_additional\_agents(optimal\_agents - self.current\_agents)  
        elif optimal\_agents < self.current\_agents:  
            self.retire\_excess\_agents(self.current\_agents - optimal\_agents)

跨领域专业化
为不同领域创建专门的代理：

classDomainSpecialistFactory:  
    defcreate\_specialist(self, domain):  
        specialist\_config = {  
            'academic\_research': AcademicResearchAgent,  
            'market\_analysis': MarketAnalysisAgent,    
            'technical\_review': TechnicalReviewAgent,  
            'legal\_compliance': LegalComplianceAgent  
        }  
        return specialist\_config[domain]()

智能协调算法
优化代理间的协调和依赖关系：

retail\_enter\_domain\_model (信息获取型)  
    ↓ 提供 enter\_node\_name\_list 参数  
retail\_shop\_qual\_audit\_info (依赖调用型)  

check\_business\_license\_duplicate (独立调用型)

核心总结
通过 Open Deep Research 项目的演进历程，我们看到了 AI 工程化的清晰路径：

单体LLM → 流水线架构 → 多智能体架构

关键启示：

多智能体不是一开始就需要的，而是在遇到根本性限制时的自然演进
上下文工程是多智能体架构的理论基础
成功的多智能体系统本质上是上下文隔离策略的极致应用

写在最后
Open Deep Research 项目的演进历程给我们最重要的启示是：每一次架构变迁都是为了解决具体问题而自然涌现的。
从单体到流水线，再到多智能体，技术选择的背后是对复杂性管理的不断深化。不要为了技术而技术，要为了解决问题而技术。
作者团队
我们来自字节跳动的电商即时零售技术团队，专注于构建统一的 AI 基座与智能化服务体系，通过多模态技术与自动化平台，为商家和平台提供高效、可扩展的解决方案，助力商家提升经营能力、降低运营成本。
团队研究与落地方向包括：知识问答与治理、AI 内容创作与供给、AI Infra 与原子能力建设。

相关推荐

评论抢沙发

近期文章

相关推荐

评论 抢沙发

近期文章

评论抢沙发