文章目录
如果一个平台鼓励用户用 Agent 创建应用，它自身的新功能能否也用同样的能力构建？这就是 brazosd on brazosd：让 brazosd 越来越多地运行在自己提供的应用基础设施上。
它是一条产品演进方向。云函数、云数据库、云盘和平台 API 已经提供了基础；后续更多功能将沿着这套路径搭建。理解这个方向，需要先区分保存事实的地方、处理业务的地方，以及显示结果的地方。
三类数据，各有权威来源
Single source of truth，通常译为“单一事实来源”。它指的是：对于同一项事实，系统应当知道哪份记录具有权威性。这个原则不要求把所有数据塞进一个数据库。
在 brazosd 的应用模型中，三类数据有不同的归属。
| 数据 | 权威来源 | 界面如何使用它 |
|---|---|---|
| 文件、材料、可交付成果 | 云盘 | 浏览、预览、编辑和组织文件 |
| Agent 与会话中的持久记录 | 平台的 Agent 数据 | 呈现对话、任务进展与执行结果 |
| 应用自己的结构化业务数据 | 云数据库 SQLite | 形成表格、统计、业务页面 |
表格可以左右滑动
例如，一份合同文件保存在云盘，围绕合同的 Agent 会话保存在会话系统，合同管理应用的审批状态保存在 SQLite。三者可以通过引用联系起来，不必让每个界面都复制一套合同、聊天记录和状态，再设法保持同步。
这是应用层的权责划分。平台内部仍有用于账户、权限和基础设施协调的数据库，并不意味着整个 brazosd 的底层数据都已经迁入 SQLite。
云函数承接可以重复执行的业务
在这些事实之上，云函数提供应用自己的逻辑。例如，一个合同应用可以读取获准访问的云盘材料，把审批记录写入自己的数据库，再返回适合界面展示的数据。
Agent 可以负责理解需求、编写和修改这段逻辑；稳定的规则则交给代码反复执行。这样，“理解一个新问题”与“可靠地执行已确定的规则”就有了不同的承担者。
现有云函数已经具备独立的服务身份，可以通过平台 SDK 调用 API。企业组织中，这个身份也受用户组和权限策略约束。这一点很关键：应用接入平台数据不必依赖管理员把个人凭据硬塞进程序，更不能通过更换界面绕过权限。
产品使用自己的能力，意味着什么
当平台自己的新功能也以云函数和数据库构建，同一套能力会接受真实产品需求的检验：发布是否可靠，权限是否足够细，数据是否可组合，出问题后是否能定位和恢复。
这种自用方式有机会缩短平台团队与应用开发者之间的距离。内部遇到的问题，往往也是外部开发者会遇到的问题；基础设施的改进也就能同时服务两者。
这并不意味着所有底层系统都应改写成云函数。身份校验、资源调度和运行时控制仍然需要明确的平台边界。brazosd on brazosd 的重点，是让更多上层产品能力使用可复用的应用基础设施，而不是消除一切底层实现。
用户可以构建自己的 brazosd UI/UX
UI 是人看到的界面，UX 是完成工作的整体体验。当数据和操作能力通过稳定接口提供，官方界面就不必成为唯一入口。
同一份项目数据，可以呈现为管理层看板、项目经理的任务视图，或者只围绕某个业务动作设计的极简页面。用户可以在授权范围内调用平台 API，把云盘、Agent 会话和自己的业务数据库组合成专属工作台。
现有 UnoZ OS 已经提供了一个例子：它使用独立的桌面与窗口界面，同时复用平台 API 和实时通信能力。它说明共享后端能力与重做交互体验可以同时成立。
构建自定义体验仍需要处理登录、权限和数据契约；把第三方应用安全地嵌入系统，也有独立的托管与隔离工作。这个方向不是承诺任意生成的界面今天就能替换所有系统功能。
平台的扩展方式，也随之改变
如果每个新功能都必须进入同一个大型前端和后端，产品的扩展速度会受统一发布流程和既有界面结构限制。可编程平台则允许一部分需求以应用、技能和定制界面的方式生长。
对平台而言，关键资产逐渐包括稳定的数据边界、可调用的能力、权限模型和应用运行环境。对用户而言，价值在于自己的流程不必永远等待官方新增一个页面。
这也是 Agent > UI、Serverless 与 UnoZ OS 的交汇点：Agent 构建和协调能力，云基础设施执行能力，不同界面围绕同一份事实形成各自的体验。