DeepAgent vs Claude Code 深度研究能力对比分析

问题一：上下文处理机制对比

1.1 上下文压缩策略

维度	DeepAgent	Claude Code
触发时机	上下文达 85%	上下文达 95-98%
压缩方式	LLM 生成结构化摘要（SESSION INTENT / SUMMARY / ARTIFACTS / NEXT STEPS）	API 级别对话摘要，保留架构决策和未解决问题
保留比例	最近 10% 的消息	压缩约 85%（167K → ~25K）
历史可恢复性	可恢复 —— 压缩前完整历史写入 /conversation_history/{thread_id}.md，Agent 可通过 read_file 回溯	不可恢复 —— 旧消息直接丢弃，只剩摘要
手动控制	无	/compact 命令，可带指令引导保留重点

DeepAgent 压缩流程

上下文达到 85%
  │
  ▼ Phase 1: 工具参数截断
  │  扫描旧消息中 write_file / edit_file 的参数
  │  超过 2000 字符的参数截断为前 20 字符 + "...(argument truncated)"
  │
  ▼ Phase 2: 完整历史落盘
  │  将待压缩消息写入 /conversation_history/{thread_id}.md
  │  保留回溯路径
  │
  ▼ Phase 3: LLM 生成摘要
  │  调用模型生成结构化摘要（意图/概要/产物/下一步）
  │
  ▼ Phase 4: 消息替换
     移除所有旧消息，替换为摘要 HumanMessage + 最近 10% 的消息
     摘要中附带历史文件路径供回溯

Claude Code 压缩流程

上下文达到 95-98%
  │
  ▼ 第一步: 清除旧工具输出
  │  移除历史中的 tool results（文件读取、grep、bash 输出等）
  │  这些通常占上下文 80%，清除后释放大量空间
  │
  ▼ 第二步: 对话摘要（如仍不够）
  │  通过 API 对完整对话历史生成摘要
  │  保留架构决策、未解决 bug、实现细节
  │  丢弃冗余内容
  │
  ▼ 第三步: 生成 <summary> 块
  │  所有旧消息被替换为摘要块
  │  剥离所有图片内容、旧的 extended thinking 块
  │
  ▼ 保护项: CLAUDE.md 是唯一保证跨压缩存活的内容

1.2 子 Agent 上下文隔离

两者在子 Agent 设计上思路一致——上下文隔离是深度研究的核心机制，但共享程度不同：

维度	DeepAgent	Claude Code
接收的上下文	仅一条 HumanMessage(task描述)，空白对话历史	类似，仅收到任务 prompt
状态共享	state["files"] 等状态键传递给子 Agent，共享文件系统视图	子 Agent 无法访问父 Agent 内部状态，仅通过磁盘间接共享
返回内容	子 Agent 最后一条消息的文本内容	简洁结果摘要
独立压缩	有独立的 SummarizationMiddleware，自主管理上下文	有独立上下文窗口和压缩周期
嵌套调用	支持多层嵌套	不支持，仅单层级

子 Agent 隔离的核心价值：每个子 Agent 在独立的上下文窗口中工作，MCP 工具返回的大量数据不会污染主 Agent 的上下文。 子 Agent 完成后只返回精炼的结果文本，实现了天然的上下文压缩。

1.3 额外的上下文优化手段

手段	DeepAgent	Claude Code
工具参数截断	✅ 压缩时截断旧的 write_file/edit_file 参数（>2000字符）	❌ 无此机制
thinking 块清理	❌ 不涉及	✅ 前轮 extended thinking 自动剥离
MCP Schema 优化	❌ 全量加载工具定义	✅ 工具定义超过上下文 10% 时延迟加载，改用搜索发现
手动压缩	❌ 无	✅ /compact 命令，可定向保留
持久记忆	AGENTS.md + StoreBackend 跨线程持久化	CLAUDE.md（唯一跨压缩存活的内容）

1.4 设计哲学总结

DeepAgent —— “不丢失，只转移”：

• 大结果 → 驱逐到文件
• 压缩前历史 → 写入文件
• 所有被移除的内容均保留 read_file 回溯路径
• 代价：state["files"] 无限膨胀，无主动清理机制

Claude Code —— “分层丢弃，保护核心”：

• 第一层：清除旧工具输出（最大且最不重要）
• 第二层：压缩对话历史
• 第三层：硬错误兜底
• 代价：信息不可恢复，多次压缩后精度逐步稀释

---

问题二：大规模 MCP 工具调用处理

2.1 问题背景

在深度研究场景中，Agent 需要频繁调用 MCP 工具（如代码查询、文件检索），每次调用可能返回数万字符的数据，其中大量内容与当前任务无关。当多次调用堆积后，上下文迅速膨胀，推理质量下降。

2.2 数据进入上下文前：拦截层

维度	DeepAgent	Claude Code
大结果驱逐阈值	80,000 字符（20K tokens x 4）	25,000 tokens（约 100,000 字符）
驱逐方式	写入 /large_tool_results/{id}，替换为首尾各 5 行预览 + 路径提示	写入磁盘，内联截断 + 路径引用
内置工具豁免	ls/glob/grep/read_file 等有独立截断逻辑，不走通用驱逐	所有工具统一处理
<阈值的无效数据	全量进入上下文，无过滤	全量进入上下文，无过滤

核心问题：两者的拦截都是基于大小而非基于相关性。一个 MCP 工具返回了 60K 字符的无关代码（低于两者的驱逐阈值），两个系统都不会拦截，直接进入上下文占用 token。

2.3 数据进入上下文后：消化层

这里是两者差异最大的地方。

DeepAgent 的处理

MCP 工具调用 #1 返回 50K 字符（未触发驱逐）→ 进入上下文
MCP 工具调用 #2 返回 40K 字符（未触发驱逐）→ 进入上下文
MCP 工具调用 #3 返回 60K 字符（未触发驱逐）→ 进入上下文
  ...累计 150K+ 字符的工具输出占满上下文
  │
  ▼ 每轮 LLM 调用都需要处理全部历史工具输出
  │  ⚠️ 无关数据持续干扰推理，且按 token 计费
  │
  ▼ 上下文达 85% → 触发 SummarizationMiddleware
  │
  ├─ Phase 1: 截断旧的 write_file/edit_file 参数
  │  ⚠️ 只处理写入工具的参数，不处理 MCP 工具返回值
  │
  └─ Phase 2: LLM 生成摘要
     ✅ 所有内容（包括无关数据）被压缩为摘要
     ✅ 历史写入 /conversation_history/ 可回溯
     ⚠️ 但之前若干轮的推理成本已浪费

DeepAgent 的弱点：对 MCP 工具返回值没有独立清理机制。只有 write_file/edit_file 的参数会被截断，而 MCP 返回的大段无关代码原封不动留在消息历史中，直到被整体摘要压缩。

Claude Code 的处理

MCP / 工具调用 #1 返回大量数据 → 进入上下文
MCP / 工具调用 #2 返回大量数据 → 进入上下文
MCP / 工具调用 #3 返回大量数据 → 进入上下文
  ...
  │
  ▼ 上下文达 95% → 触发 compaction
  │
  ├─ 第一步: 清除旧工具输出 ← 关键差异
  │  ✅ 不区分 MCP 还是内置工具，所有旧 tool results 直接清空
  │  ✅ 工具输出通常占上下文 80%，这一步往往就能释放足够空间
  │  ❌ 清除后不可恢复
  │
  └─ 第二步: 如仍不够，压缩对话历史

Claude Code 的优势：compaction 的第一步就是无差别清除旧工具输出，这是一个粗暴但高效的策略——旧的工具返回值大概率已经被 LLM 消化为推理结论，原始数据不再需要。

2.4 多轮 MCP 密集调用场景对比

假设一个任务需要调用 20 次 MCP 工具，每次返回约 40K 字符：

阶段	DeepAgent	Claude Code
前 5 次调用	200K 字符进入上下文，推理正常	200K 字符进入上下文，推理正常
第 6-10 次调用	上下文逼近 85%，前 5 次的返回值仍占据空间，新数据与旧数据竞争上下文	上下文逼近 95%，触发 compaction，旧工具输出被清除，释放大量空间
触发压缩后	LLM 对全部内容做摘要，保留 10% 消息。摘要质量取决于 LLM 从 400K+ 字符中提取关键信息的能力	旧工具输出直接删除，保留对话推理链。如仍不够再做对话摘要
第 11-20 次调用	摘要后上下文充裕，但如果再次堆积，需要等待下一轮摘要	compaction 可多次触发，每次优先清工具输出
最终信息质量	✅ 历史可回溯（文件保底） ⚠️ 摘要中混合了有效推理和无效数据的压缩	⚠️ 不可回溯 ✅ 推理链保持清晰（工具输出与推理分离清除）

2.5 对比总结

维度	DeepAgent	Claude Code
拦截策略	仅按大小驱逐（>80K字符）	仅按大小驱逐（>25K tokens）
清理策略	不区分工具输出和对话，统一摘要压缩	优先清除工具输出，再压缩对话
清理粒度	粗粒度（整体摘要）	分层（工具输出 → 对话 → 硬错误）
工具返回值的独立处理	❌ 无（仅处理 write/edit 参数）	✅ compaction 第一步就是清工具输出
信息保全	✅ 压缩前完整落盘，可回溯	❌ 不可恢复
推理链保护	⚠️ 推理链和工具输出一起被摘要，可能丢失推理细节	✅ 工具输出和推理链分离清除，推理链优先保留

2.6 优化建议

针对 DeepAgent 在大规模 MCP 调用场景下的不足，建议：

方案一：降低驱逐阈值

# FilesystemMiddleware 初始化时配置
FilesystemMiddleware(backend=backend, tool_token_limit_before_evict=5000)
# 将阈值从 20000 tokens 降至 5000 tokens（约 20K 字符）
# 更多工具输出会被驱逐到文件，减轻上下文压力

方案二：在工具包装层限制返回长度

MAX_TOOL_RESULT_CHARS = 20000  # 单次工具返回上限

def _safe_wrap(tools):
    for t in tools:
        orig = t.coroutine
        name = t.name

        async def _safe(*args, _orig=orig, _name=name, **kwargs):
            try:
                result = await _orig(*args, **kwargs)
                if isinstance(result, str) and len(result) > MAX_TOOL_RESULT_CHARS:
                    return result[:MAX_TOOL_RESULT_CHARS] + f"\n...(结果已截断，原始长度 {len(result)} 字符)"
                return result
            except Exception as e:
                msg = f"工具 {_name} 调用失败: {type(e).__name__}: {e}"
                return msg

        t.coroutine = _safe
    return tools

方案三：利用子 Agent 天然隔离

将 MCP 密集调用分配给子 Agent，这是最有效的策略：

• 子 Agent 在独立上下文中工作，MCP 返回的无关数据不污染主 Agent
• 子 Agent 完成后只返回精炼的文本结果
• 建议确保所有 MCP 密集操作都在子 Agent 中完成，主 Agent 只做编排和文件写入