作者：望宸
2024 年以来，AI 基础设施的快速发展过程中，PaaS 层的 AI 网关是变化最明显的基建之一。从传统网关的静态规则和简单路由开始，网关的作用被不断拉伸。用户通过使用网关来实现多模型的流量调度、智能路由、Agent 和 MCP 服务管理、AI 治理等，试图让系统更灵活、更可控、更可用。
国庆期间 AI 界发布/升级了一些产品，我们在此做一个简报，从中窥探下对 AI 网关演进新方向的启示。
01 自由度更高的低门槛后训练工具
OpenAI 前 CTO Mira Murati 创建的 Thinking Machines Lab 发布了其第一款产品「Tinker」，旨在简化大规模语言模型的微调过程。用户可以通过 Python 编写训练循环，Tinker 则负责分布式训练的基础设施管理。目前支持阿里云的 Qwen 系列模型和 Meta 的 Llama 系列，主要面向研究人员、开发者和 AI 爱好者，特别适合需要定制化模型的用户。
相比市面上，例如各云厂商已经提供的低门槛（白屏化）的模型微调工具/平台，「Tinker」的主要优势是微调的自由度更高，它为编写实验和训练流水线提供了底层的、清晰的 API 接口，通过标准的 Python 代码，就可以对损失函数、训练循环和数据工作流等进行精细化控制。
虽然基础模型越来越智能，但「Tinker」是希望以更开放的方式，让更多的人基于私有数据和算法，自行构建专业知识和领域的模型。
这一趋势会进一步强化 AI 网关在多模型的流量调度、智能路由场景下的需求程度。当前 AI 网关大多采用简单的、与内容无关的路由策略（如基于 URL 路径），无法理解 AI 请求的内在语义。这种路由方式导致所有请求，无论简单或复杂，都被发往同一个默认模型，造成了模型错配、甚至资源的浪费。通过智能路由的功能，将符合语义设计要求的路由到后训练过的模型，其他请求则路由到基础大模型。Higress 正在开发相关能力，如果您有相关技术储备，欢迎参与我们的挑战赛。
02 被再一次激活的工具生态
在《AI 原生应用架构白皮书》中，我们分享过：工具的意义在于，实现了大模型向物理世界的延伸，把物理世界的读写权以受控的方式暴露给模型，让其在安全边界内发挥效能。虽然世界范围内已有成千上万个 MCP Server，但是调用其的 Agent 数量有限，使用 Agent 调用 MCP Server 的用户更是寥寥。这其中的原因是复杂的，既有 Agent 的集成和输出体验问题，也有 MCP Server 良莠不齐的准入问题，更有用户侧的采用心理成本和收益问题等等。
OpenAI 推出的 App Inside ChatGPT 开始尝试解决这些棘手的问题，笔者认为这是一个很好的示范作用，全球活跃度最高的 Agent 通过工具生态带来更好的 AI 体验，可以极大的激活开发者生态。
- 对其他 Agent 而言，最大的收益是标准路径的出现。过去每个团队都在尝试自己解决工具集成的问题，写各类适配器、定义各自的接口。ChatGPT 的工具生态如果稳定下来，就相当于给全行业提供了样板间：工具应该如何暴露能力、如何描述参数、如何被模型检索、如何在对话中被自然引用。Agent 开发者可以直接借鉴这些范式，并专注在自己的业务场景上。
- 对 MCP Server 而言，当越来越多用户习惯在 ChatGPT 内部直接调用 Figma、Canva、Zillow 这些 APP。这种用户认知的改变，会反向刺激更多开发者去完善自己的 MCP 工具，让工具更快响应、参数更直观、结果更可解释，而不仅仅是符合规范、快速上线。
虽然 App Inside ChatGPT 采用的是 MCP 标准，但是提供的开发者指南是有本质上的差异的，例如支持支持双向的、实时的通信方式。并提供了专门的设计指南，其强调的是：应用程序（APP）存在于 ChatGPT 内部，它们扩展了用户的功能，同时又不会打断对话流程，并通过轻量级卡片、轮播、全屏视图和其他显示模式无缝集成到 ChatGPT 界面，同时保持其清晰度、可信度和语音功能。
这些差异性正是用来尝试解决上文提到的三大问题。详细的开发指南差异性和设计指南，可以查看：
https://developers.openai.com/apps-sdk
以下我们直接从用户的交互体验上对比两者的不同。
交互体验 |
ChatGPT 调用 APP |
MCP 模式下的 APP 调用 |
一体化 /连贯感 |
用户在会话里提一句话，就可以直接触发 APP，用户不一定会察觉 APP 被调用的过程。 |
模型在对话中出现“正在调用 /外部工具处理中 /等待响应”等提示，用户能感知工具是模型思考链的一环。 |
工具体验内置 |
调用的 APP，其操控在ChatGPT 中进行。 |
调用的 APP，其操控需跳出ChatGPT，到 APP 中进行。 |
实时性 |
支持 Real Time 的通信方式。 |
单向通信为主。 |
可见性 /工具探索 |
有 APP 的展示目录、推荐、图标、描述等，用户能浏览 /启用 /停用工具。工具可以被设计为像插件一样在 ChatGPT 中被安装。 |
工具通常是模型内部的一部分，用户不一定有清晰的工具目录界面，而是由模型在背后决定是否调用。 |
视觉一致性 |
统一设计工具的 UI /对话界面 /交互风格，用户体验更一致。 |
工具在不同模型 /Agent 调用下可能表现不一样，体验一致性更难保证。 |
错误 /Fallback |
可以在工具调用失败时做平滑降级 /捕获 /重试 /回退，对话可以继续进行。用户体验相对稳定。 |
如果模型 /工具调用失败，模型本身要判断如何 fallback，可能导致对话中断 /不连贯 /出错提示明显。 |
操作权限 /用户授权 |
可以统一处理用户授权 /数据访问 /隐私边界，用户对 APP 的权限控制可能集中在 ChatGPT 平台 UI 内。 |
授权 /数据访问控制可能要由模型 /工具设计者在调用层面自行控制；用户可能需要多次授权或手动干预。 |
总的来看，ChatGPT Apps SDK 的调用机制倾向于隐藏调用边界、减少显性工具感，目标是让工具能力像 ChatGPT 自有的能力。而 MCP 模式，由于其中立性，无法为 Agent 定义一种设计指南，并基于此定义开发细致的开发指南，因此选择保留更多模型/Agent 与工具之间的可见协作感，工具调用可能显得更露出。
这一趋势会激活 AI 网关在 MCP 场景下沉淀的能力，例如 MCP Server 代理、工具精选、安全认证，以及统一观测、限流等治理能力。
03 Agent 开发者套件
大家是否还记得今年 4 月 Langchain CEO 驳斥 OpenAI 出品的 Agent 构建指南，认为这本指南缺乏技术细节，难以指导开发者确定 Agent 的具体功能和实现方式。他认为一个可靠的编排层对开发者是至关重要的，不仅能提升获取上下文的的准确度，对数据的持久化和容错都有直接的帮助。
这不 6 个月后，OpenAI 推出了自己的 Agent 开发者套件（Agent Kit），包含 Agent Build、Connector Registry、Chat Kit。
Agent Build：
我们曾在《AI 原生应用架构白皮书》中分享过两种主流的 Agent 构建范式，低代码和高代码。Agent Build 属于低代码，用于创建多代理工作流的可视化画布，并进行版本控制，让工程师和领域专家能够在同一个界面上协同工作，是比较友好的展示模式。和其他框架一样，也同样提供了模型、工具、安全护栏、知识库、记忆、评估等能力。此外，提供了 SDK 的高代码编排框架，相比低代码是更好的应用构建模式。
Connector Registry 为管理 OpenAI 产品间数据和工具的连接方式提供了便利，这个有点像 Himarket 对 API、MCP、Agent 提供的管理平台，只是前者是用来对连接器进行集中的后台管理。Chat Kit 则是将代理工作流程引入产品 UI，并将可嵌入的聊天连接到代理后端。
总的来看，无论您是使用 Agent Build 来构建一个基于 OpenAI API 的原生 Agent，还是将 Agent 通过 Chat Kit 引入存量应用，这些工具都进一步降低了开发成本，缩短交付周期。当越来越的企业和开发者将 AI 应用部署到云计算厂商的基础设施上，都需要进行企业级的安全、审计、权限管理、流量控制、成本管控等私有能力建设，这将提升企业对云上计算、存储、网关的需求程度。
04 视频生成工具的意义
看上去似乎是一个和 AGI 关系不大的视频生成工具，但对社会与技术的协同进化将具有特别的推动作用。可能大多数从业者有类似的体感，由于 AI 技术的发展远超公众对 AI 的认知迭代，而公众需要时间来理解、适应和消化，这导致 AI 的真实能力远未被大众所理解和利用。
相比文本，Sora 具有更强的情感共鸣和影响力，也更容易激发公众的创造热情。通过 Sora，自然语言不再仅仅是触发逻辑操作，而是生成可感知的世界，这能加速公众对 AI 的理解和运用能力。
另一方面，如果说 LLM 让机器理解语言，Sora 则是让机器理解世界的动态结构，两者结合才可能让 AI 在物理与社会可视化的环境中演化。
这一趋势会加速多模态场景对 AI 网关的诉求，包括通讯协议的兼容（例如对 WebSocket 的支持）、内容安全的审核、请求和响应内容的保存用于可观测建设等。
