tty7：把持久会话、SSH 与编码 agent 放进 Rust 终端工作台
纯 Rust 的终端工作台：shell、持久会话、SSH、编码代理。 GPU 在 Alacritty 的 Zed gpui、VT 核心上进行渲染。
秒懂
- 它是什么？
- 纯 Rust 终端工作台，使用 Zed gpui 做 GPU 渲染、沿用 Alacritty VT 核心，并提供持久会话、远程工作和 agent 入口。
- 适合谁用？
- 适合偏好 Rust 原生终端，并需要持久 shell、SSH 和支持编码 agent 的开发者。不适合把 README 的同机基准直接当作你的设备性能结论，或依赖文档未说明的平台支持。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月19日）和我们的分析，不构成法律意见。
开源项目深度解析
tty7 把终端当作工作台
README 将 tty7 定义为纯 Rust terminal workbench，目标包括 shell、持久会话、SSH 和 coding agents。渲染使用 Zed 的 gpui，VT 核心来自 Alacritty。它的重点不是另一个只负责显示字符的窗口，而是把远程工作和 agent 会话放进可持续的终端环境。
项目仍应按工作台来评估：会话如何保存，窗口如何恢复，网络断开后状态如何处理，都比首页功能词更关键。材料没有提供完整平台兼容矩阵，因此不要从“纯 Rust”推出所有系统都能直接运行。
持久会话减少重复启动
README 的 Why 部分强调，退出或重启后 shell 和受支持的 agent session 仍会继续运行，不需要 tmux。这个承诺针对的是会话生命周期，而非普通终端历史。若实现可靠，用户可以把终端窗口当作查看入口，进程本身独立于窗口存在。
测试时启动一个会持续输出的命令，退出 tty7 后重新打开，再检查进程、当前目录和输出是否保留。再模拟 SSH 断开，确认本地界面展示的是断开、重连还是新的会话。仓库说明没有给出异常恢复的完整策略。
编辑器式输入覆盖日常操作
README 列出历史建议、解释型 tab 补全、语法高亮、多行编辑、点击定位光标和 `Ctrl-R` 模糊历史。窗口提供 tabs、splits、命令面板和查找入口。它借用了编辑器的交互模型，让复杂命令和多任务切换不必完全依赖 shell 自身。
键位和终端兼容是实际门槛。应逐项检查中文输入、长命令、多行粘贴、全屏 TUI 与鼠标定位，记录不同 shell 的行为。文档中的功能列表不能证明每个终端程序都已兼容。
GPU 渲染与 Alacritty 核心各司其职
tty7 使用 gpui 处理 GPU 界面渲染，以 Alacritty 的 VT 核心解释终端控制序列。这样的组合把画面呈现与终端语义分开，理论上便于沿用成熟的 VT 行为并增加工作台界面。
README 给出的性能数据来自同一台 Apple M1 Pro、macOS 26.3.1 和 155×40 网格的五次平均，包含 plaintext I/O、DOOM-fire 和冷启动内存。它是项目自报的特定条件结果，不能替代你的显卡、字体和程序组合测试。
远程工作和 agent 让权限更重要
SSH 与编码 agent 是 tty7 的一等使用场景。终端工作台如果同时承载本地 shell、远程 shell 和自动化 agent，用户必须能辨认当前会话、主机和工作目录。README 指向 `docs/features.md` 作为终端及键位参考，但没有在材料中展开所有权限和凭据处理细节。
首次接入远程主机时应使用非生产账户，检查 SSH 密钥调用、断线恢复和 agent 的命令范围。不要仅凭界面把 agent 当作受限进程；真实权限仍由 shell、主机和项目配置决定。
基准数据应连同脚本一起复核
README 的表格声称 tty7 在 plaintext I/O、DOOM-fire 和冷启动内存等项目上与 Alacritty、Ghostty、Kitty 对比，并提供 `scripts/bench/` 的复现入口。基准是快照，项目元数据显示默认分支有 582 个 star、42 个 fork 和 24 个开放 issue，这些都不能推出稳定性。
项目采用 Apache-2.0。它适合愿意接受快速变化、并能自行构建和验证的终端用户。采用前应找到准确构建命令，复现持久会话和基准脚本，重点观察输入延迟、重启后进程状态和异常退出后的数据完整性。
l0ng-ai-tty7-deep-analysis 验收路径
针对 l0ng-ai-tty7-deep-analysis，验收从 README 明确写出的输入和输出开始。先固定版本和运行环境，保留不含凭据的命令输出，再按项目类型观察协议握手、终端会话、请求取消、文件变化或模型字段。每个用例设置成功结果和故意错误，区分文档承诺、实现行为与环境问题。输出含时间、金额、版本、路径或字段时，单独保存原始值并比较格式、顺序和缺失值。网络功能记录错误和退出码，文件功能使用副本目录，账户功能采用最低权限。材料没有独立基准的地方，只报告实测观察。
l0ng-ai-tty7-deep-analysis 边界清单
README 未说明的默认值、兼容矩阵、数据保留、限流、性能和安全保证，都作为 l0ng-ai-tty7-deep-analysis 的边界记录。升级时固定回归样本，重查主要命令、失败日志和许可证义务。依赖本地文件或账户时先用可恢复副本；依赖编译器、模型或网络对端时先用仓库示例建立基线。具体结果支持判断后，再扩大到真实数据。
l0ng-ai-tty7-deep-analysis 的最小验收记录应包含具体版本、输入样本、命令和输出摘要。若是 Synthadoc，要检查生成 Markdown 的 frontmatter、引用行号、contradicted 状态和 candidates 目录；若是 predikit，要检查 Pydantic 字段名、OpenAI schema、predict_proba 阈值和 `ainvoke` 异常；若是 shuorenhua，要逐项比对数字、修饰对象、否定关系和责任归属；若是 Note Companion，要检查音频转录、YouTube 链接、vault 文件变化和桌面端限制；若是 openJiuwen，要检查异步流、状态保存、工作流跳转和工具错误；若是 tossinvest-cli，要检查账户权限、报价字段、JSON 或 CSV 输出、dry-run 和订单错误；若是 Pion DTLS，要检查证书、PSK、ALPN、会话恢复和 OpenSSL `-dtls1_2`；若是 tty7，要检查 shell 持久化、SSH 断线、分屏和键位；若是 xior，要检查 fetch、拦截器、timeout、取消、嵌套查询、缓存和 FormData；若是 LuminaEngine，要检查 mesh shader、Setup.bat、BuildConfiguration.json、编辑器场景和 C# 热重载。每项都保存成功与失败两种结果，避免把单次运行写成普遍保证。
l0ng-ai-tty7-deep-analysis 的协议或运行记录还应标注时间、系统版本和依赖版本。将一次成功结果与一次输入错误、网络中断或资源缺失结果并列保存，才能看出程序是否正确报告边界。若输出有自动生成的内容，保留原始输出和人工检查意见；若输出涉及远程服务，记录对端版本和响应状态。这样形成的记录只对当前版本和环境负责，也能在下一次升级时准确定位变化。
编辑结论
适合偏好 Rust 原生终端，并需要持久 shell、SSH 和支持编码 agent 的开发者。不适合把 README 的同机基准直接当作你的设备性能结论，或依赖文档未说明的平台支持。先找到仓库实际构建入口，启动一个 shell、创建分屏并重启程序，检查会话恢复、键位和 GPU 渲染是否符合工作流。
社区笔记