2.1 背景与场景

一台机器一张名单

先说清楚：没有跨机通道的时候，人是怎么干活的。

第1课的 send（第1课 单机通信）之所以能按名字找到人，是因为名字登记在本机的会话注册表里——crosschat status 看到的就是这张名单。名单是本机的：A 机器上的 beta2 与 B 机器上的 beta2 互不相干，A 机器的 status 也永远看不见 B 机器的会话。

于是你就是邮差：在两个终端之间人工复制粘贴。A 机器上的 agent 说了一段话，你复制，切窗口，粘贴到 B 机器；对面回了话，再复制回来。消息走得通，但每一跳都是你的手，而且两个 agent 自始至终不知道对面是谁——名字、轮次、上下文，全都断在你这里。

消息出机器需要什么

crosschat 对跨机的答案克制到只剩一个参数：--via ssh:<对端>。

crosschat send --via ssh:yangwsl --to beta2 --body "……"

对 crosschat 来说，跨机 = 单机全部用法 + 一个 --via。命令到达对端后，以对端的完整本机权限执行——等价于有人在那台机器上敲了同一条 send：名字在目标机上解析，投递走对端自己的管道，忙时排队、异常暂存用的也是对端自己的机制。

crosschat 不新建任何连接层。网络、认证、加密全部复用 ssh；地址、端口、用户、密钥这些连接参数，住在每台机器自己的 ~/.ssh/config 里——这是运维世界三十年的存量标准。2.4 SSH 部署与配置要做的不是学新配置，而是把这份存量配好。

┌ crosschat 层（零自有配置）────────────────────────────┐
│  --via 解析 · origin 身份 · ref 对话引用 · 回执渲染    │
└────────────────────┬────────────────────────────────┘
                     │ 借道（不重造）
                     ▼
┌ ssh 层（连接的全部参数住这里）──────────────────────┐
│  ~/.ssh/config 别名 · 密钥 · known_hosts · 反向隧道  │
└─────────────────────────────────────────────────────┘
  2.4 配的每一样东西都在下面这层；上面这层一个配置文件都没有

打个比方：--via ssh:yangwsl 像是“把命令寄到 yangwsl 这台机器，让那里的 crosschat 干活“。类比到此为止——正文并不在命令行里，也不经过对端 shell 的解释（2.6 通信机制会讲为什么这条设计挡掉了一整类事故）。

双向可达与单向 NAT

ssh 形态有一个默认前提：两台机器彼此都能 ssh 到对方（同局域网、VPN、或双方都有公网地址）。按你的网络对号入座：

双向可达                              单向 NAT（本机在 NAT 后）
win ────► yangwsl                     win ────► 云端 Linux
win ◄──── yangwsl                     win ✗───── （云端连不回）
两台互装密钥，配完即用                回程由一条常驻反向隧道背回来

单向不是残缺形态：出站方向（你→对端）与双向完全一样，只有回程改走隧道。隧道是 ssh 自己的能力——crosschat 代码里没有一行隧道逻辑，它只认 ~/.ssh/config 里的别名（单向 NAT 差量会把隧道伪装成一个普通别名，crosschat 毫无感知）。