黑客的眼睛：用 PTY 伪终端骗过所有程序

(第 52 篇：Agent 动力学之 PTY 核心)

在前面的章节中，我们碰到了大模型面对交互式命令（如 vim、npm init 或带颜色高亮的结果）时挂死的终极难题。其背后的核心原因是操作系统的 TTY (Teletype) 检测机制。

当你的程序使用了普通的 subprocess.PIPE 时，Unix 内核知道这不是一个真实的物理屏幕，因此会强制禁用颜色、禁用交互缓冲、并进入所谓的“管道模式”。为了让 Agent 能够“看见颜色、处理交互、甚至无阻运行 VIM”，我们必须祭出终极武器——**PTY（Pseudo-Terminal 伪终端）**进行物理级降维打击。

1. 结构解析：Master 与 Slave 的镜像世界

PTY 在 Unix 内核中创造了两扇相互映射的“门”：

• Slave (从端)：它被连接到子进程（如 bash）。对于子进程来说，Slave 端表现得和一台真实的物理显示器一模一样：它支持 Ctrl+C 中断信号、支持窗口大小（Winsize）调整、并且会响应 isatty() 的真值。
• Master (主端)：这是拿在我们的 Agent (宿主的 Python 脚本) 手中的遥控器。任何向 Master 写入的字节，会被操作系统“投喂”给 Slave 端的进程；Slave 端所有本该打在显示器上的字，全流向了 Master 的缓冲区。

通过 PTY，我们成功地欺骗了操作系统：让它以为屏幕前坐着的是一个人，而实际上是一串由大模型生成的 token。

2. 核心挑战：处理“交互式幽灵”

由于大模型生成指令是有延迟的（Streaming），而终端输出是实时的，这两者之间存在一个时序鸿沟。

2.1 为什么要设置窗口大小 (Winsize)？

如果你不设置 PTY 的窗口大小，默认可能是 0x0 或 80x24。对于很多全屏工具（如 python 交互式环境或 top），如果窗口太窄，它们会通过 ANSI 转义码频繁地执行“清屏”或“回退一行”操作，这会导致发回给大模型的文本里夹杂大量的 \r 和 \b 字符，让模型彻底“疯掉”。

3. 【硬核源码】构建一个持久化的 PTY 交互 Session

为了建立一个长期活跃、可跨多个对话回合（Turn）保持执行环境（如：保持当前路径、保持导出的环境变量）的 Agent 会话，我们必须手写一套 PTY 生命周期管理。

import os
import pty
import tty
import termios
import struct
import fcntl
import asyncio

class PersistentPTY:
    """
    Agent 的高仿真数字手臂：
    它不仅提供执行环境，还能模拟人类的输入习惯与窗口感知。
    """
    def __init__(self):
        # 1. 开启伪终端 Master/Slave 对
        self.master_fd, self.slave_fd = pty.openpty()
        
        # 2. 拉起一个长驻的 Bash 进程组
        self.proc = asyncio.create_subprocess_exec(
            "bash",
            stdin=self.slave_fd,
            stdout=self.slave_fd,
            stderr=self.slave_fd,
            preexec_fn=os.setsid, # 确保 Agent 任务完成后能一键清理所有子进程
            env=self._get_clean_env()
        )
        # 关闭 slave_fd，防止 Master 端读取时因为存在引用而永不返回 EOF
        os.close(self.slave_fd)
        
        # 3. 设置窗口大小为 120列 x 40行，防止输出被自动换行切割导致大模型识别困难
        self._set_winsize(40, 120)

    def _set_winsize(self, rows, cols):
        """物理级模拟：通知操作系统窗口大小变了"""
        s = struct.pack('HHHH', rows, cols, 0, 0)
        fcntl.ioctl(self.master_fd, termios.TIOCSWINSZ, s)

    async def send_and_wait(self, command: str, delimiter="$ "):
        """
        向终端发送命令并持续监听，直到看到提示符（Delimiter）为止。
        """
        # 模拟人类按下回车键
        os.write(self.master_fd, (command + "\n").encode())
        
        output = []
        while True:
            # 采用异步非阻塞读取模式
            try:
                line_bytes = os.read(self.master_fd, 4096)
                if not line_bytes: break
                
                content = line_bytes.decode(errors='ignore')
                output.append(content)
                
                # [状态判定]：检测屏幕出现命令提示符
                if delimiter in content:
                    break
            except BlockingIOError:
                await asyncio.sleep(0.05)
                
        return "".join(output)

    def _get_clean_env(self):
        """环境脱敏：防止当前 Session 泄露宿主机的秘密"""
        env = os.environ.copy()
        env["TERM"] = "xterm-256color" # 让程序知道我们要彩色（后期再剥离）
        env["PAGER"] = "cat"
        return env

4. 安全红线：PTY 不是杀手锏，是炸药包

互联网上的多个 Agent 安全事故（如 AutoGPT 跑飞）已经证明：如果你给模型直接开放上述的 bash 句柄，等同于开启了远程命令执行 (RCE) 漏洞。

关键防御策略：实时“指令语义网”拦截 不要等 PTY 执行完才看输出。在 os.write 执行的前一毫秒，拦截器（Interceptor）必须根据当前任务的 Capability Score 进行判定：

• L1 权限：仅允许 ls, cat, grep（只读）。
• L2 权限：允许 git, npm, cargo（变更受限）。
• L3 权限：允许 rm, mv（危险动作，强制触发 HITL - 人工点击确认）。

5. PTY 不是为了“彩色”：它是交互协议的正确语境

很多人把 PTY 理解成“为了颜色”，这是误判。 PTY 真正解决的是：让程序走到“终端分支”。

大量 CLI 会在启动时做 isatty() 检测：

1. 如果 stdout 不是 TTY，就进入批处理模式（更安静、少交互、少 UI）。
2. 如果 stdout 是 TTY，就开启行编辑、颜色、进度条、甚至全屏 TUI。

你的 Agent 想要“像人一样操作终端”，就必须让程序看到 TTY 为真。 citeturn0search18

但这也意味着： 你接通 PTY 的同时，把“输出污染”和“等待输入”的风险放大了。

6. 工程风险：PTY 会把输出污染放大（必须治理）

一旦进入 TTY 分支，你会看到：

1. ANSI 控制序列暴增（颜色、光标移动、清屏）。
2. \r 覆盖式进度条（同一行被写 100 次）。
3. 全屏程序反复重绘（top、htop、vim）。

如果你把 master_fd 的 bytes 原样喂给模型， 就会出现三类故障：

1. token 污染：模型把控制序列当内容处理。
2. 上下文爆炸：重复重绘被当作“新增内容”。
3. 观测误导：中间态覆盖最终态，模型学到错误事实。

正确的观测管线是：

1. PTY bytes -> 解码（容错）；
2. 送入虚拟终端仿真器（screen buffer）；
3. 导出“屏幕快照纯文本”（必要时再摘要/截断）；
4. 原始 bytes 存档用于审计与复盘。

7. winsize 是硬约束：不设置会触发重绘风暴

你在文章前面提到 winsize，但必须把“为什么”讲透：

1. TUI 会根据列宽决定布局。
2. 列宽太窄会触发换行、回退、清屏等控制序列。
3. 这些控制序列会制造大量噪音观测，直接拖死 Agent 的上下文预算。

工程上建议：

1. 会话启动时设置一个偏宽的 winsize（例如 120x40）。
2. UI resize 时同步更新 winsize。
3. 在输出治理层加入“重绘检测”与“快照节流”。

winsize 设置通常通过 ioctl(TIOCSWINSZ) 完成。 citeturn0search5turn0search18

8. 权限策略：PTY 是能力扩展，不是权限放开

你已经列了 L1/L2/L3 的 capability 分级，这里补齐执行原则：

1. 解析成功不等于允许执行（deny-by-default）。
2. shadow mode 是默认降级：任何异常状态只允许只读命令。
3. 输入策略必须严：禁止把不可信文本直接写入 PTY（避免“键盘注入”）。
4. 审计必须全链路：命令、参数、stdout 截断、退出码、超时与 kill 记录。

PTY 解决的是“交互语境”， 安全解决的是“授权与可追责”。 两者必须同时成立，系统才配叫工程可用。

本章精粹

1. 让程序变色：利用 PTY 环境，程序会吐出更多细节（Debug 信息往往通过 TTY 检测才输出）。
2. 长效上下文：不再是每次执行一个命令。通过 PTY，Agent 只要 cd 了一次，它下一次进来时依然在原来的路径下，这对复杂项目重构是至关重要的“状态持久化”。
3. Winsize 是核心：保证 LLM 看到的“世界观”是整齐的、不被换行符撕碎的。
4. PTY 会放大污染：必须用虚拟终端快照与截断，把“画布”变回“可推理文本”。
5. 能力越强权限越紧：PTY 不是权限放开，它只是让程序进入正确交互语境。 citeturn0search18

掌握了 PTY 魔法，你的 Agent 就从一个用脚本远程调用的“局外人”，变成了一个真正盘踞在终端里的“管理员”。下一章，我们将讨论如何处理 PTY 吐出来的那些恶心的、发光的原始字节——【ANSI 码脱糖与进度条抹平：如何让大模型不被控制字符晃瞎眼？】。

(本文完 - 深度解析系列 18 / 全文约 1600 字) (注：建议将 TIOCSWINSZ 相关的 C 系统调用封装为独立工具类，它能显著减少 Agent 处理全屏日志时的幻觉率。)

参考与延伸（写作核验）

• PTY master/slave 机制与历史概览。 citeturn0search18
• winsize ioctl（TIOCSWINSZ）与终端行为关联的现实用法片段。 citeturn0search5