WorkBuddy 联手 CloudBase：AI 负责写代码，后端交给云端基础设施

近日，腾讯 WorkBuddy 发布 5.5.6 版本，上线了全栈「应用」生成能力：用户用一句话描述需求，就能生成一个带云数据库、文件存储、注册登录功能的完整网页应用，免部署，发布即得访问链接。每一个开启云服务的 WOrkBuddy 应用，后端都运行在一个独立的 CloudBase 环境中——用户未必感知到 CloudBase 的存在，但数据、账号、文件和访问链接都由它承载。

WorkBuddy 想让用户专注在需求和创意上，不必理解任何后端概念；CloudBase 则想让后端成为 Agent 能直接理解、操作和运维的基础设施。两者指向同一个问题：当 AI 成为软件的生产者，应用的后端应该长什么样。

AI 时代需要新的后端基础设施

过去十年，云计算基础设施围绕一个前提设计：人类工程师开发少量应用，手工完成资源配置和运维。如今 AI 正在改变这个前提的两端：

• 开发主体从人变成 Agent：AI 促进了技术民主化，扩大了「开发者」群体，现在普通人也能通过 Agent 生成应用；

• 应用数量从少量变成海量：任何人在任何时间、任何设备上都能操控 Agent 生成应用，极大提升了应用总量。

这两个变化不是预测，在 CloudBase 的运行数据里已经发生：现在每天有上万个应用被各种 Agent 在 CloudBase 上创建；整个平台约三分之一的调用量来自 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 百分之百不出错。

3. 资源管控能力

集成版套餐将 PostgreSQL 数据库、存储、函数等全部云资源统一折算为「资源点」，平台可以通过 API 查询每个环境的用量汇总和分模块明细，精确掌握每个应用消耗了多少、消耗在哪。资源点可以直接成为平台自己商业化体系的计量单位——WorkBuddy 的会员权益就是基于资源点设计的：

4. 灵活升降配与按量计费

每个环境的 PostgreSQL 可以随时独立升降配，升配立即生效；开启超限按量后，超出套餐额度的用量自动转为按量计费，业务不中断。这让平台可以从最低成本起步：绝大多数低频应用跑在共享实例的 PostgreSQL 上，让成本可控；当某个应用突然爆量，单独把它的 PostgreSQL 升配即可，避免「应用访问量太大导致挂掉」这类事故。

除 WorkBuddy 外，腾讯吐司（tusi.qq.com）等 AI 应用生成平台同样基于 CloudBase 构建后端。模式是一致的：当 AI 生成应用的速度和规模超出人力运维的边界，后端基础设施本身必须先为 Agent 而设计。

延伸阅读

如果你正在构建 Vibe Coding 产品、企业内部的 AI 开发平台，或任何需要「为每个应用提供一个后端」的产品，可以进一步了解 CloudBase 的平台集成方案与 PostgreSQL 版：

• CloudBase 平台集成方案文档：https://docs.cloudbase.net/solutions/cloudbase-for-platforms/overview

• CloudBase PostgreSQL 版：https://docs.cloudbase.net/quick-start/pg-overview

也可以直接用 WorkBuddy 生成一个全栈应用，亲自看看它的后端长什么样。