InsForge 01：一個為 coding agent 設計的後端長什麼樣
「Most backends assume a human in a dashboard. InsForge assumes a coding agent at a terminal.」（InsForge docs，Agent-Native Initiatives overview）
InsForge 是一個 Backend-as-a-Service。光看能力清單，它跟其他 BaaS 差不多。差別在設計時預設的操作者：傳統後端假設有人坐在 dashboard 前面點，InsForge 假設下指令的是一個在 terminal 裡跑的 coding agent。
這個假設聽起來只是換了使用者，實際上會一路改掉很多東西：狀態怎麼呈現、錯誤怎麼回、設定放在哪、權限給多少。在 2026-03-09 的〈InsForge 2.0: The Backend Built for Agentic Development〉裡，官方說平台上 99% 的操作來自 agent，這個假設已經反映在他們實際的流量上。
這篇不談 API 細節，只回答一個問題：如果後端的第一操作者是 agent，架構會長成什麼樣子。
讀完這篇，你會理解：
- 操作者從人換成 agent 之後，後端設計會跟著改的幾件事，以及 InsForge 背後的四條哲學
- InsForge 的架構全貌：兩個對等介面、護欄、provider 層各自為什麼存在
- 它刻意不做的事（沒有 read-only、MCP 不做執行前確認）為什麼也是設計的一部分
當操作者從人變成 agent，後端設計的三個前提不再成立
傳統後端的很多設計，背後都藏著一個沒寫出來的前提：操作的人有眼睛、有記憶、會停下來想。人打開 dashboard 看一眼，就知道有哪些表；昨天建了什麼，今天還記得；看到一行錯誤，會先查文件再動手。
換成 coding agent，這三個前提都不成立。
| 情境 | 人怎麼做 | agent 怎麼做 |
|---|---|---|
| 了解現況 | 人打開 dashboard，掃一眼就知道有哪些表和設定。 | agent 只能讀文字，畫面上的東西它看不到。 |
| 延續工作 | 人記得昨天改過什麼。 | agent 每個 session 都從零開始，必須重新把狀態讀回來。 |
| 遇到錯誤 | 人會停下來想，必要時去翻文件。 | agent 傾向直接重試，或憑印象猜下一步。 |
InsForge 對這三個落差的回應，可以收斂成四條哲學，每一條都能在官方文件裡找到對應的說法。
Agent 不笨，是瞎。 CTO Tony Chang 在 2026-07 的〈Three Levels of Trust in AI Coding Agents〉裡寫道：
「Your agent isn’t dumb, it’s blind.」
他想說的是，agent 出錯的時候，多半缺的是資訊，能力本身夠用。所以平台要負責把狀態、文件、錯誤原因都變成 agent 讀得到的文字。
給能寫文字的東西用。 CLI harness 文件裡有一句話：
「A dashboard is built for a human pointer; a CLI is built for anything that can write text.」（InsForge docs，CLI harness）
Dashboard 是為了拿滑鼠的人做的，CLI 則是任何會寫字的東西都能用。對 agent 來說，文字進、文字出的介面才是主介面，dashboard 就退到旁邊。
人定義意圖並 review，agent 執行。 InsForge 在比較頁上把分工講得很直接：在傳統平台上，人負責「implement and execute」；在 InsForge 上，人負責「define intent and review」（InsForge docs，alternatives）。人不再一步步動手，而是說清楚要什麼，再看 agent 交回來的結果。這也決定了 review 該放在哪裡：放在人看得懂的 diff、migration 檔和 PR 上，而不是每一次 tool call 上。
The agent’s hands。 官方文件把 CLI 稱為「the agent’s hands」（InsForge docs，Agent-Native Initiatives overview）。平台提供的是動手的工具，本身沒有內建 agent loop。平台裡用到 LLM 的地方只有兩處，都是輔助性質：後端用它抽取記憶，CLI 的診斷指令用它把診斷資料轉成白話。要做什麼、先做哪一步，都由外部的 coding agent 決定。
InsForge 的架構：兩個對等的介面、一道護欄、一層可替換的 provider
從上往下看，coding agent 有兩隻手可以碰到後端：MCP server 和 CLI。兩條路最後都打進同一個 InsForge instance，先經過認證與護欄，再進到後端的業務邏輯，最底下是一排 provider，負責接真正的資料庫、儲存、運算和外部服務。
兩隻手為什麼要對等。 README 這樣描述這兩個介面：
「Both interfaces let coding agents operate the backend like backend engineers.」（InsForge README）
兩者能做的事大半重疊，查表、建 bucket、看 log 兩邊都行。MCP 是編輯器原生的接法，Cursor、Claude Code 這類工具接上就能用；CLI 則是任何有 shell 的地方都能跑，CI、sandbox、沒有 MCP client 的 agent 都行，而且每個命令都有 --json，agent 不用另外學一套協定。InsForge 沒有替兩者劃出嚴格的分工，倒是從 2026 年起明顯把重心放在 CLI 加 skills 上，官方的 agent 文件直接寫「A coding agent drives it end to end through the InsForge CLI and agent skills」（insforge.dev/agents.md）。這背後是整個產業都在問的問題：給 agent 的介面，該走協定還是走命令列。
Provider 層為什麼存在。 後端程式一律分三層：route 接請求，service 放邏輯，provider 接外部 vendor。同一個能力底下可以掛不同的 provider，例如儲存可以用本機檔案，也可以用 S3；運算可以跑在本機 Docker、Fly，或 InsForge 自己的 cloud。cloud 版和自架版的差異，大多也收在這一層。
對 agent 來說，這一層換來的是穩定的介面：cloud 版和自架版對外是同一組 tool 和命令，agent 學過的用法在兩邊都成立。不過要說明的是，目前真正能在多個 vendor 之間切換的只有運算這一塊，其他能力多半是「InsForge cloud 或自己架」兩種實作而已。
護欄放在唯一的入口。 兩隻手送進來的請求，都要先過認證 middleware。這道門依 credential 的形狀分派身分，驗證失敗就直接拒絕，不會退一步降級成權限較低的身分。至於這道門擋什麼、不擋什麼，下一節的 Guardrail 層再談。
Agent 需要什麼，後端就長成什麼：從 Context 到 Capability 的五個設計決定
這個系列用五層來看 agent 使用的基礎設施：agent 怎麼學會用它（Context）、能做什麼（Action）、不能做什麼（Guardrail）、可以在哪裡試錯（Isolation）、底下有哪些能力（Capability）。InsForge 在每一層都有一個最能代表它想法的設計。
Context：文件跟著部署的版本走。 agent 很常照著訓練資料裡的舊 API 寫 code。InsForge 讓文件由 server 端回傳，內容和當下部署的版本一致，並在給 agent 的指令文件裡用醒目的標記寫明：寫任何整合程式之前，一定要先拉文件。知識過期這件事，平台直接替 agent 處理掉。這套文件機制後來演進了三代，下一篇會細講。
Action：狀態一次讀回，設定寫成文字。 InsForge 沒有把「列出所有表」「列出所有 bucket」拆成一堆細碎的 tool，而是用一次 metadata 呼叫回傳整個後端的現況。官方的工作流程第一步永遠是先讀 metadata，讓 agent「works from real state rather than guessing」（InsForge docs，CLI harness），也就是照著真實的狀態做事，不靠猜。設定也是同樣的思路：Auth、儲存、部署的設定都寫在一份設定檔裡，先 plan 看差異，再 apply 套用，秘密只用環境變數引用，不寫進檔案。設定變成文字之後，就能 diff、commit、review。
Guardrail：擋逃逸，不擋破壞。 這是 InsForge 最容易被誤解的一層。agent 透過 raw SQL 執行 DROP TABLE 或 DELETE，InsForge 不會攔。它攔的是會改變執行環境的語句：切換 role、改 search_path、解除 timeout、管理 role、自己控制交易，以及碰系統表和使用者帳號表。agent 可以對自己的業務 schema 做任何事，但不能爬出沙箱去動底層 Postgres 的權限模型。
另一個刻意的選擇是信任 admin key。MCP 用的是一把 admin key，拿到它就有整個專案的權限，沒有唯讀模式，也沒有再細分。Supabase 在這一層走的是相反方向，用唯讀模式和執行前確認把護欄做厚，這部分留到之後的系列再比。
確認也做得很輕。MCP 送出就執行，不跳確認；CLI 在 merge 或刪除 branch、reset、處理 secrets 這類命令前會問 Y/N，但加上 --yes 或 --json 就會跳過，而 agent 通常就是用 --json 跑。CLI 0.2.8 另外加了一道本機的 human-approval guard，做在 CLI 本身，不管哪個 agent 呼叫都會經過，但預設關閉，要用 INSFORGE_GUARD=1 或 link --guard 自己打開。
Isolation：branch 整個後端，不只資料庫。 要做有風險的變更時，agent 可以把整個後端 clone 成一個子專案，資料庫、Auth 設定、儲存、edge functions、排程都一起複製。branch 預設用 full 模式連資料一起複製，也可以選 schema-only 只帶結構；儲存裡的檔案不複製，直接讀 parent 的。在 branch 上改完之後，先預覽要套用的 SQL，再用三方比對 merge 回去；如果 parent 在這段期間被改過，merge 會因為衝突停下來。因為副本連設定都包含在內，像「換一個 OAuth provider」這種變更也能先在副本上試。代價是每個 branch 都是一整套環境，成本比只重放 migration 高得多。
Capability：能力清單延伸到部署、運算與收費。 資料庫、Auth、儲存、函式這些 BaaS 標配它都有，另外還把前端部署、長駐容器和金流串接也收進同一個平台，讓 agent 從建表做到上線都不用換平台。這幾塊大多是包裝現成的 vendor，例如前端部署交給 Vercel、金流交給 Stripe。
沒有 read-only、確認可以跳過：InsForge 選擇相信 agent，代價是什麼
讀到這裡，InsForge 少了幾樣東西已經很明顯。這些不是遺漏，而是同一套哲學的另一面。
| 沒有做的事 | InsForge 的考量 | 付出的代價 |
|---|---|---|
| 沒有唯讀模式，也不分權限群組 | 拿到 admin key 的 agent，就被當成受信任的操作者。 | agent 一旦被 prompt injection 誘導，平台端沒有第二道防線。 |
| MCP 不確認，CLI 的確認可以跳過 | CLI 每個命令都能用 --json 非互動跑，agent 不會卡在提示上；human-approval guard 預設關閉。 | 沒有打開 guard 時，破壞性操作送出就生效，回不了頭。 |
| 建表時不強制開 RLS | 安全檢查改成事後掃描，期待 agent 跑診斷後自己修。 | 從建表到被掃出來之前，拿 anon key 的人都讀得到這張表。 |
| dashboard 是配角 | 官方明確要求不要把 InsForge 描述成 no-code 或點選式的 dashboard 產品。 | 不用 agent 的人，用起來會比較陽春。 |
有一個地方的方向剛好相反。CLI 的確認大多可以用 --json 跳過，唯獨刪除專案這個命令反過來加摩擦：專案 id 必須明確填寫，不能沿用目前連結的專案。文件寫得很直接：
「Never pass
--yeshere, and have a human verify the exact project id before the command runs.」（InsForge docs，CLI harness）
意思是，刪專案這一步不要讓 agent 自己按下去，要有人親眼核對 id。可見 InsForge 認真劃分過哪些事可以讓 agent 順手做掉，哪些事一做就回不來。
本文判讀。 我認為這套取捨在它的目標情境裡說得通：agent 在自己的專案上快速迭代，表被 DROP 了可以重建，真正不可逆的只有刪掉整個專案。但它把安全押在兩個前提上，一是使用者會在需要時自己打開確認（MCP 不攔、CLI 的提示可以跳過、guard 預設關閉），二是 agent 本身沒有被誘導。只要其中一個不成立，平台端能擋住的就只剩「不能爬出沙箱」這一條。要拿 InsForge 處理正式資料，這一層得自己補上。
設計啟示
- 讓整個狀態能被一次讀回。 agent 每次開工都從零開始，它對系統的理解只來自它讀得到的東西。一次呼叫就能拿到全貌，它就不必拼湊，更不必猜。
- 錯誤訊息的讀者是一個會重試的程式。 人看到錯誤會停下來想，agent 會直接再試一次。錯誤裡如果寫明下一步該做什麼，重試才會往對的方向走。
- 設定寫成文字，review 才有地方落腳。 人很難檢查 agent 點過哪些按鈕，卻能讀懂一份 diff。把設定和 schema 變更做成檔案，人就能在熟悉的地方審核 agent 的工作。
- 有風險的變更先在可丟棄的副本上跑。 副本涵蓋的範圍要跟變更的範圍一樣大，只複製資料庫的副本，測不出設定改動帶來的問題。
- 相信操作者，但守住它爬出沙箱的路。 每個破壞性操作都擋，agent 會寸步難行；什麼都不擋，又太危險。比較好的切法是允許它在自己的範圍內犯錯，但不讓它改變自己的範圍。
下一篇會把前兩條往下挖：錯誤裡的「下一步」在 InsForge 的 code 裡是怎麼來的，文件又是怎麼從一份 MCP 操作手冊，一路長成上萬行的 skills。