Shell、PTY、Terminal 与后台作业

结论：这里不是一个 Shell，而是四个相互正交的生命周期系统

这种拆分真正解决的是生命周期，而不是命令语法：谁能看见资源、取消何时算完成、输出丢失怎样显式表达、Agent 销毁时谁负责收尸。代价是部署者必须同时理解 composition、owner scope 和 provider 能力；仅看到一个 bash 工具名，无法判断它是一次性进程还是持久 Shell。

1. 四层拓扑：执行、命令、后台控制与交互会话

模型工具
  bash / pwsh ───────────────→ ctx.shell ──────→ ctx.subprocess.spawn
       └─ run_in_background ─→ ctx.jobs ───────┘

  terminal_* ────────────────→ ctx.terminals ─→ PTY backend
       └─ background send ───→ ctx.jobs             └→ ctx.subprocess.spawnTerminal

  persistent bash wrapper ───→ ctx.terminals（每个 Agent 复用一个 PTY）

ctx.shell 刻意不知道 Session 与 Job ID；后台注册、轮询和通知属于 Job 层。反过来，Job Registry 不知道命令、PTY 或 subagent 的实现，只接受生产者给出的 cancel/done/readOutput hooks。

2. 发布配置选择两种完全不同的 bash

3. Subprocess seam 拒绝隐式默认：每一项执行条件都由 caller 给出

SubprocessSpawnSpec 明确携带 argv、cwd、三条 stdio disposition、cleanup grace、AbortSignal 和环境 overlay；provider 不替调用者猜 Shell、目录、缓冲上限或 deadline。argv[0] 直接作为 executable，substrate 本身不做 Shell 解释。

这使本地执行与远端执行可以替换而不改工具合同：provider 可以改变 executable lookup、进程/PTY transport 与文件系统世界，但调用者仍决定策略和呈现。

4. 子进程环境先清洗，再显式重建当前 Harness 身份

process.env
  ├─ 删除名称匹配 KEY|PASSWORD|SECRET|TOKEN 的变量
  ├─ 删除全部 DSH_*（大小写不敏感）
  └─ 保留 PATH / HOME / locale / proxy 等
        ↓
调用者 env overlay（string 恢复；undefined 删除）
        ↓
Shell tool 每次从 ctx.shellEnv 注入当前 DSH_* snapshot

5. 长输出优先保留尾部；完整 Spill 只有在仍可信时才发布

“保留尾部”是诊断取向：错误和总结常在输出末端；spill 才承担完整取回。模型结果还会再经过工具级渲染上限，因此 substrate 可恢复并不等于该次模型上下文包含全部字节。

6. 一次性 Shell 把非零退出、超时与取消当成事实，而不是基础设施异常

7. 后台切换不是“不要 await”，而是一次原子所有权转移

bash(args)
  → 参数 / escalation / workdir / shellEnv 全部解析
  → 检查 tool-call signal 尚未 abort
  → jobs.start({ owner, kind, label, run })
       ├─ controller / owner / capacity preflight
       ├─ run() 真正 spawn
       ├─ 注册 record 与 JobId
       └─ Job runtime 接管 cancel / done / output
  → 返回 job id

8. Job Registry 是 producer-neutral 的 process-local 控制面

一个 Job 由 kind、label、可选 exact-Agent owner、输出 cap 与三个 hook 组成：producer 在 run() 中返回 cancel、永不 reject 的 done、可选 consuming readOutput；registry 负责 ID、状态、访问控制、waiter、通知与销毁。

9. Job 工具区分“请求取消”和“已经停止”

10. 完成通知会选择当前 Turn 的 inbox 或新 Follow-up Turn

Job settle 且尚未 reported
  ├─ owner busy                         → owner.inject(notice)
  ├─ owner idle + wake budget 尚有余额 → owner.followup(notice)
  └─ quiet mode / budget耗尽           → owner.inject(notice)

11. Job 生命周期跟 exact Agent 对象绑定，而不只是可复用的 Session 字符串

Owner cleanup 被挂到 exact Agent scope；销毁时 registry 先对 owned Jobs 请求取消，等待每个 settlement，最后删除 records 并通知镜像。服务整体销毁也执行同一套 quiescence。

Web 的 Job 列表只是 Host 推送的只读镜像：进程重启后清空，历史 transcript 中的启动卡仍然存在。它显示“曾经启动”和“当前仍有 live control”是两种不同事实。SHELL-JOBS-UI

12. Terminal service 发布的是 exact-owner 会话，不是可猜中的全局 PTY

13. terminal_send 的返回表示“何时适合再次思考”，不等于命令退出

14. 六个 Terminal 工具暴露资源；Persistent Bash 则隐藏资源

15. Kill 面向进程树，但静止证明因平台而异

普通本地进程在 POSIX 以 detached process group 为树根，先 TERM、等待 grace、再 KILL，并用 group liveness 观察静止；Windows 调用 taskkill /T /F 请求树级终止，但把 direct-child exit 当作可观察完成代理，没有独立的 descendant/group liveness probe。

16. 跨平台与远端替换发生在 substrate/provider，不应渗进工具合同

Bash 与 PowerShell 工具共享 ctx.shell、Job、审批和 managed env 语义；差异留在 executable、启动 flags、编码与 sandbox runner。E2B provider 则替换 ctx.subprocess 的 executable lookup、普通进程和 Terminal transport，让上层 Shell/PTY consumer 继续使用同一 seam。SHELL-E2B-SEAM

17. 固定基线上的三个静态审计发现

18. 保证矩阵：什么是耐久事实，什么只是当前进程的控制状态