DeepAgent 论文精读：当 Agent 能在推理过程中自己找工具、用工具、折叠记忆，会发生 - sdk社区

论文名称： DeepAgent: A General Reasoning Agent with Scalable Toolsets
会议： The ACM Web Conference 2026（WWW ’26）
研究方向： Large Reasoning Model、Autonomous Agent、Tool Retrieval、Memory Mechanism、Reinforcement Learning
核心关键词： DeepAgent、Autonomous Tool Search、Memory Folding、ToolPO、Long-Horizon Agent、Open-set Tool Retrieval
主推理模型： QwQ-32B
辅助模型： Qwen2.5-32B-Instruct

1. 前言：这篇论文真正想改变的不是“工具数量”，而是 Agent 的控制方式

近两年，Agent 已经能够搜索网页、调用代码执行器、访问 API，并完成越来越复杂的多步任务。但很多 Agent 的底层控制逻辑仍然是一个预先设计好的 Workflow：什么时候规划、什么时候调用工具、可以使用哪些工具、什么时候压缩上下文，往往都由框架提前规定。

DeepAgent 的出发点并不是“再加一个工具”，而是重新思考一个更本质的问题：

如果 Large Reasoning Model 已经具备很强的推理能力，为什么还必须由外部工作流替它决定下一步该做什么？

于是，DeepAgent 将“思考、搜索工具、调用工具、折叠记忆”都统一为模型可以自主产生的动作，让 LRM 在一条连续的推理流中自己决定：

下一步继续思考？
还是搜索工具？
找到工具后是否调用？
当前探索路线是否需要放弃？
历史是否应该折叠？
任务是否已经完成？

同时，论文提出 ToolPO，通过强化学习同时训练“最终任务做对”和“中间工具调用做对”。

如果只用一句话概括 DeepAgent：

DeepAgent 把「思考 → 动态找工具 → 调工具 → 处理反馈 → 必要时折叠记忆」统一进一个连续的推理过程。

2. 为什么现有 Agent 范式还不够？

论文指出传统 Agent 主要存在四个瓶颈。

2.1 执行步骤和整体流程缺乏自主性

ReAct 的经典逻辑是：

Reason → Act → Observe → Reason → Act → Observe

它非常有效，但整体节奏仍由外部框架规定。复杂任务可能需要中途改变策略、重新寻找工具、放弃错误路线，而固定循环不一定能充分发挥 Reasoning Model 的全局决策能力。

2.2 任务过程中不能动态发现新工具

当工具只有几个时，可以全部放进 Prompt；但当 Toolset 扩展到几千甚至 16k+ API 时，一次性暴露所有工具既昂贵又会产生大量无关上下文。

更现实的问题是：任务开始时认为需要的工具，不一定等于任务进行到一半时真正需要的工具。

因此 DeepAgent 希望实现：

推理到哪一步
→ 发现当前缺少某种能力
→ 此时再搜索工具

而不是“任务开始前只检索一次”。

2.3 长交互历史缺乏自主记忆管理

长任务会不断累积：

旧的工具返回；
错误探索路径；
已完成子任务；
重复信息；
过时计划。

如果这些内容一直保留在 Context 中，不仅 Token 越来越多，错误路线也可能持续影响后续推理。

DeepAgent 因此让模型自己决定什么时候触发 Memory Folding。

2.4 对整项任务的全局推理深度与连贯性不足

复杂 Agent 任务真正需要持续回答：

已经完成了什么？
哪些路线失败了？
现在真正缺什么？
哪些工具已经验证可用？
下一步是否应该换策略？

DeepAgent 的目标是让 LRM 对整个任务保持连续、全局的推理视角。

3. Traditional Agent → Deep Research → DeepAgent

3.1 Traditional Agent：固定工作流 + 固定工具

User Task
   ↓
Predefined Workflow
   ↓
Fixed / Pre-retrieved Tools
   ↓
Iterative Execution

模型负责局部决策，框架负责整体节奏。

3.2 Deep Research Agent：推理更深，但工具通常有限

Deep Research 类 Agent 已经能把：

Web Search
Page Browsing
Code Execution

插入长推理链，但常见 Toolset 仍偏“研究工具”。

3.3 DeepAgent：连续推理中按需发现可扩展工具集

DeepAgent 允许：

Think
→ Search Tool
→ Call Tool
→ Think
→ Search Another Tool
→ Call Tool
→ Fold Memory
→ Think Again

关键变化是：

固定流程 / 固定工具 → 连续推理中按需发现 Scalable Toolsets。

4. 论文贡献：三个机制 + 一套系统评测

整篇论文可以沿着“推理 → 记忆 → 训练 → 评测”理解：

部分	解决的问题	核心设计
DeepAgent	Agent 如何真正自主行动	Think / Search / Call / Fold
Memory Folding	长任务如何管理历史	Episodic / Working / Tool Memory
ToolPO	怎样把正确工具行为训练出来	Tool Simulator + Advantage Attribution
Experiments	方法是否真的有效	开放工具、长任务、跨 Backbone

一句话概括：

DeepAgent 改推理范式，Memory Folding 解决长视程，ToolPO 解决“怎么把这种行为训练出来”。

5. 整体框架：DeepAgent 到底怎么运行？

5.1 Main Reasoning Process

主 LRM 在同一条推理流中自主决定：

思考
  ↓
是否需要工具？
  ├─ 否 → 继续推理
  └─ 是 → 搜索工具
              ↓
          调用工具
              ↓
          观察反馈
              ↓
          继续推理

如果任务走入错误路线或阶段性完成，可以：

Fold Memory
    ↓
Start a New Round

5.2 Memory Folding

历史被压缩成：

Episodic Memory
Working Memory
Tool Memory

然后替换原始 Interaction History，重新开始下一轮推理。

5.3 ToolPO Training

训练同时考虑：

最终任务是否成功
+
中间工具调用是否正确
+
Memory Folding 是否有效

因此模型学习的不只是“最后答对”，而是“怎样通过正确动作把任务做对”。

6. 形式化：把 Agent 看成一个序列决策过程

设当前状态为 (s_t)，它表示此前全部 Action 与 Observation 历史。

模型根据状态 (s_t)、用户问题 (Q)、系统指令 (I) 选择下一步动作：

$encoding="application/x-tex">a_t \sim \pi_\theta(\cdot \mid s_t,Q,I) </annotation></semantics></math>$

整条轨迹为：

$encoding="application/x-tex">\tau=(s_1,a_1,o_1,\ldots,s_T,a_T,o_T) </annotation></semantics></math>$

最终目标是学习：

$encoding="application/x-tex">\pi_\theta^* = \arg\max_{\pi_\theta} \mathbb{E}_{\tau\sim\pi_\theta} [R(\tau)] </annotation></semantics></math>$

这一形式化很重要，因为一旦 Tool Search、Tool Call 和 Memory Fold 都进入 Action Space，它们就可以被端到端 RL 优化。

7. DeepAgent 的四类核心动作

Think：内部思考

分析当前任务、已有证据和下一步策略。

Search：工具搜索

模型产生：

<tool_search>
自然语言工具需求
</tool_search>

从大规模 Toolset 中检索候选工具。

Call：工具调用

模型生成：

<tool_call>
{
  "name": "tool_name",
  "arguments": {...}
}
</tool_call>

系统执行后把结果送回推理上下文。

Fold：记忆折叠

模型生成：

<fold_thought>

触发 Memory Folding。

关键点：Fold 不是系统后台偷偷压缩，而是模型自己可以主动触发的 Action。

8. 核心模块一：Autonomous Tool Search & Calling

8.1 为什么不能把所有工具一次性塞给模型？

当 Toolset 扩展到 16k+ API 时，每个工具都包含：

name
description
parameters
required fields
parameter descriptions

全部放进 Prompt 会造成严重 Context 开销和无关工具干扰。

DeepAgent 的答案是：

工具在需要时检索，而不是全部预加载。

8.2 工具搜索流程

产生需求
   ↓
<tool_search> query
   ↓
Dense Retrieval
   ↓
Top-k Relevant Tools
   ↓
Auxiliary LLM过滤/总结
   ↓
返回主推理上下文

8.3 Dense Retrieval

工具文档 (d_i) 预先建立 Embedding：

$encoding="application/x-tex">E(d_i) </annotation></semantics></math>$

查询 (q_s) 也进行 Embedding：

$encoding="application/x-tex">E(q_s) </annotation></semantics></math>$

根据余弦相似度取 Top-k：

T_{retrieved} = \operatorname{top-k}_{\tau_i\in T} \left( sim(E(q_s),E(d_i)) \right)

论文使用：

bge-large-en-v1.5

作为 Retriever。

8.4 为什么需要 Auxiliary LLM？

Auxiliary LLM 主要承担三件事：

工具文档太长时，过滤和总结；
工具返回太冗余时，去噪和压缩；
Memory Folding 时生成结构化记忆。

因此：

Main LRM → 高层策略与任务推理
Auxiliary LLM → 信息压缩、整理、模拟工具

主实验中：

Main LRM：QwQ-32B
Auxiliary LLM：Qwen2.5-32B-Instruct

8.5 与“一次性工具预检索”的本质区别

传统：

任务开始
→ 检索一批工具
→ 固定工具集合
→ 开始执行

DeepAgent：

推理
→ 搜索工具A
→ 调用A
→ 得到新信息
→ 发现还需要B
→ 再搜索工具B
→ 调用B

也就是说，工具发现本身就是推理过程的一部分。

9. 核心模块二：Autonomous Memory Folding

如果 Tool Search 解决“工具太多”，Memory Folding 解决的是“历史太长”。

当模型输出：

<fold_thought>

Auxiliary LLM 会并行生成：

$encoding="application/x-tex">(M^E,M^W,M^T) = f_{compress}(s_t;\theta_{aux}) </annotation></semantics></math>$

分别对应：

Episodic Memory；
Working Memory；
Tool Memory。

然后：

原始长历史
   ↓
三类结构化记忆
   ↓
替换原始历史
   ↓
开启新的推理轮次

10. Episodic / Working / Tool Memory 分别记什么？

10.1 Episodic Memory：长期任务进度

回答：

这项任务一路发生了什么？
哪些重大决策已经做过？
哪些子任务完成了？
当前总体进度怎样？

主要字段：

{
  "task_description": "...",
  "key_events": [
    {
      "step": "...",
      "description": "...",
      "outcome": "..."
    }
  ],
  "current_progress": "..."
}

10.2 Working Memory：当前状态

回答：

现在具体在做什么？
当前障碍是什么？
下一步是什么？

主要字段：

{
  "immediate_goal": "...",
  "current_challenges": "...",
  "next_actions": [...]
}

10.3 Tool Memory：可复用工具经验

总结：

用过哪些工具；
哪些调用成功；
哪些参数有效；
常见错误；
工具返回模式；
可复用规则。

也就是说，它不是简单存“结果”，而是在存工具使用经验。

11. 为什么固定 JSON Schema 很重要？

如果只让模型：

“总结上面的历史”

自由文本很容易把长期进度、当前目标和工具经验混在一起。

固定 Schema 有两个主要作用：

结构稳定，容易被下一轮模型解析；
比自由摘要更容易降低关键信息压缩丢失。

当然，它不能彻底消除信息损失，但能使 Memory Folding 更可控。

12. Memory Folding 不只是“省 Token”

Memory Folding 还有一个更重要的功能：

让 Agent 从错误探索路线中跳出来。

例如：

错误方向A
→ 调工具
→ 结果不对
→ 继续围绕A搜索
→ 历史越来越长
→ 旧思路不断影响新判断

此时 Fold 可以：

记录A已经失败
保留真正有效的信息
明确当前障碍
重新列出下一步

所以 Memory Folding 同时承担：

Context Compression
+
Strategy Reset

13. 核心模块三：ToolPO

前两个模块定义了 DeepAgent 应该怎样行动，但还剩一个问题：

模型怎样学会正确地搜索工具、调用工具和折叠记忆？

这就是 ToolPO 要解决的核心问题。

14. 为什么普通 Agentic RL 不够？

论文指出两个现实难题。

14.1 Challenge 1：真实 API 做 RL 太不稳定

如果 Rollout 直接依赖成千上万个真实 API，会遇到：

网络波动；
服务状态变化；
Rate Limit；
调用费用；
第三方 API 异常；
结果随时间变化。

这会让强化学习环境难以复现，并污染 Reward。

14.2 解决方案：LLM-based Tool Simulator

作者使用 Auxiliary LLM 模拟真实 API 的返回。

Policy Model
   ↓
Tool Call
   ↓
LLM Tool Simulator
   ↓
模拟 API Result

这样可以获得：

更稳定的训练环境；
更低调用成本；
更高 Rollout 效率；
更容易扩展到大规模 Toolset。

需要注意：

Simulator 主要服务于训练稳定性，并不意味着真实部署时可以完全不接真实工具。

15. Challenge 2：只看最终结果，中间 Tool Call 的 Reward 太稀疏

假设一条轨迹中有 10 次 Tool Call。

最终答案错了，不代表 10 次调用都错；最终答案偶然对，也不代表每一步调用都合理。

如果只使用 Final Reward，模型就很难知道：

哪次工具调用值得鼓励？
哪个参数是正确的？
哪个 Memory Fold 有帮助？

因此 ToolPO 引入：

Tool-call Advantage Attribution

对工具调用和 Memory Fold 做更细粒度的 Credit Assignment。

16. ToolPO 的两类 Reward

对于同一个输入，系统采样 (K) 条轨迹：

$encoding="application/x-tex">\{\tau_1,\ldots,\tau_K\} </annotation></semantics></math>$

ToolPO 定义两类 Reward。

16.1 Task-success Reward

$encoding="application/x-tex">R_{succ}(\tau) </annotation></semantics></math>$

衡量最终任务是否成功，例如最终答案是否正确、环境目标是否完成。

16.2 Action-level Reward

$encoding="application/x-tex">R_{action}(\tau) = \lambda_1 \sum_{t=1}^{T} C(a_t^{call}) + \lambda_2S_{pref}(\tau) </annotation></semantics></math>$

其中：

C(a_t^{call}) = \begin{cases} 1,& \text{工具调用正确}\\ 0,& \text{否则} \end{cases}

而 Memory Folding 的效率偏好项为：

$encoding="application/x-tex">S_{pref} = \frac{ L(\tau_{direct})-L(\tau_{fold}) }{ L(\tau_{direct})+L(\tau_{fold}) } </annotation></semantics></math>$

直观理解：

正确 Tool Call → 加分
有效、节省轨迹的 Memory Fold → 加分

论文设置：

$encoding="application/x-tex">\lambda_1=\lambda_2=1 </annotation></semantics></math>$

17. 两个 Group-relative Advantage

任务成功 Advantage：

$encoding="application/x-tex">A_{succ}(\tau_k) = R_{succ}(\tau_k) - \frac{1}{K} \sum_{j=1}^{K} R_{succ}(\tau_j) </annotation></semantics></math>$

表示当前轨迹最终任务表现相对同组 Rollout 好多少。

Action-level Advantage：

$encoding="application/x-tex">A_{action}(\tau_k) = R_{action}(\tau_k) - \frac{1}{K} \sum_{j=1}^{K} R_{action}(\tau_j) </annotation></semantics></math>$

表示当前轨迹的工具与 Fold 行为相对同组 Rollout 好多少。

18. 真正关键：Token-level Advantage Attribution

ToolPO 最关键的公式是：

$encoding="application/x-tex">A(y_i) = A_{succ}(\tau_k) + M(y_i)\cdot A_{action}(\tau_k) </annotation></semantics></math>$

其中：

$encoding="application/x-tex">M(y_i)=1 </annotation></semantics></math>$

仅当 Token (y_i) 属于：

Tool-call Token；
Memory-fold Token。

否则：

$encoding="application/x-tex">M(y_i)=0 </annotation></semantics></math>$

这意味着：

所有生成 Token

都得到：

$encoding="application/x-tex">A_{succ} </annotation></semantics></math>$

保证模型仍然围绕最终任务目标学习。

Tool Call / Memory Fold Token

额外得到：

$encoding="application/x-tex">A_{action} </annotation></semantics></math>$

精准强化过程动作。

其他 Thinking Token

不直接获得局部 Action Reward，避免某个工具调用分数错误扩散给整个思考链。

因此 ToolPO 的本质可以写成：

最终任务做对了吗？
        +
中间工具行为做对了吗？
        ↓
在 Token 层精确合并

它真正处理的是复杂 Agent RL 中的 Credit Assignment 问题。

19. ToolPO 的优化目标

ToolPO 使用 clipped surrogate 目标：

L_{ToolPO}(\theta) = \mathbb{E}_{\tau_k} \left[ \sum_i \min \left( \rho_i(\theta)A(y_i), \operatorname{clip} (\rho_i(\theta),1-\epsilon,1+\epsilon) A(y_i) \right) \right]

其中：

$encoding="application/x-tex">\rho_i(\theta) = \frac{ \pi_\theta(y_i\mid y_{<i},s) }{ \pi_{\theta_{old}}(y_i\mid y_{<i},s) } </annotation></semantics></math>$

重点并不是公式本身，而是：

Global Task Reward 和 Local Action Reward 被分开计算，再在 Token 层按类型合并。

20. 训练数据：规模不大，但覆盖能力广

论文训练数据大约 4.6k 实例，覆盖四类能力：

能力	数据	规模
General Tool-Use	ToolBench	1k labeled + 1k retrieval
Real-World Interaction	ALFWorld + WebShop	500 + 500
Deep Research	WebDancer + WebShaperQA	200 + 500
Mathematical Reasoning	DeepMath	0.9k

可以看到，训练目标并不是只学习“API 调用”，而是同时覆盖：

工具规划；
环境交互；
深度检索；
Web 任务；
数学与代码推理。

21. 核心实现参数

配置	设置
Main LRM	QwQ-32B
Auxiliary LLM	Qwen2.5-32B-Instruct
Retriever	bge-large-en-v1.5
ToolPO Steps	100
Batch Size	64
Rollout K	8
Max Sequence Length	32,768（训练）
Max Generation Tokens	81,920（实验生成设置）
Max Actions	50
Training Framework	VeRL
Compute	64 × NVIDIA H20-141GB

一个很有意思的点是：

训练样本规模并不巨大，但 Agent RL 的长序列、多 Rollout 和环境交互让计算成本非常高。

22. 实验设计：既测“会不会用工具”，也测“能不能完成真实长任务”

论文实验分成两大类。

22.1 General Tool-Use

主要评估：

Tool Planning；
Tool Retrieval；
多步 Tool Calling；
大 Toolset 可扩展性。

包括：

Benchmark	工具规模 / 特征
ToolBench	16k+ APIs
API-Bank	73 APIs
TMDB	54 tools
Spotify	40 tools
ToolHop	3,912 tools，每题 3–7 次调用

并设置两种条件：

Ground-truth Tools
Open-set Tool Retrieval

其中 Open-set 更接近现实，因为 Agent 必须从完整工具库中自己发现工具。

22.2 Downstream Applications

更关注长视程真实任务：

ALFWorld： 文本具身环境；
WebShop： 搜索 + 点击完成购物任务；
GAIA： Search、Browser、VQA、Code、File Reading；
HLE： 高难推理，可能组合 Code、Search、Browsing、VQA。

这些任务要求：

状态跟踪
+
错误恢复
+
长交互
+
多工具协调

23. 关于“8 个 Benchmark”的口径

论文正文称“8 benchmarks”，但列出的任务名看起来有 9 个：

ToolBench
API-Bank
TMDB
Spotify
ToolHop
ALFWorld
WebShop
GAIA
HLE

原因是：

TMDB 和 Spotify 是 RestBench 的两个子场景，按 Benchmark 家族统计时 RestBench 计为一个。

这是阅读时比较容易困惑的地方。

24. 主结果一：一般工具使用

Ground-truth / labeled tool 场景

代表性结果：

TMDB：DeepAgent-32B-RL = 89.0
最强 32B workflow baseline = 55.0

Spotify：DeepAgent-32B-RL = 75.4
最强 32B workflow baseline = 52.6

提升分别约为：

TMDB：+34.0
Spotify：+22.8

Open-set 场景

代表性结果：

ToolBench：DeepAgent-32B-RL = 64.0
代表性 32B 强基线 = 54.0

ToolHop：DeepAgent-32B-RL = 40.6
代表性 32B 强基线 = 29.0

提升：

ToolBench：+10.0
ToolHop：+11.6

25. 为什么 Open-set 结果特别重要？

现实中系统不会提前告诉 Agent：

“这题就用 Tool A、Tool B、Tool C。”

更真实的情况是：

这里有几千甚至上万个工具
你自己决定该找哪个

因此 Open-set 才真正测试：

模型有没有能力在推理过程中按需发现工具。

而 DeepAgent 的优势在大 Toolset 中更加明显。

26. 动态工具检索 vs 预先检索

论文专门比较了：

Input Retrieved Tool
vs
Autonomous Tool Retrieval

平均结果：

方法	预先检索	推理中动态检索
ReAct	22.4	28.0
Plan-and-Solve	24.2	28.5
DeepAgent	42.0	52.6

DeepAgent 从：

42.0 → 52.6

提升 10.6。

说明：

工具检索并不一定只能作为任务开始前的预处理，它可以成为推理过程本身的一部分。

27. 主结果二：下游长任务

与同为 QwQ-32B 的 HiRA 对比：

Task	HiRA	DeepAgent-32B-RL	提升
ALFWorld Success	84.3	91.8	+7.5
WebShop Success	23.2	34.4	+11.2
GAIA All	42.5	53.3	+10.8
HLE All	13.6	20.2	+6.6

这部分更能体现：

连续 Agentic Reasoning；
Memory Folding；
ToolPO；

对长视程任务的价值。

28. ToolPO 能否迁移到长任务？

对比 Base 与 RL：

GAIA：46.7 → 53.3
ALFWorld：88.1 → 91.8

说明 ToolPO 学到的工具行为并不只服务 ToolBench，而能迁移到复杂交互环境。

29. 一个必须避免的误读：HLE 并不是全模型总体 SOTA

DeepAgent-32B-RL：

HLE All = 20.2

而论文表中 OpenAI o3：

26.6

因此更严谨的说法是：

DeepAgent-32B-RL 在 32B 级别模型中整体非常强，而不是对所有更大或闭源模型全面领先。

30. 消融实验：三个核心机制到底有没有用？

Method	ToolBench	ToolHop	WebShop	GAIA	Avg.
DeepAgent-32B-RL	64.0	40.6	34.4	53.3	48.1
w/o Training（Base）	60.0	38.4	32.0	46.7	44.3
w/o Memory Folding	63.0	36.6	32.4	44.7	44.2
w/o Tool Simulation	62.0	35.2	33.6	48.5	44.8
w/o Tool Adv. Attribution	62.0	39.6	33.2	49.5	46.1

去掉 ToolPO Training

平均：

48.1 → 44.3

说明端到端 RL 对整体工具与任务能力有明显贡献。

去掉 Memory Folding

平均：

48.1 → 44.2

GAIA：

53.3 → 44.7

说明 Memory Folding 对长视程任务非常关键。

去掉 Tool Simulator

平均：

48.1 → 44.8

支持“稳定模拟环境有利于 Tool RL”的判断。

去掉 Tool-call Advantage Attribution

平均：

48.1 → 46.1

说明只使用最终 Task Reward 不够，局部工具行为的细粒度归因确实有效。

一个小口径问题

正文称移除 Training 带来“最显著”的下降，但表中：

w/o Training = 44.3
w/o Memory Folding = 44.2

从平均数看 Memory Folding 反而低 0.1。

这是非常轻微的文字与表格口径差异，不影响整体结论，但论文精读时值得指出。

31. ToolPO vs GRPO：训练动态说明了什么？

论文 Figure 4 显示：

ToolPO 的 Reward 上界更高；
Validation Score 更高；
ToolPO 的训练 Reward 波动更小。

作者据此认为：

Tool Simulator
+
细粒度 Tool-call Process Supervision

让 Agentic RL 更稳定、更有效。

32. Action Limit：任务越长，DeepAgent 的优势是否还存在？

论文改变最大 Action 数，在 WebShop 与 GAIA 上比较 DeepAgent 与 ReAct。

主要观察：

两种方法都随 Action Limit 增大而改善；
DeepAgent 全程领先；
WebShop 中 Action Limit 越大，DeepAgent 与 ReAct 差距越明显。

这意味着：

复杂任务确实需要更长的交互 Horizon，但只允许“更多步”不够，Agent 还必须会有效使用这些步骤。

否则：

更多 Action
=
更多无效尝试

DeepAgent 想实现的是：

更多 Action
+
更自主的策略
+
更好的记忆管理

33. 换 Backbone 后还能成立吗？

论文额外测试：

Qwen3-30B-A3B-Thinking；
Qwen3-235B-A22B-Thinking。

结果：

Backbone	ReAct Avg.	Plan-and-Solve Avg.	DeepAgent Base Avg.
Qwen3-30B-A3B	35.7	37.0	46.9
Qwen3-235B-A22B	45.1	46.0	55.7

说明：

DeepAgent 的 Agentic Reasoning 增益并不依赖单一 QwQ-32B。

模型规模扩大后，方法收益依然保留。

34. Appendix 多工具案例：DeepAgent 到底怎样“边想边找工具”？

论文给出的案例可以简化为：

任务需要 Vimeo documentary
        ↓
<tool_search>
搜索 Vimeo 工具
        ↓
选择 search_videos
        ↓
<tool_call>
按 cinema tag 检索
        ↓
提取 creator
        ↓
继续推理
        ↓
发现还需要验证 YouTube ID
        ↓
再次搜索 / 调用 YouTube 工具
        ↓
构造 streaming link
        ↓
整合最终答案

这个 Case 的意义不是“API 本身很复杂”，而是：

Agent 可以在同一个任务里反复发现需求、搜索不同工具、调用工具并继续利用反馈。

35. DeepAgent 真正强在哪里？

结合论文原文、方法、实验和消融，DeepAgent 最值得关注的并不是某一个单独模块，而是它把 Agent 的控制权进一步交给了 Reasoning Model。

35.1 把工具检索从“预处理步骤”变成“推理动作”

传统：

先检索工具
→ 再开始推理

DeepAgent：

推理过程中
→ 什么时候需要
→ 什么时候搜

这使它更适合 Open-set 和大规模 Toolset。

35.2 把 Context Compression 变成模型 Action

传统：

系统发现 Context 太长
→ 外部自动摘要

DeepAgent：

模型判断当前需要重构历史
→ 主动 Fold

Memory Management 因而不再只是工程优化，而成为 Agent Reasoning 的组成部分。

35.3 把 Final Reward 与 Local Tool Reward 分开

ToolPO 不再假设：

最终答案正确
=
每个中间动作都正确

而是只把局部 Action Advantage 分配给 Tool-call / Memory-fold Token。

这是长轨迹 Agent RL 中非常重要的 Credit Assignment 思路。

35.4 评测同时覆盖“工具能力”和“真实任务能力”

论文没有只看 API Benchmark，而是同时验证：

大规模工具检索
多步 Tool Calling
Embodied AI
Shopping
General Assistant
Hard Reasoning

因此证据链比单一 Tool Benchmark 更完整。

36. 这篇论文还有哪些问题值得继续追问？

以下部分属于基于论文架构、实验设置以及 PPT 解析进一步得到的技术思考，不是作者在正文中逐条给出的结论。

36.1 Tool Simulator 与真实 API 仍可能存在 Simulator-to-Real Gap

LLM Simulator 可以模拟常见 API 输出，但真实服务还会包含：

Rate Limit；
Authentication；
Timeout；
服务宕机；
API Version Change；
动态网页；
随机错误码。

因此，Simulator 对训练稳定性很重要，但真实生产环境仍可能出现训练中没有覆盖的复杂噪声。

36.2 Tool Retrieval 依赖 Tool Documentation 质量

Dense Retrieval 的基础是：

Query Embedding
vs
Tool Documentation Embedding

如果工具文档本身：

描述模糊；
参数解释缺失；
同义表达不足；
功能边界不清；

Retriever 就可能成为新的瓶颈。

也就是说，DeepAgent 并没有让“工具选择问题”完全消失，而是把问题转化为：

工具文档是否足够可检索？
检索模型是否能找到真正相关的工具？

36.3 Memory Folding 仍然有压缩信息损失风险

固定 JSON Schema 可以降低信息丢失，但任何压缩都意味着：

完整历史
→ 更短表示

如果 Auxiliary LLM 错误地删除了未来真正重要的信息，新一轮推理可能无法恢复。

未来可以继续研究：

Fold 后保留 Evidence Pointer；
可回溯原始 History；
Memory Confidence；
分层 Memory Retrieval；
Memory Consistency Check。

36.4 训练成本非常高

论文训练数据只有约 4.6k 实例，但使用：

64 × NVIDIA H20-141GB

因为成本来自：

32B Reasoning Model；
长 Context；
多条 Rollout；
Agent Environment；
Tool Simulation；
RL 更新。

因此，DeepAgent 并不是一个低成本、容易复现的 Agent RL 方案。

36.5 权限、安全、审计与工具副作用不是主要评测重点

真实生产 Toolset 可能包含：

发邮件；
删除文件；
修改数据库；
支付；
企业内部操作。

这时除了“调用是否正确”，还需要处理：

有没有权限？
高风险动作是否需要确认？
错误调用如何回滚？
如何审计？
如何隔离第三方工具？

论文主要关注 General Tool Use 与 Agent Performance，这些生产级安全问题仍是后续落地必须补上的部分。

37. DeepAgent 和普通 RAG 有什么区别？

两者都可能使用：

Embedding
→ Retrieval
→ Context

但检索对象不同。

RAG 检索的是“知识”

例如：

问题
→ 找相关文档
→ 把文档作为上下文
→ 生成答案

DeepAgent Tool Retrieval 检索的是“能力”

例如：

任务需要一种能力
→ 找到对应 API / Tool
→ 生成调用参数
→ 真正执行

因此可以简单理解为：

RAG 解决“我需要知道什么”，Tool Retrieval 更偏向解决“我需要用什么能力去做”。

38. DeepAgent 和 ReAct 的本质区别

ReAct：

Reason → Act → Observe

DeepAgent 并不是完全抛弃这个逻辑，而是把动作空间继续扩展：

Reason
  ↓
Search Tool?
  ↓
Call Tool?
  ↓
Observe
  ↓
Fold Memory?
  ↓
Continue Reasoning

最重要的区别不是“多了几个节点”，而是：

这些行为不再完全由外部 Workflow 规定，而是主 LRM 自主决定何时触发。

39. DeepAgent 和 Deep Research 的区别

Deep Research 类系统已经能够进行很深的搜索与分析，但工具通常集中于：

Search
Browser
Code

DeepAgent 讨论的是：

Scalable Toolsets

包括：

RapidAPI 16k+；
ToolHop 3.9k；
TMDB；
Spotify；
Robotics；
Shopping；
自定义工具。

所以它关注的是：

如何让 General Reasoning Agent 面对任意规模 Toolset 时仍能自主发现和使用工具。

40. 这篇论文最值得复用的研究思路

40.1 先重新定义 Agent Action Space，而不是只堆系统模块

很多 Agent 设计会不断加入：

Planner
Critic
Memory
Retriever
Tool Router

DeepAgent 更进一步问：

为什么不能让主 Reasoning Model 自己决定什么时候执行这些行为？

于是：

Tool Search
Tool Call
Memory Fold

都进入了 Policy Action Space。

40.2 把长上下文问题转化成“主动压缩决策”

Memory Folding 不再只是 Context Engineering，而是一个决策问题：

什么时候压缩？
压缩什么？
怎样保留长期进度？
压缩后是否应该换策略？

40.3 Agent RL 必须解决细粒度 Credit Assignment

只有 Final Reward 很难指导几十步 Agent 轨迹。

ToolPO 的启示是：

Task-level Reward
+
Action-level Reward
+
Token-level Attribution

复杂 Agent RL 不能只关心“最后答对没有”。

40.4 Agent 评测必须同时覆盖基本工具能力和真实下游任务

只测 ToolBench：

不知道长任务能否完成

只测 GAIA：

又很难定位工具模块究竟强在哪里

DeepAgent 的两层评测同时回答：

它会不会找工具、用工具？
+
它能不能用这些能力完成真实长任务？