A. 终端 agent CLI（重度用户推荐）
把 Claude Code、Codex、Aider、Cursor Agent CLI 等当作真实终端进程并行运行。imux 是宿主工作台；agent 是工人。
- 需要时用分屏：实现 / 审查 / 测试 各占一 pane。
- 在 Ghostty 终端里启动 agent，并保持文件与 SCM 可见。
- 在 imux 里看 Git 脏状态与 diff 预览，作为一等证据。
完整使用说明
从第一次启动到日常执行，imux 应该这样用。
imux 是 macOS 上的终端优先 AI 指挥中心——面向 agent 时代的多 agent 执行工作台，不是完整的 VS Code / Cursor IDE 克隆。Claude / Codex 等是工人，imux 是车间。请选一条默认路径，把执行、验证、远程与 Git 证据留在同一个原生工作台里。
快速开始
- 01
安装 imux，作为日常主工作台。
- 02
从本地仓库或已配置 SSH 主机打开工作区——尽量一目标一工作区。
- 03
选定默认路径：终端 agent CLI（多数重度用户）、Agent Chat（应用内 LLM）、或 Mission Control（目标 → 舰队分派 → 验收）。
- 04
用资源管理器、应用内编辑、浏览器、Git 侧栏与 Mission Control 谓词验收——不必离开 imux。
按角色的默认路径
不要一次打开所有表面。每次会话选定一条主路径。imux 是日常主战场——多 agent 执行、文件、SCM、浏览器与远程同处一个指挥中心。
B. Agent Chat（应用内 LLM，适合聚焦任务）
需要流式对话、@file/@symbol、斜杠命令与可审阅 diff 时使用 Agent Chat。
- 先选好仓库工作区，再打开 Agent Chat（Cmd+Shift+L）。
- 优先 /review、/fix、/test 等有边界任务；应用 diff 前先审阅。
- 保留终端可见，用于构建与测试。
C. Mission Control（多 agent 舰队编排）
在目标明确后打开监督器 → Mission Control：设定完成条件，Start Mission 向空闲舰队分发简报，Verify 用可观测谓词验收（不只靠 LLM 自评）。
- 开工前写清一句话目标与完成检查（git clean / shell / HTTP）。
- Start Mission 会入队 mesh 任务，并向空闲 Claude/Codex/终端 peer 注入 mission brief。
- 用舰队列表（Needs input / Working / Ready）处理转折点，不要每个按键都过循环。
D. 从 VS Code / Cursor 迁出
把 imux 当作 Electron IDE 之外的终端优先指挥中心，承接 agent 时代日常工作。把 agent 运行、文件查看、SCM、远程与浏览器验证收进同一个原生工作台。
- 打开你在 VS Code 或 Cursor 里用的同一 git 根目录。
- 把 agent CLI 与长时构建放到 Ghostty 终端，而不是集成终端。
- 用资源管理器、应用内编辑、浏览器与 SCM 走完整闭环——日常不必再开第二套 IDE。
E. 远程运维循环
把每台 SSH 主机当作一等工作区，纪律与本地一致。
- 确认目标与凭据后再连接。
- 远端 shell 就绪后再用远程资源管理器。
- 尽量一台主机一个工作区，避免日志与路径混杂。
1. 先建立工作区，而不是先堆终端
imux 的核心不是孤立终端，而是工作区。一个工作区最好只对应一个明确项目或一个明确远程主机，这样终端、文件、浏览器任务和监督器都基于同一上下文运行。
- 本地工作区应该直接指向你真正要处理的仓库或目录。
- 远程工作区最好一台主机一个，不要把不相关的远端任务混在一起。
- 尽量一项目标对应一个工作区，这样监督器生成的计划更清晰。
2. 把本地和远程资源管理器当作控制平面来用
资源管理器不是装饰，而是你快速确认项目结构、打开文件、核对路径、保持方向感的主要界面。
- 在开始编辑或交给监督器前，先用本地资源管理器读一遍仓库结构。
- 只有在 SSH 会话真正连接并认证完成后，再依赖远程资源管理器执行远端文件操作。
- 需要让终端上下文明确指向某个文件时，直接把路径拖进当前终端对话。
3. 把应用内编辑纳入工作台闭环
imux 可打开与编辑文件，让查看、小修与 agent diff 审阅和终端、Git 留在同一甲板。日常闭环尽量留在 imux。
- 点击文件预览或编辑；大范围多文件重写需要时用 agent CLI。
- 保存后回到终端/agent 线程，不丢工作区上下文。
- 应用 agent diff 或继续监督循环前，先确认实际内容。
4. 把监督器当成执行层，而不是聊天玩具
监督器只有在目标具体、上下文充分、边界明确时才真正高效。它的价值在于压缩歧义、组织下一步，而不是输出一堆空泛话术。
- 给每个工作区先设定一个明确目标，再让监督器接手。
- 先看监督器给出的下一步是否可执行，不要盲目接受模糊计划。
- 监督器适合用来组织推进、追踪进度，以及约束多任务漂移。
5. 让源码状态在执行过程中始终可见
imux 最大的价值之一，是让 Git 状态在执行过程中始终可见，而不是到最后才想起来核对改动。
- 开始编辑前先确认当前分支和工作树状态。
- 利用可见路径和仓库上下文，避免误改到错误目录。
- 在准备发布或交付结果前，再检查一遍当前变更。
6. 用发布优先的习惯来升级 imux
不要把升级当成盲覆盖。imux 控制的是项目上下文、远程访问和模型设置，升级动作本身也应该有工程纪律。
- 先读升级日志，再替换应用构建。
- 升级后重新确认模型设置、SSH 行为和保存的连接偏好。
- 先用一个干净工作区验证新构建，再把全部重要任务迁移过去。
能立刻改善体验的习惯
只要建立几条简单习惯，imux 就会从一个看起来不错的工具，变成真正稳定的指挥中心。
每次会话选定一条默认路径：终端 agent CLI、Agent Chat 或监督器——不要三者同时主线。
尽量保持一个工作区只对应一个仓库或一台远程主机。
把工作区目标先写清楚，再交给监督器推进。
把完整闭环留在 imux：agent、文件、测试、浏览器、远程与 Git 证据同一表面。
把精确文件路径拖进线程，而不是用模糊描述代替。
尽早看 Git 状态，不要到最后才检查。
非平凡生成变更后用应用内文件视图做确认。
每次升级后至少验证一个本地路径和一个远程路径。
怎样给 imux 下达任务，才能在 2 到 3 轮内进入执行
大多数启动缓慢的问题，并不是功能不够，而是目标太模糊。一个短而具体的任务简报，通常就足够让 imux 快速开工。
先说清楚具体仓库、目录或 SSH 目标。
一次只讲当前最重要的一个结果，不要把多个无关目标塞在一起。
如果你已经知道关键文件、命令或 URL，就直接指出来。
用一句可衡量的话说明什么叫完成。
下一轮只需要收紧范围或优先级，不需要把全部需求重新讲一遍。
常见问题与恢复方式
imux 出现卡顿、混乱或不可靠时，通常原因都在操作方式本身，而不是神秘错误。优先检查下面这些点。
SSH 连接像是卡住了
大多数远程问题都来自认证未完成、SSH 配置不匹配，或者在连接尚未稳定前就开始浏览远程文件。
- 重新确认 SSH config 里的目标并干净重连。
- 等终端明确出现远端 shell 状态后再使用远程资源管理器。
- 如果仍然异常，先用普通 SSH 会话测试该目标。
工作区显得很乱、不聚焦
这通常意味着工作区目标过大，或者多个不相关路径与任务堆在了同一个操作面里。
- 把不相关任务拆成多个工作区。
- 把当前目标压缩成一个明确结果。
- 关闭不再参与当前决策链的文件和面板。
监督器给出的下一步太空泛
这往往意味着它缺少明确目标、最新文件证据，或者没有得到清晰的完成标准。
- 用一句话重述目标，并写明什么算完成。
- 继续前先打开最相关的文件。
- 把它重新指向当前仓库状态，而不是依赖旧对话记忆。
安全升级检查表
从 imux 官方网站下载最新 DMG。
先正常退出当前应用，避免中途打断写入或活动会话。
安装新构建后重新打开 imux，并在继续重要工作前核对 LLM 设置与 SSH 连接。
如果资源管理器、监督器、文件编辑或路由行为有变化，先读升级日志再继续。