越来越多可信数据空间正在被建起来。

企业有企业可信数据空间，行业有行业可信数据空间，城市也开始建设自己的可信数据空间。围绕参与方接入、身份认证、数据目录、数据产品发布、数字合约和使用控制，单个空间内部正在逐渐形成一套相对完整的可信流通机制。但当这些空间真正进入业务运行以后，一个更现实的问题会出现：这些空间之间怎么办？

如果汽车可信数据空间需要能源空间中的充电设施数据，如果城市可信数据空间需要行业空间中的专业数据，如果一个人工智能任务同时依赖多个空间的数据资源，那么单个空间内部建设得再完整，也无法独立解决全部问题。

直观上，我们很容易把它理解成一个“连接”问题。空间A部署一个连接器，空间B也部署一个连接器，如果双方技术体系不同，就在中间增加一个网关，把接口和协议转换一下。

但真正进入交易以后会发现，网络连接反而不是最难的部分。

空间A已经认证过的参与方，空间B是否认可？空间A发布的数据产品，空间B能否准确理解？提供方提出的数据使用规则，进入另一个空间以后是否继续成立？数据交付之后，又如何证明消费方确实按照约定使用了数据？

两个空间需要跨越的并不只是网络边界，而是治理边界。因此，跨空间互联真正需要解决的，也不是“两个连接器怎么连”，而是一个空间内部已经建立起来的身份、规则和信任关系，在进入另一个治理域以后，如何被重新理解、重新验证，并最终形成一笔双方都能够接受的可信交易。

这也是可信数据空间从“建设一个空间”走向“形成数据空间网络”时必须跨过的一道门槛。

可信数据空间首先需要建立明确的治理边界。

企业可信数据空间通常围绕企业及其上下游协作展开，行业可信数据空间围绕特定领域组织参与主体和数据资源，城市可信数据空间则更多面向一定区域范围内的数据流通利用。

这样的边界并不是人为制造的限制，而是形成稳定数据流通规则的前提。只有明确谁能够参与、什么数据可以进入、数据按照什么条件使用，以及出现问题以后由谁承担治理责任，身份认证、数据目录、数字合约和使用控制等机制才真正具有可执行基础。但真实业务并不会严格按照这些治理边界展开。

汽车企业开展智能驾驶研发时，除了车辆和零部件数据，还可能需要道路、气象、地图和交通运行数据；供应链金融除了金融机构自身掌握的信息，也离不开制造、物流和交易数据；面向人工智能训练和复杂城市治理的任务，则更可能同时依赖多个行业和不同主体的数据资源。

数据空间可以按照企业、行业或者城市组织，但业务价值通常沿产业链、供应链和具体任务产生，两者之间天然存在错位。

这种错位意味着，跨空间并不是单个可信数据空间建设完成以后额外增加的一项高级功能，而是业务需求穿透治理边界之后产生的自然结果。

单个空间主要解决的是一个治理域内部的数据如何按照共同规则流通，而随着真实业务不断扩展，问题必然进一步转向：多个治理域之间如何形成持续的数据协作关系。

如果这个问题长期得不到解决，还可能形成一种新的“空间孤岛”。传统的数据孤岛表现为数据被封闭在不同系统中。而当大量可信数据空间分别建设以后，如果空间之间仍然需要大量人工协调和定制化集成才能协作，那么数据虽然已经可以在一个个局部空间内部流通，却仍然难以跨越空间边界。

一个空间不仅要解决内部数据能不能可信流通，还要解决能不能与其他空间建立稳定、可重复的数据协作关系。

跨空间互联首先表现为技术系统之间的连接，因此连接器和跨空间网关很容易成为工程设计的中心。

两个空间分别部署连接器，通过共同协议完成消息交换；如果接口、协议版本或者数据模型存在差异，再引入网关进行适配，这在技术实施中具有现实必要性。

但这些能力首先解决的是“双方能不能交流”，并不能自动回答“交流以后形成的交易关系能不能被双方接受”。

例如，空间A的参与方向空间B请求某项数据产品，只要网络和协议兼容，双方可以顺利建立连接。但空间B真正决定是否提供数据时，仍然需要判断请求方是谁、是否具备相应业务资质、凭证由谁签发，以及这些证明来源是否在自己的信任范围内。

数据产品也存在同样的问题。两个系统能够交换完全相同的数据结构，并不意味着双方对于数据质量、业务口径、更新频率和使用范围拥有相同理解。技术层面的“格式一致”，距离业务层面的“含义一致”仍然存在很长距离。

数字合约会进一步暴露这种差异。假设空间B规定某项数据只能用于科研分析，禁止进入模型训练，并要求在一定期限后删除。连接器可以传递这些条件，网关也能够把规则转换成另一种格式，但技术上能够解析，并不意味着治理上已经实现互认。“科研分析”是否包括模型训练，删除义务如何证明，发生违规以后责任如何划分，这些都不是网络连接本身能够决定的。

因此，跨空间网关更适合被理解为异构环境中的适配组件，而不是互联本身。它可以解决协议和表达方式“听不懂”的问题，却不能单独决定一项身份、规则或者责任关系“认不认”。

这也是IDSA近年来演进中一个值得关注的变化。早期Connector是非常突出的技术要素，但随着不同实现和不同数据空间逐渐出现，关注点开始从某一种连接器产品，转向不同参与方代理之间应该共同遵循怎样的交互规则。

真正需要解决的，不再只是两个系统如何连起来，而是不同数据空间在技术、语义和治理层面，如何形成能够持续协作的共同基础。如果空间之间缺少这种稳定机制，每增加一个新的数据空间，都可能重新建立一套点对点映射和适配关系。这样的方式能够支撑少量具体项目，却很难随着空间数量增长而平滑扩展。

所以，真正决定跨空间互联能否成立的，不只是连接器是否能够交换消息，而是空间边界上是否存在一套能够共同解释身份、资源、规则和交易状态的基础。

当交易进入另一个治理域以后，最先需要重新判断的是参与方是否可信。在空间A中已经完成身份认证并获得准入资格，并不意味着空间B必须自动接受相同结论。两个空间可能拥有不同的业务目标、风险偏好和准入条件，如果空间B仍然承担自身治理责任，它就必须保留重新判断的权利。

因此，跨空间互信不应理解为信任结果的直接继承，而更适合理解为：支撑信任判断的证据能够跨域流动。

空间A或者其他可信机构，可以提供参与方的身份、角色、业务资质、安全能力和处理条件等证明；空间B再结合自身的准入规则和风险要求，判断这些证据是否满足当前交易条件。

换句话说，跨空间传递的并不是一句“这个参与方是可信的”，而是“这里有一组你可以验证的证据，你可以根据自己的规则重新判断”。这两个逻辑之间的差别非常重要。

前一种方式实际上是在要求空间B接受空间A已经形成的信任结论，随着空间数量增加，很容易进一步演变成谁有资格给谁背书、哪个空间的信任等级更高等复杂问题。

后一种方式则保留了不同空间自身的治理自主性。外部系统负责提供可以验证的事实，本空间继续拥有最终判断权。身份认证因此只是跨域信任建立的起点。证明“你是谁”之后，还需要进一步证明“你是否具备完成这次交易的条件”。

同一个参与方访问不同数据产品时，可能需要提交不同的业务资质、用途说明或者运行环境证明。因此，可信与否并不是一个脱离场景的固定标签，而是与具体交易目标和数据产品条件相关。

这也是去中心化声明协议（Decentralized Claims Protocol，DCP）、可验证声明以及信任框架等机制值得关注的地方。它们真正想解决的，并不是再建立一套新的账号体系，而是让组织身份、角色、业务资质和其他声明能够被另一参与方验证，从而支撑各方根据自己的规则重新建立信任。而信任也不会随着身份验证完成而结束。数据提供方在交易形成过程中还需要判断消费方是否接受其使用条件，数据交付以后则需要进一步确认这些条件是否真正得到执行。

因此，一笔跨空间交易实际上贯穿了三个连续阶段：交易前判断参与方有没有资格进入，交易形成过程中判断双方能否围绕数据使用规则达成一致，交易完成以后再判断这些规则有没有被真正履行。

日志、使用控制、审计和可信运行环境的价值，也正是在这里变得更加清晰。它们并不仅仅用于提高系统安全性，更重要的是帮助把“发生了什么”转化为另一个治理域能够验证的履约事实。

所以，跨空间信任最终要解决的，并不是建立一个覆盖所有空间的统一“可信名单”，而是形成一套让不同空间能够依据共同证据独立作出判断的机制。统一的是证据如何表达和验证，保留的是不同空间最终作出信任判断的治理权。

既然信任需要依靠证据跨空间重新建立，那么这些证据和规则就必须能够被另一个空间理解，标准化问题也由此出现。

但标准化并不意味着要求企业、行业和城市可信数据空间使用完全相同的技术平台、数据模型和治理规则。

不同行业面对的数据对象、业务语义和责任体系本来就存在差异，试图消除所有差异既缺乏现实基础，也不符合数据空间保持自治的基本逻辑。

跨空间更需要统一的是：当两个空间发生交互时，哪些内容必须被双方共同理解。

从一笔完整交易来看，至少会涉及几个基本对象：交易主体需要能够被识别，数据资源需要能够被描述，业务语义需要拥有一致或者可映射的解释，使用规则需要能够被表达，双方需要对交易状态保持共同认知，履约行为最终还需要形成可验证证据。这些内容共同构成了空间边界上的最小公共语言。其中，语义互操作可能比接口兼容更加长期。

两个空间采用完全相同的字段或者消息格式，并不意味着“实时数据”“科研用途”“合格供应商”这些业务概念具有相同含义。如果业务语义没有真正对齐，系统可以顺利交换数据，但使用过程中仍然需要依赖大量人工解释。

因此，更现实的语义体系可能不是建立一个覆盖所有行业的超级数据模型，而是在公共层形成一组基本概念，各行业继续保留自己的专业扩展，再通过明确的映射机制解决跨领域差异。数字合约同样体现了这种边界。

标准可以规定权限、禁止事项、义务和使用条件应该如何机器可读地表达，但无法替治理主体决定某项条件是否能够接受。当两个空间的规则发生冲突时，技术机制可以帮助双方发现冲突，最终如何处理仍然需要治理规则参与。

标准负责让规则能够表达、交换和比较，治理负责决定规则是否接受，以及发生冲突以后如何处理。IDSA从具体Connector逐渐走向数据空间协议、去中心化声明协议和信息模型，也体现了类似的思路。

真正值得稳定下来的，不是某一种技术产品的内部实现，而是不同参与方代理跨越空间边界以后应当遵循怎样的交互行为。所以，跨空间标准化的目标并不是让所有空间变得一样，而是统一那些“不统一就无法完成交易”的内容。

剩下真正需要保留的行业差异、技术差异和治理差异，再由映射、适配或者网关去处理。这时网关的角色也会更加合理：它负责解决剩余异构，而不是承担跨空间互联的全部逻辑。

身份、信任和标准最终都需要落到真实的数据交易中。

跨空间互联真正需要保持连续的，也不是某一条固定的数据传输通道，而是一笔交易从资源发现、资格判断、规则协商，到数据交付和履约验证的完整状态过程。

仍然以汽车可信数据空间使用能源空间中的充电设施数据为例。请求方首先需要发现目标数据产品，并获得数据范围、更新频率、质量和使用条件等基本描述。这一步解决的是“有没有我需要的数据”。找到数据以后，提供方需要进一步验证请求方提交的身份和可验证声明，判断对方是否满足这项数据产品的准入要求。这一步解决的是“你有没有资格使用”。

资格确认以后，双方才会围绕用途、期限、处理环境、再分发以及其他约束进行协商，并最终形成共同接受的数据使用协议。这一步解决的是“在什么条件下可以使用”。

数据空间协议（Dataspace Protocol，DSP）中的目录发现、合约协商和传输过程，正是在尝试把这些原本可能依赖大量人工沟通的过程，转换成不同参与方代理都可以共同理解的交易状态。

值得注意的是，在双方形成使用协议以前，原始数据可能根本没有真正开始流动。跨空间交易最先建立起来的是一组控制关系：谁请求什么数据，依据什么资格，在什么条件下使用，以及这笔交易当前处于什么状态。

当这些关系得到确认以后，具体的数据交付方式反而可以比较灵活。数据可以通过API调用，也可以通过文件或者对象存储交付；可以进入可信执行环境，也可以保持数据不动，仅允许算法进入数据所在环境完成计算。

这一区分非常重要。它说明跨空间互联真正需要保持一致的是交易控制关系，而不是固定的数据传输路径。数据不一定需要经过一个统一中转平台，只要交易条件已经被双方共同理解和确认，实际的数据交付方式完全可以根据业务需求和安全要求选择。数据交付之后，交易也没有立即结束。

此前达成的数据使用协议中，可能还规定了用途范围、保存期限、再分发限制或者其他持续性义务。这些要求需要在后续使用过程中得到执行，并通过日志、策略执行结果、环境证明或者审计记录形成履约证据。跨空间真正连接起来的，不是两个平台，而是一条贯穿交易生命周期的可信关系。

从资源发现开始，到身份验证、规则协商、数据交付，再到最终的履约证明，只要其中某一个关键状态在跨越治理边界以后失去共同解释，整笔交易就可能重新退化成人工确认和双边协调。

即使跨空间交易已经被协议清楚描述，也不能直接推出不同厂商和不同空间的实现一定能够协作。技术标准规定系统“应该如何表现”，但具体实现仍然可能在消息字段、状态转换、异常处理和边界条件上存在差异。

如果每增加一个新的连接器，都需要重新与已有系统逐一进行完整联调，那么跨空间协作仍然无法真正实现规模化。

技术兼容性测试套件（Technical Compatibility Kit，TCK）的价值就在这里。它尝试把协议中的规范性要求进一步转换成机器可以执行的测试，使“支持某项协议”不再完全依赖厂商自己声明，而是可以通过公共测试验证实现是否满足相应技术要求。

但这里需要进一步区分三个容易被混在一起的层次。

第一个层次是协议符合性。它回答的是：某个实现有没有按照协议规定的消息格式、状态转换和异常行为正确工作。

第二个层次是互操作性。它回答的是：两个分别符合规范的实现放在一起以后，能不能连续完成同一笔真实交易。

第三个层次才是跨域可信。它回答的是：当交易真正跨越两个治理域以后，参与方身份、业务规则、使用约束和履约结果能不能继续被另一方接受。

这三个层次并不能相互替代。通过协议测试，并不意味着双方的数据语义已经一致；两个连接器能够互操作，也不能说明两个空间的治理规则已经实现互认。技术兼容只是完整跨空间互联中的一个组成部分。

因此，未来更有价值的评价方式，应该逐渐从静态检查“有没有连接器、数字合约和使用控制模块”，转向围绕一笔完整交易设计场景化验证。

一个空间能不能发现其他空间的数据产品，能不能验证对方身份和可验证声明，能不能形成双方一致的数据使用协议，传输过程能不能正确推进，使用规则能不能真正得到执行，最终形成的履约证据又能不能被另一空间验证。

这些连续行为，比单纯的功能列表更能说明一个空间是否真正具备跨域协作能力。这也是为什么跨空间互联最终需要从“实现了某项标准”走向“能够证明自己具备互操作能力”。

当公共标准和公共测试基线逐渐稳定以后，一个新空间进入已有协作网络时，就不需要首先与所有既有空间重新完成一轮完整的定制化集成，而可以先通过统一的协议测试、能力验证和信任证据证明自身具备基本协作条件。只有到了这个阶段，跨空间互联才真正开始摆脱项目制集成。

如果前面的机制主要解决两个空间如何完成一笔可信交易，那么真正进入规模化阶段以后，还需要回答一个更长期的问题：一次成功的跨空间交易，如何演变成多个空间之间稳定、可持续的协作关系？

协议可以规定系统如何交互，测试可以证明技术实现是否符合公共规范，但这些机制无法替不同空间决定哪些凭证可以互认、哪些信任锚点可以接受、哪些语义模型能够映射，也无法自动解决规则冲突、责任划分和风险事件处置。

随着空间数量增加，这些原本依赖项目双方临时协商解决的问题，需要逐渐沉淀为空间与空间之间相对稳定的治理安排。因此，一个成熟的数据空间网络实际上同时存在两类关系。

第一类是参与方之间围绕具体数据产品形成的交易关系。它解决一笔数据交易如何从资源发现走向履约验证。

第二类是不同空间治理主体之间形成的长期协作关系。它决定双方依据什么接受彼此提供的身份、规则和交易证据，以及发生冲突以后按照什么机制处理。

前者保证“交易能够发生”，后者降低“每次交易都需要重新协商全部基础规则”的成本。

这也意味着，可信数据空间网络并不是把越来越多空间连接到一个更大的中心平台。更加可持续的路径，是在保持不同空间治理自主性的基础上，把反复出现的共性问题逐渐沉淀为公共边界标准、信任框架、互操作验证和治理协同机制。

一个新的空间加入以后，如果能够依靠这些公共能力建立基本协作关系，而只需要针对具体行业和业务差异进行有限协商，跨空间互联才真正具有规模化复制的基础。IDSA的演进路径在这一点上提供了一个很有价值的参照。

从早期参考架构和Rulebook，到数据空间协议（DSP）、去中心化声明协议（DCP）、TCK以及跨数据空间互操作讨论，其关注点实际上不断从“一个数据空间应该是什么”，推进到“不同参与方如何交互”“信任依据什么建立”“如何证明技术实现符合共同规则”，并进一步触及不同治理域之间如何形成长期协作关系。

真正值得借鉴的并不是某一个具体组件，而是这种从单空间能力逐渐走向网络协作能力的演进逻辑。国内可信数据空间具有自己的制度环境、应用模式和数据基础设施体系，没有必要简单复制欧洲数据空间的实现方式。

但随着越来越多空间进入实际运行，身份互认、语义互操作、规则协调、履约验证和技术兼容等问题几乎必然出现。

下一阶段真正值得关注的，也将不再只是“建设了多少个可信数据空间”，而是这些空间在保持自身治理边界的同时，能不能依靠公共规则和可验证证据建立稳定的数据协作关系。

回到最初的问题，跨空间互联真正需要解决的，并不是两个连接器之间是否应该增加一个网关。

连接器、网关、协议和身份凭证都是完成跨域交易的重要工具，但真正决定不同可信数据空间能否长期协作的，是原本隐含在各自内部的信任关系，能否在空间边界上被表达、理解、验证、协商和执行。

单个可信数据空间解决的是一个治理域内部如何形成可信的数据流通关系。当数据交易跨越治理边界以后，不同空间如何在保持自治的同时，继续建立可以被双方接受的可信关系。

所以，跨空间互联最终需要沉淀的并不是一个更大的交换中心，而是一组能够被不同空间共同使用的公共协作机制。连接器解决“怎么交互”，标准解决“怎么理解”，信任机制解决“为什么接受”，证据体系解决“如何证明”。

当这些能力逐渐稳定下来以后，一个新的数据空间才有可能不依赖大量一对一项目集成，就进入已有的数据协作网络。到了那个阶段，我们讨论的也就不再只是一个个相对独立的“可信数据空间”，而是一张真正能够持续协作、不断扩展的：可信数据空间网络。