把编码智能体塞进一个持久终端会话，是当下不少开发者摸索出的实用技巧——它顺手，却也很快暴露出边界。
发生了什么
Hacker News 上出现一篇题为《Tmux and Claude Code: Sessions, Send-Keys, and the Ceiling》的讨论，主题是把 Anthropic 的命令行编码工具 Claude Code 运行在 tmux 会话中，通过 send-keys 向会话注入输入、在不同窗口间切换任务，并借 tmux 的持久化能力让长任务在断开连接后继续跑。讨论在 HN 上获得了少量但集中的关注（16 points），说明这是一个小圈子内真实存在的实践痛点，而非大众话题。
需要说明的是，公开信息仅限于标题与讨论热度，具体实现细节与作者结论无法核实，以下分析基于该实践方向的通用逻辑。
为什么重要
编码智能体的产品形态正在从「IDE 里的补全」转向「能自己跑很久的进程」。一旦任务时长从秒级拉到分钟甚至小时级，交互界面就成了瓶颈：终端一断、SSH 一掉，上下文和进度就没了。tmux 恰好补上这块——会话可附着、可分离、可多窗口并行，天然适合托管多个长时间运行的智能体实例。
而 send-keys 代表的是另一种思路：不去等官方提供 API 或 SDK，而是把终端当成一个可编程接口，用模拟按键的方式驱动任何 TUI 程序。这是一种典型的「用脚本周转产品缺口」的做法，成本极低，兼容性极好。
标题里的「ceiling」正是关键。这类方案的上限也很明确：按键注入依赖屏幕文本解析来判断状态，输出格式一变、出现交互式确认框、或者需要读取结构化结果时，脚本就会失灵。它本质上是把人类操作录制成机器操作，而不是真正的程序化集成。
影响与看点
对开发者而言，这套组合短期内的价值是确定的：多任务并行、断线续跑、把智能体当作后台作业管理。它不需要等待厂商支持，今天就能用。
但值得关注的是产品侧的反应。当用户普遍用 tmux 加按键注入来「外挂」能力时，说明 CLI 智能体在会话管理、状态查询、非交互模式上存在明显缺口。合理的演进方向是提供结构化的非交互接口与可查询的运行状态，让编排回到程序层面，而不是停留在模拟按键。
我的判断是：tmux 方案会长期作为个人工作流存在，但它更像一块过渡踏板——它证明了「长时运行的编码智能体需要被当作进程来管理」，而这件事最终应该由工具本身提供，而不是由用户的 shell 脚本兜底。
