tmux-orchestration

tmux-orchestration

功能

• 读取另一个窗格——总结 Agent 的进展、获取错误信息、检查长时间运行的进程是否已完成。
• 操控另一个 Agent——发送交接提示词、提出后续问题、回答确认请求，或在任务中途调整方向。
• 启动新任务——打开另一个窗口或会话，启动一个已预先输入任务的全新 Agent、REPL、监视器或 shell。
• 协调长时间运行的任务——将输出写入日志、在后台监视，或在多个工作树中执行同一命令。
• 操控交互式 TUI——通过发送按键并读取渲染的界面来操作 lazygit、k9s、htop、编辑器等。

适用场景

每当用户的请求涉及另一个窗格时。常见触发情形：

• “读取 / 检查 / 看看 / 总结 [窗格|窗口|会话] 中发生了什么。”
• “把这条消息发给 X 中的 Agent。”/“告诉另一个 Claude……”
• “回答那个窗格中的提示。”/“在那里输入 ‘y’。”
• “打开一个新窗口，启动 Claude 来处理……”
• “监视构建 / 部署 / 测试，完成后告诉我。”
• “在我所有工作树的 shell 中运行相同的命令。”

不适用于当前窗格中常规的 shell 操作。

窗格 ID 是稳定的标识

每个窗格都有一个类似 %69（#{pane_id}）的 ID，在窗格的整个生命周期内保持不变；而 session:window.pane 索引会因窗口重新编号或添加窗格而变化。识别出窗格后，应使用其 ID 作为目标。

用户可以直接提供 ID：prefix + i 会将当前窗格的 ID 复制到剪贴板。当用户粘贴 %69 并说“读取这个”或“Agent 在这里”时，目标明确无误——跳过 list-panes 猜测，直接捕获该窗格。（写入前仍需确认该 ID 不是你自己的窗格——见下文。）

在 Agent 之间转达消息时，在发送的消息中包含发送方的窗格 ID（“……然后告诉 %24 中的 Agent 你已完成；你的窗格是 %69”），以便接收方能回复到正确位置。

安全

危险之处不在 tmux 命令本身，而在于判断。

操作前确认目标

用户的说法（“另一个”、“apps 工作树”、“那个 Codex”）很少明确无误。列出所有窗格及足够的元数据，以便识别它们——会话、窗口、窗格、当前命令、工作目录。如果有两个或更多候选目标符合条件，请指出并让用户选择。不要猜测。在执行任何实质性操作（发送输入、关闭、启动）之前，先向用户确认目标。

绝不写入当前窗格

如果目标窗格是 Agent 自己运行的窗格，后果可能很严重——按键会输入到 Agent 自己的界面中，取消任务或发送乱码。务必确认哪个窗格是“自己”，并排除它。

先读取，再写入

先捕获并检查窗格，再发送输入。原因有二：

• 这样可以知道该窗格正在等待什么。 shell 提示符接受命令；Agent 的输入框接受文本；确认提示则需要 y/n。发送格式错误的输入会造成实际损害——例如，将多行提示粘贴到 bash 中，会尝试把每一行作为命令执行。
• 这样可以发现目标是否识别错误。 原以为是 Codex 会话，却看到了某人主目录下的 bash 提示符？立即停止。

非简单输入使用缓冲区粘贴

单个按键、简短回答和单行命令可以直接发送。任何多行内容，或包含反引号、引号、美元符号及其他 shell 特殊字符的内容，都应先写入 tmux 缓冲区再粘贴。直接用 send-keys 发送复杂文本会因 shell 引号处理而变形。

粘贴不会提交内容。发送 Enter 是单独且明确的一步——值得暂停确认，因为这是不可逆操作的临界点。

发送实质性内容前先预览

对于任何超出简单回答的内容（交接提示词、多段指令、破坏性命令），先向用户展示确切文本，并在按下 Enter 前取得同意。快速输入 y / n 或使用箭头键等交互无需预览。

发送后验证

再次捕获目标窗格。确认接收的 Agent 已接受输入并开始工作。如果界面上没有任何明显变化，就说明出了问题——目标选错、漏按了 Enter，或者 Agent 正忙而丢弃了粘贴内容。

启动 Agent

优先采用分离式创建，以便当前窗格继续保持控制权。等新 Agent 的界面就绪后，再发送开场提示词来初始化它——先粘贴到缓冲区，再按 Enter。

避免留下孤立窗口。如果出了问题（启动了错误的命令、选错了 cwd），请先关闭窗口再重试。

后台监视

对于在另一个窗格中运行的长时间进程：

• 按需轮询。 当用户询问“完成了吗？”时，捕获窗格并汇报。
• 镜像到文件。 在后台将窗格的实时输出写入日志文件，然后对文件执行 tail 或 grep。当滚动缓冲区可能截断内容，或用户希望暂时离开时，这种方式很有用。

完成后停止镜像——让管道继续连接到不活跃的窗格很不妥。

广播

同时向多个窗格发送相同输入很有用（在多个工作树 shell 中运行命令、重启多个服务），但也很危险（一个错字会执行 N 次）。应将其视为破坏性操作：确认窗格集合，确认输入，然后立即关闭同步模式。切勿让广播模式跨轮次保持开启。

良好示例

“apps 工作树中的 Agent 在做什么？”

1. 列出窗格，找出在 apps 工作树中运行 Agent 的那个窗格。
2. 捕获其可见内容（如果有用，也可包含一部分滚动缓冲区）。
3. 阅读内容并理解其含义——正在进行什么任务、刚完成了什么、正在等待什么——而不只是照读屏幕内容。
4. 汇报总结，并指出任何值得注意的情况（错误、待处理的提示、长时间闲置）。

“向那个窗格发送交接信息。”

1. 按名称确认目标。
2. 起草交接提示词——简洁、完整，并指向权威信息来源（计划文档、分支、规范），而不是重复陈述其中的内容。
3. 将提示词展示给用户以供审批。
4. 通过缓冲区粘贴发送，按 Enter，然后捕获窗格以确认已收到。

应避免的失败模式

• 用户说“另一个”时自行猜测，导致向错误的窗格发送输入。
• 将多行提示词粘贴到 shell 而不是 Agent 界面中，导致每一行都被执行。
• 忘记按 Enter，导致提示词留在输入框中，让用户以为 Agent 卡住了。
• 将破坏性命令隐藏在广播操作中，直到它在五个窗格中运行后才意识到。
• 忘记关闭 synchronize-panes，导致下一次普通按键意外广播。
• 在错误的 cwd 或错误的会话中启动新窗口，然后留下孤立窗口不管。

跨窗格操作出错通常无法挽回——接收的 Agent 已经根据收到的内容采取了行动。如有疑问，请停下来询问。