昨天，腾讯 WorkBuddy 发布 5.5.6 版本，上线全栈「应用」生成能力：
用户用一句话描述需求，就能生成一个带云数据库、文件存储、注册登录的完整网页应用，免部署，发布即得访 问链接。
每一个开启云服务的 WorkBuddy 应用，后端都运行在一个独立的 CloudBase 环境中。用户不一定感知到 CloudBase 的存在，但数据、账号、文件和访问链接都由它承载。
WorkBuddy 想让用户专注在需求和创意上，不必理解任何后端概念；CloudBase 想让后端成为 Agent 可以直接理解、操作和运维的基础设施。这两个目标指向同一个问题：当 AI 成为软件的生产者，应用的后端应该长什么样。
AI 时代需要新的后端基础设施
过去十年，云计算的基础设施围绕一个前提设计：人类工程师开发少量应用，手工完成资源配置和运维。但如今 AI 正在快速改变这个前提的两端：
- 开发主体从人变成 Agent：AI 促进了技术民主化，扩大了「开发者」的群体，现在任何普通人都可以通过 Agent 生成应用；
- 应用数量从少量变成海量：任何人在任何时间、任何设备上都能操控 Agent 生成应用，这极大地提升了应用的数量。
这两个变化不是对未来的预测，在 CloudBase 的运行数据里已经发生：现在每天有上万个应用被各种 Agent 在 CloudBase 上创建出 来；整个平台约 1/3 的调用量来自 Agent，这个比例还在快速扩张。
那么对于应用开发的基础设施，新的要求也随之浮现：
- 开发门槛趋近于零，基础设施必须不可见。 咖啡店老板、活动运营、宠物主人都在用 AI 做应用，他们不应该看到「数据库」「鉴权」「RLS」这些技术词汇，后端的配置和运维必须被 Agent 完全接管。
- 应用数量大、单体负载小，供给成本必须趋近于零。 每个用户可能创建多个应用，但绝大多数处于低频访问状态。后端服务必须能以近乎零的边际成本批量供给，空闲时不产生浪费。
- Agent 是后端的主要操作者，能力必须完全 API 化。 建表、写权限规则、部署、回滚，全部由 Agent 完成。后端的每一项能力都必须声明式、可被 Agent 理解和验证，没有「需要人去控制台点一下、配置一下」的隐藏路径。
满足这三条，靠的不是在旧架构上做加法，而是从供给、隔离、计量到回收的全链路自动化。
WorkBuddy 的「应用生成」能力，正是这样一套新基础设施的第一次完整落地。
WorkBuddy 如何基于 CloudBase 构建应用后端
每个开启云服务的 WorkBuddy 应用，背后都有一个独立的 CloudBase 环境，这是一 整套生产级后端：
- 一个独立的 CloudBase 环境：一应用一环境，资源与数据天然隔离，生命周期独立管理；
- PostgreSQL 数据库：结构化数据存云端，支持事务、复杂 SQL 与向量检索，数据权限由 RLS 策略以 SQL 显式定义，Agent 可以直接读写和校验；
- 内置身份认证：注册登录开箱即用，数据按用户隔离；
- 文件存储与免密钥 AI 调用：图片附件直接上云，大模型调用无需自行申请和管理 API Key；
- 秒级发布：构建、部署、回滚通过 MCP 完成，应用生成后秒级获得可访问的 HTTPS 链接。
对 WorkBuddy 的用户来说，这一切被压缩成了一个动作：确认开启云服务，应用就「有了后端」。数据存哪、谁能访问、如何上线，全部由 WorkBuddy 与 CloudBase 协同在背后完成。
CloudBase 平台集成方案：让每个平台都能拥有自己的后端云服务
WorkBuddy 的应用生成能力构建在 CloudBase 平台集成方案之上，这是 CloudBase 为任何 Vibe Coding 平台准备的解决方案：
1、多租户资源隔离
平台通过调用 CloudBase 的 API 批量创建和管理环境，每个应用分配一个独立环境，环境之间资源与数据天然隔离。
对平台来说，这意味着每个应用的后端供给完全自动化，不需要任何人工开通动作；任一应用出现异常流量或故障，也不会波及其他应用。
2、基于 API Key 的权限收敛
每个环境签发独立的 API Key，用户侧的 Agent 持有 Key 直连环境，自行完成建库建表、部署函数等操作，无需经过平台后端中转。
API Key 的权限边界就是环境本身：Agent 拿着某个环境的 Key，只能操作这个环境里的资源。即使 Agent 生成了错误的指令，也不会越权改到其他用户的环境。平台的整体安全边界由基础设施层保证，而不依赖 Agent 不出错。
3、资源管控能力
集成版套餐将 PostgreSQL 数据库、存储、函数等全部云资源统一折算为「资源点」，平台可以通过 API 查询每个环境的用量汇总和分模块明细，精确掌握每个应用消耗了多少、消耗在哪。
资源点可以直接成为平台自己商业化体系的计量单位，WorkBuddy 的会员权益就是基于资源点设计的：
| 会员版本 | 可开启云服务的应用数 | 每个应用每月资源点 |
|---|---|---|
| 免费版 | 10 | 5,000 |
| 标准版 | 30 | 25,000 |
| 高级版 | 50 | 50,000 |
| 旗舰版 | 99 | 150,000 |
4、灵活升降配与按量计费
每个环境的 PostgreSQL 可以随时独立升降配，升配立即生效；开启超限按量后，超出套餐额度的用量自动转为按量计费，业务不中断。
这让平台可以从最低成本起步：绝大多数低频应用跑在共享实例的 PostgreSQL 上，让成本可控；当某个应用突然爆量，单独把它的 PostgreSQL 升配即可，避免「应用访问量太大导致挂掉」这类事故。
除 WorkBuddy 外，腾讯吐司（tusi.qq.com）等 AI 应用生成平台同样基于 CloudBase 构建后端。模式是一致的：当 AI 生成应用的速度和规模超出人力运维的边界，后端基础设施本身必须先为 Agent 而设计。
让 AI 负责 Coding，让 CloudBase 负责后端
如果您正在构建 Vibe Coding 产品、企业内部的 AI 开发平台，或任何需要「为每个应用提供一个后端」的产品，不妨来试试把 CloudBase 集成到您的平台或产品中去：
- 阅读 CloudBase 平台集成方案文档
- 了解 CloudBase PostgreSQL 版
- 用 WorkBuddy 亲自生成一个全栈应用，看看它的后端长什么样
