feat: C控制程序对接KCP

AGENT.md

@@ -0,0 +1,54 @@
+# 通信场景说明
+
+## 系统拓扑
+- 系统中有 `A/B/C/D` 四个终端。
+- `A` 与 `C` 在同一侧，`B` 与 `D` 在同一侧。
+- 实际运行时不是一条端到端 KCP，而是两条独立 KCP 链路：
+  - `B <-> D`
+  - `D <-> A`
+- `C` 只负责 UDP 端口转发。
+- 整体目标是让 `A` 与 `B` 双向通信：
+  - `A -> B` 发送控制命令
+  - `B -> A` 发送视频和其他反馈数据
+
+## 网络情况
+- 主要瓶颈在 `B` 侧 5G 链路，`A` 侧是有线网络，不是主要约束。
+- `B <-> D` 的时延抖动较大：
+  - 常见约 `15-60 ms`
+  - 最差约 `80-90 ms`
+- 带宽是明显非对称的：
+  - `B -> D` 约 `8 Mbps`，偏低且不稳定
+  - `D -> B` 约 `27-50 Mbps`，更高但也有波动
+- 工程含义：
+  - 控制流必须优先保障
+  - 视频流必须限速并具备自适应能力
+  - 不能默认把所有流合成一个共享传输就一定更优
+
+## 三个项目的角色
+- `OmniSocketGo`
+  - 底层传输项目
+  - 使用 C 编写
+  - 提供 OmniSocket/KCP 传输能力，以及视频发送等原生传输程序
+- `robot-command-center`
+  - A 侧上层应用
+  - 主要负责接收视频帧，并提供监控/展示能力
+  - 当前通过本机 `A-side OmniDaemon` 使用传输能力
+- `tienkung-szu`
+  - 上层控制项目
+  - 同时包含 A 侧控制发送和 B 侧控制执行逻辑
+  - A 侧典型入口是键盘/Xbox sender
+  - B 侧典型入口是 `rl_control_node.py` / `rl_control_node_sim.py`，负责接收控制并驱动机器人行为
+
+## 当前架构方向
+- `A` 侧通过 `A-side OmniDaemon` 统一管理本机的控制发送和视频接收。
+- `B` 侧通过 `B-side OmniDaemon` 统一管理本机的控制接收和视频发送。
+- 核心原则：
+  - 控制流与视频流逻辑分离
+  - 每台主机通过本地 daemon 统一持有传输会话
+  - 后续围绕真实网络瓶颈做 telemetry、调度和速率自适应
+
+## 代码原则
+- 一定要精简，不能写过于复杂和冗余的代码，因为必须确保各个环节可控，在低延迟的要求下，需要细化各个环节的消耗
+
+## SSH原则
+- 如果你需要SSH到某个远程端执行操作，一定要确保不做删除文件操作，确保留有记录