Cloudflare Ask AI：Agent Lee 到底有多好？

Cloudflare Ask AI 是控制面板右上角的按钮。其背后是 Agent Lee——一个能够读取你的账户、用通俗语言回答问题，并且自 2026 年 4 月起，在你批准更改后修改配置的 agent。

这不是又一个文档聊天机器人。它是一个持有凭据、位于互联网大部分流量之前的控制平面中的 agent。这值得比一篇发布公告更仔细的审视。

下面的内容都来自 Cloudflare 自己的文档和博客，以及遇到相关问题的人发布的公开事件报告。我没有让它接触生产账户，而在读完那些报告后，我也完全不急着这么做。这个选择本身就是本文的一部分。

Cloudflare Ask AI 按钮背后是什么

Agent Lee 构建于 Cloudflare 自己的技术栈之上：用于推理的 Agents SDK、Workers AI、用于存储每位用户的对话和写入审批门控的 Durable Objects，以及用于 API 工具定义的 Cloudflare MCP server。

有趣的地方在于它调用工具的方式。模型不是一次发出一个工具调用，而是针对一个生成的 API 编写 TypeScript，然后通过充当带凭据代理的 Durable Object，在沙箱中运行这些代码。Cloudflare 将其称为 Codemode。API 密钥不会出现在生成的代码中，而是由服务器端注入。读取操作会直接执行。写入操作会停在 Cloudflare 所称的 elicitation gate 上；在其发布文章中，Cloudflare 明确表示，确认提示本身就是门控机制，而不是一种 UX 装饰。

Cloudflare 表示，Agent Lee 每天在 DNS、Workers、SSL/TLS、R2、Registrar、Cache、Tunnel 和 API Shield 等服务中处理大约 250,000 次工具调用。

从架构上看，这是一个真正经过设计的系统，比我研究过的大多数厂商 copilot 都更加谨慎。问题不在架构上。

Cloudflare Ask AI 做对了什么

在狭义场景下，它的宣传基本成立。问它某个设置在哪里，它比你点开八个标签页更快。让它执行 DNS 查询或证书检查，你无需离开页面就能得到答案。让它生成流量图表，它会通过 generative UI 从你的分析数据中渲染出来。

账户感知能力是真正超越文档搜索的升级。它回答的是关于你的 zone 的问题，而不是文档中某个假设 zone 的问题。对于那些一年只接触 Cloudflare 控制面板两次、记不清某条规则究竟位于 Rules、Caching 还是 Configuration 下的人来说，这一点本身就很有用。

Cloudflare Ask AI 出错的地方

目前有三类失败已经被公开记录，而且它们并不是同一种失败。

没有人要求创建的令牌

2026 年 2 月下旬，Cloudflare 用户开始发现自己的账户中出现了一个名为“Agent Lee (auto-generated)”的 API token，而他们从未创建过它。删除也没有用，刷新后它又会出现。一篇社区帖子查明了原因：Ask AI 面板中一个小控件后面隐藏着名为“Let AI view your account”的设置，该设置在发布时默认启用。关闭它后，令牌才彻底消失。

该帖子中的一位用户表示，自己从未启用过这个功能，也没有收到任何通知。同一帖子中回复的一名前 Cloudflare 员工也同意，这项功能在未通知用户的情况下上线了，并指出了一个更严重的问题：agent 并不知道自己的令牌。之后，团队发布了 beta 文档并修复了令牌问题。

到了 5 月，一名开发者在审计凭据时，在自己的账户中发现了一个类似的令牌。该令牌创建于 4 月 28 日，三周后才被发现。他的文章Cloudflare's Ask AI created an API token with read access to my entire account描述了覆盖所有账户、所有 zone 和所有用户的读取权限，权限数量超过 160 项，而且没有过期日期。他的观点很有道理：“一个回答问题的助手，只需要针对该问题范围内的读取权限。”

Cloudflare 当前的文档将 API token 列在 Agent Lee 无法访问的内容之下。如果为 agent 配置的凭据比 agent 的预期用途更宽泛，那么这两件事可以同时成立。这正是永久、范围过宽且永不过期的令牌所带来的全部问题。

去看看吧：dash.cloudflare.com/profile/api-tokens。

无声的无回答

5 月，一名用户在Cloudflare 社区论坛上报告说，Ask AI 在几个流量分析问题上一直停留在“thinking about it”，随后什么也没有返回。没有错误，没有部分答案，也没有任何信号表明某个环节失败了。Cloudflare 方面的回复者复现了这个问题，并表示团队正在发布改动，以阻止这种无回答情况。

这是一个 beta bug，最终会被修复。我提到它，是因为它暴露了界面设计的问题。一个没有系统反馈的聊天面板，让你无法判断这是一个困难的问题，还是一条已经损坏的处理链路。

一条因已批准写入而损坏的缓存规则

7 月的报告才是值得你关注的那一个。一名用户在排查缓存问题时，通过 Ask AI 一步步处理，看到它成功保存，结果第二天早上发现问题又出现了。进一步调查后，他们发现 agent 通过 Rulesets API 将 browser_ttl 设置为 0，并启用了 override_origin。API 接受了这个值。之后在打开规则的编辑模式时，控制面板却将其标记为无效。该规则已经以损坏状态部署，而缓存绕过则悄无声息地没有发挥作用。

再读一遍这个过程，因为防护机制完全按照设计工作了，但最终结果仍然是一条损坏的生产规则。

审批门控无法覆盖的缺口

elicitation gate 回答了一个问题：你是否授权执行这次写入？但它无法回答真正导致该用户遇到问题的那个问题：这个值是否正确？

批准“在这条缓存规则上设置 browser TTL”，并不等于知道 0 与 override_origin 结合后会产生一条 API 接受、但控制面板拒绝的规则。要在审批提示中捕捉到这一点，你必须事先知道这个约束；而如果你已经知道这个约束，就不会来询问 agent 了。

这就是基础设施中“写入前确认”的结构性限制。授权不等于验证。一个人批准自己无法评估的更改，本质上只是多了几步的橡皮图章；而且这种失败模式比直接拒绝更糟，因为无声的错误配置看起来像是成功，直到流量告诉你事实并非如此。

如果你在构建 agent 系统，这就是可以迁移到其他场景的经验。我在构建由 agent 驱动的发布和 CMS 工作流时也遇到过同一堵墙：只有当审批环节的人确实能够判断 payload 时，审批步骤才真正能保护你。否则，你需要的是工具中的验证，而不是 UI 中的同意。

Free plan 悖论

截至 2026 年 9 月，Agent Lee 仍处于 beta 阶段，并且仍然只对 Free plan 账户开放。

想想这会把谁放进测试群体。那些真正复杂、拥有多个 zone、Enterprise WAF 规则，并且收入依赖缓存行为的账户无法使用它。能够使用它的账户，反而最不可能在 browser_ttl 为 0 造成损失之前发现这是错误的。

我理解这种爆炸半径逻辑。但这也意味着反馈循环恰好运行在错误的人群上，而 7 月的缓存事件正是这一点在实践中的体现。

我今天会如何使用 Cloudflare Ask AI

只读侦察，可以。询问某个设置在哪里、某个 zone 当前配置为何、证书是否有效，或者快速查看流量图表。这些风险低，而且确实能节省时间。

写入操作，不行。至少不会在任何承载我所关心流量的对象上这么做。让它告诉你会修改什么，然后自己在控制面板中完成更改，让控制面板验证你的输入。

无论你是否使用它，本周都有三件值得做的事：

这些做法都不是反 Cloudflare。我在自己的技术栈中使用他们的产品，包括用 Workers 和 D1 构建生产环境中的候补名单。重点在于，位于你的控制平面中的 agent，理应接受比位于编辑器中的 agent 更高程度的审查。

结论

Agent Lee 是我读过内部实现的厂商 copilot 中，架构最严谨的一个。Codemode、带凭据的代理、真正的审批门控，全部建立在他们自己的基础设施之上。Cloudflare 正确地完成了最困难的部分。

截至 2026 年 9 月的评分如下：

架构与发布之间的差距，就是整个故事。Cloudflare 谨慎地设计了凭据路径，却在没有通知任何人的情况下默认启用它；这一举动抵消了大量原本的谨慎。

适合提问。暂时还不值得信任来执行更改。

来源

截至 2026 年 9 月 18 日核查。