月之暗面的 Kimi Code 和 Kimi Work 正式接入 CloudBase。两条产品线、两种交互形态，一个插件全搞定。

为什么是 Kimi​

Kimi 是国内 AI 编程赛道里增速最快的玩家之一——从对话式 AI 到代码生成，再到现在的 Kimi Code（终端优先的 CLI 客户端）和 Kimi Work（面向知识工作者的桌面 Agent），月之暗面在短时间内铺开了两条完全不同的产品线。

对 CloudBase 来说，这意味着我们的用户又多了两个「用自然语言操作云资源」的入口。

两条线，两个场景​

Kimi Code：终端党的选择​

Kimi Code 是一个命令行优先的 AI 编程客户端，类似 Claude Code 或 Codex CLI，但深度整合了 Kimi 的模型能力。

安装方式极简：

1. 在 Kimi Code 中输入 /plugins 打开插件面板
2. 切换到 Curated 标签页
3. 找到 Tencent CloudBase，回车 install

安装后重启 Kimi Code，CloudBase 的 29 个技能 + 1 个 MCP 服务自动加载。你可以直接说：

• "帮我创建一个 PostgreSQL 表，存用户信息"
• "部署一个云函数处理文件上传"
• "查一下今天的环境用量"

所有操作都在终端里完成，不用切浏览器。

Kimi Work：桌面端的效率工具​

Kimi Work 是 macOS / Windows 桌面应用，面向更广泛的知识工作者——不限于写代码，也能做文档整理、数据分析、定时任务等。

安装同样简单：

1. 打开 Kimi Work → 左侧 设置 → 插件
2. 找到 Tencent CloudBase，开关一拨即可
3. 面板显示 v0.2.0 · 29 个技能 · 1 个 MCP 服务

技术细节：一个插件，两端通用​

CloudBase 的 Kimi 插件（cloudbase-kimi-plugin.zip）基于 Open Plugin Spec 打包，内部包含：

插件通过 INTEGRATION_IDE=Kimi（Code）或 INTEGRATION_IDE=Kimi Work 环境变量标识来源，CloudBase MCP Server 会据此优化提示词和默认配置路径。

下一步​

• Kimi 配置指南 — Kimi Code 插件市场安装、手动 MCP 配置，以及 Kimi Work 桌面端插件面板与 ZIP 安装
• CloudBase 概述 — 了解全部支持的 IDE 和能力

这篇我们想聊：从 0 到 1 用 CloudBase 搭一个能真用的工作台，再一路长到能接图片视频、权限协同、外发链接、定时任务和支付。全程不写代码，全在 WorkBuddy 里跑完。

先说背景，方便第一次了解的朋友跟上节奏，最近两拨“交作业”都带火了用AI搭建工作台，一波是胡楚靓在小红书发视频，教大家用AI搭建专属工作台、晒网友交来的作业，直接带起全网热潮。另一波是WorkBuddy启动了AI工作台模板创作大赛，喊你教作业，底下留言热热闹闹。

评论区里既有"终于跑起来了"的成就感，也开始冒出更深的问题，比如换设备打开是空的、图片同步不了、发出去的链接别人填不进来、想跟家人一起用又想各看各的。

这些都是信号，说明工作台开始想长大了。

工作台会长大，起步顺手的底座，到后面往往不够用。

所以这篇讲两件事：先带你从 0 到 1 用 CloudBase 把工作台搭起来，再讲怎么给它接上能一直往上长的能力（图片视频、权限、外发、支付、定时任务、接入AI...等）。

一、什么时候，你会知道该换底座了​

看看这四个信号，踩中任何一条，都是底座该升级的提示。

信号 1｜想放图片、视频、PDF，不再只是文字

“可以同步图片吗？做个笔记本工作台，每天新增图文……新增的图文笔记一直无法同步。”

浏览器 localStorage 装不了图，base64 编码几张就撑爆配额。

信号 2｜想和家人 / 团队一起用，但每人只看自己的

“一个账号可以和家里女儿一起使用吗？我们是否可以在不同电脑上用一个界面来协作、创建家庭项目、给她辅导作业、监督日常计划……”

同账号多设备登录只是最基本的。真正的协作要"各登各的号、共享指定数据、各自看自己的私域"。这需要一整套身份 + 权限体系。

信号 3｜想把链接发给外面的人填，还得能读能写

“对外发布的 link，无法和数据表交互（内部链接可以）……”

这是表格类同步方案的天然边界：内部编辑器帮你维持关联，一旦发布成外部链接、脱离了编辑器环境，读写通道就断了。云数据库不存在这个问题，不管从哪里打开，走的都是同一套 API。

信号 4｜想再往前走一步, 网站、小程序、在线支付、能自动跑的后端

“希望能有轻量化的网站 / APP / 小程序功能，可以快速、可以支持在线支付……真正的小白也能做一个合规的网站和 APP。”

这已经是全栈应用的范畴了。工作台是入口，往后想接更多能力，底座得先能承接住。

只要你碰到其中任何一个，就是底座该升级的信号。

二、从 0 到 1，用 CloudBase 搭一个能真用的工作台​

不写代码，全在 WorkBuddy 里跑完。跟着这 7 步走一遍，你会拿到一个电脑手机同步、图片能存、别人访问也不丢数据的工作台。

开始之前，你有啥​

• • 一个内容创作工作台（或换成你自己的场景）——包含「今日重点 / 选题灵感 / 内容进度 / 发布日历 / 每周复盘」

• • 数据在腾讯云CloudBase（云开发）里，本地与云端自动同步

• • 电脑手机开同一个地址，看到的是同一份东西

• • 图片、文件也能同步

先备齐这几样​

• • WorkBuddy 客户端：对话框、连接器、Skill 都在里头

• • 腾讯云账号：开 CloudBase 免费体验环境用

• • 电脑 + 手机：跨设备验证本来就靠它俩

• • 建好环境后，就有了环境 ID ，后面接连接器、查部署、绑域名都靠它辨识

第一步：把工作台生出来​

WorkBuddy 里开搭，三种方式任选：

• • 套模板：对话框下方「不知道做什么，试试最佳实践案例」，挑最接近的一键套用,用官方或者开源 prompt 

  

• • 手写：一句话（目标 + 模块 + 约束）

做一个内容创作工作台，包含今日重点、选题灵感、内容进度、发布日历、每周复盘五个模块；先做成本地可跑的版本，移动端要适配。

它不会上来就写，而是先跟你把需求问清楚：场景 / 模块 / 设备 / 导航 / 首页露什么 / 视觉风格。这一步问得越清，后面返工越少。

需求对完发「开始制作」，扔后台跑。搭好右侧出预览，点右上角「在外部浏览器打开」看着更顺。

别急着上云，本地版先亲手点一遍：

• 每个模块加、改、删、勾都试一遍

• 首页数字要跟着模块联动

• 手机端按 F12 切移动视图看一遍，样式错位就截图给 WorkBuddy 修

顺手让 WorkBuddy 把「重置示例数据」按钮删了，免得哪天误点清空。下一步，把数据层从本地挪到云端。

第二步：开通一个 CloudBase 环境​

CloudBase 有免费体验版，先白嫖着。腾讯云开发控制台进去：

1. 1. 点「免费试用」，新用户有免费额度，学习/小规模用基本不产生费用
2. 2. 首次进入做「服务授权」
3. 3. 环境名填一个有意义的（比如 growth/rich，后面日志、部署、绑域名都靠它辨识）
4. 4. 地域默认上海
5. 5. 选「免费体验版本」，数据库选「文档数据库（NoSQL）」。当然也支持 PostgreSQL / MySQL，要根据业务来选。
6. 6. 填兑换码，点「立即购买」

建好进控制台，能看到云数据库、云函数、云存储、身份认证。工作台数据就存这个环境里。

第三步：WorkBuddy 接上 CloudBase​

回 WorkBuddy，点连接器，在管理链接器搜「腾讯云 CloudBase」，加号装上。添加选中，会话中使用就可生效。

授权成功，连接器变绿。到这步，WorkBuddy 才真正读得到你刚建的环境——它从"只会改本地代码"升级成"能操作云端资源"。

之后你可以直接在对话里让 WorkBuddy 查数据库、部署站点、管理云函数，不用自己开控制台。

第四步：把数据层搬上云，发布预览​

回生成工作台那个对话，直接说：

把工作台数据存放到CloudBase中，我需要多设备同步访问。

这句话可以直接复制、也可以换成你自己的说法。核心一句：数据上云、多设备同步。

它会先请你授权，然后确认数据现在搁哪、有哪些模块和字段、要改哪些文件、旧数据怎么备份、出错怎么退。

方案对完再让它执行：备份本地数据 → 在 CloudBase 建好数据集合 →数据读写从本地换成云端 → 部署出访问地址。

同步形态：更稳的是「本地 + 云端自动同步」本地留一份做秒开，云端集合做多端真源。文档数据库是 schemaless 的，后面想加新字段不用跑迁移，直接写就同步。

部署形态：静态托管，地址形如 https://<环境ID>.webapps.tcloudbase.com，想好记，也支持在控制台绑个自定义域名。

• • 电脑端开地址，加条任务，确认存住了，手机端开同一地址,数据也在

• • 电脑上加一条，手机刷新就出来；手机勾完成，回电脑刷新，状态同步变

• • 上传一张图片，另一端刷新，图也在

• 

到这一步，你已经拿到了一个电脑手机同步、图片能存、外发链接可用的工作台，这是它「真的能用」的起点。也可以前往云控制台查看部署的应用。

也能跟直接跟AI说：帮我检查后台数据库是否都正常使用，AI会帮你查询所有云端资源使用情况

三、进阶：四个「分水岭能力」，让工作台从"能用"变"好用"​

上面部署走完，工作台就已经在云端了。接下来这四件事，每做一件，工作台就往「实用」这一档再走一步。

3.1 图片、视频、大文件都能同步​

文字进数据库，图片视频进云存储，两者用一条记录关联。这是 CloudBase 的基础配置，你已经在第六步顺手拿到了图片同步。视频是同一套逻辑、只是文件更大，更值得放云端，本地视频塞进项目文件夹传起来慢、也不适合扔进代码仓库。

具体怎么落地视频上云 + 工作台播放，拆成两段：

A. 建云存储（一次性）

1. 进环境后，左侧「云存储」新建一个存储桶，建议视频单独开一个桶，别和图片混一起，方便后面单独控权限、清旧文件

B. 传视频、接进工作台（每次要用新视频时）

1. 1. 连接器接上后，直接在 WorkBuddy 对话里说「把这个视频传到云存储」，不用手动去控制台点上传
2. 2. 上传成功会拿到一个云端访问地址
3. 3. 告诉 WorkBuddy：「在工作台里生成一个页面，用刚上传的这个云端地址播放视频」，它会生成一个用 <video> 标签指向云端地址的页面

好处很直接：项目文件夹保持轻量、视频却能随时点开播放。不用担心浏览器存不下。

图片、视频、PDF、任何静态资源都能按照这个方法。

3.2 分级权限：协同的时候，每个人只看自己的​

这是家庭 / 团队协作的核心。CloudBase 原生支持两层权限

第一层：角色分级（决定"谁能进来、能碰什么资源"）

让AI帮你设计好符合这个系统所有的角色权限说明，按项目、按团队再细分都行。

第二层：行级权限（"每个人只看自己的"就靠这个）

每个角色对同一份数据，还能单独设读写范围：

• • me = 只能读写「自己创建的那条」

• • all = 能读写「所有人的」

举个具体例子。管理员配 rw:all + rw:me所有人的数据都能改；家庭成员配 rw:me只能读写自己的，看不到别人的；外发访客配 r:all + rw:me能看到公开信息，能改自己的一条。

同一个工作台，不同角色协同，各看各的，管理员看全部。 家庭里辅导作业的场景，就可以这么落地。自己写代码的 Web / 小程序：走数据库安全规则，用 doc._openid == auth.openid 判断"这条是不是我的"

不管哪种，都不用你自己搭一整套账号体系。

3.3 外发链接：谁打开都能读能写​

CloudBase 部署的站点，**数据和页面是同一个应用的一部分，**不管从哪里打开，读写走的是同一套 API。

再叠加身份认证，能做更多事：

• • 匿名模式：任何人点开都能填一条（比如客户反馈表、活动报名）

• • 登录后可写：需要留痕就要求手机号或微信登录

• • 登录 + 权限：登录后按角色决定能看多少

三档按需切换，不用重写代码。

3.4 从工作台到全栈应用​

工作台是入口，同一层 CloudBase 环境上还能长这些：

从工作台到全栈应用，中间没有断层，只是同一层数据上不断叠加能力。

这就是「选底座」真正的价值：起步做的是工作台，长大之后是完整的产品。

官方投稿征集​

工作台会继续长。需要加图片视频、想跟家人一起用又互不干扰、想把链接发给外面的人填、想接支付，想变成小程序APP持续积累运营职，直接用CloudBase一键升级。

📮 我们在小红书征集你的工作台

如果你也用 CloudBase 搭过工作台，不管是刚跑起来的 0 到 1，还是已经接上了云函数、云存储、权限、定时任务、AI 助手、支付……都欢迎你来投稿。

我们想看到更多真实的用户案例：

• • 你用工作台解决了什么问题

• • 用到了 CloudBase 哪些 Skill（云函数 / 云存储 / 权限 / 定时任务 / AI / 支付……）

• • 踩过什么坑、怎么绕过去的

• • 现在它长成什么样了

怎么参与：

1. 1. 在小红书搜索并关注 「CloudBase 和它的朋友们」
2. 2. 发一篇你的工作台笔记 #CloudBase，@官号 , 或在官方教程下评论区截图交作业都行，直接赠送资源点

3. 3.我们也会同步挑选案例，在官方渠道里展示

也欢迎你把踩过的坑、想问的问题发过来，未来的案例分享可能就是从你的分享开始的，欢迎转给身边也在琢磨"工作台怎么落地"的朋友们🐧

个人做小程序，企业团队做 vibe 应用，认准 CloudBase。

🔥 比 GLM 5.2 强在哪？​

• 编程 +50%：Z.ai Code Bench 较 5.2 提升 50%，Terminal Bench 3.0、Agents' Last Exam 等公开基准开源第一
• 安全上新：白盒代码审查、漏洞发现持平 Mythos 5
• CloudBase：写完直接上线，不用另开 AI 账号，切模型只需要改一个参数。云数据库（支持 PG）、云函数、域名备案、Token 都在同一份套餐里，AI 写完代码可以直接上线。

💻 两种姿势用 AI​

1. 装进正在用的 AI 开发工具​

云开发控制台 → AI → 生文模型启用即可。复制 Base URL 和 API Key，把模型直接装到 WorkBuddy、CodeBuddy、Codex 里当普通 OpenAI 兼容模型用就行。

2. 在全栈应用里直接调​

做小程序、Web、公众号或客服机器人时，SDK 几行代码拿流式输出，不用单独搭后端。

Token 用量自动从资源点扣，在套餐用量页实时查看。

现在就来 CloudBase 尝鲜 GLM 5.3 👇

今天，腾讯云 CloudBase 正式支持 PostgreSQL（开发者喜欢简称 PG）。作为全球应用广泛的开源数据库，PG 功能成熟、使用方式标准，天然适配 Agent 操作。接入 CloudBase 后，AI 生成应用时，从建表、配置权限到生成 API，都可以在 CloudBase 内一键完成。

针对 Agent 开发应用的新需求，CloudBase PG 底层依托腾讯云数据库能力进行了专门适配，让数据库也能跟上 Agent 快速开发、反复迭代的节奏。同时，CloudBase PG 高度兼容 Supabase，已经在用 Supabase 的开发者也可以低成本迁移。

Agent 看得懂：建完表，权限和 API 一步到位​

PostgreSQL 有一个很适合 Agent 的特点：足够标准，也足够显式。

表结构、字段约束、数据库函数、权限策略，都可以通过标准 SQL 定义。Agent 读取 Schema，就能理解数据怎么存、谁能访问、自己能做什么。

以一个协作文档应用为例，当你写下这些 SQL 时，几行代码就完成了数据建模、身份绑定和权限控制的全部工作：

在 CloudBase 里，建一张表还可以同时定义数据结构、用户身份和访问权限。表建好后，RESTful API 自动生成，增删改查直接可用，不需要再单独开发服务端接口。

全文检索、定时任务、RAG 语义搜索等更复杂的需求，也可以通过数据库函数、事务和 pgvector 等能力完成。CloudBase 此前上线的 MCP Server、Agent Skills 和插件系统也已适配 PG 模式——从建表、配置权限到调用 API，Agent 不仅能读懂，也能自己动手。

Agent 放心试：TB 级数据库秒级复制​

Agent 开发应用的过程中，经常需要反复修改表结构、调整权限策略、尝试不同的查询逻辑。代码可以放心改，现在，数据库也可以放心「分叉（Branch）」。

CloudBase PostgreSQL 版支持 Database Branch。Agent 需要尝试新方案时，可以先复制一套独立数据库环境，在里面修改 Schema、调整函数和权限策略。验证成功后再发布，失败则直接丢掉分支，不影响线上数据。

背后支撑这一能力的是腾讯云数据库。依托腾讯云自研的底层架构，1TB 数据库的复制可以从小时级缩短到秒级，让 Agent 每次试验都能快速获得一套与线上数据结构一致、彼此隔离的数据库环境。

Agent 随叫随到：秒级创建，闲时不占资源​

Agent 生成应用的数量和调用频率并不固定，数据库也需要更灵活地跟着应用启停和扩缩。

CloudBase PostgreSQL 版将数据库环境创建从分钟级缩短至秒级。Agent 生成一个新应用，数据库可以同步跟上，不需要等待传统数据库实例完成创建和初始化。

应用闲下来后，系统自动停止计算资源，但数据、权限策略和 API 等继续保留，请求再次到来时快速恢复。业务负载突然增长，也可以快速扩展计算资源——要用的时候马上有，不用的时候不用一直占着资源。

目前，这套能力已经在鹅厂 Agent 的后端稳定运行：

• CloudBase 接入 WorkBuddy 连接器，用户连接后就可以直接利用 CloudBase 做应用的数据库和后端。

• 搭载 CloudBase 的吐司，让用户输入需求后，就能完成应用开发和部署，生成的 App 自动拥有独立数据库、数据隔离和账户体系。

已经在用 Supabase？迁移几乎不用写代码​

CloudBase PG 高度兼容 Supabase。双方在数据库、用户认证、权限和接口等主要使用方式上基本一致，绝大多数项目只需少量改动即可完成迁移，实现无感搬家。

你的 AI 应用前端已经很精美了，快来腾讯云 CloudBase 配一个坚实的后端。

吐司是应用宝团队推出的「应用生成及灵感共创平台」。用户输入任意提示词，AI 完成 App 的开发、部署和上线，生成一个可以直接下载安装的 App。

一旦要服务成千上万的用户、生成成千上万个 App，后端就成了真正的瓶颈。一个能下载安装的 App，背后是数据库、登录、存储、托管一整套后端。如果每生成一个 App 都要 Agent 现写一遍 DDL、现配一遍 Nginx、现搭一套登录系统，生成会变慢、会变错，平台方也得在应用层反复兜底。通过 CloudBase，平台可以具备：

• 每个用户生成的 App 自动获得一份独立的云数据库实例，数据在租户维度天然隔离
• 内置微信、手机号、邮箱、匿名登录，App 从第一行代码起就自带账户体系
• 数据库、云函数、云存储、静态托管、容器托管全部封装为 MCP，Agent 声明式调用
• 生成和运行，走同一条数据链路

多租户数据隔离​

每一个用户生成的 App 如果涉及后端，都将自动创建一份独立的云数据库实例，数据在租户维度天然隔离，平台方无需在应用层再写一遍多租户逻辑。

Agent 在生成阶段可以通过 MCP 直接声明数据模型并写入测试数据，App 上线后真实用户的业务数据也落到同一份数据库里——从「生成」到「运行」走的是同一条数据链路，不存在「生成时一套库、上线后再迁一次」的接缝。

身份认证​

身份是另一个容易被忽略的成本。如果让 Agent 在提示词里现写一套 OAuth、现管一套 Session，既不稳定也不可复用。

CloudBase 内置了微信、手机号、邮箱、匿名登录等多种鉴权方式，吐司生成的 App 默认就具备「能登录、能识别用户、能区分数据归属」的能力。用户不需要在提示词里专门要求「帮我做一套登录系统」，Agent 也不需要现写一遍 OAuth / Session 管理；身份是平台的默认能力，App 从第一行代码起就自带账户体系，可以直接做收藏、个人空间、社交分享这类强账户特性。

MCP/Skills：让 Agent Loop 变短​

真正决定生成质量的，是 Agent 要处理多少底层细节。

CloudBase 把数据库、云函数、云存储、静态托管、容器托管等后端资源全部包装成标准 MCP 工具，并沉淀了一批面向常见场景（用户体系、内容存储、AI 调用、支付等）的可复用 Skills。吐司的 Agent 在生成 App 时不需要写 DDL、不需要配 Nginx、不需要管 HTTPS 证书，而是用声明式的方式调用 MCP，由 CloudBase 负责资源创建、配置发布和运行维护。这让 Agent Loop 显著变短、出错面大幅收敛，也让生成出来的 App 一上线就具备生产级的工程质量。

三层能力叠加起来，平台方就可以通过 Agent 用声明式调用拿到一整套默认生产级能力。点击「阅读原文」，查看全套解决方案。

About 吐司​

吐司是应用宝团队推出的应用生成及灵感共创平台。用户输入提示词，由 AI 完成 App 的开发、部署与上线，生成可直接下载安装的 App。后端以 CloudBase 为主要服务平台。

点击体验：https://tusi.qq.com

• 会话历史与压缩
• 断线重连
• 对接沙箱
• MCP/Skills 对接
• 人机响应（Human in the Loop）
• 模型多轮循环
• ……

真正与开发者自身业务相关的只是代码量很小的一部分，70% 的工作花在了这些底层细节上。

这和 Web 开发的「刀耕火种」时代很像：每个团队要从路由、ORM、会话管理开始重复造轮子，直到 Django、Rails 这些全栈框架把基础设施标准化了，开发者的精力才真正回到业务逻辑上。

Agent 开发现在就站在这条分界线上。虽然当下代码仍然是构建 Agent 的主要方式，但显然开发者不需要再徒手写一套会话持久化和工具编排了。

为了解决这些 Agent 开发者的痛点，我们今天很荣幸地推出 OpenAgentKernel：

• GitHub 仓库地址：https://github.com/TencentCloudBase/OpenAgentKernel
• CNB 仓库地址：https://cnb.cool/tencent/cloud/cloudbase/OpenAgentKernel

这是一个原生适配 CloudBase 平台的 Agent 框架，内置了会话持久化、工具编排、人机响应（HITL）等基础能力，让开发者可以专注于业务逻辑的实现，而不是陷入基础设施的细节中。

立即试用​

npm install @cloudbase/open-agent-kernel@beta

前置条件：Node.js 22+、一个 CloudBase 环境的 envId、以及环境的服务端 API Key。

最小示例：三十秒看懂核心 API​

import { createAgent } from "@cloudbase/open-agent-kernel";

process.env.TCB_API_KEY = "your-cloudbase-api-key";

// 创建 Agent
const agent = createAgent({
  envId: "your-env-id",
  model: "deepseek-v4-pro",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
});

// 创建会话
const session = await agent.startSession({ userId: "user-1" });

// 发送消息，并接收响应
for await (const event of session.send("一句话解释：什么是 Serverless？")) {
  if (event.type === "message_delta") process.stdout.write(event.text);
  if (event.type === "session_idle") break; // 本轮结束
}

你可以将上面这段代码很轻松地部署到 CloudBase 的 HTTP 云函数中运行，然后用 curl 或者 Postman 等工具来测试。

特性介绍​

1. 会话持久化和跨进程恢复​

会话记录默认持久化到云开发数据库，不依赖进程内存。

const agent = createAgent({
  envId: "your-env-id",
  model: "deepseek-v4-pro",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
});

const session = await agent.startSession({ userId: "user-1" });
const conversationId = session.id;

在之后的另一个进程里（比如第二次函数调用），可以直接使用 conversationId 来恢复对话上下文：

const resumed = await agent.resumeSession(conversationId);

2. MCP 接入​

对接 MCP 几乎是 Agent 开发中必须的功能，所以我们内置了多种 MCP 的接入方式：进程内、本地 stdio、远程 HTTP。

import { createSdkMcpServer, tool } from "@anthropic-ai/claude-agent-sdk";
import { z } from "zod";

// 进程内 MCP
const localMCPServer = createSdkMcpServer({
  name: "calc",
  version: "1.0.0",
  tools: [
    tool(
      "add",
      "Add two numbers",
      { a: z.number(), b: z.number() },
      async (args) => ({
        content: [{ type: "text", text: String(args.a + args.b) }],
      }),
    ),
  ],
});

// 本地 stdio MCP
const stdioMCPServer = {
  type: "stdio",
  command: "npx",
  args: ["-y", "@modelcontextprotocol/server-everything"],
};

// 远程 HTTP MCP
const remoteMCPServer = {
  type: "http",
  url: "https://example.com/mcp/v1",
  headers: { Authorization: "Bearer xxx" },
};

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
  mcpServers: {
    local: localMCPServer,
    stdio: stdioMCPServer,
    remote: remoteMCPServer,
  },
});

3. 人机响应（HITL，Human in the Loop）​

在 Agent 进行一些敏感操作时（比如删除数据库、设置密码等），我们通常需要用户主动确认，Agent 才可以继续执行任务。

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",

  // 配置哪些工具需要人工确认
  permissions: {
    requireApproval: ["database_delete", "reset_password"],
  },
});

配置完成后，Agent 如果在任务中遇到需要人工确认的工具，那么在响应的事件流就会触发一个 tool_approval_required 类型的事件，开发者可以进一步基于此来实现人工确认的产品交互逻辑：

const session = await agent.startSession({ userId: "user-1" });

for await (const event of session.send("帮我删除 todo_list 这个数据表")) {
  if (event.type === "tool_approval_required") {
    // 实现人工确认的交互逻辑，拿到 event.toolUseId 后调用 session.respondApproval()
  }
}

4. Agent 记忆​

现在记忆也成为了大多数 Agent 自带的能力。在 OpenAgentKernel 中，我们内置了记忆的功能：

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个智能助手，请帮我回答用户的问题",
  // 开启记忆
  userMemory: true,
});

用户私有的 .claude/ 记忆文件将会自动同步到 CloudBase 的云存储中，并且跨会话生效。

当然开发者也可以主动调用 API 来实现记忆的预置和删除：

import { writeUserMemoryFiles } from "@cloudbase/open-agent-kernel";

await writeUserMemoryFiles({
  envId,
  userId: "alice",
  files: [{ path: "CLAUDE.md", content: "请始终用中文回答。" }],
});

5. 沙箱：让 Agent 在安全环境中跑代码动文件​

Agent 跑代码、改文件、执行 Shell，都需要一个隔离的执行环境。为此我们在 OpenAgentKernel 中内置了沙箱（Sandbox）的功能：

const agent = createAgent({
  envId,
  model: "glm-5.2",
  systemPrompt: "你是一个全能编程助手，帮助用户编写代码",
  // 开启 Sandbox
  sandbox: {
    enabled: true,
    cloudbaseTools: true, // 镜像支持时，沙箱内可直接调用 CloudBase MCP 工具
    scope: "shared", // shared：多会话共享实例；session：每会话独立实例
    ttl: 3600,
  },
});

开启沙箱后，Agent 会在沙箱环境中执行代码、读写文件。比如让 Agent 生成一个网页并预览：

const session = await agent.startSession({ userId: "user-1" });
session.send(
  "帮我写一个个人博客的首页，用 React + Tailwind CSS，然后部署到 CloudBase 上"
);

这样 Agent 就会自动在沙箱中创建文件、安装依赖、并且调用沙箱中内置的 CloudBase 密钥，将产物部署到云端，开发者无需管理和调度沙箱。

CloudBase 的 Sandbox 能力当前内测中，如果您有需求，欢迎联系我们。

我们自己是如何使用 OpenAgentKernel 的？​

目前 CloudBase 平台大部分的 AI 功能已经基于 OpenAgentKernel 构建，包括：

CloudBase Agent​

云开发控制台的 Agent 板块是基于 OpenAgentKernel 焕新的：新建 Agent 时选择官方 cloudbase-agent 模板，得到的就是一个 OpenAgentKernel 项目——会话持久化、MCP 工具、人工审批开箱即用，创建完成即可在「接入 & 调试」页直接对话。

需要深度定制时，「本地开发」页给出完整指引：tcb fn code download 把代码拉到本地，交给你的 AI 编程工具修改，改完 tcb fn deploy 一条命令部署回去。控制台负责托管、日志和调试入口，OpenAgentKernel 负责运行时。

Issue Agent​

CloudBase 社区（CNB）的 Issue Bot 是一个跑在流水线里的 OpenAgentKernel Agent。新 issue 进来后，它以「云开发工程师」的角色检索资料、给出有依据的答复。

它用到了 OpenAgentKernel 的三个能力：进程内 MCP server 提供受控工具，最终答复必须通过 reply 工具发布，从机制上保证"要么有据可查，要么明确标注推断"；skills 加载答疑经验（issue-agent-guide）；多模态附件让它能看懂用户贴的报错截图——截图先由一个视觉会话逐张识别，再进入主流程。

立刻使用 OpenAgentKernel​

npm install @cloudbase/open-agent-kernel@beta

你也可以访问下面的链接来查看代码：

• GitHub：https://github.com/TencentCloudBase/OpenAgentKernel
• CNB：https://cnb.cool/tencent/cloud/cloudbase/OpenAgentKernel

或者，直接打开 CloudBase 控制台（https://tcb.cloud.tencent.com/dev）的 Agent 板块，开始你的 Agent 开发之旅：

• npm：https://www.npmjs.com/package/@cloudbase/open-agent-kernel
• 源码与 README：https://github.com/TencentCloudBase/OpenAgentKernel
• Agent 开发文档：https://docs.cloudbase.net/ai/agent-development/

关注腾讯云开发，第一时间获取产品动态与最佳实践。

只需要在 ZCode 里装一个插件，就能用自然语言操作整座云开发后端，从建库、写函数、部署站点、管存储与认证，全程不用切回云控制台。

装上就能用​

下载打开 ZCode，进入左侧菜单「设置」→「插件」，切换到「开发者工具」分类，找到 cloudbase-skills（腾讯云 CloudBase 开发技能与 MCP 集成），点击右侧「安装」。

安装完成后回到 AI 对话，直接开工。几个可照抄的起手式：

• "用云开发做一个微信小程序点餐系统" —— 搭页面、建云数据库、写云函数并引导预览。
• "做一个预约管理系统，支持用户下单和后台改状态" —— 用 CloudBase PostgreSQL 建模、配权限、接前后端。
• "给 Web 应用加上手机号登录" —— 启用认证方式并接入 CloudBase SDK。

现在就开始​

CloudBase 插件对 ZCode 3.4.1 及以上版本开放，覆盖所有云开发环境。点击阅读原文，查看完整接入方案。

ZCode 下载地址：https://zcode.z.ai

这是装好 CloudBase 插件后的日常。Codex、Claude Code、WorkBuddy 均已原生支持 CloudBase Plugin：数据库、云函数、静态托管、AI 能力，全部变成对话里的一句话。

接入：一段 Prompt 的事​

推荐用 Prompt 方式，复制下面这段，粘贴进你的 AI IDE，回车：

帮我把 CloudBase 接好，按下面做：
1. 打开 https://docs.cloudbase.net/skill.md，按说明完成接入。
2. 接入完成后告诉我，并建议最相关的下一步。

AI 会自己完成安装与配置，结束时还会告诉你下一步该干什么。不会配？让它教你。配错了？让它修。

习惯命令行？一条命令​

npx plugins add TencentCloudBase/cloudbase-plugin -y --scope user

plugins CLI（兼容 Open Plugin Specification）会自动检测你本机装了哪些 AI 工具，全部一次装好。优先用这条路径，不要手写 MCP JSON。 检测结果可随时查看：

npx plugins targets

装完之后，AI 能帮你干什么​

插件把三件东西捆绑在一起：

• MCP Server——「查一下 users 集合有多少条数据」「把这个函数改成每分钟跑一次」，对话里直接执行
• Agent Skills——CloudBase 的开发最佳实践注入 Agent 技能库，它知道该怎么用云开发，而不是瞎猜
• Hooks——Skill 激活更稳定，不会时灵时不灵

相比单独装 Skills，插件多了 Hooks，激活更可靠——推荐所有接入都走插件。

支持这些 AI IDE​

另有 Sites 插件可选（npx plugins add TencentCloudBase/cloudbase-sites-plugin -y --scope user）。

完整文档：CloudBase AI 插件。

下一次部署，试试不打开控制台。

👉 续费路径：完成续费任务：0 元免费续 6 个月​

STEP 1：选择任一平台发布 CloudBase / 云开发相关内容：小红书、掘金、知乎、CSDN、B 站、X(Twitter)、V2EX、即刻

点击「去完成」→ 弹窗内选平台 → 下载素材包 → 复制推荐文案（多条模板可选），官方提供参考素材

STEP 2：发布后粘贴分享链接 + 上传截图

点「提交验证」→ 混元 AI 自动验证 → 通过后点「立即续费」

进入 0 元购买页，点击「立即购买」，即可续费成功

👉 升级路径：直接升级，4.9 元个人版首购特惠​

直接选「立即升级」，进入购买页，点击「立即购买」，即可升级成功

说明：本次首购升级特惠，仅享价格优惠，所有升级到个人版的环境，均不支持降配回体验版哦

同期还能参与有奖问卷活动，只需要 2 分钟，参与问卷的小伙伴可以参与抽奖，有随机资源点补贴惊喜！

留言区分享你对云开发 CloudBase 的使用感受和期待吧！

详细参考：https://cloud.tencent.com/developer/article/2715255

如果你的产品正在（或准备）服务东南亚用户，大概率遇到过这几件事：

• 服务器部署在国内，新加坡、马来西亚、印尼用户访问延迟明显，体验打折扣；
• 数据出境合规要求越来越细，"能不能把数据留在当地"成了绕不开的问题；
• 想快速验证出海业务，但又不想为了一个新地域重新搭一套账号体系、重新学一套云产品。

现在不用另起炉灶：云开发 CloudBase 国内站正式全量开放新加坡地域，开发者继续用国内站账号和控制台，就能就近部署后端服务到新加坡机房。

新加坡地域全量开放，专发 PostgreSQL​

国内站用户现在可以直接选择"新加坡"地域创建云开发环境，新加坡地域专属发货 PostgreSQL（PG）数据库环境。

1. 新加坡地域全量开放​

新加坡地域本次是移除白名单限制、面向全量用户开放。购买页的地域选择器直接选中"新加坡"选项，操作方式和上海地域完全一致，不需要额外申请、不需要切换到国际站。

2. 新加坡专发 PostgreSQL​

新加坡地域仅提供 PostgreSQL 数据库环境，暂不支持文档型数据库 / MySQL。

CloudBase for Supabase 版是云开发在 PostgreSQL 之上构建的 Serverless 后端云服务，和业内主流的 PG-first 后端思路一致（完全兼容 Supabase），把数据库、权限、鉴权、存储统一到同一套 SQL 语言体系里：

选择新加坡地域的 5 个实在好处​

1. 就近部署，东南亚访问更快​

数据中心物理落在新加坡，服务新马泰印尼等用户时，网络链路更短，接口响应更快，对实时性要求较高的场景（社交、电商、工具类 App）体验提升明显。

2. 数据不出境，合规更从容​

国内节点只加载国内站数据，新加坡地域按合规策略处理站点数据加载，从架构层面隔离，满足"数据本地化"、"区域合规"诉求。

3. 原账号直接用，不用注册国际站​

依然是国内站账号、国内站支付方式、国内站控制台，不需要注册国际站账号，不需要切换语言，选个地域就能获得海外节点。开发习惯、CLI 工具、SDK 用法基本不变。

4. 一套 SQL，管完数据、权限、账号、存储​

传统后端搭建，数据库、鉴权服务、文件存储往往是三套不同的系统、三套不同的权限语言，接入和维护成本不低。CloudBase for Supabase 版把这些统一收敛到 PostgreSQL 一套体系里：

• 业务数据怎么存 → 建表；
• 谁能读、谁能写 → GRANT + RLS Policy；
• 用户是谁 → auth schema 里的一张表；
• 文件权限怎么控制 → 还是 RLS Policy。

对开发者来说，掌握好 SQL，就能覆盖数据建模、权限设计、跨模块协作的绝大部分工作。

5. 零运维​

数据库实例的创建、高可用、备份都由平台托管，开发者不用管机器规格、扩缩容、打补丁；开通环境后即可直接建表写代码。

开通选择地域「新加坡」​

整个流程和你熟悉的云开发购买流程完全一致，多一步"选地域"而已：

Step 1：进入购买页，选择新加坡地域

打开云开发 CloudBase 购买页，在地域选择中选择「新加坡」——选定后，数据库类型会自动锁定为 PostgreSQL（新加坡地域不提供其他数据库类型的选项）

Step 2：完成套餐选购、下单支付

选择套餐版本（个人版 / 标准版 / 企业版），走标准下单支付，和选择上海地域一样。

Step 3：环境自动初始化

下单完成后，系统会自动完成：

1. 创建云开发环境；
2. 创建 PostgreSQL 数据库实例；
3. 初始化系统角色与默认权限；
4. 配置 API 服务网关。

整个过程通常在几分钟内完成，无需人工干预。

Step 4：进入控制台

环境创建完成后即可直接进入 PG 版控制台，使用数据库表管理、RLS 策略配置、连接信息查看、云函数、云存储、静态网站托管、身份认证等能力。

Step 5：代码接入，几行搞定

以 Web 前端为例，通过 SDK 直连数据库，权限由 RLS 自动完成校验：

import cloudbase from '@cloudbase/js-sdk';

const app = cloudbase.init({
  env: '<环境 ID>',
  accessKey: '<Publishable Key>',
});

const db = app.rdb();

const { data } = await db
  .from('todos')
  .select('id, title, is_completed')
  .eq('is_completed', false);

await db.from('todos').insert({ title: '写一篇出海文档' });

如果你不用前端 SDK，也可以直接用标准的 REST API（遵循 PostgREST 规范）接入任意语言、任意后端框架：

curl "https://<envId>.api.tcloudbasegateway.com/v1/rdb/rest/todos?is_completed=eq.false" \
  -H "Authorization: Bearer <Publishable Key>"

完整的建表、权限配置（GRANT + RLS）、进阶用法，可参考官方文档：PostgreSQL 数据库初始化指引

几个你可能会问到的问题​

Q：新加坡地域和上海地域可以并存吗？

可以。地域是环境级别的选择，一个账号下可以同时拥有上海地域环境和新加坡地域环境，按业务需要分别创建、独立管理、独立计费。

Q：新加坡地域以后会支持云数据库（MySQL/文档型数据库）吗？

当前阶段新加坡地域是 PG 专属地域，聚焦把 PostgreSQL 相关能力做深做透；后续如有其他数据库类型的规划会另行公告。

Q：已经在用上海地域 PG 环境，代码能直接迁移到新加坡地域吗？

可以。新加坡地域与上海地域共用同一套 PostgreSQL 技术栈、同一套 SDK 和 API 规范，业务代码基本无需改动，初始化时指向新环境的 env 即可。

Q：数据安全和隔离怎么保证？

新加坡地域与国内地域在网络层完全隔离，遵循平台既定的数据流隔离与合规策略，不存在国内节点访问境外数据、或反向访问的情况。

Q：新加坡地域不支持云托管，原来跑在云托管上的后端服务怎么办？

新加坡地域目前暂不提供云托管服务，但标准云函数（含 HTTP 触发）完整可用，建议将轻量后端逻辑改为 Web 云函数承载，即通过 HTTP 网关把云函数暴露为标准 REST 接口。相比云托管，Web 云函数在新加坡地域场景下有几点明显优势：

• 免运维，零容器管理：不需要构建镜像、配置实例规格，写完代码直接上传即可运行；
• 按量计费，空闲零成本：按调用次数 + 资源使用时长计费，没有请求时不产生费用，不需要为了避免冷启动而保留常驻实例；
• 弹性伸缩更省心：平台按并发自动扩缩容，还可用预置并发进一步降低冷启动影响；
• 与 PG 数据库无缝联动：云函数可直接读写同环境下的 PostgreSQL 数据库、复用 RLS 权限体系，做数据校验、第三方集成、定时任务等复杂逻辑时无需额外打通网络。

需要注意的是，如果业务依赖长连接（WebSocket/SSE）、需要常驻进程或完整 Web 框架级的路由中间件，云函数并非云托管的全能替代，这类场景建议关注后续云托管在新加坡地域的开放计划。

结语​

出海不再需要"先搭一整套海外基础设施"才能起步。选一个地域、走一遍熟悉的购买流程，几分钟后你就拥有了一个部署在新加坡、开箱即用的 Serverless PostgreSQL 后端。

如果你的业务正准备（或已经在）触达东南亚用户，现在是一个很好的时机，去控制台看看新加坡地域，点击阅读原文直达购买页，直接动手建第一张表。

了解更多：

• PostgreSQL 数据库初始化文档：https://docs.cloudbase.net/database/configuration/db/postgresql/initialization

这篇教程手把手带你：自定义域名和 ICP 备案、备案到验证怎么一步步配通。

入口下沉：静态托管、云函数、云托管都能绑​

云开发 CloudBase 这次把域名绑定做到了静态托管、云函数、云托管三种资源各有一个入口，绑完不用再跳来跳去。HTTP 网关也支持统一查看所有绑定关系。

几种模式按需选：静态托管有「应用模式」一域名对一站点和「路径模式」同域名下挂多资源；云函数和云托管绑定时填个「触发路径」就行。

接入方式类型三选一（静态托管推荐云开发 CDN，接口类一般不选）。

生产更稳、品牌更统一，备案还能免一台服务器​

默认域名只够测试，自有域名才适合生产​

默认域名（如 xxx.tcloudbaseapp.com）官方建议只用于测试。对外业务绑上自有域名后，品牌更统一、搜索引擎收录更稳、分享链接点击率也更高。

另外两个实用场景：一个 CloudBase 环境跑多个站点（官网、博客、活动页），用不同自定义域名区分；云函数 / 云托管对外暴露 API 时，用品牌域名 + 自定义路径比抛默认域名干净得多。

备案不是走过场：云开发环境就能办​

面向中国大陆访问的自定义域名，必须已完成 ICP 备案，否则在云开发里绑不上、也访问不通。对开发者来说，备案的价值不只是「合规」：

• CloudBase 环境支持备案：不用为了备案额外买一台服务器。省一笔开支，也少维护一套机器。
• 备案是域名能绑、能访问的前提：拿到备案号后，域名才能在 CloudBase 里正常绑定并对外服务。
• 一个环境最多可备案 2 个网站：一个符合条件的环境能申请多个网站的备案服务码，多站点场景够用。
• 别家已备案的域名要「转入」：如果域名已在其它服务商备过案，不能直接绑到 CloudBase，系统会拦截或提示未备案。需要先办「新增接入备案（备案转入）」，把备案信息接入腾讯云后才能正常绑定。

从备案到上线：三步把自定义域名配通​

前置条件一：ICP 备案​

在 CloudBase 里完成备案，需同时满足三个准入条件：

• 套餐版本：个人版及以上（免费体验环境不支持备案）
• 剩余有效期：云环境剩余有效期 > 6 个月
• 固定 IP：该环境已开启「云托管固定 IP」

满足条件后，在控制台进入对应环境的「备案管理」页，点「去备案」，系统会引导到腾讯云备案控制台拉取该环境并提交申请。

管局审核通常 1–20 个工作日，通过后拿到备案号。

前置条件二：SSL 证书​

准备一份 SSL 证书，在 SSL 证书控制台上传，绑定域名时选它来开启 HTTPS。

整体流程三阶段​

整个过程分三步：先在控制台把域名加进来 → 再去 DNS 服务商做一条解析 → 最后回来验证生效。

下面以最常见的「静态托管 + 应用模式 + 云开发 CDN」为例，绑一个官网域名 www.your-brand.com。

阶段一：控制台里添加域名​

第一步 · 确认前置：动手前先备齐三样：域名已完成 ICP 备案（还没备案的，先按上节在云开发里办备案）；SSL 证书已上传；云开发环境里静态托管已建好并上传了站点文件。

第二步 · 进到静态托管详情页：云开发控制台 → 选择目标环境 → 左侧菜单「静态网站托管」→ 点进应用部署列表，点进应用名称，打开详情页。

第三步 · 打开自定义域名入口：在详情页里找到「自定义域名」（tab 或按钮），点「添加自定义域名」。

第四步 · 填写四项配置：填完提交。此处仅演示云开发 CDN 教程，如需查看自定义 CDN 配置流程，点击「阅读原文」。

第五步 · 等关联，复制 CNAME 值：提交后平台需要 3–5 分钟完成域名关联。关联成功后，控制台会给出一条 CNAME 记录值（如 xxx.tcloudbaseapp.com），点「复制」，这一步是整条流程的关键，下一阶段就靠它。

阶段二：去 DNS 服务商加一条解析​

第六步 · 添加 CNAME 记录：登录域名所在的 DNS 服务商（如 DNSPod 等），进入该域名的解析页，点「添加记录」。

最常见的坑：同一条主机记录下，CNAME 与其它记录类型（A、TXT 等）会冲突。如果保存时提示「记录有冲突」，先把该主机记录下已有的其它记录删掉，再加 CNAME。

阶段三：验证生效​

第七步 · 确认解析生效：DNS 通常 5–30 分钟生效。可以用命令自查：

nslookup 你的自定义域名

返回结果里出现 CloudBase 提供的 CNAME 域名，就说明解析生效了。

第八步 · 回控制台看状态、浏览器验证：回到云开发控制台，等该域名状态变为「正常 / 已生效」（没更新就刷新页面）。然后浏览器打开 https://www.your-brand.com，能看到站点、且是 HTTPS，即绑定成功。

云函数 / 云托管怎么绑​

流程和上面一模一样（控制台加域名 → DNS 加 CNAME → 验证），只有两处不同：

• 多填一个触发路径：绑定时除了域名，还要填触发路径。云函数常填 /api 或 /，云托管按服务路由填。同一个函数 / 服务可以绑多个域名，各走不同路径。
• CDN 一般选「不使用」：接口类服务通常不需要 CDN 加速，选「不使用 CDN」即可（有静态资源加速需求再选云开发 CDN）。

入口：

• 云函数 → 函数管理 → 云函数列表 → 函数详情页 → 自定义域名
• 云托管 → 服务管理 → 服务列表 → 服务详情页 → 自定义域名

多域名管理与解绑​

同一资源绑多个域名时，列表展示更清晰，支持一键复制 CNAME、跳解析、解绑。

要统一看所有绑定关系，去 HTTP 网关 → 域名关联资源即可。HTTP 网关关联静态托管资源支持双形态（应用/文件）。

每个环境最多 50 个自定义域名（企业版最高），注意额度。

结语​

云开发 CloudBase 已经将自定义域名链路压缩到三步：云环境备案、控制台加域名，回来验证即可生效。

还没把站点挂上自有域名的开发者，欢迎体验。大家在配置过程中卡在什么环节、或者还想让 CloudBase 在域名这块补什么能力，都欢迎在评论区分享开聊。

为什么值得用​

• ⚡ 快：一行命令拉取云函数 / 数据库 / 云托管等 12 类资源的实时指标，告别控制台层层点选。
• 🤖 可编排：命令可直接写进脚本、定时巡检、CI 流水线，异常自动播报。
• 🛡️ 有兜底：指标越界自动告警，质量风险主动触达，不再被动等用户投诉。

1. 监控查询（tcb monitor）—— 一眼看清资源健康度​

统一入口覆盖云函数 / 数据库 / MySQL / 云托管 / 静态托管 / 认证 / 大模型 / 知识库 / 网关 / 登录 / DB Connector / 环境 QPS 共 12 类资源。

典型场景

• 🔍 排障：函数报错、耗时突增？一键拉出错误数与时延曲线。
• 📊 巡检 / 周报：--json 输出直接喂给脚本，自动生成资源水位报表。
• ⏱️ 时间自由：--last 7d / --last 24h 任意回看，指标名精准指定。

# 查看某函数最近 7 天的错误数
tcb monitor function --name helloWorld --metric-name FunctionError --last 7d

# 查看最近 24 小时耗时，结构化输出给脚本消费
tcb monitor function --name helloWorld --metric-name FunctionDuration --last 24h --json

常用参数：

• 相对时间窗口：--last 7d / --last 24h
• 精准指标：--metric-name FunctionError
• 结构化输出：--json（便于脚本消费）
• 指标清单：tcb monitor schema <资源类型>

2. 告警配置（tcb api monitor）—— 让风险主动找你​

场景：函数报错即告警。 当任意云函数版本出现错误，立即推送通知到企微 / 邮件 / 短信，线上质量有兜底。

tcb api monitor CreateAlarmPolicy --api-version 2018-07-24 --body '{
  "Module": "monitor",
  "PolicyName": "云函数版本错误数告警",
  "MonitorType": "MT_QCE",
  "Namespace": "SCF",
  "ProjectId": 0,
  "Enable": 1,
  "Condition": {
    "IsUnionRule": 1,
    "Rules": [
      { "MetricName": "Error", "Period": 60, "Operator": "gt",
        "Value": "0", "ContinuePeriod": 1, "NoticeFrequency": 3600, "IsPowerNotice": 0 }
    ]
  },
  "NoticeIds": ["notice-xxxxxxxx"]
}'

要点：

• 创建即覆盖该命名空间下所有函数版本，无需逐个绑定。
• 返回 PolicyId，可用于后续删除或精确绑定到指定实例。
• NoticeIds 为通知模板 ID，不需要可删除该行。

3. 升级到支持版本​

npm i -g @cloudbase/cli@latest
tcb -v   # 确认 ≥ 3.5.8

参考文档​

• 监控：https://docs.cloudbase.net/cli-v1/monitor/management
• 告警：https://docs.cloudbase.net/cli-v1/monitor/alert
• 可观测平台 API：https://cloud.tencent.com/document/api/248/87588

在 WAIC 2026 上，腾讯云 CloudBase 产品负责人王伟嘉分享了一个判断：Agent 时代，云的价值不只是提供资源，更要成为一条适合 Agent 工作的软件生产线。

过去，云主要服务职业开发者。写代码、配环境、接数据库、做部署、排查故障，每一步都依赖人工推进。

今天，越来越多"超级个体"正在出现：他们不必亲自完成每一项工程操作，而是定义目标、调度 Agent，并借助一套云基础设施将想法变成真正可运行、可交付的应用。

这意味着，云需要被重新设计。

软件生产者变了，基础设施也要变​

从 Lovable、Vercel v0 到 Replit Agent，Vibe Coding 已经从技术演示走向规模化产品。

但这场竞争的关键，早已不只是"谁能生成更漂亮的页面"或"谁的代码生成得更快"。真正的挑战在于，Agent 能否把代码、数据、身份、存储、部署、运维等能力完整串联起来，交付一个真实可用的应用。

代码生成越来越快，真实系统的集成却仍然复杂。

数据库如何创建？认证如何接入？文件如何存储？权限怎样配置？发布失败后如何定位和回滚？这些能力过去大多是为人设计的：通过控制台操作、阅读文档理解、根据模糊报错排查。

对 Agent 而言，这些环节会形成大量"基础设施噪声"。

因此，AI 编程的下半场，不只是让 Agent 更聪明，而是让它的工作环境更清晰、更可读、更可执行、更可验证。

从 Prompt 到 Loop：让 Agent 真正进入生产​

让 Agent 完成一次代码生成并不难，让它在真实生产环境中稳定完成任务，才是更大的工程挑战。

这需要从四个层面理解 Agent 工程：

• Prompt Engineering：解决"怎么问"；
• Context Engineering：解决"让 Agent 知道什么"；
• Harness Engineering：解决"如何约束 Agent"；
• Loop Engineering：解决"如何让 Agent 持续自主运转"。

其中，Loop Engineering 让任务形成完整闭环：触发、目标、行动、验证、记忆。Agent 不再只回答问题，而是围绕目标持续推进，并根据环境反馈不断修正。

Harness Engineering 则为这一循环加上生产级护栏：架构边界、最小权限、测试、类型检查、CI、日志审计，以及必要的人工审批。

两者共同指向一个原则：Agent 的每一次行动，都应当在真实运行环境中获得反馈，并基于反馈继续迭代。

Agent 时代，需要一朵 AI-Native 云​

传统云平台的核心交互对象是人：控制台给人操作，文档给人阅读，报错给人排查。

而 AI-Native 云的核心交互对象是 Agent。它需要提供的是标准化工具调用、结构化上下文、机器可读错误、安全沙箱、Serverless 资源和可观测反馈。

换句话说，云正在从"人机界面"，变成 Agent 的工作环境。

对于 Agent 来说，一朵合适的云应当具备四种特征：

• 可读：让 Agent 理解资源、配置、权限与状态；
• 可执行：让 Agent 通过标准工具完成云上操作；
• 可验证：让 Agent 能够检查结果、定位问题、持续修正；
• 可控：通过沙箱、权限和审计机制，让自动化在边界内运行。

CloudBase：让云能力成为 Agent 的语言​

围绕 AI-Native 云，CloudBase 正在将 Serverless、BaaS、托管、多租户、权限和计费等能力，重新组织为更适合 Agent 调用的基础设施。

面向开发者，CloudBase 通过 MCP、Skills 和 Plugins，降低 Agent 操作云资源的门槛。

CloudBase MCP 将数据库、认证、存储、云函数、日志、域名、安全、部署与回滚等能力，封装为可通过标准协议调用的工具。Agent 可以直接理解并操作云能力，而不必在复杂的控制台流程中反复切换。

CloudBase Skills 则将小程序开发、身份认证、微信支付、数据库调用、云函数编写、LLM 编排与权限管控等实践，沉淀为 Agent 可调用的领域知识。

再通过 Claude Code、Codex 等编码环境中的 Plugins，开发者可以在日常工作流中直接使用这些能力。

目标很明确：缩短 Agent 的执行闭环，减少无效工具调用和 Token 消耗，让 Agent 将注意力从运维细节重新放回业务目标。

在一组生成并部署 Todo 应用的对照测试中，相比传统 VM 方式，CloudBase 将完成时长从 990 秒缩短至 260 秒，工具调用从 79 次减少至 36 次，Token 消耗降低 52%。同时，安全暴露面从 SSH 收敛为 HTTPS API。

基础设施适配 Agent，带来的不只是更快的交付速度，更是更短、更稳定、更安全的生产闭环。

从开发者效率，到 Vibe Coding 平台能力​

Agent 时代的挑战，也不仅属于单个开发者。

当一个 Vibe Coding 平台面向大量用户提供"生成应用"能力时，多租户隔离、权限管理、资源配额、生命周期、成本核算与运行安全，都会成为平台能否规模化的基础问题。

如果这些能力完全由应用层临时拼接，平台很快会陷入复杂度和成本失控。

CloudBase 的思路，是将这些能力下沉至基础设施层：

• 为每个用户或项目提供独立环境；
• 通过 Sandbox 隔离控制面与运行环境；
• 以 Serverless 支持弹性扩缩与按量计费；
• 在租户维度完成资源配额、成本核算、运行监控、备份与销毁。

这让"用户生成应用"不再只是一次性的代码输出，而能成为可隔离、可运营、可计费、可持续演进的云资源。

在 CloudBase 上，已经长出这样一批产品：腾讯吐司让用户通过一句话生成可安装的 App；WorkBuddy 面向产品经理、创业者与独立开发者，帮助用户生成可交付的全栈项目。它们表面上是不同的产品，本质上都在推动同一件事：让一个人可以调度 Agent 和云基础设施，完成过去需要一个小团队协作才能完成的软件生产流程。

云正在成为 Agent 的生产线​

电力革命带来的最大变化，不只是把蒸汽机换成电动机，而是围绕电力重新设计了整条生产线。

AI 也是如此。

如果只是把 Agent 放进传统的云控制台和运维流程中，效率提升很容易被环境噪声抵消。真正的机会，在于按照 Agent 的工作方式重构云：让工具可调用、上下文可理解、权限可控制、结果可验证、资源可弹性供给。

未来，云将不再只是工程师租用资源的平台。

它会成为 Agent 生成、运行、验证、发布和维护软件的生产线。

而"超级个体"的意义，也不在于一个人包揽所有工作，而在于一个人能够调度一组 Agent 和一整套云基础设施，将自己的想法快速转化为真实世界中的产品与服务。

为超级个体重新设计云，就是为 Agent 时代重新设计软件生产力。

想让 Agent 替你跑完这条生产线？点击阅读原文即刻开始。

Kimi K3 + CloudBase 适合做什么​

Kimi K3 在 Code Arena 前端编程盲测中拿到全球第一（1679 分，压过 Claude Fable 5 和 GPT-5.6 Sol），原生支持视觉理解，百万上下文。

Kimi K3 擅长前端编程和交互应用，具备长程编码能力，可持续完成长时间工作任务，理解和处理大型代码库。也支持结合截图和视觉反馈进行任务迭代，适用于前端、游戏开发等需要视觉理解和代码协同的场景。

依托上下文与 Agent 能力，Kimi K3 + CloudBase 在行业研究、科研分析、资料处理和可视化表达的任务中，支持从大量网页、PDF、论文和数据材料中进行信息整合，并生成报告、图表和交互式内容。

这些应用的后端，数据库、云函数、云存储都在同一份套餐里，不用切换平台。

不只 Kimi K3​

CloudBase AI 模型，目前已支持：

• Kimi 系列：K3、Kimi-K2.7-code、Kimi-K2.7-code-highspeed
• GLM 系列：GLM 5.2、GLM 5.1、GLM-5、GLM-5-Turbo
• DeepSeek：V4-Pro、V4-Flash
• MiniMax：M3、M2.7、M2.5
• 混元系列：Hy3、Hy3 preview
• Qwen3.5：qwen3.5-flash、qwen3.5-plus

模型定价和原厂统一，调用方式一致，切模型只改一个参数，不用换 SDK、不用切凭证。完整价目点击阅读原文，查看资源点价格文档。

三种姿势用 Kimi K3​

1. 装进开发者正在用的 AI 工具​

复制 Base URL 和 API Key，把模型直接装到 WorkBuddy、CodeBuddy、Cursor 等任意 AI Coding 工具里。当成普通 OpenAI 兼容模型用就行，扣费在 CloudBase 后台走资源点池，不影响工具里现有的配置。

2. 在开发者的全栈应用里直接调​

如果在做小程序、Web、公众号或客服机器人，把 K3 当作云开发能力来调——SDK 几行代码就能拿到流式输出，不用单独搭后端。

const model = wx.cloud.extend.AI.createModel("cloudbase");
const res = await model.streamText({
  model: "kimi-k3", // 以控制台实际模型 ID 为准
  messages: [{ role: "user", content: "你好" }],
});

数据库、云函数、域名、Token 都在同一份套餐里，写完代码可以直接上线。

3. 用 CloudBase MCP 让 AI 工具直接调 K3​

用的 AI 编码工具要是原生支持 MCP（Codex、Workbuddy、Codebuddy、Cursor、Claude 等），不用复制 Base URL 和 API Key，配一下 CloudBase MCP 就接上了。工具直接拿到 CloudBase 的调用能力，K3 在会话里就能调。

在项目的 MCP 配置文件里加一段（以 Cursor 为例，文件是 .cursor/mcp.json）：

{
  "mcpServers": {
    "cloudbase": {
      "command": "npx",
      "args": ["@cloudbase/cloudbase-mcp@latest"]
    }
  }
}

数据库、云函数、域名、Token 都在同一份套餐里，写完代码可以直接上线。

怎么开始​

1. 进云开发控制台 → 套餐用量页，确认套餐是标准版或企业版
2. 进 AI 控制台 → 生文模型 启用 Kimi K3
3. 复制 Base URL 和 API Key 装进 AI 开发工具，或者直接用 SDK 在应用里调用

一句话总结​

开发小程序，一个 CloudBase 套餐就够了。

• 带云资源的 Token Plan，写完代码可以直接上线，不用再切平台
• K3、GLM 5.2、DeepSeek、Qwen 全在一个池子，切模型只改一个参数
• 开发者只管调，不用自己部署

美亚风鸟专注于企业数据查询与分析服务，业务模式类似企查查、天眼查。凭借"注册即送 5 年 SVIP"差异化策略，正快速积累用户、拓展市场。但对于这样一个团队来说，要在竞争激烈的企业数据赛道持续提升产品能力、服务质量和市场覆盖，仅依靠增加人力并不是最优解。

过去半年，AI 部门负责人 Andy，一直在公司推动一个目标：借助 AI，让每一位员工都拥有"一个人即一家公司的产能"。

"我们做的是 OPC，One Person Company。这个目标越来越有可能了。" —— Andy，上海美亚风鸟 AI 部门负责人

过去公司里很多事情因为生产工具限制被搁置​

风鸟的业务里有很大一块是数据爬取与入库。产品经理判断"我们需要这些数据"，然后找爬虫工程师提需求，工程师排期、写爬虫、入库、上架。一个完整链路下来，从需求到能用，往往是几周。

工程师时间有限，能排上去的是产品主线需求。排不上的是那些"也想要、但没那么紧急"的长尾。HR 想做一次团建投票，过去用问卷星凑合。业务同事想看一眼竞争对手的某个公开数据，过去只能写需求等着。

"原来产品经理他基本只能提需求，他是做不了里面细节的。说白了，会写代码的人才能把一个想法变成一个能跑的东西。公司里其余 80% 的人，无论想法多清晰，都得排队等那 20% 的人。"

Andy 推 AI Native，最早盯上的就是这件事。

产品经理打开 CodeBuddy，连上 CloudBase 自己跑​

来看一个真实的协作流程。

• 过去：产品经理说"我要这个网站这些字段的数据"，爬虫工程师接需求，开发，入库，再回到产品。
• 现在：产品经理打开 CodeBuddy（腾讯的 AI 编码工具），连上一台 CloudBase，直接告诉 AI："我要去这个网站爬这些数据，入库到这个地方。"AI 写代码、运行、把数据落到指定位置。产品经理全程不写一行代码。

这套组合 Andy 用得最熟，他给团队推荐的标准开发链路是：

• AI 编码工具：CodeBuddy（也支持 Codex / Claude Code，Andy 自己偏向用国产工具）
• 配套接入方式：MCP 或 Skill，AI 编码工具通过标准协议直接调用 CloudBase 的能力
• 承接后端 / 算力：CloudBase 提供静态托管、对象存储

CloudBase 在这套组合里干两件事。

给 AI 一个"安全的物理隔离环境"​

"你要考虑到你用 AI 开发的时候，AI 是会有不确定性的。它很聪明很灵活，如果放在生产环境去搞，很容易就造成灾难。让 AI 在安全的环境上做，它怎么搞都不会破坏掉成果。"

把整台 CloudBase 交给 AI。AI 在里面装环境、跑命令、写代码、调试，干任何事。开发完成后，把整个环境打包成一个 docker 镜像，再迁移到生产环境（CloudBase 自己的镜像服务，或公司其他主机的容器）。

Andy 把这种用法形容成"AI 开发的隔离物理机"。它解决了 AI 编码当下最棘手的一件事：AI 的不确定性 vs 生产环境的稳定性。这是他自己摸出来的用法，没有现成的教程。

让做完的东西立刻能用起来​

最早 Andy 试 CloudBase 的第一个项目，就是把开发完的应用直接托管到静态网站托管上，给一个公网链接，公司里所有人都能访问。

"做完直接托管到 CloudBase 上，直接通过一个公网的链接就可以访问。"

开发和部署是连续的，没有"找运维同事帮忙发布"这一步。

不到一个月，团队跑出了 10 个左右的内部应用​

这套组合在风鸟跑通的速度比 Andy 自己预期的快。

第一批先做的是问卷类、投票类的轻应用。HR 部门要做一次团建投票，过去用问卷星凑合，现在直接做一个属于公司自己的小网站托管出去。

接下来是数据采集类。业务同事自己跟 AI 说"去爬哪个网站的什么数据，入库到哪里"，CloudBase 上跑爬虫。

再后面是一些 POC，把 AI 写出来的 demo 直接托管到 CloudBase，给内部团队验证。

"现在差不多有 10 个了，因为我们事情本来就多。因为你用 AI 开发的话其实都很快的。"

10 个应用一个月内做出来。这个数字背后，是公司里第一次有非技术岗位的同事，能够独立交付一个可访问、可用的内部应用。

更具体一些看协同链路的变化：

• 过去：所有内部需求 → 找研发 → 排期 → 等 → 上线
• 现在：每个人都能用 AI 编码工具 + CloudBase 自己做需求 → 自己上线

研发同事从"瓶颈位"被解放出来，去做架构、模型、AI 框架本身。长尾需求被消化掉，主线需求得到了更多研发资源。

风鸟是一家中小公司，没有大厂的 AI 中台投入，没有专门的 AI 工具部门。Andy 和几个同事，用了不到半年把这条路走通了。这件事没有现成教程，他们是在一条没人走过的路上先踩了脚印。

如果要给这种"一个人独立交付一个应用"的能力起个名字，叫 OPT（One Person Team） 也合适。一个人就是一支小队伍，AI 编码工具是键盘，CloudBase 是后端的脚手架，做出来的东西直接托管出去，团队里其他人打开链接就能用。这是过去 To B 公司里业务岗做不到的事，现在做得到。

OPT 是能力单元。再往上一层看，Andy 推的 OPC（One Person Company） 其实是把公司里所有这些 OPT 串起来：每个人都能独立交付价值，公司就接近"每个员工都是一家公司"的形态。

Andy 的经验分享​

Andy 推 AI Native 这半年，沉淀了几条朴素的判断。

AI Native 的关键，是非技术团队能不能用上​

"我自己的架构运营能力是 OK 的。但现在走 AI Native，最重要的反而不是技术团队的人会不会，我们希望把它普及到公司所有人，特别是那些非技术的同事。"

技术团队会用 AI，本来就是基础动作。让非技术同事也能用 AI 直接产出业务价值，才是真正的转折点。

CloudBase 也适合推荐给非技术岗​

"我个人认为，CloudBase 最大的用户群体不是那些专门搞技术或者 AI 的。因为我有 N 台机器或者 N 台资源，我可能已经建立了一套惯用的资源使用方式，对我来说用什么都一样。但对很多非技术、或者他没有这么多资源的人来讲，CloudBase 也许是它一个唯一的渠道。"

技术人员有自己一套使用云资源的习惯，CloudBase 对他们是可选项。但对一个 HR、一个产品经理、一个业务同事来说，让他自己去注册腾讯云账号、搞 SSH 密钥、装环境、配防火墙，一道门槛就把他拦在外面。CloudBase 把这些事抹平到"AI 直接帮你弄好了，你拿到一个公网链接"，这才是它对一家公司最大的价值。

架构自己设计，代码让 AI 写​

"我个人更愿意用国产的这些工具，包括 CodeBuddy 也好。我是做了一些架构设计的，模型能力差距都不大，架构设计成功，那这些工具就一定能工作得好。如果用 Codex 或者用 Claude，你会更多依赖于别人帮你设计好的，从长远来看是不利的。"

模型能力差距正在快速收敛，工具本身已经不是变量。变量是架构是不是你自己设计的。架构是你的，工具就是顺手的工具，无所谓是谁家的。

OPC 这件事，分两步走​

"短期内会先把流程嵌到现有的体系里面，无法做到 100% OPC，只能覆盖一部分流程。可能几个月之后我们能做到 50% 的 OPC，就不需要人管，都是 AI 在搞的程度。将来要做 100%，我觉得最大的点是不能用旧的框架，得要用新的框架完全做一套，然后再把旧的东西往里灌。"

第一步，把 AI 嵌入现有流程，做到 50% OPC，公司里一半的流程不再需要人手动跟进。第二步，重新设计一个为 AI 而生的新框架，把现有资源全部往新框架迁移，做到 100% OPC。

"我们现在大概在 15%，准备做更多，未来几个月最大的点是把 OPC 的比例提高到 50% 左右。"

从 15% 到 50% 再到 100%，不是 PPT 上的数字，是 Andy 给团队排的真时间表。这是风鸟团队给自己的 AI Native 路线图。

风鸟的实践，对什么样的人有意义​

• 如果你是公司里的业务、产品、运营、HR：你大概有过这种感觉——心里很清楚一个内部工具该长什么样，但你没办法把它做出来，研发排期永远不是你想要的速度。
• 如果你是技术负责人或老板：你大概算过一笔账——研发资源是公司里最贵的成本之一，把它消耗在长尾内部需求上是浪费。当公司里的非技术同事可以自己用 AI + CloudBase 把内部应用做出来，研发资源就被解放出来去做真正核心的事。
• 如果你关注 AI Native、OPC/OPT 这些话题：风鸟做的事很多中小公司现在也可以参考。OPC 也可以发生在一家中小公司组织内部。从 OPT（One Person Team）到 OPC（One Person Company），是一个从"能力单元"到"组织形态"的递进。

一家公司真正进入 AI Native，看的是有没有让公司里的每一个人都接近 OPT 与 OPC 的状态。

组织上的难，比技术上的难更值得说一下​

跟 Andy 聊完，他反复回到一个点上。

技术上的事其实不复杂，半年就能跑通。难的是组织。难在愿不愿意改变同事的工作习惯，愿不愿意承担短期效率下降的代价，去换一个长期更好的形态。

"前期肯定是慢的，后续用起来的话，可能就会创建环境也就几分钟的时间就会很快。推广要有时间，要逐步说服别人，改变他的工作习惯。"

愿意花一两个月去说服同事改变习惯，愿意把 AI Native 真正做成全公司的事，这是小型公司里很少见的一种推进方式。

CloudBase 在他们的故事里是隐形的角色。开发的时候它是 AI 的物理隔离机，做完的时候它是公网链接，没人用了它就被回收。它在台后，每一步都在。

写在最后：CloudBase 的一种企业用法​

风鸟是 CloudBase 的企业版用户。CodeBuddy + 静态托管 + Docker 镜像迁移这套链路，是 Andy 和团队自己一边做一边总结出来的，没有教程、没有方案咨询，把 CloudBase 的标准能力按自己的需求拼了起来。

这是 CloudBase 在企业里的一种用法。今天就能起步，最小路径只需要一个 AI 编码工具账号，一个 CloudBase 环境。

🔗 现在就试 CloudBase：https://tcb.cloud.tencent.com/

如果你已经在实践的路上了，也欢迎向我们投稿分享！

什么是云开发 CloudBase

腾讯云 CloudBase（云开发）是腾讯云面向 AI 时代的全栈一体化后端基础设施，提供云函数、云数据库、对象存储、静态托管、AI 模型托管等核心能力，配合 CodeBuddy / Codex / Claude Code 等 AI 编码工具的 Skill 与 MCP 协议，让业务岗、产品、研发都能直接接住业务需求。

10 亿 Token、10 万张图，意味着你可以放心地把 AI 能力「用厚」在产品里，不必再盯着用量条算账。资源包自申请成功之日起 6 个月有效。

报名依然全行业开放​

延续此前承诺，好创意不被类目限制，全行业开发者皆可申请。

报名入口：微信公众平台 → 行业能力 → 小程序成长计划

没有云开发环境的可免费获得 6 个月个人版环境，已有环境的自动升级或领取 120 元代金券，均附赠 AI 资源包。

三步开始使用​

第 1 步 · 开通 CloudBase 环境。 访问 CloudBase 官网注册，创建首个个人版环境，同步报名微信 AI 小程序成长计划，Token 与生图额度自动到账。

第 2 步 · 启用大模型。 进入 CloudBase 控制台 → AI → 生文模型，勾选 Hy3 preview 或其他所需模型，即刻可调用。

第 3 步 · 生成第一个小程序。 使用微信开发者工具 → 云开发 → AI 助手，或通过 CloudBase MCP/Skill 在 AI 编程工具中用自然语言生成完整小程序代码，几分钟内完成部署。

常见问题​

Q1：在哪里查看 AI 资源包的用量？ 小程序扫码登录 CloudBase Web 控制台，或最新版微信开发者工具的「云开发 → AI」模块可查。用量达 80%、90%、100% 时通过微信公众号消息提醒。

Q2：AI 资源包用完后如何处理？ 可切换为 CloudBase 资源点套餐，套餐内资源点直接抵扣大模型 Token 用量。详细规则参见 CloudBase 文档「接入大模型 - 资源点套餐」。

Q3：怎么用自然语言开发小程序？ 配置一次 CloudBase MCP/Skill（在 CodeBuddy、Cursor、Codex 等工具中填入 CloudBase Base URL 和 API Key），后续通过自然语言描述需求即可生成完整小程序代码并部署。

Q4：小游戏开发者能用这些资源包吗？ 可以。享受与小程序开发者同等的 CloudBase AI 资源包支持。入口：MP 后台 → 功能 → 游戏能力地图 → AI 成长计划。

Q5：大模型 API Key 在哪获取？ CloudBase 控制台 → 环境配置 → API Key。Base URL 为 https://<ENV_ID>.api.tcloudbasegateway.com/v1/ai/cloudbase，兼容 OpenAI 协议。

Q6：个体工商户能开发 AI 小程序吗？ 可以。持有营业执照的个体工商户可申请添加「深度合成」类目，CloudBase 提供相应算法资质，配合微信官方文档提交即可。

访问 CloudBase 官网注册环境，报名微信 AI 小程序成长计划，即可获得完整资源，开始 6 个月的开发周期。

我用 Cursor 一句话做完了一个待办小程序。全程没打开微信开发者工具，也没打开云开发控制台。

先说个背景，方便你判断这篇跟你有关系没。

2026 年开发工具圈有个明显的风向：大厂都在把自家能力"开放给 AI Agent"。GitHub 推了 Copilot Extensions，Vercel 和 Supabase 先后开放了 MCP，连数据库都在争当 Agent 的"手和脚"。这个月，微信开发者工具也跟上了——而且它给 Agent 的不只是代码补全，是整套小程序的"驾驶舱"。

这篇大概 6 分钟。如果你做小程序，或者正打算做，建议看到最后一段。

一、先做小程序的人，回忆一下你昨天的开发节奏​

AI 写了一段代码 → 你切到微信开发者工具 → 点编译 → 看模拟器 → 复制报错 → 切回 AI → 粘贴 → AI 改 → 再切回去……

一个功能调下来，窗口切了二三十次。

问题不在 AI 笨。你的 Agent 能读写代码、能跑命令，但它看不见开发者工具里的"世界"：编译成不成功、页面渲染成啥样、Console 报了什么错、云函数到底部署上没有。

就像一个顶级厨师，菜谱背得滚瓜烂熟，但看不见锅、闻不到味、尝不了咸淡——只能凭想象做菜，你在旁边一遍遍替它试吃。这叫"蒙眼编程"。

效率全耗在切换上，不在写代码上。

二、微信开发者工具把"驾驶舱"交给了 Agent​

最近微信开发者工具干了件事：给开发者的编程 Agent 开放了一套可操作、可调试、可验证的小程序 Skills。

翻译一下：你的 Agent 现在能自己在开发者工具里完成整个开发流程——打开项目、读状态、调配置、编译、操作模拟器、读日志、定位问题、预览上传、管云开发资源。

以前 AI 只能帮你写代码，现在它能自己验证代码对不对。这个差别，是所有后续故事的前提。

对照一下就清楚了：

三、场景一：一句话，Agent 自己建库、部函数、真机预览​

我试了个最朴素的场景：在 Cursor 里打了一句"做个待办小程序，数据存 CloudBase，能真机预览"。

然后就看着它自己跑完了全程：建数据库集合、写云函数、通过 CloudBase 部署、调起模拟器截图验证、最后推真机预览到手机。

我中途只做了一件事——在弹窗里点了个"允许"。

重点不是"AI 写了代码"，而是"AI 自己验证了代码落地了"。建库、部署、验证、预览，这条链路以前最少要你手动点五六个地方，现在它在你熟悉的编辑器里一口气跑完了。

也是在这步，CloudBase 自然进了故事：云函数部署、云数据库读写、权限规则，全是 Agent 通过 CloudBase 的能力完成的。没有 CloudBase 这半边，Agent 顶多帮你写完前端代码，后面还得你手动接管。

四、场景二：报错别再人肉搬，AI 自己翻日志破案​

第二个场景更爽。

云函数报错，以前你要人肉把报错从控制台搬给 AI，它再猜。现在 Agent 直接翻 CloudBase 的日志（CLS），自己定位根因、自己改、自己重部署。

这才是"闭环"。以前那一整套"复制报错—粘贴—AI 猜—你再验证"的人肉往返，被压成了一句话。

五、CloudBase：让 Agent 的闭环真正合上的另一半​

单独看微信开发者工具 Skills，Agent 能编译、能截图、能调模拟器。但要真正"从想法到上线"，还差云端的那一截：数据库、云函数、存储、权限、日志。

这一截，就是 CloudBase。

说点实在的，这也是我敢推荐你试试的原因——对个人开发者，CloudBase 的免费额度够厚：

• 云数据库：读 5 万次 / 天、写 3 万次 / 天（官方基础档免费配额）
• 云函数：每月有免费调用额度，个人版就够一个练手项目跑通
• 云存储 / 静态托管：基础额度内免费
• 月成本：个人练手项目，开发测试阶段基本是 0 元

2026 独立开发者新配方 = AI Agent × 微信开发者工具 Skills × CloudBase 一个人。三样工具。从想法到上架。

（这一段你可以直接截图发朋友圈。）

一句实话：免费是阶段性的，不是永久的。量跑起来之后按量付费，这是所有云服务的常态。但把一个想法从 0 跑通、跑到一个能给人看的原型，免费额度绰绰有余——这点我替你确认过。

六、安全刹车​

肯定有人担心：Agent 能部署、能发布，会不会乱来？

三个保险：

1. 危险操作（部署云函数、发体验版）弹明确确认框，你授权才执行；
2. 取 AppID、云环境等敏感信息前，必须你主动授权；
3. 所有 Skill 调用都在本地开发者工具内完成，代码与日志不上传云端。

换句话说，它能干多快，方向盘还在你手里。

七、两步接入​

如果你也想试，两步：

Step 1：下载新版微信开发者工具。 在开发者工具下载页下 Nightly Electron Build 2.02.2607032 及以上版本。

Step 2：装 Skill，两种方式任选。

方式一（极客首选）：装完在终端跑 wechatide，复制输出的 Skill 路径，贴给你的 Agent。

方式二（小白友好）：开发者工具菜单栏 → 「导出开发者工具 Skill」→ 导出 → 导入你的 AI Agent。

CloudBase 那半边不用单独配，Agent 用到时按提示授权即可。

我这套下来，账单是 0 元。不是因为我抠，是免费额度真的够一个独立开发者把想法跑通。

你如果已经用 CloudBase，这套组合只是让你少切窗口；如果你还没用过——这篇就是想让你知道，现在开个环境、跑个小程序，门槛比我去年写同类教程时低了一大截。

觉得我说得不对，评论区骂我；觉得有用，转给那个天天跟你抱怨"小程序开发太碎"的朋友。

我是阿树。下篇接着聊：一个人怎么把小程序养到能赚钱。

1. 日志里明明看到一个字段（比如 memory_usage），打开检索面板却找不到这个选项
2. 好不容易写对一条 CQL 检索语句，系统却给您自动拼接 requestId、timestamp 等默认条件，结果一片空白

这次日志检索把这两个痛点一次修了。

改了什么​

可视化检索字段自动同步​

以前，可视化检索的字段列表靠后台版本更新维护。您打的某个字段（比如云函数示例里的 memory、status_code、function_name）就算上报上来了，检索面板里也可能看不到，要等下一次版本发布。

现在系统动态拉取日志上报的所有 Key，新上报的日志字段会自动出现在可选列表里，不用等版本更新。

检索交互更可控​

在语句交互模式下，系统过去会在您手写的检索语句基础上自动拼上 requestId、timestamp 等默认条件，结果常常和您预期的不一致——明明写对了语句却查不到数据。

现在系统完全以您手动输入的检索语句为准，不再自动拼接任何默认条件，搜什么得什么。

怎么用​

无需额外配置，直接在控制台 → 日志监控 → 日志管理使用即可。

• 可视化模式：勾选您想筛选的字段，组合查询
• 语句模式：手写 CQL，系统不会再帮您「自动补全」

一句话总结​

字段不再漏，检索不再被补。您看到的字段就是能搜的，您写的语句就是真正执行的。

CloudBase 邮箱登录现在新增 Magic Link 模式：用户输入邮箱后，邮件里收到一条登录链接，点一下就完成登录，不需要再敲 6 位验证码。

这个改动给您带来什么​

• 用户登录路径少 3 步：少了「看验证码 → 复制 → 切回 → 粘贴」四个动作
• 托管登录页直接生效：开启后，邮箱登录区域自动显示「发送登录链接」按钮
• 跳转地址可配：用户点击链接验证通过后，自动跳转到您指定的页面（订单页、Dashboard 等）
• 两种模式按需切：保留邮箱验证码的产品也不受影响，按业务调即可

怎么开始​

1. 进云开发控制台 → 身份认证 → 登录方式选择 → 邮箱登录
2. 选择 Magic Link 模式（或保留验证码模式）
3. 如需自定义跳转地址，在发送验证请求时传入 email_redirect_to

实际怎么调用​

Magic Link 模式下，发送邮箱验证请求时传入 email_redirect_to 参数即生效：

{
  "email": "user@example.com",
  "target": "ANY",
  "email_redirect_to": "https://your-domain.com/dashboard"
}

不传 email_redirect_to 时，自动 fallback 到验证码模式：

{
  "email": "user@example.com",
  "target": "ANY"
}

跳转地址必须是完整 URL，且只能是 CloudBase 默认域名或已配置的自定义域名（避免用户点开链接后跳转失败）。

注意​

• Magic Link 支持邮箱登录
• 默认有效期 600 秒，点击使用后即失效
• 托管登录页和自定义 SMTP 都已适配，两种模式都能用

云开发现在上线集成中心，把这些「脏活累活」沉淀到平台层。您只管写业务逻辑，剩下的平台代劳。

集成中心做了什么​

四步完成接入​

1. 创建集成：集成中心 → 选择类型（如「小程序微信支付」）→ 填写凭证与配置
2. 自动部署：平台生成 HTTP 云函数，并把凭证作为环境变量注入
3. 业务调用：前端 / 后端通过云函数 SDK 或 HTTP 调用集成函数（下单、查单、退款）
4. 回调处理：第三方异步回调经集成中心验签解密后，以明文转发到您的函数路由

集成函数创建后会出现在云函数列表，函数名形如 <集成名>-<随机串>，您可以直接通过 SDK 调用，无需再写验签逻辑。

目前支持​

微信支付：小程序 / Native / JSAPI 网页支付一键接入​

覆盖：

• 微信小程序支付：下单、查单、退款、回调通知
• Native 扫码支付：PC 网页扫码下单
• JSAPI 网页支付：公众号网页内支付

填好商户号与证书即可调用，回调验签解密全由平台处理，省去自建支付后端与密码学逻辑。

怎么开始​

1. 进 云开发平台 → 集成中心
2. 选择要接入的集成类型（首期：微信支付）
3. 填写商户凭证和配置，确认部署
4. 业务侧用 SDK 调集成函数即可

集成类型持续扩充中，最新支持列表以集成中心控制台为准。

一句话总结​

接微信支付的密码学和网络兜底，从此不归您管。 您写业务逻辑，平台写脏活累活。

#CloudBase #集成中心 #微信支付