机制 vs 语义：边界在哪

如果你正在做自己的 agent 框架、想把 conmux 接进来，这一页是最该先读的一页。它讲的不是某个 API，而是一条刻意划死的边界——理解它，你就明白为什么 conmux 值得当地基，以及哪些活它故意不替你干。

一句话

conmux 只知道 pane（面板）、进程和字节。它不知道「agent」是什么。

你在别处听到的那些概念——哪个 agent 在等你、谁该排到注意力队列前面、几个 agent 怎么协作、灵动岛上该亮哪盏灯——conmux 一个都不认识。对它来说，一个 pane 里跑的是 Claude Code、是 cargo build、还是一个普通的 PowerShell，没有任何区别：都是一棵被监管的进程树，往外吐字节、偶尔要你喂输入。

这不是还没做，是故意不做。

为什么故意划这条线

一个东西想当「地基」而不是「框架」，关键就在这里。

框架替你把语义定死：它假设你在做 agent、假设 agent 该怎么排队、该怎么互相说话——你顺着它的假设走很省事，可一旦你的想法和它不一样，就得跟它对着干。

地基只提供机制，把语义留白：它给你稳的地面（进程不跑飞、输入有人审、断线能接回来），至于地上盖什么——一个 agent 工作台、一个 CI 面板、一个多会话运维工具——它不替你决定，也就不会挡你的路。

conmux 选的是后者。它把「一个 CLI 会话怎么被可靠地托管、监管、断连重连」这件又脏又难的事做到底，然后在语义开始的地方停手。「这个 pane 是个正在等权限的 agent」这句话，conmux 说不出来——因为「agent」「等权限」都是上层的词，得由消费方自己定义。

这也是为什么 conmux 的公开 API 里，你翻遍了也找不到一个带 Agent 的类型。对外能看到的就是 PaneHost、协议消息（MuxRequest / MuxReply / …）、事件出口（PaneOutput / PaneExited）、注入钩子、主题——全是「面板 / 进程 / 字节」这一层的词汇。（要落到具体类型名，见 控制面。）

那语义谁来做——你

边界的另一半，就是留给你的空间。「agent 是什么、几个 agent 怎么协作」这层语义，conmux 一概不碰，全交给上层。 Conflux 就是这样一个上层：它在 conmux 提供的 pane / 事件 / 注入之上，自己定义了「这个 pane 是一个 agent」「这个 agent 弹了权限请求、该提醒用户」「把用户的一条消息广播给这几个 agent」这些概念。

换成你，边界的两侧大致这么分工：

conmux 负责（机制）你负责（语义）
起进程、监管整棵进程树、进程死了给你个准确退出码判断「这个 pane 代表一个 agent / 一次构建 / 一个服务」
把 pane 吐的字节按序交给你（PaneOutput）从字节里读出「它在等我输入」「它报错了」「它跑完了」
提供唯一、可审计的输入通道，把你要喂的字节送进 PTY决定「什么时候、喂什么、要不要先过一道策略」
断线重连时把屏幕原样接回来决定「界面长什么样、谁排在注意力队列前面」

一句话：conmux 保证下面那层地面是平的、稳的、看得住的；地上盖什么由你说了算。

依赖是单向的（也请你保持单向）

这条边界在代码里是硬约束，不是口头约定：依赖方向永远是 你的框架 → conmux，反过来不成立。conmux 不依赖任何上层——不依赖 Tauri，不感知 UI，更不认识任何具体框架的业务概念。

对你的好处很直接：

  • 你换掉整个上层（换 UI、换交互模型、甚至换一门语言来驱动它），conmux 那层地面不用动。
  • conmux 出新版本时，它承诺稳定的只是那个小而明确的公开面（协议类型 + 几个核心 trait），其余内部实现明确标了「不稳定、可能随时变」。你贴着公开面写，升级就不容易被内部重构波及。这条原则 conmux 自己叫「库即产品」——公开面小、稳，好过大而全。

记住这一条就够

conmux 给你平、稳、看得住的机制；「这是不是一个 agent、该怎么协作」的语义，是你的活，也是你的自由。

这条边界不是缺功能，是设计上的克制——正因为它在语义开始的地方停手，你才有地方盖自己的楼。

接下来