智能体演进五阶段：从模型调用到DeepAgents深度解析

智能体开发的五个演进阶段

在过去短短两三年里，AI智能体（Agent）的开发范式经历了剧烈的迭代。从最初的一问一答，到如今的多智能体协同，几乎是一周一个样、一月一个大突破。理解这条演进脉络，是掌握 DeepAgents 这类新框架的前提。

如果从宏观上概括，智能体的发展可以归纳为三大趋势：模型直接调用 → 半自主 Agent → 自主决策的深度智能体。但从微观技术实践看，真正值得拆解的是五个清晰的阶段。下面我们逐一梳理。

第一阶段：程序与模型的纯网络交互

这是「上古时期」的智能体形态。本质上，它只是把人机对话中的「人」替换成了「程序」。开发者只需要掌握一项技术——HTTP 网络请求即可。

早期与大模型交互的方式本质上就是 RESTful API 调用。开发者通过 HTTP POST 请求将提示词（prompt）发送到模型服务端点，服务端返回 JSON 格式的生成结果。这与传统的 Web API 调用（如调用天气接口、支付接口）在技术层面几乎没有区别。唯一的特殊性在于：大模型的输出是非确定性的——同一个输入可能产生不同输出，且输出格式难以精确控制。这就导致了开发者需要花费大量精力在「后处理」环节：正则表达式匹配、字符串截取、JSON 解析容错等。

典型场景如一个「智能考试系统」：程序封装好提示词，通过网络请求发送给大模型（如 Kimi），模型返回结果后，程序再手工解析 JSON、截取校验、存入数据库。智能出题、智能判卷、智能评价，全部依靠程序与模型的一来一回完成。

这一阶段的两大痛点非常明显：没有上下文记忆，每次交互都是一次性的，判卷时还得把所有信息重新塞回提示词；数据解析极其繁琐，需要纯手工约定格式、截取、校验合规性再转 JSON。

第二阶段：框架封装带来的开发便利

随着 SpringAI、LangChain、LangChain4J 等框架陆续涌现，开发进入第二阶段。但需要澄清的是，此时的框架还没有真正的 Agent 概念。

LangChain（Python 生态）和 SpringAI/LangChain4J（Java 生态）属于 LLM 应用开发的中间件框架。它们的核心贡献是抽象了与不同大模型交互的差异性，提供了统一的接口层。其中的消息类型体系（SystemMessage 设定角色、AIMessage 承载模型回复、HumanMessage 承载用户输入、ToolMessage 承载工具返回结果）是对 OpenAI Chat Completions API 消息格式的标准化封装。会话记忆（Memory）机制则通过在每次请求中自动附带历史对话记录来模拟「记忆」，本质上是将历史消息拼接进上下文窗口（Context Window），这也是为什么上下文长度限制（如 4K、8K、128K tokens）会成为关键约束。

它们主要提供了三样东西：多轮对话的会话记忆、提示词的结构化封装（AIMessage、SystemMessage、ToolMessage）、以及便捷的输出解析器。配合原有代码，与模型交互确实变得更简单了。

但本质上，第二阶段只是对第一阶段做了封装，程序依然「有点傻」——你写什么它做什么，缺乏自主性。

从图结构到真正的Agent

第三阶段：LangGraph 实现半自主智能体

第三阶段的核心是 LangGraph（图结构）。理解它需要先分清两个概念：LangChain 是「链」（Chain），像小火车一样一二三四固定往前走；而 LangGraph 是「图」（Graph），是多节点的网状结构。

LangGraph 借鉴了有向图（Directed Graph）和状态机（State Machine）的概念。在图结构中，每个「节点」（Node）代表一个处理单元——可以是一次 LLM 调用、一次工具执行或一段业务逻辑；「边」（Edge）定义了节点间的执行流转关系；「条件边」（Conditional Edge）则根据运行时状态动态决定下一步走向。这种设计模式在工作流引擎（如 BPMN）和数据流编程中早已成熟，LangGraph 的创新在于将其与 LLM 的推理能力结合——条件判断可以由模型输出驱动，而非仅靠硬编码规则。与传统的「链式调用」相比，图结构支持循环（Loop）、分支（Branch）和并行（Parallel），表达能力显著增强。

在这一阶段，开发者可以设定固定节点、设计具体流程，再通过「边」连接节点，甚至设置「条件边」——满足特定条件时跳转到指定节点。由此实现的是一个半自主的 Agent：既有完整流程，又能加入条件控制实现部分智能化处理。

第四阶段：create_agent 与自主工具调用

第四阶段迎来了真正意义上的智能体。LangChain 中的 create_agent 函数创建出的 Agent，配置了模型和若干工具（tools），能够根据传入的提示词自主规划要调用哪些工具。

这一能力的底层技术基础是大模型的 Function Calling（函数调用）机制。这项技术由 OpenAI 在 2023 年 6 月首次引入：开发者在请求中声明可用函数的名称、参数 Schema（JSON Schema 格式），模型在生成回复时如果判断需要调用某个函数，会输出结构化的函数调用指令（包含函数名和参数值），而非直接给出文本答案。程序捕获这个指令后执行对应函数，再将结果回传给模型继续推理。这个机制是 Agent「自主决策」的技术根基——模型不是在执行工具，而是在「决定」调用哪个工具以及传什么参数。

举个直观的例子：一个 Agent 配了四个工具，当提示词是「今晚打老虎」时，它可能自动调用工具 1 和 4；换成另一个提示词，它又会触发工具 1、3、4 的调用。这种「根据提示词动态决策」正是 Agent 智能化的体现。

一个关键认知是：create_agent 的底层依然是 LangGraph 的图。每个工具就是一个节点，Agent 通过模型规划决定调用哪些节点及其顺序，最终动态组装成一张图去执行。区别在于，LangGraph 的图是写死的，而 Agent 的图是由提示词动态生成的。

但这一阶段的短板同样突出：结果不可控。很多人用 AI 编程工具时都遇到过——模型确定一个方案后就「一根筋」往下钻，陷入死循环，反复调用某个工具却始终得不到结果。对此只能通过中间件监控、HITL（人机交互）等干预手段来缓解，比如监控到某工具调用八遍无果后强制退出。

HITL（Human-In-The-Loop，人在回路中）是 AI 系统设计中的一种安全范式。在 Agent 场景下，它指的是在自主执行流程的关键节点插入人类审核或干预环节。典型实现包括：执行高风险操作前请求人类确认、检测到异常循环时暂停并请求人类指导、定期向人类汇报进度并征求反馈。这种机制是对「完全自主」的一种务实妥协——在当前模型能力尚不完美的阶段，HITL 既保留了 Agent 的自动化优势，又通过人类监督降低了失控风险。

DeepAgents：自主决策的多智能体架构

第五阶段：深度多智能体协同

最后一个阶段就是本文的主角——DeepAgents（深度智能体）。名字已透露一切：Deep + Agents，即「深度的多智能体」。

它的核心模式是：一个主智能体（Main Agent）协调若干子智能体（Sub Agent），子智能体下还可以继续嵌套子智能体，同时每个智能体依然可以配置 tools 工具乃至 skills 技能。主智能体不仅能决定调用哪个工具，还能自主决策调用哪个子智能体。这正是 Anthropic 提出的多智能体理念——分而治之。

DeepAgents 与普通 Agent 的本质区别

很多人会疑惑：普通 Agent 也能配一万个工具，和 DeepAgents 有什么区别？关键在于上下文隔离。

普通 Agent 无论配多少工具，它们都属于同一个智能体、共享同一套上下文和同一个模型。这会带来严重问题：假设一个 Agent 既要处理医疗知识库又要处理法律知识库，把不同领域的知识全灌进一个上下文，模型就会出现「专注力不足」——处理单一方向没问题，但混杂多领域后能力反而越来越弱。

从技术层面看，这种「专注力不足」对应的是 Transformer 架构中注意力机制（Attention Mechanism）的稀释效应。模型对输入的每个 token 都会计算与其他所有 token 的注意力权重。当上下文中混入大量不同领域的信息时，模型在处理特定领域问题时的注意力会被无关信息分散，导致推理质量下降。研究表明，即使在上下文窗口容量允许的情况下，过长或过杂的上下文也会导致「中间遗忘」（Lost in the Middle）现象——模型对上下文中间部分的信息提取能力显著弱于开头和结尾部分。

而 DeepAgents 中，每个子智能体的上下文和提示词都是隔离的。可以让一个子 Agent 专攻医疗、一个专攻法律、一个专攻娱乐，主智能体只负责分发调用和结果润色。这本质上是一种解耦行为。

此外还有一个重要优势：不同子智能体可以配置不同模型。普通 Agent 只能选一个模型，若同时要处理文字和图片，就不得不勉强选一个多模态模型，而多模态模型在纯文本处理上未必最优。DeepAgents 则可以让擅长图片的智能体用一个模型、擅长文本的用另一个模型，各司其职，每个单体都很强。

关于它与 A2A、MCP 的关系：DeepAgents 的子智能体调用算是一种 A2A（Agent to Agent），但它是框架内部的方法调用，而非外部协议调用；与 MCP（工具的远程调用协议）类似，但 MCP 是外部协议，DeepAgents 是内在调用。

A2A（Agent-to-Agent）是 Google 在 2025 年提出的开放协议，旨在让不同厂商、不同框架构建的 AI Agent 之间能够相互发现、通信和协作，类似于微服务架构中的服务发现与 RPC 调用。MCP（Model Context Protocol）则是 Anthropic 在 2024 年底推出的开放标准，它定义了 LLM 应用与外部工具/数据源之间的标准化连接方式，可以类比为 AI 领域的「USB 接口」——让任何兼容 MCP 的工具都能被任何兼容 MCP 的 Agent 调用。DeepAgents 框架内部的子智能体调用虽然在概念上类似 A2A，但它是进程内的方法调用（in-process），无需网络通信开销和协议协商，效率更高但也意味着耦合度更强。理解时可以先把它看作框架内部的 Agent 间调用即可。

实现自主智能体的两大驱动力

要真正搭建自主的多智能体系统，需要两个核心驱动力。

驱动力一：深度代理框架

第一是把智能体「捏到一起」的框架，也就是 DeepAgents。它带来的最大改变是——执行过程不再是一次性输出，而是具备「规划、执行、反馈、迭代」的完整闭环。

这种闭环执行模式源自经典的控制论（Cybernetics）反馈回路和认知科学中的 OODA 循环（观察-定向-决策-行动）。在 AI Agent 研究中，这种模式被称为 ReAct（Reasoning + Acting）范式的进阶版本。ReAct 让模型交替进行「思考」和「行动」，而 DeepAgents 进一步引入了显式的规划层（Plan）和反思层（Reflect）。这与 2023 年以来学术界提出的多项研究成果一脉相承，如斯坦福的 Generative Agents 使用「反思」机制、Princeton 的 Tree of Thoughts 使用「搜索」策略。核心思想是：让 Agent 不只是「执行」，还要「规划」和「自我纠错」，从而在复杂任务中表现出更接近人类的问题解决能力。

举例来说，处理任务时框架会先规划路线（如「只用工具 1、3、4」），执行中若工具 3 报错，它会把错误反馈给模型，模型再次迭代规划出新路线（如改走「1、4」）。整个过程会根据每次提示词和执行情况动态调整，这与我们使用 AI 编程工具时生成 to-do list 再逐步执行的体验高度一致。

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

第二是提示词写法的升级。传统提示词告诉模型「要做什么」（如「帮我写一段代码」）；而高阶提示词则是告诉模型「你有什么」——你拥有哪些工具、哪些模型，整个处理流程大概是怎样的规则。

打个比方：传统提示词是打工人思维，老板让干啥就干啥；高阶提示词则是全盘规划思维，你只需说清目标、可用资源和过程规则，剩下的具体工具调用交由 DeepAgents 框架根据实际问题自主决策。

不过需要坦诚的是，高阶提示词并不好写，即便是资深开发者也需要不断打磨。

理性看待智能体框架热潮

最后需要提醒的是：智能体领域的技术名词层出不穷，几乎一天一个新概念、一月一个爆款框架。但很多概念其实是「换汤不换药」，只是叫法不同、本质类似，不必被眼花缭乱的术语误导。

同时，DeepAgents 虽好却并非万能——它有明确的适用场景，也有自身缺点。演进到第五阶段并不意味着前面的模式全被淘汰，LangGraph 等仍会在 RAG 知识库等项目中继续发挥作用。掌握每个阶段的适用边界，才是真正的进阶之道。

核心要点