核心概念
A2B：Agent-to-Business
A2B（Agent-to-Business） 是指 Agent 安全、可治理地接入现有业务系统，代表真实业务主体查询数据、创建请求、修改状态或启动业务流程的场景。
A2B 不只是工具调用，还包括：
- 业务侧身份和最终授权；
- 路由与场景边界；
- 能力声明；
- 风险与审批意图；
- 审计和追踪；
- 签名与调用问责；
- 业务系统继续保留最终裁决权。
简短表达：
A2B = Agent 通过现有业务系统安全地完成真实业务工作。
ACC：Agent Capability Contract
ACC（Agent Capability Contract） 是 A2B 场景下的能力声明契约。
ACC 回答：
- 哪项业务能力可以暴露给 Agent？
- 能力属于哪个作用域？
- 操作具有怎样的风险等级？
- 是否必须绑定真实业务主体？
- 是否需要表达人工审批意图？
- 哪些信息需要脱敏或审计？
- 运行时应保留哪些执行语义？
ACC 不执行能力，只声明能力边界。
简短表达：
ACC 是 A2B 场景下的能力声明契约。
三者关系
A2B 是问题场景。
ACC 是开放契约。
不同实现把 ACC 声明转换为运行时行为。
为什么这些问题会反复出现
Agent 可以只做内部推理、生成尚未生效的草稿或进行模拟。当 Agent 的行动跨越以下任一边界时，治理问题开始具有结构性：
- 后果边界：行动会读取受控数据、修改状态、发送消息、移动资金或产生其他现实后果；
- 授权边界：行动会使用用户、组织、应用或外部系统授予的权限；
- 信任边界：声明方、决策方、执行方和最终授权方并不处在同一信任域。
跨越这些边界的系统会反复遇到能力触达、行动主体、后果等级、人工介入、责任追溯和执行语义问题。某项低后果操作可以不要求主体或审批，但“无需主体、无需审批”本身也应是一个明确的治理结论。
这组问题比任何单一传输协议或 Binding 更广泛，但这并不表示 ACC v1 已经治理所有 Agent 行动，也不表示当前字段可以原样复制到 MCP、A2A、App Intent、操作系统权限或跨组织委托中。ACC v1 继续是 A2B 业务操作的具体契约，首个 Binding 继续是 OpenAPI。更广泛的适用性需要独立 Binding、失败语义、实现证据和公开 Proposal 审查。
相邻术语
| 术语 | 含义 | 与 ACC 的关系 |
|---|---|---|
| A2A | Agent-to-Agent 协作 | 相邻问题，不属于同一协议层 |
| MCP | 暴露和调用工具、资源与提示的协议生态 | 可以与 A2B 组合，但自身不等于业务操作治理契约 |
| ACC | A2B 能力声明契约 | 定义可移植的业务能力治理元数据 |
| ACC Runtime | 解析、校验或执行 ACC 声明的实现 | 属于运行时实现，不是契约本身 |
范围说明
ACC v1 是 A2B 系统中一份具体、机器可读的能力声明契约。它独立于任何产品实现进行维护，任何实现都不会因为支持 ACC 而成为标准本身。
前面这些治理问题可能在其他 Agent 行动环境中反复出现，这为后续研究和独立 Binding 提供了方向，但不会把 ACC v1 当前的兼容性声明扩大到已公布的 A2B 范围之外。