做平台之前我一直被一个问题折磨智能体越来越多却没有一个统一的地方能管住它们。一开始我们团队只接了一个对话机器人后来又加了数据分析助手、工单自动处理、文档审查好几个全都是各自部署、各自写监控、各自对接业务系统。结果每次线上出问题都得挨个翻日志问到这个月智能体一共花了多少钱哪个智能体响应最慢没人能立刻答上来。后来我们决定不再继续堆智能体而是先做一个混合型 AI 智能体 管理平台把所有不同类型、不同模型、不同自治程度的智能体统一纳管起来。这篇内容就是我搭建这个平台的实际记录会讲到架构分层、路由调度、观测评估、成本管控以及不少只有踩过坑才知道的细节。适合正在做 AI 应用工程化的后端架构师、平台工程师以及准备从单智能体走向多智能体协作的团队参考。1. 先对齐定义混合型到底在混合什么很多人听到混合型 AI 智能体第一反应是把多个智能体加起来。但我做了这个平台后才意识到混合不光是数量上的多它至少体现在三个完全不同的维度上管理平台要面对的是这三个维度交叉出来的复杂空间。1.1 三个维度的混合逻辑第一个维度是模型形态的混合同一个平台上既有大参数量模型驱动的智能体也有小参数量模型驱动的智能体甚至还有本地私有化部署的模型。大模型负责复杂推理小模型负责高频低难度的任务本地模型处理敏感数据。管理平台得让这些模型在同一个体系下共存而不是为每个模型单独做一套基础设施。第二个维度是决策方式的混合不是所有智能体都靠大模型想出来答案。我们平台上有相当一部分智能体是规则驱动和 workflow 驱动的比如工单分类、字段校验、定时任务调度这些用确定性的规则和状态机就能完成既快又可控。真正需要语义理解、多步推理的场景才交给大模型智能体。平台要把这两种决策方式统一编排不能默认智能体大模型。第三个维度是自治程度的混合全自动智能体可以一口气执行完任务半自动智能体在执行到关键节点时必须停下来等人工审批还有辅助型智能体只是给人类建议、不直接操作任何系统。这个维度在管理平台上特别容易被忽略但恰恰是生产环境能不能落地的最重要变量。我用一个表格把这四类典型的智能体放在一起对比方便后续讨论有一个共同语言类型决策方式典型场景延迟要求失败处理管理重点规则智能体确定性逻辑工单分类、格式校验毫秒级无歧义配置变更、版本灰度RAG 智能体检索增强生成知识问答、文档摘要秒级拒答 / 兜底知识库质量、引用溯源通用大模型智能体多步推理 工具调用数据分析、复杂查询秒级到分钟级重试 / 降级提示词版本、工具权限人工审批智能体推理 人类复核财务报销、权限申请分钟级到天级超时转人工流程状态、审批链路这四类智能体的运行特征差异巨大放在同一个平台里管理意味着我们的注册、路由、监控、成本模型都必须做得足够通用否则平台本身就会变成一个新的瓶颈。1.2 管理平台到底在管理什么想清楚这个问题很关键。我们的平台不是一个 AI 框架不负责写智能体内部逻辑平台的核心职责是在智能体之上做四件事生命周期管理、流量编排、状态协调、质量与成本监管。生命周期管理包括智能体的注册、版本发布、灰度、回滚、下线。你要能对某一个智能体发一个新版本只把 10% 的请求切过去观察没问题再全量。流量编排就是当一个用户请求进到平台时平台决定把它交给哪个智能体甚至把一个大任务拆成多个子任务分发给多个智能体。状态协调解决的是多智能体协作时的上下文传递、共享记忆、任务进度同步。这个问题在单智能体时代完全不存在但在混合平台上非常容易翻车。质量与成本监管则是把每个智能体的成功率、时延、Token 消耗、人工介入率这些指标统一采集、统一评估。一句话总结单智能体时代大家拼的是模型能力和提示词技巧多智能体时代拼的是平台的编排和治理能力。这也是我坚持要先做平台、再继续加智能体的原因。2. 平台骨架控制面与数据面分开设计架构设计上我参考了服务网格的思路把整个平台分成控制面和数据面。控制面负责想数据面负责做。这个拆分听起来有点抽象但对后续扩展帮助非常大值得展开讲讲。2.1 为什么必须拆开一开始我们图省事把路由判断、智能体调用、日志采集全部塞在一个服务里结果每个智能体接入都会改一遍公共代码发布一次就要把所有智能体都回归一遍完全不可维护。后来才下决心拆成两套平面。控制面包括智能体注册中心、路由决策引擎、版本管理服务、评估任务分发器、人工审批流程服务。这些模块的特点是变更频繁但流量小它们的输入大多来自运营配置和管理员操作不直接面对高并发业务请求。数据面包括智能体执行运行时、工具网关、上下文存储、跟踪采集器。这些模块面对的是线上真实流量它们必须能水平扩展、快速故障隔离而且不能因为控制面短暂不可用而停止服务。两套平面之间只通过一个轻量级的控制协议通信数据面定期上报心跳和执行状态控制面下发路由策略和配置变更。这样做的好处是我可以半夜发布一个新的路由策略完全不影响正在跑的业务请求某几路智能体执行异常需要重启时也不会把整个控制面拖垮。2.2 注册中心里放什么注册中心是整个平台的户口本每个智能体接入平台的第一件事就是在注册中心登记一份描述文件Agent Spec。我们把这份描述设计成 YAML 配置字段不多但每一个都直接决定后续的路由和运维。我贴一份简化过的 Agent Spec 示例agent_id:>routing_policy: order: - rule_match - intent_classify - capability_score rule_match: enabled: true source: agent_spec.rules intent_classify: model: small-intent-model-01 top_k: 5 capability_score: weights: semantic: 0.5 priority: 0.3 historical_success: 0.2 fallback: action: route_to_general_assistant log: true这套分级路由的本质是把确定性的逻辑放在前面把模型的灵活判断放在后面。越是能固定下来的决策越不该交给模型自由发挥。3.2 编排模式别一上来就搞复杂协作很多团队做多智能体时特别喜欢把所有智能体搞成交叉对话的网络状协作看起来炫酷实际生产一压测就崩。我在平台上沉淀下来四种基础编排模式绝大多数场景都够用了。第一种是 supervisor 模式一个主智能体负责拆解目标把子任务分配给其他智能体汇总结果并做最终输出。适合目标复杂但子任务相对独立的场景比如写一份竞品分析报告可以拆成数据获取、产品对比、文案撰写三个子任务。第二种是 pipeline 模式任务按固定顺序流经多个智能体上一个的输出是下一个的输入。适合有明确顺序依赖的场景比如先做数据清洗再做特征提取最后生成结论。第三种是 map-reduce 模式一个任务被拆成多份并行处理最后统一汇总。适合处理大量单据、审核大量文档这类场景重点是控制并发度避免瞬间把下游系统打满。第四种是 escalate 模式一个智能体解决不了时自动升级给更高级的智能体或转人工。这个模式最能体现混合的价值低成本智能体先试不行再升级而不是所有请求都直接上最强的智能体。一个任务也不一定只能套一种模式。我们实际写过一个任务策略示例task { id: report-2024-05, strategy: { type: supervisor, decompose: True, subtasks: [ {type: map_reduce, target: data_fetcher, parallelism: 4}, {type: pipeline, target: text_analyzer}, {type: escalate, target: senior_reviewer, if: result_quality_score 0.8} ] } }在这个例子里supervisor 先拆分任务数据获取部分走 map-reduce 并发执行拿到数据后交给文本分析智能体走 pipeline如果分析结果质量分低于阈值再 escalate 到人工评审。这就是混合编排的典型用法不同子任务用最适合的模式而不是一个模式套到底。3.3 上下文与状态传递多智能体协作最容易翻车的地方单智能体对话只需要管好一个上下文窗口多智能体协作后上下文问题会变成一场灾难。我们踩过一个大坑数据获取智能体返回了一套原始报表主管智能体把整张报表全部塞进下一个智能体的上下文窗口结果一个 5000 字的任务直接烧掉了几万 Token响应还变慢了十几秒。后来我们规定所有跨智能体的上下文传递必须经过三道处理一是摘要化。每个智能体传递给别人之前先用模型生成一段结构化的摘要而不是把原始结果原样搬运。原始大数据存放在对象存储里需要时再取。二是裁剪。系统对上下文设置一个字段级白名单比如只传最终数字结论、关键图表地址、异常标记不传中间计算过程、调试日志、全量行数据。三是版本化。每个任务会话维护一个上下文版本号某一步出错回滚时可以恢复到之前某版本的上下文而不是在已经被污染的状态里继续硬跑。同时我们给语义记忆和短期工作记忆做了分离。短期工作记忆存在 Redis 里TTL 设置为任务会话生命周期放的是当前任务的分步骤状态。语义记忆存的是智能体对某个长期用户的画像、偏好、历史结论放到向量库里只在需要做个性化回答时按相关度检索。这个分离对平台的可观测性和成本控制都有帮助因为你不会每次调用都把所有历史捞一遍。4. 可观测性与评估不被延期的那一层管理平台做得再漂亮如果上线后说不清楚每个智能体到底干得怎么样那一切都是空中楼阁。可观测性在我的优先级排序里仅次于路由引擎高于漂亮的配置界面。可观测性最核心的要求是一个执行链路至少能还原出四个信息入了什么请求、路由去哪了、调了什么工具、花了多少钱。4.1 链路追踪要落在三个粒度我们对每个请求分配一个全局 TraceID要求所有日志、工具调用、Token 计费都必须携带这个 ID。在此基础上追踪至少要覆盖三个粒度。第一个粒度是任务链路。从用户请求进入平台开始到最终响应返回这条链路上所有经过的智能体、编排步骤、重试行为都要有记录。业务排查时问的是这个用户的任务为什么失败了答案就在这个粒度里。第二个粒度是智能体内部。重点记录智能体内部调用模型多少次、每次的输入输出 Token 数、每次工具调用的入参与出参摘要。成本优化时问的是这个智能体为什么这么贵答案就藏在 Token 消耗的明细里。第三个粒度是模型服务。记录每个模型接口的调用量、成功率、后验时延、排队时间。模型提供方出问题时要先能看到是不是某个共享模型把资源吃光了而不是等业务方来反馈。我们给每个智能体定了几个核心指标这些指标也直接挂钩路由决策指标计算公式用途任务成功率成功任务 / 总任务路由兜底判断平均时延总时延 / 任务数性能监测单位任务成本Token 费用 / 任务数成本预算控制兜底率路由后转其他智能体的比例智能体能力判断人工介入率需要人工处理的任务占比自治程度评估这些指标不是只给人看的路由引擎实时消费它们。比如某个智能体的成功率连续十分钟低于 90%路由权重就会自动调低。4.2 评估集建设离线评测比线上评测更重要很多团队只做线上观察出了问题再补救这远远不够。我们的做法是建设一套分层评估用例库在每次智能体版本上线前先跑离线评测。用例库分为三层基础功能层、场景对抗层、回归防劣化层。基础功能层是每个智能体的标准输入输出对用来验证基本能力没有退化场景对抗层包含一些刁钻输入比如很长的用户输入、故意带错误数据的报表、模糊指令等回归防劣化层记录历史上出过问题的 case确保修过的 bug 不会复发。离线评测的过程完全自动化把用例输入跑一遍用打分模型和人工标注标准答案做对比算出一致性分。只有一致性分高于设定阈值的版本才允许进入灰度环境。我们评估集还专门加了同任务双跑的机制旧版本智能体和灰度版本同时在离线集上跑同一个输入各跑一遍然后把两份输出对比。这样能快速发现新版本把老能力弄坏了这类回归问题不用等到线上用户骂了才知道。4.3 线上评测怎么接住灰度流量离线评测不能覆盖所有线上变化所以灰度发布时我们还要做线上小流量评测。具体做法是新版本智能体只接收 5% 的流量但这 5% 流量的结果会被额外标记进入一个人工抽检队列。抽检规则不搞随机而是优先抽检出置信度低、任务失败、成本异常的请求。这样人力的投入集中在最容易出问题的地方。抽检结果会回流到评估集里变成新的回归用例。这一步相当于把线上发生的真实教训固化下来防止以后再犯。我特别想说一点评估和可观测性千万不要等平台上线后再补因为上线之后的历史数据是坏的、脏的、缺上下文的补出来的指标意义有限。我们在第二个智能体接入前就把追踪和评估打通了后面所有智能体接入都强制过同一套标准这一点省了后面大量的返工成本。5. 成本控制与安全治理让平台能活得下去一个混合型智能体管理平台如果只管性能和效果不管成本和权限它很可能在三个月后因为预算超支或安全审计不过直接被叫停。成本和安全不是运维课题而是平台的生存课题。5.1 成本模型怎么设计混合平台的成本不只是模型 Token 钱还有工具调用成本、人工处理成本、算力资源成本。我们在平台上把成本拆成四类模型推理成本、工具执行成本、人工介入成本、基础设施分摊成本。做过财务分析后你会得到一个反直觉的结论有时让大模型智能体多跑一步看起来花了更多 Token 钱却能减少一次人工介入综合算下来反而更划算。所以成本控制不是简单地把所有请求都往小模型上导而是建立一个统一的成本账本把每次任务的所有开销都记进去然后按业务线做单位成本核算。我们实行的成本策略是三级预算控制第一级是按智能体设定单任务成本上限超了就直接降级响应比如改成返回部分结果并提示信息过多只展示核心结论第二级是按业务线设定月度总预算预算快用尽时把该业务线的请求优先级调低减少非关键任务的调用第三级是平台总成本预警每天凌晨出一个前一天的账单按业务线、智能体、工具三个维度排列方便负责人对账。5.2 小模型优先与缓存兜底这一条是从成本账单里总结出来的一个简短的查询任务如果交给最大模型成本是小模型的好几十倍但效果差距往往没有那么大。所以我们把模型分层做了硬性约束只有路由判定任务复杂度达到一定阈值才允许调用大模型。阈值是怎么定的我们用历史数据做回归从已完成的日志里取一批任务记录它们的输入长度、工具调用次数、是否成功。统计后发现输入 Token 小于 800、工具调用不超过 1 次的简单任务用小模型就能达到 95% 以上的成功率。于是平台就把这些维度做成路由前置条件满足条件直接走小模型不需要经过能力评分。缓存也是成本控制的好朋友。我们对常见问答做了语义级缓存用户问的意图相似、语义相近的问题直接返回当时已经生成的答案不再调模型。实测下来问答型智能体的调用成本能省掉接近三成。5.3 权限边界与数据隔离平台上的智能体越多安全问题就越突出。一个智能体如果权限过大可能被恶意提示词诱导去调用不该调用的工具所以权限边界必须在平台层强制收敛不能靠智能体自己自觉。我们给每个工具调用都配了 ACL 策略粒度到智能体 对 某个工具 的 某个操作是否能执行。例如上面数据分析助手的描述文件里就限制了sql_database_query只能只读哪怕用户反复要求把数据库最近一周的用户明细导出发邮箱平台也会在工具网关层拦掉而不是等数据库权限被突破。数据隔离则分了两个层次一个是运行时数据隔离不同业务线的智能体使用不同的上下文存储空间跨业务线上下文不互通另一个是敏感数据脱敏工具网关对返回结果做脱敏规则匹配手机号、身份证号等个人信息在进入模型上下文前已经被打码避免它们进入模型训练或外部日志链路。审计日志也全程开启任何人或智能体对数据做了什么操作都可回溯这个在安全审计时是硬要求。6. 从零落地的关键步骤与踩坑实录架构思路讲了不少最后把从零落地这个平台的经验总结一遍。我们不是绿地项目是在一堆存量智能体的基础上做的改造所以过程更像是边治理、边迁移、边接入这个背景下积累的经验对新团队更有参考价值。6.1 建议的落地顺序第一步是只挑一个高频智能体做全链路打通。别一上来就规划十个智能体的大蓝图先选一个业务价值最高、链路最典型的智能体把它完整接入平台走完注册、路由、追踪、评估、计费全流程。这个阶段的目标不是面面俱到而是把平台的地基打夯实。第二步是确定黄金指标和评估基线。把上面提到的成功率、时延、成本、人工介入率在平台上先跑一两个星期拿到基线数据否则后续你无法判断新方案是否变好了。第三步是批量接入存量智能体。如果存量智能体接口规范不一致可以临时加一层适配器把各自的协议翻译成平台标准协议。适配器可以做得很薄目的只是让存量系统先活下来后续再逐步原生接入。第四步才是扩展多智能体协作场景。前几步走稳后同一个任务需要流转多个智能体时再引入 supervisor、pipeline 这些编排模式并配套上下文传递规范。6.2 那些踩过的深坑第一个坑是过度编排。我们曾为了让一个简单问答任务显得智能硬生生让意图识别、知识检索引擎、摘要模型、质量评估模型四个环节串行跑一遍。结果每个环节都很优秀但整体任务耗时增加了 4 倍效果提升可以忽略。后来我们把多环节编排设为默认不启用只有任务确实需要时才显式开启复杂度立刻降下来了。第二个坑是共享记忆的无边界扩张。最早我们为了让多智能体协作顺畅把工作记忆设计成全局共享所有智能体都能读写同一个 Redis 空间。结果一个智能体在一次失败任务里写入了脏数据另一个智能体在下一次任务里读到了这份脏数据还把它当成了用户真实诉求导致一连串错误输出。后来我们强制所有共享数据都带任务 ID 和过期时间跨任务读取必须显式声明问题才消失。第三个坑是路由策略变成黑盒。有一段时间我们给能力评分增加了十几个权重维度理论上很完美但一旦线上出问题没人能解释为什么某个流量被路由到某个智能体。后来我们做了路由决策可解释性改造每次路由都会记录参与判断的关键因子并附上命中理由排查问题的时候一查便知。可解释性不是可选项路由一旦复杂起来它就是刚需。第四个坑是评估集被人为污染。为了让灰度评测通过率更高有人会偷偷往评估集里加专挑简单用例导致指标虚高。我们的应对办法是评估集的修改必须有管理员审批并留有操作记录同时从线上随机抽 10% 的真实请求进入复评让评测结果和真实表现互相校验。6.3 运行一段时间后的真实感悟平台上线三个月后再回头看最大的收益并不是某一次技术指标优化的效果而是团队的协作方式被彻底改变了以前每个智能体各自为政现在所有智能体都共享一套观测体系以前讨论方案靠拍脑袋现在可以指着成功率曲线和数据账单讨论。至于具体数字我们平台上最典型的成功案例是一个大模型驱动的数据分析智能体经过路由分级和小模型优先改造后单位任务成本下降一半同时成功率提升近十个百分点——光是成本优化这件事就足够说明平台的价值。如果要说给正在考虑做这件事的团队一个最朴素的建议我会说先别纠结平台的形态是服务网格还是网关也别纠结架构图多漂亮先想清楚你要统一管理哪些维度然后立刻找一个智能体把追踪、路由、评估跑通。混合型 AI 智能体管理平台不是一个一次建成的阶段交付物它是一个会跟着智能体数量同步生长的治理体系。把地基打对方向后面每一步都是积累方向不对每一步都会变成需要推倒重来的试错。