企业官网建设流程全解析

早期微信AI机器人的架构很直接：收到消息调大模型，模型回答里要查订单就由后端调业务接口。业务复杂度上来后这种直连模式会全面失控——模型想换一家要改遍所有调用点、业务接口鉴权方式各不相同、模型调用成本没人管、敏感对话直接发给外部模型。新阶段的架构思路是引入两个网关：模型网关统一管理所有大模型调用，工具网关统一管理所有业务能力，业务编排层只跟两个网关对话，不再直连任何模型或系统。

一、模型网关——把大模型当成一个可治理的资源池

业务代码里散落着十几处直接调用大模型的代码，是多数团队的真实状态。模型网关把这些调用全部收口，对上提供统一的对话、分类、抽取、向量四类标准接口，对下管理多个模型提供方。它解决的不是"能不能调通"，是四个治理问题。

路由与降级：不同任务按难度和成本路由——意图分类用小模型，复杂推理用旗舰模型，多模态理解用视觉模型；某个模型超时或限流时自动降级到备用模型，业务无感知。成本控制：按场景设token预算，高频场景强制走小模型和语义缓存——客户问重复问题的比例很高，相似问题的答案命中缓存直接返回，不调模型。数据安全：对话内容出门前做脱敏，手机号、身份证、订单号替换成占位符，模型返回后还原。观测：每次调用的模型、耗时、token、成本、失败原因统一记录，成本异常和效果回归都有据可查。

二、工具网关——业务能力的统一注册中心

工具网关是业务系统能力的唯一出口。ERP、CRM、工单、库存等系统的接口在这里注册成标准工具，每个工具声明名称、描述、参数模式、鉴权要求、风险级别。对上，Agent和业务编排通过统一协议调用工具，不用知道底层是哪个系统的什么接口；对下，网关处理各系统千差万别的鉴权、协议、数据格式。

工具网关的核心价值在三点。注册即用：新业务系统接入只需在网关注册工具描述和适配器，上层能力立刻可被Agent调用，不用改编排代码。统一管控：鉴权、限流、熔断、审计在网关层集中实现——前面讲业务系统对接时的治理措施天然有了落地点。能力编排：复杂动作（"查客户最近订单并判断能否改地址"）由网关把多个原子工具组合成复合工具对外暴露，Agent面对的是语义化能力而不是一堆零散接口。工具描述同时供两类消费者使用——人看的接口文档和模型看的function schema，一份定义两处生成，避免文档和实现脱节。

三、双网关协作——编排层只表达业务意图

有了两个网关，业务编排层变得很薄：它不关心用哪个模型、不关心订单数据存在哪个系统，只表达"理解这条消息、判断意图、需要什么数据、执行什么动作、如何回复"。模型调用走模型网关，数据获取和动作执行走工具网关，编排层专注业务流程本身。

这种架构还有一个关键收益是两侧独立演进：模型升级换代（更强模型发布、价格调整、国产化替换）只改模型网关配置；业务系统迁移（ERP换厂商、CRM版本升级）只改工具网关适配器——两侧任何变化都不波及业务编排。初期看起来多了一层，但系统超过三个模型调用点和两个业务系统后，省下的联调和改造成本远超网关建设成本。

两种直连问题对照

双网关架构实现

# 模型网关：统一入口 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, timeout=plan["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"]}, caller="agent") 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), caller="bot") reply = model_gateway.chat("reply_compose", [text, json.dumps(info)]) eyun.send_text(wxid, reply)

落地建议

双网关不要等系统复杂了才补——第一个模型调用和第一个业务接口对接时就走网关，哪怕网关里当时只有一个模型、一个工具，后续扩展零迁移成本。模型网关优先做路由和语义缓存，成本收益最直接；工具网关优先做注册和鉴权，管控能力随接入系统增多逐步补齐。微信侧的消息收发由Eyun这类个人微信API平台承接，建议把它也注册为工具网关中的一组原子工具（发消息、打标签、拉群），与业务工具接受同一套治理，接口参数和返回码以Eyun平台的开发文档为准。