基于Cloudflare Workers与容器技术构建云端智能编码助手部署指南

1. 项目概述：在云端部署一个专属的智能编码伙伴

如果你和我一样，经常需要在不同的机器上切换工作，或者希望有一个随时在线、配置统一、能记住你所有工作习惯的编程环境，那么自己搭建一个云端的“智能编码伙伴”会是一个绝佳的选择。Cloud Code 这个项目，本质上就是帮你把强大的 OpenCode 智能体（Agent）打包成一个容器，然后借助 Cloudflare 全球网络的基础设施来运行和管理它。简单来说，你不再需要在本机安装复杂的开发环境，而是通过浏览器访问一个部署在 Cloudflare 上的服务，这个服务背后就是一个功能完整、可以与你交互的 OpenCode 实例。

为什么选择 Cloudflare？对于个人开发者或小团队而言，它的 Workers 和容器服务提供了极具吸引力的免费额度，全球边缘节点的部署意味着低延迟访问，并且其生态系统（如 R2 对象存储、Tunnel 隧道）能无缝集成，一站式解决网络、存储和暴露服务的问题。而 OpenCode 作为新兴的智能编码助手，其本地化部署版本能更好地保护代码隐私，并允许深度定制。将两者结合，Cloud Code 项目就诞生了——它不是一个简单的托管服务，而是一个可完全掌控、可自定义、具备持久化能力的云端开发环境底座。

这篇文章，我将以一个实际部署者的角度，带你从零开始，深入理解 Cloud Code 的每一个组件，完成从本地开发、调试到最终上线的全流程。我会重点拆解那些官方文档可能一笔带过，但在实际操作中至关重要的细节，比如如何安全地配置认证、如何经济高效地设置持久化存储、以及如何排查容器启动时的各种“坑”。无论你是想快速搭建一个属于自己的云端 AI 编程助手，还是希望学习如何基于 Cloudflare 生态构建容器化应用，这篇详尽的实践指南都能提供直接的参考。

2. 核心架构与设计思路拆解

在动手之前，我们必须先理解 Cloud Code 是如何工作的。这不仅能帮助我们在遇到问题时快速定位，也能让我们在后续自定义时知道该动哪里。整个项目的架构可以清晰地分为三层：接入层、逻辑层和容器运行时层。

2.1 三层架构解析

第一层：接入层（Cloudflare Workers）这是整个服务的门面。所有外部 HTTP 请求首先到达 Cloudflare Workers。Worker 在这里扮演了一个“智能路由器”和“安全网关”的角色。它的核心职责包括：

1. 请求代理与协议转换：将来自客户端的 HTTP 请求，通过 Cloudflare 的ContainerAPI，转发给后端实际运行 OpenCode 的容器。这包括了处理 WebSocket 升级（用于编辑器实时协作）和 Server-Sent Events (SSE) 流（用于接收 AI 的流式输出）。
2. 身份认证（Basic Auth）：在请求抵达容器前，进行第一道安全校验。这是项目内置的简易而有效的防护，防止服务被随意扫描和访问。
3. 负载均衡与生命周期管理：虽然当前是单容器模式，但 Worker 架构为未来扩展成多容器池、实现简单的负载均衡和冷启动管理预留了可能性。

选择 Workers 作为接入层，而非直接暴露容器 IP，有几个关键优势：全球加速（利用 Cloudflare 的 Anycast 网络）、DDoS 防护、灵活的边缘逻辑处理（如根据地理位置路由），以及最重要的——它让我们的服务看起来就是一个普通的 Web API，简化了客户端的连接复杂度。

第二层：逻辑层（TypeScript 业务逻辑）这一层是项目的“大脑”，主要代码位于src/目录下。它定义了 Worker 如何与容器交互。

• index.ts：这是 Worker 的入口。它导出一个标准的ExportedHandler，处理fetch事件。在这里，它检查 Basic Auth、创建或获取AgentContainer实例，并将请求转发给它。
• container.ts：定义了AgentContainer类，它继承自@cloudflare/containers包中的Container。这个类的核心是管理容器的生命周期（启动、停止、重启）和维护与容器的连接会话。一个关键设计点是，它通常采用“单例”或“长连接”模式，避免为每个请求频繁创建/销毁容器，从而减少冷启动延迟。
• sse.ts：专门处理 Server-Sent Events 的逻辑。当 OpenCode 在容器内执行命令或生成代码时，会产生持续的流式输出。这个模块负责正确地从容器进程读取数据，并将其转换为符合 SSE 规范的 HTTP 响应流，实时推送给前端客户端。

第三层：容器运行时层（Docker 容器）这是实际执行 OpenCode 的环境。项目使用了一个预构建的 Docker 镜像（基于nikolaik/python-nodejs），里面集成了：

• Python 3.12 + Node.js 22：为 OpenCode 及其可能依赖的各种工具链（如 Python 数据分析包、Node.js 前端构建工具）提供了运行时。
• OpenCode 本体：智能编码 Agent 的核心。
• TigrisFS：一个 FUSE 文件系统驱动，用于将 S3 兼容的对象存储（如 Cloudflare R2）挂载为本地目录。这是实现数据持久化的关键。
• cloudflared：Cloudflare Tunnel 客户端，用于从容器内部向外暴露临时服务（如调试用的 Web UI）。

这种分层架构的好处是职责清晰、易于维护。Worker 处理网络和通用逻辑，容器专心提供计算和 AI 能力，中间通过明确的 API（容器控制接口、文件挂载）进行通信。

2.2 关键技术选型背后的考量

为什么用 TypeScript 和 Wrangler？Cloudflare Workers 原生对 TypeScript 支持极佳。使用 TypeScript 能在开发阶段就捕获大量类型错误，尤其是在与 Cloudflare 特定的环境变量（Env）和绑定（如 R2、D1）交互时，类型安全至关重要。Wrangler 是官方的开发和部署 CLI 工具，它无缝集成了本地模拟、秘密管理、版本发布等功能，是开发 Cloudflare 生态项目的不二之选。

为什么选择 S3/R2 + TigrisFS 做持久化？容器本身是无状态的，重启后所有更改都会丢失。对于开发环境，我们需要保存代码、安装的依赖、OpenCode 的配置和历史对话。直接在容器内挂载一个网络文件系统（NFS）是传统方案，但在云函数/容器场景下配置复杂。S3 协议是对象存储的事实标准，而 Cloudflare R2 提供了兼容 S3 API 且免出口流量费的存储。TigrisFS 则巧妙地将 S3 桶“伪装”成本地文件系统，对容器内的应用（包括 OpenCode）来说，它只是在读写本地磁盘，无需修改任何代码就获得了持久化能力。这是一个低成本、高兼容性的优雅方案。

集成 cloudflared 的实用场景你可能好奇，既然 Worker 已经能对外提供服务，为什么容器内还需要cloudflared？这里有两个典型场景：

1. 临时调试与预览：假设你在容器内启动了一个临时的 Next.js 开发服务器（npm run dev）在 3000 端口。你可以快速在容器终端执行cloudflared tunnel --url http://localhost:3000，获得一个临时的公网 URL 来预览页面，无需修改任何 Worker 配置。
2. 访问容器内其他服务：比如，你未来可能在同一个容器内部署了数据库的管理界面（如 Adminer）或监控面板，可以通过 Tunnel 安全地暴露给特定IP访问。

3. 从零开始的详细部署实操

理解了架构，我们开始动手。我会假设你从一个全新的 Cloudflare 账户开始，并详细记录每一个可能卡住的步骤。

3.1 前期准备与环境配置

首先，你需要准备好以下账户和工具：

1. Cloudflare 账户：前往 Cloudflare 官网注册。确保你的账户已验证邮箱，并且可以登录到 Dashboard。
2. GitHub 账户：用于 Fork 和克隆项目代码。
3. 本地开发环境：
   • Node.js (v20+)：建议使用nvm(Mac/Linux) 或nvm-windows来管理 Node 版本，方便切换。执行node -v确认版本。
   • pnpm：这是一个比 npm 更快、更节省磁盘空间的包管理器。安装命令：npm install -g pnpm。安装后执行pnpm -v确认。
   • Wrangler CLI：Cloudflare 的命令行工具。安装命令：pnpm add -g wrangler。安装后，运行wrangler login，这会打开浏览器，引导你授权 Wrangler 访问你的 Cloudflare 账户。这是后续所有部署操作的基础，务必成功。

3.2 获取项目代码并进行本地初始化

不建议直接克隆原仓库，最好 Fork 到自己的 GitHub 名下，这样你可以自由地修改和迭代。

# 1. 在 GitHub 上 Fork 原项目 (miantiao-me/cloud-code) # 2. 将你 Fork 后的仓库克隆到本地 git clone https://github.com/<你的用户名>/cloud-code.git cd cloud-code # 3. 安装项目依赖 pnpm install

这一步pnpm install会读取package.json，安装所有必要的依赖，包括@cloudflare/workers-types,wrangler等。

关键一步：生成环境变量类型定义项目使用wrangler.jsonc来配置环境变量和绑定。为了让 TypeScript 知道这些变量的存在和类型，需要生成类型定义文件。

pnpm cf-typegen

这个命令会读取wrangler.jsonc中的vars（环境变量）和bindings（如 D1、R2 绑定）配置，然后生成或更新worker-configuration.d.ts文件。每次你修改wrangler.jsonc中的配置后，都应该重新运行一次这个命令，否则 TypeScript 可能会报类型错误。

3.3 本地开发与调试

在部署到云端之前，强烈建议先在本地运行和测试。

pnpm dev # 或者 pnpm start

这两个命令都会启动wrangler dev，它会在本地启动一个模拟 Cloudflare Workers 环境的开发服务器。

本地开发服务器的关键特性：

• 它会自动读取你的wrangler.jsonc配置。
• 默认情况下，它会在http://localhost:8787启动服务。
• 它支持热重载（Hot Reload），你修改src/下的代码后，保存即可生效，无需重启。
• 它不会在本地启动真实的 Cloudflare 容器！对于容器相关的逻辑，wrangler dev会进行模拟或尝试连接到你在 Cloudflare 上已部署的容器服务。因此，第一次运行或容器逻辑有较大改动时，最好在本地进行基础的路由和逻辑测试后，再部署到云端进行完整测试。

如何测试 Basic Auth？在wrangler.jsonc中设置vars：

{ "vars": { "SERVER_USERNAME": "myuser", "SERVER_PASSWORD": "mypassword123" } }

运行pnpm dev后，用浏览器访问http://localhost:8787，你会看到一个认证弹窗。或者使用curl测试：

# 不带认证，应返回 401 curl -v http://localhost:8787 # 带认证，应能成功（注意将 `bXl1c2VyOm15cGFzc3dvcmQxMjM=` 替换为你自己的 base64 编码） curl -v -H "Authorization: Basic bXl1c2VyOm15cGFzc3dvcmQxMjM=" http://localhost:8787

生成 base64 编码的命令：echo -n 'myuser:mypassword123' | base64。

3.4 配置持久化存储（Cloudflare R2）

数据持久化是核心需求。我们使用 Cloudflare R2，因为它与 Workers 集成度最高，且免出口流量费。

1. 创建 R2 存储桶：

   • 登录 Cloudflare Dashboard，进入 “R2” 页面。
   • 点击 “Create bucket”，输入一个全局唯一的桶名，例如my-cloud-code-workspace。区域选择自动即可。
   • 创建成功后，进入桶的详情页。

2. 获取 R2 的 S3 兼容 API 凭证：

   • 在 R2 页面，侧边栏找到 “R2 API Tokens”。
   • 点击 “Create API token”。
   • 权限设置至关重要：选择 “Edit” 权限（至少需要Object:Read, Object:Write）。令牌名称随意，如cloud-code-token。
   • 在 “Resources” 部分，选择 “Specific bucket” 并选中你刚创建的桶。不要使用 “All buckets”，遵循最小权限原则。
   • 点击 “Create” 生成令牌。请立即妥善保存弹出的Access Key ID和Secret Access Key，它们只显示一次！

3. 配置项目环境变量： 我们需要将 R2 的访问信息通过环境变量传递给容器。在wrangler.jsonc文件的vars部分添加（注意，这里配置的是传递给 Worker，再由 Worker 传给容器的变量）：

   { "vars": { // ... 其他变量如 Basic Auth "S3_ENDPOINT": "https://<你的账户ID>.r2.cloudflarestorage.com", "S3_BUCKET": "my-cloud-code-workspace", "S3_ACCESS_KEY_ID": "你的 Access Key ID", "S3_SECRET_ACCESS_KEY": "你的 Secret Access Key", "S3_REGION": "auto", "S3_PATH_STYLE": "false", "S3_PREFIX": "", "TIGRISFS_ARGS": "" } }

   重要提示：直接将密钥写在wrangler.jsonc并提交到 Git 是极不安全的！我们应该使用 Wrangler 的秘密管理功能。

4. 使用 Wrangler Secrets 管理敏感信息： 在命令行中，进入项目根目录，执行以下命令来设置秘密。这些值会被加密存储在 Cloudflare 中，不会出现在你的代码仓库里。

   # 设置 S3 访问密钥 wrangler secret put S3_ACCESS_KEY_ID # 然后在提示中输入你的 Access Key ID wrangler secret put S3_SECRET_ACCESS_KEY # 然后在提示中输入你的 Secret Access Key # 其他非敏感或可公开的变量，可以保留在 wrangler.jsonc 的 vars 中 # 但 S3_ENDPOINT 和 S3_BUCKET 通常不算敏感，可以保留

   设置完成后，你需要从wrangler.jsonc的vars中移除S3_ACCESS_KEY_ID和S3_SECRET_ACCESS_KEY这两行。Wrangler 在部署时会自动注入这些秘密值。

   本地开发时如何使用 Secrets？运行wrangler dev时，它会尝试从云端读取这些秘密。确保你已登录 (wrangler login)。你也可以在项目根目录创建.dev.vars文件（此文件应被.gitignore忽略）来模拟本地秘密：

   S3_ACCESS_KEY_ID=你的本地测试AK S3_SECRET_ACCESS_KEY=你的本地测试SK

   wrangler dev会优先使用.dev.vars中的值。

3.5 首次部署到 Cloudflare

当本地测试通过，环境变量和秘密都配置好后，就可以进行首次部署了。

pnpm deploy

这个命令会执行以下操作：

1. 将你的 Worker 代码和配置打包。
2. 将容器镜像（如果配置了）推送到 Cloudflare 的容器注册中心。
3. 在 Cloudflare 上创建或更新你的 Worker 服务，并建立与容器服务的绑定。
4. 将环境变量和秘密注入到生产环境中。

部署成功后，命令行会输出你的 Worker 的访问域名，格式如https://cloud-code.<你的子域>.workers.dev。用浏览器访问这个地址，输入 Basic Auth 的用户名和密码，你应该就能看到 OpenCode 的界面了。

部署后的关键检查点：

• 日志：在 Cloudflare Dashboard 中，进入你的 Worker，查看 “Logs” 标签页。观察是否有错误信息，特别是容器启动失败或连接超时的错误。
• 容器状态：在 Dashboard 中进入 “Workers & Pages” -> 你的 Worker -> “Settings” -> “Containers”，查看绑定的容器状态是否为 “Active”。
• R2 桶内容：进入 R2 控制台，查看你的存储桶。如果持久化配置正确，容器启动后，桶内应该会自动创建workspace和.opencode目录。

4. 深入核心：配置详解与高级用法

基础部署完成后，我们来深入看看几个核心配置和高级用法，这些能让你更好地驾驭这个云 Agent。

4.1 深度解析wrangler.jsonc配置

这个文件是项目的总控中心。我们拆解关键部分：

{ "$schema": "https://raw.githubusercontent.com/cloudflare/workers-sdk/main/packages/wrangler/config-schema.json", "name": "cloud-code", // Worker 的名称，也是子域名的一部分 "main": "src/index.ts", // 入口文件 "compatibility_date": "2024-07-24", // 指定 Workers 运行时版本的兼容日期，重要！ "compatibility_flags": ["nodejs_compat"], // 启用 Node.js 兼容模式，某些 npm 包需要 "vars": { // 传递给 Worker 的环境变量（非敏感信息） "SERVER_USERNAME": "admin", // SERVER_PASSWORD 已移入 secrets "S3_ENDPOINT": "https://xxx.r2.cloudflarestorage.com", "S3_BUCKET": "my-cloud-code-workspace", "S3_REGION": "auto", "S3_PATH_STYLE": "false", "S3_PREFIX": "" }, "containers": { // 容器配置块 "bindings": [ { "type": "container", "name": "AGENT_CONTAINER", // 在代码中通过 `env.AGENT_CONTAINER` 访问 "container": { "image": "docker.io/miantiao/cloud-code:latest", // 使用的容器镜像 "command": ["/bin/bash", "-c", "启动容器的命令脚本，通常项目已内置"], "keep_alive": 300 // 容器不活动后的保活时间（秒），影响冷启动 } } ] }, "observability": { // 可观测性配置 "enabled": true, "head_sampling_rate": 1.0 // 头部采样率，1.0表示记录所有请求的trace } }

重要参数调优建议：

• compatibility_date：务必定期（如每季度）更新到一个较新的日期，以获取最新的运行时特性和安全更新。更新前请在测试环境验证。
• containers.bindings[0].container.keep_alive：这个值决定了容器实例在无请求后多久被回收。设置太短（如30秒）会导致频繁冷启动，用户下次访问需等待容器重新拉取镜像和初始化（可能10-30秒）。设置太长（如3600秒）则会持续占用资源，可能产生更多费用（如果超出免费额度）。建议值：对于个人使用的开发环境，设置为 300 到 600 秒（5-10分钟）是一个平衡点。
• observability：开启后，你可以在 Dashboard 的 “Trace” 标签页查看请求的详细链路，包括 Worker 执行时间和容器内耗时，对性能调优和问题排查非常有用。

4.2 自定义容器镜像与启动命令

默认使用miantiao/cloud-code:latest镜像。如果你想自己构建镜像，或者修改容器内的默认行为（例如预装特定软件包），你需要：

1. 编写 Dockerfile：在项目根目录创建Dockerfile，可以从官方镜像继承。

   FROM docker.io/miantiao/cloud-code:latest # 示例：安装额外的系统工具 RUN apt-get update && apt-get install -y \ htop \ vim \ && rm -rf /var/lib/apt/lists/* # 示例：预装 Python 包 RUN pip install --no-cache-dir pandas numpy # 保持原有的入口点 # ENTRYPOINT [ ... ]

2. 构建并推送镜像：你需要一个 Docker 镜像仓库（如 Docker Hub, GitHub Container Registry）。

   docker build -t yourusername/cloud-code-custom:latest . docker push yourusername/cloud-code-custom:latest

3. 修改wrangler.jsonc：

   "container": { "image": "docker.io/yourusername/cloud-code-custom:latest", // ... 其他配置 }

4. 部署：运行pnpm deploy，Wrangler 会自动使用新镜像。

关于启动命令 (command)：除非你非常清楚自己在做什么，否则不要轻易修改command。这个命令负责在容器内启动 OpenCode 服务、挂载 TigrisFS 等关键初始化操作。错误的命令会导致容器启动后无法提供服务。

4.3 利用 Cloudflare Tunnel 进行深度调试

当你的 Agent 行为异常，或者你想查看容器内部某个临时服务的状态时，cloudflared就派上用场了。但生产容器通常没有交互式终端。我们可以通过一个“调试模式”来启用它。

一个常见的技巧是：通过环境变量控制容器的启动行为。你可以修改项目代码（src/container.ts或相关的启动脚本），使其在检测到某个特定环境变量（如DEBUG_MODE=enabled）时，除了启动主服务，还同时运行一个 SSH 服务器或一个简单的调试 Web 端点。

更简单直接的方法是利用 Cloudflare 容器的“Exec” 功能（如果镜像内包含必要的 shell）。在 Cloudflare Dashboard 中，找到你的 Worker 对应的容器实例，可能会有 “Connect” 或 “Exec” 按钮，允许你打开一个浏览器内的终端会话。在这个终端里，你可以直接运行cloudflared tunnel --url http://localhost:<内部端口>来暴露服务。

实操案例：调试一个内部的监控面板假设你在容器内运行了一个 Prometheus 在 9090 端口。你可以在容器终端里执行：

cloudflared tunnel --url http://localhost:9090

cloudflared会输出一个临时的*.trycloudflare.com域名。在浏览器中访问这个域名（可能需要通过 Cloudflare Access 设置权限），你就可以看到 Prometheus 的界面了。这对于排查容器内部状态非常有用。

5. 实战问题排查与运维心得

即使按照指南一步步操作，在实际部署和运行中依然会遇到各种问题。这里我总结了一些常见的“坑”和解决方法。

5.1 容器启动失败与日志分析

这是最常见的问题。症状通常是 Worker 返回500或502错误，前端无法连接。

排查步骤：

1. 查看 Worker 日志：在 Cloudflare Dashboard -> Workers & Pages -> 你的 Worker -> Logs。关注ERROR级别的日志。常见的错误信息：

   • Container startup timed out：容器启动超时。可能原因是镜像过大、网络拉取慢，或者启动命令执行时间过长。尝试增加keep_alive让容器常驻，或者优化镜像大小。
   • Failed to bind to container：Worker 无法连接到容器。检查wrangler.jsonc中容器绑定的配置是否正确，特别是image地址。确保你的账户有权限使用容器服务（需要在 Dashboard 中启用 Beta 功能或确认套餐支持）。
   • Authentication failed for S3：S3 持久化挂载失败。检查S3_ACCESS_KEY_ID和S3_SECRET_ACCESS_KEY这两个 Secrets 是否设置正确，以及对应的 R2 API 令牌是否还有效（令牌可能被意外删除）。

2. 查看容器日志（如果支持）：Cloudflare 容器目前可能不直接提供stdout/stderr日志。一个变通方法是，将容器的日志输出到挂载的 S3 文件系统中。你可以修改容器启动脚本，将关键日志写入/root/s3/workspace/container.log，然后通过 R2 控制台或 Worker 提供一个下载接口来查看。

3. 检查镜像兼容性：确保你使用的容器镜像架构与 Cloudflare 的运行时兼容（通常是linux/amd64）。如果你在 Apple Silicon (M1/M2) 的 Mac 上构建了linux/arm64的镜像并推送，可能会导致运行失败。构建时使用--platform linux/amd64参数。

5.2 持久化存储不生效

表现为重启容器后，之前安装的包、编写的代码或 OpenCode 的对话历史全部丢失。

排查步骤：

1. 检查环境变量：确认S3_ENDPOINT、S3_BUCKET已正确配置在vars中，且S3_ACCESS_KEY_ID和S3_SECRET_ACCESS_KEY已通过wrangler secret put设置。
2. 检查 R2 桶内内容：直接去 Cloudflare Dashboard 的 R2 页面，查看你的桶。如果配置正确，容器首次成功启动后，桶内应该会出现workspace目录和.opencode目录。如果桶是空的，说明挂载可能失败了。
3. 检查 TigrisFS 挂载参数：S3_PATH_STYLE对于 Cloudflare R2 必须设为false（默认）。S3_REGION设为auto。S3_PREFIX如果你希望将数据存在桶的某个子目录下，可以设置，例如S3_PREFIX: "env/prod"，则数据会存在my-bucket/env/prod/workspace下。
4. 权限问题：确保你创建的 R2 API 令牌对该桶有读写（Object:Read, Object:Write）权限。如果使用了S3_PREFIX，令牌至少需要该前缀路径的权限。

5.3 性能优化与成本控制

对于个人项目，在免费额度内运行是目标。

1. 冷启动延迟：这是 Serverless 容器的通病。解决方案：
   • 适当增加keep_alive时间（如 600 秒），让容器在空闲时多存活一会儿。
   • 编写一个简单的“心跳”脚本，定期（例如每 5 分钟）向你的 Worker 端点发送一个轻量级请求（如 GET/health），保持容器活跃。你可以在本地用cron任务，或者使用另一个免费的 Cron 服务（如 GitHub Actions 的schedule事件）来触发。
2. R2 存储成本：R2 的免费额度很慷慨（10GB 存储，每月一定量的 A 类操作）。主要成本可能来自过多的PUT/POST/DELETE操作（B 类操作）。OpenCode 的频繁自动保存可能会产生大量小文件操作。可以考虑：
   • 调整 OpenCode 的自动保存频率（如果其配置允许）。
   • 定期清理workspace目录下的临时文件或node_modules（如果不需要持久化）。
3. Worker 调用次数：免费套餐有每日 10 万次请求的限制。对于个人使用几乎不可能用完。但如果你公开了服务且没有设置 Basic Auth，可能会被爬虫刷请求。务必启用 Basic Auth是最有效的防护。

5.4 安全加固建议

1. 强密码与定期更换：不要使用默认或弱密码。定期更换SERVER_PASSWORD，并更新对应的 Secret。
2. 限制 R2 令牌权限：遵循最小权限原则，只为令牌分配特定桶的读写权限，不要使用全局令牌。
3. 考虑使用 Cloudflare Access：对于更严格的安全需求，可以禁用 Basic Auth，转而使用 Cloudflare Access。在 Worker 前面设置一个 Access 策略，只允许你的 GitHub 账号、特定邮箱或 IP 地址访问。这样连密码都省了，且管理更灵活。
4. 监控与告警：在 Cloudflare Dashboard 中，为你的 Worker 设置简单的告警，例如当错误率超过 5% 或请求量异常激增时发送邮件通知。

部署和运行 Cloud Code 的过程，是一个典型的云原生应用实践。它涉及了无服务器函数、容器化、对象存储、安全认证等多个环节。通过这个项目，你不仅获得了一个私有的云端 AI 编程助手，更重要的