用一句话管理整个平台：Cloudflare Agent Lee 是怎么做到的

fliter
0 阅读9分钟

技术产品的界面，几十年来几乎没变过

自互联网诞生以来，使用技术平台的动作没有实质性的变化：点进五层菜单，在多个标签页之间来回切换查日志，寻找藏在某个角落里的配置开关，希望自己能在茫茫选项里认出问题在哪里。

凌晨两点，你的 Worker 开始大量返回 503。问题可能出在 R2 存储桶、路由配置，也可能是某个限速规则在默默触发。你打开六七个标签，一边翻日志一边靠经验。大多数开发者在凌晨两点没有一个熟悉整个平台的队友陪着——Cloudflare 现在想给你配一个。

他们明确说，不想只是"在 Dashboard 里加一个聊天框"。他们想要的是一种全新的方式来与整个平台交互：任何任务，任何模块，一句话描述，直接完成。

这就是 Agent Lee。

Agent Lee 是什么

Agent Lee 是嵌入 Cloudflare Dashboard 的 AI 助手，理解你的 Cloudflare 账户——你的 Workers、你的域名配置、你的 DNS 记录、你的错误率。今天分散在六个标签页里的知识，现在集中在一个地方，你可以直接和它对话。

用自然语言，可以做四类操作：

回答问题："给我看一下这个 Worker 里出现最多的前 5 个错误。"

排查问题："我的网站用 www 前缀访问不了。"

执行变更："给我的域名开启 Access。"

部署资源："创建一个新的 R2 存储桶存照片，然后把它连接到我的 Worker。"

不是带你去找答案，而是直接给答案，必要时直接执行。问过去 24 小时的错误率走势，Agent Lee 会在对话里直接渲染一张图表，数据来自你的真实流量，而不是把你重定向到另一个分析页面。

目前 Agent Lee 每天服务约 1.8 万活跃用户，执行约 25 万次工具调用，覆盖 DNS、Workers、SSL/TLS、R2、Registrar、Cache、Cloudflare Tunnel、API Shield 等产品线。这些是生产环境里真实账户的真实操作数字，不是演示环境里的结果。

技术实现：让模型写代码，而不是调工具

理解 Agent Lee 的构建方式，需要先理解一个关键技术选择：Codemode。

传统 Agent 工具调用的工作方式是这样的：把工具的名称、参数、描述打包成定义喂给模型，模型选择调用哪个工具，系统执行后把结果返还给模型，模型再决定下一步，如此循环。每一步都是一次往返，每一次往返都有延迟和 Token 成本。任务越复杂，往返越多。

Cloudflare 的选择不同：不把 MCP 工具定义直接给模型，而是把这些工具转换成 TypeScript API，让模型写代码来调用它。

这个选择有两个实质性优势。

第一，准确率。LLM 在训练数据里见过大量真实世界的 TypeScript，但几乎没见过标准化的工具调用格式。用熟悉的语言工作，模型的准确率更高，犯格式错误的概率更低。

第二，效率。对于多步骤任务，模型可以在一个脚本里把所有调用链式写完，最后只返回最终结果。所有中间状态的往返都消失了，整个任务变成一次执行。

生成的代码发往上游的 Cloudflare MCP Server 执行，中间有一个 Durable Object 充当凭证代理——这是整个安全架构的核心位置。

安全架构：写操作的闸门不是界面礼貌

Agent Lee 的权限模型值得单独讲清楚，因为它是结构性设计，而不是行为约束。

Agent Lee 连接的 MCP Server 只暴露两个工具：search() 用于查询 API 端点，execute() 用于执行对 API 发起请求的代码。所有对账户的读取和写入都通过这两个入口。

路径中间的 Durable Object 在转发任何请求之前，会检查生成代码的 HTTP 方法和请求体，把操作分类为"读"或"写"：

  • 读操作：直接代理转发，无需等待
  • 写操作：被拦截，触发 Elicitation——向用户界面发出审批请求，等待明确确认后才继续执行

原文里有一句话说得很直接："The confirmation prompt you see is not a UX courtesy. It's the gate."（你看到的确认提示不是界面礼貌，而是执行闸门。）

Agent Lee 在代码层面无法绕过这个步骤。写操作不经审批就是无法发生，这是架构决定的，不是依赖模型的"自律"。

另一个细节：API 密钥不存在于生成的代码里。密钥由 Durable Object 持有，在向上游实际发起调用时由服务端注入。攻击者即便拿到生成的代码，也找不到任何可用的凭证。

生成式 UI：对话历史演变成活的仪表盘

Agent Lee 的界面设计有一个不寻常的选择：对话不只返回文字，而是动态生成可交互的 UI 组件。

问这个月的流量趋势，得到的不是一段描述数字的文字，而是一张内联渲染的交互式折线图，可以直接看到流量的峰值和低谷。问 DNS 情况，可能渲染架构图。问错误分布，可能是动态表格。

更进一步：每个对话旁边都有一个自适应网格。你可以拖拽划出一块区域，然后用自然语言描述想在这里看什么，Agent Lee 负责生成对应的 UI 组件填进去。对话历史不只是一条消息流，它会随着你的问题一起演变成一个动态的仪表盘，每次问的是不同的问题，整个界面就跟着重塑。

这个设计背后的判断是：和平台协作不应该只是文字往来。答案出来了，能不能真正理解它，往往取决于有没有可视化。

用自己的产品构建，是找到问题最快的方式

Agent Lee 的整个技术栈由 Cloudflare 自己的开发者原语构成：Agents SDK、Workers AI、Durable Objects，以及同样对外开放的 MCP 基础设施。这些不是内部专用的工具，而是任何在 Cloudflare 上构建 Agent 的开发者都能用到的东西。

Cloudflare 在这里做了一个直接的声明：这不只是设计原则，而是在生产环境里找 Bug 最快的方法。

在真实账户、真实用户的环境里构建 Agent Lee，意味着他们遇到的每一个限制，就是平台需要修复的地方；每一个运转良好的模式，就是可以让下一个在上面构建的团队省力的地方。

每天 25 万次工具调用产生的数据，是真实的反馈信号——不是通过压力测试模拟出来的，而是用户在真实操作中产生的。这些数据在持续告诉他们什么有效、什么没效、哪里需要改。

质量的持续度量

一个能对账户执行操作的 Agent，单次发布做好还不够，需要持续监控。Cloudflare 为此建立了一套运行中的度量体系：

  • 自动化 Eval：持续测量会话成功率和信息准确率
  • 用户反馈信号：对话里的点赞和踩，直接来自真实用户
  • 工具调用监控：执行成功率实时追踪，加上幻觉评分器
  • 按产品维度拆分：DNS 的问答质量和 Workers 的问答质量分开统计，问题可以精确定位到哪个产品线

这不是上线前做一次的验收测试，而是持续运行的质量基础设施。

接下来的路线图

原文在路线图上的描述分了三个层次，值得原样传达，因为它把"现在有什么"和"接下来做什么"分得很清楚：

现在：Dashboard 里的 Agent Lee，Beta 阶段，Cloudflare 免费套餐用户即可使用，在控制台右上角点击"Ask AI"进入。

下一步：CLI 支持和手机端。他们的判断是：你使用的界面不应该决定你能做什么。在终端里敲命令或者在路上拿手机，描述你需要什么，同样能完成。

再往后：主动式 Agent。不等你来问，而是主动监视你关心的事情——Workers 状态、流量变化、错误率阈值——在有什么值得注意的时候主动找你。只会响应的 Agent 是有用的工具；能主动发现问题的 Agent 是另一种东西。

底层积累：Agent Lee 现在已经知道你的账户配置。随着时间推进，它会知道你之前问过什么、你在哪个页面、你上周在调试什么。这种持续积累的上下文，是让一个平台从工具变成协作者的关键路径。

原文对现状的描述也很坦诚："我们还没到那里。今天的 Agent Lee 是第一步。架构是为到达那里设计的。" 方向清楚，当下的边界也说清楚了。

小结

从这次发布里有三个判断值得关注：

Codemode 对工具调用的替换是实质性决策，不是实现细节。 让模型写 TypeScript 而不是调工具，既提高了准确率，也把多步骤任务压缩成单次执行。对于覆盖整个 Cloudflare API 表面这样体量的工具集，两者的效果差距是显著的。

安全边界落在架构上，而不是模型行为上。 写操作不经审批无法发生，这不是因为模型被训练成这样，而是因为 Durable Object 在结构上不允许这发生。在 Agent 拥有真实账户操作权限的场景里，这种区别非常重要。

"用自己的产品构建自己的产品"让两件事同步推进。 Agent Lee 的开发和平台原语的改进用同一批摩擦点驱动，修复也可以是同一批修复。这个循环的速度，是外包给第三方工具做不到的。

参考链接

avatar
文章
阅读
粉丝