2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！
过去几年，企业 AI 技术栈已演变成一个高度复杂，却又碎片化且难以管理的生态系统。如今，这一技术栈涵盖了向量数据库、监控系统、Pipeline 调优等各类组件，并通过编程 Agent、嵌入式 Agent，以及与企业系统对接的模型上下文协议（MCP）服务器相互连接。支撑这一切的模型组合也在不断变化，几乎每隔几周就会更新一次。不同团队按照各自的节奏引入技术栈中的不同组件，可能由此产生管理和治理缺口，进而影响安全性。
在这样一个割裂的环境中，很少有企业能够掌握足够全面的上下文信息，准确回答贯穿各个层面的基本问题：我们正在调用哪些模型？谁在调用这些模型？它们正在执行什么操作？相关成本又是多少？
面对这种情况，企业的本能反应往往是加强限制，但这并非可行的长期解决方案。限制员工使用 AI 的能力，只会促使他们转向未经批准的 AI 工具，从而进一步放大风险。
这一缺口的根源并非工具问题，而是缺少一个关键层。现代 AI 技术栈需要一个控制节点，位于每个 AI 客户端与其所访问的企业系统之间。Cortex AI Gateway（已进入公开预览阶段）通过充当这一集中式控制平面，为现代多元化基础设施提供所需的统一可见性、治理能力和监督机制。在我们看来，现代企业的 AI 基础设施技术栈必须具备以下六大要素：
统一且受治理的模型推理
动态模型路由
MCP 与工具治理
集中式可观测性
安全策略与护栏
成本治理与控制
目前，Cortex AI Gateway 已进入公开预览阶段。平台团队可以通过统一入口授予模型及 MCP 服务器的访问权限，对支出进行归因和控制，并了解 AI 代表用户执行了哪些操作。应用团队则可以通过单一端点进行开发。接下来，我们将逐一介绍它如何覆盖技术栈的各个层面。
Cortex AI Gateway 是 Snowflake 面向企业 AI 基础设施打造的集中式控制平面。它通过单一端点提供受治理的模型推理、动态模型路由、MCP 工具治理、可观测性、安全护栏和成本控制能力，让平台团队能够统一查看组织内所有 AI 客户端和 Agent 的运行情况。
统一且受治理的模型推理：让 Agent 通过单一端点访问模型
随着 AI 技术栈不断扩展，最先暴露的问题之一就是模型访问路径过多：一名工程师将编程 Agent 配置为连接某家模型提供商，平台团队又将应用程序接入另一家，还有其他人通过脚本调用第三家。每条访问路径都有独立的凭证、日志和账单。
Cortex AI Gateway 将这些访问路径整合为单一端点。它为 OpenAI、Grok、GLM、Gemini、Llama、Mistral 和 DeepSeek 模型实现了 Chat Completions API，并为 Claude 实现了 Messages API。这两种协议已成为模型服务领域的主流标准。流式传输、工具调用、结构化输出、Prompt 缓存、图像输入和推理等功能，都能以与原生接口相同的方式运行。因此，要让现有客户端接入 Cortex AI Gateway，只需配置一个新的 base URL 和一个 token。对 OpenAI Responses API 的支持也即将推出。以下示例展示了使用 Cortex AI Gateway 配置 OpenCode 所需的全部设置：
export PAT="<pat>"export BASE_URL="<base_url>"export OPENCODE_CONFIG_CONTENT='{ "$schema": "https://opencode.ai/config.json", "model": "snowflake-cortex/openai-gpt-5.4", "small_model": "snowflake-cortex/openai-gpt-5.4", "provider": { "snowflake-cortex": { "options": { "baseURL": "${BASE_URL}", "account": "<ACCOUNT>.snowflakecomputing.com", "apiKey": "<PAT>", "headers": { "snow-agent-name": "opencode" } } } }}'访问控制沿用 Snowflake 现有的基于角色的访问控制（RBAC）框架。管理员可以配置通过 Gateway 提供的模型，确保用户只能访问组织批准的模型。
为了进一步简化编程 Agent 与 Cortex AI Gateway 的集成，Snowflake CLI 将能够自动完成流量经由 Gateway 路由的相关配置。只需一条命令，即可从当前有效的 Snowflake 连接中读取凭证，将其注入编程 Agent 的配置文件，并启动 Agent，使其流量通过 Cortex AI Gateway 进行路由。例如，现在使用 Snowflake CLI 启动 OpenCode，只需运行 snow ai opencode 即可。
Cortex AI Gateway 中的动态模型路由：为每项任务选择合适的模型
大多数团队习惯于使用单一前沿模型处理所有任务。这是一个合理的起点，但随着应用规模扩大，成本也会变得高昂。Agent 执行的很多步骤实际上只是文件编辑、格式调整和信息查询，成本更低的模型同样能够以相当的质量和准确性完成这些任务。
即将通过 Cortex AI Gateway 开放私有预览的动态模型路由功能，能够在 Agent 执行任务的每个步骤中，从可用模型里选择能够可靠完成当前任务、且成本最低的模型。Snowflake 研究团队对这一功能进行了微调，使低复杂度和重复性任务能够交由高效模型处理，而需要深度推理的任务则交由前沿模型完成。在一项内部评估中，与仅使用前沿模型的方案相比，该功能在完成 dbt Pipeline 工作负载时，在质量相当的情况下，token 效率最高提升至 3 倍；在另一项独立的编程测试中，工程团队在保持 Pull Request 吞吐量不变的同时，将 token 使用量减少了约 25%。这些结果有望转化为企业实际的成本节省。
动态路由与手动选择模型遵循相同的治理规则。系统只会使用经过批准的模型，遵守现有的数据驻留设置，并记录每一次路由决策，使合规团队能够查看具体由哪个模型处理了哪项请求。由于路由逻辑位于 Cortex AI Gateway，而非各个应用程序内部，因此 Snowflake 可以随着模型价格和性能的变化不断调整路由决策，无须修改 Agent 配置。
开源模型在这里同样发挥着重要作用。在使用 Snowflake CoCo 作为 Agent 测试框架的 ADE-bench 评测中，DeepSeek-V4-Flash 取得了 74.4% 的成绩，超过了我们测试的领先专有模型。GLM-5.3 也即将进入私有预览阶段，而其前代模型 GLM-5.2 在 ADE-bench 评测中取得了 66% 的成绩，同时也是该基准测试中 token 消耗量最低的模型，这正是高吞吐量工作负载所需要的特性。Snowflake 在其安全边界内提供这些模型的服务，因此推理可以在受治理的数据附近执行，并受到现有 RBAC 和审计追踪机制的统一管理。
MCP 与工具治理：控制 Agent 能够执行的操作
一旦 Agent 能够调用工具，它就成为了企业系统中的一个执行主体，而 MCP 让这种能力的实现变得异常简单。员工每安装一个未经管理的 MCP 服务器，就相当于为生产系统增加了一条新的访问路径，而使用这条路径的软件会在运行时自行决定如何利用其获得的访问权限。这是一种影子 IT，只不过这些未经授权的软件还能够读取生产数据库，并修改企业 SaaS 系统中的记录。
API Gateway 需要判断的是：某个客户端是否有权访问指定端点。工具网关则必须回答另一个问题：此时此刻，这个 Agent 是否有权代表该用户执行这次工具调用？
在 Snowflake 收购 Natoma 之后，Cortex AI Gateway 中的 Tools 功能为这一问题提供了解决方案。该功能目前处于私有预览阶段，内置了一个经过筛选的 MCP 服务器目录，包含超过 100 个 MCP 服务器，并已为用户处理好各服务器的 OAuth 授权，有助于减少 MCP 服务器无序扩张的问题。
管理员可以选择启用特定工具、所有当前已发布的工具，或所有当前及未来发布的工具。未启用的工具对客户端不可见，也无法被调用。因此，被禁止的能力通常根本不会向客户端暴露，而非等到实际调用时才返回失败。系统还可以记录工具调用日志，将同一个 Prompt 触发的完整 Agent 执行过程串联为连续的操作序列。工具调用还会将 Span 写入与模型推理相同的 Trace 表，从而使单条 Trace 同时覆盖推理过程和实际操作。
这套审计追踪机制能够帮助防范针对工具层的特定攻击。工具投毒（Tool Poisoning）、工具遮蔽（Tool Shadowing）以及 Rug Pull 攻击，都可能在终端用户毫无察觉的情况下发生。例如，在 Rug Pull 攻击中，已经获得批准的服务器可能悄悄将工具定义更新为恶意内容，而客户端会自动获取这些变更。此类攻击在设计上很难被终端用户发现，但对于记录每项工具定义和每次调用的系统而言，它们并非不可见。
可观测性：在统一位置查看 Agent 的运行轨迹
当企业被问及有哪些 Agent 正在访问其系统时，大多数情况下，能够给出的真实答案往往来自一份已经过时的 Agent 清单表格。我们开展的一项调查也印证了这一现象：约三分之一的受访客户使用自行开发的内部仪表板来实现 Agent 可观测性。
云安全联盟（Cloud Security Alliance）的一项调查发现，在过去一年中，82% 的组织至少发现过一个此前不为安全或 IT 团队所知的 AI Agent 或自主工作流。此外，根据《2026 年数据泄露成本报告》，影子 AI 使用率较高的组织平均数据泄露成本达到 539 万美元，而在发生数据泄露的组织中，有 43% 受到影子 AI 事件的影响。
常见的应对方式是为每个客户端添加监测埋点，但这一方法存在一个根本性问题：企业无法对那些自己尚未发现的客户端进行埋点。
Cortex AI Gateway 采用了另一条路径，将可观测性直接构建在模型服务层。无论是运行在开发者本地笔记本电脑上的 Agent，还是部署在远程 Kubernetes 集群中的 Agent，只要其模型调用或 MCP 工具调用经过 Gateway，系统就会在 Snowflake 中将其记录为 OpenTelemetry Span。这样一来，无须修改 Agent 代码，企业就能够完整查看跨第三方运行时的执行情况。
这些 Span 会按照 OpenTelemetry 生成式 AI 语义约定写入 AGENT_TRACE_TABLE。每条记录都包含请求调用的模型、输入和输出 token 数量、缓存读取和写入情况、执行时长、状态码、MCP 服务器与工具信息，以及发起调用的客户端，甚至包括客户端版本和会话信息。
只有管理员启用 Payload Capture（请求与响应内容捕获）功能后，系统才会记录 Prompt、响应，以及工具调用的输入和输出内容。启用后，这些文本数据仍存储在 Snowflake 内部，并受到组织现有访问控制机制的保护。由于遥测数据直接写入客户自有的事件表，例如 AGENT_TRACE_TABLE，因此这些数据始终严格处于客户的 Snowflake 安全边界之内。
Cortex AI Gateway 还可以通过自身端点接收客户端侧的 OTLP Trace。通过同时查看服务端和客户端的 Trace，企业能够获得深入分析 Agent 行为所需的可观测能力。
借助 CoCo，用户只需输入一个 Prompt，就能调查 AGENT_TRACE_TABLE 中的遥测数据。下面的示例展示了如何发现缓存命中率下降的问题，并找出降低模型成本的机会。
安全与护栏：保护最关键的系统接入面
Agentic AI 以一种全新的方式扩大了攻击面，而最直接的证据就来自过去几个月引发广泛关注的安全事件。
从这些事件中很容易得出一个结论：安全护栏是安全 AI 技术栈不可或缺的组成部分。护栏应该部署在 Agent 必须经过的边界，而非 Agent 内部，因为 Agent 自身的判断能力恰恰可能成为失效的环节。
Snowflake Cortex AI Guardrails 已经能够为 CoCo、Snowflake CoWork 和 Cortex Agents 提供运行时防护，抵御 Prompt 注入和越狱攻击。它能够扫描工具输出，识别试图覆盖系统指令的间接 Prompt 注入；检测绕过模型安全边界的行为；并实时发现此前未出现过的攻击模式。
Cortex AI Gateway 即将把这套基础设施引入 Gateway 流量。届时，防护范围将从 Snowflake 自有的 AI 产品扩展至所有通过 Gateway 路由的第三方 Agent 和 Agent 运行框架，从而最大限度地减少暴露的攻击面。
成本治理：让每一笔 AI 支出都物有所值
2026 年，AI 支出让许多企业的预算承受了巨大压力，但真正的问题在于成本预测不准确，而非单纯的过度支出。与此同时，还出现了一种被称为 tokenmaxxing 的现象，即将 token 使用量视为生产力的衡量指标。
一些公司曾发布内部排行榜，但最终不得不将其关闭，因为用户为了在榜单上获得更高排名，会刻意增加 AI 支出。人们很快意识到，更高的 token 使用量通常并不意味着更高的投资回报率（ROI）。
为应对这一问题，Snowflake 将现有的成本控制能力扩展到了 Cortex AI Gateway。
Budgets（预算）提供了成熟的成本治理控制机制，现在也适用于所有通过 Cortex AI Gateway 路由的 AI 流量。具体能够实现多精细的控制，主要取决于管理员的配置。
预算可以设置在 Gateway 层级，以实现更细粒度的控制；也可以通过资源标签和用户标签，按照所需维度灵活划分和管理成本。无论是按部门、角色、成本中心、用户 ID、Agent 还是应用程序进行划分，Cortex AI Gateway 都将支持上述所有维度的成本可见性与控制。
用户级配额允许管理员为每位用户设置月度限额，以及可选的每日限额，并在数分钟内执行超额阻断。
Gateway 流量的使用情况会记录在 AI_GATEWAY_USAGE_HISTORY 中，其中包含按模型细分的 Credit 消耗量，以及可直接关联到 AGENT_TRACE_TABLE 的请求 ID。借助这些数据，企业可以精细追踪究竟是哪些 Agent 对话、工作流、任务、模型请求和工具调用导致了成本失控。
CoCo 则提供了一种便捷方式，帮助用户深入分析 Trace 数据，更好地了解 AI 成本构成。
如何开始使用 Cortex AI Gateway
Snowflake 致力于帮助企业安全、经济地使用 AI，而 Cortex AI Gateway 正是实现这一目标的起点。你可以亲自体验：将一个客户端接入 Cortex AI Gateway，查看其 Trace 数据；开始实施细粒度的成本控制；或者深入分析模型使用趋势。
Cortex AI Gateway 目前已在 AWS 商业区域进入公开预览阶段。请参阅我们的 Cortex AI Gateway 文档，进一步了解其特性、功能及入门方法。