构建一个长期运行的 Agent

如何以每月仅 5.70 美元的价格，在云端 24/7 全天候运行一个自主 AI Agent？

最近，我想构建一个带有持久磁盘存储和即时 Web 仪表盘的后台 Worker，但我不想为管理虚拟机而头疼，也不想支付高昂的月度账单。

如果你正在构建长期运行的 Agent，你一定知道这种云托管的困境：

• 标准 Serverless（如 Cloud Run 服务或 Lambda）：当流量停止时，容器会缩容到零——这会立即终止你的后台循环，并清除 Agent 的活动内存（RAM）。另一方面，突然的流量高峰会启动多个容器，它们可能互相覆盖状态文件并损坏你的数据。（注意：请使用 JSON 或 Markdown 文件保存状态。避免使用 SQLite，因为 Cloud Run 卷挂载 存在限制）

• 常规虚拟机（如 EC2 或 Compute Engine）：能让你的 Agent 24/7 运行，但一台标准的 1 vCPU 机器即使空闲时通常每月也要花费 15 到 25 美元。即使你使用每月 7 美元、性能受限的分片虚拟机，你仍然要承担完整的基础设施管理开销。

去年，我用 ADK 构建了一个多 Agent 趋势发现器。它运行得很好，但我想让它完全自主：一个持续、长期运行的 Agent，在后台扫描和总结科技资讯，无需手动触发，也不产生高昂的托管成本。

Google Cloud 新的 Cloud Run 实例 原语正好解决了这个问题。它为你提供一个单一、始终开启的容器，24/7 运行，在共享 CPU 上每月仅需 5.70 美元，提供免费的 HTTPS 端点，并允许你像挂载普通本地磁盘一样挂载云存储。

以下是如何使用此设置构建和部署一个生产级长期运行 Agent（你可以参考代码仓库中的完整源代码）。

我们要构建什么？

我想随时了解 AI 和 Agent 工程领域的最新动态。但我不想每天早上手动打开 20 个不同网站标签页，而是想构建一个自己的长期运行 Agent，随时向我推送最新新闻。

以下是这个 Agent 的功能：

• 作为后台守护进程持续运行：每 30 分钟自动唤醒一次，收集最新新闻。请注意，Cloud Run 实例最多每 7 天会自动重启一次，因此你的 Agent 只需在重启后优雅地恢复其计划即可。

• 扫描 Hacker News 和其他精选的 AI 与 Agent 工程来源。

• 接收实时提醒和移动端分享：包含一个入站 Webhook（POST /api/webhook），这样你可以将突发推文、iOS 分享面板链接或 GitHub 发布信息直接推送给 Agent，进行即时总结。

• 过滤噪音：剔除付费墙、广告和低质量文章。

• 使用 Gemini 2.5 Flash 进行总结：我们使用 Gemini 2.5 Flash 来降低成本。如果你需要高级推理能力，可以换成更新的 Gemini 3.5 或 3.6 Flash 模型，但请注意，它们的输入 token 成本是 2.5 Flash 的 5 倍（每 100 万 token 分别为 1.50 美元和 0.30 美元）。对于简单的日常总结，2.5 Flash（或同样便宜的 Gemini 3.5 Flash-Lite）速度快、能力强，并且能将月度 API 账单控制在几美分。

• 安全保存数据：将每日 Markdown 简报和已见 URL 直接存储在挂载的云存储文件夹（/data）中。

• 提供简洁的 Web 仪表盘：提供一个即时网页，让你随时阅读简报或触发新的运行。

系统如何工作

整个应用运行在一个 Cloud Run 实例内：

你还能用长期运行的 Agent 构建什么？

科技简报 Agent 只是一个例子。由于 Cloud Run 实例为你提供了始终开启的后台 Worker、免费的 Web 端点和安全的本地磁盘存储，你可以将完全相同的模式用于许多开发者工作流：

• 持久化的 Slack、Discord 或 Telegram Bot：一个与聊天网关保持长连接的机器人，回答开发者问题，并将未解决的问题同步到你的待办事项中。

• 安全与漏洞监控器：一个按内部定时器运行的 Agent，监控依赖项和 CVE 安全源，并在本地磁盘上缓存漏洞签名。

• DevOps 事件分类副驾驶：一个 Agent，接收来自监控工具的入站 Webhook 提醒，运行不会超时的后台日志查询，并渲染即时根因仪表盘。

• 基于拉取的队列 Worker：一个 Agent，持续从 Pub/Sub、Kafka 或 RabbitMQ 拉取复杂任务，执行多步骤 LLM 推理，并将结果写入存储。

• 夜间 CI/CD 与不稳定测试修复器：一个后台守护进程，运行夜间测试套件，分析测试日志以发现不稳定的测试，并自动打开带有修复的拉取请求。

为什么 Cloud Run 实例非常适合 Agent

标准 Serverless 平台是为快速 Web 请求设计的。它们等待用户点击按钮，运行一秒钟，然后关闭。

长期运行的后台 Agent 有不同的需求：

使用实例，你获得了 Serverless 的简单性和 VM 的稳定性。由于你的实例始终处于热状态并带有公共 HTTPS 端点，它可以在一个容器中轻松处理三种触发方式：

• 周期性后台轮询：在内部 asyncio 调度上自主运行，无需外部 cron 服务。

• 即时 Web 仪表盘：打开阅读仪表盘时零冷启动。

• 实时推送 Webhook：一个入站 POST /api/webhook 路由，允许你将突发推文、iOS 分享面板链接或 GitHub 发布提醒直接推送给 Agent，进行即时总结。

何时不应使用此方案

Cloud Run 实例非常适合单 Worker 后台 Agent。如果你需要以下功能，则应选择其他工具：

• 大规模并行批处理作业：如果你需要一次处理 10,000 个文档，分布在 100 个并行 Worker 上，请使用 Cloud Run Jobs 或 GKE。实例是单一 Worker。

• 高流量、突发性 Web API：如果你的网站突然收到数百万请求，请使用标准 Cloud Run 服务，以便你的应用可以自动扩展到数百个容器，并在流量停止时缩容到零。

• 重型本地 GPU 模型托管：如果你想在专用 H100 GPU 上直接在容器内托管开放 70B 模型，请使用 GKE 或 Compute Engine。Cloud Run 实例是为连接 Gemini 等托管模型的 CPU 应用设计的。

替代架构：解耦的 Job + Service

你可以不采用单一实例，而是构建一个事件驱动系统：Cloud Scheduler 触发 Cloud Run Job 进行轮询，而一个缩容到零的 Cloud Run Service 托管仪表盘并监听 Webhook。

虽然这种解耦方法将计算成本降至免费层级的几乎 0.00 美元，但你失去了单容器的简单性。你被迫管理多个云服务和消息队列（以防止并发 Webhook 破坏你的状态），同时还要接受 Web 仪表盘的冷启动。

6 个简单步骤部署你的长期运行 Agent

你可以在大约五分钟内将此设置部署到 Google Cloud。

1. 启用云服务

export PROJECT_ID="your-project-id"
export REGION="us-west1"
export BUCKET_NAME="${PROJECT_ID}-agent-data"
export REPO_NAME="agent-repo"
gcloud config set project $PROJECT_ID
gcloud services enable run.googleapis.com storage.googleapis.com artifactregistry.googleapis.com cloudbuild.googleapis.com secretmanager.googleapis.com

注意：Cloud Run 实例并非在所有区域都可用。请从 Cloud Run 实例位置 页面选择你附近的受支持区域。

2. 为你的数据创建存储桶

gcloud storage buckets create gs://$BUCKET_NAME \
  --location=$REGION \
  --uniform-bucket-level-access

3. 构建你的容器

gcloud artifacts repositories create $REPO_NAME \
  --repository-format=docker \
  --location=$REGION
gcloud builds submit \
  --tag ${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/tech-briefing-agent:latest .

4. 创建服务账号

gcloud iam service-accounts create briefing-agent-sa \
  --display-name="Briefing Agent SA"
gcloud storage buckets add-iam-policy-binding gs://$BUCKET_NAME \
  --member="serviceAccount:briefing-agent-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectUser"

5. 安全存储你的 API 密钥

切勿以明文传递 API 密钥。将你的 Gemini API 密钥存储在 Google Cloud Secret Manager 中，并授予你的服务账号读取权限：

echo -n "YOUR_GEMINI_API_KEY" | gcloud secrets create gemini-api-key \
  --data-file=- \
  --replication-policy="automatic"
gcloud secrets add-iam-policy-binding gemini-api-key \
  --member="serviceAccount:briefing-agent-sa@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

6. 启动实例

gcloud beta run instances create tech-briefing-agent \
  --image=${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/tech-briefing-agent:latest \
  --region=$REGION \
  --port=8080 \
  --cpu=1 \
  --memory=1Gi \
  --public \
  --service-account=briefing-agent-sa@${PROJECT_ID}.iam.gserviceaccount.com \
  --add-volume mount-path=/data,type=cloud-storage,mount-options="uid=1000;gid=1000;file-mode=0700;dir-mode=0700",bucket=$BUCKET_NAME \
  --set-secrets "GEMINI_API_KEY=gemini-api-key:latest" \
  --set-env-vars "DATA_DIR=/data,POLL_INTERVAL_MINUTES=30"

我们设置 --cpu=1 和 --memory=1Gi 以将成本控制在 5.70 美元。如果省略这些参数，默认值为 2 个 CPU 和 2 GiB（约每月 11.40 美元，请参阅定价表）。为了改善加载时间，你可以增加 CPU 和内存。

[!TIP] 如果不同，请调整 mount-options 标志中的 uid=1000;gid=1000，以匹配 Dockerfile 中定义的具体非 root 用户 ID。

当此命令完成时，Cloud Run 会为你提供一个实时的 HTTPS Web 地址。在浏览器中打开它，即可看到你的简报仪表盘。

实际成本是多少？

以下是 24/7 运行此服务的真实月度账单：

不到两杯咖啡的价格，你就拥有了一个日夜运行的私人 Agent。

了解更多关于 Cloud Run 实例的信息

想深入了解 Cloud Run 实例？请查看以下官方 Google Cloud 资源：

• 官方发布博客：Introducing Cloud Run instances

• 官方文档：Create and manage Cloud Run instances

• 动手实践 Codelab：Deploying to Cloud Run instances Codelab

• 源代码与 ADK 图：Tech-briefing-agent on GitHub

接下来是什么？

托管问题已经解决，那么如何让 Agent 更智能、更具韧性？如何防止它在遇到付费墙时总结噪音，或者构建自我纠正的反思循环？

请加入我们的下一部分，我们将深入探讨使用 ADK 2.0 的图工程和 Agent 架构。

祝你构建愉快！

• 位置

华盛顿

• 加入时间

2026 年 3 月 14 日

• 复制链接

“缩容到零会杀死你的循环”这个问题，是每个人第一次尝试将 Agent 作为“服务”运行时都会遇到的。关于避免在 FUSE 挂载卷上使用 SQLite 的建议非常有价值——我们是通过惨痛教训学到的：当通过 GCS 挂载进行并发写入时，生成的数据库在本地看起来正常，但在云端却悄悄损坏了。JSON/Markdown 文件状态建议对单实例 Agent 效果很好，但我想指出其中隐藏的假设：一旦你拥有一个始终开启的容器，你也让该容器成为单点故障，除非循环完全幂等并经常检查点，否则没有崩溃恢复方案。我们最终将状态写为仅追加事件，而不是可变文件，正是为了确保循环中途崩溃并重启时不会留下半写入的状态文件。不过，每月 5.70 美元的始终开启 Cloud Run 实例确实是一个很好的原语——我很好奇它在实例重启（部署、底层主机迁移）时的表现：挂载的存储是否能干净地存活，你的循环是否能恢复，还是存在你必须设计规避的冷启动间隙？

如需进一步操作，你可以考虑屏蔽此人并/或举报滥用行为