◆ ObjectOS / 文章
← 全部文章
集成与数据 通用 已发布 · · 作者 ObjectStack Team

让你现有的业务系统原生支持 AI —— 无需迁移

把 ObjectOS 连到你已经在运行的数据库，让编码 Agent 把数据表建模为对象，再为真实数据叠加 AI —— 在你的权限之下、在你的服务器之上，原系统毫发无损。

  • Data Sources
  • AI-Native
  • Architecture

大多数”给你的业务加上 AI”的说辞，都悄悄假设了一次重建：把数据搬到新平台、 重新实现工作流、重新培训团队，然后祈祷迁移顺利落地。而这正是没人想做的部分。 那套记录系统 —— CRM、ERP、工单工具、自研的后办公系统 —— 已经在运转，数据 也已经在那里。

ObjectOS 采取相反的立场。你不迁移。你连接。

一句话讲清这个想法

把 ObjectOS 指向你现有的数据库，将你关心的数据表描述为对象，于是每一个 AI Agent、流程、API 和仪表盘都立刻在这些数据上工作 —— 自动路由到正确的系统， 并受你的用户已经拥有的同一套权限治理。

原有的应用不会改变。数据行不会移动。ObjectOS 成为你已运行系统之上那层原生 支持 AI、感知权限的界面。

一个具体的画面

假设你的销售团队跑在一个 40 张表的 Postgres CRM 上。客户、联系人、商机、 明细行、活动 —— 多年的真实数据，一个销售每天都在用的生产应用。管理层想要 两件事：让大家用自然语言向数据提问（“哪些企业级商机滑出了 Q2，分别是谁 在负责？”），以及让自动化安全地操作这些数据。

重建的答案是一个六个月的项目。ObjectOS 的答案是一个下午：

  1. 把 CRM 数据库连接为一个只读数据源。
  2. 让编码 Agent 把你真正关心的那十来张表建模为对象。
  3. 向你的数据提问，并接上第一条自动化。

没人碰 CRM。销售毫无察觉。而你在完全相同的数据行之上，得到了一层原生支持 AI 的能力。

它今天如何运作

一共四步，而且没有一步是”重建你的应用”。

1. 将数据库连接为数据源

数据源是一个具名连接 —— Postgres、MySQL、MongoDB、SQLite。凭据来自环境 变量，绝不写死在源码里。如果你想先做分析，把它指向只读副本或只读数据库 用户，写入便根本无从发生。

import type { Datasource } from '@objectstack/spec';

export const BusinessDb: Datasource = {
  name: 'business_primary',
  label: 'Business System (Postgres)',
  driver: 'postgres',
  config: {
    connection: {
      host: process.env.BIZ_DB_HOST,
      user: process.env.BIZ_DB_USER,
      password: process.env.BIZ_DB_PASSWORD,
      database: process.env.BIZ_DB_NAME,
    },
  },
  pool: { min: 1, max: 10 },
  active: true,
};

2. 将数据表建模为对象 —— 交给编码 Agent

这一步人们以为会很慢，其实不然。你不必为每张表手工敲对象。把像 Claude Code 这样的编码 Agent 指向已连接的 schema，让它完成内省与初稿。一句朴素 的提示就够了：

“连接到 business_primary 数据源。为这几张表 —— accounts、contacts、 opportunities、line_items —— 各生成一个 src/objects/<name>.object.ts 文件，使用 ObjectSchema.create。把 SQL 列映射到合适的 Field.* 类型， 把外键转成 Field.lookup(...)，并在每个对象上设置 datasource: 'business_primary'。”

Agent 会读取真实的列、类型和外键，写出源级别的对象文件。我们的 hotcrm 参考应用展示了输出的 确切形态：

import { ObjectSchema, Field } from '@objectstack/spec/data';

export const Opportunity = ObjectSchema.create({
  name: 'biz_opportunity',
  label: 'Opportunity',
  datasource: 'business_primary',
  fields: {
    name:      Field.text({ label: 'Name', required: true }),
    account:   Field.lookup({ label: 'Account', reference_to: 'biz_account' }),
    amount:    Field.currency({ label: 'Amount' }),
    stage:     Field.select({ label: 'Stage', options: [/* … */] }),
    close_date: Field.date({ label: 'Close Date' }),
  },
});

因为产物是你拥有并提交的普通源码，你始终掌握控制权：保留重要的列、丢弃 不想暴露的列，再叠加 label、校验与权限。Agent 几分钟内把你带到一份可审阅的 初稿；你来让它达到生产级别。

3. 将对象绑定到数据源

每个对象都带有 datasource。可以逐个对象设置，也可以为整个命名空间声明一条 路由规则，让其下每个对象继承：

datasourceMapping: [
  { namespace: 'biz', datasource: 'business_primary' },
  { default: true,    datasource: 'default' },
]

规则按命名空间、包名或对象名 glob 匹配；首个命中者生效。数据驻留的决策集中 在一处，而不是散落在各个文件里。

4. 让 AI 开始工作

一旦一张表成为对象，AI 层就能免费地在它上面工作。ObjectOS 的 Agent 与工具 —— list_objects、describe_object、query_records、aggregate_data 以及 data-chat agent —— 都经由 ObjectQL，由它将每个对象路由到所绑定的数据源， 并在驱动支持时把过滤、排序与聚合下推进数据库。

于是当用户问：

“哪些企业级商机滑出了 Q2，分别是谁在负责？”

Agent 不会把整张表灌进提示词。它会把这句话编译成一条针对 biz_opportunity 的 ObjectQL 查询 —— 对阶段和关闭日期的 WHERE、对负责人的 join —— 在你的 Postgres 上以 SELECT … WHERE … 执行，并基于真实、当前的数据行作答。而且 关键在于，它以已登录用户的身份运行这条查询：如果某个销售在 CRM 里看不到 其他区域的商机，Agent 也同样看不到。

为什么这是安全的

对”在我们的业务数据上跑 AI”的质疑总是关于治理，而这恰恰是运行时发挥作用的 地方：

  • AI 以用户身份行动，绝不凌驾其上。 Agent 看到的，恰好是它背后那个人被 允许看到的内容 —— 对象级、记录级、字段级权限由运行时强制，而非由提示词约束。
  • 如果你愿意，默认只读。 把对象绑定到只读连接或只读数据库用户。安全地 分析生产数据；再有意识地、一个对象一个对象地开启写入。
  • 一切皆有审计。 每一次读取、写入和提权 —— 无论来自人还是 Agent —— 都记录下何人、何事、何时、何因。
  • 你的数据留在你的网络里。 ObjectOS 跑在你的环境中。业务数据和提示词 从不离开你的边界。

重建 vs. 连接

重建到新平台用 ObjectOS 连接
首次见效时间数月一个下午
对记录系统的风险高 —— 数据迁移、双写、切换上线无 —— 源应用毫发无损
数据存放在哪被搬走原地不动
建模工作量手工重新实现每个实体编码 Agent 从真实 schema 起草对象
权限重建并重新审计继承；AI 遵守同一套模型
可逆性难以撤销断开数据源 —— 什么都没变

第一天你就能得到什么

一旦几张表被建模并绑定：

  • 自然语言分析作用于实时记录，经由 ObjectQL 计算 —— 而非一份过期的导出。
  • 受治理的自动化。 流程与动作读取、并（在允许处）写入同一批数据，每一步 皆有审计。
  • 生成式 API 与控制台。 REST/GraphQL 端点与管理界面源自同一份元数据 —— 无需另建集成层。
  • 同一套权限模型。 适用于人的边界，同样适用于 AI 流量。

已经交付的 vs. 即将到来的

上面这套流程今天就能用，凭借的是已交付的构建块：数据源、按对象路由、 感知能力的 ObjectQL 下推，以及 AI Agent 层。对象的建模由一个编码 Agent 针对 你已连接的 schema 完成 —— 与 hotcrm 的对象被编写出来的方式相同。

一套更丰富的**开箱即用联邦（turn-key federation）**体验 —— 一步式 schema 导入、绑定到外部拥有的 schema、内建的写入安全闸门 —— 正在 ADR-0015 下积极设计（状态：Proposed）。随着它落地，我们会写更多内容。在那之前， 有文档记载的路径 —— 连接、建模、绑定、查询 —— 才是受支持的路径。

常见问题

我必须把每张表都建模吗？ 不必。只建模你想让 AI 和自动化触及的表。数据库 其余部分会被忽略。

这会写入我的生产数据库吗？ 只有你允许才会。绑定到只读连接或只读数据库 用户，写入便不可能发生；准备好后，再有意识地、按对象开启写入。

我的数据会发给模型厂商吗？ ObjectOS 跑在你的环境中，查询在你的数据库上 执行。配置哪个 AI 提供方、允许它看到什么，由你掌控。

如果我的 schema 变了怎么办？ 针对更新后的 schema 重新运行编码 Agent， 重新生成或对受影响的对象做 diff —— 它们不过是你仓库里的源码文件。

试一试

如果你已经有一个业务数据库，那你已经走完了大半路程。连上它，建模几张表， 然后向你的数据提个问题。