ModelEngine企业级多智能体协作系统实战指南

从去年开始我把 ModelEngine 从“跑通 Demo”逐步推进到了生产环境期间最大的感受是企业级的 AI 系统靠单个大模型硬扛是不现实的真正需要的是一套能编排、可控制、能审计的多智能体协作机制。这篇文章就把我在 ModelEngine 上构建“企业级 AI 团队”的思路、配置、部署和排障过程完整记录下来适合正在做智能客服、内部助手、多步骤自动化决策的团队参考。1. 为什么“单个大模型”撑不起企业级业务很多团队一开始都会走一条路把业务规则全部塞进一个 Prompt让一个大模型处理所有请求。这种方案在 Demo 阶段没问题一旦进入生产环境痛点会集中爆发。我最早也这么干过后来被线上问题逼着切换成了多智能体架构。1.1 单体 Prompt 的天花板单个大模型处理复杂业务时Prompt 会越来越长。比如一个客服系统既要判断用户意图又要查订单还要处理退款、安抚情绪、识别风险所有指令堆在一个 Prompt 里表面看很省事实际会遇到三类问题指令冲突、行为漂移和排障困难。指令冲突不同角色的规则互相干扰。让模型“语气热情”的同时“严格拒绝超额退款”模型往往会顾此失彼经常在边界场景上做出意料之外的选择。行为漂移今天调好了一个场景下周因为新增了一条规则模型在其他场景上的表现就变差了。修改一个模块影响的是全局。排障困难用户反馈回答不对你只能对着几千字的 Prompt 猜是哪个规则出了问题没有清晰的调用链路无法快速定位。更麻烦的是成本。一个大模型处理任何请求无论简单复杂都会消耗相近的 token 和延迟。高频简单问题被大模型“大材小用”成本很难降下来。1.2 多智能体协作的核心价值多智能体的思路本质上是把一个庞大的全能型“员工”拆成多个各司其职的“小员工”。每个智能体只负责一个明确的小任务用适合自己的模型遵守自己那份 Prompt。这样做有三个明显优势。第一是职责边界清晰。意图识别只负责输出结构化意图订单查询只负责调用外部接口并格式化结果退款处理只负责执行退款策略。出了问题看是哪个智能体的输出不合理直接定位到人。第二是模型选型灵活。高频的路由、质检任务用响应快的小模型就够真正需要生成回复或处理复杂推理的节点才调用大模型。整体的平均成本和延迟都下来了。第三是故障半径可控。退款接口超时不会影响整个链路可以通过降级策略把请求转到人工处理而不是让整个系统都被拖死。1.3 ModelEngine 到底在解决什么问题ModelEngine 不是又一个聊天框架。它更像一套企业内部的工作流引擎只不过执行单元从“函数”变成了“智能体”。它主要解决三件事消息如何在智能体之间流转、工作流的并行与分支怎么编排、会话状态和上下文怎么在多个智能体之间共享。实际用下来我的理解是它的核心抽象是「数据流 控制流 会话状态」。数据流决定了一个智能体的输出能不能作为另一个智能体的输入控制流决定了请求是走串行、并行还是条件分支会话状态则是整个协作过程中的“共享便签”让不同智能体知道当前用户发生了什么、已经做到哪一步了。理解了这三个维度后面搭团队就顺了。2. 搭建团队的前提角色设计与流程编排把多智能体系统比作公司第一件事不是招人写代码而是画组织架构图。智能体角色没有设计好后面每一步都是坑。2.1 角色不是随便起的先做职责拆分我见过不少团队一上来就定义“客服智能体”“销售智能体”这种粒度太粗。角色拆分的核心原则是一个智能体只做一件可以独立描述清楚的事。判断标准很简单——如果这个智能体的 Prompt 里需要写“同时”两个字说明它应该拆开。比如售后场景我不会只定义一个“售后 agent”而是拆成意图识别 agent只负责把用户的话归类成订单查询、退款申请、投诉、其他输出一个 JSON。订单查询 agent根据用户提供的订单号调用订单接口把结果转成简洁的摘要。退款处理 agent核对退款政策、计算可退金额、调用退款接口。质检 agent检查前面所有 agent 的输出是否合规、有没有风险表述。人工兜底 agent当意图不明确或流程走到异常分支直接转人工。每个角色的输入输出都需要用 schema 约束住。什么意思就是让模型按固定结构返回数据不要让它自由发挥。意图识别的输出必须是{intent: refund, confidence: 0.92}而不是一段自然语言。结构化的中间结果是后面流程编排和路由判断的前提。2.2 编排方式串行、并行、条件分支角色定好了接下来要看怎么把它们组织起来。ModelEngine 的编排基本是三类模式对应不同的场景。串行A 的输出作为 B 的输入适合有依赖关系的任务比如先识别意图再查询订单。并行多个独立任务同时执行比如同时查订单、查优惠券、查库存适合能并行计算的节点能显著降低响应时间。条件分支根据某个节点的输出决定走哪条路比如意图是退款就走退款流程意图是投诉就走投诉流程。实际配置里条件分支最容易出错。很多人喜欢在 workflow 里写各种判断但判断条件依赖的字段一定要在前面先结构化好。不要在分支条件里去依赖自然语言描述模型输出稍微一变流程就断裂了。2.3 一个“售后客服团队”的完整配置示例这里给一个简化版配置完整还原了我第二版售后系统的结构。真实实现里节点 id 会更多但骨架就是这样。agents: - id: intent_router model: fast_model prompt: 识别用户意图只返回结构化结果 output_schema: type: object properties: intent: type: string enum: [order_query, refund, complaint, other] confidence: type: number customer_id: type: string - id: order_query model: large_model tools: [query_order_api] input_from: [intent_router] output_schema: type: object properties: order_status: type: string message: type: string - id: refund_handler model: large_model tools: [refund_api, check_policy_api] input_from: [intent_router] parameters: refund_threshold: 5000 - id: quality_check model: fast_model input_from: [order_query, refund_handler] prompt: 检查上述输出是否包含风险承诺、违规表述或敏感词 - id: human_handoff type: notification notify_target: oncall_group need_human: true workflow: - start - run: intent_router - switch: - condition: intent order_query and confidence 0.7 then: [order_query, quality_check] - condition: intent refund and confidence 0.7 then: [refund_handler, quality_check] - condition: confidence 0.7 then: human_handoff - default: human_handoff这个例子有几个关键细节要强调。每个 agent 的input_from指定了数据来源串行关系就藏在里面。switch里用了confidence 0.7作为路由保护。模型识别不准的时候宁可转人工也不要往下走流程。退款节点设置了阈值参数超过 5000 的申请会走人工审批这个在业务上是必须的。质检节点放在所有生成节点之后相当于又一道护栏。这个配置跑起来之后整个链路的行为从“一个大模型自由发挥”变成了“一条有红线、有分支、有兜底的固定流水线”。业务方来问某个单子怎么处理的我能直接指出它在哪个分支、过了哪些节点这是单体 Prompt 做不到的。3. 核心协作机制实战记忆、路由与消息传递角色和流程定好了真正让智能体“协作”起来的是三个底层机制共享记忆、消息路由和消息传递。这块如果理解不透配出来的系统经常会出现“各干各的、互相不通气”的问题。3.1 共享记忆与状态管理多智能体协作最基础的需求是B 智能体怎么知道 A 智能体刚才说了什么答案是需要一份共享记忆。我把它理解成工位旁边的公共白板任何节点都可以往上面写信息但要遵守约定。在 ModelEngine 这类引擎里共享记忆通常分成两层。会话级状态记录当前用户对话过程中的临时信息比如用户身份、订单号、已执行的步骤。全局级配置记录所有会话都适用的规则比如退款阈值、风控开关、模型参数。实际操作里我建议遵守两条纪律。第一智能体对共享状态尽量“只读”需要写入时使用自己独立的命名空间。比如订单查询 agent 只写order_query.result退款 agent 只写refund_handler.result不要大家共用一个大字段。否则并行执行的时候后写的数据把先写的数据覆盖掉排查起来特别痛苦。第二不要把长对话历史全部塞进每个智能体。企业级场景下很多对话历史对当前任务没有帮助全部传给每个智能体既浪费 token又容易造成“上下文漂移”。更好的做法是每个智能体只接收必要的结构化摘要再加上最近几条原始消息。3.2 消息路由与条件匹配路由是编排的发动机。我在实践中反复强调路由条件必须基于结构化字段不能基于自然语言判断。什么意思意图识别 agent 的输出必须是{intent: refund, confidence: 0.95}这种格式然后 workflow 里用intent refund判断。如果意图识别 agent 的输出是“用户想要退款”这种自然语言路由就没法稳定工作了。另外路由判断一定要带上置信度阈值。模型识别用户意图不可能百分百准确低置信度时强行走自动流程后续节点会用错误的前提做一堆无用功最后用户还要投诉。我的做法是confidence 0.7一律走人工兜底这一步能让自动解决问题率稍微下降一点但整体用户体验提升一大截。3.3 流式输出、外部工具与数据落库企业级系统绕不开外部依赖。退款要调支付接口订单查询要调订单服务这些都不是模型自己能完成的。ModelEngine 里把外部工具包成可调用的函数智能体在需要的时候触发调用。这里有一个关键设计智能体不能自己“实现”外部功能它只能“编排”对工具函数的调用。退款 agent 不需要真的知道退款接口怎么实现它只需要按照 schema 向工具函数传参比如{order_id: 123456, amount: 88.5}然后拿到结果继续处理。数据落库也很重要。每个智能体的输入、输出和中间决策都应该有持久化记录。我见过不少团队只记录最终回答中间节点完全不落库。等到用户投诉说“你们的系统承诺给我双倍赔偿”你根本查不到是哪个智能体做出了这个承诺。后来我在每个节点都加了审计日志这才算真正可控。注意工具函数的返回值也要定义 schema。如果工具返回乱格式的数据智能体后续处理时很容易产生幻觉随意解读不存在的字段。4. 部署与可观测性让 AI 团队稳定“上班”多智能体系统不是开发完就结束了部署和上线后的稳定性比单体系统要求更高。毕竟你现在是让一堆“数字员工”在线上协作任何一个环节掉链子整个流程都会卡住。4.1 模型接入与资源配置多智能体架构的优势之一是可以用不同模型干不同的事。我在生产环境里做了两类模型配置。节点类型模型定位核心要求典型用途路由、质检节点快模型低延迟、低费用意图识别、格式校验、合规检查生成、决策节点大模型强推理、高质量生成回复、处理复杂退款策略配置层面ModelEngine 做了模型供应商抽象你可以在不改业务代码的情况下切换不同模型。但我们线上不配“默认所有节点都用大模型”而是每个 agent 单独指定模型。这个细节能让成本差好几倍。在并发配置上我建议给不同节点设置不同的最大并发数。路由节点并发可以高一点因为它是快模型、耗时不长外部工具调用节点反而要限流防止瞬时大量请求打到下游订单服务的接口把对方打挂。4.2 并发量与费用估算上线前一定要做容量和费用估算。我有一套简单的估算公式单请求平均智能体调用次数 每条业务请求经过的有效节点数。假设一天有 1 万用户提问每个用户平均产生 3 次请求平均每条请求串行经过 3 个智能体节点那么一天的总 LLM 调用次数是10000 × 3 × 3 90000 次再假设平均每次调用的上下文总量约为 1200 token输入 800 输出 400那一天的 token 总量约为90000 × 1200 1.08 亿 token按当前主流商业模型的价格估算这个量级的日成本大概在几百元到上千元之间。如果你全部用大模型处理同样的调用次数单次 token 成本可能翻 2~3 倍。所以用快模型处理路由和质检不是抠门是合理降本。4.3 日志、追踪与告警多智能体出问题时最怕的是没有“调用链”。一个请求从入口进来一路上经过哪些节点、每个节点用了什么模型、消耗了多少 token、结果是什么这些必须全部能被追踪。我的做法是给每个外部请求生成一个唯一的 trace id从入口网关开始传递给后续所有节点。日志里除了记录输入输出还要记录模型名称、token 数、耗时、状态码。这样排查问题就像看新闻联播一样按时间线把整个流程拉出来。告警规则也要单独定不能只监控服务器指标。我比较关注三类指标错误率智能体调用失败率超过 1%说明链路有问题。延迟P95 响应时间超过预期阈值说明慢模型节点需要优化。费用每日 token 消耗环比增长超过 20%触发提醒检查是不是出现死循环或异常重复调用。5. 企业落地中的高频问题与排查技巧实录这个章节全是真金白银的踩坑记录。我在多智能体系统上线后遇到过不少集中爆发的问题很多都是代码测试时发现不了的。5.1 智能体之间死循环问题表现某段时间费用快速增长日志里发现两个智能体在反复互相调用同一个请求一直循环到超时。根因工作流里存在回环。比如 A 智能体输出异常结果触发了 B 智能体的分支B 又调用了 A而且没有设置最大跳数。排查方式先看 trace id 相关的日志数一下同一个请求经过了多少个节点。如果出现几十次重复的节点记录基本就是死循环。解决办法我给每条请求增加了最大跳数限制默认 20 跳超过直接熔断转人工。同时在 workflow 设计阶段就禁止出现“从下游节点指回上游节点”的显式回环。在 ModelEngine 里尽量用 switch 表达条件不要在一个节点内部去触发另一个节点的复杂逻辑。5.2 输出格式不稳定问题表现部分请求走到路由节点的时候突然报错提示 JSON 解析失败。根因模型输出偶发不合规常见的有多了一个逗号、字段名变了、把布尔值输出成了字符串。排查方式看路由节点的输入日志把那几次失败请求的原始输出捞出来对比基本能发现规律。解决办法双重校验。第一层在模型输出后立即做 schema 校验不通过就重试一次第二层准备一个“宽容解析”兜底比如尝试解析 JSON 里的某段内容。另外在所有 prompt 里都要求“只输出 JSON不要输出任何解释性文字”能把异常率压到千分之几以下。5.3 外部 API 调用失败与幂等问题表现有用户反馈被重复退款了。根因退款接口第一次调用超时系统判断失败后自动重试结果第一次调用其实已经成功了第二次请求又执行了一遍退款操作。排查方式调取退款 agent 的工具调用记录能看到同一个退款请求被提交了两次。解决办法所有写操作的外部工具必须支持幂等调用时带上唯一的请求 id服务端根据请求 id 去重。我在所有写操作工具里都加了request_id字段并且在重试逻辑里改成“查询上一次请求的状态如果未知结果就只查不重试”。这个原则适用于退款、转账、发券不能只是口头上强调。5.4 共享状态被莫名覆盖问题表现并行执行了查订单和查优惠券两个节点最后回答里优惠券信息是对的但订单信息却变成了空。根因两个并行节点都向同一个共享变量写入后完成的节点覆盖了先完成节点的结果。排查方式看 trace 里两个节点的完成时间再对照共享状态的最后一次写入时间。解决办法给每个 agent 配置独立的输出字段然后再设计一个汇总节点去拼接结果。并行节点只写自己的 namespace谁也不要碰别人的数据。5.5 费用失控问题表现上线一周后成本比预估高出一倍多。根因口径不对。很多请求走了并行分支实际 token 消耗比串行估算高另外某些节点设置了 unlimited 重试失败一次就反复调用大模型。排查方式看每个节点的 token 统计按节点维度排序基本能找到大头。解决办法给所有大模型节点设置最大重试次数默认 2 次。凡是低风险判断类任务一律切换成快模型。每周末出一份 token 消耗报表按 agent 维度看趋势哪里异常就查哪里。这里整理成一个速查表方便团队内部转发。现象可能根因第一排查路径长期对策死循环 / 费用激增流程存在回环看同一 trace 的节点次数加最大跳数禁止回环JSON 解析失败模型输出不规则捞失败节点的原始输出schema 校验 宽容解析重复退款 / 重复发券写操作未做幂等看工具调用记录调用带 request_id失败只查不重试并行结果互相覆盖共享变量没隔离对照节点完成时间独立 namespace 汇总节点成本超预期重试/并行过度使用按节点维度的 token 报表限重试次数快慢模型分流6. 我的几点建议和踩坑体会最后这部分不是总结就是我这段时间摸爬滚打积累下来的朴素经验希望后来的人少走点弯路。6.1 从最小协作单元开始第一版不要直接搭十个智能体会把自己绕晕。我建议从“一个路由节点 两个执行节点 一个质检节点”起步。先跑通最简单的串行链路确认共享记忆和路由都没问题再慢慢加并行分支和复杂条件。一上来就追求大而全往往连最基本的日志排查都做不好。6.2 给每个团队配一个“质检智能体”企业级场景不能信任任何智能体的裸输出。质检节点放在流程末端用快模型检查前面所有输出里有没有风险承诺、违规用语、误导性信息。这个节点非常关键它相当于内容发布前的最后一道校对。我在客服系统里加了它之后需要人工介入的高危投诉数量明显下降。6.3 后续可以这样扩展这套架构跑稳定之后扩展方向很多。可以加入异步任务把耗时的生成类工作放到队列里做用户不用一直等待可以加入人工审批节点在退款超阈值、投诉升级等场景强制转人工还可以做多团队编排比如一个系统里同时跑“售前推荐团队”和“售后支持团队”通过统一路由分配。ModelEngine 的数据流和会话状态模型足够支撑这些场景关键还是业务规则要设计清楚。有一点我特别想说多智能体系统真正难的不是调模型而是工程化习惯。输入输出结构、状态隔离、链路追踪、幂等控制、预算告警这些才是企业级 AI 团队能不能稳定运转的底座。只要把这些基础打牢换更好的模型、加更多智能体都是水到渠成的事。