Supervisor-Worker 分层智能体架构，揭秘 Agent 如何理解意图、拆解任务、何时调模型、何时调工具？

公众号名称：技术自由圈

作者名称：尼恩塔尖AI架构

发布时间：2026-07-02 07:18

FSAC未来超级架构师

架构师总动员
实现架构转型，再无中年危机

尼恩说在前面

在45岁老架构师尼恩的读者交流群（50+人）里，最近不少小伙伴拿到了阿里、滴滴、极兔、有赞、希音、百度、字节、网易、美团这些一线大厂的面试入场券，恭喜各位！

Agent 架构已经是架构面试的核心题目，前两天就有个小伙伴面阿里，问到了 Agent 的理解意图、拆解任务、何时调模型、何时调工具，小伙伴立马懵逼了：

问题一、用户输入后，Agent 如何理解意图、拆解任务？
问题二、任务拆解后，Agent 如何决定先后顺序、何时调模型/何时调工具？

小伙伴面试回来后，找尼恩复盘。

通过这个系列的文章，这里尼恩给大家做一下系统化、体系化的梳理，写一个系列的文章组成尼恩编著《Harness 架构与源码学习圣经》深入剖析 Harness AI 平台级架构的架构思维与核心源码，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

同时，也一并把这个题目以及参考答案，收入咱们的《尼恩Java面试宝典PDF》V176版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

尼恩用 Supervisor-Worker 分层多智能体经典范式，解答 Agent 如何理解意图、拆解任务、何时调模型、何时调工具等问题

三层Agent 编排架构的完整业务执行流程

当前，大模型多智能体落地，普遍存在职责边界模糊、任务耦合严重、调度逻辑混杂、异常不可控、横向扩展困难五大痛点：

单 Agent 大包大揽导致上下文膨胀、推理效率低下；
多 Agent 扁平协作缺少全局统筹，跨领域依赖极易死锁；
ReAct 动态推理与 DAG 静态流程无规范，排障与可观测性缺失。

真正的工业级 Agent架构，是 L3 全局编排器 - L2 领域调度 Agent-L1 原子执行 Agent三层架构体系。

一张图看懂 L3、L2、L1 三层Agent 编排架构

L3、L2、L1 三层Agent 编排架构，基于Supervisor-Worker 分层多智能体经典范式、A2A（Agent-to-Agent）通信标准、ReAct 推理循环、DAG 有向无环图调度理论，满足企业级私有化部署、复杂长任务编排、多领域协同、权限管控、迭代扩展生产级要求。

一、架构整体执行总览

完整链路：

用户自然语言输入 → L3 Root Orchestrator（全局超级编排器 super Agent：预处理→意图理解→任务拆解→DAG生成→跨域路由分发） → L2 Domain Agent（领域监管Agent：域内任务解析、调度模式选择[ReAct/DAG]、原子任务执行、异常处理、局部聚合） → L1 Specialist Agent（原子技能Agent：单一步骤工具执行、结构化结果返回） → 结果逐层上抛聚合 → L3全局汇总、格式化输出给用户

用户自然语言交互输入（含文本 / 多模态 + 多轮对话上下文）

→ L3 Root Orchestrator 全局超级编排 Agent

输入预处理→上下文归一化→需求分类判定→结构化意图解析→全局跨领域粗拆解→全局 DAG 拓扑构建

→A2A 路由分发

→ 批量 L2 Domain Agent 领域闭环调度 Agent（多领域并行 / 串行协同）

领域任务解析→调度模式决策（DAG 静态调度 / ReAct 动态推理循环 / 混合模式）→域内精细化原子任务拆解→子任务依赖 DAG 构建→逐级下发调用 L1、管控重试 / 缓存 / 降级 / 异常→域内结果聚合封装

→ L1 Specialist 原子技能执行 Agent 集群

接收结构化入参→无状态单能力执行→标准化结果回传 L2

→ L2 汇总域内结果逐层向上回包至 L3

→ L3 全局结果校验、多域数据融合、格式归一化、话术封装

→ 结构化 / 自然语言结果输出至用户交互终端

核心分层铁律（工程落地关键）

层级	职责	禁止行为
L3	顶层决策与全局编排	不执行工具、不做细粒度ReAct循环、不处理局部异常
L2	领域内调度与闭环	承接单领域任务，管控本域所有原子任务的执行循环、重试、缓存、降级
L1	纯原子执行	无决策、无推理、无状态，仅接收结构化入参，执行工具/API/LLM能力，返回标准化JSON结果

三层 Agent 并非孤立运行，依赖统一基础设施保障通信、状态、可观测、安全管控：

(1) A2A 通信网关：标准化消息队列 + RPC 双协议，定义统一请求 / 响应报文结构体、消息 ID 追踪、超时重试、消息重放、防重复投递，支撑 L3↔L2、L2↔L1 异步 / 同步通信；

(2) 全局上下文管理器：滑动窗口上下文截断、指代消解、Token 压缩、历史快照持久化，区分会话级上下文、任务级上下文、原子执行上下文；

(3) 分布式缓存中间件：多级缓存设计，L3 全局缓存、L2 域内热点缓存、L1 原子结果缓存，配置 TTL 失效策略、缓存击穿防护；

(4) 异常中心 & 熔断降级中心：分级异常定义、错误码体系、重试次数阈值、超时阈值、熔断开关、降级备选方案配置中心；

(5) 可观测平台：全链路 TraceID 埋点、每层级耗时统计、LLM 调用 Token 消耗统计、工具调用日志、异常堆栈归档、LangFuse/LangSmith 对接；

(6) 权限 & 密钥管理中心：RBAC 细粒度 Agent 工具访问权限、数据库 / API 密钥托管、操作审计日志、敏感数据脱敏；

(7) Schema 校验引擎：全局入参、任务结构体、返回结果 JSON Schema 强制校验，拦截格式异常、字段缺失、类型错误，自动触发重试或报错。

预置 L2 垂直领域集群（可按需横向扩展新增领域）

系统原生预设五大业务领域 Domain Agent，覆盖绝大多数企业 AI 场景，新增领域遵循统一接入规范注册至 L3 路由中心：

(1) AI 问数领域 Agent：结构化数据查询、SQL 生成校验、数据统计、多表关联查询、数据集清洗、指标计算；

(2) RAG 知识库问答领域 Agent：向量库召回、多路检索、重排序、冗余段落过滤、知识摘要、问答匹配；

(3) 长报告生成领域 Agent：大纲规划、章节内容生成、素材填充、全文润色、排版格式化、图表文案适配；

(4) 通用 Default 兜底领域 Agent：闲聊应答、常识问答、简单单次推理、需求无法分类兜底处理、边缘异常收容；

(5) 联网搜索领域 Agent：全网检索、摘要提取、时效性信息抓取、多源信息去重整合；

扩展示例：代码执行领域、文件解析领域、工单审批领域、供应链数据分析领域等，新增领域仅需开发对应 L2 + 配套 L1，无需改动 L3 核心编排逻辑，满足插件化扩展。

二、L3 Root Orchestrator （super Agent超智能体）

L3核心职责：把控全局需求、拆分跨领域任务、生成依赖拓扑、路由至对应领域，全程不参与具体执行。

L3 是整个多智能体系统唯一入口、唯一全局决策单元、唯一跨域调度枢纽，设计原则为轻量化全局统筹，绝不下沉执行细节，内部分为四大核心执行阶段，每个阶段配套标准化数据结构、多技术方案选型、工程落地优化策略。

2.1 阶段一：全局输入预处理与会话归一化

预处理目标：消除用户输入噪声、消解上下文歧义、统一输入范式，为意图识别、任务拆解提供稳定输入基底，规避杂乱输入导致大模型输出漂移、解析失败问题，整体分为三层处理流水线。

（1）第一层：规则引擎文本清洗（低延迟、高吞吐，前置执行）

通过正则表达式批量处理，无需调用大模型，毫秒级完成：

过滤无效字符：连续标点、多余空格、换行符、emoji 表情、HTML 标签、无效 URL、特殊波浪 / 星号冗余符号；
冗余压缩：重复语句合并、语气助词（嗯、那个、就是、呃）剔除、口语化冗余修剪；
符号保留策略：业务关键符号（百分号、货币符号、日期格式、代码标识符、括号表达式）完整保留，不做删除；
脏输入拦截：空字符串、纯表情、乱码内容、恶意指令前置拦截，直接返回友好提示。

（2）第二层：多轮上下文拼接与指代消解

解决用户承接式提问、代词省略、上下文指代模糊问题，是对话系统核心难点：

(1) 滑动窗口策略：配置最大上下文轮次（默认 3～5 轮），超出轮次自动淘汰最早历史对话，避免上下文超长溢出；

(2) 指代消解处理：调用轻量 BERT 指代消解模型，将 “它、这个、刚才的数据、上文报告” 等代词替换为实体内容，消除语义断层；

(3) 上下文标记格式化：固定拼接模板【历史对话上下文】{合并历史内容}\n【当前用户提问】{用户最新输入}，模型可明确区分新旧信息；

(4) 超长上下文优化：总 Token 逼近模型上下文阈值时，自动调用 LLM 做历史摘要压缩，保留关键业务信息，舍弃无效闲聊内容。

（3）第三层：五级需求分类判定（路由前置分流）

预处理完成后，系统必须判定需求所属类型，不同类型走差异化处理链路，提供 小样本分类模型（高性能首选）、Few-Shot Prompt 分类（快速原型） 两种实现方案：

需求类型	判定特征定义	对应处理链路
①闲聊类	问候、情绪倾诉、无关闲聊、无业务诉求闲聊语句	直接路由 Default 兜底 L2，简短应答，终止复杂拆解流程
②纯推理问答类	仅依赖大模型静态知识即可作答，无需外部数据库、检索、工具调用	路由 Default 领域，L2 直接调用单次 LLM 生成答案，跳过全局任务拆解
③单工具调用类	需求明确仅需要一个原子工具执行（查天气、翻译、单条数据查询）	L3 super 极简拆解为单领域单任务，快速下发对应 L2，减少编排开销
④跨领域复杂项目类	必须 2 个及以上领域协同、存在跨域前后依赖、多步骤长流程	进入完整意图解析 + 全局粗拆 + DAG 编排全流程
⑤模糊残缺需求类	语义歧义严重、关键参数缺失、表述模糊无法判定目标	L3 super 启动槽位补全反问机制，定向收集缺失信息，补齐后再进入后续流程

2.2 阶段二：结构化意图理解（L3 super核心能力，消除语义模糊性）

摒弃传统非结构化自由式意图输出，强制输出标准化意图结构体，实现 “自然语言→机器可解析结构化数据” 转化，提供三种工业级落地方案，适配不同体量业务，可组合使用、互为兜底。

意图结构体固定 Schema（全局统一，不可自定义字段）

{
  "coreGoal": "字符串，用户最核心业务目标，精简一句话定义",
  "constraints": "数组，所有显性约束、限制条件、边界要求",
  "keyParameters": "对象，抽取全部业务关键实体、参数、时间、范围、指标",
  "missingInfo": "数组，识别出的必填缺失参数、未明确信息",
  "implicitNeeds": "数组，用户字面之外潜在隐性诉求、业务默认习惯",
  "domainLabels": "数组，匹配对应的L2领域标签列表"
}

实例演示

用户输入：帮我整理一份北京三日游玩方案，预算不高

结构化意图输出：

{
  "coreGoal": "生成北京3天旅游行程规划方案",
  "constraints": ["整体低成本、高性价比消费", "三日时间周期"],
  "keyParameters": {"目的地":"北京","时长":"3天"},
  "missingInfo": ["出行人数", "出行月份/季节", "交通方式偏好", "住宿档次要求"],
  "implicitNeeds": ["路线顺路少绕路", "吃住性价比优先", "规避高额门票景点", "行程节奏适中不紧凑"],
  "domainLabels": ["长报告生成领域"]
}

方案 1：Prompt 强结构化约束（原型、中小业务首选，零训练成本）

(1) 系统提示词强制约束输出 JSON 格式、字段释义、禁止额外文本、禁止 Markdown 包裹；

(2) 后端配置 JSON Schema 校验器，解析失败自动重试最多 2 次，重试依然格式异常则降级方案 3 槽位处理；

(3) 优势：快速落地、迭代灵活；劣势：大模型随机性导致格式偶发错乱，高并发稳定性偏弱。

方案 2：小样本微调分类 + 槽位抽取联合模型（企业级高并发生产首选）

(1) 构建标注数据集：每条样本包含原始问句、意图标签、槽位键值对；

(2) 基于轻量级 RoBERTa/BERT 微调，同时完成领域分类 + 实体槽位抽取，推理耗时 < 100ms，远快于 LLM 调用；

(3) 置信度阈值管控：模型输出置信度低于预设阈值（默认 0.7），自动降级调用方案 1 大模型解析，兼顾速度与准确率；

(4) 优势：稳定性强、吞吐高、抗输入噪声；劣势：前期需要标注数据、微调部署成本。

方案 3：槽位抽取 + 歧义 / 残缺反问补齐（结构化强业务场景必备）

针对表单类、流程类、指令类强结构化需求，主动识别信息缺陷并交互式补齐：

(1) 歧义消解逻辑：同一语句存在两种及以上合理解读时，枚举选项向用户确认，例：“查上海订单”→询问 “您需要查询出发上海，还是收货地上海的订单？”；

(2) 残缺补齐逻辑：遍历必填槽位清单，一次仅反问一个缺失参数，避免一次性抛出多问题造成用户困惑，补齐一项再校验下一项；

(3) 深层隐含推理：结合用户历史会话画像、业务默认规则推导隐性参数，减少反问频次。

2.3 阶段三：分层任务拆解范式（L3 粗拆 + L2 细拆权责隔离）

拆解核心原则：两级拆解权责严格隔离（架构设计核心壁垒）

(1) L3 仅做全局粗粒度跨领域拆分：拆分单元是完整领域任务，不触及具体执行步骤、不定义工具调用、不拆分原子操作；仅确定不同领域之间先后依赖、并行关系；

(2) L2 唯一负责域内精细化原子拆解：接收本领域上层任务包，全权拆分至可直接调度 L1 的最小不可拆分原子子任务，是细粒度拆分唯一主体；

(3) 禁止逆向越权：L3 不能下沉拆解原子步骤，L2 不能向上修改全局跨领域依赖拓扑。

跨领域拆解实例（需求：生成 Q2 销售复盘报告，需要知识库素材 + 业务数据支撑）

L3 super 输出 3 个 Domain 任务：

(1) dt_rag_001（RAG 领域）：无前置依赖，检索 Q2 复盘模板、竞品对比素材；

(2) dt_dq_002（AI 问数领域）：无前置依赖，查询 Q2 销售额、同比增速、区域分布数据；

(3) dt_report_003（长报告领域）：依赖 dt_rag_001、dt_dq_002，基于素材 + 数据生成完整复盘报告。

执行逻辑：任务 1、2 并行启动，全部执行完成后，才启动任务 3。

2.4 阶段四：全局 DAG 生成、拓扑排序与 A2A 路由分发

(1) 环检测校验：基于邻接表构建全局任务有向图，采用 Kahn 拓扑排序算法自动检测循环依赖，出现死环立即终止任务，返回异常提示用户；

(2) 分层调度执行：入度为 0 的无依赖领域任务批量并行下发；

前置依赖全部完成、入度清零后，再调度下游依赖任务；
L3 通过消息回执、轮询回调双机制监听每个 L2 任务完成状态；

(3) A2A 路由分发机制：L3 作为核心的入口网关，将 DomainTaskPacket 封装为标准 A2A 请求报文，投递至对应 L2 消息队列，携带全局唯一 TraceID 贯穿全链路，实现问题溯源；

(4) 全局兜底管控：配置整体任务超时阈值、最大总耗时，超时未完成触发预设降级策略（部分结果返回、终止未执行任务、缓存兜底）。

2.5 阶段五：全局结果聚合与输出格式化

(1) 等待全部领域任务节点执行完毕，收集所有 L2 返回结果；

(2) 基于expectedOutputSchema逐一校验各领域返回数据合法性，过滤异常失败任务，标注部分结果不可用说明；

(3) 跨领域数据融合、冲突信息消歧、冗余内容合并；

(4) 根据用户原始交互习惯，选择自然语言段落、结构化表格、Markdown 文档、JSON 数据等格式封装最终回复；

(5) 写入会话历史、持久化任务快照，本轮流程闭环。

3. L3 super Agent 全局任务拆解 & 领域Agent 路由

基于标准化意图，遵循四大拆解原则，完成全局任务拆分，并按领域自动分组。

主流拆解模式：分层拆解

L3（全局粗拆） + L2（领域细拆）

严格区分L3与L2拆解权责：

L3（全局粗拆）：仅基于用户全局需求，拆分出跨领域、大粒度的阶段任务，只划分领域层级任务，不拆解原子执行步骤、不定义工具调用细节，仅明确领域执行先后顺序。
L2（领域细拆）：接收L3下发的本域大粒度任务，自主完成域内细颗粒原子拆解，拆分出可直接调度L1原子Agent的最小执行子任务，是细粒度任务拆分的唯一执行主体。

默认执行逻辑：链式线性拆解，严格按照「前置领域任务完成→后置领域任务执行」的顺序推进，无复杂并行逻辑。但对于L2内部，可以进一步采用DAG或ReAct模式（详见第三章）。

L3 全局粗拆：

仅基于用户全局需求，拆分出跨领域、大粒度的阶段任务，只划分领域层级任务，不拆解原子执行步骤、不定义工具调用细节，仅明确领域执行先后顺序。

默认执行逻辑：链式线性拆解，严格按照「前置领域任务完成→后置领域任务执行」的顺序推进，无复杂并行逻辑。

拆解输出标准

L3全局粗拆输出标准：

字段	说明
领域任务编号	唯一标识
大任务名称	描述性名称
任务目标	该领域要达成的目的
所属领域	domain标签
跨域前置依赖	依赖的其他领域任务编号
整体执行要求	如超时时间、降级策略
领域预期产出	期望的输出结构描述

L3 super 全局粗拆输出结构体：DomainTaskPacket（领域任务包，A2A 分发载体）

结构体名称：DomainTaskPacket（领域任务包）

用途：L3 全局粗拆产物、跨领域 DAG 构建载体、A2A 路由分发标准报文、L2 领域任务入参契约

标准字段名	字段类型	对应旧版名称	字段详细说明
domainTaskId	字符串	领域任务编号	全局唯一任务编号，全链路 Trace 追踪主键，用于依赖绑定、日志溯源、任务状态管理
taskGoal	字符串	任务目标 / 大任务名称	当前领域任务需要达成的核心业务目标，简洁描述本领域整体任务诉求与输出目的
domainLabel	字符串	所属领域	领域唯一标签（domain 标签），用于 L3 精准匹配、路由分发至对应 L2 领域 Agent
dependencies	字符串数组	跨域前置依赖	前置依赖的 domainTaskId 列表，为空数组代表无前置依赖，可并行执行；用于构建全局领域 DAG 拓扑关系
globalConstraints	对象	整体执行要求	全局统一执行约束，包含：单领域超时时间、最大重试次数、降级策略、并发限制、优先级等全局管控规则
expectedOutputSchema	JSON Schema	领域预期产出	约定当前领域任务最终输出的数据结构标准，L2 执行完成后必须严格匹配该 Schema 校验，不匹配则判定任务异常

统一规范说明

taskGoal 统一承载「大任务名称+任务目标」语义，不再拆分两个字段，精简结构体；
globalConstraints 统一收敛所有全局执行策略，替代零散的执行要求字段；
expectedOutputSchema 为强校验字段，是 L2 结果回传、L3 全局聚合的契约基准；
所有 L3 粗拆输出、A2A 下发报文、前后端结构体定义、文档注释，全部对齐本表，禁止自定义字段。

本规范统一合并原有两套输出表格，取缔不一致字段与描述，作为 L3 Root Orchestrator 全局粗拆唯一输出结构体标准，是 A2A 领域路由分发、L2 任务接收校验、全局 DAG 生成的唯一可信依据，所有工程落地严格以此版为准。

L2（领域细拆）：

接收L1下发的本域大粒度任务，自主完成域内细颗粒原子拆解，拆分出可直接调度L1原子Agent的最小执行子任务，是细粒度任务拆分的唯一执行主体。

拆解四大核心原则

(1) 原子化原则：拆分至最小不可拆分执行单元，单个子任务职责唯一、边界清晰

(2) 依赖解耦原则：明确所有子任务的前置/后置依赖关系，梳理执行时序

(3) 可落地原则：每个子任务明确执行属性（纯模型推理/工具API调用/数据计算/文档生成）

(4) 容错兜底原则：为复杂任务预留异常分支、降级方案、重试机制预留位

默认执行逻辑：链式线性拆解，严格按照「前置领域任务完成→后置领域任务执行」的顺序推进，无复杂并行逻辑。

L2各领域细拆（域内原子任务）：

RAG领域L2拆解：知识库召回 → 相似度排序 → 冗余过滤 → 素材汇总
AI问数领域L2拆解：需求解析 → SQL生成 → 执行查询 → 数据清洗

L2领域细拆输出标准：

字段	说明
子任务编号	域内唯一
子任务详情	具体做什么
前置依赖	依赖的其他子任务编号
执行方式	tool_call / llm_call / code_exec
完成判定标准	如何判断成功
单任务预期输出结果	输出schema描述

4. 全局DAG生成 + A2A领域路由分发

L3根据任务依赖关系，生成全局简易DAG时序图，锁定domain Agent任务执行先后顺序
按「领域标签」将拆分后的子任务批量分组，通过A2A智能路由，精准下发至对应L2 Domain Agent
L3仅做全局分发，不直接调度L1原子Agent，彻底解耦全局决策与局部执行

三、L2 Domain Agent （领域 Agent）

L2 承接L3下发的本域子任务组，全权负责领域内调度、ReAct循环、异常处理、局部结果聚合。

L2 是单领域业务闭环核心，承接 L3 下发任务包，解决 “领域内部具体怎么做” 的问题，核心决策点为调度模式选型（DAG 静态调度 / ReAct 动态推理循环），自主管控域内全流程、容错、缓存、聚合，隔离领域复杂度，避免污染上层 L3。

L2为单领域任务闭环核心，承接L3下发的本域子任务组，全权负责领域内调度。L2支持两种调度模式：ReAct循环和DAG调度，可根据任务性质灵活选择。

1. 域内任务解析与重构

接收L3下发的本域子任务DAG片段/任务列表，结合领域业务特性，二次细化任务执行细则，适配本域专属执行规则（如AI问数侧重SQL纠错、RAG侧重检索召回优化）。同时，L2需决定本域采用何种调度模式。

2. 调度模式选择

模式	适用场景	特点
ReAct循环	动态推理、多步探索、不确定执行路径的任务（如复杂问答、多轮工具调用）	L2每一步都进行模型思考，决定下一步行动；适合需要自适应调整的场景
DAG调度	静态依赖、确定性子任务链的任务（如ETL流程、固定数据处理流水线）	预先定义好子任务DAG，L2按拓扑序依次调度L1执行；无需每步模型推理，效率高

选择逻辑：

如果L3下发的任务列表中，子任务之间的依赖关系明确且稳定，优先选用DAG模式
如果任务需要根据中间结果动态决策下一步（如SQL纠错、多轮检索），则选用ReAct模式
也可混合使用：先通过DAG执行确定性步骤，再对不确定步骤启用ReAct

3. 调度执行

模式A：ReAct循环调度（核心能力）

所有L1原子任务的执行循环，全部由L2管控。标准ReAct执行范式：

(1) 模型思考：L2结合本域任务目标、历史执行状态，判断当前子任务的执行方案

(2) 能力判定：区分纯模型推理可解决 / 必须调用L1工具Agent执行

(3) 参数封装：生成标准化结构化入参，下发至对应L1 Specialist Agent

(4) 原子执行：调用L1技能，获取工具/API返回的原始结构化数据

(5) 迭代推理：将「原始需求+工具返回结果」重新输入模型，完成本轮推理，生成局部中间结果

(6) 循环闭环：重复上述流程，直至本域所有子任务全部执行完成

完整循环迭代步骤（L2 独占决策，循环最大步数可配置防死循环）：

(1) Thought（推理思考）：L2 结合本域目标、历史执行上下文、过往工具返回观测结果，判断当前进度，决策下一步行动类型；

(2) Action（行动决策）：输出标准化行动枚举，区分六大动作类型，决定是否调用 L1、反问用户或结束任务；

(3) 参数封装下发：如果是工具 / LLM 调用，构造强结构化入参，下发对应 L1 Specialist 执行；

(4) Observation（观测接收）：接收 L1 返回原始结果、异常信息、状态码；

(5) 上下文迭代更新：将思考、动作、观测记录写入局部上下文，进入下一轮循环判定；

(6) 终止判定：满足完成条件则退出循环，聚合域内结果向上回包。

模式B：DAG调度

(1) 构建域内DAG：基于L3下发的子任务列表及其依赖关系，生成域内有向无环图

(2) 拓扑排序：确定子任务的执行顺序（并行节点可并发调度）

(3) 逐层执行：按拓扑序调度L1 Agent，每个子任务完成后检查下游依赖是否就绪

(4) 结果汇聚：所有叶子节点执行完毕后，聚合域内结果

DAG调度示例（AI问数领域）：

需求解析 → SQL生成 → 执行查询 → 数据清洗

Atom1：解析需求提取统计指标与时间范围（llm_call）
Atom2：基于解析内容生成合规 SQL 语句（llm_call，依赖 Atom1）
Atom3：调用 L1-SQL Agent 执行数据库查询（tool_call，依赖 Atom2）
Atom4：调用 L1 - 数据转换 Agent 清洗整理结果（tool_call，依赖 Atom3）

DAG调度流程如下：

(1) 构建域内子任务 DAG，拓扑排序确定执行顺序，环检测；

(2) 按序封装参数调用对应 L1 Agent，同步 / 异步执行；

(3) 单个子任务失败触发 L2 预设重试、降级分支，不可修复则标记任务异常，携带错误信息上报 L3；

(4) 全部节点完成后聚合所有原子结果，封装匹配上层预期 Schema，回传 L3。

此流程中，每个步骤的依赖关系是确定的，无需模型每步思考，直接用DAG调度即可高效完成。

4. 域内运维能力

局部缓存：短时间内重复同源子任务，直接复用历史执行结果，减少工具调用损耗
异常管控：
ReAct模式下：L1执行失败时，L2可尝试重试、参数纠错、切换工具；无法修复时上报L3
DAG模式下：某个子任务失败时，L2可触发降级分支（如使用备用数据源），或标记失败并通知L3
上下文隔离管控 仅维护本域局部执行上下文，禁止读取、修改其他领域私有数据，跨域数据交互必须经过 L3 中转，防止上下文污染。
局部聚合：汇总本域所有L1执行结果，整理为标准化领域结果，上传至L3

关于文档撰写等生成任务：L2本身可以具备LLM推理能力，因此文档撰写、内容规划等生成型任务应在L2内部完成（通过调用L1的LLM调用Agent获取一次性文本片段，再由L2组合、润色），而不是交给L1去“决策”。

四、L1 Specialist Agent 执行流程（原子层）

核心定义：L1为无状态纯执行单元，无决策、无推理、无全局感知，仅负责单一原子技能执行。

L1 是整个架构唯一执行单元、无状态纯工人层，设计原则：零决策、零推理、零上下文感知、单一职责、幂等执行，只被动接收 L2 结构化指令完成操作，不具备自主思考能力，彻底规避底层逻辑混乱。

4.1 L1 标准化执行流程

(1) 入参强校验：接收 L2 下发 JSON 入参，匹配预设 JSON Schema 校验字段完整性、参数类型、取值范围，非法参数直接返回失败响应；

(2) 原子能力执行：调用对应底层资源（数据库、向量引擎、搜索引擎、文件系统、LLM 接口、代码沙箱）完成单一固定操作；

(3) 执行过程防护：超时控制、资源配额限制、敏感操作脱敏、SQL 注入防护、沙箱隔离防恶意代码；

(4) 结构化结果回包：统一返回报文格式，包含执行状态码、业务数据体、异常信息、耗时统计，固定格式回传给调用方 L2。

典型L1原子Agent

系统预置 L1 原子 Agent 矩阵

L1 原子 Agent 名称	核心能力边界	底层执行载体	执行约束规范
SQL 查询 Agent	接收结构化查询参数，执行 SELECT 查询，返回数据集；禁止 DDL/DML 修改语句	数据库驱动连接业务库、数仓	只读权限、SQL 语法前置校验、查询行数上限、慢查询拦截
向量库检索 Agent	输入 Embedding 文本，执行向量相似度召回、返回匹配文档片段列表	Milvus/Chroma/Zilliz 向量数据库 API	TopK 数量限制、索引隔离、重复片段过滤
联网搜索 Agent	关键词 / 自然语言检索全网信息，抓取摘要、标题、来源链接	搜索引擎第三方 API	单次搜索频次限制、结果条数上限、时效性过滤
单次 LLM 调用 Agent	接收 Prompt 与参数，发起单次大模型请求，返回原始文本	LLM 推理 API	禁止多轮循环推理、仅单次调用、Token 上限管控
代码沙箱执行 Agent	执行 Python/JS 运算脚本，返回计算结果，隔离系统权限	容器化沙箱、进程隔离	运行时长限制、文件读写隔离、禁止系统高危调用
文件读写 Agent	指定路径读取、写入、解析文档（PDF/Word/Excel/TXT）	本地 / 对象存储 IO 接口	路径白名单管控、文件大小上限、越路径访问拦截
数据转换 Agent	数据格式化、字段映射、去重、聚合、类型转换、表格组装	纯函数式内存计算	无外部 IO、无网络请求、纯数据处理逻辑

五、端到端完整业务案例全链路推演（具象落地验证）

用户需求：帮我统计 Q1、Q2 销售额，如果 Q2 同比 Q1 增幅超 20%，生成一份增长分析报告

尼恩提示：原文3w字以上，超过平台限制，此处省略 1000字，具体请参考免费pdf。

完整版本，请参考尼恩免费百度网盘免费pdf ，点赞收藏本文后，截图找尼恩获取

六、架构核心优势、工程避坑与扩展演进方案

尼恩提示：原文3w字以上，超过平台限制，此处省略 1000字，具体请参考免费pdf。

完整版本，请参考尼恩免费百度网盘免费pdf ，点赞收藏本文后，截图找尼恩获取

问题一、用户输入后，Agent 如何理解意图、拆解任务

Step 1｜L3 预处理：从“人话”到“机器可处理的干净文本”

预处理不是简单去噪，而是为后续意图识别建立稳定的输入基底。工程上通常分三层：

1.1 文本清洗（规则引擎 + 轻量模型）

规则层：正则匹配去除多余空格、重复标点、emoji、HTML标签、URL（视场景保留或替换为占位符）。例如用户输入“帮我查一下……嗯……就是那个Q2的数据”，规则引擎会将省略号和表情去掉，得到“帮我查一下就是那个Q2的数据”。
语义层：使用轻量纠错模型（如基于BERT的拼写校正）修正明显错别字，例如“销受额” → “销售额”。注意：纠错模型本身是一次LLM调用，但属于预处理阶段的决策行为（允许），不应归类为工具执行。
特殊符号处理：保留有意义的符号（如百分比%、货币符号$），去除无意义符号（如连续波浪线～～～～）。

1.2 上下文拼接：解决“承接式提问”的语义断裂

窗口策略：取最近N轮对话（通常3～5轮），将历史消息拼接为一条连续的文本，并在当前输入前加上“【历史】…【当前】…”的标记，帮助模型区分新旧信息。
指代消解：对于“它”、“那个”、“刚才说的”等代词，可用轻量指代消解模型替换为具体实体。例如用户第二轮说“把它做成表格”，需要替换为“把[上一轮提到的数据]做成表格”。
截断策略：若历史过长（超过模型上下文窗口），采用滑动窗口或关键句提取（按角色、时间、关键词重要性评分），保留最相关的上下文。

1.3 需求分类判定：五大类型的判别标准

类型	特征	处理方式
闲聊类	问候、情感表达、无关话题	直接走Default兜底领域，返回简短回复
纯推理问答类	无需外部数据，仅靠模型知识即可回答（如“光的传播速度是多少？”）	可能不走任何L1工具，L2直接调用自身LLM返回答案
单工具调用类	明确指向一个工具（如“查一下天气”、“翻译成英文”）	路由到对应L2，L2直接调度对应L1
跨领域复杂项目类	需要多个领域协作（如“写报告+查数据+搜索资料”）	L3进入完整拆解流程
模糊残缺需求类	意图不明、缺少关键信息	进入槽位抽取+反问补全流程

工程经验：分类判定可以使用一个小的分类模型（方案2），响应速度快于大模型；若用大模型，则通过few-shot prompt固定输出类别标签。

Step 2｜L3 结构化意图理解：从“模糊语义”到“程序可解析的结构体”

三种方案并非互斥，实践中常组合使用：

方案1：Prompt结构化约束（轻量、通用）

原理：在System Prompt中写明“你必须输出如下JSON格式，字段为…”，并在User Message中强调“请严格按照格式输出，不要添加额外内容”。
优点：零成本、快速迭代、适合原型验证。
缺点：大模型偶尔输出格式偏离（如字段名大小写不一致、遗漏字段），需要后处理校验+重试。
增强措施：在后端增加JSON Schema校验，若不通过则让模型重试一次（最多2次），仍失败则降级为方案3的槽位抽取（规则+小模型）。

方案2：小样本微调分类模型（企业级、高精度）

适用场景：意图标签库稳定（如<50个标签），且每日调用量上万。微调一个小型BERT/RoBERTa模型，分类+槽位抽取同时输出。
训练数据：每条标注数据包含“原始输入 + 意图标签 + 槽位键值对”。例如输入“帮我查北京明天天气”，标签=“天气查询”，槽位={城市:北京, 日期:明天}。
部署：作为L3的一个服务，响应时间<100ms，远低于大模型。
兜底：当模型置信度低于阈值（如0.7），回退到大模型方案1。

方案3：槽位抽取+补全机制（结构化业务场景）

流程：先用规则或小模型抽取已知槽位，然后检测缺失的必填槽位，主动发起反问。
反问策略：一次只问一个关键缺失信息，避免用户困惑。例如用户说“帮我订机票”，系统反问“请问出发地和目的地是哪里？”用户回答后，再问“出发日期呢？”
歧义处理：当槽位取值存在多种可能时（如“上海”可能是出发地也可能是目的地），列出选项让用户确认。例如“您是想从上海出发，还是到达上海？”
深层理解：基于用户画像或历史行为推断隐含诉求。例如用户是财务人员，说“看下Q2费用”，隐含诉求是“按部门分类的费用明细”，即使没明说也要补全。

Step 3｜L3 全局粗拆：只到领域层，不做原子拆解

为什么L3只做粗拆？

因为L3如果深入拆解到原子步骤，就会变成“超级单体”，既做全局决策又管局部执行，违背分层铁律。而且不同领域的拆解逻辑差异很大（如AI问数关注SQL生成，RAG关注检索策略），L3不可能预知所有领域的细粒度规则。

粗拆的具体方法：

基于领域标签分组：意图结构体中的domainLabels可能包含多个领域（如长报告、AI问数、RAG）。L3将这些标签对应的任务分别打包。
确定依赖关系：根据常识或规则判断领域间的先后顺序。例如“长报告”依赖于“RAG素材”和“AI问数数据”，所以①②并行，③等待①②完成。
生成全局DAG：每个领域任务作为一个节点，依赖关系作为有向边。DAG中允许并行节点，但默认工程简化版采用链式线性（串行），避免死锁和复杂调度。

输出产物：DomainTaskPacket列表，每个元素包含：

domainTaskId、domainLabel、goal、dependencies（其他domainTaskId列表）、expectedOutputSchema（期望输出的JSON Schema，用于L2执行后校验）

Step 4｜L2 领域细拆：真正决定“怎么做”的地方

每个L2 Domain Agent收到自己的DomainTaskPacket后，开始域内任务解析：

解析目标：理解本领域要达成什么结果，有哪些约束。
结合领域知识：例如AI问数领域，需要知道数据源的schema、SQL方言、权限限制；RAG领域需要知道向量库索引配置、topK参数等。
拆解原子任务：根据领域特性，将大任务分解为一系列L1可执行的原子步骤。

原子化原则的实操判断标准：

一个原子任务只能调用一个L1 Agent（或一次LLM调用）。
原子任务之间不能有交叉依赖（即A的输出不能直接作为B的输入的一部分，必须通过L2聚合后再传给下一个）。
原子任务必须能够独立测试和复现。

L2拆解输出：AtomTask列表，每个包含：

atomTaskId、detail、dependencies（其他atomTaskId）、executionType（tool_call / llm_call / code_exec）、completionCriteria（如“返回结果不为空且格式正确”）、expectedOutput（JSON Schema）

示例（AI问数L2拆解）：

AtomTask1: 解析用户需求，提取查询指标和时间范围 → executionType: llm_call (L1-LLM)
AtomTask2: 根据解析结果生成SQL语句 → executionType: llm_call (L1-LLM) [依赖AtomTask1]
AtomTask3: 执行SQL查询 → executionType: tool_call (SQL Agent) [依赖AtomTask2]
AtomTask4: 清洗数据（去重、格式化） → executionType: tool_call (数据转换Agent) [依赖AtomTask3]

问题二、任务拆解后，Agent 如何决定先后顺序、何时调模型/何时调工具

2.1 先后顺序：双层DAG + 拓扑排序

全局顺序（L3层）：

L3将DomainTaskPacket列表中的依赖关系转换为有向图，执行拓扑排序。
无依赖的领域任务可以并行下发（例如RAG和AI问数同时启动）。
有依赖的领域任务等待前置任务完成后才触发。L3通过监听L2的回调或轮询结果来推进。

域内顺序（L2层）：

L2需要采用ReAct循环还是DAG调度完成域内的 L3任务的临时编排 / 或者预编排。

2.2 L2 决定了什么时候调模型、什么时候调工具

这是L2 ReAct循环的核心步骤，也是整个架构的分水岭。

L2在每轮循环开始时，会执行一次模型思考，输出当前应该采取的行动类型：

行动类型枚举：

行动类型	含义	对应调用
`llm_reasoning`	需要模型进行推理、规划、总结、润色	调用L2自身的LLM（或L1-LLM调用Agent单次）
`tool_call`	需要调用外部工具获取数据或执行操作	调用对应的L1工具Agent
`code_exec`	需要运行一段代码进行计算	调用L1代码执行Agent
`user_clarify`	需要向用户追问缺失信息	暂停当前循环，返回反问消息给L3
`finish`	本域任务已完成	退出循环，聚合结果

具体映射表（基于文档中的L1清单）：

原子操作	走哪条路	说明
理解用户意图、拆解任务、规划步骤	L2自身LLM（决策行为）	这是L2的核心推理能力，不算“工具执行”
单次文本生成（如“把这段摘要改写成结论”）	L1-LLM调用Agent	单次、无状态、无推理，只是生成文本
多步文档规划+组装（如长报告）	L2自身推理 + 多次调用L1-LLM	L2负责规划，L1只负责生成段落片段
SQL查询、向量检索、代码执行、联网搜索	L1工具Agent	纯执行，无决策
数据清洗、格式转换	L1数据转换Agent	纯函数计算，无推理
异常处理（重试、降级）	L2自身逻辑	属于L2的运维能力，不涉及模型调用

三、总结：一张图看懂 L3、L2、L1 三层Agent 编排架构

用户输入
  ↓
L3预处理（清洗+上下文+分类）
  ↓
L3意图理解（三种方案 → 结构体）
  ↓
L3全局粗拆（领域级DAG + A2A路由）
  ↓
┌──────────────────────────────┐
│ L2领域Agent                  │
│  ├─ 域内任务解析             │
│  ├─ 选择调度模式（DAG/ReAct）│
│  └─ 执行循环                 │
│      ├─ 模型思考（决策）     │
│      ├─ 能力判定（调模型/工具）│
│      ├─ 调用L1（执行）       │
│      └─ 迭代直到完成         │
└──────────────────────────────┘
  ↓
L2聚合结果 → L3全局汇总 → 格式化输出