Deep Agent 架构深度解析：主Agent与子Agent完整交互机制与核心参数作用

在基于 LangGraph 的 Deep Agent 智能体架构中，主Agent + 子Agent 分层委派是实现复杂任务拆解、专业场景分工、上下文隔离的核心设计。很多开发者在落地时，往往困惑三个核心问题：主Agent如何自主判断调用子Agent？Task节点的底层执行逻辑是什么？父子Agent交互传递的各类参数、上下文、线程ID各自承担什么作用？

本文结合源码运行逻辑，完整梳理主、子Agent的全链路交互机制、触发原理、传递信息清单及核心作用，彻底讲透 Deep Agent 分层协作的底层逻辑。

一、核心前置认知：整体交互本质是Graph有向图流转

首先明确核心定论：Deep Agent 的父子Agent交互，本质是双层 Graph 有向状态图的嵌套调用。

1. 主Agent是顶层Graph的核心节点，负责需求理解、任务决策、路由判断；
2. Task节点是顶层Graph的委派分支节点，是父子Agent交互的唯一中间载体；
3. 每一个子Agent，都是独立的子Graph，拥有专属的节点逻辑、提示词、执行规则和状态体系。

整个交互不存在硬编码的固定调用，而是 「LLM智能决策 + Graph状态路由 + 运行时参数透传」 三者结合的自动化流程。

二、主Agent调用子Agent的完整触发原理

1. 前置绑定：子Agent元信息注册（初始化阶段）

在项目初始化 create_deep_agent 时，我们传入所有子Agent列表，框架会自动完成元数据绑定注册，这是后续所有调用的基础：

• 自动收集所有子Agent的 name（唯一标识）、description（能力描述）；
• 将 task 方法注册为主Agent的标准工具（Function Call）；
• 把所有子Agent的能力清单，自动注入主Agent的系统提示词与工具Schema。

关键区分：此阶段仅为「信息注册」，不会触发任何调用，只是让主Agent的LLM拥有「可委派子任务」的认知。

2. 核心决策：LLM自主判断是否调用Task子Agent

主Agent的决策逻辑完全由LLM驱动，无固定if/else硬编码路由，决策依据只有两个：

1. 主Agent系统提示词：规定主Agent的职责、委派规则（复杂任务委派、专属领域任务指定子Agent、简单任务自行处理）；
2. 子Agent Description描述：LLM通过语义理解，判断当前用户需求是否匹配某一个子Agent的专业能力。

最终主Agent会输出两种Graph路由分支：

• 分支1（无需委派）：需求简单、主Agent可独立完成，直接输出结果，顶层Graph结束流转；
• 分支2（需要委派）：需求复杂、属于子Agent专属领域，LLM输出 Task工具调用指令 （携带 subagentType、任务详情）。

3. Graph路由跳转：进入Task执行节点

当LLM输出Task工具调用后，顶层Graph自动完成分支跳转，进入Task专属节点，正式开启父子Agent的交互流程。

核心逻辑：决策是LLM做的，节点跳转、任务执行是Graph框架做的。

4. Task节点执行：拉起子Agent子Graph

Task节点脱离LLM决策，进入纯代码执行阶段，核心操作：

1. 解析LLM的工具调用参数，通过 subagentType（唯一主键）匹配对应子Agent；
   1. 避坑：代码匹配靠唯一标识，不靠Description，Description仅用于LLM决策参考；
2. 获取该子Agent独立的子Graph实例；
3. 透传所有父级运行时信息，执行 sub_graph.invoke() 拉起子任务；
4. 等待子Graph执行完毕，回收结果，回传给顶层主Agent Graph。

三、父子Agent交互的核心信息清单及作用

父子Agent交互并非简单传递任务文本，而是传递任务指令、运行时配置、会话溯源信息、权限环境四类核心数据，每一项都有不可替代的作用。

1. 子Agent静态元信息（初始化注册阶段传递）

包含：子Agent name（唯一标识）、description（能力描述）

传递方向：子Agent → 框架 → 主Agent LLM

核心作用

• 是LLM路由决策的唯一依据，让主Agent精准判断「什么任务交给谁」；
• 标准化工具调用Schema，保证LLM输出的Task参数可被框架精准解析；
• 限定子Agent职责边界，避免跨领域错误委派。

2. 任务指令信息（运行时动态传递）

包含：具体子任务Prompt、用户需求片段、任务执行要求

传递方向：主Agent Task节点 → 子Agent

核心作用

• 为主Agent拆解后的精细化子任务，作为子Graph的唯一执行入参；
• 剥离无关上下文，让子Agent聚焦专属任务，提升执行精度与效率。

3. ParentConfig 父级运行时配置（核心核心）

parent_config 是父子交互的核心载体 ，存储主Agent本次运行的全部Runtime动态配置，区别于静态初始化配置，每次对话运行都会生成独立实例。

传递方向：主Agent运行上下文 → Task节点 → 子Agent执行上下文

核心包含字段及作用

1. thread_id（会话线程ID）
   1. 作用：会话唯一标识，是子Agent读取历史上下文的核心凭证；
   2. 逻辑：子Agent不会自主生成线程ID，完全依赖父级传递；子Agent通过该ID从Redis/数据库/内存存储中主动拉取整轮对话历史（而非父Agent打包传递）。
2. parent_thread_id（父级线程ID）
   1. 作用：全链路溯源，用于嵌套委派（父→子→孙Agent）的日志排查、任务链路追踪；
   2. 价值：区分主会话与子任务会话，实现层级任务管理。
3. user_id、run_id
   1. 作用：用户身份校验、单次任务运行标识，实现权限隔离、日志精准定位。
4. 环境/权限/中间件配置
   1. 作用：子Agent直接继承主Agent的文件权限、沙箱环境、中断审批规则、中间件逻辑，无需重复配置。

4. 对话上下文（会话记忆数据）

两种传递模式，适配不同生产场景

1. 生产主流模式（隔离安全）

2. 父仅传递 thread_id，子Agent通过记忆组件（MemoryStore）自主查询持久化上下文；

   • 优点：不膨胀State状态、上下文完整、支持长会话、父子状态隔离。

3. Demo简易模式（仅测试用）

4. 父Agent直接将当前对话消息列表打包传入子Graph State；

   • 缺点：长对话状态臃肿、性能差、容易污染主会话上下文，禁止用于生产。

四、父子Agent上下文隔离与共享核心规则

1. 决策隔离：主Agent只做任务拆分与路由，子Agent只做专属任务执行，职责完全解耦；
2. 配置继承：子Agent默认继承父级运行时环境、权限、溯源ID，自身静态配置（模型、提示词）优先级更高，可覆盖父配置；
3. 会话可控
   1. 共享会话：父子复用同一个 thread_id，子可读取完整主对话历史；
   2. 隔离会话：Task节点生成独立 sub_thread_id，子任务会话独立，中间思考过程不会污染主对话；
4. 结果回流 ：子Agent仅将最终执行结果回传给主Agent，中间推理、迭代过程全部隔离，保证顶层Graph简洁稳定。

五、全链路交互流程终极总结

1. 注册阶段：框架绑定所有子Agent的名称、能力描述，注册Task工具，注入主Agent提示词；
2. 决策阶段：主Agent LLM根据用户需求、子Agent能力描述，自主判断是否委派任务；
3. 路由阶段：LLM输出Task调用指令，顶层Graph跳转Task节点；
4. 传参阶段：Task节点携带 parent_config、thread_id、任务指令，匹配并拉起对应子Agent子Graph；
5. 执行阶段：子Agent通过线程ID读取对话上下文，独立执行子任务；
6. 回流阶段：子Graph执行完毕，结果返回主Agent，主Agent整合输出最终答案。

六、核心关键结论（避坑干货）

1. 主Agent调用子Agent 不是字符串匹配，是LLM语义推理决策；
2. Description只给LLM看（用于选任务），代码执行只认 subagentType 唯一标识；
3. thread_id 绝对由父级传递，子Agent无自主生成主会话ID的能力；
4. parent_config 是运行时动态配置，和代码初始化的静态配置完全无关；
5. 生产环境优先使用「独立子线程」模式，实现任务隔离，避免主会话污染。

以上就是 Deep Agent 架构中，主Agent与子Agent分层交互的完整底层逻辑，也是自定义多级智能体、实现复杂任务自动化的核心理论基础。