研究项目

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 是开源的，目标是被多种运行时与多类应用实现。如果你也在探索工具接入、审批机制或安全自动化，我们很愿意交流彼此的思路与实践。