用Windows悬浮条管理OpenCode会话

同时跑多个 OpenCode 会话，麻烦的不只是窗口多，而是你很难随时知道：哪个还在执行，哪个等着批准命令，哪个已经结束。作者做了一个 Windows 悬浮应用 OpenCode Notch，把这些状态集中到屏幕顶部，需要你处理时再展开。

它的价值在于减少来回切终端的打断。不过，对前端开发者更有参考意义的，是作者修复的一次布局故障：当 Electron 窗口跟着内容调整大小，常见的「响应式」写法反而可能把面板挤成一条细缝。

多个 Agent 会话，怎样才能少切几次窗口

OpenCode Notch 借用了 macOS 刘海区域的外观。收起时，它是屏幕顶部的一个胶囊，每个会话对应一个状态点，区分执行中、等待批准、已完成和出错。

鼠标悬停后，面板会展示会话标题、项目目录、耗时、正在执行的具体工具调用，以及上下文使用量。你不必为了确认 Agent 是否还在工作，反复用 Alt+Tab 找终端。

作者还把一部分交互放进了悬浮面板：权限请求可以选择批准一次、始终批准或拒绝；Agent 表单会渲染成实际输入控件；当前查看的会话支持快速回复和中断。

会话中心则负责项目标签、分组、搜索、重命名、归档与恢复，也能通过「open in TUI」回到终端界面。偏好键盘操作的用户，可以用 Ctrl/Cmd+K 打开命令面板。

它想解决的是「什么时候需要我介入」，而不只是把终端内容换个地方显示。

为什么用了 vw 和 vh，面板反而打不开

这个应用是独立的 Electron 程序，通过本地 OpenCode server 通信，方式与 TUI 相同。按作者的描述，它不需要插件、hooks 或 API keys，可以连接已经运行的 OpenCode。

布局问题出在 0.3.0。作者希望展开面板能适应可用空间，于是写了下面这段 CSS：

width: min(440px, calc(100vw - 18px));
max-height: min(640px, calc(100vh - 18px));

要留意的是 100vw 和 100vh：这里的视口属于 Electron 窗口，并不是整块屏幕。

OpenCode Notch 会测量面板内容，再调整原生窗口的大小。收起时，窗口只有约 226×38 像素。以这个窗口计算，上述宽度限制约为 208 像素，高度限制约为 20 像素。鼠标悬停后，本该展开的面板被裁成了一条窄带。

问题形成了循环：内容决定窗口大小，窗口大小又通过视口单位限制内容。原本用于适配空间的规则，成了阻止内容展开的约束。

0.3.1 的修复很直接，改成明确的尺寸：

width: 440px;
max-height: 640px;

要留意的是，宽度不再依赖 vw，最大高度也不再依赖 vh，从而切断了这条尺寸依赖链。作者由此提出经验判断：如果窗口尺寸由自身内容决定，在里面使用视口单位通常容易出问题。

我的判断

我认可把状态展示和必要操作集中起来的方向。对经常并行运行多个 Agent 的开发者来说，知道「谁在等我」比持续盯着所有执行过程更有用。相比只显示通知的做法，直接回复、处理表单和批准请求，也能减少后续切换。

但收益目前还是作者的使用体验。原文没有给出任务切换次数、响应耗时或与其他界面的对照数据；作者尤其希望获得同时打开十个及以上会话时，跨项目切换的反馈，因此不能据此认定大量会话下已经足够好用。

布局修复也有适用范围。固定 440px 宽度和 640px 最大高度，解决了这次尺寸循环，但原文没说明小屏幕、不同缩放比例或屏幕边缘空间不足时怎样处理。相比固定尺寸，依据外部可用区域限制窗口也是一种思路，只是原文没有实现或比较。

另外，「不需要 API keys」描述的是这个应用连接本地 OpenCode 的方式，不代表 OpenCode 使用模型时也不需要凭据。

能拿来做什么

• 开发 Electron 悬浮窗或托盘面板时，先确认尺寸由谁决定。如果原生窗口跟随内容缩放，就检查内部的 vw、vh 是否反过来限制了内容。
• 为 AI 编程工具设计状态界面时，可以参考「收起看状态、展开看详情、需要时直接操作」的层次，并明确展示正在执行的工具调用。
• 如果你使用 Windows 10 或 11，并行运行多个 OpenCode 会话，可以把它作为候选工具。作者提供安装包和便携 zip，采用 MIT 许可，按用户安装且无需管理员提示；配置保存在 %APPDATA%\OpenCode Notch\notch.json。