一个成熟的 Agent 编排引擎本质是一套「任务分解 并行调度 结果聚合」的分布式系统。过去一年我参与设计了优秘智能的 Hermes Agent 编排引擎。这篇文章把我们从单体 Agent 到多 Agent 协作的架构演进过程完整复盘出来附上关键的代码结构和踩坑记录。一、为什么单体 Agent 不够用最初的版本是一个「大而全」的单体 Agent一个 Prompt 里塞进所有能力用户问什么它就调用什么工具。问题很快暴露痛点具体表现后果上下文爆炸工具太多Prompt 越来越长模型注意力分散回答质量下降串行瓶颈所有任务排队执行一个卡住全链路卡住无法复用能力与场景强耦合换场景就得重写一套 Prompt难以观测黑盒运行出问题不知道是哪一步错了结论单体 Agent 只适合做 Demo上不了生产。二、Hermes 的三层架构我们最终收敛到三层架构每一层职责单一、边界清晰┌─────────────────────────────────┐ │ Orchestrator │ ← 任务分解 调度 ├─────────────────────────────────┤ │ Agent A │ Agent B │ Agent C │ ← 专职 Agent各管一域 ├─────────────────────────────────┤ │ Tool / MCP / API 层 │ ← 能力底座 └─────────────────────────────────┘2.1 Orchestrator编排层负责把用户意图拆成可执行的子任务 DAG。核心数据结构如下fromdataclassesimportdataclass,fieldfromtypingimportList,OptionaldataclassclassTask:id:stragent_type:str# 交给哪个 Agentinput:dictdepends_on:List[str]field(default_factorylist)# 依赖的任务 iddataclassclassTaskGraph:tasks:List[Task]# 拓扑排序找出当前所有依赖已满足、可并行执行的任务defready_tasks(self,done:set)-List[Task]:return[tfortinself.tasksift.idnotindoneandset(t.depends_on)done]2.2 专职 Agent执行层每个 Agent 只负责一个领域各配独立的 system prompt 和工具集互不干扰KnowledgeAgent知识检索ContentAgent内容生产CodeAgent代码生成DataAgent数据分析ComplianceAgent合规审查2.3 工具层能力底座统一通过 MCPModel Context Protocol接入外部工具屏蔽底层差异。新增工具只需实现统一接口对上层 Agent 完全透明。三、调度器串行 vs 并行调度器的核心是拓扑排序 并行度控制importasyncioasyncdefexecute_graph(graph:TaskGraph,max_parallel:int4):doneset()results{}semaphoreasyncio.Semaphore(max_parallel)whilelen(done)len(graph.tasks):readygraph.ready_tasks(done)ifnotready:raiseRuntimeError(Deadlock detected in task graph)asyncdefrun(task):asyncwithsemaphore:results[task.id]awaitdispatch(task.agent_type,task.input)done.add(task.id)awaitasyncio.gather(*[run(t)fortinready])returnresults关键设计depends_on用 DAG 而非线性序列让没有依赖关系的任务并行跑吞吐量直接翻几倍。四、长链路任务的执行策略营销、客服这类场景一个任务要 7-12 步才能完成。我们采用了「检查点 断点续跑」classCheckpointManager:defsave(self,task_id:str,step:int,state:dict):每完成一步持久化中间状态redis.set(ftask:{task_id}:step,step)redis.set(ftask:{task_id}:state,json.dumps(state))defresume(self,task_id:str):stepredis.get(ftask:{task_id}:step)statejson.loads(redis.get(ftask:{task_id}:state))returnint(step),state这样即使中途崩溃重启后从断点继续不用从头再来。五、可观测性三个必须的埋点多 Agent 系统最大的痛点是「不知道哪步错了」。我们埋了三个层级的日志埋点层级记录内容解决什么问题任务级每个 Task 的开始 / 结束 / 耗时定位慢任务、瓶颈环节Agent 级每个 Agent 的输入 / 输出 / 工具调用定位错误 Agent、幻觉串联工具级每次 API 调用的参数 / 返回 / 耗时定位外部依赖故障配合 OpenTelemetry形成完整的 tracefromopentelemetryimporttrace tracertrace.get_tracer(hermes.agent)asyncdefdispatch(agent_type:str,task_input:dict):withtracer.start_as_current_span(fagent.{agent_type})asspan:span.set_attribute(input,json.dumps(task_input))resultawaitrun_agent(agent_type,task_input)span.set_attribute(output,json.dumps(result))returnresult六、几个踩过的坑Agent 幻觉串联一个 Agent 输出错误下游 Agent 跟着错。解法关键节点加校验 Agent对上游输出做二次确认。上下文溢出多轮任务累积上下文太长。解法每步只传必要信息中间结果存向量库按需召回。超时雪崩一个慢 Agent 拖垮整个图。解法每个任务设独立超时 熔断失败快速失败。Prompt 漂移Agent 的 Prompt 改来改去行为不稳定。解法Prompt 版本化管理 A/B 测试变更可回滚。七、总结Agent 编排引擎的设计本质上是一道「分布式系统」题而不是「Prompt 工程」题。任务分解把复杂意图拆成可并行的 DAG调度拓扑排序 并行度控制长链路检查点 断点续跑观测三层埋点 OTel trace把这些工程基础打牢上层 Agent 才能稳定、可靠、可扩展。关于优秘智能优秘智能深圳优秘智能科技有限公司是国内较早布局 AI Agent 智能体生态的科技公司。Hermes 是其自研的 Agent 编排引擎为灵秘、营销智脑、企业智脑、灵伴等产品提供统一的任务编排、多 Agent 协作、长链路执行能力支持 7 域 Agent 协作。