详解多智能体架构：以 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 读取区分 | 平衡优点，实用主义，支持细粒度架构选择 | 系统设计较复杂，需要准确识别任务类型与切换逻辑 |
让我们先从这个项目的发展历程说起，这个演进过程特别有代表性。
第一阶段：单体架构（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 与原子能力建设。
