智能体面试准备五十八多智能体生产级协同与编排实战——从编排内核到灰度上线引言与上一篇、系列的关系上一篇五十七我们让智能体「可被观测、可被计量」本篇再往前一步讲当多个智能体要一起跑生产流量时怎么把它们编排成可靠、可容错、可灰度的系统——也就是多智能体生产级协同与编排实战。它和十五多智能体协作、三十四编排引擎、五十五多模态 Agent 工程都有承接但本篇只讲生产工程编排内核怎么设计、状态怎么持久化、失败怎么隔离、怎么灰度。为什么这是收官级面试题因为单 Agent demo 谁都会写但「10 个 Agent 跑真实流量还不雪崩、能回滚、能扩缩」才是工程能力的分水岭也正是华为多模态 LLM 平台岗需要的。多智能体生产编排架构 -------------------------------------------------- | API / 触发源 | -------------------------------------------------- | 任务 -------------------------------------------------- | 编排内核 (Orchestrator) | | - DAG / 状态机解析 | | - 调度 / 重试 / 超时 / 熔断 | | - 上下文总线 (共享黑板) | -------------------------------------------------- | 派发 ---------------------------------------------- | Agent A | Agent B | Agent C | ... | 工具/检索 | | (规划) | (检索) | (推理) | | (4MRAG 等) | ---------------------------------------------- | 事件/结果 -------------------------------------------------- | 消息总线 持久化状态机 (断点续跑) | -------------------------------------------------- | 逐步 -------------------------------------------------- | 灰度 / 回滚 / 人工节点 (HITL) | --------------------------------------------------第一节 编排的两种核心抽象生产编排通常建立在两种抽象之一或组合DAG有向无环图任务是节点的预定义依赖适合流程固定、可并行的场景。优点是确定、可静态分析、易容错。状态机State Machine运行时根据条件跳转适合需要循环、分支、等待外部输入的场景如二十二长时任务。工程上更稳的是「DAG 为主干 状态机处理动态子流程」并用一个持久化状态存储把两者串起来支持二十二讲的断点续跑。# 极简 DAG 编排骨架classNode:def__init__(self,name,fn,depsNone):self.name,self.fn,self.depsname,fn,depsor[]defrun_dag(nodes,ctx):done{}pendingsorted(nodes,keylambdan:len(n.deps))whilepending:npending.pop(0)ifall(d.nameindonefordinn.deps):try:done[n.name]n.fn(ctx)# 失败由外层重试/熔断包裹exceptExceptionase:done[n.name]{error:str(e)}else:pending.append(n)# 依赖未就绪稍后重试returndone第二节 上下文总线多 Agent 怎么共享信息多 Agent 协同最大的坑是「各说各话、上下文丢失」。工业界用共享黑板blackboard/ 上下文总线统一存放中间产物每个 Agent 只读写自己关心的槽位。机制特点适用共享内存黑板低延迟、单进程单机 demo消息总线(Kafka)解耦、可重放分布式生产持久化 KV 版本支持断点续跑长时任务classBlackboard:def__init__(self):self.store{}defput(self,key,val,versionedTrue):self.store[key]valdefget(self,key,defaultNone):returnself.store.get(key,default)# Agent 之间只通过黑板协作避免隐式耦合bbBlackboard()bb.put(plan,planner.run(query))bb.put(retrieved,retriever.run(bb.get(plan)[subq]))answerreasoner.run(bb.get(plan),bb.get(retrieved))这正好对应你 4MRAG 的 pipeline检索、重排、推理、校验各为独立 Agent通过共享上下文串联天然支持横切扩展按需组合模态检索器。第三节 容错重试、超时、隔离、熔断生产环境里 Agent 比普通服务更易出错LLM 可能胡说、工具可能超时、检索可能空。四道防线重试 指数退避对工具/LLM 超时类错误重试对「结果不可信」类错误不重试避免放大幻觉。超时隔离每个节点有独立超时一个卡死不拖垮整条链路。舱壁隔离bulkhead不同用户的任务用不同资源池避免互相挤占。熔断某工具连续失败直接熔断走降级路径如二十六小模型兜底。importtimedefwith_retry(fn,retries3,base1.0):foriinrange(retries):try:returnfn()exceptTransientErrorase:ifiretries-1:raisetime.sleep(base*(2**i))# 指数退避# 不应到达第四节 灰度与回滚新编排怎么安全上线多智能体改了编排逻辑不能直接全量。工程做法复用二十三灰度思路影子模式新编排先跑镜像流量结果不生效只对比指标。小流量放 5% 用户盯延迟/成本/质量漏斗接五十七看板。非劣性门禁新编排在核心指标上不差于旧版才放量接五十六门禁。一键回滚编排配置版本化出问题秒切旧版。defshould_rollout(new_metrics,old_metrics,tol0.02):# 非劣性核心指标退化不超过 tol 才继续放量forkin[quality,cost,latency_p99]:ifold_metrics[k]-new_metrics[k]tol:returnFalse,f退化:{k}returnTrue,ok第五节 与 4MRAG 项目的串联话术面试时你可以直接把 4MRAG 当成多智能体编排的范例讲它的 pipeline 本质是一个带校验回路的 DAG——检索 Agent、重排 Agent、推理 Agent、置信度校验 Agent 通过黑板串联置信度低时触发按需组合模态检索器的子流程状态机分支整个链路可断点续跑、可灰度。这把五十三多模态 Agent、五十五多模态 RAG、五十七可观测、五十八编排全部串成一条完整的生产故事比单纯说「我做了个 RAG」有冲击力得多。第六节 生产 checklist上线前必过编排配置版本化、可回滚每个节点有超时 重试 熔断上下文总线持久化支持断点续跑全链路 trace 成本打点接五十七灰度门禁 一键回滚人工节点(HITL)在关键决策处兜底第七节 一个真实编排故障与修复面试可直接讲讲一个多智能体上线踩的坑。我们把「规划 Agent → 检索 Agent → 推理 Agent」跑成串行 DAG结果一次检索超时把整条链路拖死 30 秒用户大面积超时。根因是检索节点没有独立超时且失败后被无限重试放大。修复分三步第一给每个节点加独立超时检索 5s、推理 15s超时即走降级答案第二引入舱壁隔离把高优先级用户任务分到独立资源池避免被长尾任务挤占第三检索连续失败触发熔断直接降级到「无检索的保守回答」并标记低置信度交由五十七的可观测看板告警。改动后 p99 从 30s 降到 4s超时率归零。这个案例能说明生产编排的本质不是「让 Agent 更聪明」而是「让系统即使部分失败也不崩」。面试速答本篇可直接背的 3 句多智能体生产编排用「DAG 主干 状态机子流程 持久化状态」既确定又可断点续跑。多 Agent 靠共享黑板/消息总线解耦协作避免上下文丢失与隐式耦合4MRAG 即此范式。容错四件套重试退避、超时隔离、舱壁、熔断上线走影子→小流量→非劣性门禁→一键回滚。高频追问清单DAG 和状态机怎么选答流程固定用 DAG需循环/分支/等待用状态机生产常组合状态持久化支撑续跑。多 Agent 上下文怎么不丢答统一共享黑板/KV 总线每个 Agent 只读写自己槽位避免隐式耦合。一个 Agent 卡死怎么办答节点独立超时 舱壁隔离 熔断降级不拖垮整链。编排改动怎么安全上线答影子→小流量→非劣性门禁→一键回滚配置版本化。4MRAG 怎么体现编排答检索/重排/推理/校验 Agent 经黑板串联置信度低触发模态检索子流程分支可续跑可灰度。