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

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

背景

业界 AI 大佬们最近对上下文进行了很深入的一番讨论（"争吵"）：

1.Cognition 的看法：反对多智能体，推崇上下文工程

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

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

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

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

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

| 阶段／角色 | 核心观点 | 优势 | 局限性或挑战 | | --- | --- | --- | --- | | Cognition / Devin | 单体 + 上下文工程 | 简洁、稳定、可控 | 并行处理能力弱、应对大规模任务时效率低 | | Anthropic | 多智能体协作，依赖上下文工程 | 并行处理能力强，适合信息检索与大任务场景 | 协调复杂，若上下文不共享，易产生碎片化结果 | | LangChain | 灵活组合，任务写作 vs 读取区分 | 平衡优点，实用主义，支持细粒度架构选择 | 系统设计较复杂，需要准确识别任务类型与切换逻辑 |

本文就着重用 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 与原子能力建设。