艾体宝 × TrueFoundry 技术解读：企业 AI 为什么需要三层 Gateway 治理？

一、企业 AI 的难点，正在从“能不能调用”转向“能不能管理”

过去一段时间，很多企业 AI 项目的起点都很相似：开发人员申请一个模型 API Key，写几十行代码，把内部知识库接入大模型，很快就能做出一个问答机器人。

到了这个阶段，团队最关心的是模型回答得准不准、Prompt 怎么写、RAG 能不能找到正确资料。但当应用真的进入生产，问题会迅速发生变化：

• 客服系统使用 Azure OpenAI，研发助手使用 Anthropic，海外业务又接入了其他模型，SDK、地址和密钥各自维护；
• 主模型发生故障或触发 429 限流时，应用需要修改配置、重新发布，甚至由运维人员人工切换；
• 新模型效果看起来更好，却不敢直接替换旧模型，因为真实流量下的质量、延迟和成本还没有得到验证；
• Agent 开始访问数据库、工单系统和企业内部 API，模型的一次错误判断可能变成一次真实操作；
• 管理者无法回答“哪个团队调用了什么模型、花了多少钱、哪个工具被谁调用、某次异常操作是如何发生的”。

这时企业缺少的已经不是又一个模型，而是一个能够统一管理模型、工具和 Agent 的生产入口。

这也是 Gateway 在企业 AI 架构中越来越重要的原因。作为 TrueFoundry 的合作伙伴，艾体宝也在持续研究企业从单模型调用走向多模型、多工具和多 Agent 生产治理过程中遇到的问题，并尝试将产品能力转化为客户更容易理解和验证的技术方案。

二、第一层：AI/LLM Gateway 管理 Agent 的“大脑”

假设一家制造企业正在建设智能售后助手。最初，应用代码可能直接调用某个模型：

from openai import OpenAI

client = OpenAI(
    api_key="provider-api-key",
    base_url="https://provider.example.com/v1",
)

response = client.chat.completions.create(
    model="model-a",
    messages=[{"role": "user", "content": "设备出现异常振动，应该如何排查？"}],
)

这种方式很适合验证想法，但应用已经和模型供应商、模型名称、访问地址及凭据绑定在一起。后端模型一旦改变，修改就会扩散到每个调用它的业务系统。

AI/LLM Gateway 位于应用和模型供应商之间，​为应用提供统一入口​。以 TrueFoundry AI Gateway 为例，应用可以使用统一接口访问不同模型，并通过 Virtual Model 对后端真实模型进行抽象。

应用看到的始终是一个稳定的逻辑模型名：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TRUEFOUNDRY_API_KEY"],
    base_url=os.environ["TRUEFOUNDRY_GATEWAY_URL"],
)

response = client.chat.completions.create(
    model="support/production-chat",
    messages=[{"role": "user", "content": "设备出现异常振动，应该如何排查？"}],
)

support/production-chat 并不是某一家供应商的真实模型，而是一个 Virtual Model。Gateway 可以在它的后端配置一个或多个目标模型，并应用不同路由策略：

• ​优先级路由​：优先调用主模型，在符合配置的失败条件时切换到备用目标；
• ​权重路由​：例如让旧模型承接 90% 流量，新模型承接 10%，用于灰度验证；
• ​延迟路由​：根据目标的延迟情况选择后端；
• ​复杂度路由​：根据请求复杂度将任务分配给不同层级的模型。

这样做的价值不是简单地“少写一个模型地址”，而是把原本散落在每个应用中的重试、Fallback、负载分配和模型切换逻辑集中到统一策略层。

模型接入统一之后，企业还可以在同一入口上继续实施：

• 按用户、团队、应用或模型设置访问权限；
• 配置限流和预算，避免流量突增或费用失控；
• 查看请求量、失败率、延迟、Token 和成本；
• 对输入和输出应用 PII、Prompt Injection、内容审核等 Guardrail；
• 根据日志策略决定是否记录请求正文，并对日志副本进行脱敏。

因此，AI/LLM Gateway 管理的是“应用和 Agent 可以使用哪些大脑，以及如何稳定、安全、经济地使用它们”。

三、第二层：MCP Gateway 管理 Agent 的“工具和手”

如果 AI 应用只是生成文字，风险通常停留在回答层面。但 Agent 的目标是完成任务，它需要调用外部工具，例如：

• 查询 CRM 中的客户信息；
• 在工单系统中创建或更新任务；
• 查询库存和设备运行数据；
• 调用数据库、GitHub、Jira 或企业内部 API；
• 执行经过授权的自动化流程。

MCP（Model Context Protocol）为模型和工具之间提供了标准化连接方式，但“可以连接”并不等于“适合直接进入企业生产”。

当 MCP Server 和 Tool 数量增加后，企业会面临新的问题：工具由谁注册和发布？哪些 Agent 可以调用？用户身份如何传递？访问凭据存放在哪里？危险参数如何拦截？一次工具调用失败后，如何追踪完整过程？

MCP Gateway 负责的正是工具接入与调用治理。它与 AI/LLM Gateway 的管理对象不同：

以智能售后助手为例，模型判断需要查询设备保修状态，但真正读取数据的是 MCP 工具。MCP Gateway 可以在调用链中承担工具注册、身份认证、权限控制和审计入口等职责；Guardrail 还可以应用在工具执行前后：

• 执行前检查参数，拦截越权请求、危险 SQL 或不允许的操作；
• 执行后检查返回结果，避免密钥、个人信息或敏感数据继续传给模型。

这一步很关键。因为进入 Agent 时代后，安全治理不能只检查“模型说了什么”，还要检查“Agent 准备做什么，以及工具实际返回了什么”。

四、第三层：Agent Gateway 管理企业中的“数字员工”

当企业只有一个实验性 Agent 时，开发团队通常可以直接维护它。但随着客服 Agent、研发 Agent、数据分析 Agent 和运维 Agent 陆续上线，新的管理问题会出现：

• 企业中到底运行着多少个 Agent？
• 每个 Agent 的身份、负责人和权限是什么？
• 哪些用户或业务系统可以调用某个 Agent？
• 一次会话经历了哪些步骤、调用了哪些模型和工具？
• 出现错误结果或异常操作时，能否还原完整运行轨迹？

Agent Gateway 面向的是 Agent 的身份、统一调用入口、会话和运行治理。它不负责替企业设计 Agent 的业务决策逻辑，也不等于一个新的 Agent 开发框架。

可以用一句话区分三者：

• AI/LLM Gateway 管理 Agent 使用哪个“大脑”；
• MCP Gateway 管理 Agent 可以使用哪些“工具和手”；
• Agent Gateway 管理企业中有哪些“数字员工”，谁能调用，以及它们执行过什么。

五、三类 Gateway 不是三个孤立代理，而是一条完整治理链

在一个典型 Agent 应用中，三类 Gateway 可以形成下面的关系：

暂时无法在飞书文档外展示此内容

以一次“查询设备故障并创建工单”的请求为例，完整链路可能是：

1. 用户通过统一入口调用售后 Agent，系统识别调用者身份并创建会话；
2. Agent 通过 AI/LLM Gateway 调用 Virtual Model，Gateway 根据策略选择真实模型；
3. 主模型发生限流时，Gateway 根据已配置条件执行重试或 Fallback；
4. 模型判断需要查询设备档案，Agent 通过 MCP Gateway 调用授权工具；
5. MCP Gateway 在调用前检查权限和参数，在调用后检查返回结果；
6. Agent 根据结果生成建议，并在获得相应授权后创建工单；
7. 模型请求、工具调用、策略命中、费用和 Agent 运行轨迹被记录到相应观测与审计链路中。

在这条链路里，任何一个 Gateway 都不能完全代替另外两个。模型路由解决不了工具越权，工具权限也无法替代 Agent 会话和行为追踪。

六、为什么不直接在应用代码里自己实现？

从技术上说，重试、Fallback、限流、日志和权限都可以自己写。很多团队的第一版系统也确实是这样实现的。

问题在于，当每个应用都独立实现一遍，企业会得到多套标准不同的治理逻辑：A 应用只对 429 重试，B 应用对所有错误切换；有的团队记录完整 Prompt，有的团队完全没有日志；模型费用无法统一归属，工具权限也散落在不同服务中。

Gateway 的价值不是让这些代码“从无到有”，而是将重复的横向能力从业务应用中抽离出来，形成统一策略、统一身份、统一观测和统一审计入口。

这和 API Gateway 在微服务架构中的作用相似：业务服务当然可以自行实现认证、限流和日志，但当服务数量增加后，统一入口能够显著降低重复建设和治理差异。

七、艾体宝的建议：不要一开始就堆叠全部 Gateway 能力

三层治理是一条演进路径，不应该被理解为每个项目都必须一次性建设完整平台。

如果客户的核心问题只是“模型回答不准确”，Gateway 也不会自动解决数据质量、RAG 召回、Prompt 设计和模型评测问题。它解决的是接入、运行和治理问题，而不是替代业务算法与效果优化。

同样，产品支持某项能力不代表项目已经达到既定效果。容灾切换、灰度发布、Guardrail 和成本治理仍然需要结合客户模型、网络、数据、版本和验收指标进行 PoC。

结语：Agent 能力越强，统一治理越重要

大模型应用的第一阶段关注“能不能回答”，Agent 阶段开始关注“能不能完成任务”。能力越强，系统需要管理的对象就越多：从模型扩展到工具，再扩展到 Agent 身份、会话和行为。

TrueFoundry 所体现的思路，是通过统一平台分别治理模型调用、MCP 工具调用和 Agent 运行，让企业可以在保留模型与工具选择空间的同时，建立稳定入口、访问控制、成本归属、可观测性和安全策略。

对于正在推进企业 AI 落地的团队，真正值得讨论的问题是：当模型、工具和 Agent 不断增加时，我们是否仍然知道谁在调用什么、为什么这样路由、花了多少钱，以及发生问题后如何还原？

如果企业正在面临多模型接入混乱、供应商故障切换、模型灰度升级、Token 成本失控、MCP 工具安全或多 Agent 治理等问题，可以先从现有架构和真实业务场景出发，明确需要解决的问题，再通过 Demo 或 PoC 验证相应能力，而不是仅根据产品功能清单完成选型。

我们是​艾体宝科技​，如需进一步了解 TrueFoundry 产品能力、演示环境或场景化验证方案，欢迎与我们联系。