ObjectOS扩展现有系统
将 ObjectOS 连接到你已经在运行的业务系统，然后为其加上 AI 原生的查询、分析与自动化能力 —— 无需迁移。
扩展现有系统
大多数评估 ObjectOS 的团队都已经有一套记录系统 —— 一个 CRM、一个 ERP、一个工单工具，或者一个跑在生产 SQL 或 MongoDB 数据库上的自研后办公 系统。问题很少是 "我们是否应该把它丢掉重建？"，而是 "我们能不能让已有的 东西变得 AI 原生，又不必经历一次有风险的迁移？"
这正是本页所描述的路径：将 ObjectOS 连接到你 现有的数据库，把你关心的表建模为对象，并让 AI Agent 查询、分析这些数据并对其采取行动 —— 在你的权限之下、 在你的基础设施之上，且原系统毫发无损。
这一步的形状
你不会替换你的业务系统。你把 ObjectOS 放在它旁边， 让二者指向同一个数据库：
- 连接：把现有数据库作为数据源接入。 凭据来自你的环境；如果你只想做分析，连接可以是 只读的。
- 建模：把表建模为对象 —— 手工进行，或者让一个编码 Agent 扫描 schema 并为你生成源码级的对象文件。
- 绑定：把每个对象绑定到数据源（按对象绑定，或用针对 整个命名空间的路由规则）。
- 使用 AI：一旦某张表成为对象，每个 Agent、工具、流程 和仪表盘都能在它之上工作，并被自动路由到正确的数据库。
遗留应用的任何方面都不会改变。数据行保持原位。 ObjectOS 成为其上层那个 AI 原生、感知权限的界面。
为什么这样行得通且无需重写
| 顾虑 | ObjectOS 如何应对 |
|---|---|
| "我们没法移动数据" | 数据从不移动。ObjectOS 就地连接到你的数据库。 |
| "我们不能冒险对生产库写入" | 把对象绑定到只读数据源（或一个只读的数据库用户）。先安全地分析；再有意识地开启写入。 |
| "把每张表都建模需要几周时间" | 一个编码 Agent 扫描 schema，并为每张表生成一个对象文件 —— 你审阅并打磨，而不是逐个手敲。 |
| "AI 不能托付我们的数据" | Agent 以登录用户的身份运行，并遵守对象级、记录级和字段级权限。它们看到的内容绝不会超过其背后的那个人。 |
| "我们的数据不能离开网络" | ObjectOS 运行在你的环境里。业务数据与提示词都留在你的边界之内。 |
用编码 Agent 生成对象
把一个现有 schema 引入进来最快的方式，是使用一个编码 Agent
（例如 Claude Code）来扫描业务表并生成
源码级的对象定义 —— 每张表对应一个 *.object.ts 文件。
hotcrm 参考应用
展示了这类输出应当呈现的确切形态：每张表都成为一个
src/objects/<name>.object.ts，使用 ObjectSchema.create({ … }) 配合
带类型的 Field.* 定义，并用 Field.lookup(...) 表示外键，
由 defineStack 组装。该 Agent 内省你已连接的
数据库，把列映射到字段类型，并写出归你所有、由你
提交的对象。你保留合适的部分，丢弃不想暴露的列，并在其上
添加标签、校验与权限。
完整的、逐步的编写指南见数据源。
第一天你就能得到什么
一旦这些表被建模为绑定到你现有数据库的对象：
- 自然语言分析。 用户就真实记录提问 —— "这个季度哪些交易延期了，分别归谁负责？" —— 答案会通过 ObjectQL 针对实时数据计算得出。
- 受治理的自动化。 流程与动作可以读取并（在允许时） 写入同一份数据，每一步都被审计。
- 生成的 API 与 Console。 REST/GraphQL 端点与管理 界面来自同一份元数据 —— 无需额外的集成层。
- 统一的权限模型。 适用于人类的边界，会原封不动地 同样适用于 AI 流量。
它的走向
上述流程在今天就能通过已发布的构建块运转。一种更丰富的、 开箱即用的联邦体验 —— 一步式 schema 导入、外部 拥有的 schema 绑定，以及内建的安全闸门 —— 正在 ADR-0015 下积极设计中（状态：Proposed）。在它落地之前，这条已记录的 路径 —— 连接、建模、绑定、查询 —— 就是扩展现有系统的受支持方式。
从这里开始
- 数据源 —— 连接数据库、绑定对象、路由查询
- AI Agent —— 构建在你对象之上的声明式 Agent
- 权限 —— AI 所继承的模型
- Quickstart —— 几分钟内搭起一个运行时