关键词：ACC Binding、OpenAPI 与 MCP、gRPC Agent 治理、Agent 协议分层、能力声明
假设一家企业已经有三种系统：
商城后台：通过 OpenAPI 描述 HTTP 接口
内部微服务：通过 protobuf 定义 gRPC 方法
Agent 工具网关：通过 MCP 暴露工具
它们最终都可能触发相同的业务动作：
创建退款申请
如果这项动作允许 Agent 使用，治理层仍然需要知道：
- 是否显式开放给 Agent；
- 用什么稳定 scope 引用；
- 后果风险是什么；
- 是否要求可信行动主体；
- 什么条件下产生审批意图；
- 是否含敏感数据；
- 是否只读、幂等，以及建议的执行边界。
这些问题不会因为调用通过 HTTP、gRPC 还是 MCP 而消失。
但它们也不能被简单地复制成三套彼此独立的字段体系。否则同一项业务能力会随着传输方式变化而获得不同治理含义：
OpenAPI 中 high 表示高风险
MCP 中 high 表示需要审批
gRPC 中 high 又表示高优先级
这样的“支持多个协议”只会制造新的碎片化。
更可靠的设计必须把两件事分开：
Core 定义可移植的治理语义，Binding 定义这些语义怎样进入某一种协议或接口描述。
OpenAPI 是 ACC v1 的首个标准 Binding，但 ACC Core 的身份不等于 x-agent-capability，更不等于 HTTP。
1. Core 和 Binding 回答的是两组不同问题
ACC Core 回答：
一项 Agent-facing 业务能力需要声明哪些稳定治理事实？
Binding 回答：
在某一种载体里，这份声明放在哪里、怎样提取、怎样和原生 Schema 对齐？
可以把分工概括为：
| 层次 | 核心问题 |
|---|---|
| ACC Core | 字段是什么意思，默认值、失败语义和兼容规则是什么 |
| Binding | 声明放在哪里，如何映射参数、类型、描述和原生元数据 |
| Runtime | 如何消费已验证能力、暴露工具并执行确定性治理 |
| Business System | 当前主体能否对当前对象产生真实业务后果 |
这四层经常在同一条链路中协作，但任何一层都不能因为“实现方便”而吞掉其他层的责任。
2. x-agent-capability 是 OpenAPI 承载方式，不是 ACC Core 本身
在 OpenAPI 中，ACC v1 使用 operation 级扩展：
paths:
/refunds:
post:
operationId: createRefundRequest
x-agent-capability:
version: 1
enabled: true
scope: refund.request.create
risk:
level: high
这里有两个不同对象：
OpenAPI operation
-> 描述路径、方法、参数、请求体和响应
x-agent-capability
-> 承载 ACC Core 声明对象
x-agent-capability 只是 OpenAPI Binding 选择的放置位置。
如果未来存在经过规范化和验证的 gRPC Binding，它不可能继续使用 OpenAPI extension field；如果存在 MCP Binding，它也必须遵守 MCP 自己的对象结构和扩展规则。
但不论载体怎样变化：
risk:
level: high
都不能在新 Binding 中被重新解释为“无条件审批”或“禁止调用”。
Core 的意义就在于：
同一个字段跨 Binding 保持同一含义，不被承载协议重新发明。
3. 为什么不能把所有内容都放进 Core
既然 Core 要跨协议稳定，是否应该把路径、方法、参数和响应也全部纳入？
不应该。
这些内容已经由 Binding 原生机制表达：
| 信息 | OpenAPI | gRPC / protobuf | MCP |
|---|---|---|---|
| 操作标识 | path、method、operationId | service、method | tool name |
| 输入结构 | parameters、requestBody、JSON Schema | request message | input schema |
| 输出结构 | responses、JSON Schema | response message | tool result |
| 描述与示例 | summary、description、examples | comments、annotations | description 等原生机制 |
如果 ACC 再定义一套：
parameters:
responses:
transport:
method:
它会立即产生两个事实来源：
OpenAPI 说 amount 是 number
ACC 又说 amount 是 string
运行时只能猜哪一个正确。
因此，Core 只保留具有可移植治理意义的字段：
version
enabled
scope
risk
subject
approval
audit
execution
guidance
Binding 继续复用自己的原生 Schema。
这不是 ACC 功能不够，而是避免重复协议事实的设计纪律。
4. 一个合格 Binding 必须定义什么
“把 ACC 字段塞进另一个协议”还不足以构成 Binding。
一个可互操作 Binding 至少需要回答六组问题。
4.1 声明放在哪里
OpenAPI Binding 已明确要求：
放在 operation object
不放在 document root、path item、schema、parameter 或 response
未来的 Binding 也必须选择一个稳定、无歧义的承载对象。
如果同一份声明可以同时出现在服务、方法和参数上，却没有明确优先级，不同解析器就会产生不同结果。
4.2 operation 的稳定引用是什么
运行时、审计系统和兼容性报告必须能够指出：
这份 ACC 声明绑定的是哪一项原生操作？
OpenAPI 可以使用绑定限定的 path、method 或 operation reference。
其他协议需要定义自己的限定方式，而不能假设一个裸 scope 就能替代原生 operation 身份。
scope 是治理标识，Binding operation reference 是载体中的具体操作引用，两者用途不同。
4.3 原生输入怎样映射到 JSON 值模型
ACC 条件审批使用严格 JSON 类型：
object
array
string
finite number
boolean
null
OpenAPI 的 JSON Schema 与这个模型较接近。
但 protobuf 可能包含：
int64；- bytes；
- enum；
- oneof；
- map；
- field presence；
- well-known timestamp；
- 默认值与未出现字段的差异。
Binding 必须说明这些原生值如何映射。
如果无法无损表达，就必须拒绝或跳过受影响声明并给出诊断，不能静默转换。
例如：
原生 int64 超过 JavaScript 安全整数
-> 不能悄悄转成不精确 number
-> 否则 amount > 100000 的审批判断可能改变
4.4 approval.when.param 怎样解析
下面的条件：
approval:
when:
- param: amount
op: ">"
value: 1000
只有在 amount 能确定解析到原生输入字段时才有意义。
Binding 必须定义：
- 路径从哪个输入根开始；
- 嵌套对象如何寻址；
- 多个参数位置怎样合并；
- 引用如何解析；
- 数组和可选字段怎样处理；
- 同名字段冲突时如何失败。
两个兼容同一 Binding 的实现，必须把同一路径解析到同一输入。
否则，同一份审批声明会在不同运行时触发不同结果。
4.5 原生元数据与 ACC 怎样确定优先级
承载协议可能已经具有相关信号：
- OpenAPI
deprecated； - HTTP GET；
- MCP 只读或破坏性提示；
- protobuf 自定义 options；
- 原生 description 和 examples。
Binding 必须说明：
- 哪些原生信号可以映射；
- 哪些只是参考；
- 显式 ACC 字段与原生信号谁优先；
- 冲突时怎样诊断；
- 缺失时怎样保守回退。
它不能看到一个相似字段名就自行赋予 ACC 语义。
4.6 失败时怎样保持保守
Binding 解析失败不能生成一个治理更弱的工具。
例如：
x-agent-capability 解析失败
-> 跳过该 operation 并给出诊断
不能变成：
x-agent-capability 解析失败
-> 当作普通工具继续暴露
后者会让“治理声明写错”自动退化成“没有治理”，这正是最危险的失败方式。
5. Validated Capability Artifact 为什么重要
Core 与 Binding 分开后，运行时不一定要亲自解析每一种协议。
Binding Parser 可以向运行时提供一个经过验证的能力产物，概念上包含：
ACC declaration
binding-qualified operation reference
bound input schema
binding name and supported version
diagnostics
它可以表现为：
- 内存对象；
- 编译后的工具定义；
- 生成代码；
- 网关路由；
- 缓存记录；
- 其他等价结构。
ACC 不强制规定一个新的线格式。
这个抽象带来两个价值。
价值一：运行时不必耦合所有协议解析器
OpenAPI Parser
gRPC Parser
MCP Adapter
-> 统一产出经过验证的 capability artifact
-> Runtime 消费稳定 Core 语义
运行时可以专注于暴露、主体、审批、审计和执行，不必把每种协议的全部解析逻辑塞进核心。
价值二：Binding 可以独立测试
一个解析器是否正确，不必等到真实退款执行后才知道。
它可以用 conformance vectors 验证：
- placement 是否正确；
- malformed declaration 是否被拒绝；
- 参数路径是否确定解析；
- 类型是否严格；
- unsupported version 是否诊断；
- schema 不足时是否保守跳过。
这让“支持某个 Binding”从营销措辞变成可以核验的兼容性声明。
6. 为什么 MCP 不能自动等于 ACC Binding
MCP 解决工具、资源和提示的连接与调用生态。
ACC 解决 Agent-facing 业务 operation 的可移植治理声明。
两者可以组合：
ACC 标注的业务 operation
-> 被网关编译成 MCP tool
-> MCP 客户端发现并调用
-> 运行时继续执行 ACC 治理
但“通过 MCP 调用”本身不能证明：
- Core 字段被完整保留；
- 风险默认值一致；
approval.when参数路径一致；- subject trust 边界一致；
- 未知字段和失败行为保守；
- 原生 annotations 与 ACC 的优先级明确。
所以一个 MCP adapter 可以是有价值的实现，却不能仅凭字段复制就宣称形成了标准 ACC Binding。
正式 Binding 还需要：
- 公开的映射规范；
- 失败语义；
- 类型映射；
- 机器可读测试向量；
- 独立实现证据；
- 明确的兼容性声明语言。
7. 为什么 gRPC 也不能只加几个 protobuf option
protobuf 的 option 扩展机制确实适合承载元数据。
一种实验性设计可能看起来像：
rpc CreateRefund(CreateRefundRequest) returns (RefundRequest) {
option (...) = {
enabled: true
scope: "refund.request.create"
};
}
但这只是开始。
一个真正的 gRPC Binding 还必须回答：
- option 挂在 service 还是 method；
- proto2、proto3 和 editions 如何处理 presence；
- enum、oneof、map、bytes 和 int64 如何映射；
- well-known types 如何进入 JSON 值模型；
- request field path 如何解析；
- streaming RPC 是否适合作为一项 ACC operation；
- client streaming、server streaming 和 bidi streaming 的结果语义是什么；
- reflection 不可用时怎样获得 Schema；
- code generation 与运行时 reflection 的兼容证据是什么。
所以“protobuf 天然支持扩展”不等于 Binding 已经完成。
它说明方向可能可行，不说明跨实现语义已经稳定。
8. 同一项能力跨协议时，什么必须保持不变
假设同一项退款能力分别通过 HTTP、gRPC 和 MCP 暴露。
Core 层至少应保持：
version: 1
enabled: true
scope: refund.request.create
risk:
level: high
subject:
required: true
approval:
when:
- param: amount
op: ">"
value: 1000
audit:
sensitive: true
execution:
readonly: false
idempotent: true
Binding 层可以不同：
| Binding | operation 载体 | 输入 Schema |
|---|---|---|
| OpenAPI | HTTP operation object | parameters + requestBody |
| gRPC（未来候选） | protobuf RPC method | request message |
| MCP（未来候选） | tool 或明确映射对象 | tool input schema |
但下面这些结果不能因 Binding 改变：
enabled: false不得暴露；- scope 缺失不得作为有效能力暴露；
- high 不能被重新解释；
- subject requirement 不能被原生 description 抵消；
- amount 条件必须使用相同类型和值语义；
- Schema 不足时不能降级成无治理工具；
- 最终业务授权仍由业务系统持有。
传输可以变化，治理语义不能漂移。
9. Binding 不能替代运行时
解析出声明不等于治理已经执行。
Binding Parser 可以证明：
这项 operation 带有合法 ACC 声明
amount 条件能解析到 number 输入
当前声明版本受支持
它不能自动证明：
路由 allowlist 已经配置
可信主体已经解析
审批系统已经收到并绑定精确参数
审计记录已经持久化
幂等由业务系统兑现
最终权限已经校验
因此完整链路仍然是：
Binding
-> 提取并验证声明与原生 Schema
Runtime
-> 暴露能力并执行确定性治理
Business System
-> 校验实时权限和业务状态，产生最终结果
把 Parser 宣称成控制面，和把 API 文档宣称成授权系统一样不准确。
10. Binding 也不能替代业务系统
即使所有协议都完美保留 ACC 语义，运行时仍然不知道：
- 当前订单属于哪个租户；
- 可退余额是否变化；
- 员工是否已经离职；
- 合同是否进入锁定状态；
- 当前主体是否仍有资源级权限；
- 业务对象是否刚被另一事务更新。
这些事实只能由持有新鲜业务状态的一侧判断。
Core 与 Binding 分层并没有改变 Reach 与 Authority：
Core + Binding + Runtime
-> 控制 Agent 最多能触达和怎样尝试调用
Business System
-> 决定当前主体此刻是否真的可以做
跨协议一致不等于跨过最终授权。
11. 为什么“先支持一个 Binding”比同时支持所有协议更专业
标准早期很容易追求一张漂亮的兼容矩阵：
OpenAPI ✓
MCP ✓
gRPC ✓
A2A ✓
但每个勾如果没有类型映射、失败行为和测试证据，就只是“我们可以读取几个字段”。
先把一个 Binding 做完整，至少可以验证：
- Core 是否真的独立；
- 参数路径是否可复现；
- 默认值和优先级是否明确；
- Parser 与 Runtime 的责任是否能分开；
- conformance 是否可以被第三方实现；
- 错误声明是否保守失败。
这比同时发布多个无法互操作的草案更有价值。
OpenAPI 作为 ACC v1 首个标准 Binding，代表的是当前可验证范围，不是对其他协议的否定。
未来 Binding 应当通过新的证据扩展生态，而不是用文档里的一个“支持”标签提前制造兼容性承诺。
12. 十二个常见误区
误区一：ACC 就是 OpenAPI 扩展字段
OpenAPI extension 是首个 Binding 的承载方式，Core 是其中的声明语义。
误区二：只要字段名相同，两个 Binding 就兼容
类型映射、参数路径、优先级和失败行为也必须一致。
误区三：MCP 已经能传工具，所以不需要治理声明
传输和工具发现不自动回答风险、主体、审批和业务责任边界。
误区四：有 ACC 就不需要 MCP
ACC 不替代连接、会话、调用和工具传输协议。
误区五：protobuf 有 options，gRPC Binding 就很简单
承载字段容易，稳定定义输入映射和流式语义更难。
误区六：Binding 可以重新定义 Core 字段
Binding 只能映射和补充协议特定规则，不能改变 Core 含义。
误区七：原生 metadata 可以静默升级风险
任何映射都需要明确的信任、优先级、默认值和保守失败语义。
误区八：解析失败时继续暴露普通工具更友好
这会让治理错误变成安全降级，应当跳过或拒绝并给出诊断。
误区九：Validated artifact 必须成为新网络协议
它是概念接口，可以是内存模型、生成代码或网关路由。
误区十：支持 Parser 就等于支持完整 Runtime
解析兼容和执行治理是不同 conformance profile。
误区十一：跨 Binding 一致就等于拥有最终权限
最终授权仍由掌握实时业务状态的系统决定。
误区十二：未来可能适用，就可以现在宣称兼容
研究方向必须与当前规范范围分开；正式兼容需要 Binding、测试和独立实现证据。
13. 一份 Binding 设计检查表
为新的载体设计 ACC Binding 前，可以逐项检查：
- [ ] 是否明确声明了 Binding 名称、版本和规范状态？
- [ ] 是否定义了声明的唯一合法放置位置？
- [ ] 是否给出 binding-qualified operation reference？
- [ ] 是否完整定义原生输入到 JSON 值模型的映射？
- [ ] 是否处理了大整数、bytes、enum、presence、union 和引用？
- [ ]
approval.when.param是否能确定性解析？ - [ ] 同名或歧义输入是否保守拒绝，而不是静默选择？
- [ ] 原生 description、examples、deprecated 和行为 annotations 的优先级是否明确？
- [ ] 原生限制是否永远不会被 ACC 元数据削弱？
- [ ] 解析失败是否跳过或拒绝能力，而不是降级为普通工具？
- [ ] 是否提供最小有效示例和异常示例？
- [ ] 是否提供机器可读 Parser vectors？
- [ ] 是否区分 Parser、Generator、Runtime 和 Policy Component 声明？
- [ ] 是否有至少一个可复现实现，最好还有独立实现证据？
- [ ] 是否明确最终业务授权仍不属于 Binding？
14. 结语：开放不是支持所有协议，而是允许语义脱离协议继续成立
一个真正开放的能力契约，不是把同一份 YAML 粘贴到尽可能多的平台。
它需要做到：
协议可以更换
传输可以更换
解析器可以更换
运行时可以更换
但同一治理字段的含义不能更换
这正是 Core 与 Binding 分层的价值。
Core 保留不同实现必须共享的最小语义。
Binding 尊重每种协议自己的操作模型、Schema 和元数据，并承担确定映射和保守失败。
Runtime 将经过验证的能力变成可以执行的治理链路。
Business System 继续持有最终 Authority。
OpenAPI 是 ACC v1 的首个标准 Binding，因为它为现有业务 API 提供了一个可落地、可测试的起点。
MCP、gRPC 或其他载体未来是否形成正式 Binding，应当由公开规范、失败语义、测试向量和独立实现证据决定，而不是由字段看起来能否塞进去决定。
标准的扩展能力，不在于它承诺覆盖一切。
而在于它能够在扩展时，仍然守住同一份语义和责任边界。
