协议分层
KnotLink 协议分为 5 层。下层解决"能不能通"，上层解决"好不好用"。
┌──────────────────────────────────────────────┐
│ ⑤ 工具链层 │
│ FLEditor · API 测试页 · 自动文档 · 节点索引 │
├──────────────────────────────────────────────┤
│ ④ 能力描述层 │
│ FuncList.json · plugin_manifest.json │
├──────────────────────────────────────────────┤
│ ③ 通信模式层 │
│ 请求-响应（OpenSocket）· 发布-订阅（Signal） │
├──────────────────────────────────────────────┤
│ ② 消息体层 │
│ KLUDF 键值对 · JSON · CLI │
├──────────────────────────────────────────────┤
│ ① 传输层 │
│ TCP · 守护进程路由 │
└──────────────────────────────────────────────┘
① 传输层 — TCP + 二进制帧 + 守护进程路由
节点与守护进程之间走 TCP，复用操作系统原生栈，不自定义传输层。TCP 字节流之上用 8 字节定长帧头（Magic + Version + Length）定界每条消息。守护进程绑定 :6376，作为星型拓扑的中心路由器——所有消息转发、信号广播由它中转，节点之间不直连。
设计取舍：中心化路由使得权限管控、消息审计、节点发现集中在一点，不需要每个节点各自维护。
帧结构详见 传输帧规范
② 消息体层 — KLUDF
自研 key=val;key=val 键值对报文格式。无嵌套符号、纯文本、telnet 可直接调试。SDK 以 KLKVMap 统一 serialize / deserialize 操作。
三种格式按需选用：
| 格式 | 示例 | 适用场景 |
|---|---|---|
| 键值对 | msgContext=Hello;time=2026-07-27 | 日常通信，最轻量 |
| JSON | {"msgContext":"Hello","time":"..."} | 嵌套结构、复杂数据 |
| CLI 字符串 | backup --folder docs | 命令行工具间简单数据交换 |
详见 消息体规范
③ 通信模式层 — 请求-响应 + 发布-订阅
两种模式覆盖本地应用协作的全部场景：
| 模式 | 方向 | 拓扑 | 典型场景 |
|---|---|---|---|
| 请求-响应 | 一问一答，调用方等结果 | 多对一 | 查询数据、执行操作、远程控制 |
| 发布-订阅 | 一对多广播，发送方不关心谁收到 | 一对多 | 事件通知、状态变更、定时广播 |
两种模式可并用——比如消息提醒程序：开放 show 接口让别人调用（请求-响应），同时广播 messageShown 信号通知所有订阅方（发布-订阅）。
④ 能力描述层 — 两份 JSON 清单
用静态文件声明节点能力，替代运行时协商。接口极少动态增减的桌面软件场景，静态声明比轮询更省资源，离线即可完成校验和文档生成。
| 文件 | 声明内容 | 谁读 |
|---|---|---|
FuncList.json | 接口（openSocket）和信号（signal）的参数、返回值 | 工具链、其他开发者 |
plugin_manifest.json / standalone_manifest.json | 节点身份：app_id、名称、版本、启动路径 | KnotHub、节点索引 |
⑤ 工具链层 — 清单驱动的自动化
有了第 ④ 层的两份清单，以下内容全部自动生成，不需要单独维护：
| 工具 | 从清单自动做什么 |
|---|---|
| FLEditor | 可视化编辑清单，表单输入替代手写 JSON |
| API 测试页 | 根据参数类型自动渲染输入框 / 下拉菜单 / 灰显固定值 |
| API 文档 | 生成格式化的 HTML 参数表格和返回值说明 |
| 节点索引 | knotlink.cn/nodes 展示所有已注册节点 |
| 互联配方 | 信号匹配 → 自动触发接口调用，实现跨应用编排 |
清单是单一数据源——填一次，五个工具同时生效。
详见 工具链概览
为什么是 5 层
不再拆分。 TCP 之下不再定义物理层——那是操作系统的事。KLUDF 之上不再拆"参数校验层""鉴权层"——前者是 SDK 内部实现细节，后者规划中、尚未独立成层。
不再合并。 传输和消息体不合并——因为 KLUDF 可以跑在 TCP 之外的载体上（理论上）。通信模式和能力描述不合并——因为同一个 openSocketID 可以承载多个功能条目，模式和声明是正交概念。
五层刚好覆盖从"通了"到"好用"的完整链路，没有为了跟 OSI 对齐而凑数。
与协议规范文档的关系
本页是协议规范的总览入口。四个规范文档各自展开某一层：
| 规范文档 | 对应分层 |
|---|---|
| 传输帧规范 | ① 传输层 — TCP 之上的 8 字节二进制帧结构 |
| 消息体规范 | ② 消息体层 — KLUDF 三种格式的完整字段说明 |
| 功能清单规范 | ③④ — openSocket/signal 的 JSON 结构定义 |
| 自述清单规范 | ④ 能力描述层 — manifest 字段定义、独立式注册表机制 |