type
Post
status
Published
date
Mar 28, 2026
slug
deepagents-001
summary
DeepAgents 框架核心（1）
tags
Agent
category
DeepAgents
icon
password
开篇引入
在过去短短数年间，人工智能的形态正经历一场层层递进的深刻演化。它从最初仅能 “响应问题” 的大型语言模型（LLM），逐步迭代为具备 “调用工具、落地执行” 能力的 AI Agent，如今更朝着拥有协作意识、可驾驭复杂工作流的 Agentic AI 加速迈进。这条演进路径绝非简单的功能叠加，而是一条从 “语言理解能力” 到 “自主行动能力”，再到 “智能组织与协作能力” 的质变之路 —— 几乎构筑起未来智能应用的核心主轴。
为突破现有技术瓶颈，两个关键概念在研究与实践领域迅速崛起并成为核心驱动力 —— 深度代理（Deep Agents）与高阶提示（Higher-Order Prompts, HOPs）。
在深度代理的架构中，模型不再是 “一次性输出答案” 的黑盒，而是化身具备 “规划 - 执行 - 反馈 - 迭代” 闭环能力的智能主体：
- 面对复杂任务时，先将其拆解为可落地的子目标；
- 为每个子目标匹配专属的子代理（sub-agent），实现专业化分工；
- 执行过程中实时监控各步骤产出，精准识别偏离目标的异常；
- 基于执行结果动态调整计划、替换策略，或生成新的子任务以补全链路；
- 当出现错误时，通过反思（reflection）机制回溯问题根源，修正执行路径。
而高阶提示（HOPs）则聚焦于 “教会模型如何思考”：如果说深度代理是智能系统的 “组织架构师”，负责搭建任务执行的骨架，那么高阶提示就是 “认知规范师”，定义思考与推理的底层逻辑。
- 传统提示：告诉我做什么。
分析下面这条用户评论，判断情绪是正面、负面还是中性，并给出改进建议。评论：“这个软件经常卡顿，打开要等很久，界面也不好看，用起来很烦躁。”
- 高阶提示：告诉我怎么想、按什么步骤、用什么逻辑。
- 先逐句提取事实：用户提到了哪些具体问题？
- 再判断情绪：根据关键词判断是正面 / 负面 / 中性，并给出理由。
- 按问题严重程度排序：从最影响体验到最轻。
- 每条问题对应给出可落地的改进建议，不要空泛。
- 最后用一句话总结核心痛点。
请按以下固定思考流程分析用户评论：
评论：“这个软件经常卡顿，打开要等很久，界面也不好看，用起来很烦躁。”
传统提示偏向 “直接下达结果指令”，而高阶提示则更进一步，它向模型传递的是 “思考框架与推理范式”—— 明确告知模型该如何分析问题、如何拆解逻辑、如何组织思考过程，从根源上提升决策的精准度与执行的可靠性。
一、DeepAgents 框架核心
1.1 DeepAgents介绍和作用
构建能够规划、使用子代理并利用文件系统处理复杂任务的代理(深度智能体)
DeepAgents是一个独立库，建立在 LangChain代理核心构建模块之上（关系类似于：SpringBoot和Spring Framework）！主要实现自主多智能体系统（Agentic AI）！DeepAgents是构建由大型语言模型（LLM）驱动的代理和应用的最简单方式——内置任务规划功能、用于上下文管理的文件系统、子代理生成和长期记忆。可以用它完成复杂、多步骤、切自主规划的任务。
家族框架对比：
三者并非单向引用，有时会出现循环调用场景！！
- LangChain (Framework)：做 “动作”，是核心的代理框架。它封装了 LLM 与工具的交互，提供灵活的代理结构，但不包含规划、记忆或文件系统，适合开发者自己定制逻辑。
- LangGraph (Runtime)：管 “流程”，是外层的运行时。它把执行变成可管理的图结构，支持循环、并行和持久化，保障智能体执行的稳定与可控。
- DeepAgents (Harness)：负责 “组织”，是最外层的工具包。它内置规划器、子代理、文件系统和持久存储，让智能体从 “能执行” 升级为 “能组织、能管理、能记忆” 的深度智能体。
功能横向对比：
LangChain、LangGraph、Deep Agents 使用场景总结：
- 何时使用 LangChain？
- 你想快速构建代理与自主应用。
- 你需要对模型、工具、代理循环提供标准抽象。（单Agent）
- 你需要易用且灵活的开发框架。
- 你在开发简单直接的代理应用，无复杂编排需求。
- 何时使用 LangGraph？
- 你需要对代理编排做细粒度、底层控制。
- 你需要持久化执行，支持长时间运行、有状态的代理。
- 你在构建结合确定性步骤与智能代理步骤的复杂工作流。
- 你需要可直接用于生产环境的代理部署基础设施。
- 何时使用 Deep Agents SDK？
- 你在构建长期运行、持续运营、自主规划的智能代理。
- 你在构建需要处理复杂、多步骤任务的代理。
- 你需要使用预定义工具：如文件系统操作、自定义工具、自动化上下文工程等。
- 你希望直接使用预设提示词与子代理能力。
1.2 DeepAgents核心能力
核心能力一： 智能规划与任务分解 (最核心智能协调体现！避免传统的工作流)
DeepAgents 内置write_todos工具，使代理能够：
- 将复杂任务分解为离散的执行步骤
- 实时跟踪任务执行进度
- 根据新信息动态调整执行计划
例如：你要 “办一场生日派对”，DeepAgent 不会上来就瞎忙活，而是先帮你列个清晰的待办清单：
- 确定派对时间 / 地点 → 2. 邀请朋友 → 3. 买食材 / 蛋糕 → 4. 布置场地 → 5. 准备游戏
执行过程中，它还会实时标记 “已完成 / 未完成”，比如发现蛋糕店没开门，会自动把 “买蛋糕” 改成 “换一家店”，甚至新增 “订外卖蛋糕” 的步骤 —— 完全像个有经验的策划师，把复杂事拆成一步步能落地的小事，还能灵活调整。
提示:
write_todos 不是 Python 原生的函数，而是 DeepAgents 框架内置的一个 “工具函数” —— 你可以把它理解成：DeepAgent 自带的一个 “待办清单生成器”，专门让智能体把复杂任务拆成一条条可执行的待办事项，并且能把这些事项存起来、DeepAgent 还配了其他工具进行调整todos：
read_todos：智能体执行任务时，用来 “读取” 当前的待办清单，知道下一步该做啥；
update_todos：执行中发现需要调整步骤（比如 “检索资料” 需要加 “筛选权威来源”）来修改清单；
delete_todos：删掉不需要的步骤（比如报告写完后，删掉 “检查完整性” 的重复项）。
核心能力二：高效上下文管理（最实用的 “内存扩容” 方案！避免上下文溢出）
DeepAgents 内置文件系统工具集（ls、read_file、write_file、edit_file），使代理能够：
- 将大型上下文信息卸载到外部存储
- 有效防止上下文窗口溢出问题
- 处理可变长度的工具执行结果
就像你要 “整理 100 页的年度工作总结”，你的大脑（对应代理的上下文窗口）只能同时记住 10 页内容，多了就会忘前忘后。DeepAgent 会帮你准备一个 “专属文件柜”：
- 先把 100 页总结拆成 10 个文件存在柜里 → 2. 看第 1-10 页时，只把这 10 页拿在手里 → 3. 看完后放回，再取 11-20 页 → 4. 整理出的要点先写在草稿纸（临时文件）里，最后汇总成最终版本
执行过程中，它还会灵活管理文件：比如查到一份 5 万字的 AI 行业数据，不会硬塞进 “大脑”，而是用
write_file 存到文件柜，需要某段数据时，用 read_file 精准调取；想看看存了哪些文件，用 ls 列一下；发现数据有误，用 edit_file 直接修改 —— 完全像个会整理文件的助理，让 “大脑” 只装当前要用的信息，既不超载，也不丢东西。提示: 这套文件系统工具集不是简单的 “本地文件操作”，而是 DeepAgents 封装的跨存储工具 —— 你可以把它理解成：DeepAgent 自带的 “智能文件管家”，专门帮代理管理超出 “大脑容量” 的信息，支持本地文件、云存储（OSS/S3）等多种存储方式，还能和其他工具联动。
核心能力三：子代理生成机制（最灵活的 “分工协作” 模式！避免主代理超负荷）
DeepAgents 内置task工具，使代理能够：
- 选择对应的子代理处理特定任务
- 实现上下文隔离，保持主代理环境整洁
- 深入执行复杂的子任务流程
就像你要 “装修一套房子”，你（主代理）不会既当设计师、又当瓦工、还当水电工，而是找专业的人干专业的事：
- 派 “设计子代理” 出装修图纸 → 2. 派 “施工子代理” 按图纸砌墙 / 铺砖 → 3. 派 “水电子代理” 装水管 / 电路 → 4. 你只负责统筹进度、汇总结果
执行过程中，子代理还能独立工作：比如设计子代理只关注 “风格、尺寸、配色”，不会被施工细节干扰；施工子代理出了问题（比如墙面不平），只会自己调整，不会影响你和水电子代理的工作 —— 完全像个会 “招兵买马” 的项目经理，把复杂任务拆给专业的 “帮手”，自己只做全局把控。
核心能力四：长期记忆能力（最持久的 “记忆存储” 系统！避免代理 “失忆”）
DeepAgents 利用 LangGraph 的 Store 功能，使代理能够：
- 为代理扩展跨线程(协程)持久内存
- 保存和检索历史对话信息
- 支持多会话间的知识共享
就像你要 “持续跟进一个客户的需求”，你不会每次和客户聊天都从头问 “你想要什么功能”，而是有一个 “客户档案本”：
- 第一次聊天记录客户 “想要红色的产品、预算 5000 元” → 存进档案本 → 2. 一周后聊天，先翻档案本记住之前的需求 → 3. 新聊的 “要加定制 logo” 也补充进去 → 4. 同事跟进时，也能看这个档案本，不用你再转述
执行过程中，这份记忆还能跨场景用：比如你在电脑上和客户聊的需求，换手机登录后，代理还能查到档案本；多个同事（多代理）跟进同一个客户，都能共享这份档案 —— 完全像个带 “永久档案柜” 的客服，不管过多久、换什么设备，都能记住之前的信息。
1.3 DeepAgents快速入门
快速构建第一个 Deep Agent：**一个能够自主联网搜索并撰写报告的“AI 研究员”**会借用Tavily网络搜索工具！
步骤1：安装依赖
步骤2：配置 API Key
确保你拥有 LLM 和 Tavily (搜索) 的 API Key。位置：
.env步骤3：定义搜索工具
DeepAgents 需要通过工具与外部世界交互。我们先定义一个简单的联网搜索工具。
位置：
tavily_tools.py步骤4：创建 Deep Agent
通过
create_deep_agent 工厂函数，将工具和 System Prompt 组装成一个智能体。步骤5：运行并获取结果
总结
result['messages']：定位到存储全流程对话的列表；
[-1]：精准抓取列表最后一条（Agent 整理后的最终回复）；
.content：过滤掉所有冗余属性，只取纯文本回复内容。
1.4 DeepAgents流式处理结果解析（重点）
深度代理基于 LangGraph 的流基础设施构建，提供一流的子代理流支持。当深度代理将工作委派给子代理时，你可以独立从每个子代理处流式更新——实时跟踪进展、LLM 令牌和工具调用
解读返回结果：
场景 1：智能体前置处理（before_agent 节点）
节点名：
PatchToolCallsMiddleware.before_agent核心含义：接收用户输入，格式化 / 校验消息
场景 2：模型思考（决定调用工具）（model 节点）
节点名：
model核心含义：大模型分析问题，决定调用工具 / 子代理（无直接回答）
子智能体：
name="task"，args 含 subagent_type/description；自定义工具：
name=工具名，args 含工具自有参数（如query）；场景 3：模型后置钩子（after_model 节点）
节点名：
TodoListMiddleware.after_model核心含义：模型执行完成的空钩子（无实际业务数据）
场景 4：工具 / 子代理执行（tools 节点）
节点名：
tools核心含义：执行工具调用，返回外部数据（如天气、搜索结果）
场景 5：模型生成最终回答（model 节点）
节点名：
model核心含义：模型基于工具结果，生成自然语言最终回答
1.5 子代理Subagents和多智能体
1.5.1 多智能体理解
多 Agent 系统（Multi-Agent System, MAS）是由多个具备自主性、反应性、目标导向性的智能体（Agent）组成的协作体系，通过标准化通信与协同机制，共同完成单一智能体无法独立应对的复杂任务。
简单解释，就是将复杂任务，拆解成多个子任务，分发给专长的Agent进行处理，最后综合结果！本质分而治之！！
维度 | 单体模型（注意力稀释法则） | 多智能体（分而治之的极效） |
核心问题 | 同一个模型需处理多领域知识（如医学 + 法律），不同领域信息互相污染，推理能力断崖式下跌 | 将任务物理拆解，由专业 Agent 分别处理独立并行子任务，多方处理独立任务，性能优势极大提升！ |
组织类比 | 一人全栈（精力分散、专业度不足） | 专业敏捷团队（分工明确、各司其职） |
核心逻辑 | 注意力资源被多领域任务稀释，导致认知过载 | 分布式算力 + 专业化分工，突破单体模型的物理天花板 |
1.5.2 多智能体弊端
多智能体系统在实现分而治之的性能飞跃的同时，必然伴随两大灾难级代价，成为落地的核心阻碍：
Token 消耗的指数级失控
单体模型仅需承担自身推理的 Token 成本，而多 Agent 系统的核心交互逻辑是Agent 间的上下文互通。当多个 Agent 为完成协同任务，频繁互传长文本上下文、进行多轮循环复读时，Token 消耗会呈指数级暴涨。
更致命的是，无约束的群聊式交互可能在极短时间内爆 API 额度，直接导致成本失控，甚至成为中小团队落地多 Agent 的核心经济门槛。应对这一代价的关键，在于建立拦截基准线—— 对简单任务直接拒绝多 Agent 协作，强制使用单 Agent 或者 标准图流程，从源头控制交互规模。
调试成为噩梦：非确定性与全链路黑箱
多 Agent 系统的 “涌现性” 同时带来了不可控性：Agent 间的交互是非线性的，系统崩溃并非单一节点故障，而是像城市交通连环撞车一样，由多步交互的连锁反应引发，且难以复现。
传统的单 Agent 日志调试方式完全失效，若未搭建全链路追踪（Tracing） 体系，出现问题时既无法定位根因，也无法复盘交互过程，直接导致系统上线后风险极高。因此，“不建全链路追踪录像，绝不上线” 成为多 Agent 落地的硬性底线，这也是保障系统稳定性与可维护性的核心前提。
代价类型 | 核心问题 | 具体表现 | 风险阈值 / 特征 | 应对底线 / 策略 |
账单被击穿 | Token 消耗失控 | Agent 间频繁互传长文本上下文，Token 消耗呈指数级增长，无节制的交互对话极易快速耗尽 API 额度 | 短时间内激增 | 建立拦截基准线，简单任务严禁触发多智能体流程，控制交互文本长度 |
调试成为噩梦 | 系统非确定性与不可追溯 | 群智网络伴随 “非确定性”，系统崩溃场景复杂且无规律，难以定位根因，如同城市红绿灯瘫痪引发连环事故 | 多 Agent 交互出现不可复现的异常、全链路无日志追踪 | 不建全链路追踪录像（Tracing）绝不上线，强制记录交互日志 |
1.5.3 用多智能体的三条铁律
这三条铁律本质上是多智能体系统的 “入场许可”，只有满足其中至少一条，才值得我们承担多 Agent 带来的成本与复杂度代价：
- 问题极度开放：这类任务没有标准答案或固定流程，比如 “制定企业年度战略”“开放式科研探索”，单体模型容易陷入局部最优，而多智能体可以通过多角色探索不同方向，动态调整路径。
- 存在领域冲突：当任务需要跨两个及以上专业领域时（比如 “医疗 + 法律”“金融 + 工程”），单体模型的注意力会被分散，导致推理精度断崖式下跌。多智能体通过物理隔离不同领域 Agent，避免知识污染，保障各模块专业度。
- 需要多方向并行：任务天然可以拆分为多个互不依赖的子任务（比如 “多源数据采集”“多版本方案并行设计”），多智能体可以利用分布式算力并行执行，大幅缩短整体耗时，实现 “1+1>2” 的效率提升。
只有符合这些条件时，多智能体才是 “宝贝”；否则，强行使用只会让系统陷入 “毒药“ 般的成本与调试困境。
铁律名称 | 核心场景 | 详细说明 |
问题极度开放 | 高复杂度、无固定路径任务 | 问题复杂度过高，无法事前硬编码死路径，需要在执行过程中灵活转向、探索旁支 |
存在领域冲突 | 多领域混杂任务 | 当混淆领域达到两个以上时，单体模型会因注意力稀释导致表现下滑，必须物理隔离不同领域专家的推理上下文 |
需要多方向并行 | 天然可拆解为独立路径的任务 | 任务天然要求沿多条独立路径同时并行推进，采用多体架构并行处理可带来极显著的性能耗时收益 |
1.5.4 多智能两种架构模式
模式一：层级工作流 (Hierarchical / Orchestrator-Workers)
别名 ：指挥官模式、主从模式 核心逻辑 ： 中央集权 。有一个“大脑”负责思考和分派任务，其他 Agent 只是干活的“手”。
- 运作方式 ：
- 输入 ：用户给出一个复杂任务（比如“写一份新产品的上市策划案”）。
- 主脑 (Orchestrator) ：主管 Agent 收到任务，它不直接干活，而是分析任务，把它拆解成几个子任务（如：市场调研、创意设计、文案撰写）。
- 分发 ：主管把子任务分发给对应的 垂直领域专家 Agent （Worker）。
- 执行 ：Worker Agent 并行或串行工作，产出结果返还给主管。
- 整合 ：主管汇总所有结果，整合成最终报告输出。
- 优点 ：
- 可控性强 ：主脑掌控全局，知道进度，方便纠错。
- 逻辑清晰 ：上下级关系明确，就像传统的公司组织架构。
- 缺点 ：
- 单点故障 ：主脑如果挂了或判断失误，整个任务就崩了。
- 通信瓶颈 ：所有信息都要经过主脑中转。
模式二：协作工作流 (Collaborative / Network)
别名 ：网状模式、专家会诊模式 核心逻辑 ： 去中心化 。没有绝对的领导，大家都是平等的专家，坐在一起开会讨论，互相交换信息。
- 运作方式 ：
- 输入 ：用户给出一个开放性问题（比如“评估这家公司的投资价值”）。
- 共享 ：任务被扔到一个“共享会议室”（Shared State/Context）。
- 自组织 ：不同的专家 Agent（定价、产品、财务、合规）根据自己的专长，从“会议室”里拿取信息，进行分析。
- 交互 ：Agent 之间可以直接交流。比如财务 Agent 算出成本太高，直接告诉定价 Agent 调整价格，不需要经过领导批准。
- 收敛 ：最后通过一个 评估者 (Evaluator) 或规则来决定什么时候讨论结束，输出最终方案。
- 优点 ：
- 灵活性极高 ：适合解决极其复杂、没有标准答案的问题。
- 涌现能力 ：不同的专家碰撞可能产生意想不到的创新解法。
- 缺点 ：
- 容易失控 ：Agent 之间可能陷入无休止的争论（死循环）。
- 难以调试 ：很难追踪到底是谁做出的关键决策。
DeepAgents ** 是典型的层级/指挥官模式**，而 AutoGen 是典型的去中心化/网状协作模式（像群聊头脑风暴），CrewAI可以构建任意一种模式。
框架 | 核心模式 | 协作形态 | 适用场景 | 复杂度 |
DeepAgents (MetaGPT) | **层级工作流 ** | 流水线：角色分工明确，按预定义顺序（如：PM->架构师->工程师）传递任务。 | 标准化流程：如软件开发全流程、长篇报告撰写。 | 中等 |
AutoGen | **协作工作流 ** | 群聊/网状：所有 Agent 在一个群里，根据上下文自动接话，自由交互。 | 开放性探索：多角色头脑风暴、复杂问题求解、代码自动修正。 | 低 (开箱即用) |
CrewAI | 混合模式 | 层级+委派：主要是层级任务，但允许 Agent 自主委派子任务给别人。 | 通用任务：既有流程控制，又需要一点灵活性的场景。 | 低 |
1.5.5 DeepAgents子代理入门
深度代理可以创建子代理来委派工作。你可以在
子代理参数中指定自定义子代理。子代理用于上下文隔离（保持主代理上下文的干净）以及提供专业指令。
子代理解决了上下文膨胀问题 。当代理使用输出较大的工具（如网页搜索、文件读取、数据库查询）时，上下文窗口会迅速被中间结果填满。子代理将这些详细工作隔离开来——主代理只接收最终结果，而非产生该结果的数十个工具调用。
什么时候使用SubAgent：
- 多步骤任务会让主代理的上下文变得杂乱
- 有需要 “专业技能 / 专属工具” 的环节
比如主代理要做 “股票分析”，其中 “基本面分析” 需要财务工具、“技术面分析” 需要 K 线工具，给这两个环节配专属子代理（带对应工具）
- 需要不同模型能力的任务（多模态）
- 当你想让主Agent专注于高层协调时
什么时候不应使用SubAgent：
- 任务简单，一步就能干完
- 需要中间信息连贯，不能拆
比如 “读一篇文章，然后总结核心观点”，拆给子代理读、再拆给另一个子代理总结，会丢上下文，不如主代理一次性干完。
- 当运营费用超过收益时
Subagent配置方式:
子代理配置有两种方案词典或**CompiledSubAgent**对象。将子代理定义为包含以下字段的词典：
字段名 | 类型 | 必填 / 可选 | 核心描述 | 继承规则（与主代理的关系） |
name | str | 必填 | 子代理的唯一标识；主代理调用 task() 工具时会使用该名称，也会作为 AIMessage / 流式输出的元数据，用于区分不同代理 | -（无继承，需自定义） |
description | str | 必填 | 子代理的职能描述（需具体、以行动为导向）；主代理会根据此信息判断是否将任务委派给该子代理 | -（无继承，需自定义） |
system_prompt | str | 可选 | 子代理的执行指令，需包含工具使用指导、输出格式要求等核心规则 | 不继承主代理的，需自定义 |
tools | list[Callable] | 可选 | 子代理可使用的工具列表；建议极简配置，仅保留必要工具 | 不继承主代理的，需自定义 |
model | str | BaseChatModel | 可选 | 子代理使用的模型：1. 传字符串（如 openai:gpt-5）2. 传 LangChain 模型对象（如 init_chat_model("gpt-5")）省略则使用主代理的模型 | 默认继承主代理的模型，自定义会覆盖默认值 |
middleware | list[Middleware] | 可选 | 自定义中间件，用于实现日志记录、速率限制、自定义行为等功能 | 不继承主代理的，需自定义 |
interrupt_on | dict[str, bool] | 可选 | 为特定工具配置 “人机协作流程（HITL）”；需搭配检查点（checkpointer）使用 | - |
skills | list[str] | 可选 | 技能文件的来源路径（如 ["/skills/research/"]），用于加载子代理专属技能 | - |
示例：创建一个主智能体，它拥有三个助手：
- 天气助手：查询天气（固定返回“晴朗”）。
- 计算助手：处理数学问题。
- 翻译助手：负责中英互译。
代码实现：
原理解析：
subagents参数接收一个列表，每个元素是一个字典，定义了子智能体的配置。
description非常关键：主智能体通过这段描述来判断何时调用该子智能体。
- 当主智能体发现用户意图匹配某个子智能体的
description时，会自动生成一个task工具调用，将任务分发下去。
- *特别注意：**主子Agent之间上下文默认隔离
- 独立 Prompt ：每个 Agent 都有自己独立的 system_prompt ，定义了它是谁，负责什么。
- 独立工具集 (Skills/Tools) ：子 Agent 只能使用分配给它自己的工具，通常不能直接调用父 Agent 的工具，反之亦然。
- 独立记忆 (Memory/State) ：子 Agent 在执行任务时产生的临时对话历史、变量状态，通常只在它自己的生命周期内有效，执行完向父 Agent 汇报结果后，这些中间过程可能不会全部同步给父 Agent（除非通过特定的返回值传递）。 这种设计的目的：
- 专注 ：防止上下文污染。比如负责写代码的 Agent 不需要知道负责写文案的 Agent 的具体指令。
- 安全 ：限制工具权限。比如只有顶层 Agent 能批准发布，底层 Agent 只能提交代码。
- 模块化 ：方便独立测试和复用子 Agent。
也可以调整成异步执行：
- 高并发服务：用 FastAPI/Starlette 做接口时（比如给前端返回流式回答），
astream()+ 异步能同时处理成百上千个用户请求，不会因单个请求阻塞整个服务；
- 批量处理任务：需要同时调用智能体处理多个查询（比如你测试的 3 个问题），
astream()并发执行耗时≈最长单个任务，比同步stream()串行快几倍；
- 非阻塞主线程：在 GUI 程序（如 PyQt/Tkinter）、定时任务中调用智能体，
astream()异步执行不会让界面卡死 / 定时任务中断。
了解扩展：DeepAgents 框架支持配置子代理（Subagent）的嵌套，即子代理可以拥有自己的子代理。
- 无限嵌套结构 ：
- 你可以创建一个 Main Agent 。
- 给它配置一个 Subagent A 。
- 而这个 Subagent A 本身也可以配置它自己的 Subagent B 。
- 这种结构理论上支持多层嵌套（Agent -> Subagent -> Sub-Subagent）。
- 配置方式 ：
- 在创建代理时，通过 subagents 参数传入子代理列表。
- 如果某个子代理也需要下级，就在定义该子代理时，同样配置它的 subagents 参数。
代码示例 (Python)：假设你要构建一个 公司层级 的代理系统：CEO -> 技术总监 (CTO) -> 工程师 (Coder)。
📎 参考文章
- 一些引用
- 引用文章
欢迎您在底部评论区留言，一起交流~
Loading...