API Claw — 智慧硬體 & 第三方開發者接入
透過 Buda OpenAPI，讓你的硬體或軟體產品擁有雲端 AI Agent 能力，無需自建推理基礎設施
API Claw — 智慧硬體 & 第三方開發者接入
智慧手錶、IoT 裝置、聊天外掛……這些產品都想內建 AI Agent，但在裝置端跑大模型不切實際：算力不足、功耗太高、效果太差。
API Claw 就是為這個場景設計的：透過 Buda 的 OpenAPI，第三方開發者可以用幾個 API 呼叫，給自己的產品接入一個雲端 OpenClaw 🦞 AI Agent，擁有對話能力和專屬知識庫，按需喚醒、不用時零消耗。
更準確地說，你接入的不是一個裸模型 API，而是一層已經托管好的 Agent 能力層，裡面已經包含模型、執行環境、知識庫、會話管理與彈性擴縮容。
適合誰
- 智慧硬體開發商 — 手錶、耳機、IoT 裝置，想內建 AI 助理
- 軟體開發商 — 微信小程式、App、瀏覽器外掛，想嵌入 AI 對話
- SaaS 服務商 — 想給自己的客戶提供「帶 AI 的私有空間」
兩類最典型的接入方
1. 聊天軟體、SaaS 工具、第三方軟體服務商
如果你已經有自己的產品，有使用者、有聊天視窗、有表單或工作流，API Claw 可以讓你在不重做整套後端 AI 基礎設施的前提下，把 AI Agent 直接嵌入進去。
例如：
- 一個聊天軟體，希望每個聊天視窗都能接一個 AI 助理
- 一個客服 SaaS，希望每個客戶都有自己的私有 AI 客服
- 一個瀏覽器外掛或企業內部系統，需要一個雲端 AI Worker
2. 智慧硬體廠商
如果你在做智慧手錶、耳機、語音終端或其他聯網裝置，API Claw 可以讓裝置直接連上一個雲端 AI 大腦，而不是在裝置本地硬跑複雜智能能力。
也就是說：
- 裝置端負責輸入輸出
- Agent 在雲端運行
- 能力升級在服務端完成，不必把複雜度都壓到韌體裡
運作原理
你的產品（硬體/軟體）
↓ API 呼叫
Buda OpenAPI
↓
Space（租戶空間）
↓
Agent（AI 助理）+ Drive（知識庫）
↓
Chat Session（對話）每個終端用戶對應一個獨立的 Chat Session，上下文隔離。Agent 休眠時不消耗資源，收到訊息時自動喚醒。
你不需要自己做的部分
接入 API Claw 之後，開發者不需要再單獨建設或維護下面這些基礎設施：
- 模型配置和供應商切換
- 推理機器或 GPU 基礎設施
- Agent 執行環境與工具沙箱
- 文件知識庫處理
- 會話與上下文管理
- 不同使用者 / 客戶之間的租戶隔離
- 空閒 Agent 的喚醒與休眠調度
這正是 API Claw 的價值所在：你的團隊專注產品本身，Buda 提供背後的 Agent 基礎設施層。
為什麼不直接呼叫 LLM API？
直接呼叫模型 API，拿到的是模型輸出；接 API Claw，拿到的是一個可運行的 AI Agent。
| 裸模型 API | API Claw | |
|---|---|---|
| 返回內容 | 文本或結構化結果 | 帶上下文的 Agent 回覆 |
| 會話 | 你自己管理 | 內建 Session 模型 |
| 知識庫 | 你自己做檢索 | 自帶 Drive 知識庫 |
| 執行環境 | 你自己編排 | 托管 Agent Runtime |
| 多租戶 | 你自己設計 | 內建 Space 隔離 |
| 維運 | 你自己扛 | Buda 托管 |
如果你是產品公司，這個差異比單純「調模型」更重要。
API Claw 和 OpenClaw 的關係
OpenClaw 是底層的 Agent 能力與執行時模型，API Claw 則是把這層能力產品化、API 化之後提供給外部開發者接入的方式。
簡單說：
- OpenClaw = 底層 Agent runtime / capability layer
- API Claw = 面向開發者的接入層
接入流程
註冊開發者帳號，取得 API Key
在 Buda 註冊一個開發者帳號，進入設定取得 API Key。這個 Key 用於後續所有 OpenAPI 呼叫的驗證。
建立 Space（租戶空間）
你的每個客戶（或每台裝置）對應一個 Space。
POST /api/openapi/spaces
Authorization: Bearer <your-api-key>
{
"name": "用戶的裝置空間"
}儲存回傳的 spaceId。
在 Space 內建立 Agent
POST /api/openapi/spaces/{spaceId}/agents
Authorization: Bearer <your-api-key>
{
"name": "我的 AI 助理",
"instructions": "你是一個智慧手錶助理，幫助用戶管理行程、回答健康問題。"
}儲存回傳的 agentId。
（可選）上傳知識庫文件到 Drive
如果你的 Agent 需要根據特定文件回答問題（產品手冊、FAQ 等）：
POST /api/openapi/spaces/{spaceId}/drive/upload
Authorization: Bearer <your-api-key>
Content-Type: multipart/form-data
file=<your-document>發起對話
POST /api/openapi/spaces/{spaceId}/agents/{agentId}/chat
Authorization: Bearer <your-api-key>
{
"sessionId": "device-user-001",
"message": "今天天氣怎麼樣？"
}sessionId 由你自己管理，用於區分不同終端用戶的對話上下文。相同 sessionId 的訊息共享歷史，不同 sessionId 完全隔離。
計費模式
Buda 按 Space 收費，不按終端用戶數量收費。你作為開發者購買 Space，如何向你的終端用戶收費由你自己決定。
典型模式：
- 你向 Buda 購買 Space（批量可議價）
- 你向你的終端用戶收訂閱費（手錶啟動費、月費等）
- 差價即為你的利潤
為什麼硬體團隊會特別在意這個能力
對硬體團隊來說，這會直接改變成本結構：
- 不需要為了 AI 能力把裝置做得足夠重
- 不需要讓使用者自己的電腦或手機長期充當主執行環境
- 不需要額外養一支複雜的 AI 後端團隊，只為支撐某一條裝置產品線
你的硬體可以保持輕量，而 AI 能力持續在雲端升級。
與 ChatGPT / OpenAI 的類比
| OpenAI | Buda | |
|---|---|---|
| 面向消費者的產品 | ChatGPT | Buda App |
| 面向開發者的 API | OpenAI API | Buda OpenAPI |
| 開發者用 API 構建 | 自己的 AI 產品 | 帶 Agent + Drive 的完整 AI 空間 |
區別在於：Buda OpenAPI 不只是模型呼叫，而是提供了完整的 Agent 執行環境，包括知識庫、會話管理、工具呼叫能力。
為什麼不用 OpenClaw？
OpenClaw 是一個優秀的開源 AI Agent 專案，適合個人用戶在自己的機器上自托管運行。但對於需要規模化接入的硬體或軟體開發商，它並不是合適的選擇。
完整對比參見：Buda vs OpenClaw 深度對比
| OpenClaw | Buda | |
|---|---|---|
| 定位 | 開源個人助理，自托管 | 商業企業級平台，托管服務 |
| 基礎設施 | 運行在用戶本地機器 | 自研 Kubernetes 叢集（Claws Computer），彈性伸縮 |
| 網關架構 | 重量級 Gateway，單機瓶頸 | 無傳統 Gateway，輕量 API 層，天然橫向擴展 |
| 多租戶 | 不支援，每個實例獨立 | 原生多租戶，一個 API Key 管理百萬 Space |
| Token 管理 | 依賴用戶自行設定模型 | 商業化 Token 管理，成本可控可預測 |
| 隔離性 | 共享宿主機 OS | 每個 Agent 獨立沙箱，容器級隔離 |
| SLA & 支援 | 社群支援，無 SLA | 企業級 SLA，商業支援 |
| 適合場景 | 個人極客、開發者自用 | 硬體量產、SaaS 整合、規模化商業部署 |
一句話總結：OpenClaw 是給個人用的工具，Buda 是給開發者賣給用戶的基礎設施。
如果你要給 10 萬台手錶每台配一個 AI 助理，你需要的是 Buda，而不是在每台裝置背後跑一個 OpenClaw 實例。
常見問題
終端用戶需要註冊 Buda 帳號嗎？ 不需要。終端用戶完全不感知 Buda 的存在，你的產品透過 API 代理所有互動。
Agent 不用時會一直消耗資源嗎？ 不會。Agent 在沒有對話時處於休眠狀態，只有收到訊息時才被喚醒處理。
我能給不同用戶設定不同的 Agent 指令嗎？ 可以。每個 Space 可以有獨立的 Agent 設定，你可以按需為不同用戶建立不同的 Space 和 Agent。