Skip to main content

KnotLink 开发想法

一个本地应用互联协议。八种语言 SDK，统一的消息格式，守护进程中心路由。你的程序声明一份能力清单，其他程序就能发现、调用、编排联动——同一份清单自动生成文档和测试页。

我们发现，现代桌面应用之间缺乏一种轻量化、标准化的互联方式——协议互相难适配，跨应用协作成本高昂。

别人想接入你的软件？你得写文档、讲接口、陪着联调。对方改了需求，你改接口，所有调用方都得跟着改。

两个软件想联动？写适配代码，硬编码地址，处理不同格式。再多一个软件，适配代码直接翻倍。

应用互联本该简单，现实却总在重复造轮子。

轻量化设计取舍​

KnotLink 的"轻量"不是比谁报文更短，而是在目标场景下精准裁剪无关功能。

底层报文：KLUDF 键值对​

放弃 JSON、Protobuf 等重型序列化，自研 key=val;key=val 纯文本键值报文。无复杂嵌套符号、无固定二进制编解码，终端 telnet 可直接调试。底层完全复用操作系统原生 TCP 栈，不自定义传输层。

接口定义：静态 JSON 替代运行时协商​

MCP、DBus、gRPC 需要运行时握手、动态拉取接口清单；KnotLink 用本地静态 FuncList.json 一次性声明全部接口、参数类型、返回结构。对于常驻桌面软件，接口极少动态增减——静态声明比运行时轮询更省资源，且离线即可完成校验和文档生成。

全开源，无闭源组件​

KnotLink 全部组件 MIT 开源——SDK、协议规范、FuncList 定义、可视化编辑器、守护进程——没有任何闭源模块。开发者可以自行编译、审计、修改全部代码。

SDK 分层，依赖隔离​

核心通信逻辑无 GUI 依赖。PyQt5 仅配套可视化编辑器使用，纯后台无界面程序可完全剔除。C++/Java SDK 仅依赖标准库。

全部组件 MIT 开源。 SDK、协议规范、FuncList 定义、可视化编辑器——全部 MIT。

轻量化亮点​

部署接入门槛低。 gRPC 需提前写 proto、预编译、维护版本兼容；裸 TCP 需手写全套报文解析、参数校验、文档。KnotLink 仅一份 JSON 描述文件，自动完成参数校验、接口调用、文档生成、可视化节点。

报文兼顾轻量与可读。 KLUDF 体积远小于完整 JSON，同时人类可读，无需专用工具即可排查问题。

拒绝过度通用化。 从设计之初锁定单机本地程序联动，直接删除公网寻址、多设备路由、持久化消息、复杂权限等冗余模块，协议栈只保留信号推送、请求响应、参数校验三类刚需。

与现有方案的定位差异​

下层传输不是 KnotLink 的竞争维度。TCP、HTTP、gRPC、Unix Socket、ZeroMQ 解决的是程序之间能收发字节。KnotLink 叠加的是标准化接口描述 + 配套工具链 + 可视化编排。二者是上下层互补关系，不是替代关系。

与 MCP 的区别​

MCPKnotLink
目标场景AI 大模型 ↔ 工具桌面程序 ↔ 桌面程序
消息流AI 居中调度，必经 LLM程序直发直收，守护进程只转发不解读
能力发现运行时动态 tools/list静态 FuncList.json，离线即可预览
传输层JSON-RPC over HTTPKLUDF 键值对 over TCP
典型用户AI 应用开发者桌面工具开发者、普通用户编排联动

初心不同，设计自然不同。 两者不冲突——你可以用 MCP 让 AI 调工具，同时用 KnotLink 让工具之间自己联动。

与常见本地通信方案对比​

方案接口标准化自动文档可视化编排跨设备生态成熟度
裸 TCP / Unix Socket无，手写解析无无可，需自建40 年，RFC 标准
HTTP REST 本地服务需手写路由和序列化需额外工具无天然支持30 年，全球基础设施
gRPCProto 预编译 + 代码生成需 proto 注释 + 插件无天然支持10 年，Google 维护
ZeroMQ仅收发模型，无接口规范无无天然支持15 年，社区成熟
KnotLink一份 JSON 声明全部自动生成内置拖拽式编辑器无，仅单机早期，生态小

AppID 设计说明​

AppID 采用倒置域名格式（如 com.example.myapp），跟 Java 包名、Apple Bundle ID 同一种机制——用域名所有权保证全局唯一，不需要中心化注册。你在本地直接写一个自己的域名就行，跟注册 DNS 无关。

旧格式（0x 十六进制）仅兼容保留，新项目统一用倒置域名。AppID 的作用是区分本地多程序实例、避免信号冲突，不依赖任何在线服务。

Service 中心化与权限管理​

守护进程已实现中心化消息路由——所有节点注册和消息转发都经过它。AppID 解决的是**"我是谁"（去中心化，自声明），守护进程解决的是路由和转发**。

在此基础上，守护进程天然适合进一步承担权限管控（规划中）：

  • 哪些节点可以调用某个功能
  • 哪些节点可以订阅某个信号
  • 特定 AppID 的请求直接拒绝

权限策略在守护进程一层统一执行，不需要散落在每个节点各自实现。去掉这个中心点，权限逻辑就得每个程序自己维护——难审计、难更新、而且无法阻止恶意程序直接往 TCP 端口发消息。

场景边界（什么时候适合 / 不适合）​

适合 KnotLink 的场景：

  • 3 个及以上本地工具需要互相联动
  • 需要非开发者（普通用户）可视化编排程序联动
  • 多语言程序长期迭代，不想重复编写解析、文档、测试三套胶水代码
  • 需要统一维护接口规范，降低跨语言对接沟通成本

不适合 KnotLink 的场景：

  • 仅两个固定程序一对一简单通信 → 裸 TCP 更省事
  • 跨设备、跨网络通信 → KnotLink 定位单机，不做分布式
  • 需要运行时动态注册/热插拔接口 → 当前不支持，规划中

轻量化天然短板（诚实陈述）​

动态接口注册尚未支持。 当前运行中新增接口需修改 JSON 重启，运行时热加载在规划中。

仅覆盖单机场景。 整套裁剪逻辑全部针对本机 IPC，一旦需要多设备联动需额外封装。

协议许可​

KnotLink 全部组件（SDK 全语言客户端、协议规范、FuncList 定义、可视化编辑器）采用 MIT 许可证，可自由使用、修改、分发，无传染性约束。