文章目录
让 AI 写出一段代码，和让一个应用持续为人服务，是两件相隔很远的事。应用需要一个可以运行的地方，需要保存数据，需要发布新版本，也需要知道自己有权访问哪些资源。
brazosd 的 Serverless 体系连接这两端：Agent 负责把需求转成软件，云函数承接执行，云数据库 SQLite 保存应用状态。它们共同提供从代码到可用服务的基础。
Serverless 把哪些工作交给平台
Serverless 常被译成“无服务器”。服务器依然存在，只是应用开发者不必为每个小应用单独管理机器、启动进程和处理闲置资源回收。
可以把它理解为带公共设施的工作室。应用带来自己的业务逻辑，平台提供运行空间、访问入口和生命周期管理。暂时没有工作时，执行资源可以回收；下一次需要服务时，平台再准备运行环境。
brazosd 的云函数运行应用代码，也能承接持续响应和 WebSocket 连接等场景。这里的“函数”是云端应用的执行单元，不能简单等同于只能运行几毫秒的小片段。
为什么函数需要一个独立的数据库
如果把业务数据只放在运行中的内存或临时文件里，回收实例就可能丢失状态。因此，应用的执行环境和长期数据需要分开。
云函数负责处理请求，SQLite 云数据库负责保存结构化记录，例如客户、库存、审批状态和应用配置。云盘则保存文档、图片和交付文件。它们各自承担合适的职责。
| 组成部分 | 可以理解为 | 主要职责 |
|---|---|---|
| Agent | 理解需求的构建者 | 编写、修改、协调应用 |
| 云函数 | 按需工作的执行空间 | 运行应用逻辑、提供服务 |
| SQLite 云数据库 | 应用的业务账本 | 保存关系明确的结构化数据 |
| 云盘 | 共享的文件系统 | 保存材料和文件成果 |
表格可以左右滑动
函数可以重新启动，业务账本仍然存在。数据库本身的计算资源也有独立生命周期，应用无需为了保留数据就持续占用同一台运行中的机器。
SQLite 怎样成为云数据库
SQLite 提供熟悉的表、SQL 查询和事务。brazosd 集成的 SQLess 为它补充远程连接、身份校验、计算调度与持久存储，使应用通过网络使用 SQLite。
SQLess 将数据库计算与持久存储分开：数据库页面可以按需读取，空闲计算可以回收，后续 SQL 请求再激活计算。持久性由存储协议承担，不能依赖“那个数据库进程一直活着”。
每个数据库同时由一个有效的读写所有者负责。这种设计追求清楚的一致性与生命周期边界，不应被理解为一个 SQLite 数据库会自动变成无限并行写入的分布式数据库。
当前还内置了 sqlite-vec，可通过 SQL 保存向量并做相似度查询。向量可以理解为内容的数字化特征，适合为应用构建语义检索；生成向量仍需要相应模型或处理流程，数据库不会凭空理解所有文件。
让模型做变化，让代码做重复
假设一个业务每天接收相同格式的订单。每来一条订单都重新让模型推理所有校验规则，会增加延迟、成本与结果波动。
更合适的分工是：Agent 理解业务并建立处理程序；云函数按确定规则校验、计算和写入数据库。遇到新需求或复杂例外，再让 Agent 参与判断和修改。
这让 Agent 的成果从一次回答，变成能够反复提供服务的软件。随着使用次数增加，构建这段逻辑的投入可以在更多任务中复用。不过，实际收益取决于工作量、模型使用和运行资源，不能只凭架构就承诺固定比例的降本。
发布和身份同样属于基础设施
当前云函数使用版本化的发布包。新实例通过健康检查后再承接流量，部署历史支持选择已有版本回滚。代码回滚并不会自动回滚数据库里的业务数据，因此变更表结构仍要考虑兼容性。
函数还拥有自己的服务身份。它读取云盘或调用其他平台能力时，应当获得所需权限，而不是继承某个人的全部访问范围。应用由 Agent 生成，也要遵守这条边界。
这些事情往往不体现在演示中的“生成页面”环节，却决定了应用能否进入持续使用。
当前能力与演进空间
当前云函数采用单个稳态实例，部署切换期间可以出现新旧实例；它并未提供按流量自动横向扩容的能力。空闲回收、按需启动与自动横向扩容是不同问题，冷启动等待也需要纳入体验设计。
Serverless 的价值在于把一部分重复的基础设施工作交给平台，让小而专用的应用更容易被创建、运行和维护。这是 UnoZ OS 中“云应用即进程”的基础，也是 brazosd on brazosd 的构建材料。具体开发与发布方式见云应用文档。