多Agent系统架构设计与工程落地：从拆分到治理的实践指南

1. 为什么需要多agent拆分的真实动机与判断标准1.1 单agent的瓶颈用着用着就撞上了先说个我自己的真实经历。去年我帮一个客户做问数智能体最初是一套单agent架构一个LLM一套工具函数一个系统提示词。单agent在demo阶段跑得飞快演示效果惊艳领导很满意。结果一到真实业务数据问题就来了——业务方一会儿问华东区Q2营收环比一会儿问为什么库存周转天数上升了一会儿又问把上个月退货率最高的SKU列出来。所有这些问题都涌进同一个上下文再加上工具返回的大批表格片段上下文很快被打满模型开始丢三落四有时候把时间条件看漏有时候拿错指标口径甚至有一次把昨天的数当成上个月的数算。这其实是单agent架构的典型症状上下文膨胀导致指令遵循能力衰减工具集混杂导致模型频繁选错工具故障定位困难——一旦结果错了你根本分不清是检索的错、计算的错还是模型推理的错。我当时就在想要是不同的职责拆成不同的agent各自管各自的上下文和工具是不是能从根本上解决这个问题1.2 拆或不拆一张表说清楚结合后来做的多个项目我总结出一个判断框架。不是所有场景都该上多agent多agent是有成本的——通信开销、状态一致性、故障排查复杂度都会上升。我一般从四个维度去判断判断维度适合拆成多agent适合保持单agent上下文需求不同类型任务需要完全不同的记忆和工具上下文所有任务共享同一份知识库和工具集工具职责工具间有明显边界如数据查询、文档生成、代码执行工具数量少且互相可以替代错误定位要求必须精确到每个处理环节便于追责和审计结果错一次重跑一次也能接受并发与扩展性不同任务可并行执行且各自节奏不同单请求串行处理链路简单直接一个典型的反面教材是某个团队把一句话客服问答拆成了意图识别agent情感分析agent回答生成agent三个agent轮番调用延迟涨了三倍效果却和单agent差不多。这种拆法属于为了架构而架构纯给自己添堵。正面案例是企业数据问答系统。这个场景天然适合拆第一数据口径判断、SQL生成、结果解读是三个截然不同的能力域第二每个环节的中间结果都需要被单独审计这个SQL是谁生成的口径依据是什么第三数据查询和报表解读可以并行推进。所以把问数智能体拆成指标口径agentSQL生成agent结果解读agent是有明确收益的。1.3 水平拆分与垂直拆分的选择确定了要拆下一步是决定怎么拆。我习惯把拆分方式分成两类垂直拆分按职责分层比如上面提到的问数场景从理解问题到匹配口径到生成SQL到解读结果每一层是一个agent。这种拆法的好处是每层职责单一上层可以换下层也可以换故障边界清晰。坏处是链条变长任何一层出问题都会阻断整个流程。水平拆分按领域/数据范围拆分比如把数据按地域拆成华东agent华北agent或者按业务线拆成销售agent供应链agent。这种拆法适合数据隔离要求高、各领域知识差异大的场景。但要注意水平拆分容易产生信息孤岛——跨领域问题需要额外的路由agent去协调。真实项目里通常两种拆法混合使用。我目前维护的系统中垂直方向有问题理解agent→口径检索agent→SQL生成agent→结果解读agent水平方向按业务线划分了不同的口径检索agent。架构图画出来是这样的分层关系入口层问题理解agent负责把自然语言转成结构化任务同时做权限前置校验路由层根据业务线把请求转给对应的口径检索agent执行层SQL生成agent 安全校验agent双人复核模式出口层结果解读agent负责把数据结果组织成最终答复这个结构经历了三次大改才稳定下来里面有不少坑后续章节会逐一展开。2. 架构设计的核心决策拓扑、通信与分工2.1 三种主流拓扑各有各的适用场景多agent系统有三种主流拓扑编排者模式Orchestrator、对等协作模式Peer-to-Peer和市场模式Marketplace。我在不同项目里都用过这里直接给结论。编排者模式是我最推荐作为起步方案的。一个主控agent负责接收用户请求、拆解任务、依次调度子agent、汇总结果。优点是流程可控、便于加权限校验和审计、失败时定位问题非常直观。缺点是主控agent容易成为瓶颈和单点故障。对等协作模式适合任务边界清晰且需要频繁交换中间结果的场景。比如一个写研报的系统数据收集agent直接对话图表生成agent不需要经过主控转发。优点是交互路径短延迟低缺点是系统行为不可预测两个agent可能会因为目标冲突反复纠偏调试起来非常痛苦。市场模式说直白点就是agent发布服务其他agent按需调用其本质是一个服务注册中心。这个模式适合超大团队内部不同部门各自维护agent、互相提供服务的情况。但它对契约管理和版本兼容要求极高落地成本最大。我的建议很明确第一个版本老老实实用编排者模式。等跑通全链路、积累了真实的trace数据后再把热点路径改成对等协作。不要一开始就追求高级架构多agent系统最大的敌人是不确定性编排者模式是帮你建立确定性的第一步。2.2 通信协议不只是把消息传过去很多人在设计多agent系统时只关注谁调谁忽略了消息长什么样。通信协议设计的好坏直接决定了系统的扩展性。我的消息设计借鉴了经典的事件驱动思路每条消息包含不可变的头部和可版本化的载荷消息ID全局唯一用于追踪和幂等Trace ID同一用户请求的全链路追踪标识生产者与消费者标识用于路由和权限校验消息类型控制指令如执行任务取消任务或数据载荷时间戳记录消息生成时间用于诊断时延载荷体实际任务参数必须支持版本化避免上游升级后下游解析失败这套消息头设计看起来简单实际效果非常好。排查问题的时候只要拿Trace ID一查整条链路上的每个环节都非常清晰。举个例子我现在的口径检索agent与SQL生成agent之间传递的消息载荷结构大致是这样的{ 消息ID: msg_8f3a2b91, traceID: trace_7c9d2e4f, producer: agent.口径检索, consumer: agent.SQL生成, type: TASK_EXECUTE, version: 1, timestamp: 2025-06-12T10:23:1508:00, payload: { taskId: task_56, bizLine: sales, metric: revenue, dimensions: [region, month], filters: {region: 华东, month: 2025-05}, permissionContext: {userId: u_1024, role: manager} } }2.3 控制面与数据面分离这是一个在网关和微服务架构里已经被验证过的理念放到多agent系统里同样成立。多agent系统在运行时有两类流量一类是真正的业务数据流比如SQL查询结果、生成的文案另一类是控制指令比如暂停任务切换到某个子agent重新执行某一步。我之前见过一个团队把所有信息都塞进同一个频道结果agent之间的对话非常混乱——一个agent在讨论业务数据另一个agent却在发布控制指令协调者的上下文被反复污染。后来我把二者分离控制指令走单独的头部字段或者独立的事件topic业务数据走专门的载荷字段。这个改动之后系统的稳定性有明显提升。控制面还有一个容易忽略的问题取消和回滚。真实业务中用户经常会中途改需求或取消任务。多agent系统如果只管下发任务不管取消任务那取消指令根本传不到正在执行的下游agent或者传过去了但下游agent已经生成了半截结果。我的做法是所有需要长时间执行的任务都支持取消令牌机制每个agent在执行前检查取消令牌执行中定期检查。虽然做不到完美中断但至少能把无效资源消耗压到最低。2.4 每个agent的配置要独立管理多agent系统里每个agent都有一组自己的配置项系统提示词版本、模型选择、温度参数、可用工具列表、超时时间、重试策略。把这些配置写死在代码里是我见过最普遍、也最糟糕的做法。我建议把每个agent的配置外置为一份描述文件内容大致如下name: sql_generation_agent description: 根据口径检索结果生成可执行的SQL model: provider: openai_compatible name: qwen-max params: {temperature: 0.1, max_tokens: 4096} system_prompt_version: 12 tools: - data_catalog_query - sql_executor - permission_checker behavior: timeout_seconds: 30 retry_count: 2 max_iterations: 3这份配置会被配置中心统一管理改一个agent的参数直接改YAML再发布不用改代码、不用重新构建镜像。到了后期这套配置也是治理体系的重要抓手——一切审计和评测都基于配置展开。3. 会话状态与数据流的工程化设计3.1 三级状态模型全局、流程、私有多agent系统里状态的位置很尴尬——放哪都有问题。我最终沉淀出了一套三级状态模型实测比较可靠全局上下文Global Context存储用户身份、权限、目标场景信息、跨agent共享的约束条件。每个agent在执行时都能读但不能随意改。更新权限集中在主控agent和入口层。流程状态Flow State一个任务的中间状态比如当前执行到第几步哪些步骤已经完成哪些正在等待响应。这个状态只存在于当前任务的存续期间由编排者agent统一维护。私有状态Private State单个agent自己的运行数据比如检索到的候选指标、生成的SQL草稿。其他agent不直接读写只能通过流程状态间接获取。这套模型的价值在于既保证了关键信息的共享又避免了agent之间互相污染内部数据。我踩过的坑就是早期把全局上下文设计成了谁都可以写结果一个agent在上下文里加了一句话另一个agent就因此改变了行为轨迹问题极难排查。3.2 手动实现一个简洁的编排状态机可靠的执行离不开状态机。我不建议依赖某个框架自带的状态管理最好在架构层自己设计一个极简状态机用字符串枚举表达状态流转。执行流程的完整状态转变如下PENDING→ 任务已创建等待执行ROUTING→ 正在根据业务线确定下游agentEXECUTING→ 某agent正在执行任务REVIEWING→ SQL等执行结果正在校验COMPLETED→ 全部环节成功完成FAILED→ 某个环节失败CANCELLED→ 用户取消我建议给每个agent的核心任务都内置这部分状态流转逻辑并通过事件消息广播状态变化。这样从任何节点切进去都能看到任务卡在哪一步、是哪条链路、谁在负责问题定位效率高出一大截。3.3 短会话与长任务的存储选型状态数据存储方案也是一大坑。我现在的方案是分两层短生命周期数据单次请求内的传递数据、临时中间态用内存或RedisTTL设置为任务超时时间的两倍。数据跨agent传递时只传消息ID和数据引用不传完整数据块避免大字段在链路里反复传输。长生命周期数据用户会话记录、每个agent的执行历史、评测样本落PostgreSQL或对象存储。每个agent执行完一个任务就写一条历史记录包括输入输出的缩略信息、使用的模型版本、耗时和Token消耗。3.4 数据血缘问数系统最不能省的功夫血缘追踪在处理数据从哪来的合规问题上极其关键。我的做法是让每个agent在产出数据时自动在结果中附上血缘标记。SQL生成agent在生成查询语句时会带上三个标签口径来源引用的是哪个指标定义、数据版本数据仓库的版本或快照时间、计算逻辑汇总方式、过滤条件。到结果解读agent向用户展示时会给答案的每个环节配一份简洁的溯源说明卡片。虽然这会让系统开发和联调的工作量增加不少但它是业务方信任一个数据问答产品的基础。用户看到口径来源财务部营收口径V3数据版本DWD层2025-05快照才会放心把这份数据用到月度经营分析会上。4. 从demo到生产多agent系统的可靠性工程4.1 框架选型与时延控制多agent系统的框架选择我和不少同行聊过大家的结论是框架只是加速器核心还是要自己把数据结构和治理机制想清楚。我之前用的是AgentScope 2.0这类框架来简化多agent的调用配置核心流程上的探索配置可以快速完成但工程侧的保障依然要靠自己的代码实现。这里补一句框架负责agent之间怎么调用的问题但解决不了调用过程中出错了怎么办的问题。后者是你自己的工程责任。时延控制是多agent系统落地时最容易被低估的坑。单agent接口P95可能只需要3秒拆成三个agent串行调用后P95直接变成9秒再叠加模型推理的时间波动体验会很差。我的应对手段有三个可并行的任务坚决并行。比如口径检索和权限校验没有依赖关系就同时发起能省掉一个完整串行环节的时间。中间结果流式返回。SQL生成agent每产出一段内容就推给结果解读agent提前处理不必等完整SQL生成完。缩短链路层级。当某个子agent的响应足够好时就不再向上汇报原始过程只汇报最终答案减少一层汇总延迟。4.2 超时、重试、幂等与降级一个都不能少多agent系统的架构非常脆弱因为链路长、依赖多任何一个外部API抖动都会传导到用户侧。我在工程上做了四件事超时管理针对每个agent设置精确的超时阈值。比如SQL生成agent调用大模型接口30秒超时工具调用则根据工具类型分类管理——数据查询限时10秒是合理的复杂报表生成可以放到60秒甚至更长。超时之后必须走兜底不能让用户死等。重试策略不是所有失败都该重试。LLM调用超时属于临时故障重试2次是合理的而用户权限不足或业务参数错误属于确定失败重试只会浪费算力。我给每个agent配置了允许重试的错误清单超时、限流、网络抖动会触发重试参数校验失败则直接返回错误。幂等设计这是最容易忽略的。你重试一个创建工单的agent调用两次后果可能是用户收到了两张重复工单。解决方式是在消息头加幂等键下游agent缓存已处理的消息ID重复消息直接返回上次的结果。这个机制在重构后几乎没有再出现过重复执行的问题。降级策略当某个子agent连续失败超过阈值时主管agent要能自动降级——比如从SQL生成agent降级为直接查询预置报表虽然回答的灵活性下降但至少用户能拿到数据而不是一个超时错误。4.3 部署形态与最小单元打包部署上我强烈建议遵循一agent一服务或一容器的模式。每个agent的代码、依赖、模型配置独立打包独立扩缩容。这样做的直接好处是某个agent流量大了单独给它扩容即可不用连带把整个系统副本数都抬上去。我之前帮客户做过一个三容器五命令级别的快速部署演示形态——一个入口网关容器、一个编排agent容器、一个执行agent容器配上一条启动命令就能拉起一套可用环境。这种极简部署非常适用于小团队验证概念和做POC但是生产环境还是需要更完善的部署形态服务编排、配置中心、日志采集、链路追踪组件一个都不能少。4.4 可观测性多agent系统的暗夜探照灯可观测性在多agent系统里的地位怎么强调都不过分。我每次排查问题都会先打开链路追踪面板看一遍完整的调用瀑布图每个agent的耗时、Token消耗、输入输出长度、错误信息全部一目了然。没有这套体系多agent系统就是个黑盒出了问题只能靠猜。我的观测指标分三类面向业务请求成功率、平均处理时延、单次任务平均调用agent数量面向成本每次请求的Token消耗、模型调用次数、各agent的资源占比面向质量各agent的输出长度、重试次数、工具调用失败率如果你现在只够精力做一件事就先把Trace ID贯穿全链路让每个agent的日志、指标都按Trace ID聚合。5. 治理体系血缘追踪、权限、审计与评测5.1 权限模型不能让agent越权多agent系统的权限治理比传统API网关复杂得多。传统网关只要校验用户能不能调这个API而多agent系统还要校验agent能不能用这个工具agent有没有权限读取这批数据。用户A和用户B调用同一个agent能查的数据范围可能完全不同。我的设计思路是引入双重权限层用户-请求层用户身份、角色、数据权限范围在入口校验生成一个加密的权限上下文随消息头传给下游。agent-工具层每个agent有自己允许调用的工具清单和执行环境隔离。数据敏感程度高的工具除了校验用户权限还要二次确认该agent是否有权限代表用户执行。这套双重校验机制上线后权限越权的投诉基本清零。我再举一个细节SQL生成agent生成的SQL在真正执行前会经过一个安全校验agent做语法检查和敏感操作拦截比如禁止SELECT *、禁止无WHERE条件的DELETE、禁止访问未授权的表。这个设计其实借鉴了代码评审里的双人复核理念——一个角色负责干活另一个角色负责把关。5.2 审计日志谁在什么时间做了什么审计日志是治理体系里最枯燥但最重要的部分。我的审计记录固定包含以下字段请求发起时间、用户ID、触发入口、调用的agent链、每个agent的输入输出摘要、Token消耗、模型版本、结果反馈。所有记录写入独立的审计存储业务删除权限完全没有只有合规账号可查。审计日志的查询能力也很重要。我设计过几类最常见的检索模式按用户查这个用户在某个时间段内发起了哪些请求、看到了哪些数据按任务查某个任务完整的执行链路每个环节的出入参——用来排查无头冤案按数据查某个指标被哪些用户、哪些agent调用过——用来做敏感数据泄露溯源审计还有一个容易被忽视的价值当你打算在某条链路上砍掉一个看似多余的agent时审计日志能告诉你这个agent被调用过多少次、其结果被采纳的比例是多少。数据会说话而不是我感觉。5.3 评测体系多agent系统不能盲人摸象多agent系统的评测比单agent难在整体效果好但不知道是哪个环节的功劳整体效果差也定位不出是哪个环节的问题。我采用的是一套分层评测端到端评测的组合。端到端评测面向用户价值拿一批真实历史问题做回归集在系统完成重构后逐个运行并对比答案质量。注意这里不能简单用模型打分当唯一标准对于数据类问题还要做事实性校验比如把答案中的每一个数字都跟真实数据库结果比对一次。分层评测面向单个agent。SQL生成agent的评测指标是生成SQL可执行率和结果与标准SQL结果的一致性口径检索agent的评测指标是口径命中的准确率和top-1命中率结果解读agent的评测指标则要看信息忠实度和可读性。黄金数据集的构建是评测工作里最花时间的一步。我从真实日志中采样了500条历史问题逐条人工标注了标准SQL和标准答案。这一批数据是治理体系的基石每次模型升级或prompt调整都要用它做回归验证。没有这个数据集你根本无法判断优化到底是变好了还是变坏了。5.4 成本治理钱要花在刀刃上多agent系统的成本比单agent高出不少因为一次用户请求可能引发多个agent各调一轮模型Token消耗成倍增长。成本治理我按这个优先级来做第一步厘清成本结构。按agent维度、按用户维度、按任务类型维度统计Token消耗。不量化就无法管理。第二步建立缓存。高频问题如本月销售额是多少会命中语义缓存直接复用历史答案同时聚合多个同类请求来降低重复计算。同部门用户的相似问题也能通过缓存提速。第三步模型分级。链路里的关键推理环节用强模型简单的路由和格式转换环节用弱模型是在效果和成本之间最有性价比的杠杆。我见过太多团队所有agent一律用同一个最强模型成本翻了几倍效果提升却很有限。第四步配额与告警。为每个业务线设置月度Token预算超过百分之八十就预警超过百分之一百就触发限流或降级。这看起来像财务问题实际上是架构问题——没有配额机制成本会像没人管的水龙头一样一直流。6. 落地避坑清单与经验总结6.1 五个高频踩坑点强烈建议收藏坑一agent之间互相污染上下文。早期让子agent共享一份公共记忆结果A写进去的中间结果成了B的错误输入。后来严格区分私有状态和全局上下文再也不混了。坑二重试导致重复执行。没有幂等键的时候超时重试造成了大量业务数据重复写入。加上幂等键后这个问题才彻底根治。坑三模型升级引发行为漂移。同一个prompt换了模型版本后输出格式发生了变化下游agent解析失败。解决方式是在每个agent的prompt里加上必须返回合法JSON并严格遵守输出schema的约束同时在评测集里增加输出schema校验用例。坑四配置散落各处无法审计。早期agent的模型参数和工具列表散落在代码里上线后根本不知道线上跑的是哪个版本。全部外置到配置中心后每个agent的线上配置才真正做到可追溯。坑五过度追求全自动。一开始想让系统全自主决策不给人工介入点。实际运营发现某些关键环节加一个人工确认节点能拦截掉大量潜在事故。多agent系统不是越自动化越好——在数据输出、资金操作、外部消息发送这类高影响动作前保留人工确认是治理的基本要求。6.2 架构演进路线图我建议按四个阶段推进多agent系统落地每个阶段的投入和产出都比较清晰阶段核心任务关键产出第一阶段单agent跑通核心流程问题清单、数据集雏形、权限边界梳理第二阶段按垂直职责拆成2-3个agent采用编排者模式消息协议、Trace ID、状态机第三阶段引入治理组件权限、审计、评测权限模型、审计日志、回归集第四阶段性能优化与成本治理缓存、模型分级、降级策略我在多次实践中确认了一点不要在第二阶段就想着做第四阶段的事。很多团队在agent还没跑稳时就急着搞市场模式和高级缓存结果基础链路的问题还没解决新架构的复杂性又把问题放大了。先把最简单的编排者模式跑通把治理体系的数据基础打好再谈优化。6.3 从架构师视角的最终心得架构设计除了画图更重要的是回答这个系统出问题时我怎么能快速知道是哪一环出了错以及这个系统换人维护时新人上手的路径是什么。一份好的治理体系本身就是一份活的架构文档——它通过配置中心、审计日志和评测数据集把架构的每一处决策都变成了可查看、可验证、可追溯的实体。从个人经验来说我见过太多多agent项目在demo阶段惊艳全场上线后却因为跑一次错一次、错了不知道怪谁而迅速被业务方放弃。问题的根源不是模型不够强而是工程化程度不够治理体系缺位。模型能力终究是其中的一环真正决定系统能不能在真实环境里持续稳定运行下去的是你围绕模型搭起来的架构设计、工程保障和治理机制。希望这篇基于实操的经验分享能帮你少走几步弯路。最后补一句多agent系统的落地节奏应该是小步快跑、治理同步。第一版哪怕只有一个主agent加两个子agent也要把流控、权限、审计骨架搭进去。治理不是等系统复杂了再补的而是从一开始就要长在系统里的。