DeepAgents实战：多智能体的五个进化阶段详解

从模型调用到深度多智能体

短短数年，人工智能领域一天一个样，智能体（Agent）技术更是以周为单位在迭代。要真正理解 DeepAgents 这类多智能体框架的价值，我们需要先梳理清楚智能体技术的完整演进脉络。

据一位从2024年上半年就深度参与智能体开发的开发者分享，智能体的发展从宏观上可以归纳为三大趋势：从一问一答的模型调用，到具备自主规划能力的 Agent，再到能自主决策、协调多个子智能体的深度智能体（DeepAgent）。而如果细化拆解，这个过程实际经历了五个技术周期。

本文将沿着这五个周期，梳理智能体技术是如何一步步从「上古时期的手工调用」进化到「分而治之的多智能体协作」，并重点解析 DeepAgents 框架的核心设计理念。

第一至第三周期：从手工调用到半自主图

周期一：程序与大模型的裸交互

最早期的智能体，本质上只是把「人与大模型对话」中的人替换成了程序。开发者需要做的事情很简单——只要会 HTTP 网络请求即可。程序封装好提示词，通过网络请求发给大模型（如 Kimi），拿到返回结果后再做 JSON 解析并存入数据库。

这套模式曾被用来实现一个「智能考试系统」，包括智能出题和智能判卷。但这个上古时期的方案缺点非常明显：没有上下文记忆，一次交互结束就失去了所有对话信息；数据解析极其麻烦，需要纯手工约定返回格式、截取、校验、转换，繁琐且脆弱。

周期二：LangChain等框架封装带来便利

随着 LangChain（Python）、LangChain4j、Spring AI（Java）等框架陆续涌现，开发进入第二周期。这些框架在初期还没有真正的「智能体」概念，主要提供了多轮会话记忆、消息包装（AIMessage、SystemMessage、ToolMessage）和数据解析器等能力。

此时调用模型、组装提示词、解析结果都变得更简单，但程序本质上仍是对第一周期的封装——你写什么它做什么，谈不上智能。

周期三：LangGraph 与半自主智能体

第三周期的代表是 LangGraph。理解它与 LangChain 的区别，关键在于两个单词：Chain 是「链」（线性往前走的流程），Graph 是「图」（多节点连接的结构）。

LangGraph 允许开发者设定固定节点、设计具体流程，并通过普通边和条件边（虚拟边）来控制节点跳转，从而实现一个半自主的智能体。此时已有完整流程，也能加入条件控制实现自主化处理，但整个流程图仍然是相对写死的。

LangGraph 的「图」结构在实现上借鉴了有向无环图（DAG）与状态机的思想。每个节点代表一个处理单元（可以是模型调用、工具执行或自定义函数），边则定义了节点间的数据流向。「条件边」的核心是一个判断函数——它接收当前节点的输出，返回下一个应该跳转的节点名称，从而实现分支和循环。这种设计使得「当某条件满足时重试」「失败时走备用路径」等逻辑得以用图结构表达。相比 LangChain 中 Chain 的线性结构，Graph 能建模更复杂的工作流，但仍需开发者预先定义所有可能的节点和跳转规则，智能体本身并不能在运行时「凭空」创造新节点，这正是它被称为「半自主」的原因。

第四周期：create_agent 与真正的自主规划

第四周期的标志，是 LangChain 中的 create_agent 函数。这才真正创建出了一个「智能体」。

一个关键认知是：create_agent 的底层，用的其实还是 LangGraph 的图。深入源码会发现，它最终依然是图结构。

那 Agent 的智能体现在哪里？一个 Agent 可以配置一个模型和若干 tools。执行时，它会根据传入的提示词自主规划应该调用哪些工具以及调用顺序。举个例子，同样一批工具，提示词说「今晚打老虎」可能触发工具1和4，换成「今天打秦琼」可能触发工具1、3、4。每个 tool 本质上就是一个 LangGraph 节点，Agent 根据模型反馈决定调哪些节点、以什么顺序连边，最终动态组装成一张图去执行。

这也是当前大多数开发者停留的阶段。但它有个绕不开的问题——结果不可控。结合重度使用 AI 编程工具的实际体验来看，智能体有时会「犯轴」：确定一个方案后就死磕到底，陷入无限死循环，反复调用同一个工具、反复修改同一个文件。目前只能通过 HITL（Human-in-the-Loop，人机交互）和中间件来干预，比如监控到某工具连续调用八遍还没结果，就强制退出。

HITL（Human-in-the-Loop）是一种在自动化流程中设置人工介入节点的工程模式。在智能体场景下，它通常以「检查点（checkpoint）」的形式实现：框架在特定条件（如工具连续失败 N 次、置信度低于阈值、检测到敏感操作）下暂停执行，将当前状态序列化并等待人工确认或修正后再继续。LangGraph 原生支持持久化状态与断点恢复，这使得 HITL 在实践中具有可操作性。中间件层面的干预则更偏向被动监控——通过拦截工具调用日志、统计重复调用次数来触发熔断，本质上是在 Agent 的执行循环外套了一层保护壳，以应对当前模型规划能力不足导致的「死循环」问题。

第五周期：DeepAgents 分而治之的多智能体架构

从单 Agent 到多 Agents 协作

最后一个周期叫 DeepAgent——注意名字里的玄机，从 agent 变成了 agents，从单数变成了复数。它体现的是一个深度多智能体架构。

其典型模式是：一个主智能体（main agent）下可以配置若干子智能体（sub agent），子智能体还能继续嵌套子智能体，每个智能体同样可以配置 tools 工具乃至 skills 技能。主智能体不仅能决定调用哪个工具，还能自主决策调用哪个子智能体。

很多人看到这里会联想到 Java 中的微服务概念，或者 A2A（Agent to Agent）协议。这个类比是对的——DeepAgent 本质上也是智能体之间的调用，只不过它比微服务更强：能自主决策调用哪些子智能体；也不同于外部协议式的 A2A，它是框架内部的调用，相当于方法调用。而 Anthropic 提出的多智能体理念，其本质正是「分而治之」。

A2A（Agent-to-Agent）协议是 Google 于2025年提出的开放标准，旨在让不同厂商、不同框架构建的智能体能够通过标准化接口互相调用，类似于微服务领域的 OpenAPI 规范。它通过「Agent Card」描述智能体的能力元数据，调用方据此发现并委托任务给目标智能体，通信基于 HTTP/SSE。与之对比，DeepAgents 框架内的子智能体调用是进程内的直接方法调用，没有网络序列化开销，也不需要服务发现机制。两种方式并非互斥：A2A 适合跨组织、跨系统的智能体协作，而框架内置的多智能体调用则更适合同一应用内的高内聚场景，延迟更低、状态共享更方便。

DeepAgents相比单Agent多工具的核心优势

有人会问：既然单个 Agent 也能配很多 tools，为何还需要 DeepAgent？关键区别在于两点：

第一，上下文隔离。单个 Agent 配再多工具，这些工具都属于同一个智能体，共享同一套上下文和同一个模型。当你既要做医疗知识库又要做法律知识库，把不同领域的知识全灌进一个上下文，模型会出现「专注力不足」的问题——处理的方向越多、上下文越杂，能力反而越弱。而 DeepAgent 中，每个子智能体的上下文和提示词都是相互隔离的，本质上是一种解耦行为。

第二，模型异构。单个 Agent 只能配一种模型。如果功能既涉及文本处理又涉及图片处理，你不得不选一个多模态模型，但多模态模型未必在文本上表现最优。而 DeepAgent 可以为不同子智能体配置不同的模型，实现「不同智能体对应不同系统提示词、不同模型、处理不同能力，每个单体都很强」。

实现自主智能体的两个核心驱动力

要真正做出一个自主的多智能体系统，需要两个核心驱动力的配合。

驱动力一：深度代理框架的闭环能力

DeepAgents 这类框架负责把多个智能体「捏到一起」。与传统一次性输出不同，它具备规划、执行、反馈、迭代的完整闭环能力。

具体来说：面对一个任务，框架会先规划路线（如「只用工具1、3、4」）；执行过程中若工具3报错，它会把失败反馈给模型；模型据此重新迭代规划（如改走「工具1、4」）。整个执行过程不再是写死的固定流程，而是根据每次提示词动态调整——这与使用 AI 编程工具时看到的 to-do list 逐步执行、自主规划如出一辙。

驱动力二：高阶提示词（HOPS）

有了框架能力，提示词的写法也需要同步升级。

传统提示词告诉模型「要做什么」，比如「帮我写一段 Java 代码」，明确目标即可。**高阶提示词（HOPS，High-Order Prompt Strategy）**则不直接说做什么，而是告诉模型「你有什么」以及「大致流程」——你有哪些工具、哪些模型可以调用，遵循什么规则，然后让框架自己决定具体如何规划执行。

用一个形象的比喻来理解二者差异：传统提示词是「打工人思维」——让干啥就干啥，没有自主决策；高阶提示词则是「老板思维」——给出全盘规划（比如「公司当前市值十亿，目标涨到二十亿，我们有哪些手段和资源」），只描述过程思维，具体执行交给深度代理框架去动态调度。

不过需要注意的是，高阶提示词并非一两天能练成，它需要开发者对智能体框架有较深的理解。

高阶提示词（HOPS）在工程实践中通常包含几个固定模块：角色与目标（该智能体的定位和最终目的）、可用资源清单（列举所有可调用的工具、子智能体及其能力边界）、决策规则（遇到特定情况应优先使用哪类工具、何时应向上级智能体汇报）、输出约束（格式、语言、安全红线）。与传统提示词相比，HOPS 更像是一份「岗位说明书」而非「任务清单」。这种写法要求开发者对整个系统的能力拓扑有清晰认知，否则给出的资源描述不准确，反而会让模型规划出错误路径。这也是为什么作者强调「需要对智能体框架有较深的理解」才能驾驭高阶提示词。

写在最后：辩证看待智能体技术演进

你可能没注意到，不要被满天飞的新概念误导：智能体领域「一天一个新名词，一周一个大技术」，但很多概念其实是换了一种说法的已有技术。

更重要的是，DeepAgent 并非万能，前面的技术周期也不会被完全抛弃。比如在构建 RAG 知识库项目时，LangGraph 仍然是更合适的选择，而不一定需要用到 DeepAgents——因为 DeepAgent 也有其适用边界，某些场景下反而不如更简单的方案。

技术演进是叠加而非替代。理解这五个周期的来龙去脉，比盲目追逐最新框架更有价值。