公开说明
本文是Kamitu.ai的公开纲领，描述其核心定义、技术主张与长期发展路线。文中有关真实闭环、开放规范、开源实现、一致性测试、认证及开放治理的内容，既包含当前已经形成的理论与架构，也包含需要通过后续研发、真实系统接入、现场执行和跨项目验证逐步实现的目标。具体状态以Kamitu.ai正式版本、代码仓库、测试结果及项目验收证据为准。

人工智能正在迅速获得理解、判断、规划和生成意图的能力。

能源系统能够发现异常并提出优化方案，机器人能够规划路径并执行动作，BIM、GIS、IoT、设备平台、ERP、MES和数字孪生正在描述越来越多的现实对象与运行状态。

但当智能真正进入现实世界，仍有几个基础问题没有被普遍解决：

AI面对的究竟是哪个真实对象？

不同系统中的标识，是否指向同一个房间、设备、构件或能源节点？

一个意图在什么权限、状态和安全条件下，才能转化为真实执行？

系统返回“成功”，是否代表现实动作真实发生？

结果依据什么证据验证，又如何形成可追溯、可复用的事实记录？

这些问题无法通过增加一个接口、一个看板或一个智能体解决。

真实世界需要一套连接数字系统、智能主体与现实执行过程的共同协议。

这正是Kamitu.ai存在的原因。

---

一、Kamitu.ai解决的不是“更多连接”，而是真实闭环

Kamitu.ai不是新的信息孤岛，也不是包揽所有行业功能的超级平台。

Kamitu.ai要建立的是：

智能系统进入真实空间的统一对象、接入、执行、证据、验证和事实协议。

它以SG——Spatial Granule，空间颗粒——作为真实空间的共同对象入口。

一个SG可以是一栋建筑、一个房间、一台设备、一个能源节点、一个机器人任务点，也可以是任何具有明确身份、状态、执行和验证边界的真实空间对象。

不同系统继续保留各自的专业能力：

• BIM描述设计与工程对象；

• GIS描述位置与空间关系；

• IoT采集设备与环境状态；

• BMS和EMS执行专业能源控制；

• 机器人平台负责感知、导航与动作；

• ERP和MES管理业务与生产；

• AI生成分析、判断与行动意图。

Kamitu.ai不替代这些系统。

它补充的是一条经常缺失的真实闭环：

外部系统或AI意图
→ 真实对象解析
→ 连续身份确认
→ 当前状态读取
→ 权限与安全判断
→ 命令与真实执行
→ 结果事件
→ Evidence
→ QC
→ DQ事实记录

Kamitu.ai关注的不是系统能否互相调用，而是：

不同系统能否围绕同一个真实对象，形成受治理、可证明、可追溯的执行闭环。

---

二、API连接不等于真实空间接入

API能够返回数据，不意味着真实空间已经被可靠接入。

普通接口通常无法完整回答：

• 当前调用对应哪个真实对象；

• 对象在不同系统中分别是什么身份；

• 当前状态是否允许执行；

• 调用主体是否拥有对象级权限；

• 指令是否作用于正确设备；

• 动作是否真实发生；

• 结果依据哪些证据；

• 验证采用什么规则和版本；

• 失败、拒绝、超时和人工接管是否被记录。

因此，Kamitu.ai提出Spatial Socket。

Spatial Socket不是普通API地址，而是一组面向真实空间的协议能力：

对象解析
+ 身份映射
+ 状态读取
+ 事件订阅
+ 能力发现
+ 权限判断
+ 执行调用
+ 证据回传
+ 结果验证
+ 事实输出

Kamitu.ai V2解决真实空间如何进入确定性执行。

Kamitu.ai V2.5 Spatial Socket OS进一步解决：

外部智能系统如何统一、可靠、安全地接入真实空间执行内核。

---

三、Kamitu.ai所要形成的，不是普通实时数据

现实世界已经在持续产生温度、功率、坐标、设备状态、告警、图片、视频、任务日志和系统回执。

这些数据通常只能说明某个信号发生了变化，却未必能够说明：

• 变化属于哪个真实对象；

• 为什么发生；

• 谁发起并批准了动作；

• 动作是否真正完成；

• 结果是否满足业务和安全要求；

• 证据是否完整；

• 最终责任属于谁。

Kamitu.ai所要形成的，是具有完整执行上下文的实时执行事实：

Target SG / UID
+ Execution Actor
+ State Before
+ Intent
+ Authorization
+ Command
+ Physical Execution
+ State After
+ Evidence
+ QC Rule
+ QC Result
+ Responsibility
+ Timestamp

它不是普通遥测数据，而是：

Real-time Execution Fact Stream

实时执行事实流

事实边界说明
本文所称“事实”或“DQ事实记录”，是指依据明确对象、执行过程、Evidence和QC规则形成的协议事实记录。它不自动等同于法律事实、审计意见、检测认证结论、行业信用、金融信用或资产价值。相关专业结论仍应由具有相应职责和资格的主体作出。

概念性示例：房间级能源调节

以下内容用于说明Kamitu.ai执行事实的结构，不代表该具体场景已经完成现场验收。

普通能源系统可能记录：

空调功率由15kW降至11kW

Kamitu.ai所要进一步形成的是：

目标对象：
SG-HVAC-ZONE-001

前置状态：
区域无人、无预约、无人工锁定，
设备状态允许调整。

执行过程：
经过对象级权限和安全策略检查，
由指定BMS Connector执行设定值调整。

结果证据：
设备回执、电表曲线、温湿度数据、
占用状态及规则版本。

验证结果：
Comfort QC与Energy QC通过。

事实输出：
ENERGY_DQ_ROOM_IDLE_OPTIMIZATION

前者是信号。

后者是具有对象、动作、证据、规则、结果和责任上下文的事实样本。

Kamitu.ai负责的是：

组织证据
→ 固化规则
→ 保存验证结果
→ 形成可追溯记录

它不替代法院、审计机构、检测认证机构或专业责任主体。

---

四、Kamitu.ai旨在建立真实闭环的执行事实形成机制

传统数据平台通常遵循：

产生数据
→ 汇集数据
→ 分析和展示

Kamitu.ai的运行逻辑是：

定义真实对象
→ 读取当前状态
→ 形成受治理意图
→ 触发现实执行
→ 采集结果证据
→ 按规则完成验证
→ 生成结构化事实

在真实系统完成接入、执行、Evidence采集和QC验证后，Kamitu.ai可以通过协议闭环持续形成高质量事实数据。

长期飞轮是：

更多SG对象
→ 更多专业Socket
→ 更多受治理执行
→ 更多Evidence
→ 更多QC结果
→ 更多实时事实样本
→ 更好的AI与规则
→ 更高质量的执行
→ 更多场景接入

能源调节、机器人巡检、设备维护、工程安装与现场验收，都可以成为可复核的真实执行样本。

这些事实样本可以服务于：

• AI执行反馈；

• 机器人任务学习；

• 设备运维复盘；

• 能源效果验证；

• 工程履约评价；

• 责任追踪；

• 规则优化；

• 多项目统计；

• 经明确授权的模型训练。

因此，Kamitu.ai最深层的价值不是采集更多数据，而是：

把现实世界中原本割裂的对象、状态、意图、动作、证据和结果，转化为机器能够理解、验证和复用的事实样本。

---

五、不同场景，共用同一条事实主线

在能源场景中

Energy Intent
→ Space / Equipment SG
→ Permission & Safety Gate
→ BMS / EMS Execution
→ Meter & Environment Evidence
→ M&V / Comfort QC
→ Energy DQ

能源系统不仅要说明消耗了多少，还要说明哪个对象在什么意图下执行了什么调节，依据什么证据完成验证，并形成了什么结果。

在机器人场景中

AI / Business Intent
→ Target SG
→ Robot Identity
→ Capability & Safety Check
→ Robot Execution
→ Arrival / Action Evidence
→ Result QC
→ Robot DQ

机器人到达坐标，不等于到达正确对象。

机器人返回任务完成，也不等于业务结果成立。

只有对象、权限、执行、证据和验证完整关联，机器人任务才可能形成事实记录。

在设备运维中

Device Alarm
→ Device SG
→ Maintenance Intent
→ Repair Execution
→ Device Feedback
→ Recovery Evidence
→ QC
→ Device DQ

工单关闭，不等于设备已经恢复。

设备恢复，也不等于运行质量、能效与安全状态已经通过验证。

在工程和建造中

Design / Work Order
→ Component SG
→ Manufacturing or Installation
→ Site Evidence
→ QC
→ Delivery Fact

Kamitu.ai将设计对象、制造对象、安装位置、执行动作和质量证据连接为持续的对象事实。

所有场景共享同一条主线：

对象
→ 身份
→ 状态
→ 意图
→ 权限
→ 执行
→ 证据
→ 验证
→ 事实

---

六、数据本地留存与授权使用，而不是集中占有

Kamitu.ai的终局，不是把建筑、园区、能源、机器人和设备数据全部集中到一个中心平台。

数据可以继续留在产生它的组织、项目和现场：

Site A Local Fact Store
Site B Local Fact Store
Site C Local Fact Store

不同站点共同采用：

共享对象模型
+ 共享事实Schema
+ 共享验证协议
+ 共享版本规则

在明确授权下，可以开展：

• 跨站点查询；

• 脱敏统计；

• 本地计算；

• 分布式模型协同；

• Evidence摘要交换；

• Provenance与哈希验证；

• 跨组织事实协作。

Kamitu.ai追求的不是中心化的数据所有权，而是：

真实执行事实的结构统一、互操作能力、验证机制与可信交换。

数据留在产生它的组织和现场，按照明确权限与用途参与协同。

---

七、为什么Kamitu.ai的长期终局必须开放

Kamitu.ai要连接的不是一种设备、一个行业或一家公司的系统。

它面对的是：

• BIM；

• GIS；

• IoT；

• BMS；

• EMS；

• ERP；

• MES；

• 机器人；

• 智能设备；

• AI Agent；

• 数字孪生；

• 真实空间中的各类设施。

如果协议长期由一家企业封闭控制，其他厂商会担心被锁定，大型组织也会担心长期依赖单一供应商。

真正的基础设施需要具备：

厂商中立
+
可独立实现
+
可验证兼容
+
允许多方贡献
+
规则公开、过程可追溯

因此，Kamitu.ai的长期终局是：

成为一套中立、开源、可扩展、可测试、可认证的真实空间执行事实基础设施。

成熟的开放结构应当是：

协议开放，代码开源，数据本地留存并按授权使用，规则公开、过程可追溯，兼容可测，认证有据。

---

八、终局开源，不等于今天全量公开

Kamitu.ai当前仍处于协议定义、真实Pilot、Connector、Evidence、QC、DQ和跨项目验证不断形成的阶段。

现在立即全量公开，可能导致：

• 协议尚未稳定便形成兼容负担；

• 未完成确权的技术被重新包装；

• 不成熟实现被误认为正式标准；

• 不兼容分支提前出现；

• 社区治理机制尚未建立；

• 客户数据与生产安全边界被混淆。

因此，Kamitu.ai坚持：

终局开源，当前确权。

协议开放，节奏受控。

越接近公共协议，越应开放；越接近客户数据、执行安全和生产环境，越应严格治理。

---

九、Kamitu.ai的四层开放结构

第一层：开放核心协议

长期开放：

• SG基本模型；

• UID语义；

• State、Event、Intent和Command；

• Execution Record；

• Evidence结构；

• QC结果类型；

• DQ状态和版本关系；

• Spatial Socket Capability Profile；

• 基础Schema；

• 核心API与事件契约。

任何组织都可以独立理解并实现兼容系统。

第二层：开源参考实现

逐步开放：

• SG Registry参考实现；

• UID Mapping基础组件；

• Connector SDK；

• Mock Socket；

• Sandbox；

• Event Envelope；

• Evidence Collector；

• 基础QC Engine；

• DQ Ledger参考实现；

• CLI工具；

• 示例Connector。

参考实现用于证明协议可以运行，并降低生态接入成本。

第三层：开放一致性测试

未来逐步开放：

• Contract Conformance；

• Real-System Integration；

• Verified Execution；

以及相关测试工具和结果格式。

未来开放一致性测试后，任何实现都可以运行公开测试；涉及Kamitu.ai官方兼容标识或认证声明的，应按照届时正式发布的规则进行。

第四层：生产资产保持本地留存与授权管理

以下内容不会因开源而自动公开：

• 客户数据；

• 生产Evidence；

• 人员和设备身份；

• 真实对象映射；

• 密钥和生产配置；

• 高风险安全规则；

• 客户专属Connector；

• 私有QC规则；

• 项目DQ记录；

• 未经授权的训练数据；

• 商业秘密和安全信息。

必须始终明确：

软件开源
≠ 数据开放

协议开放
≠ 客户场景公开

测试开放
≠ 任何人可以自行认证

---

十、开源之后，Kamitu.ai的价值不再主要来自代码封闭

一个开放基础设施的长期价值，来自：

• 协议定义与持续演进；

• 官方版本和兼容窗口；

• SG、Capability、Event、QC、DQ和Connector命名空间；

• 一致性测试与认证机制；

• 真实样板和现场方法；

• 企业级部署与运行服务；

• Connector与行业Profile生态；

• 兼容的执行事实协作体系。

即使核心协议和参考实现开放，企业仍然需要：

• 私有部署；

• 托管运行；

• Connector开发；

• SG与UID治理；

• 安全审计；

• Evidence存储；

• QC规则服务；

• 兼容性测试；

• 培训；

• SLA与持续支持。

Kamitu.ai的商业模式可以概括为：

协议开放
+
参考实现开源
+
企业运行收费
+
专业Connector收费
+
事实验证收费
+
测试、认证与支持收费

其中，正式认证机制需要在真实场景、测试规则和组织治理条件成熟后逐步建立。

---

十一、Kamitu.ai的开放演进路线

阶段0：确权与真实闭环

PRIVATE DEVELOPMENT

阶段1：开放规范

OPEN SPECIFICATION

阶段3：开放一致性测试

OPEN CONFORMANCE

阶段4：核心Runtime开源

OPEN CORE RUNTIME

阶段5：多方参与的开放治理

OPEN GOVERNANCE

---

十二、我们坚持什么

Kamitu.ai坚持对象优先。
没有明确对象，就没有可信执行。

Kamitu.ai坚持权限和安全优先。
AI意图不能绕过治理直接控制真实设备。

Kamitu.ai坚持Evidence优先。
接口成功、页面成功和任务返回成功，都不能自动等同于现实结果成立。

Kamitu.ai坚持验证优先。
Evidence必须经过明确规则和版本，才能形成QC结果。

Kamitu.ai坚持失败也是真实事实。
拒绝、超时、冲突、部分完成、证据不足、人工接管和撤销，都必须被记录。

Kamitu.ai坚持数据本地留存与授权使用。
数据留在产生它的组织和现场，协议负责结构统一与可信协同。

Kamitu.ai坚持开放终局。
开放不是放弃责任，而是让不同系统能够共同实现、共同验证和共同演进。

Kamitu.ai坚持边界诚实。
架构不是部署，Mock不是现场，接口成功不是物理执行，一次样板也不是行业标准。

---

十三、Kamitu.ai的公开定位

当前定位

Kamitu.ai V2.5 Spatial Socket OS，是连接智能系统与真实空间执行内核的统一协议接入层。

核心价值

Kamitu.ai通过统一协议，让不同系统围绕同一个真实空间对象形成受治理、可验证的执行闭环，并在真实接入与验证条件成立后，持续形成可追溯的实时执行事实。

数据立场

Kamitu.ai不以集中占有数据为目标，而是统一真实执行事实的对象、结构、证据、规则和交换方式。

开源终局

Kamitu.ai的长期终局，是成为中立、开源、可扩展、可测试、可认证的真实空间执行事实基础设施。

最终使命

让真实空间从可接入、可执行、可验证，进一步走向可学习与开放协同。

From Accessible and Executable Real Space
to Verifiable, Learnable and Open Real Space.

---

结语

AI正在迅速获得生成意图的能力。

机器人、设备和自动化系统正在迅速获得执行动作的能力。

但真实世界需要的，不只是更多意图和更多动作。

它需要知道：

• 动作面对哪个真实对象；

• 谁拥有执行权限；

• 当前状态是否允许；

• 动作是否真实发生；

• 结果由什么证据支持；

• 使用什么规则完成验证；

• 最终形成了什么可追溯的事实记录。

Kamitu.ai不希望以封闭软件限制真实世界的连接与协同。

Kamitu.ai希望通过一套开放协议，让系统、设备、机器人、AI和组织围绕共同对象形成真实闭环，并让每一次受治理的执行，都成为可信、可学习、可协同的事实样本。

Kamitu.ai不是又一个数据平台。

它致力于成为让真实世界持续形成可信执行事实的开放协议基础设施。