Codex“看起来卡死”最常见的原因是在等你批准一个approval请求，官方恢复三步是查批准队列→跑git status验证终端→开新线程，但新手的第一反应永远是Ctrl+C重启——“卡住先查队列”这件事，到底该靠肌肉记忆还是该靠工具给一个更明显的提示？

1. 问题的提出：一个被反复误判的“卡死”

在终端里运行 AI 编码代理时，几乎每个使用者都经历过这样的场景：输入一条指令，代理开始工作，打印了几行日志，然后——光标停住，屏幕不再刷新。等待十秒、三十秒、一分钟，没有任何变化。此时绝大多数人的第一反应是按下 Ctrl+C，然后重新启动，重新描述需求，重新等待。

但真实情况往往并非进程崩溃。代理可能已经走到了一个需要人工确认的节点：它想写入某个文件、执行某条 shell 命令、访问某个网络地址，或者提交一次 git 变更。这类操作被设计为需要用户批准（approval），以确保人类对敏感动作保有最终控制权。问题在于，这个批准请求的呈现方式，与用户对“程序正在运行”的直觉预期之间存在落差。终端没有进度条，没有闪烁提示，没有声音，只有一片安静。

“卡住先查队列”这句话，本质上是一条经验规则（heuristic）。经验规则的价值在于低成本、易传播，但它的可靠性高度依赖使用者是否真的把它内化为条件反射。当规则与直觉冲突时，直觉往往先赢。

这就引出了本文要处理的核心张力：“卡住先查队列”这件事，到底该靠肌肉记忆，还是该靠工具给一个更明显的提示？ 表面上看，这是一个 UX 问题；往深里看，它涉及代理运行时的状态建模、人机之间的信息通道设计，以及故障诊断的可观测性基础设施。本文认为，把责任完全推给用户的肌肉记忆，是一种工程上的懒惰；而把提示做到极致却忽视状态机本身的可查询性，则是另一种形式的本末倒置。二者需要结合，且结合的优先级有讲究。

为了让讨论不至于停留在经验层面，本文先给出一个可检验的分析框架，再逐层展开。

2. 背景与概念界定：代理、审批与状态机

2.1 什么是编码代理（Coding Agent）

编码代理是一类以大型语言模型为决策核心、能够自主调用工具（读写文件、执行命令、检索代码库）以完成软件工程任务的系统。与单纯的代码补全不同，代理具备多步规划与工具调用循环：观察环境 → 生成动作 → 执行动作 → 观察结果 → 继续。这个循环在学术文献中常被描述为 ReAct 式（Reasoning + Acting）的交替过程，其代表性工作可追溯至 Yao 等人 2022 年提出的 ReAct 框架（Yao et al., 2022, arXiv:2210.03629）。

本文评述：ReAct 框架的价值在于把“推理”和“行动”显式地交织起来，但它对“行动被阻塞”这一状态几乎没有讨论。原因不难理解——学术基准通常假设工具调用是即时返回的，而真实工程环境里，工具调用可能因为权限、审批、网络、资源竞争而进入等待。这个被学术叙事忽略的“等待态”，恰恰是工程实践中最常见的故障来源。

2.2 审批（Approval）机制的设计动机

审批机制的核心动机是风险控制。代理具备执行任意 shell 命令的能力，这意味着它理论上可以删除文件、修改系统配置、发起网络请求。若不加约束，一次模型幻觉就可能造成不可逆损害。因此主流代理运行时普遍引入“人在回路”（Human-in-the-Loop, HITL）的审批层：对高风险动作暂停执行，等待用户显式确认。

HITL 在安全与自动化领域并非新概念。Amershi 等人 2019 年在 CHI 发表的《Guidelines for Human-AI Interaction》中系统提出了人机交互的十八条设计准则，其中“支持高效纠正”“在适当时机告知用户”“传达系统能力边界”等条目，与审批提示的设计直接相关（Amershi et al., 2019, CHI）。本文评述：这份准则清单提供了一个很好的评价坐标系，但它写于生成式代理大规模落地之前，对“代理主动暂停并请求授权”这一具体场景着墨有限。笔者认为，审批提示应当被视为 HITL 准则在代理时代的一个高优先级子问题，而非附属细节。

2.3 状态机视角：代理运行时的四种基本状态

把代理运行时抽象为一个状态机，有助于精确定位“卡死”发生在哪一环。一个简化的状态划分如下：

从表中可以清楚看到，“Awaiting Approval”是唯一一个“用户可观测信号可能完全缺失”的状态。Running 有日志，Blocked 有错误，Done 有提示符，唯独等待批准，在提示渲染失败或被日志淹没时，外部表现与“死机”几乎无法区分。这就是本文所说的状态可见性缺口的精确位置。

3. 机制剖析：审批阻塞的因果链与分类

3.1 因果链：从动作生成到静默等待

一次典型的审批阻塞，其因果链可以拆解为五个环节：

1. 动作生成：模型决定调用一个被标记为敏感的工具（如 shell.exec、file.write）。
2. 策略判定：运行时根据配置的审批策略（allowlist / denylist / 全量确认）判定该动作是否需要人工批准。
3. 请求入队：需要批准的动作被写入批准队列，代理主循环挂起，等待队列状态变更。
4. 提示渲染：运行时尝试把批准请求渲染到终端。这一步是缺口的高发区——渲染可能被并发日志覆盖、被 TUI 刷新吞掉、或在非交互模式下根本无处渲染。
5. 静默等待：若用户未察觉，代理无限期挂起。多数实现没有超时机制，因为超时后自动拒绝或自动批准都违背安全初衷。

本文评述：第 4 步是整个链条中最脆弱的一环，却往往被当作“UI 细节”而低估。从可靠性工程的角度看，一个可能无限期挂起且无外部信号的状态，属于典型的静默失败（silent failure）。NASA 与航空工业的故障分析传统中，静默失败被视为比显式失败更危险，因为它剥夺了操作者的干预时机。笔者认为，代理运行时应当把“等待批准”当作一等状态来对待，而不是当作日志流中的一条普通消息。

3.2 阻塞的分类

并非所有“卡住”都是审批阻塞。把可能的阻塞来源分类，有助于排查时快速缩小范围：

分类的意义在于：不同阻塞类型的恢复成本差异巨大。审批阻塞只需一次确认即可继续，上下文完整保留；而 Ctrl+C 重启会丢失全部对话上下文，重新描述需求的成本可能是几分钟到几十分钟。这正是“先查队列”这条经验规则的经济学基础——它用极低的检查成本，避免了极高的重启成本。

3.3 为什么提示会被“看不见”

即便运行时确实渲染了批准提示，用户仍可能视而不见。原因可以归为三类：

其一，信号淹没。代理在等待批准前往往已经打印了大量日志。批准提示若以普通文本行插入日志流，视觉权重与周围内容无异，容易被滚动出视野。信息可视化研究中，显著性（salience）是注意捕获的关键变量，Wolfe 与 Horowitz 关于视觉搜索的综述指出，与背景对比度低、缺乏独特特征的目标极易被漏检（Wolfe & Horowitz, 2004, Nature Reviews Neuroscience）。本文评述：把批准提示做成与日志同质的文本行，本质上是在制造一个低显著性目标，漏检几乎是必然的。

其二，预期错位。用户的心智模型是“程序在跑就会动”。当屏幕静止，用户倾向于归因为“程序死了”，而不是“程序在等我”。这种归因偏差在认知心理学中被称为可用性启发式（availability heuristic）的变体——最容易想到的解释（崩溃）压倒了正确但少见的解释（等待批准）。

其三，交互范式惯性。命令行用户长期习惯了“无输出即卡死”的判断，因为传统 CLI 工具确实如此。代理引入了一种新的交互范式——程序主动暂停并请求人类输入——但终端本身没有为这种范式提供标准化的视觉语言。

4. 官方三步恢复法的工程语义

面对“看起来卡死”，官方给出的恢复路径是三步：查批准队列 → 跑 git status 验证终端 → 开新线程。这三步不是随意的操作顺序，而是一条从“最可能、最低成本”到“最不可能、最高成本”的排查梯度。理解每一步的工程语义，比记住步骤本身更重要。

4.1 第一步：查批准队列

批准队列是运行时维护的待批准动作列表。查询它，等价于直接读取代理的内部状态，是信息量最高、成本最低的诊断动作。如果队列非空，问题定位即告完成，用户只需做出批准或拒绝的决定。

这一步的工程语义是状态外化：把原本只存在于运行时内存中的状态，通过一个可查询的接口暴露给用户。状态外化是可观测性（observability）的基础。控制论先驱 W. Ross Ashby 在《An Introduction to Cybernetics》中提出的“必要多样性定律”（Law of Requisite Variety）指出，调节器的内部多样性必须不低于被调节系统的多样性，否则无法有效控制（Ashby, 1956）。本文评述：用户要有效“调节”代理，就必须能观测到代理的足够多状态；批准队列的查询接口，正是提升用户侧多样性的一个具体手段。

实践中，查队列的方式因运行时而异，常见形态包括：

# 伪代码示意：不同运行时的队列查询入口
# 形态 A：斜杠命令
/approvals            # 列出待批准动作
/approve 2            # 批准第 2 项

# 形态 B：独立子命令
agent approvals list
agent approvals approve <id>

# 形态 C：TUI 快捷键
Ctrl+A                # 打开批准面板（示意）

需要强调的是，具体命令以所用运行时版本的官方文档为准，不同版本可能调整。本文不虚构任何具体产品的命令细节，读者应查阅对应版本的帮助输出（如 --help）确认。

4.2 第二步：跑 git status 验证终端

如果队列为空，或者查询命令本身没有响应，下一步是验证“终端是否还活着”。git status 之所以被选为探针，原因有三：

• 低副作用：只读操作，不改变仓库状态，可安全重复执行。
• 快速返回：在正常仓库中毫秒级返回，若卡住则说明终端或 shell 本身有问题。
• 信息附加：顺便能看到代理是否已经修改了工作区文件，为后续判断提供线索。

这一步的工程语义是通道验证：把“代理是否卡住”与“终端是否卡住”两个假设分离开。如果 git status 正常返回，说明终端通道健康，问题在代理侧；如果它也卡住，说明问题在更底层（shell、TTY、系统资源）。

本文评述：选择 git 相关命令作为探针还有一个隐性优势——编码代理的工作对象通常就是 git 仓库，git status 的输出与用户当前任务高度相关，不会产生“为了测试而测试”的割裂感。这种“探针即工作”的设计，降低了用户执行诊断的心理门槛。

4.3 第三步：开新线程

如果前两步都无法恢复，最后的手段是开一个新线程（new thread / new session）。这一步的语义是隔离故障：旧线程可能已经进入不可恢复的挂起状态，继续在其上操作只会浪费时间。新线程拥有干净的上下文，可以重新开始。

但“开新线程”是有代价的：旧线程中积累的对话历史、已完成的中间成果、模型对任务的理解，都不会自动迁移。因此这一步应当被明确定位为“止损”而非“修复”。在工程实践中，建议在开新线程前，先把旧线程的关键结论、已修改文件清单、待办事项手动记录下来，作为新线程的初始输入。

5. 终端验证：git status 为什么是可靠的探针

上一节把 git status 作为通道探针，本节展开其可靠性依据，并给出更完整的终端诊断方法。

5.1 探针的可靠性条件

一个合格的诊断探针应满足：低副作用、确定性返回、失败可区分。git status 满足前两条较为明显；第三条“失败可区分”值得展开——当 git status 卡住时，我们需要能判断是 git 本身慢（如超大仓库、网络文件系统），还是终端通道坏了。区分方法是换一个更简单的命令（如 echo ok）再试一次。如果 echo 也卡，问题在终端；如果 echo 正常而 git status 卡，问题在 git 或仓库。

# 分层探针：从最简到最复杂
echo ok                 # 终端通道是否健康
pwd                     # shell 是否响应
git status --short      # git 是否响应（--short 减少输出）
ps aux | grep -i agent  # 代理进程是否存活

# 若怀疑是 TTY 问题，可尝试
stty sane               # 重置终端设置（谨慎使用）
reset                   # 重置终端（会清屏）

5.2 进程视角的验证

终端验证之外，进程视角能提供更直接的证据。若代理进程处于 S（可中断睡眠）或 T（停止）状态，且 CPU 占用接近零，基本可以判定它在等待某个外部事件——这与“等待批准”的假设一致。反之，若 CPU 占用高，则更可能是模型推理或工具计算中。

# Linux / macOS 通用
ps -o pid,stat,%cpu,etime,command -p <PID>

# 输出示例（示意）
#   PID STAT %CPU     ELAPSED COMMAND
# 12345 S     0.3       04:12 agent-cli

# 查看进程打开的文件描述符（判断是否在等 stdin）
lsof -p <PID> | grep -E '0u|1u|2u'

本文评述：进程状态是比终端输出更“诚实”的信号源。终端输出是应用层的渲染结果，可能被缓冲、被覆盖、被 TUI 吞掉；而进程状态由内核维护，不受应用层渲染逻辑影响。在诊断“看起来卡死”时，把观测层次从应用层下沉到进程层，往往能一举打破僵局。这与分布式系统可观测性中“不要只信应用日志，要看指标和追踪”的原则一脉相承。

5.3 终端复用器的价值

使用 tmux 或 screen 等终端复用器，能显著降低诊断难度：代理在一个 pane 中运行，用户在另一个 pane 中执行诊断命令，互不干扰。若代理卡住，用户无需中断它就能检查队列、查看进程、验证仓库状态。这实际上是把“单通道”变成了“多通道”，从根本上缓解了状态可见性缺口。

延伸阅读：tmux 官方文档提供了 pane 管理与脚本化能力，适合构建自动化的诊断布局（tmux Wiki）。

6. 线程隔离与上下文管理

6.1 线程作为故障隔离单元

“开新线程”之所以有效，是因为线程是代理运行时中上下文与状态的天然隔离单元。一个线程的挂起不会污染另一个线程。这种隔离在软件工程中并不新鲜——Erlang/OTP 的“let it crash”哲学、Kubernetes 的 Pod 隔离，都建立在“故障应被限制在最小单元内”的原则上。Armstrong 在《Making Reliable Distributed Systems in the Presence of Software Errors》中系统阐述了这一思想（Armstrong, 2003, KTH Doctoral Thesis）。

本文评述：把“let it crash”直接套用到代理线程上需要谨慎。Erlang 进程崩溃后可以快速重启，因为状态由监督树重建；而代理线程的“状态”包含大量不可重建的对话上下文，重启的代价远高于 Erlang 进程。因此代理场景下的线程隔离，重点不在“快速重启”，而在“故障不扩散”与“上下文可迁移”。

6.2 上下文迁移的实践

开新线程前，把旧线程的关键信息结构化地迁移过去，能显著降低重启成本。一个可复用的迁移模板如下：

## 任务目标
（一句话描述要完成的事）

## 已完成
- [x] 修改了 src/foo.ts 的解析逻辑
- [x] 补充了 3 个单元测试

## 待办
- [ ] 修复 test/bar.test.ts 的失败用例
- [ ] 更新 README 的用法说明

## 关键约束
- 不得改动公共 API 签名
- 提交前必须通过 lint

## 已知问题
- 旧线程在请求批准 `git push` 时挂起，未完成

这份模板的价值在于把“隐性上下文”显性化。旧线程里模型“知道”的东西，新线程并不知道；只有写成文本，才能跨线程传递。这与知识管理中的“外化”（externalization）概念一致，Nonaka 与 Takeuchi 在知识创造理论中把隐性知识向显性知识的转化视为组织学习的关键环节（Nonaka & Takeuchi, 1995）。

6.3 何时不该开新线程

开新线程是止损手段，不是首选。以下情况应优先尝试恢复旧线程：

• 批准队列可查询且非空——直接批准即可，无需重启。
• 进程仍存活且状态为睡眠——说明它在等待，而非崩溃。
• 上下文积累量大且难以结构化迁移——重启成本高于排查成本。

判断标准可以概括为：只要旧线程还有“可读的内部状态”，就优先读状态而不是重启。只有当内部状态完全不可读、且进程行为异常时，才动用新线程。

7. 可见性工程：从肌肉记忆到工具提示

回到本文的核心问题：“卡住先查队列”该靠肌肉记忆还是靠工具提示？ 本节给出笔者的分析框架与结论。

7.1 肌肉记忆的边界

肌肉记忆（更准确地说，是程序性记忆）的优势在于低认知负荷、快速触发。它在高频、稳定、反馈明确的场景中非常有效——比如打字、驾驶。但它的形成需要两个条件：高频重复与即时反馈。而“卡住先查队列”这条规则恰恰缺乏即时反馈：用户查了队列，如果为空，得不到“你查对了但这次不是这个原因”的正向强化；如果非空，问题解决，强化才发生。这种稀疏反馈使得习惯难以稳固形成。

本文评述：把可靠性寄托于一条反馈稀疏的经验规则，在工程上是不稳健的。这不是说肌肉记忆无用，而是说它不足以作为唯一防线。任何依赖“用户必须记得”的安全机制，都会在压力、疲劳、新手期等条件下失效。安全工程领域对此有成熟认识：Reason 在《Human Error》中提出的“瑞士奶酪模型”指出，事故往往发生在多层防御的漏洞对齐时，而依赖单一人类记忆的防御层是最容易被穿透的（Reason, 1990）。

7.2 工具提示的设计原则

工具提示要真正解决问题，不能只是“把提示字放大”，而要从信息架构上重新设计。笔者认为应遵循以下四条原则：

7.3 推送与拉取的组合

从信息传递方向看，工具提示是“推送”（push），查队列命令是“拉取”（pull）。推送的优势是主动、及时，劣势是可能被忽略或淹没；拉取的优势是按需、精确，劣势是依赖用户主动发起。成熟的系统通常两者兼备——就像监控系统既有告警推送，也有仪表盘供主动查询。

本文评述：在代理审批场景中，推送应负责“引起注意”，拉取应负责“确认状态”。用户看到推送提示后，通过拉取命令确认队列内容，再决定批准或拒绝。这条“推送→拉取→决策”的链路，比单纯依赖任一方向都更可靠。它把肌肉记忆从“必须记住查队列”降级为“看到提示后知道怎么查”，认知负担显著降低。

7.4 一个可落地的提示设计草案

下面给出一个不依赖具体产品的提示设计草案，供工具开发者参考：

┌─────────────────────────────────────────────┐
│ ⏸  AWAITING APPROVAL  (1 pending)            │
│                                              │
│  动作: shell.exec                            │
│  命令: npm run build                         │
│  原因: 该命令会写入 dist/ 目录               │
│                                              │
│  批准: /approve 1     拒绝: /deny 1          │
│  查看队列: /approvals                        │
└─────────────────────────────────────────────┘

这个草案体现了前述四条原则：常驻框体（原则一）、直接给出批准命令（原则二）、明确的动作与原因（降低决策成本）、附带队列查询入口（原则四）。超时升级（原则三）可以在框体颜色或边框闪烁上体现。

8. 对比与局限：不同代理运行时的提示策略

不同代理运行时对审批提示的处理策略差异明显，这种差异恰好构成了一组天然的对照实验。下表基于公开文档与社区讨论整理，标注为“定性对比”，不涉及具体版本的精确行为。

本文评述：三种策略没有绝对优劣，取决于使用场景。个人开发者追求流畅，可能偏好预配置；团队协作与生产环境追求安全，可能偏好交互式确认。但无论哪种策略，“等待状态必须可观测”都是不可妥协的底线。预配置型看似没有等待，但它把风险前移到了配置阶段，一旦配置失误，后果可能更严重。

局限方面，本文的讨论主要基于命令行交互场景。在 IDE 插件、Web 界面等图形化环境中，审批提示的呈现方式不同（如弹窗、侧边栏、状态栏），状态可见性缺口的形态也会变化，但“内部状态与外部可观测信号之间的断层”这一本质不变。读者在迁移本文结论时，应结合具体界面的信息架构做调整。

9. 可操作路径：一份排查清单与工具化方案

9.1 三十秒排查清单

面向日常使用，下面这份清单按顺序执行，绝大多数“卡死”能在三十秒内定位：

9.2 工具化：把清单变成脚本

清单的价值在于可重复，而可重复的东西应该被脚本化。下面是一个诊断脚本的骨架，读者可根据所用运行时的实际命令替换占位符：

#!/usr/bin/env bash
# agent-diag.sh —— 代理卡死快速诊断（示意）
set -u

echo "== 1. 终端通道 =="
echo ok || { echo "终端无响应"; exit 1; }

echo "== 2. 仓库状态 =="
git status --short 2>/dev/null || echo "git 不可用或非仓库"

echo "== 3. 代理进程 =="
pgrep -af "agent" || echo "未发现代理进程"

echo "== 4. 批准队列 =="
# 替换为实际运行时的队列查询命令
# agent approvals list || echo "队列查询不可用"

echo "== 5. 建议 =="
echo "若队列非空 -> 批准或拒绝"
echo "若进程睡眠且 CPU≈0 -> 大概率在等待输入"
echo "若以上均正常仍无输出 -> 考虑开新线程并迁移上下文"

本文评述：脚本化的意义不只是省事，更在于把隐性知识固化为可执行资产。当“卡住先查队列”变成一条命令，它就不再依赖某个人的记忆，而成为团队共享的诊断能力。这与 SRE 领域“把 runbook 变成自动化”的实践方向一致——Google SRE 团队在《Site Reliability Engineering》中反复强调，减少人工判断环节是提升系统可靠性的关键（Beyer et al., 2016, O'Reilly）。

9.3 团队层面的落地建议

• 统一运行时版本：不同版本的提示行为可能不同，团队内统一版本能减少“我这里不卡你那里卡”的沟通成本。
• 共享诊断脚本：把上一节的脚本纳入仓库，新人入职即可使用。
• 约定上下文迁移模板：把第 6 节的模板固化为团队规范，降低开新线程的损失。
• 记录故障案例：每次“卡死”排查后，记录根因与耗时，形成团队知识库。

延伸阅读：关于终端可观测性与诊断脚本设计，可参考 Google SRE Book 与 tmux Wiki；关于人机交互准则，可参考 Microsoft Research 的 HAI 准则页面。

10. 结论与展望

回到开篇的问题。“卡住先查队列”该靠肌肉记忆还是靠工具提示？本文的结论是：两者都需要，但优先级应当是“工具提示负责引起注意，肌肉记忆负责兜底确认”。把主要防线放在工具侧，是因为人类记忆在压力与疲劳下不可靠，而工具的行为是确定性的；把兜底放在人侧，是因为任何提示都可能失效，用户需要保留主动查询的能力。

更一般地，本文用“状态可见性缺口”这条主线，把审批阻塞从一个个案上升为一类工程问题：当系统的内部状态无法被外部充分观测时，用户会把“等待”误判为“故障”，并采取破坏性的恢复动作。这个模式不仅适用于代理审批，也适用于构建系统、数据库迁移、分布式任务调度等一切存在“静默等待”的场景。识别并填补状态可见性缺口，是提升人机协同可靠性的通用抓手。

展望未来，笔者认为有三个方向值得关注：其一，代理运行时的可观测性标准化，类似 OpenTelemetry 为分布式系统定义追踪语义，代理领域也需要一套描述“等待、批准、拒绝”状态的通用语义约定；其二，渐进式提示的实证研究，通过用户实验量化不同提示设计对误判率的影响，而非停留在经验判断；其三，上下文迁移的自动化，让开新线程不再意味着从头开始，而是带着结构化记忆无缝续接。

在这些方向成熟之前，一份清晰的排查清单、一个可执行的诊断脚本、一条“先查队列再重启”的纪律，仍然是每个代理使用者最实在的依靠。

主要参考文献