终端工作台最难排查的一类问题，不是明显崩溃，而是 Agent 仍在运行，界面却突然空白，状态还显示为“已停止”。Termexo v0.8.7 将重点放在这类终端可靠性问题上：换用 avt 解析器，并修复宽字符、窗口缩窄以及重绘阻塞相关故障。
Termexo 是一个 MIT 开源的 Windows 工作台，用于集中使用 Claude Code、Codex 和 OpenCode。这个版本不以新增工作台功能为主，而是改善长时间运行、多次刷新和调整窗口尺寸时的终端表现。需要注意的是，官网中展示的工作台截图是 v0.8.0 的界面示意，并不代表 v0.8.7 新增了截图中的功能。
为什么终端会“看起来停止了”
终端输出并不是普通文本流。Agent 可能同时产生普通字符、ANSI 控制序列、光标移动、清行指令和重绘请求。中文、日文、全角符号等宽字符还会占用两个终端单元格；当窗口变窄时，原有行布局也需要重新计算。
如果解析器对这些状态的处理不完整，可能出现几种很容易误判的结果：
- 输出区域变成空白，但后台进程仍然在工作。
- 状态栏根据错误的终端状态显示“已停止”。
- 窗口缩窄后出现错位、残留字符或重复绘制。
- 大量刷新请求阻塞界面线程，让用户感觉 Agent 没有响应。
因此，这次切换到 avt 的价值不只是“换了一个依赖”。它对应的是终端解析和屏幕状态维护这一层的可靠性改进。对于持续输出的编码 Agent，解析器是否能正确处理控制序列和宽字符，会直接影响用户对运行状态的判断。
这次修复关注的边界
v0.8.7 的核心变化可以概括为三点：
- 使用
avt解析器：让终端控制序列和屏幕状态的处理有更明确的解析基础。 - 处理宽字符与窗口缩窄：减少字符宽度计算和重新布局带来的空白、错位问题。
- 避免重绘阻塞：降低终端刷新过程对工作台交互和状态展示的影响。
这类修复通常不会改变 Agent 的调用方式，却会改变长任务期间的实际体验。尤其是在 Claude Code、Codex 或 OpenCode 持续输出日志、执行命令并更新进度时，终端必须同时满足两个条件：内容要显示正确，界面还要保持可交互。
可以这样验证终端行为
下面的 Python 示例不依赖 Termexo 内部代码，用来构造一个最小的终端压力场景：输出宽字符，使用 ANSI 转义序列清理当前行，并反复重绘进度。可以在 Windows Terminal、PowerShell 或其他支持 ANSI 的终端中运行，再手动缩窄窗口观察显示是否稳定。
将内容保存为 terminal_redraw_check.py 后运行：
import sys
import time
for step in range(1, 11):
message = f"步骤 {step}/10 | 宽字符：中文测试 | 状态：运行中"
sys.stdout.write("\r\x1b[2K" + message)
sys.stdout.flush()
time.sleep(0.25)
sys.stdout.write("\n完成，终端仍可继续输入。\n")
运行命令：
py .\terminal_redraw_check.py
这个例子只验证终端呈现层，不等同于 Termexo 的完整回归测试。针对工作台类应用，还应补充以下场景：
- Agent 持续输出时缩窄和恢复窗口。
- 输出包含中英文、全角标点和表情符号时重新绘制。
- 大量 ANSI 控制序列连续到达时，界面是否仍能响应。
- Agent 仍在输出但暂时没有新内容时，状态是否被误判为停止。
- 多个终端会话同时刷新时，某个会话是否会阻塞其他会话。
升级时的实际建议
如果你依赖 Termexo 长时间运行 Claude Code、Codex 或 OpenCode，v0.8.7 值得作为终端可靠性版本验证。升级后不要只打开一个空闲会话，建议直接使用日常任务做一次观察：让 Agent 输出较长日志，插入包含中文的命令或文件内容，再调整窗口宽度。
验证时重点看三个信号：内容是否持续更新、状态是否与实际进程一致、窗口调整后是否还能正常重绘。如果问题只在特定 Agent 或特定输出模式下出现，应同时记录终端宽度、输出内容类型和是否包含 ANSI 控制序列，这些信息比单独描述“界面空白”更有助于定位。
终端工作台的可靠性并不只取决于进程有没有启动。解析器、屏幕缓冲区、重绘调度和状态判断任何一层出错，都会把一个仍在运行的任务呈现成失败。Termexo v0.8.7 选择从终端解析与重绘基础修复这些问题，适合把稳定性放在新增界面功能之前的用户升级验证。