教程
Cloud Run instances 跑长驻 Agent：月成本约 5.70 美元，什么时候比 VM 更合适？
Google Cloud 在 2026 年 8 月 27 日推出 Cloud Run instances Preview，专门填补 Cloud Run services 和传统 VM 之间长期存在的一块空档：有些 AI Agent 需要“始终只有一个实例在线、长期保持状态、偶尔突发工作”，但又没有必要维护一整台 VM。Cloud Run instances 当前提供单实例、无自动扩缩、最长 7 天连续运行、默认自动重启、跨更新与重启保持不变的 HTTPS URL，以及 Stop/Resume。Google 给出的公开价格示例是 1 vCPU + 1 GiB 内存连续运行 30 天约 5.70 美元。它非常适合个人 Agent、消息机器人、低频 Worker 和小型自动化，但不适合高并发无状态 API，也不能简单替代 Kubernetes 或 VM。
# Cloud Run instances 跑长驻 Agent：月成本约 5.70 美元，什么时候比 VM 更合适？
## 文章摘要
Google Cloud 在 2026 年 8 月 27 日推出 Cloud Run instances Preview，专门填补 Cloud Run services 和传统 VM 之间长期存在的一块空档：有些 AI Agent 需要“始终只有一个实例在线、长期保持状态、偶尔突发工作”，但又没有必要维护一整台 VM。Cloud Run instances 当前提供单实例、无自动扩缩、最长 7 天连续运行、默认自动重启、跨更新与重启保持不变的 HTTPS URL，以及 Stop/Resume。Google 给出的公开价格示例是 1 vCPU + 1 GiB 内存连续运行 30 天约 5.70 美元。它非常适合个人 Agent、消息机器人、低频 Worker 和小型自动化，但不适合高并发无状态 API，也不能简单替代 Kubernetes 或 VM。
---
过去部署一个个人 Agent，通常有三个选择。
### 方案 A：本地电脑
```text
Laptop
↓
Agent
```
优点：
> 便宜。
缺点：
> 合上电脑，Agent 就没了。
### 方案 B：VM
```text
VM
↓
Agent
```
优点：
> 一直在线。
缺点：
- OS Patch；
- Firewall；
- HTTPS；
- SSH；
- 监控；
- 长期开机成本。
### 方案 C：Cloud Run service
很省运维。
但传统 Cloud Run service 的设计核心是：
> Request-driven + Auto Scaling + Scale to Zero。
对于“一个 Agent 应该一直在”的场景不够自然。
Cloud Run instances 就是为这个空档来的。
## 一、Cloud Run instance 和 Cloud Run service 最本质的区别
Cloud Run service：
```text
0 → N instances
```
根据流量扩缩。
Cloud Run instance：
```text
Exactly 1 instance
```
没有 Autoscaling。
这对个人 Agent 很合理。
一个 Agent 通常代表：
> 一个用户的一份记忆、一个状态、一个后台循环。
如果突然扩成 5 个副本，反而可能导致：
- 重复发消息；
- 重复执行任务；
- 重复调 API；
- 状态竞争。
所以“只能一个实例”在这里不是限制，而是产品语义。
## 二、最长 7 天连续运行是什么意思？
Google 当前说明：
> 一个 Cloud Run instance 最长可以连续运行 7 天，并默认配置自动重启策略。
这意味着：
> 它不是一台永远不重启的 VM。
Agent 本身必须设计成：
```text
Restart-safe
```
也就是：
- 状态不能只放内存；
- 任务要能恢复；
- 连接断开后能重建；
- 定时器要幂等。
## 三、Agent 状态应该放哪里？
不要：
```text
Conversation Memory
→ Python Dict
```
然后认为实例能一直活着。
更推荐：
```text
Agent Runtime
↓
Persistent Store
```
例如：
- Cloud Storage；
- Firestore；
- Cloud SQL；
- 外部数据库。
运行时可以重启。
状态继续存在。
## 四、稳定 HTTPS URL 很有用
每个 instance 会得到一个 HTTPS URL。
而且 Google 说明：
> 更新与重启后 URL 保持不变。
这非常适合：
- Telegram / WhatsApp Webhook；
- Agent Control UI；
- Home Automation Callback；
- 外部服务回调。
不需要自己：
> 配 Nginx + TLS。
## 五、为什么可以 Stop / Resume？
个人 Agent 并不一定 24×7 都要运行。
比如：
> 工作日 8:00～22:00。
或者：
> 旅行时才开启。
Cloud Run instance 可以停止后再恢复。
这比 VM 的“关机 + 管理磁盘 + 网络”更轻。
## 六、5.70 美元到底是什么口径？
Google 给出的例子是：
```text
1 vCPU
1 GiB RAM
持续运行 30 天
≈ 5.70 USD
```
这是当前 Preview 的公开示例价格。
要注意：
> 不是所有 Agent 每月固定 5.70 美元。
实际成本还可能包含：
- Storage；
- Network；
- API；
- Model Token；
- Database；
- Logging。
对多数 Agent 来说：
> 模型 API 费往往比 Runtime 费更高。
## 七、为什么它能这么便宜？
Google 使用 Shared vCPU + Burst Budget。
这类 Agent 非常符合这种负载：
```text
大部分时间：idle
↓
收到消息
↓
CPU spike
↓
继续 idle
```
如果你的程序 24 小时 100% CPU：
> 这就不是它最理想的工作负载。
## 八、什么是典型 Long-lived Agent？
例如：
```text
Personal Assistant
↓
Telegram
↓
一直监听
```
或者：
```text
Email Agent
↓
每隔一段时间查新任务
```
又或者：
```text
Research Agent
↓
维护长期任务状态
```
它们共同特点：
- 单用户；
- 单实例；
- 长期在线；
- CPU 大部分时间不满载；
- 需要稳定地址或后台状态。
## 九、什么时候 Cloud Run service 更合适？
如果你的服务是：
```text
1000 Users
↓
HTTP Request
↓
Stateless API
```
更适合 Cloud Run service。
因为你真正需要的是：
> Auto Scale。
典型场景：
- Web API；
- Public RAG Endpoint；
- Chat Backend；
- Batch HTTP Worker。
## 十、什么时候 VM 更合适？
如果你需要：
- 完整 OS 控制；
- Kernel Module；
- 自定义 Networking；
- 长时间高 CPU；
- GPU 特殊环境；
- 常驻大量本地磁盘；
VM 仍然更合适。
不要因为 Cloud Run instance 新：
> 就把所有 VM 迁走。
## 十一、什么时候 Kubernetes 更合适？
如果你需要：
```text
很多 Agent
+
复杂调度
+
Sidecar
+
Service Mesh
+
GPU Pool
+
自定义网络策略
```
GKE / Kubernetes 更强。
Cloud Run instances 的目标不是：
> 替代容器编排平台。
而是：
> 把“一份长期在线 Container”做得更简单。
## 十二、一个典型个人 Agent 架构
```text
Telegram / Webhook
↓
Cloud Run instance
├── Agent Runtime
├── Scheduler
└── Tool Router
↓
External Services
├── Gemini / Claude / OpenAI
├── Calendar
├── Email
└── Search
```
状态：
```text
Cloud Storage / Firestore
```
Secret：
```text
Secret Manager
```
## 十三、不要把 API Key 直接写进镜像
最差：
```dockerfile
ENV GEMINI_API_KEY=xxx
```
更合理：
```text
Cloud Run Identity
↓
Secret Manager
↓
Runtime
```
Agent 一旦被 Prompt Injection：
> Secret 仍然应该尽可能难被直接读取。
## 十四、稳定 URL 不代表应该 Public
Google 示例可以快速暴露 Public HTTPS。
但生产个人 Agent 应该考虑：
```text
谁能调用这个 URL？
```
如果只是自己使用：
- Identity-aware access；
- Webhook Secret；
- Signed Request；
- Token；
都比“完全公开”更合理。
## 十五、Agent 重启恢复流程要设计清楚
启动时：
```text
Boot
↓
Load Config
↓
Load Last State
↓
Rebuild Connections
↓
Resume Pending Jobs
↓
Ready
```
而不是：
> 启动时假设这是第一次运行。
## 十六、Pending Job 必须幂等
比如 Agent 计划：
> 10:00 发一封邮件。
9:59 执行开始。
10:00 Runtime 重启。
如果恢复后又执行一次：
> 邮件发两封。
因此任务至少要有：
```text
job_id
status
idempotency_key
```
## 十七、日志也不能只放本地
Cloud Run instance 不是永久机器。
不要依赖：
```text
/app/logs/*.txt
```
要发到：
- Cloud Logging；
- 外部 Observability。
否则重建后：
> 事故证据没了。
## 十八、什么时候“一个 Agent 一个 Instance”很合适？
对于：
```text
几十个高价值内部用户
```
可以：
```text
User A → Instance A
User B → Instance B
```
优势：
- 状态隔离；
- 故障隔离；
- Secret 隔离；
- 成本清晰。
但如果：
> 10 万个用户，
每人一个实例显然不经济。
这时需要：
> Multi-tenant Agent Platform。
## 十九、选型表
| 场景 | 更适合 |
|---|---|
| 单人长驻 Agent | Cloud Run instances |
| 无状态 HTTP API | Cloud Run services |
| 大规模多 Agent 平台 | GKE / Kubernetes |
| 需要完整主机控制 | VM |
| 低频后台机器人 | Cloud Run instances |
| 高 CPU 常驻任务 | VM / GKE |
## 二十、值得关注但不要过度宣传的点
Google 提到一家用户反馈：
> 使用 Cloud Run instances 后，Long-running Agent 的 Cold Start 明显降低。
这是具体用户案例。
不能外推成：
> 所有 Agent 都会降低同样比例。
Cloud Run instances 当前仍然是：
> Preview。
生产使用还应该关注：
- SLA；
- 区域；
- 限制；
- 运维成熟度。
## 最终判断
Cloud Run instances 不是一个“更小的 VM”。
它更像：
> **把一个长期在线、单实例、偶发突发计算的容器，做成托管服务。**
这个形态刚好击中了个人 Agent 的典型基础设施需求：
```text
Always available
+
Mostly idle
+
Single stateful runtime
+
Stable URL
+
Low ops
```
对于个人助手、消息机器人、低频研究 Agent 和内部自动化，它可能比传统 VM 更轻。
但如果你需要高并发、自动扩缩或复杂编排：
> Cloud Run services / GKE 仍然更合适。
真正正确的选型问题不是：
> “Cloud Run instances 新不新？”
而是：
> **我的 Agent 到底是一个长期在线的个人进程，还是一个需要水平扩展的服务？**
想继续了解 Agent 部署、Cloud Run 和 AI 基础设施，可以访问 **智元选**：https://www.zyentorpicks.com/。