长命令和代码变更怎么管：PTY、Git 与 Verification

前置：代码修改如何成为可验证动作：Shell、Patch 与 Command Lifecycle
核心问题：长命令跨时间运行、代码又发生修改时，怎样用 PTY 与 Git 证明“执行发生了什么”和“最终改了什么”？

交互式 REPL 需要 PTY；普通 pytest -q 用 pipes 更简单、可控。启动任务记录 base SHA；修改后只展示相对 base 的 diff，并禁止自动 reset 用户原有 dirty files。

PTY / Long-running Process 基础

PTY（pseudo-terminal）为子进程提供终端语义，使 REPL、需要 TTY 的 CLI 或交互式程序可以接收 stdin、窗口尺寸和控制字符；长进程还需要独立 process/session handle、流式 stdout/stderr、timeout 与显式终止。

PTY 用于需要终端语义/交互的进程，和普通 pipe 不同；长进程还需 session handle、输入、窗口、终止和资源回收。不要默认所有命令都需 PTY。

Git 提供基线、diff、分支和可回滚性。Agent 不应无授权 force push/rewrite history，commit identity 与 remote write 属于权限边界。

Git 提供版本化工作树、base commit 和变更边界。Agent 操作前要知道当前 branch/head/dirty state，避免覆盖用户未提交修改。

“工具返回成功”不是修改正确的证据。Diff 是修改的最小可审查证据；Patch 应基于明确 context/base 应用并检测冲突。修改后通过 reread、lint、test、git diff 验证实际文件状态，不相信模型声称“已经改好”。

Diff 是“Agent 实际改了什么”的事实，Patch 是变更操作，Verification 通过语法/测试/静态检查证明结果。三者要形成闭环。

启动 dev server、测试套件或 build 时，Tool result 不应只有“命令已启动”。Runtime/Workspace adapter 需要保存：

text

command_id
pid/session identity
cwd
env/policy version
started_at
stdout/stderr artifact refs
exit status / still_running

PTY 适合需要终端语义或交互的程序，但它不是 durability。进程重启后旧 PTY 可能不存在，因此长期任务仍要把重要输出/状态外部化。

修改前记录 base revision，修改后获取 diff/working-tree status，再运行与该 revision/diff 对应的测试。验证链应是：

text

base commit
→ patch applied
→ diff hash
→ tests against that workspace
→ final artifact/commit

如果 Agent 测完又继续改文件，之前的 test evidence 就变 stale。Coding Harness 应把 verification 与具体 workspace snapshot/diff identity 绑定，而不是只保存一句 tests passed。