什麼是代理原生基礎設施？AI 開發者指南

代理原生基礎設施讓 AI 代理能透過結構化介面，自行探索、佈建、檢查及操作後端資源。代理可以在明確限制內完成設定，但政策、帳務及影響重大的核准仍由人負責。

光有 API，並不代表基礎設施就是代理原生。介面還需要提供機器可讀的能力說明、範圍受限的身分、可預期的錯誤、安全的重試機制，以及讓人認領或核准工作的流程。

代理原生基礎設施有哪些特性？

代理能找到可用的操作

介面會告訴呼叫端有哪些操作、每個參數代表什麼，以及結果會包含哪些內容。這些說明可以放在 OpenAPI 文件、MCP 伺服器、CLI 說明介面或其他結構化合約中。格式本身不是重點；重點是代理不必把整個文件網站載入上下文，就能選對操作。

身分與權限屬於呼叫端

每個代理或代理工作階段都應取得範圍受限的身分。後端再根據該身分判斷呼叫端能否讀取或建立資源、花費款項或刪除資料。共用管理員金鑰會抹去這條界線，也讓責任歸屬變得模糊。OWASP 的 Excessive Agency 指南建議將擴充功能、權限和自主程度限制在完成工作所需的最低範圍。AI 代理安全設計也面對相同問題：身分、權限和稽核紀錄必須一致指出操作是由誰執行。

寫入操作可以安全重試

代理會在逾時、執行中斷或工具結果不完整時重試。因此，寫入操作需要等冪金鑰，或其他伺服器端去重機制。Stripe 的等冪合約就是具體例子：伺服器會保存某個金鑰第一次執行的結果，遇到相同重試時再次回傳。代理原生後端也需要這項特性，才不會建立第二個資料庫、重複扣款或多寄一封訊息。

高影響操作始終受到限制

佈建可丟棄的開發資料庫，和刪除正式環境磁碟區，不該套用同一套核准規則。代理原生系統會直接開放低風險流程，遇到破壞性、財務相關或範圍異常廣泛的操作時，則依政策暫停或要求人工核准。正式環境代理檢查清單把這項區別轉成具體控制措施。

代理原生與可透過 API 存取的基礎設施

這不是名稱上的差異，而是實際操作方式的差異。傳統 API 即使包裝成 MCP 伺服器，只要仍暴露權限過廣的憑證、含糊的工具說明或無法等冪重試的寫入操作，代理依然很難可靠使用。

為什麼這種介面現在很重要

Vercel 在 2026 年 4 月表示，由程式開發代理發起的部署在六個月內增加了 1,000%，並占該平台每週部署量的 30% 以上。其中 75% 來自 Claude Code，6% 來自 Lovable 和 v0，1.5% 來自 Cursor。Vercel 也發現，由代理部署的專案使用 AI 推論供應商的機率高出 20 倍。這些是 Vercel 平台的量測結果，不是整體市場估計，但足以顯示大型部署平台的介面正在改變。

控制台預設人能理解模糊的失敗訊息、開啟另一個分頁、複製密鑰後再試一次。代理需要的是資料化的狀態：缺少哪項權限、能否安全重試、哪些內容已變更，以及哪個操作需要核准。

具體的佈建流程

Cohesivity 的設定流程示範了這種模式。npx @cohesivity/init 會建立專案上下文並寫入 .cohesivity 檔案。接著，代理能透過同一個專案請求資源，不必為每個供應商分別走一次註冊流程。專案在 72 小時內可供認領，讓代理有時間完成建置，同時把擁有權保留給人。

佈建資料庫、身分驗證、儲存和託管指南會展示相關請求與產生的專案結構。這只是代理原生基礎設施的一種實作方式，不代表每個平台都必須綑綁同一組服務。

如何評估代理原生平台

用一項真實工作檢查完整流程：

1. 代理能否在沒有純文字設定說明的情況下找到操作？
2. 操作是否明確宣告輸入、輸出、限制及穩定的失敗原因？
3. 憑證是否只允許代理存取所需的專案和操作？
4. 代理能否重試寫入，而不會重複產生效果？
5. 破壞性或財務相關操作是否會在執行前停止？
6. 人能否辨識、認領、撤銷及稽核代理建立的內容？

無法通過前兩項的平台，代理很難使用；無法通過其餘檢查的平台，也許容易呼叫，卻不適合在無人監督下操作。

測試一條佈建路徑

在可丟棄的專案中執行設定，建立第一個資源後中斷，再執行一次相同請求。檢查第二次執行是否能順利接續、兩次嘗試是否共用同一筆操作紀錄，以及產生的資源能否歸因到發起操作的代理。

如果重試建立了第二個資源，很好，你在正式環境凌晨 2:47 出事前就找到了錯誤。從這個指令開始測試：

npx @cohesivity/init