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

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

1.1 上下文压缩策略

维度DeepAgentClaude 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 设计上思路一致——上下文隔离是深度研究的核心机制,但共享程度不同:

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

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

1.3 额外的上下文优化手段

手段DeepAgentClaude 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 数据进入上下文前:拦截层

维度DeepAgentClaude 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 字符:

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

2.5 对比总结

维度DeepAgentClaude 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 只做编排和文件写入
Logo

有“AI”的1024 = 2048,欢迎大家加入2048 AI社区

更多推荐