ACC 设计依据与边界
状态：非规范性设计依据
适用于：ACC v1
ACC 有意保持一份小而明确的契约。小不等于残缺，而是规范核心只包含独立运行时能够一致理解、又不依赖某个产品数据库、UI、身份模型、审批系统或部署拓扑的语义。
规范性行为以 SPEC.md、版本化 Schema 和 Binding 文档为准。本文解释一些有价值的平台与业务能力为什么没有成为 ACC 核心字段。
1. 一句话边界
ACC 声明面向 Agent 的能力边界。
运行时治理能力暴露与调用过程。
业务系统保留最终裁决权。
ACC 回答 Agent 运行时理解业务能力时必须知道的内容：是否暴露、策略 scope、后果风险、主体要求、审批意图、审计敏感性、执行提示和模型可读指引。
ACC 不试图描述整个 A2B 控制面。
2. 核心字段准入测试
一个字段只有同时满足以下条件，才适合进入 ACC 核心：
- 它会改变可移植的 Agent 治理语义。
- 相互独立的 Parser 或 Runtime 能实现相同含义。
- 不依赖某个产品的私有数据库、UI、身份目录或工作流，就能测试其行为。
- 标准 OpenAPI 与 JSON Schema 不能已经清晰表达它。
- 它不要求运行时成为最终业务授权方。
- 旧运行时忽略它时不会静默降低安全性，否则必须进入新的 major 兼容家族。
这六项是必要条件，不是充分条件。全部满足只代表提案具备进入治理评审的资格，并不意味着该字段必然进入 ACC 核心。
治理评审还会判断：
- 是否在多个独立实现环境中出现了可验证的共同需求；
- 是否已经收敛为最小、稳定的语义增量；
- 是否更适合放在 Binding、实现扩展或相邻规范；
- 默认值、优先级、失败和安全语义是否完整；
- 向后兼容与生态实现成本是否可接受；
- 是否具备实现证据和机器可读 Conformance 测试向量。
字段更多不代表规范更好。无法通过这组测试的字段，只会让声明看似可移植，却把隐藏假设强加给每个实现。
3. 已知但有意不进入 ACC 核心的问题
| 问题 | 为什么不是 ACC v1 核心字段 | 正确责任层 |
|---|---|---|
| 最终用户权限 | 角色、ABAC、归属权、数据权限和账号状态都具有业务特性并随时间变化。 | 业务授权层 |
| 租户或商户隔离 | 绕过 Agent 运行时直接调用 API 时，隔离仍必须成立；网关注入参数不是安全边界。 | 业务数据层与授权层 |
| 身份表达 | Session、JWT Claim、服务主体、证书、目录组和签名票据不能互相等同。 | 运行时身份桥与业务系统 |
| 审批人和审批流程 | 审批人、会签、委托、过期、UI 和升级路径取决于组织流程。 | 外部审批所有者 |
| 业务拒绝规则 | 黑名单、订单状态、库存、退款额度和合同限制需要权威业务数据。 | 业务策略与授权层 |
| 跨字段与上下文不变量 | “退款额不超过当前可退余额”等规则需要新鲜且经过授权的业务状态。 | 业务操作或预检 API |
| 上下文取值 | 数据来源、读取授权、时效、失败和缓存需要单独的数据访问契约。 | 运行时集成或业务 API |
| 审计保留与 legal hold | 保留时长、归档、删除与法律保全是组织级合规策略。 | 部署与合规策略 |
| 字段级审计脱敏 | ACC v1 只声明整体敏感性；请求/响应路径、数组、引用和保守回退仍需形成可移植设计证据。 | OpenAPI Schema 标注、运行时策略或未来 ACC Proposal |
| 通用布尔条件组 | ACC v1 有意使用有限的 ANY 条件；嵌套布尔策略仍需定义优先级、兼容和 fail-safe 语义。 | 运行时策略引擎或未来 ACC Proposal |
| 审批 UI 或二次确认 | 部分运行时是无 UI 的网关、队列或确定性工作流。 | 运行时或审批产品 |
| 回滚与补偿 | 补偿不一定是一次反向调用，还涉及授权、状态、幂等和工作流语义。 | 事务、Saga 或工作流层 |
| 工具组合与顺序 | 前置条件、编排与多步骤事务构成另一类工作流或规划契约。 | 工作流或编排层 |
| 存储、队列、签名、指标与成本 | 它们是重要控制面能力，但不改变可移植的声明含义。 | 运行时实现 |
| HTTP、RPC、消息队列或 MCP 传输 | 同一 ACC 声明可以在多种调用传输之前被消费。 | Binding、适配器或传输规范 |
这些问题不进入 ACC，并不代表它们不重要。这样划分是为了避免 ACC 对只有业务系统或部署方才能兑现的责任作出虚假保证。
4. 小不等于含糊
一份小契约仍然必须具备精确语义。因此 ACC 明确定义：
- 必填字段与 JSON 类型；
enabled、scope和可信主体可用性对应的暴露要求；- 严格、类型敏感的审批条件比较；
- 不支持版本与未知字段的安全处理；
- 模型可控输入与可信治理元数据之间的边界；
- Conformance Profile 与可观察结果。
如果同一份声明能被两个合规实现解释成相反含义，那是规范缺陷，应该修正。如果两个组织有意把相同风险分类映射成不同本地审批流程，那是部署策略差异，不是可移植性缺陷。
5. 边界示例
可移植声明
approval:
when:
- param: amount
op: ">"
value: 10000
调用参数和字面量阈值都在 operation 契约中，运行时不需要私有业务数据就能评估。
业务不变量
退款金额 <= 当前订单可退余额
当前可退余额属于权威业务状态。即使 API 没有经过 Agent 运行时，业务操作也必须验证它。
可信主体要求
subject:
required: true
ACC 声明匿名或不可信调用不能接受，但不强制主体必须通过 JWT、签名票据、服务账号或其他特定形式传递。
6. 为什么 ACC 不定义通用策略引擎
一门通用策略语言需要类型系统、表达式语法、权威数据来源、数据读取授权、时效规则、确定性失败语义和沙箱。半成品表达式语言只会制造“已经能够执行”的假象，实际仍由各运行时自行解释。
ACC v1 只使用对已声明调用参数进行判断的有限、类型安全条件。运行时可以在明确的私有策略命名空间中集成更强的策略引擎，但不能把它冒充为可移植的 ACC 行为。
7. 安全演进
未知字段可被忽略，保证旧运行时能够解析较新的声明。但这不代表每个新安全字段都天然向后兼容。
影响能力暴露、审批、授权边界或脱敏的新字段，只有在旧运行时忽略它时仍然 fail-safe，或者声明同时携带旧运行时认识的保守回退时，才能进入同一个 major 家族。否则必须进入新的 major 契约家族或引入明确的能力协商。
例如：
- 可选的条件组合提示，如果旧运行时回退后只会产生更多审批，可以兼容演进。
- 新脱敏字段如果被旧运行时忽略后会记录原始敏感值，就不能只凭“字段可选”判断为兼容；它需要既有的整体敏感标记作为回退，或新的兼容边界。
8. 如何提出更强的表达能力
一个新字段提案应包含：
- 能跨多个实现成立的问题，而不是某个产品的内部需求；
- 为什么标准 OpenAPI 或实现扩展不能解决；
- 完整字段、交互、优先级和失败语义；
- 与既有字段的关系；
- 向后兼容与 fail-safe 分析；
- Parser 与 Runtime Conformance 测试向量；
- 不依赖某个产品私有架构的示例。
新能力可以先作为实现扩展存在。被真实实现验证过、具备可移植语义且能够测试的部分，可以再按照 CONTRIBUTING.md 的流程提议进入 ACC。