Anthropic 和 Cloudflare 联合推出了 Claude Managed Agents 的 Cloudflare 集成——把自主代码交付型 Agent 放进 Cloudflare 的隔离执行环境里跑。这意味着你不再需要自己搭容器集群、管安全边界、操心冷启动延迟,Agent 的运行、扩容和后端访问控制都由平台兜底。下面拆开看它到底解决了什么问题,以及怎么上手。
为什么要把 Agent 放到 Cloudflare 上跑
自主 Agent(能自己规划、调用工具、写代码、提交结果的 Agent)和普通 API 调用不一样:它需要长时间运行、反复调用外部工具、访问私有后端服务,还要保证执行环境干净可隔离。传统做法是自己在 VPS 或 Kubernetes 上起沙箱,但这条路的问题很现实:
- 冷启动慢:Agent 每次拉起容器都要等镜像下载和运行时初始化,全球用户延迟差异大。
- 隔离成本高:自己建沙箱要管网络隔离、文件系统隔离、进程隔离,漏一项就是安全事故。
- 扩容麻烦:Agent 流量突发时手动加节点,闲时资源空转烧钱。
Cloudflare 的 Workers 平台天然解决了前两个问题——边缘节点全球分布、V8 isolate 级隔离、零冷启动。现在加上 Claude Managed Agents 的集成,第三个问题(扩容)也交给了 Cloudflare 的自动调度。
三个核心能力
1. 全球扩容的执行环境
Agent 不再绑在某台服务器上。Cloudflare 的边缘网络有 300+ 城市 PoP,Agent 请求会被自动路由到离用户最近的节点执行。流量从 10 QPS 到 10K QPS,平台自动伸缩,不需要你改配置或加机器。
2. 严格的后端访问控制
Agent 要调用你的私有 API(比如内部数据库、代码仓库、部署服务),但你不想把这些服务暴露到公网。Cloudflare 的集成通过 Private Backend 机制实现:Agent 运行在 Cloudflare 的隔离环境里,通过 Cloudflare Tunnel 或 Service Binding 访问你的私有后端,流量不经过公网。你可以精确控制每个 Agent 能访问哪些后端、用什么权限。
3. 自定义工具和运行时
Claude Managed Agents 默认提供一套基础工具(文件读写、代码执行、搜索等),但实际业务中你需要自己的工具——比如调用 Jira API、触发 CI pipeline、查询内部知识库。集成允许你用 Cloudflare Workers 定义自定义工具函数,然后注册给 Agent 使用。运行时环境也可以自定义:装什么包、设什么环境变量、挂什么 KV 存储,都在你的控制下。
实战:部署一个带自定义工具的 Agent
下面用一个完整示例演示:创建一个 Claude Managed Agent,注册一个自定义工具(查询内部部署状态),并配置 Private Backend 访问控制。
步骤一:创建自定义工具 Worker
先写一个 Cloudflare Worker,作为 Agent 的自定义工具,查询内部部署系统的状态:
// worker-deploy-status.js
export default {
async fetch(request, env) {
// 只允许来自 Agent 的内部调用
const signature = request.headers.get("X-Agent-Signature");
if (signature !== env.AGENT_SECRET) {
return new Response("Forbidden", { status: 403 });
}
const url = new URL(request.url);
const service = url.searchParams.get("service") || "all";
// 模拟查询内部部署系统(实际中替换为你的后端调用)
const status = await queryDeployStatus(env.DEPLOY_DB, service);
return Response.json({
tool_result: {
service,
status: status.state,
last_deploy: status.timestamp,
commit: status.commit_sha,
},
});
},
};
async function queryDeployStatus(db, service) {
// 实际实现:查 D1 / 内部 API / KV
// 这里用 D1 做示例
const result = await db
.prepare("SELECT state, timestamp, commit_sha FROM deploys WHERE service = ? ORDER BY timestamp DESC LIMIT 1")
.bind(service)
.first();
return result || { state: "unknown", timestamp: null, commit_sha: null };
}
步骤二:配置 wrangler.toml
把 Worker 绑定到 D1 数据库,并设置 Agent 密钥:
# wrangler.toml
name = "deploy-status-tool"
main = "worker-deploy-status.js"
[[d1_databases]]
binding = "DEPLOY_DB"
database_name = "deploy-status-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
[vars]
AGENT_SECRET = "change-me-to-a-real-secret"
部署工具 Worker:
wrangler d1 create deploy-status-db
wrangler deploy
步骤三:注册 Agent 并绑定工具
在 Cloudflare Dashboard 的 AI 选项卡里创建 Claude Managed Agent,或者用 API:
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/agents" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "deploy-review-agent",
"model": "claude-sonnet-4-20250514",
"description": "Review deployment status and suggest rollback actions",
"tools": [
{
"type": "custom",
"name": "query_deploy_status",
"description": "Query the deployment status of a service",
"worker_endpoint": "deploy-status-tool.your-subdomain.workers.dev",
"input_schema": {
"type": "object",
"properties": {
"service": {
"type": "string",
"description": "Service name to query"
}
},
"required": ["service"]
}
}
],
"private_backends": [
{
"name": "internal-api",
"binding": "INTERNAL_API",
"service": "your-internal-api-worker"
}
]
}'
步骤四:调用 Agent
部署完成后,用 API 调用 Agent:
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/agents/{agent_id}/run" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"prompt": "Check the deployment status of the payment-service and tell me if the latest deploy is healthy. If not, suggest a rollback plan.",
"stream": false
}'
Agent 会自动调用 query_deploy_status 工具,拿到结果后分析并给出建议。整个过程在 Cloudflare 的隔离环境里执行,你的私有后端通过 Service Binding 内部可达,不暴露到公网。
落地前的考量
| 维度 | 建议 |
|---|---|
| 工具设计 | 每个自定义工具只做一件事,输入输出用 JSON Schema 严格定义,避免 Agent 理解歧义 |
| 权限边界 | Private Backend 按最小权限配置——Agent 只能读部署状态就只给读权限,不要把写权限也绑上 |
| 成本控制 | Agent 每次运行会消耗 Anthropic token + Cloudflare Workers 调用,高频场景注意设调用上限 |
| 调试 | 初期建议 stream: true,实时看 Agent 的推理过程和工具调用链,方便定位工具返回格式问题 |
| 冷启动 | Workers 本身零冷启动,但自定义工具里的 D1/KV 首次连接有几十毫秒延迟,关键路径可预热 |
什么时候值得用,什么时候先等等
如果你的团队已经在用 Claude 做 Agent 开发,并且遇到以下情况之一,这个集成值得立刻试:
- Agent 需要全球用户低延迟访问(比如客服 Agent、代码审查 Agent)
- 你不想自己维护沙箱和隔离环境
- Agent 需要访问私有后端,但安全团队不允许公网暴露
反过来,如果你的 Agent 只在内网跑、用户集中在一个区域、或者你已经有成熟的 Kubernetes 沙箱方案,迁移的紧迫性没那么高——可以先在一个非关键 Agent 上做试点,验证工具注册和 Private Backend 的实际表现,再决定是否全面迁移。
Cloudflare + Anthropic 这步棋把 Agent 的"运行在哪"和"能访问什么"这两个最麻烦的基础设施问题打包解决了。剩下的核心挑战——Agent 的推理质量、工具编排逻辑、业务边界定义——仍然在你手上。平台兜底基础设施,你专注 Agent 本身的能力建设,这个分工是合理的。