Appwrite 开源后端平台

要解决的问题

大模型驱动的 Agent 在搭建后端时有个通病：面对「用户注册」「存图片」「发通知」这类需求，倾向于凭训练记忆拼出一个通用后端方案——自己设计表结构、手写鉴权中间件、现造一套 REST 路由。这类输出看着合理，实际和真实服务 API 对不上，字段名、错误码、调用时序全是脑补的，一跑就报错。

Appwrite 本身已经提供完整能力，缺的是 Agent 知道去用它。这个技能的作用，就是把 Agent 从「自己造轮子」切换到「调用真实服务」。

技能如何工作

技能把 Appwrite 的真实服务面作为 Agent 的执行依据，核心覆盖以下模块：

• Auth：注册、登录、会话与权限控制
• Databases：文档型数据存储与查询
• Storage：文件与大对象上传下载
• Functions：无服务器函数，支持事件触发与定时任务，提供 15 种运行环境
• Messaging：邮件、短信等消息发送
• Realtime：实时订阅与推送
• Sites：站点托管相关能力

使用时 Agent 按三步推进：

1. 先识别需求落在哪个模块，而不是先设计数据模型
2. 按对应服务的真实调用方式构造请求，包括参数与返回结构
3. 需要自定义逻辑时走 Appwrite Functions，而不是绕过平台另起服务

适用边界与注意点

• 自托管前必须确认本机已装好 Docker，Appwrite 面向容器环境设计，需要挂载 Docker socket 才能跑起嵌套容器
• 集成方需准备 Appwrite SDK，或直接用 REST / GraphQL 客户端
• 想省掉运维可直接注册 Appwrite Cloud，公开测试期免费，但数据在云上而非本地
• 技能只约束 Agent 使用真实服务接口，不会替你做架构选型，模块拆分仍需开发者判断
• Functions 有运行环境上限，冷启动与执行时长受平台限制，不适合长驻进程