从普通 Agent 到 Deep Agents：复杂任务的能力演进

一个基础 Agent 的结构并不复杂：

01User
02  ↓
03Model
04  ↓
05Tool
06  ↓
07Model
08  ↓
09Answer

模型判断下一步做什么，需要外部能力时调用 Tool，拿到结果后继续推理，直到任务完成。

像搜索资料、查询数据库、调用 API，使用这套结构已经能处理很多任务。

然而，实际任务中有很多更为复杂的任务。比如：

调研 20 个 AI Coding Agent 产品，分别整理产品定位、技术特点、商业模式和融资情况，最后形成一份完整报告。

搜索工具依然能用，但 Agent 面临的问题已经不只是搜索。

它还要知道哪些产品已经完成，哪些资料仍然缺失；保存大量中间结果；控制不断增长的 Context；处理多个独立任务；必要时还要读写文件、运行代码。

Deep Agents 主要就是为了解决这些复杂任务中的工程问题。

一个基础 Agent 的核心可以概括为：

01Model
02+
03Tools
04+
05Agent Loop

Model 负责判断下一步。

Tools 负责执行操作。

Agent Loop 让这个过程持续运行。

例如，用户要求查询 Python 的最新变化。Agent 可以先搜索，发现资料不足后继续搜索，最后整理结果。

这里最关键的机制是：模型根据当前状态决定下一步操作。

对于步骤较少、信息量有限的任务，这套结构已经足够。

问题并不是普通 Agent 无法执行更多步骤。只要允许循环，它同样可以连续调用很多次 Tool。

真正的限制来自任务复杂变长以后不断增加的状态。

仍然以调查 20 个产品为例。

Agent 可能连续执行几十次搜索：

01Cursor
02Claude Code
03Codex
04Copilot
05Windsurf
06……

搜索并不困难。

困难的是搜索之后产生的状态：

01Cursor：已完成
02Claude Code：缺融资资料
03Codex：已完成
04Copilot：待补充
05Windsurf：未开始

同时还会产生大量官网内容、产品文档、新闻、价格信息和分析结果。

如果这些内容不断进入 Context，执行过程很容易变成：

01调用 Tool
02   ↓
03结果进入 Context
04   ↓
05继续调用
06   ↓
07更多结果进入 Context
08   ↓
09Context 持续增长

假设每个产品产生 5000 Token 的资料，20 个产品就可能达到十万 Token 量级。

即使模型支持足够大的上下文，也没有必要在调查第 20 个产品时，重新读取前 19 个产品的全部原始资料。

这时，问题已经从：

01下一步调用哪个 Tool？

逐渐变成：

01任务进行到了哪里？
02资料放在哪里？
03哪些信息应该留在 Context？
04哪些工作可以独立处理？
05失败以后从哪里继续？

复杂 Agent 的难点，开始从 Tool Calling 转向整个执行过程。

Deep Agents 没有改变 Agent 最基本的工作方式。

模型仍然负责推理，Tool 仍然负责执行。

底层依然是：

01Model
02  ↓
03Tool
04  ↓
05Model

而在这个循环之外，Deep Agents 还增加了一套运行与控制机制。

LangChain 将 Deep Agents 定义为一种 Agent Harness。

Harness 可以理解为围绕模型建立的一套运行支撑层。

模型负责判断：

01现在应该做什么？

Harness 则负责处理：

01在哪里工作？
02资料怎样保存？
03Context 怎样控制？
04任务怎样分开？
05代码在哪里运行？
06哪些操作需要人工确认？

因此，Deep Agents 的重点并不是创造一种新的推理方式。

它解决的是：怎样给 Agent 提供一个适合复杂任务的工作环境。

一个基础 Agent 可以简化为：

01Model
02  │
03  ├── Tools
04  │
05  └── Agent Loop

Deep Agents 则在外面增加更多运行能力：

01                 Model
02                   │
03              Agent Loop
04                   │
05        ┌──────────┼──────────┐
06        │          │          │
07      Tools     Filesystem  Subagents
08        │          │          │
09        └──────────┼──────────┘
10                   │
11        Context Management
12                   │
13         Memory / Skills
14                   │
15        Sandbox / Approval

这些能力大致解决以下几类问题：

• 行动能力：搜索、查询数据库、调用 API、修改外部系统，主要由 Tools 提供。

• 工作空间：长任务会产生大量文件和中间结果，需要独立于 Context 的地方保存。

• 上下文管理：模型每次推理只需要当前步骤相关的信息，没有必要始终携带全部历史资料。

• 任务隔离：大型任务往往包含多个相对独立的部分，可以交给不同 Subagent，在独立 Context 中完成。

• 执行控制：当 Agent 可以修改文件、运行代码甚至操作外部系统后，还需要 Sandbox、权限和人工确认。

这些能力组合起来，才构成一个更完整的 Agent 工作环境。

从基础 Agent 到 Deep Agent，可以看到一层明显的变化。

最开始只有：

01Model
02+
03Tools

主要解决两个问题：

01模型下一步做什么？
02模型怎样操作外部系统？

任务变复杂后，还会出现：

01任务状态
02工作空间
03上下文
04子任务
05执行环境
06持久化
07权限控制

于是 Agent 的结构逐渐变成：

01Model
02+
03Tools
04+
05Workspace
06+
07Context Management
08+
09Task Delegation
10+
11Execution Environment
12+
13Control

这里没有哪一个组件单独代表 Deep Agent。

真正重要的是，它们共同支撑一个能够持续工作的 Agent。

这也是 Agent Harness 这个概念的核心。

并不是所有 Agent 都需要这些能力。

如果一个 Agent 只有几个 Tool，一次请求几秒钟就能完成，也不会产生大量中间资料，那么增加文件系统、Subagent 和执行环境通常没有多少收益。

Deep Agents 更适合另一类任务：

• 步骤较多，执行时间较长；
• 中间产生大量资料或文件；
• Context 开始成为实际限制；
• 存在多个相对独立的子任务；
• 需要读写文件或运行代码；
• 任务可能中断后继续；
• 部分操作需要人工确认。

典型场景包括 Deep Research、Coding Agent、大型文档处理和长期自动化任务。

它们的共同特点并不是 Tool 更多。

而是：

执行过程本身已经成为系统的一部分。

普通 Agent 已经解决了一个关键问题：

让模型能够根据任务选择并调用外部工具。

对于大量应用，这已经足够。

但当任务持续更久，开始产生大量资料、状态和文件，并涉及代码执行、子任务、持久化和权限时，仅靠 Model、Tools 和不断增长的 Context 会越来越难管理。

Deep Agents 在这里增加了一层完整的运行支撑。

它没有替代 Agent Loop，也没有改变 LLM 的基本推理方式。

变化的是 Agent 所处的环境。

从一次 Tool Calling，到可以保存资料、管理上下文、分配任务、运行代码并持续执行，Agent 才开始具备处理复杂长任务所需要的工程基础。

这也是理解 Deep Agents 最重要的一点：它关注的不只是模型下一步做什么，更关注一个复杂任务怎样持续执行。

下一篇，我们继续进入这个 Harness 内部，看看一个 Deep Agent 到底是怎样运行起来的。