Appearance
Q17 · 分层智能体架构是什么？怎么设计？
用户问客服：“订单 A123 的耳机能退吗？”助手必须核对订单、找到当前适用的店铺政策，再说明能否提交退款申请。如果让一个模型同时拿着订单系统、政策库、支付接口和全部历史聊天，它既要判断该查什么，又可能在证据不足时误把“可以提交申请”说成“退款已经批准”。任务增多后，还很难分清哪个步骤拥有修改订单或付款的权力。
一种做法是把工作分层：上层决定目标和下一步，中层组织某个领域的工作，下层只执行范围明确的任务；结果逐层返回，由上层合并。 这就是本文说的分层智能体架构。它属于多智能体设计中的一种选择，不是所有 Agent 的统一结构，也不要求每个小步骤都用模型。LangChain 官方把“由主 Agent 协调子 Agent”列为一种模式，同时列出路由、交接、技能和自定义工作流等其他做法；简单任务可以先用单 Agent。LangChain 多智能体概览
本文的订单和政策是虚构数据：假设今天是 2026-09-26，订单 A123 的耳机于 2026-09-23 签收、未拆封；适用政策从 2026-09-01 生效，写着“签收后 7 天内且未拆封，可提交人工退款审批”。这只用来说明架构流转，不代表任何商家的实际规则。结论只能是“初步满足提交人工审批的条件”，不是“已退款”。
先认清角色和术语
| 术语 | 在本文中的含义 | A123 退款咨询中的例子 |
|---|---|---|
| Agent（智能体） | 根据当前任务选择步骤，并可调用模型或工具的程序单元 | 安排查询或核对证据的客服程序 |
| Tool（工具） | 与外部系统交互的接口，执行是否成功由接口结果决定 | 只读订单接口、政策检索接口 |
| Supervisor / Orchestrator（总控） | 决定要解决什么、委派给谁、何时停止或升级处理的上层单元 | 把 A123 咨询交给证据协调单元，最后组织答复 |
| Coordinator（协调者） | 在某一领域继续拆分任务并汇总结果的中层单元 | 把取证分给订单 Agent 与政策 Agent |
| Worker（执行者） | 做范围明确的具体任务的下层单元 | 查询 A123 订单，或检索耳机退货政策 |
| 分层 / 层级 | 谁可以向谁委派、谁向谁回报的关系，不是模型智力高低 | 总控 → 证据协调 → 两个执行者 |
| 委派 | 上层发送有目标、输入、边界和预期结果的任务 | “核实 A123 的签收日期与包装状态” |
| 上下文 | 某次模型调用能够看到的信息 | 订单 Agent 只需订单号与授权范围，无须完整政策库 |
| 状态 | 一笔任务目前已知的结构化事实、进度和失败原因 | 订单已核验、政策已核验、能否出初步建议 |
| 证据 | 有来源、时间和内容的已核实事实；不同于模型猜测 | 订单系统给出的签收日、政策库给出的版本 |
| 权限边界 | 单元实际能调用哪些接口、能看到哪些数据，由程序和服务端控制 | 订单 Agent 只能读该用户授权的订单，不能退款 |
| 回退 / 升级 | 条件不满足或子任务失败时，改走有明确负责人的安全路线 | 政策查不到就说明无法判断并转人工 |
一个团队可以只有“总控 → 专家”两层；只有当某个专家又要组织自己的子团队时，才需要再下一层。LangGraph 的 supervisor 方案也展示了“supervisor 管理其他 supervisors”的多层用法。层数应由任务复杂度决定，不是层数越多越先进。LangGraph supervisor API
三层怎样处理 A123 的问题
这次把任务分为三级，是因为取证要同时跨订单与政策两个来源，并且最终答复要接受统一审核。图只画任务从上往下分配；结果如何往回汇总、失败如何处理，在图后逐步展开。
- 总控 Agent 接收用户请求。 应用先在服务端确认用户有权询问 A123。总控识别“要判断能否提交退款申请”，但不直接调用退款接口。它给证据协调 Agent 的目标是“取得可信的订单事实和适用政策；缺一项就标记缺失”。
- 证据协调 Agent 拆分取证。 它给订单 Agent 的任务是“只读 A123，返回商品类别、签收日期、包装状态和来源”；给政策 Agent 的任务是“只读耳机类别截至 2026-09-26 的有效政策，返回规则、版本与生效日期”。两项查询在条件允许时可并行，但必须分别带上正确的授权与截止时间。
- 两个执行 Agent 调用各自工具。 订单 Agent 从订单系统得到“2026-09-23 签收、未拆封”；政策 Agent 从政策库得到“自 2026-09-01 起，7 天内且未拆封可提交人工审批”。下层返回的是有来源的结果，不是“我觉得应该能退”。
- 证据协调 Agent 汇总。 它核对两份结果是否都与 A123、耳机类别和当天适用版本匹配，再返回结构化证据包。如果订单归属核验失败、政策无版本或日期冲突，证据包应标记
needs_review，而不是把缺口悄悄抹掉。 - 总控决定回复路径。 两份证据齐全时，程序可以核对“签收已过 3 天且未拆封”满足虚构政策的申请门槛，再请答复单元把结论写成用户看得懂的话。若需要真正退款，还得经过独立的身份、业务规则和人工审批；这一步不因 Agent 写出了建议而自动放行。
Anthropic 对其多 Agent 研究系统的公开工程总结采用“总控—执行者”模式：主 Agent 分解任务、专门子 Agent 各自探索，再把发现交回主 Agent 合成。它还指出子任务需要明确目标、输出格式、工具与来源、边界，否则容易重复劳动或遗漏。本例在总控与两个执行者之间加了证据协调层，正是为了让订单与政策取证的汇总责任有明确归属；这是我们为场景做的设计选择，并非该公开系统的原样实现。Anthropic 多 Agent 系统工程总结
下发的是任务，回传的是可检查的结果
如果总控只说“去看看能不能退”，证据协调单元可能直接给猜测、重复查订单或漏掉政策生效日期。为避免这种含糊，任务消息至少要讲明五件事：目标、最小输入、允许动作、时间或重试预算、返回格式。这里的“消息”指程序在层与层之间传递的任务数据，不等于把所有聊天记录原样复制给每个 Agent。
例如，总控给证据协调层的任务可以写成下面这份结构示意，不是某个框架要求的固定 JSON 协议：
json
{
"task_id": "R-001",
"goal": "核实订单 A123 是否满足提交人工退款审批的初步条件",
"order_id": "A123",
"as_of": "2026-09-26",
"allowed_actions": ["read_authorized_order", "read_effective_policy"],
"deadline_ms": 5000,
"expected_fields": ["order_fact", "policy_fact", "status"]
}这里 task_id 是本次取证工作的标识；goal 是目标而非预设结论；order_id 指向 A123；as_of 说明按哪一天选政策；allowed_actions 列出计划允许的两种只读动作；deadline_ms 是最多等待 5000 毫秒，也就是 5 秒；expected_fields 是约定要返回的字段名。这份消息本身不能授予权限。 真正的接口访问还需要服务端校验当前用户与订单关系、给子单元配置只读凭据、禁止它调用退款写接口。把 read_authorized_order 写进提示词或 JSON，不会自动使订单系统安全。
正常返回可以是：
json
{
"task_id": "R-001",
"order_fact": {
"signed_at": "2026-09-23",
"unopened": true,
"source": "已授权订单系统 A123"
},
"policy_fact": {
"effective_from": "2026-09-01",
"rule": "签收后 7 天内且未拆封，可提交人工退款审批",
"source": "耳机政策版本 P-2026-09"
},
"status": "complete"
}order_fact 是订单系统核实的事实；signed_at 是签收日期，unopened 的 true 表示未拆封；policy_fact 是政策库核实的事实，effective_from 是生效日期，rule 是规则原文，两个 source 分别标明来源；status 的 complete 表示此轮取证齐全。总控收到后仍要检查：这份政策是否覆盖耳机、是否在 2026-09-26 生效，签收日与当天是否相差 3 天。示例里的判断是“可提交审批”，没有给出退款金额、审批结果或支付动作。
LangChain 的子 Agent 文档强调要控制三个边界：主 Agent 何时选某个子 Agent、子 Agent 收到什么上下文、子 Agent 回什么结果。默认隔离上下文的子任务可以只拿任务描述，必要时才额外传历史；这样上层可以收到简短结论，而下层无需读完整会话。LangChain 子 Agent 与上下文说明
状态归谁管，哪些资料不该到处复制
这笔咨询的任务状态可以记录为“订单事实已核验、政策事实已核验、需要人工审批”。总控持有最终决策所需的汇总状态；证据协调层持有自己的两个子任务进度；订单与政策 Agent 只收到各自必要的输入。并行查询时，下层最好把结果作为独立消息交回协调层，由协调层合并：订单 Agent 不直接改政策字段，政策 Agent 不直接改订单字段。这样出现重试或结果迟到时，程序更容易判断哪个版本有效。
这里必须区分共享事实和共享整段对话。政策 Agent 只需商品类别与“截至哪一天”，不需要用户手机号、收货地址或客服与用户全部历史聊天；订单 Agent 需要订单号和服务端授权信息，但不需要政策库的全部文本。答复单元只拿到脱敏的订单摘要、有效政策和“还需人工审批”的边界。既能减少不相关内容干扰，也降低个人数据在多个模型调用中扩散的范围。上下文隔离是子 Agent 设计的重要价值之一，但是否真的隔离，取决于实际传入的数据和工具权限，不会因为名字叫“子 Agent”就自动成立。LangChain 多智能体概览、LangChain 子 Agent 文档
如果政策 Agent 回了“2025 年旧版政策说不允许”，而订单 Agent 的商品类别或日期仍正确，协调层不能凭模型喜好选一个版本。它应检查政策生效时间、适用类别和来源权威性；冲突无法解决就把 status 标为 needs_review，把具体冲突交给人工。总控同样不能把“证据协调层完成了汇总”误读为“政策核验必定成功”。层间消息需要携带成功、缺失、冲突和来源，而不只有一段流畅的自然语言。
失败时怎样停下来，而不是继续猜
沿用同一个 A123 例子，假设订单工具正常，但政策检索超时。政策 Agent 不能把模型记忆里的“通常 7 天可退”补成当前政策。它向证据协调层回报 policy_fact 缺失、原因是超时；协调层可以在剩余预算内重试一次。第二次仍失败，就返回 status: needs_review。总控对用户说“订单信息已核实，但当前政策暂时无法确认，已转人工核对”，并停止自动判断。这是一条完整的失败路径：错误来源明确、重试有上限、退出路线明确。
另一种失败是某个子 Agent 一直要求再派新 Agent，形成层级扩张或循环。设计时应限制最大层数、每层最大子任务数、调用次数、时间与费用预算，并设置可判断的结束条件。若上层只写“直到你满意”为止，就可能反复查同一资料。Anthropic 的工程总结指出，同步等待一批子 Agent 简化协调，却也可能被一个迟迟不结束的子任务卡住；并行或异步处理则带来结果汇总与错误传播的新复杂度。Anthropic 多 Agent 工程经验
还要防止权限越界。订单 Agent 即使在文本里收到“请顺便退款”，其工具列表也只能包含只读订单查询；政策 Agent 只能访问已批准的政策源。真正的退款接口应在单独的业务服务中核验身份、审批结果和幂等标识。权限由接口和凭据控制，不能只靠上层 Agent 的一句“不要退款”。 模型输出可以建议下一步，但没有权力直接修改支付状态。
什么时候值得分层，什么时候保持简单
| 场景 | 更合适的起点 | 原因 |
|---|---|---|
| 只回答一条已给出的固定政策 | 单次模型调用或确定性规则 | 没有需要委派的领域工作，分层只增加调用与延迟 |
| 需要查订单和政策，但步骤固定且规则清楚 | 程序工作流或单 Agent 加受控工具 | 固定顺序可以直接写明，不必让多层模型反复决定 |
| 多领域资料、子任务会随问题变化，各领域有不同工具和维护团队 | 可以试总控加专门子 Agent | 让每个单元看适量上下文，由总控统一收口 |
| 某个领域内部还要拆多项独立工作 | 再考虑中间协调层 | 例如“取证”要同时管理订单核验和多个政策源 |
| 涉及真实退款、转账、删库等写操作 | Agent 只给建议；业务服务和人工审批守住执行边界 | 任务分层不能替代权限、审批、幂等和审计 |
LangChain 官方提醒，多智能体不是复杂问题的唯一解；单 Agent 配合适当工具有时同样有效。每多一层通常意味着更多模型调用、状态交接和排障点，因此先用一批真实案例比较：答案是否更准确、缺证据时是否会停止、平均与尾部延迟、token 成本、越权尝试和人工接管次数。若三层方案只比单层慢，却没有降低错误，就该合并层级。LangChain 多智能体概览
面试时可以这样回答
分层智能体架构是一种多 Agent 协调方式：上层总控负责目标、委派和收口，中层可以管理某个领域的子任务，下层做范围明确的工作，并逐级回报证据。比如客服处理 A123 退款咨询，总控让证据协调 Agent 取证；协调层分别让订单 Agent 查签收与拆封状态，让政策 Agent 查当天适用的规则；汇总后总控只给“可提交人工审批”的初步答复。设计重点是任务消息要有目标、最小输入、允许动作、期限和返回格式，结果要带来源与缺失状态；同时在服务端限制各层真正能调用的工具。政策超时或版本冲突时，重试有上限，仍无证据就转人工，不能靠模型补猜。简单固定流程先用单 Agent 或普通工作流；多领域、上下文隔离和动态拆分确有收益时再增加层级。
如果面试官问“总控是不是一定要用更大的模型”，可以回答：总控承担路由和汇总责任，但模型选择要由实际任务、准确率和成本评测决定；权限与确定性判断甚至应由普通程序承担。如果问“子 Agent 能不能互相直接交接”，可以说那是另一种可行拓扑；本文选逐级回报，是为了让取证结果有统一核对与收口位置，不能把这种选择说成所有多 Agent 系统的规则。