nana：Windows上的多AI编程代理终端管理器

为什么Windows需要专属的AI代理终端

当Claude Code、Codex、OpenCode等AI编程代理逐渐成为开发者的日常工具，一个现实问题浮现出来：如何同时管理多个代理，让它们各自在独立环境中工作，而不互相干扰？在macOS和Linux上，tmux等终端复用器早已是标配，但Windows生态一直缺乏原生的解决方案。

nana正是瞄准这一空白的产品。它被描述为“Windows原生的终端复用器”，核心定位是让开发者在一个界面里并排运行多个AI编程代理，每个代理绑定独立的git worktree。这个设计思路直接回应了多代理协作中的隔离需求——不同的代理修改不同分支，互不污染工作区。

核心功能拆解：状态感知与工作流整合

nana的功能设计围绕三个关键词展开：并行、可见、持久。

多代理并行与git worktree隔离

nana允许同时运行Claude Code、Codex、OpenCode等多个代理，每个代理拥有自己的git worktree。这意味着代理A在feature分支上的改动不会影响代理B在bugfix分支上的工作。对于需要对比不同代理输出质量、或让多个代理分头处理不同任务的开发者来说，这种隔离是刚需而非锦上添花。

git worktree 是 Git 2.5 引入的特性，允许从同一个仓库中检出多个工作树（working tree），每个工作树挂载不同的分支，且共享底层的对象数据库。与传统的 git clone 多次复制仓库相比，worktree 几乎不产生额外磁盘开销，切换分支时也无需 stash 或提交暂存改动。对于多代理场景，这意味着代理 A 和代理 B 可以同时操作同一仓库的不同分支，各自的文件系统视图相互隔离，但最终的提交仍汇聚到同一份 Git 历史中，便于后续合并与对比。

状态面板：谁在忙、谁在等、谁完成了

多代理场景下最大的痛点之一是“黑箱感”——你不知道某个代理是正在思考、卡在权限确认，还是已经完成任务在等你审阅。nana提供了状态视图，将代理归类为“工作中”“等待中”“已完成”。这个看似简单的功能，实际上把开发者从频繁切换窗口的焦虑中解放出来，只需扫一眼面板就能决定下一步操作顺序。

内置diff审阅

代理完成代码修改后，开发者需要审查变更。nana将diff审阅集成在终端界面内，省去了切换到IDE或git客户端的步骤。虽然素材未披露diff视图的具体交互细节，但从产品定位看，它显然试图把“运行代理—等待结果—审查代码”的闭环收拢在一个窗口里。

关闭应用后代理继续运行

这是nana区别于普通终端标签页的关键能力。关闭应用后代理进程仍在后台运行，重新打开时状态和输出得以保留。对于动辄运行数分钟甚至更久的AI编程任务，这个特性意味着开发者不必为了等结果而保持窗口常开，可以合上笔记本去开会，回来再查看进度。

Windows 下实现终端进程后台持久化，通常依赖 ConPTY（Console Pseudo Terminal）。这是 Windows 10 1809 引入的伪终端 API，取代了此前难以编程控制的传统控制台模型，为终端复用器、IDE 内置终端等工具提供了与 Unix pty 类似的抽象。nana 若要保证关闭界面后代理进程不中断，需要将代理进程与 UI 进程解耦，由常驻的后台服务托管 ConPTY 会话，并在重连时回放缓冲区内容。这一机制是否健壮，直接决定了“合上笔记本再回来”的体验是否可靠。

产品定位分析：谁适合用nana

从功能组合来看，nana的目标用户不是偶尔用AI补全代码的轻度用户，而是已经将AI代理纳入日常工作流的重度开发者。具体来说，以下几类人群会直接受益：

• 多代理对比型用户：同时订阅了Claude Code和Codex，想比较同一任务下不同代理的输出质量，需要并排运行、独立隔离的环境。
• 任务分流型用户：把重构、测试编写、文档生成分别交给不同代理，需要清晰的状态总览来安排审阅优先级。
• Windows原生环境用户：不愿为了终端复用能力而切换到WSL或依赖第三方模拟层，希望获得与Windows深度整合的体验。

说个细节，nana目前处于免费beta阶段，由开发者Gustavo Ramirez打造。在Product Hunt上获得70票、排名第17位，说明它切中了一部分开发者的真实需求，但声量尚属早期。评论区仅2条讨论，也侧面反映产品仍处于小众尝鲜阶段。

终端复用器（terminal multiplexer）是一类在单个终端窗口内管理多个会话的工具，代表产品是 tmux 和 GNU Screen。其核心能力包括：会话分离与重连（detach/attach）、窗口与面板分屏、进程在断开连接后继续运行。在 Unix 生态中，这几乎是远程开发和长时间任务的标配。Windows 长期缺乏一等公民级别的同类工具，用户往往借助 WSL 内的 tmux 或第三方方案曲线实现。nana 的“Windows 原生”定位，正是要填补这一平台级空缺。

潜在局限与待验证之处

现有信息并未披露nana的技术架构细节，比如它如何处理Windows下的伪终端（ConPTY）兼容性、是否支持Windows Terminal的现有配置导入、多代理并发时的资源占用表现如何。这些对实际体验影响很大，但需要上手试用才能判断。

另一个需要观察的点是代理生态的覆盖广度。目前明确提到的Claude Code、Codex、OpenCode都是命令行形态的代理工具，nana的复用器定位天然适配这类工具。但如果未来AI编程代理更多转向IDE插件或GUI形态，纯终端管理器的价值空间可能被压缩。

小结：一个务实的Windows补位产品

nana没有试图重新发明AI编程代理，而是解决代理变多之后的管理摩擦。git worktree隔离、状态面板、内置diff、后台持久运行——四个特性拼在一起，构成了一套针对Windows多代理工作流的完整补丁。免费beta阶段值得Windows平台的AI编程重度用户关注和试用，尤其是那些已经在用两个以上命令行代理、并且厌倦了手工管理窗口和分支的开发者。

产品能否从beta走向成熟，取决于它能否在代理兼容性、终端体验细节和Windows特有问题处理上交出合格答卷。就目前释放的信号而言，方向是正确的。