Agent 開發指南
別教每個開發者手寫應用。教你的 Agent 目標格式。
ObjectStack 的設計前提是：Agent 是作者，人是審閱者。開發者的工作流是給 Agent 規則、示例、測試與評審閘門，讓後設資料變更保持小巧、保持可治理。
AI 編寫後設資料 物件、許可權、流程、工具
人 審閱 diff 業務許可權、資料訪問、審批
執行時 執行策略 UI、API、審計、MCP、動作
- Agent 優先
- 規則與示例是產品表面的一部分
- 後設資料 diff
- 審閱物件、檢視、流程、許可權、工具
- MCP 就緒
- 把受治理的物件與動作暴露給 AI 客戶端
Agent 指令
一份好的規則檔案把目標格式寫得明明白白
最重要的開發者產物不是一篇手寫介面的教程，而是一份緊湊、可檢索的指令集：告訴 Agent 該改什麼、不該發明什麼、以及如何證明這次變更是可審閱的。
When building an ObjectStack app:
1. Model business objects before UI.
2. Prefer metadata definitions over generated application code.
3. Add conservative permissions by default.
4. Expose AI actions only through approved tools.
5. Return a small diff and a reviewer checklist.工作流
Agent 編寫的開發閉環
閉環刻意保持簡單：給 Agent 上下文，讓它編輯後設資料，跑檢查，然後在部署前由人審閱業務許可權。
上下文
1. 提供運營上下文
把業務流程、物件命名、許可權邊界、流程狀態與整合約束交給 Agent。
編寫
2. 生成後設資料
Agent 編輯物件、檢視、流程、動作、儀表盤、翻譯與工具定義，而不是應用膠水程式碼。
驗證
3. 執行生成的檢查
校驗 schema、許可權、必填標籤、示例資料、物件查詢與流程流轉。
批准
4. 審閱許可權
人審的是許可權變化：資料訪問、寫權、審批繞行、匯出與 AI 工具暴露。
模式
Agent 應該生成什麼
最好的生成式變更用清晰的業務概念命名，並讓執行時權力保持顯式。
物件與欄位
使用業務命名、關係、校驗、索引與生命週期規則，與真實運營一一對應。
檢視與動作
從物件模型生成列表、表單、看板、儀表盤與動作後設資料，而不是一次性介面。
流程與審批
把流轉與審批閘門顯式定義出來，執行時才能對人和 Agent 一體執行。
Agent 工具
只通過 MCP 暴露有邊界的物件查詢與動作，帶策略檢查和便於審計的命名。
決策面
改什麼、誰來審、跑什麼
| 舊的開發表面 | Agent 編寫的 ObjectStack 表面 | 評審者要問的 |
|---|---|---|
| 控制器程式碼 | 物件動作後設資料 | 誰能呼叫這個動作？ |
| 自定義鑑權檢查 | 物件、行級與欄位級許可權 | 資料許可權發生了什麼變化？ |
| 手搭的介面 | 檢視與表單後設資料 | 這個介面支撐哪條流程？ |
| 臨時拼的 AI 提示詞 | 策略感知的工具契約 | 模型能讀什麼、能改什麼？ |
評審清單
Agent 編寫的 ObjectStack diff 評審清單
- 這份 diff 改的是業務許可權，還是隻有呈現？
- 物件與欄位命名是否穩定且貼合領域？
- 讀、寫、匯出與工具的預設值是否保守？
- 敏感動作的審批閘門是否顯式？
- 測試或示例資料能否演示這條流程？
- 未來的 Agent 能否檢索並複用同一個模式？
FAQ
這一頁應該回答的問題
開發者還需要懂 ObjectStack 嗎？
需要，但主要任務變了。人負責設計邊界、審閱 diff、寫測試、維護示例；重複性的後設資料編寫更多交給 Agent。
任何編碼 Agent 都能寫 ObjectStack 嗎？
只要有清晰的文件、示例、規則與測試，任何強力編碼 Agent 都能駕馭這個格式。站點與文件的寫法本身就應讓 Agent 能正確檢索並生成。
下一步