研究項目

OpenPort Protocol (OPP)

一套面向可靠 AI 工具接入的開放協定：支援感知授權的發現機制、草稿優先寫入，以及能夠經受真實工作流程考驗的穩定回應。

An abstract AI systems image with layered luminous structures and flowing digital particles.

一套將 AI 意圖轉化為可問責行動的協定。

當 AI 系統從對話走入工作流程，它就不再只是「模型」。它會開始讀取資料、提出變更建議，並觸發實際操作，而這一切往往發生在不確定、上下文不完整、且人類輸入並不整潔的條件下。真正脆弱的環節並不在工具清單，而在「意圖如何變成結果」的那個瞬間。

OpenPort Protocol（OPP）正是為了把這一瞬間顯式化。它為工具發現與工具呼叫定義了一個小而穩定的介面面，並將治理保持在服務端：權限、邊界、可審查寫入，以及執行階段能安全恢復的可預測失敗模式。

我們將 OPP 設計為與模型和執行環境無關的協定，因此不同生態都可以透過可選綁定來接入，而不必把治理執行邏輯分散到每一個客戶端中。

查看 GitHub 在 arXiv 閱讀在 SSRN 閱讀（即將上線）

SSRN 條目仍在審核中。連結可用後，我們會第一時間補上。

核心概覽

OpenPort 刻意保持精簡。協定介面本身不是目的，它真正的價值在於：讓不同執行環境能夠在同一環境中以安全、一致的方式運作。

是閘道，不是外掛

工具存取統一透過服務端閘道進行中介，因此無論另一側接的是哪種模型、智能體框架或 SDK，邊界與策略都能被一致執行。

貼近真實權限的發現機制

manifest 反映的是某個憑證在當前時刻「實際可以做什麼」的授權視圖。如果某項能力不被允許，它就不應作為可選項出現。

寫入預設可審查

大多數操作都先以草稿形式開始。執行必須是顯式的，並可設定時間窗口；對於高影響工具，還會附帶額外保護措施。

可預測的失敗語義

穩定的回應封裝與可由機器處理的 agent.* 原因碼，使重試、退避與升級處理具備確定性，尤其是在「安全的答案就是拒絕」時。

架構

OPP 將兩個關注點分離開來：領域邏輯（你的產品要做什麼）與治理語義（工具存取如何被控制、審查並具備可運維性）。適配器保持私有，閘道保持一致。

智能體執行環境 / 模型

來自任意模型或智能體框架的結構化工具呼叫。

↓Agent API 呼叫（`agent/v1`）

信任邊界

服務端強制執行

OpenPort 閘道

認證、邊界控制、寫入控制、速率限制與穩定回應。

↓適配器呼叫

私有適配器

面向領域的讀寫能力，以及與內部系統之間的轉換。

↓領域操作

應用資料與動作

你的系統保持私有。OpenPort 統一的是介面，而不是你的資料 schema。

管理控制平面

簽發或撤銷金鑰、審查草稿、設定執行時間窗口。

為什麼需要這條邊界

智能體執行環境本質上具有機率性。OpenPort 透過把治理決策留在服務端來控制風險半徑，從而讓策略、審查與事故回應都能被一致執行。

協定介面（核心）

核心設定模式被刻意設計得盡量精簡。讀取能力可以按領域擴充，但寫入行為會統一收斂到一小組具備治理意識的端點上。

Agent API（`agent/v1`）

GET  /api/agent/v1/manifest
GET  /api/agent/v1/ledgers
GET  /api/agent/v1/transactions
POST /api/agent/v1/preflight
POST /api/agent/v1/actions
GET  /api/agent/v1/drafts/{id}

統一穩定的回應封裝

// success
{ "ok": true, "code": "...", "data": { ... } }

// error
{ "ok": false, "code": "agent.*", "message": "...", "details": { ... } }

這個結構本身就是契約：客戶端始終能夠穩定解析回應，而原因碼則可用於驅動安全的恢復策略。

運作方式

OPP 圍繞一個簡單原則設計：讓安全的行為成為最容易採用的行為。讀取路徑保持直接，寫入路徑則被組織為「意圖 → 審查 → 結果」。

讀取

先取得 manifest，了解當前憑證下有哪些工具可用，以及各自的 schema 與約束：GET /manifest。
呼叫 manifest 允許的某個領域讀取端點（或讀取工具）。
解析穩定回應封裝，並顯式處理拒絕結果，而不是依賴猜測。

GET /api/agent/v1/manifest
→ 工具 + schema + 治理中繼資料

寫入

（可選）先執行 preflight，計算影響摘要，並透過雜湊將意圖綁定起來。
提交 action 請求。服務端預設回傳 draft，只有在策略明確允許時才會直接執行。
由操作人員在管理控制平面中批准或拒絕草稿。
進入執行階段後，OpenPort 會強制執行保護措施（例如冪等性與 preflight 綁定），並記錄執行結果。

{
  "action": "transaction.hard_delete",
  "payload": { "...": "..." },
  "execute": true,
  "forceDraft": false,
  "requestId": "req_...",
  "idempotencyKey": "idem_...",
  "preflightId": "pfl_...",
  "preflightHash": "sha256(...)",
  "stateWitnessHash": "sha256(...optional...)",
  "justification": "operator intent for high-risk execution"
}

草稿生命週期

草稿機制把「意圖」與「結果」分離開來。如此一來，在重試、提示含糊或審批延遲的情況下，寫入路徑仍能保持安全，而不需要每個客戶端都重新發明同樣的保護機制。

draft

等待操作人員決策。尚未產生任何副作用。

→reject

canceled

由操作人員拒絕。終態。

confirmed

已批准執行（或在策略允許下可自動執行）。

→執行失敗

failed

已嘗試執行但失敗。終態。

一個雖小卻重要的細節

`draft.status` 表示治理狀態，並不能替代執行記錄。若執行成功，OpenPort 會將執行結果與對應草稿一併記錄，以確保可追溯性。

綁定與設定模式

OpenPort 對核心語義保持克制，對接入方式保持靈活。綁定層允許各類生態把自身的工具格式映射到 OPP 上，同時不把治理執行責任轉移到客戶端。

工具生態 / 執行環境

MCP 客戶端、Web 綁定、自訂 SDK 與智能體框架。

↓綁定層（可選）

OpenPort Protocol（核心）

工具發現、穩定封裝、草稿優先寫入，以及可預測的控制語義。

↓服務端強制執行

OpenPort 部署

閘道 + 管理平面 + 適配器，並與您的系統完成整合。

核心設定模式

最小端點集合 + 穩定回應封裝 + 草稿優先寫入。設計目標是與領域無關，並盡可能易於接入。

State Witness（可選）

這是面向延遲審批的更強設定模式：它會在執行時重新驗證前置條件；一旦底層狀態發生漂移，就會以失敗關閉的方式中止執行。

我們如何驗證

協定只有在不發生語義漂移時才真正有價值。OpenPort 將規範與可執行工件配套交付，包括黑盒一致性設定、負路徑回歸測試，以及確保版本行為穩定的發佈門禁。

建置 + 單元測試

→

黑盒一致性驗證

→

模糊 / 濫用回歸

→

安全與邊界掃描

→

發佈打標

參與交流

OpenPort 是開源的，目標是被多種執行環境與多類應用實作。如果你也在探索工具接入、審批機制或安全自動化，我們很樂意交流彼此的思路與實踐。

相關連結