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 —— 它們不過是你倉庫裡的原始碼檔案。

試一試

如果你已經有一個業務資料庫，那你已經走完了大半路程。連上它，建模幾張表， 然後向你的資料提個問題。