Agent 開發指南

別教每個開發者手寫應用。教你的 Agent 寫本體。

一份可執行的業務本體。AI 編寫它,執行環境執行它,Agent 操作它,你擁有它。Agent 寫的就是本體——四個承諾里的「AI 可編寫」——你是審閱者:腳手架寫入 AGENTS.md,讓 Agent 一開始就帶著協議規則;Strict TypeScript、Zod schema 與 os validate 會在無效輸出進入執行環境前將其拒掉;整個應用小到 AI 能整體裝下。

ObjectOS product surface connecting business data, applications, and AI agents
AI 編寫中繼資料 物件、權限、流程、工具
人 審閱 diff 業務權限、資料訪問、審批
執行環境 執行策略 UI、API、審計、MCP、動作
AGENTS.md
由腳手架寫入,Agent 一開始就帶著協議規則
4 道閘門
型別化、校驗、審閱、治理——橫在 Agent 與你的使用者之間
整體裝下
應用小到 AI 能整體裝下——README 自帶的示例 CRM 可端到端讀完

README 路徑

三條命令,你的 Agent 就有了規則

腳手架安裝 AI skills 包並寫入 AGENTS.md,Agent 一開始就帶著協議規則,而不是泛泛的“給我寫點 TypeScript”先驗。在 Claude Code、Cursor 或 Copilot 裡描述需求;Agent 寫的是型別化中繼資料而不是程式碼庫,閘門會拒掉執行環境會靜默失敗的東西。然後在瀏覽器裡預覽真實應用,並在一份讀得懂的 diff 上提出下一次變更。

# 1 · 建立專案:安裝 AI skills 包,寫入 AGENTS.md
npm create objectstack@latest my-app && cd my-app

# 2 · 用 Claude Code(或 Cursor、Copilot……)開啟它,描述業務需求:
#    “搭一個支援臺。加一個 ticket 物件,有 subject、description、
#     priority 選擇和 status 選擇。加一個只在未解決工單上顯示的
#     Resolve 動作。加一個 Open tickets 列表檢視和 Support 導航組。
#     做完跑 npm run validate。”

# 3 · 在瀏覽器裡預覽
npx os dev --ui   # -> http://localhost:3000/_console/

工作流

Agent 編寫的開發閉環

閉環刻意保持簡單:給 Agent 完整的當前定義與運營上下文,讓它編輯型別化中繼資料,跑 validation gate,然後在部署前由人審閱業務權限。

上下文

1. 提供運營上下文

把業務流程、物件命名、權限邊界、流程狀態、整合約束與完整的當前定義交給 Agent。應用小到 AI 能整體裝下——README 自帶的示例 CRM 可端到端讀完——因此可以被整體檢視,無需從碎片裡拼湊。

編寫

2. 編寫本體

Agent 以 Strict TypeScript 編輯本體——物件與欄位、關係、動作、權限、流程與工具定義——及其投影——檢視、儀表盤、翻譯——而不是生成應用膠水程式碼。

驗證

3. 通過 validation gate

以 Strict TypeScript 模式編譯,逐項用 Zod schema 校驗定義,再檢查權限、必填標籤、示例資料、物件查詢與流程流轉。

批准

4. 審閱權限

人審的是權限變化:資料訪問、寫權、審批繞行、匯出與 AI 工具暴露。

模式

Agent 應該生成什麼

最好的生成式變更用清晰的業務概念命名,並讓執行環境權力保持顯式。

物件與欄位

使用業務命名、關係、校驗、索引與生命週期規則,與真實運營一一對應,並符合已釋出的 Zod schema。

檢視與動作

從物件模型生成列表、表單、看板、儀表盤與動作中繼資料,而不是一次性介面。

流程與審批

把流轉與審批閘門顯式定義出來,執行環境才能對人和 Agent 一體執行。

Agent 工具

只通過 MCP 暴露有邊界的物件查詢與動作,帶策略檢查和便於審計的命名。

決策面

改什麼、誰來審、跑什麼

舊的開發表面Agent 編寫的 ObjectStack 表面評審者要問的
控制器程式碼物件動作中繼資料誰能呼叫這個動作?
自定義鑑權檢查物件、行級與欄位級權限資料權限發生了什麼變化?
手搭的介面檢視與表單中繼資料這個介面支撐哪條流程?
臨時拼的 AI 提示詞策略感知的工具契約模型能讀什麼、能改什麼?

評審清單

Agent 編寫的 ObjectStack diff 評審清單

  • Agent 是否檢視了完整的當前應用,而不是根據碎片猜測缺失狀態?
  • 變更是否通過 Strict TypeScript 編譯、Zod schema 校驗與 validation gate?
  • 這份 diff 改的是業務權限,還是隻有呈現?
  • 物件與欄位命名是否穩定且貼合領域?
  • 讀、寫、匯出與工具的預設值是否保守?
  • 敏感動作的審批閘門是否顯式?
  • 測試或示例資料能否演示這條流程?
  • 未來的 Agent 能否檢索並複用同一個模式?

FAQ

常見問題

開發者還需要懂 ObjectStack 嗎?

需要,但主要任務變了。人負責設計邊界、審閱 diff、寫測試、維護示例;重複性的中繼資料編寫更多交給 Agent。

任何編碼 Agent 都能寫 ObjectStack 嗎?

只要有清晰的文件、示例、規則、測試與完整的當前定義,任何強力編碼 Agent 都能使用這個格式。Strict TypeScript、Zod schema 與 validation gate 會在部署前給出確定性反饋;通過後,同一應用可自託管於 ObjectStack,也可由 ObjectOS 使用同一開源執行環境代為運營。

下一步

繼續完善你的評估材料。