甚麼是代理原生基礎設施？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