BaaS for agent 怎麼設計？從 InsForge 和 Supabase 拆出三層骨架

現在的 coding agent 讀得懂 API 文件，會自己組 request，也會看錯誤訊息重試。照理說，後端只要把 API 開好，agent 自己就接得上。

但看 InsForge 和 Supabase 這兩個 BaaS，兩邊都在 agent 和後端之間多做了一層：MCP server、CLI、skills，還有專門寫給 agent 讀的文件。InsForge 從一開始就假設操作者是終端機前的 coding agent；Supabase 是為人設計的 Postgres 平台，後來才接上 agent。出發點不同，做出來的東西卻有一套共同的骨架。

這篇以 InsForge 為主、Supabase 為對照，拆開這一層到底在做什麼。

讀完這篇，你會知道：

• 給 agent 用的 BaaS 都在做哪三件事，以及三者為什麼有上下之分
• 為什麼一個假設（誰在操作、在什麼環境操作），就讓兩個平台往不同方向走
• 怎麼把同一套判斷，套到你自己要讓 agent 操作的系統上

給 agent 用的 BaaS 都在做哪三件事？

拆開 InsForge 和 Supabase 的 agent 層，做的事可以收成三層。底層是一致的介面：把資料庫、認證、儲存、函式這些服務，收成同一套認證、同一種錯誤格式、同一個控制入口。上面兩層建在它之上，一層是讓 agent 看得懂，另一層是依後果處理動作。

層	做什麼	少了它會怎樣
一致的介面	讓 agent 在一個服務學到的規則，換到下一個服務還能用；讓控制只需要做在一個地方	每個服務各學一次，護欄也要各做一次
讓 agent 看得懂	把平台的知識、狀態和錯誤，用 agent 讀得懂的形式交給它	agent 拿訓練資料裡的舊知識猜，猜錯了也不知道
依後果處理動作	依動作能不能退回、做錯的代價多大，決定放手、先改造成能退回，或攔下來交給人	建一張測試表和刪掉 production 資料，被當成同一種動作

三層之間有上下之分。「看得懂」要建在一致的介面上，agent 需要讀的 context 才會少；「處理動作」要有單一的控制入口，攔截才擋得住。

為什麼兩個平台都先把服務整合成一致的介面？

一致的介面降低的是 agent 每個 session 都要重付的學習成本，也給控制留下唯一的入口。人學一套系統，學一次就記住，成本會慢慢攤掉；agent 每開一個 session 都從零開始，五個服務就是五套認證、五種錯誤格式、五份文件，每次都要重新摸一遍。服務之間越不一致，這筆成本越高，而且每個 session 都要付。

InsForge 的整合是為 agent 刻意做的。agent 碰得到後端的入口有兩個，MCP 和 CLI，但兩者都只是 adapter：MCP 的 tool 和 CLI 的命令，最後打的是同一組 REST endpoint。驗身分、留 audit、擋危險 SQL，都寫在這些 endpoint 後面，只寫一次。給 agent 的語意也收在同一層：一次 metadata 呼叫，就把資料庫、儲存、函式等服務的現況彙整成一份回傳；各服務的錯誤，在同一個 middleware 翻成同一種格式。

這份整合的代價是平台得替每個能力親手寫一遍給 agent 用的介面。工這麼重，InsForge 就不可能什麼都接：資料庫只用 Postgres，每個能力通常只接一家 vendor，模型閘道接 OpenRouter，前端部署接 Vercel。

Supabase 也整合，但它整合的時候 agent 還沒出現。官方 Architecture 頁的產品原則裡本來就有 Everything is integrated 這一條：「Even though every product works in isolation, each product on the platform needs to 10x the other products.」每個產品都能單獨運作，放在一起時要互相放大。落到架構上，所有服務的資料和權限都收斂到同一個 Postgres：使用者存在 auth.users，檔案的 metadata 放在 storage schema，誰能讀哪一列、哪個檔案，用 RLS 寫在資料庫裡。這是為人做的整合，agent 接上之後順帶受惠。Supabase 能把 MCP 的唯讀模式做在一個唯讀的 Postgres role 上，靠的就是所有東西都在 Postgres 裡，一個 role 就涵蓋了全部。

兩邊放在一起看，整合本來就有價值，Supabase 在 agent 出現前就做了。agent 讓這份價值變大，因為它不會把學習成本攤掉，而且控制要有單一入口才擋得住。

讓 agent 看得懂，要給它哪三種東西？

agent 需要平台交給它三種資訊：狀態、錯誤和知識。模型再強，也不會知道你昨天刪了哪個欄位，也不知道上個月才改版的 API。訓練資料永遠落後於產品，這不是模型變聰明就能補的。InsForge 的兩位共同創辦人都把這件事當成核心命題。CEO Hang Huang 在 2025-10 寫道：

「The limitation is not intelligence. It is context.」（Hang Huang，〈Why Context is Everything in AI Coding?〉，2025-10）

CTO Tony Chang 在 2026-07 說得更直接：

「The agent’s intelligence was never the bottleneck. Its context was.」（Tony Chang，〈Three Levels of Trust in AI Coding Agents〉，2026-07）

InsForge 給 agent 的資訊分成三種，每一種都做進平台核心：

種類	agent 缺什麼	InsForge 的做法
狀態	現在有哪些表、哪些 bucket、部署了什麼	一次 metadata 呼叫讀回整個後端，官方流程第一步永遠是先讀它，讓 agent「works from real state rather than guessing」
錯誤	錯了之後下一步該做什麼	錯誤回傳多一個 nextActions 欄位，直接寫出下一步；這個欄位在 2025-08 第一個後端 commit 就存在
知識	現在這一版的 API 怎麼用	文件由 server 端回傳，跟部署的版本一致；skill 規定寫 code 前先拉文件，文件寫錯時 agent 用 feedback 命令回報

Supabase 走的是另一條路。它不為 agent 改核心，所以給 agent 的資訊都放在核心外面：MCP 的 tool 說明、Postgres best practices skill、llms.txt 和每頁一份的 Markdown。鋪得很廣，問題是 agent 讀不讀。Supabase 在 2026-07 推出自己的 evals，量出 skill 原本大約十個 session 才載入一次，就算載入了，「Claude Code checks our docs in under 40% of scenarios even with skills loaded.」改寫 skill 的描述之後，載入率升到 60%。資訊放出去了，agent 有沒有拿到，要量過才知道。

agent 的動作，該放手、先改造，還是攔下來？

agent 要執行的動作，後果差很多：在 dev 建一張測試表，錯了刪掉就好；刪掉 production 的使用者資料，就回不來了。這一層要做的，是把動作依後果分開處理，判準有兩個：能不能退回，以及做錯的代價和成本有多大。AWS 有個類似的說法，把決策分成雙向門和單向門：雙向門走錯了可以退回，應該讓它快；單向門走過去就回不來，要慢、要有人看。依這兩個判準，處理方式有三種。

放手。 能退回、代價低的動作，直接交給 agent。InsForge 讓 agent 在自己的業務 schema 裡全權操作，建表、改欄位，連 DROP TABLE 都不擋。它擋的是會讓 agent 爬出這個範圍的語句，例如切換 role、改 search_path、自己控制交易。每次執行前，InsForge 先把連線換成 project_admin 這個角色，agent 能碰什麼，交給資料庫的角色權限判斷。授權決定了 agent 碰得到哪些動作，放手的是這個範圍裡的全部。

改造成能退回。 有些動作本來回不去，但可以換個地方做，讓它變得回得去。最典型的工具是 branch。InsForge 的 branch 是一個完整的子專案，有自己的 Postgres、auth 設定、storage、edge functions、email 範本、realtime channel 和排程，預設用 full 模式連資料一起複製。agent 在 branch 上改完，merge 前可以用 --dry-run 預覽要套用的 SQL；merge 用三方比對，parent 在這段期間被改過就整個擋下；改壞了可以 reset 回到建立時的快照。一個在 production 上退不回來的 schema 變更，搬到 branch 上就變成可以丟掉重來的動作。唯讀也是一種改造：把寫入整個拿掉，剩下的動作全都沒有副作用。

攔下來。 改造不了的動作，就交給人，或固化成固定的流程。InsForge 的 CLI 在 merge branch、刪除 branch、reset、處理 secrets 之前會問 Y/N；刪除整個專案時，文件直接寫：

「Never pass --yes here, and have a human verify the exact project id before the command runs.」（InsForge docs，CLI harness）

刪專案這一步，要有人親眼核對專案 id。CLI 0.2.8 另外加了一個本機的 human-approval guard，原始碼的註解說明了它為什麼放在 CLI 裡：

「inside the insforge binary itself (not in any agent’s harness), it protects EVERY caller」（InsForge CLI，lib/guard/index.ts）

攔截做在被呼叫方，不管是哪一個 agent、用哪一種 harness 呼叫，都會經過同一道關卡。這也是一致的介面在這一層的回報：入口只有一個，關卡裝一次就夠。

攔下來不一定要交給人。Supabase 讓 production 的變更只能走 PR 和 CI：agent 把 migration 寫成檔案、開 PR，人 review 後 merge，再由 CI 套到 production。這條路上沒有 agent 的判斷，每一步都是寫死的程式。把會改到 production 的動作固化成 pipeline，就是把確定性的流程放進 agent 系統裡；skill 和 tool 也是同一類東西，把 agent 不該臨場發揮的部分寫死。

處理動作還牽涉到一個問題：是誰在執行。InsForge 的 MCP 用一把 admin key，拿到它就代表整個專案；Supabase 的 hosted MCP 代表的是開發者本人，官方說「The MCP server operates under the context of your developer permissions」。agent 拿到的都是開發者等級的身分，平台能做的是縮小範圍：InsForge 靠 project_admin 角色和 SQL guard，Supabase 靠 project_ref 鎖專案、features 決定開哪些 tool，再加上唯讀的 Postgres role。

同一套骨架，為什麼 InsForge 和 Supabase 走向不同？

兩個平台的分岔來自同一個假設：誰在操作，在什麼環境裡操作。InsForge 的文件開宗明義寫：

「Most backends assume a human in a dashboard. InsForge assumes a coding agent at a terminal.」（InsForge docs，Agent-Native Initiatives overview）

它假設的 agent 坐在終端機前，在開發者自己的專案裡工作。Supabase 假設的操作者是人，agent 是 Management API 的另一個 client，而它碰到的專案，可能就是有真實使用者資料的那一個。這個假設一路往下推，三層各自分岔：

	InsForge	Supabase
假設誰在操作	coding agent，在開發者自己的專案裡	人；agent 是另一個 client，可能碰到真實使用者的資料
服務怎麼整合	專門為 agent 做：MCP 和 CLI 打的是同一組 API	原本就為人做：全部收在 Postgres 裡，agent 直接沿用
agent 怎麼知道怎麼用	平台直接告訴它：回傳現況、錯誤附上下一步、文件跟著版本走	放在平台外面讓它讀：tool 說明、skill、文件，再量它有沒有讀
危險的動作怎麼處理	先在 branch 上做，改壞了丟掉，很少攔	不讓 agent 碰 production，花錢和刪資料前先問人

分岔最明顯的是第三層。兩邊處理退不回來的動作，基本工具一樣，都借自 git 的 branch：先開一條分支隔離出去試，確認了再合回來，不要就整條丟掉。差別在分支裡放什麼，以及分支之外怎麼攔。

InsForge 假設 agent 在開發者自己的專案裡，大部分動作都可以先在 branch 上做，所以 branch 預設連資料一起複製，agent 在跟原本專案一樣的資料上試。分支之外的攔截就做得很輕：MCP 不做任何確認；CLI 的 Y/N 用 --json 執行時會跳過，而 agent 通常就是這樣執行的；human-approval guard 預設關閉，要自己開。

Supabase 假設 agent 可能碰到真實使用者的資料，第一步就是讓 agent 根本碰不到 production。官方〈Defense in Depth for MCP Servers〉的原話是「Never connect AI agents directly to production data.」agent 不該看到真實資料，branch 就只複製 schema。攔截則做在 MCP 層：建專案或 branch 要付費時，先把費用給人看；SQL 裡有 DROP、DELETE、TRUNCATE，先把 SQL 給人看，人按同意才執行，而且沒有「全部跳過」的開關。

所以兩個平台適合的情境不同：InsForge 適合 agent 碰到的東西大多能退回的情境，用「改造成能退回」換速度；Supabase 適合 agent 可能碰到退不回來的東西的情境，用「遠離加攔截」換安全。

要讓 agent 操作自己的系統，該怎麼判斷？

把前面的骨架和分岔收起來，可以整理成五個步驟。不管你要讓 agent 操作的是後端、內部工具，還是一套既有的服務，都可以照這個順序問：

1. 誰在操作，在什麼環境？ 這是唯一的分岔點，後面每一步的答案都跟著它變。agent 碰得到的範圍裡有沒有真實使用者的資料，比 agent 用哪個模型更重要。
2. 把動作列出來，標上能不能退回、做錯的代價多大。 建一張表和刪一張表不一樣，在 dev 刪和在 production 刪也不一樣。代價也包含錢：開一個新環境要付費，就算能刪掉，也該被當成一個需要看的動作。
3. 能退回、代價低的動作，放手給 agent。 用授權把範圍畫好，範圍裡的事不要一件件攔，否則 agent 寸步難行。
4. 退不回來的，先想能不能改造成能退回的。 branch、用完即丟的環境、唯讀權限、先 dry-run 再執行，都是把退不回來的動作改造成能退回的工具。
5. 改造不了的，固化成流程，或交給人點頭。 寄信給使用者、扣款、套用到 production 的 migration，這些動作做了就回不來。把它寫成 CI pipeline、skill 或專用的 tool，或在執行前讓人確認，而且確認要做在被呼叫方，所有呼叫者都會經過。

以一個已經有付費使用者的 SaaS 後端為例，走一遍大概是這樣：

動作	做錯了會怎樣	歸類	怎麼處理
在 dev 建表、改欄位	刪掉重來就好	放手	讓 agent 直接做
改 production 的資料表結構	改壞了，線上使用者馬上受影響	先改造	先在 branch 上試，再經過 PR 和 CI 上線
查 production 的資料找 bug	只讀不寫，不會改壞東西	先改造	給一條只能讀的連線；資料敏感就不給連
開一個要付費的新環境	可以刪，但錢已經花了	攔下	開之前先讓人看費用
刪除使用者資料、寄信給使用者	做了就收不回來	攔下	寫成固定流程，或先讓人確認

這張表裡，agent 自由發揮的部分和寫死的部分混在同一個系統裡。前兩步決定了哪些地方交給 agent 判斷、哪些地方用固定的流程守住，組裝的比例取決於你的系統裡有多少退不回來的動作。InsForge 和 Supabase 做的是同一套骨架，只因為對誰在操作的假設不同，放手和攔下的界線畫在了不同的地方。