InsForge 03：agent 能直接打 API，為什麼還要多隔一層
「A single agent is an intelligence problem. A million agents is a distributed systems problem.」（Tony Chang，CTO，$8M seed 報導，2026-09）
前兩篇拆了 InsForge 怎麼為 agent 設計後端：架構怎麼擺、權限怎麼畫、錯誤怎麼回、文件怎麼給。讀完之後，很自然會冒出一個問題：現在的 coding agent 已經能自己讀 API 文件、直接打 Postgres、S3、Stripe、Vercel，為什麼還要在中間多隔一層 InsForge？
這層看起來很費工。InsForge 要替每個能力親手寫一遍給 agent 用的介面、錯誤提示和文件，還要一直跟著底下的服務更新。照理說，模型越強，這種中介層應該越不需要。但 InsForge 在 2026 年 9 月拿到了 800 萬美元的種子輪。
開頭那句話給了一個線索：單一 agent 的問題是智慧，一百萬個 agent 的問題是分散式系統。模型越強，agent 越能自己接上任何一個 API；它自己湊不出來的，是跨所有服務的一致性：同一份狀態、同一種錯誤語言、同一道護欄邊界、同一個可以回滾的地方。這篇要論證的是，InsForge 賣的就是這份一致性，而那份「費工」本身就是它的護城河。
讀完這篇，你會理解：
- agent 直接操作各家服務時，真正卡住它的是什麼，以及為什麼模型變強反而讓問題更貴
- 給 agent 的後端裡，哪些部分抄得走，哪些抄不走，InsForge 又把資源押在哪裡
- 當 agent 自己成為使用者，基礎設施的設計重心要怎麼移，以及什麼時候值得多隔這一層
讓 agent 直接打 API，會卡在哪裡
先公平地說：很多時候，讓 agent 直接打 API 就夠了。只用一個服務、有人在旁邊看著、做完就丟的任務，agent 讀完文件直接呼叫，比多學一層平台更快。
問題出在服務變多、時間拉長的時候。假設 agent 要從零做一個有登入、資料庫、檔案上傳、前端部署和收費的 app，直接打 API 意味著它要同時面對五家服務：
| 面向 | agent 直接打各家 API | 經過一層 agent backend |
|---|---|---|
| 了解現況 | agent 要分別查資料庫、儲存、部署平台，自己把結果拼起來。 | agent 呼叫一次，就拿到整個後端的現況。 |
| 遇到錯誤 | 每家的錯誤格式不同，agent 要自己判斷每種錯誤代表什麼。 | 錯誤用同一種格式回來，而且附上下一步。 |
| 讀文件 | agent 靠訓練資料或臨時搜尋，五份文件各有各的版本。 | 文件跟著部署版本走，拿到的就是現在這一版。 |
| 權限 | 五把 key 各管各的，沒有一個地方能統一擋住 agent 越界。 | 所有操作都經過同一道身分邊界。 |
| 回滾 | 改壞了，agent 要分別去五個地方復原。 | 有風險的變更先在可丟棄的副本上跑。 |
這張表的每一列，都是 agent 自己做得到、但每次都要重做一遍的事。它每開一個新 session，就要重新 survey 一次每個服務；它每猜錯一次錯誤的意思，就多燒一輪 token；它每拿一把新的 key，系統就多一個沒有人統一看管的入口。
InsForge CEO 在〈Why Context is Everything in AI Coding〉（2025-10）裡把這種失敗歸成兩類：
「Without solid context engineering, even the best model will make wrong assumptions and produce messy code.」
一類是知識過期，例如前端套件改版之後，agent 照著舊寫法一路失敗；另一類是資訊不完整，例如 agent 查到幾個月前就刪掉的欄位，或寫出繞過真實授權規則的 code。兩類都跟模型聰不聰明無關，跟它手上的資訊有關。
所以中間這一層要做的事，不是讓 agent「打得到」API，那件事它自己就做得到。這一層要做的，是讓 agent 不必每次都自己把五家服務拼成一個一致的世界。
模型越強，缺 context 的代價反而越大
直覺上，模型越強，越能從零碎的資訊裡推出正確答案，中介層的價值應該越來越小。InsForge 拿出一份數據，主張剛好相反。
他們用 MCPMark 這套 benchmark 跑了兩次，對照組是 Supabase 的 MCP server，第一次用 Sonnet 4.5（2025-12），第二次換成更強的 Sonnet 4.6（2026-03）：
| 指標 | Sonnet 4.5 | Sonnet 4.6 |
|---|---|---|
| InsForge 每次執行的 token | 8.2M | 7.3M |
| 對照組每次執行的 token | 11.6M | 17.9M |
| token 差距 | 1.4x | 2.4x |
| InsForge 的 Pass⁴ | 47.6% | 42.9% |
| 對照組的 Pass⁴ | 28.6% | 33.3% |
InsForge 對這份數據的解讀是：
「More capable models do not eliminate the need for structured backend context. They amplify the cost of not having it.」（InsForge，MCPMark v2，2026-03）
更強的模型不會讓結構化的後端 context 變得多餘，反而會放大缺少它的代價。原因是更強的模型在 context 不完整時，會推理得更多、嘗試得更多，token 燒得更兇。能力越強，在黑暗中摸索得越賣力。
這份數據是 InsForge 自己跑、自己解讀的，看的時候要打點折扣，但方向是對的：模型能力的成長，沒有讓「agent 需要正確、即時、結構化的資訊」這件事消失。模型再強，也不會知道你昨天刪了哪個欄位。
這也延伸出一個常被忽略的好處：這層設計能壓低 model drift 帶來的傷害。換模型、模型更新、行為變得不一樣，這些都是 agent 系統的日常。這時要分兩件事看：
- 安全的下限不會跟著模型漂移。 身分邊界、SQL guard、branch 都在平台端執行，跟模型是哪一版無關。換上一個比較不穩的模型，它能闖的禍仍然被同一條線擋住。
- 成功率還是會漂移。 文件綁版本、狀態讀回、錯誤附下一步，能降低「靠模型記憶和猜測」的比例，讓結果不那麼依賴某個特定模型；但它沒辦法保證每個模型都一樣好，InsForge 自己的 Pass⁴ 下降就是例子。
所以比較準確的說法是：把 context 和護欄放在平台這一側，穩住的是系統的下限與行為的一致性，而不是讓模型的能力變得無關緊要。
介面抄得走，一致性抄不走
如果 InsForge 的價值只在「有 MCP、有 CLI、有 skills」，它應該很快就會被追上。事實上也正在被追上：對照組的 MCP server 已經做到 39 個 tool，幾乎每家開發工具都開始提供自己的 skills，給 agent 的文件格式也越來越標準。
所以該問的是：一個給 agent 用的後端，哪些部分別人抄得走，哪些抄不走？
我把它拆成五層來看：
介面：抄得走。 MCP tool、CLI 命令、skill 檔案都是公開的形式，任何一家服務都能在一兩個月內做出自己的版本。協定越標準，這層越沒有差異。
Context 正確性：追得上。 狀態一次讀回、錯誤附下一步、文件跟著版本走，01 和 02 都拆過。這些設計不難懂，別人也在做，例如對照組後來也補上了讀 migration 紀錄、跑安全檢查的 tool。InsForge 在這層的優勢是完整度和起跑得早，但差距會縮小。
跨服務的護欄與隔離：要接完每個服務才做得到。 02 講過，InsForge 的身分邊界、SQL guard、audit 都寫在所有入口後面的同一層，branch 能把資料庫、Auth 設定、儲存、函式一起複製。這件事的前提是平台擁有每一個服務的操作權。一個只包裝資料庫的 MCP server，沒辦法替 agent 的部署、寄信、收費也畫上同一條線。
累積的 agent 失敗知識：要時間。 InsForge 的錯誤提示目錄長到 21 條，每一條都來自一次 agent 真的卡死的 bug；skills 裡那些「不加 -y 就會永遠卡住」的規則，是看著 agent 撞牆才寫得出來的；feedback 命令還讓 agent 自己回報文件跟現實不符的地方，官方說這類回報「often becomes the doc fix」。這些知識可以被讀走，但產生它的過程抄不走。
擁有資料庫與運算：要整個平台。 metadata、advisor、branching 都建立在「我擁有這顆 Postgres」上。InsForge 被問到要不要支援其他資料庫時，回答是「focus is purely on Postgres」。運算也一樣，要能隨時開一個隔離的環境、沒流量時縮到零，得自己掌握底下的機器。
越往下，越需要把每個服務真的接一遍、真的跑一段時間。這就是開頭那個疑問的答案：替每個能力寫一遍整合確實很費工，但正因為費工，它才不容易被抄。介面是一個週末的事，一致性是兩年的事。
那為什麼投資人會買單？我們拿不到投資人的理由，只能從公開訊號推。2026 年 3 月的 2.0 發布文說，平台上 99% 的操作來自 agent，2025 年 11 月起資料庫建立量成長了 500%。YC 公司頁列出的 agent-native 特性是「structured outputs, readable errors, branching, scoped permissions, and reversible writes」，五項裡有三項是護欄與隔離。
我認為這些訊號指向同一件事：InsForge 押注的不是「agent 需要一個比較好用的後端介面」，而是「agent 會變成後端最主要的使用者，而且數量會很多」。在那個世界裡，能讓大量 agent 安全、一致地操作所有服務的那一層，就算介面被抄走，大家還是會選它，因為換掉它的成本是重新接一遍所有服務。
他們看到介面守不住，所以往下挖
InsForge 自己顯然也看到了介面這層守不住。從幾個訊號可以看出他們觀察問題的角度在轉：
- 被問到跟對照組的差別時，答案從功能變成生態。 在 Hacker News 上，他們的回答大意是：對方是一條線，我們是一整個生態。這是一個承認「單看介面差不多」的回答。
- benchmark 的題目從「比模型」換成「比介面穩定度」。 2026 年 6 月的 Agent Benchmark 不再跨模型比較，而是跑 30 個任務、每題三次，看結果能不能重現。官方的結論是「Repeatability appears to be the most useful signal here」，可重現性才是最有用的訊號。
- 公司的自我描述換了。 YC 公司頁的描述，從「Supabase 的替代品」變成「The agent-native serverless cloud」。
策略也跟著轉，資源往抄不走的那幾層壓。2025 年 8 月，〈Focus or Die〉這篇文章砍掉了 OAuth、logs、團隊管理和 serverless functions，只留一件事：讓 coding agent 能做完整個應用：
「The No. 1 enemy of startups isn’t competition. It’s trying to build everything at once.」（InsForge，〈Focus or Die〉，2025-08）
新創最大的敵人不是競爭者，是想一次做完所有事。這份紀律後來體現在「每個能力只接一家 vendor」上：模型閘道只接 OpenRouter，前端部署只接 Vercel。
但有一個例外。02 的分層裡，大多數能力的 provider 抽象，是為了讓同一份 code 能跑在不同環境，不是為了讓使用者自由換 vendor。真正做成可切換 vendor、會自動探測哪個可用、每筆資料都記住自己跑在哪家的，只有 compute 一個。一個只接一家 vendor 的團隊，唯獨在運算上花力氣做抽換，說明他們知道這塊會是主戰場。
之後的動作順著這個方向走：2026 年 5 月連發 Custom Compute、Backend Branching、Config as Code，9 月拿到種子輪、改名 InstaCloud，每個服務跑在獨立的 microVM 裡，沒有流量時縮到零。
這條路線的邏輯很一致。介面會被追上，就把重心從「怎麼讓 agent 操作後端」往下移到「讓 agent 有一個可以安全、大量、便宜地跑東西的地方」。前者是一座橋，後者是地基。
當 agent 自己是使用者，設計重心要往哪裡移
前面談的大多是「人帶著 coding agent 做 app」。InsForge 押注的另一個情境更極端：沒有人在對話框的另一端，agent 自己就是使用者。它要自己開專案、自己存狀態、自己跑長駐的服務，人只在 review 時出現。
這個情境裡，原本為人設計的基礎設施假設會一個個失效，設計重心要往這幾個方向移：
身分：agent 要能自己拿到身分，而且權限要能縮到很小。 傳統雲服務的註冊流程是一張給人填的表單。InsForge 做了兩件事：讓 agent 用它所在平台簽發的身分直接註冊（目前還在 preview），以及在沒有瀏覽器的環境裡，讓人在別處掃碼授權，並把權限縮到只能讀寫專案。官方的說法是：
「An agent can provision your whole cloud autonomously, with no human sign-up form required.」（InsForge，agents 文件）
agent 不用經過任何人類表單，就能自己開好整個雲端環境。這句話的另一面是：身分和權限的設計，必須假設申請的那一方可能不是人。
狀態：agent 要有地方放記憶和長時間跑的工作。 一個 session 結束，agent 學到的東西就消失。InsForge 提供了記憶 API，讓 agent 把對話紀錄丟進去，由平台抽取、整併後存起來；也提供長駐的容器，讓 agent 能跑排程和背景服務。
成本：一百萬個 agent，大多數時間都是閒著的。 給人用的服務可以假設流量有規律，給 agent 用的服務卻可能同時開出上萬個專案，其中大部分很少被呼叫。沒有流量時縮到零，是讓這種使用模式付得起的前提。這也是開場那句話說「一百萬個 agent 是分散式系統問題」的意思。
爆炸半徑：錯誤一定會發生，重點是能不能收回來。 人在旁邊看著時，錯誤可以被即時攔下；無人值守時，只能靠事前限制和事後復原。branch、可以回滾的寫入、縮小範圍的權限，在這個情境裡從「好用的功能」變成「必要的安全網」。
人的位置：從核准每個動作，退到 review 結果。 01 引過官方的說法，人的角色從「implement and execute」變成「define intent and review」。在 agent 自己是使用者的情境裡，這條線被推得更遠：人不會看到每一個操作，只會看到結果和異常。所以系統要能讓結果被 review，例如每個變更都有紀錄、每個環境都能被列出來、每個異常都會被診斷出來。
對照一下就能看出這個情境有多不一樣：Supabase 的 MCP 文件明白寫著「Don’t give to your customers」，它的 MCP 是給開發者用的工具。InsForge 反過來，把 agent 當成第一等的使用者，連身分和計費都為此設計。我認為這是 InsForge 最難被取代的一塊，因為它不是在既有的服務外面包一層 agent 介面，而是從身分、成本到復原機制，整套為不是人的使用者重新想過。
什麼時候，值得多隔一層
回到開頭的問題：agent 能直接打 API，為什麼還要多隔一層？
我的判準是看三件事：
- 服務有多少個。 只用一個服務，agent 直接打就好；服務一多，拼湊一致狀態的成本就會超過學一層平台的成本。
- 有沒有人在旁邊看。 有人盯著的時候，人就是護欄；無人值守的時間越長，越需要一道不依賴模型的邊界。
- 錯一次的代價有多大。 做完就丟的 PoC，錯了重來就好；會碰到真實使用者資料的系統，就需要可以丟棄的副本和可以收回的寫入。
三件事越往高的那一端走，越值得多隔一層。用這個判準看 InsForge：
| 情境 | 適不適合 | 原因 |
|---|---|---|
| 一個人帶著 coding agent 從零做一個 app | 適合 | 從資料庫、登入到前端部署和收費，agent 不用換平台，這是它的設計原點。 |
| 既有 app 補後端或從其他平台遷移 | 看情況 | 資料本來就在 Postgres 的話，schema 和權限規則搬得過來；深度依賴其他平台獨有功能的，就得重做。 |
| agent 自己是使用者 | 最有特色 | 自主註冊、記憶、長駐運算、縮到零，都是為這個情境設計的。 |
| 資料不在 Postgres | 不適合 | InsForge 只接自己的 Postgres。 |
| 需要合規證據或正式的 SLA | 不適合 | 官方自己寫著正式使用前要先確認，相關證明只在企業方案提供。 |
| 無人值守的 agent 要碰正式資料，而且只能唯讀 | 不適合 | InsForge 沒有唯讀模式，一把 key 就是全部權限。 |
最後把三篇收在一起看。InsForge 這套設計，表面上是 context engineering：讓 agent 拿到正確、即時、結構化的資訊。往下看，它其實也是 harness engineering。InsForge 把 CLI 的文件直接命名為「CLI harness」；它雖然不擁有 agent loop，那是 Claude Code 這類工具的事，但它從環境這一側補上了 harness 的元件：tool 的顆粒怎麼切、錯誤怎麼回饋、權限邊界畫在哪、有沒有可以丟棄的沙箱、出問題時怎麼診斷、指令文件怎麼給。我在〈你在比的是模型，但決定 Claude Code 效果的是 Harness〉裡談過，同一個模型換了 harness，表現會差很多。InsForge 做的，是把 harness 延伸進後端。
如果要從三篇裡帶走幾件事，我會留下這些：
- 先決定操作者是誰，再設計其他一切。 操作者從人換成 agent，狀態、錯誤、文件、權限的設計都要跟著改，這些改動不是加一層 MCP 就能完成的。
- 給 agent 的價值在一致性，不在介面。 介面誰都做得出來；能讓 agent 在所有服務上用同一種方式讀狀態、理解錯誤、守同一條邊界的那一層，才是別人抄不走的部分。
- 模型進步會放大缺 context 的代價，不會消除它。 把 context 和護欄放在平台這一側，系統的下限就不會跟著模型漂移。
- 能被 agent 回報修正的系統，才跟得上 agent 的速度。 錯誤提示和文件都來自 agent 卡住的地方，讓 agent 自己回報，系統就有一條持續變好的回流。
- 當使用者不是人，身分、成本和復原機制都要重新想過。 這是給 agent 的基礎設施下一步最值得投入的方向，也是最難被取代的地方。
這個系列用「操作者換成 agent」這個鏡頭看了 InsForge。下一個系列會用同一個鏡頭看 Supabase，一個從「給人用的後端」出發、再往 agent 靠攏的平台。兩者走到同一個問題面前的路徑不同，最後再把兩邊放在一起，統整成一篇 Agent Infra 的設計地圖。