6. 技术实现与设计演进 · 历史项目草案 · 1.7-draft
认识 IAP 智能接入协议草案
窄屏可在表格区域横向滚动；键盘用户可聚焦表格区域后滚动查看。
版本说明：本文保留 IAP-SPEC-001、1.7-draft（2026-10-18）的早期设计，供理解方案演进；不是当前产品规范、正式行业标准或已上线能力清单。当前收窄方向请同时阅读《IAP：智能接入协议的证据格式设计与考虑》。1.7-draft 与内部格式 0.1 属于不同文档体系，不宜直接作版本大小比较。
IAP（智能接入协议）希望让智能接入（Intelligent Access，简称 IA）的能力说明、核查证据与信任判断拥有共同的数据语言，帮助人和 AI 在使用工具之前，看清能力边界、适用条件与尚未确认的问题。
本文介绍 CapaLens 项目提出的智能接入协议（Intelligent Access Protocol，IAP），依据 IAP-SPEC-001、1.7-draft，草案日期为 2026 年 10 月 18 日。它目前是项目协议提案，不是已经获行业组织采纳的正式标准，也不是 MCP 官方标准的一部分。本文所述机制是草案设计，不代表 CapaLens 已上线全部相关能力。
为什么需要接入证据
一个工具能够被发现、接受参数并返回结果，只能回答接入过程中的部分问题。真正选用它时，还需要知道：它会读取什么数据，是否修改外部状态，测试对应哪个版本，结论由谁给出，以及证据是否仍然适用。
以一个假设的库存服务为例，“查询库存”和“调整库存”可能出现在同一份工具清单里，但两者的权限、影响和确认要求不同。即使查询接口通过了测试，也不能把这个结果直接套用到调整库存的操作上。
IAP 尝试把这些差异记录成可供人阅读、也可供程序处理的信息，让接入判断从一句“可用”进一步落实到“什么能力，在什么条件下，有哪些依据”。
草案中的四个层次
IAP 将能力说明、证据、签名声明和治理信息分开组织。四者相互关联，但不能互相替代。
| 层次 | 主要描述什么 | 使用时要看什么 |
|---|---|---|
| 能力描述层 | 节点身份、接入类型、能力清单、输入、副作用、风险及确认要求 | 声明对应的具体能力与版本，是否符合当前任务 |
| 证据层 | 协议合规、功能实测、安全检查，以及设计中的动态变化跟踪 | 检查范围、方法、环境、时间、结果与未覆盖项 |
| 信任凭证层 | 签发方对特定对象和证据作出的可验证声明 | 签发方是否可信，证据是否匹配，凭证是否有效 |
| 治理与审计层 | 调用链记录和组合使用时的治理支持 | 谁作出判断，依据是什么，变化后如何复核 |
这里的“治理”是协议设计方向，不表示接入方已经建立完整的企业审批、审计或组合安全系统。具体控制仍须由使用方及相关系统落实。
能力清单和证据文件分别记录什么
能力清单首先说明“这是什么接入”。1.7-draft 列出了节点标识、主体类型与名称、服务名称、服务版本、接入类型、能力列表和更新时间等字段，并采用 JSON Schema 2020-12 表达结构。
对每项能力，草案提出记录标识、名称、描述、输入结构、副作用、风险等级及是否需要确认。例如，side_effects 用于描述操作影响，requires_confirmation 用于声明确认要求。它们是需要核查的声明，不能仅凭字段值就认定实现确实只读、低风险或已经获得用户授权。
主体分类用于区分企业、个人、教育、科研、医疗等提供方。分类标签本身不能证明主体身份、行业资质或法律地位。
证据文件则说明“这些判断从哪里来”。1.7-draft 明确列出的必含部分是 protocol_compliance、functional_test 和 security_audit，分别对应协议合规、功能实测与安全审计。动态跟踪也是项目设计的一部分，但当前文本未完整展开相关字段与判定规则。
阅读证据时，至少应把以下信息放在一起看：
| 核查维度 | 要回答的问题 |
|---|---|
| 对象与范围 | 检查的是哪个节点、版本、能力和权限配置？哪些内容未覆盖？ |
| 方法与条件 | 谁检查、如何检查、在什么环境和数据条件下检查？ |
| 结果与状态 | 是通过、失败、未测试、证据不足，还是不适用？ |
| 时间与变化 | 何时形成证据？之后的版本或权限变化是否影响结论？ |
“未测试”不能写成“失败”，也不能写成“通过”；一次成功调用不能直接证明业务结果正确。公开证据应在授权和脱敏前提下支持核查，不能为了可复现而公开密钥、个人信息或受限业务数据。
信任凭证如何发挥作用
草案设计的签发流程包括：对证据文件计算 SHA-256 摘要，将签发方、声明对象、签发时间、到期时间、证据摘要、信任等级及声明内容组织为规范化 JSON，再使用签发方私钥签名。草案推荐的签名算法是 Ed25519。
验证方需要重新计算证据摘要、核对签名，并检查有效期与撤销状态。草案还建议通过 /.well-known/iap-jwks.json 提供公钥信息。
在公钥与签发方身份的关联可信、算法和实现正确的前提下，这一过程可以核对签发来源与内容完整性。但签名不会自动证明声明内容真实，也不会保证工具安全。签发方能力、测试质量、证据范围和实际使用场景，仍然需要分别判断。
项目备忘录提出 untested、basic、verified、high 四个信任等级标签，并考虑节点自证与独立第三方签发。它们不是法定资质或安全认证。当前合并文本没有完整展开各等级的判定规则，因此不能仅凭名称推导测试覆盖、第三方背书或适用场景，也不应自行补出一套门槛。
IAP 与 MCP API CLI 如何配合
IAP 的设计定位是独立的证据与治理层，不承担实际业务调用，也不要求所有调用经过一个新的代理网关。MCP、API 和 CLI 继续提供各自的接入方式，IAP 负责关联相应的描述与证据。
| 接入方式 | 原有作用 | IAP 拟补充的信息 |
|---|---|---|
| MCP | 在 AI 应用与外部工具、数据之间建立标准化交互 | 具体工具与版本的检查记录、风险声明和凭证关联 |
| API | 提供可调用的服务接口；OpenAPI 可描述 HTTP API | 接口实现与描述是否一致，以及特定环境下的核查依据 |
| CLI | 通过命令行使用软件能力 | 执行环境、权限、副作用及对应测试证据 |
MCP 本身已经包含用户控制、数据隐私、工具安全及访问控制等要求，不能理解为“只有调用，没有安全设计”。IAP 提案侧重的是如何组织和交换特定实现的证据，两者可以互补。以上 MCP 基础能力与安全要求参见 MCP 官方规范；OpenAPI 的接口描述范围参见 OpenAPI 官方规范。
项目提出两种证据发现方式：通过 /.well-known/iap.json 等路径提供 IAP 信息，或利用 MCP Resources 暴露相关材料。MCP Resources 确实可以向客户端提供上下文数据，但用它承载 IAP 是本项目提出的集成方案，不是 MCP 官方规定的 IAP 功能。参见 MCP Resources 官方说明。
在这样的设计中，客户端可以先查询能力和证据，再结合自身策略、任务风险和用户授权决定是否调用。发现了证据、验证了凭证，都不等于取得执行权限。
当前草案距离完整实施规范还有哪些工作
1.7-draft 已提出数据结构、签名验证流程、测试套件命令和专项附录，可以用于讨论与实现设计。但当前合并文本仍引用未附上的前序章节和主体分类列表，未给出完整 $defs，并使用 example.com 作为 Schema 标识占位地址。因此，这份文本尚不足以单独充当完整、可执行的合规判定标准。
后续需要补齐和固定的内容包括：完整字段定义与约束、各等级的判定规则、JSON 规范化的具体方法、签名与密钥标识、撤销状态的查询约定，以及可复现测试和跨实现验证样例。
草案列出的 iap-tester 命令属于接口设计。命令名称的出现不代表已有可下载、可运行且通过验收的测试器；同样，设计了凭证流程也不代表已经存在正式运行的签发服务。
CapaLens 在其中承担什么角色
CapaLens 的项目定位是帮助人类与 AI 选择可信有效的智能接入。IAP 提案为能力说明与证据交换提供共同结构，CapaLens 则计划通过证据服务的实践，验证这些结构是否清晰、可核查、便于使用。
协议方向、产品计划与已交付功能需要分别说明。对每条接入，用户真正需要的是与当前版本相符的能力、风险、依据和未知项，而不是仅凭一个“可信”标签作出决定。
IAP 希望推动的，正是这种有范围、有来源、能复核的接入判断。最终是否采用某项能力，仍要由使用方结合实际任务、权限和责任边界决定。
项目来源与版本说明
本文的 IAP 设计说明依据 CapaLens 项目资料《智能接入协议标准》（IAP-SPEC-001，1.7-draft，2026-10-18）及同日关于 IAP 与 MCP 关系的项目备忘录。上述资料用于说明项目提案，不代表外部标准组织认可、已有真实部署案例或已完成产品验收。具体实现与后续修订应以正式公布的版本及验收结果为准。