智能接入的设计：定义、分类与风险维度

版本范围：本文保留 2026 年 10 月的观点与版本语境。设计目标、后续计划、说明性示例与已交付能力需分别理解，具体功能以所使用版本为准。

前面的世界观与入门文章介绍了智能世界的设想和智能接入（Intelligent Access，简称 IA）的基本概念。这一篇讲一件更基础的事："智能接入"到底指什么，怎么分类，怎么计数，怎么看风险。 这些定义不是文字游戏——它们直接决定了一个目录能不能规模化、一张卡片上该写什么、一条记录该怎么对比。

我们花了不少时间把这些口径定下来，这篇文章把结论公开出来，也欢迎讨论和纠正。

远期设想：收录 10–15 万条并扩大机器与人工核验覆盖，不是当前收录或核验现状，不是 0.4.8 / 0.5.0 上线指标，也不是既定交付承诺。分类与风险维度均须以逐条证据和实际实现核对。

一、定义：什么算智能接入

我们采纳的表述是：

智能接入：面向程序提供可稳定调用契约的接口或封装工具，AI 可以通过它连接外部系统，读取、写入数据，执行操作，或调度其他系统协同工作。形态包括 MCP、API、CLI、SDK、Skills 以及未来的新形态。收录不代表已经测试或做了安全背书。

判定时首先核对下述程序契约与接入边界；本节为设计口径，不代替逐条目录证据。

第一条是边界所在：有面向程序的稳定契约——文档化的输入输出、命令、schema 或协议。AI 靠浏览器代理去点击的网页不算；有 OpenAPI 文档的接口算。没有这条线，几乎所有软件都会被算进来。

两类情况单独处理。边缘类收录但单独标注：界面自动化（浏览器、桌面 RPA）、聚合网关、设备控制——它们能用，但要么契约不稳定，要么风险形态特殊。不收录的包括：只有图形界面的软件；AI 自身的能力（截屏点击、内置联网搜索）；静态数据集和纯教程；以及 OpenAPI 规范、llms.txt、A2A Agent Card 这类描述文件——它们不单独计数，而是挂在对应的接入记录上，作为"能否被发现"的证据。

还有一条配套的口径："智能接入"是一个中性的总称。它不暗示经过测试，也不暗示安全背书。安全性和可靠性作为证据维度呈现，不进入定义。

二、它和传统接口有什么不同

技术上没有不同——还是那些 HTTP 请求、命令行和函数调用。不同的是调用者变了：从工程师写死的代码，变成了会读、会猜、会决定的 AI。由此带来五个特点：

• 可被发现。 AI 要能找到它：注册中心、llms.txt、Agent Card、包仓库都是发现途径。找不到的接入，对 AI 来说等于不存在。
• 自描述。 工具的名称、描述、参数 schema 直接决定 AI 会不会选它、能不能调对。描述写得差的接入，在 AI 眼中就是"坏"的。
• 形态多样但可互转。 同一个能力常常同时有 API、SDK、CLI、MCP 几种形态，API 网关正在批量把已有 API 自动转成 MCP。
• 动作影响风险。 读取、写入、执行、调度有不同后果，不能仅按动作排列安全程度；数据敏感性、权限、环境与组合关系同样重要。
• 维护状态需要持续核对。 公开目录可能存在版本变化、维护状态不明和端点不可达；实际比例与厂商分布须按明确样本和日期统计。

这些特点构成 CapaLens 的设计方向：帮助发现、组织结构化事实、关联同一软件的不同接入、说明操作影响并逐步补充变化记录。实际覆盖以各版本和各条记录的证据为准。

三、三个分类维度，不混用

我们用三个彼此独立的维度给智能接入分类：

前两个维度本文展开；第三个维度——按"动词 + 对象"组织、人和 AI 共用一套、技术标签作为下层——属于后续需求组织设计，具体交付以实际版本为准。

形态分类：6 大类 15 小类

A 类是 AI 原生的接入：MCP 服务器、Agent 之间的协议（A2A）、Skills 能力包、AI 平台插件和应用。B 类是通用程序接口：Web API、SDK 与程序库、CLI。C 类是事件与消息：Webhook、消息中间件协议。D 类是数据直连：数据库协议、文件与对象存储。E 类和 F 类是边缘：界面自动化，以及编排与物理世界——聚合网关和设备控制，需要结合实际权限与后果单独评估。

新形态留了口：比如智能体支付协议（AP2、ACP）这样的新东西，先归入最接近的大类，量大了再新增小类。每个小类有一个固定代码（mcp、web_api、cli……），拟议字段模型考虑按这些代码组织；这不表示当前目录或 v0.5.0 已完整采用全部分类。

动作与风险维度

一条接入记录可以同时包含多种动作，按其中最高动作等级做初筛。这是项目内部的分类规则，不是普遍安全结论；读取敏感数据也可能具有高风险，最终还需结合数据、权限、环境和具体后果判断。这个维度直接对接"接入前的权限与风险说明"：一条接入能读什么、改什么、执行什么、指挥什么，应该在接入之前写清楚，让人和 AI 的策略引擎能据此判断。

特别要说明的是，"AI 被授予的权限和可访问的数据"在我们的校验清单里是独立的一项，不与接入自身的鉴权方式混在一起。前者问的是"AI 能动我哪些数据"，后者问的是"怎么登录"。

四、厂商格局：三层主体

团队曾按厂商层级提出初始研究优先级。这是产能分配假设，不是信息可靠性或维护水平的普遍排名；应随具体证据、权限风险与变更频率调整。

头部厂商仍需核对真实身份、版本与权限；长尾可先收录来源并标明未知，不能一概认定无人维护；中腰部厂商可以成为研究队列的一部分。人工投入取决于用户任务、证据缺口和风险，而不只取决于厂商规模。

发布者可能包括企业、个人、社区和批量封装平台。本文没有充分的原始快照、样本及去重方法，因此不展示发布者占比、集中度或 B2B 渗透率数字；来源类型只作为核查线索。

五、计数单位与记录原则

分类定好了，还要定怎么数。我们用三层实体：

厂商 → 软件 → 接入。 一条接入记录应对应具有独立身份、调用契约与配置边界的实现，形态和版本是属性。GitHub 的 REST API、GraphQL、MCP、CLI 与 SDK 可用于说明不同入口，但是否拆成独立记录须有证据，不能仅凭形式各加一条。本文准备所依据的正式目录快照为 246 个软件、363 条接口记录；另有 6 条本地补充信息记录与 11,382 条 Registry 来源登记，口径不同，不相加当作唯一接入数。文章定义不会触发目录重算或拆并。

目标字段规范要求每条记录应带三样东西；尚缺证据的字段按未知处理：适用版本；条件（已满足 / 未满足 / 未知）；证据状态。未核实的内容只作为示例，不作为硬规则。对外展示时，AI 自报、文档核查、机器检测、人工核验、业务实测与用户评论须分别说明来源和范围，不能揉成一个总分，也不能把人工看过资料等同于业务调用成功。

六、这些定义为什么重要

定义看起来枯燥，但它决定了三件事：

1. 能不能规模化。 我们把收录 10–15 万条智能接入、并逐步扩大机器与人工校验覆盖作为远期设想。这不是当前收录或核验现状，不是 0.4.8 / 0.5.0 的上线指标，也不是既定交付承诺；实际覆盖以逐条证据与可用产能为准。字段标准必须从第一天就标准化、可扩展、准确，否则收得越多返工越多。
2. 能不能对比。 只有同一套字段、同一套三态、同一套证据等级，两条接入才能并排放在一起看，AI 才能不张冠李戴。
3. 能不能诚实。 "收录"和"实测"分开计数，"官方写过"和"我们测过"分开标注，"未知"就写未知——这些都是定义层面的约束，不是事后的态度。

接下来两篇分别保留 IAP（智能接入协议）早期 1.7-draft 的思路，以及当前收窄为内部证据格式的设计讨论；二者不是一份已经生效的正式标准。

---

本文为团队内部的分类设计与优先级假设，不是已实施标准或行业普查报告。未完成主源核验的行业比例和规模数值本版暂不展示。