AI-Wiki

定义与身份

Cloudflare AI Gateway在文中不是一种MCP协议实现，也不是给模型新增工具能力的组件，而是一个放在大模型API调用链路前面的代理与日志平台。作者使用它的目的非常明确：让所有发往模型提供商的请求先经过这个网关，再由网关转发到真实API服务，以便抓取和检查请求内容。

文中的“MCP底层原理”并不是通过阅读抽象协议说明得出的，而是通过这个网关记录下来的真实请求日志反推出的。因此，它在实验中的身份更接近“观测点”与“证据采集器”。

在文中的核心用途

作者之所以引入Cloudflare AI Gateway，是为了观察MCP协议底层原理、Function Call关系与实验验证摘要中最关键、最不透明的一层：客户端到底把什么内容发给了大模型。

其用途不是提供MCP server，不负责执行MCP工具，也不决定模型调用哪个工具；这些动作分别由Cline、本地MCP server与模型自身完成。它承担的是中间代理与日志记录职责，尤其用于查看：

客户端最终发给模型的完整请求
请求中的系统提示词
系统提示词里是否注入了MCP相关说明
模型可见的工具名、工具描述与参数格式
调用MCP时暴露给模型的入口名称，例如 use_mcp_tool 与 access_mcp_resource

这也是原文能够证明MCP工具提示词注入机制存在的直接依据。

实验中的部署方式

文中的部署步骤是先在Cloudflare中创建一个 AI Gateway，然后把该网关提供的链接填入客户端配置中的 base URL，使原本直接发送给模型服务商的请求改为先流经网关。

具体流程包括：

进入Cloudflare的 AI Gateway。
点击 create gateway 创建一个新的 gateway，名称可自定。
创建完成后，进入右上角的 API 平台配置。
在可选平台中选择 OpenRouter。
在客户端中使用 OpenAI compatible 方式接入。
将Cloudflare提供的网关链接复制到客户端的 base URL 配置项。
再填写 OpenRouter 申请到的 API Key。
最后填写具体模型 ID，例如文中举例的免费 DeepSeek V3。

这样配置后，请求路径就变成“客户端 → Cloudflare AI Gateway → API提供商”，而不是客户端直连模型平台。

与 OpenRouter 的配合方式

原文明确写到，作者并不是把网关单独使用，而是将其与OpenRouter组合。网关的 API 平台里选择 OpenRouter 后，再通过 OpenAI compatible 接口方式在客户端接入。

这种组合的意义在于：

Cloudflare AI Gateway 负责代理与记录日志
OpenRouter 负责承载实际模型接入
客户端仍按兼容 OpenAI 的方式发请求
具体模型可以通过模型 ID 切换，例如文中举例的 DeepSeek V3

也就是说，Cloudflare AI Gateway处在“观察请求”的位置，OpenRouter处在“提供模型接入”的位置，两者职责不同，不能混为一谈。

关键贡献：暴露系统提示词与工具定义

Cloudflare AI Gateway在文中最关键的贡献，是让作者看到了请求日志里的系统提示词内容。原文强调查看日志时要“重点关注系统提示词”，因为正是在这里，作者发现了模型为什么会“知道”MCP server及其工具。

日志中暴露出的关键信息包括：

系统提示词明确告诉模型，MCP允许系统与本地运行的MCP server通信
提示词中写明可通过 use_mcp_tool 执行MCP协议相关工具
提示词中写明可通过 access_mcp_resource 获取资源
提示词中直接列出了可用工具
不仅有工具名称，如“get current time”“convert time”
还有每个工具的参数传递格式

这些日志直接说明：模型并不是凭空“懂得”本地MCP工具，而是客户端把MCP工具说明以提示词形式注入到了模型上下文中。

这也是MCP工具调用链路与MCP与Function Call关系分析能够成立的关键证据。

它支撑了哪些结论

原文几乎所有关于“MCP底层原理”的重要论证，都依赖Cloudflare AI Gateway抓到的请求数据。包括但不限于以下结论：

1. 模型知道MCP工具，是因为提示词注入

通过日志可以看到，MCP server的工具定义、工具用途与参数格式都已经出现在系统提示词里，所以模型能够据此决定是否调用工具。

2. MCP不等于模型原生 function call

因为日志显示，MCP相关知识是作为提示词附加给模型的，所以模型是否支持原生 function call，并不是它能否使用MCP的必要条件。

3. MCP的调用入口对模型是显式可见的

日志中出现了 use_mcp_tool、access_mcp_resource 这样的调用入口，说明客户端已经把“如何调用MCP”这件事描述给模型，而不是隐藏在不可见的底层机制里。

4. 参数格式是通过文本规范传达给模型的

作者不是从协议文档推测参数结构，而是直接从日志里看到工具参数定义，因此才能论证模型依据这些说明生成调用参数。

与MCP本身的边界

Cloudflare AI Gateway虽然对实验至关重要，但它并不参与以下能力：

不负责安装MCP server
不负责运行本地MCP server
不真正执行“获取当前时间”或“时间转换”这类工具
不替模型做工具选择
不等于MCP协议本身
不等于 function call 机制

文中的实际执行链路仍然是：Cline把用户问题和MCP说明发给模型，模型决定要调用哪个工具并给出参数，Cline再去调用本地运行的MCP server，最后把结果回传给模型整理输出。Cloudflare只是在这条链路前面提供一个“可见化窗口”。

因此，若没有它，MCP依然可以工作；但作者就难以拿到足够直接的请求证据去证明底层机制。

细节与实验语境

原文中，作者先在客户端接入网关，再安装与时间相关的MCP server，随后发起“现在的时间是什么”这类问题。之所以能够进一步分析模型为什么会尝试调用“get current time”工具，不是因为网关执行了该工具，而是因为网关记录下了模型调用前看到的系统提示词。

换句话说，它在实验中的价值不是“跑通任务”，而是“解释任务为什么能跑通”。这也是它区别于Cline与MCP server的地方。

Cloudflare AI Gateway