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 —— 幾分鐘內搭起一個執行時