早期微信AI机器人的架构很直接收到消息调大模型模型回答里要查订单就由后端调业务接口。业务复杂度上来后这种直连模式会全面失控——模型想换一家要改遍所有调用点、业务接口鉴权方式各不相同、模型调用成本没人管、敏感对话直接发给外部模型。新阶段的架构思路是引入两个网关模型网关统一管理所有大模型调用工具网关统一管理所有业务能力业务编排层只跟两个网关对话不再直连任何模型或系统。一、模型网关——把大模型当成一个可治理的资源池业务代码里散落着十几处直接调用大模型的代码是多数团队的真实状态。模型网关把这些调用全部收口对上提供统一的对话、分类、抽取、向量四类标准接口对下管理多个模型提供方。它解决的不是能不能调通是四个治理问题。路由与降级不同任务按难度和成本路由——意图分类用小模型复杂推理用旗舰模型多模态理解用视觉模型某个模型超时或限流时自动降级到备用模型业务无感知。成本控制按场景设token预算高频场景强制走小模型和语义缓存——客户问重复问题的比例很高相似问题的答案命中缓存直接返回不调模型。数据安全对话内容出门前做脱敏手机号、身份证、订单号替换成占位符模型返回后还原。观测每次调用的模型、耗时、token、成本、失败原因统一记录成本异常和效果回归都有据可查。二、工具网关——业务能力的统一注册中心工具网关是业务系统能力的唯一出口。ERP、CRM、工单、库存等系统的接口在这里注册成标准工具每个工具声明名称、描述、参数模式、鉴权要求、风险级别。对上Agent和业务编排通过统一协议调用工具不用知道底层是哪个系统的什么接口对下网关处理各系统千差万别的鉴权、协议、数据格式。工具网关的核心价值在三点。注册即用新业务系统接入只需在网关注册工具描述和适配器上层能力立刻可被Agent调用不用改编排代码。统一管控鉴权、限流、熔断、审计在网关层集中实现——前面讲业务系统对接时的治理措施天然有了落地点。能力编排复杂动作查客户最近订单并判断能否改地址由网关把多个原子工具组合成复合工具对外暴露Agent面对的是语义化能力而不是一堆零散接口。工具描述同时供两类消费者使用——人看的接口文档和模型看的function schema一份定义两处生成避免文档和实现脱节。三、双网关协作——编排层只表达业务意图有了两个网关业务编排层变得很薄它不关心用哪个模型、不关心订单数据存在哪个系统只表达理解这条消息、判断意图、需要什么数据、执行什么动作、如何回复。模型调用走模型网关数据获取和动作执行走工具网关编排层专注业务流程本身。这种架构还有一个关键收益是两侧独立演进模型升级换代更强模型发布、价格调整、国产化替换只改模型网关配置业务系统迁移ERP换厂商、CRM版本升级只改工具网关适配器——两侧任何变化都不波及业务编排。初期看起来多了一层但系统超过三个模型调用点和两个业务系统后省下的联调和改造成本远超网关建设成本。两种直连问题对照直连模型的问题模型网关对策直连业务系统的问题工具网关对策换模型改全部代码统一接口路由鉴权协议各自不同注册适配器单点故障无降级多提供方自动切换熔断限流各写一套集中管控成本失控预算语义缓存新系统接入成本高注册即用敏感数据裸发出门脱敏还原Agent面对零散接口原子工具复合编排双网关架构实现# 模型网关统一入口 class ModelGateway: def chat(self, scene, messages, **kw): if self.cache_hit(messages): # 语义缓存 return self.cache.get(messages) plan ROUTE_TABLE[scene] # 场景路由 for model in plan[fallback_chain]: # 降级链 try: safe_msgs self.mask(messages) # 脱敏出门 resp model.invoke(safe_msgs, timeoutplan[timeout]) self.budget.check(scene, resp.usage) result self.unmask(resp.text) self.metrics.record(model, resp) self.cache.set(messages, result) return result except ModelError: continue # 尝试下一个模型 raise AllModelsFailed() # 工具网关注册中心 class ToolGateway: def register(self, tool): self.tools[tool.name] tool def call(self, name, params, caller): tool self.tools[name] self.authz.check(caller, tool) # 统一鉴权 self.ratelimit.acquire(tool) with self.circuit(tool): # 熔断 raw tool.adapter.invoke(params) # 协议适配 result self.normalize(raw, tool.schema) self.audit.record(name, caller, params, result) return result def compose(self, composite_name): 原子工具组合成复合能力 def composed(params): order self.call(query_order, {order_no: params[order_no]}, calleragent) if order[status] shipped: return {editable: False, reason: 已发货} return {editable: True, order: order} return composed # 编排层只表达业务意图 def handle_customer(wxid, text): intent model_gateway.chat(intent_classify, [text]) if intent change_address: info tool_gateway.call(order_with_address_editable, parse_order_no(text), callerbot) reply model_gateway.chat(reply_compose, [text, json.dumps(info)]) eyun.send_text(wxid, reply)落地建议双网关不要等系统复杂了才补——第一个模型调用和第一个业务接口对接时就走网关哪怕网关里当时只有一个模型、一个工具后续扩展零迁移成本。模型网关优先做路由和语义缓存成本收益最直接工具网关优先做注册和鉴权管控能力随接入系统增多逐步补齐。微信侧的消息收发由Eyun这类个人微信API平台承接建议把它也注册为工具网关中的一组原子工具发消息、打标签、拉群与业务工具接受同一套治理接口参数和返回码以Eyun平台的开发文档为准。 
长河君 · 2026/9/23 9:44:29 · 阅读 1.2k 微信AI机器人开发进入新阶段：用双网关架构连接大模型与业务工具
早期微信AI机器人的架构很直接收到消息调大模型模型回答里要查订单就由后端调业务接口。业务复杂度上来后这种直连模式会全面失控——模型想换一家要改遍所有调用点、业务接口鉴权方式各不相同、模型调用成本没人管、敏感对话直接发给外部模型。新阶段的架构思路是引入两个网关模型网关统一管理所有大模型调用工具网关统一管理所有业务能力业务编排层只跟两个网关对话不再直连任何模型或系统。一、模型网关——把大模型当成一个可治理的资源池业务代码里散落着十几处直接调用大模型的代码是多数团队的真实状态。模型网关把这些调用全部收口对上提供统一的对话、分类、抽取、向量四类标准接口对下管理多个模型提供方。它解决的不是能不能调通是四个治理问题。路由与降级不同任务按难度和成本路由——意图分类用小模型复杂推理用旗舰模型多模态理解用视觉模型某个模型超时或限流时自动降级到备用模型业务无感知。成本控制按场景设token预算高频场景强制走小模型和语义缓存——客户问重复问题的比例很高相似问题的答案命中缓存直接返回不调模型。数据安全对话内容出门前做脱敏手机号、身份证、订单号替换成占位符模型返回后还原。观测每次调用的模型、耗时、token、成本、失败原因统一记录成本异常和效果回归都有据可查。二、工具网关——业务能力的统一注册中心工具网关是业务系统能力的唯一出口。ERP、CRM、工单、库存等系统的接口在这里注册成标准工具每个工具声明名称、描述、参数模式、鉴权要求、风险级别。对上Agent和业务编排通过统一协议调用工具不用知道底层是哪个系统的什么接口对下网关处理各系统千差万别的鉴权、协议、数据格式。工具网关的核心价值在三点。注册即用新业务系统接入只需在网关注册工具描述和适配器上层能力立刻可被Agent调用不用改编排代码。统一管控鉴权、限流、熔断、审计在网关层集中实现——前面讲业务系统对接时的治理措施天然有了落地点。能力编排复杂动作查客户最近订单并判断能否改地址由网关把多个原子工具组合成复合工具对外暴露Agent面对的是语义化能力而不是一堆零散接口。工具描述同时供两类消费者使用——人看的接口文档和模型看的function schema一份定义两处生成避免文档和实现脱节。三、双网关协作——编排层只表达业务意图有了两个网关业务编排层变得很薄它不关心用哪个模型、不关心订单数据存在哪个系统只表达理解这条消息、判断意图、需要什么数据、执行什么动作、如何回复。模型调用走模型网关数据获取和动作执行走工具网关编排层专注业务流程本身。这种架构还有一个关键收益是两侧独立演进模型升级换代更强模型发布、价格调整、国产化替换只改模型网关配置业务系统迁移ERP换厂商、CRM版本升级只改工具网关适配器——两侧任何变化都不波及业务编排。初期看起来多了一层但系统超过三个模型调用点和两个业务系统后省下的联调和改造成本远超网关建设成本。两种直连问题对照直连模型的问题模型网关对策直连业务系统的问题工具网关对策换模型改全部代码统一接口路由鉴权协议各自不同注册适配器单点故障无降级多提供方自动切换熔断限流各写一套集中管控成本失控预算语义缓存新系统接入成本高注册即用敏感数据裸发出门脱敏还原Agent面对零散接口原子工具复合编排双网关架构实现# 模型网关统一入口 class ModelGateway: def chat(self, scene, messages, **kw): if self.cache_hit(messages): # 语义缓存 return self.cache.get(messages) plan ROUTE_TABLE[scene] # 场景路由 for model in plan[fallback_chain]: # 降级链 try: safe_msgs self.mask(messages) # 脱敏出门 resp model.invoke(safe_msgs, timeoutplan[timeout]) self.budget.check(scene, resp.usage) result self.unmask(resp.text) self.metrics.record(model, resp) self.cache.set(messages, result) return result except ModelError: continue # 尝试下一个模型 raise AllModelsFailed() # 工具网关注册中心 class ToolGateway: def register(self, tool): self.tools[tool.name] tool def call(self, name, params, caller): tool self.tools[name] self.authz.check(caller, tool) # 统一鉴权 self.ratelimit.acquire(tool) with self.circuit(tool): # 熔断 raw tool.adapter.invoke(params) # 协议适配 result self.normalize(raw, tool.schema) self.audit.record(name, caller, params, result) return result def compose(self, composite_name): 原子工具组合成复合能力 def composed(params): order self.call(query_order, {order_no: params[order_no]}, calleragent) if order[status] shipped: return {editable: False, reason: 已发货} return {editable: True, order: order} return composed # 编排层只表达业务意图 def handle_customer(wxid, text): intent model_gateway.chat(intent_classify, [text]) if intent change_address: info tool_gateway.call(order_with_address_editable, parse_order_no(text), callerbot) reply model_gateway.chat(reply_compose, [text, json.dumps(info)]) eyun.send_text(wxid, reply)落地建议双网关不要等系统复杂了才补——第一个模型调用和第一个业务接口对接时就走网关哪怕网关里当时只有一个模型、一个工具后续扩展零迁移成本。模型网关优先做路由和语义缓存成本收益最直接工具网关优先做注册和鉴权管控能力随接入系统增多逐步补齐。微信侧的消息收发由Eyun这类个人微信API平台承接建议把它也注册为工具网关中的一组原子工具发消息、打标签、拉群与业务工具接受同一套治理接口参数和返回码以Eyun平台的开发文档为准。