Agent 跑命令跑一半没声了：多半是它在等一个永远不会来的回车

数据截至 2026-07，各产品的额度与报错口径以官方最新说明为准。

**Agent 执行终端命令时挂住，最常被归因成”模型抽了”或者”网络断了”，但这一类里占比最高的成因其实特别朴素：那条命令自己进入了交互态，正在等一个回车、一个 y、一个密码，而 Agent 所处的终端根本没有人在键盘那头。**这种卡法最阴险的地方在于它不报错、不超时、不留堆栈，界面上就是一条命令旁边永远转着圈。你重启 IDE、换模型、清缓存全都没用，因为那个子进程还在老老实实等 stdin。

站内有两篇邻居各管一段：Agent 转圈卡住不动讲的是整体卡住的分因，帮你判断卡在传输、上下文构建、工具执行还是交互等待哪一层；沙箱与权限拒绝讲的是命令根本没跑起来、被环境拦下的情况。这篇只切一小块——命令已经成功启动、进程也活着，但它停在等输入上——把这一类的判别方法和改写手法讲透。

一、先花三十秒自证：它到底是不是在等输入

不要凭感觉。等输入这一类有三个特征，凑齐两个基本就能坐实。

**特征一：最后一行输出长得像提问。**滚到命令输出的末尾，看最后一行的形状。(y/N) 这类括号里给了默认值的确认、一行以 ? 开头后面跟着若干条目和一个高亮箭头的选项列表、以 Password: 或 Username for ...: 结尾的凭据提示、结尾一个孤零零的 : 或 >，或者一个纯粹的空提示符——这些都是在等你回话。各家工具的措辞不一样，别去背具体字样，认形状就行：末行没有句号、以冒号或箭头收口、后面再没有新行冒出来。反过来，如果最后一行是一条正常的日志或进度百分比，那更可能是任务真的在跑或者卡在别的层。

**特征二：进程还在、CPU 几乎为零。**等输入的进程是睡着的，不烧 CPU 也不涨内存。在你自己的机器上看一眼进程列表就能确认：

ps aux | grep '你的命令关键词' | grep -v grep

如果这条命令的进程在、状态是睡眠、CPU 占用趴在零附近，同时也没有网络连接在传数据，那它十有八九在阻塞读 stdin。相对地，真的在编译、在跑测试的进程会有明显的 CPU 波动。末尾那个 grep -v grep 是为了把 grep 自己这行滤掉，不然你总会看到一条假阳性。Windows 下不要照抄这条：原生环境请用任务管理器或 Get-Process 看。Git Bash 里的 ps 是 MSYS 版本，不是 BSD 版，aux 这几个字母它既不报错也不生效，输出里压根没有 CPU 和进程状态列——你会以为命令跑通了，实际上一个能用于判断的字段都没拿到。要看进程状态和 CPU，还是回 PowerShell 用 Get-Process 更省事。

**特征三：把 stdin 掐掉重跑，行为会变。**这是最干脆的一招。你在本地手动跑同一条命令，但把标准输入接到空设备上：

你的命令 < /dev/null

三种结果对应三种结论。立刻报错退出，说明它确实要读输入，只是原来阻塞着等，现在读到 EOF 就崩了——成因坐实。正常跑完，说明这条命令能识别非交互环境并走默认分支，那 Agent 那边挂住多半另有原因。还是挂着不动，说明它没在读 stdin，而是前台常驻或者在等别的东西（网络、锁、子进程）。

补充一个判断口径：同一条命令你手动跑不会问、交给 Agent 就会问，这个反差本身就是线索。原因通常是环境变量不同（你的 shell 配置里有 CI、PAGER 之类的设置，Agent 起的 shell 没有），或者你的终端是 tty 而它的不是，程序对两种情况的默认行为不一样。

二、判别表

现象	大概率成因	怎么验证	处置动作
输出末尾是 (y/N) 或选项列表，之后没有新行	命令在等确认或等选型	看最后一行形状；< /dev/null 重跑看是否立刻退出	中断，改成带 -y 或同义非交互开关的写法
输出末尾是 Password: / Username for ...:	在等凭据输入	同上；再确认这条命令是否访问了私有仓库或需登录的服务	中断。凭据类操作不要交给 Agent，见第五节
输出停在满屏一页正好停住，末尾像个反色状态条	分页器（less 一类）接管了输出	把输出用管道接给 cat 再跑一次，如果一次性全出完就是分页器	加 --no-pager 或设 PAGER=cat
完全没有输出，进程在、CPU 为零	提示语被缓冲住没刷出来，实际已在等输入	ps 看进程状态；Python 脚本用 python -u 重跑看提示是否出现	按等输入处理；脚本侧关掉输出缓冲
输出正常滚动但永不结束，像日志在刷	不是等输入，是前台常驻（开发服务器、watch、tail -f）	看输出是不是周期性刷新或有服务已启动的字样	改后台运行 + 写日志文件，见第四节
命令是测试或构建，跑完却不退出	运行器进了 watch 模式	输出末尾常有等待文件变更的提示	用运行器的一次性执行模式，或设 CI=1
停在 git 相关命令上，且涉及提交、合并、变基	git 拉起了编辑器等你写内容或解冲突	检查仓库是否处于合并中断状态、工作区有无冲突标记 <<<<<<<	中断，改成带 -m 的写法；冲突人工处理
停在容器、远程连接类命令上	分配了交互式终端或在等主机指纹确认	看命令里有没有交互式终端参数；首次连接的主机尤其可疑	去掉交互式参数，或改成一次性执行模式
换了写法还挂，且每次挂在不同地方	不是这一类问题	回到分层判断	转去看整体卡住的分层排查或工具调用挑错

三、常见会等输入的命令，和对应的非交互写法

按我的经验，实际踩到的集中在六类。

**第一类，包管理与脚手架的确认。**很多包管理器在安装临时包之前会问一句是否继续，脚手架工具则会一路问项目名、框架、是否用 TypeScript。前者用工具自带的自动确认开关（npm 生态里是 npx --yes），后者要么把所有选项作为参数一次性传全，要么老老实实先在本地手跑一遍生成骨架，再让 Agent 接着改。系统层的包管理同理，Debian 系的写法是：

DEBIAN_FRONTEND=noninteractive apt-get install -y 包名

只加 -y 不够，有些包的配置界面是 DEBIAN_FRONTEND 控制的，漏了照样挂。Python 侧 pip install 通常不问，但它有 --no-input 开关，值得在自动化场景里显式带上。

**第二类，分页器。**git、systemd 一类工具在输出较长时会调起分页器，分页器等你按空格翻页，于是命令永不返回。

这里有个前提必须说清，否则你会拿自己的环境把这条结论证伪：这类工具通常只在判断出标准输出连着一个终端时才启用分页器，输出被重定向到管道或文件时会自己退化成直接打印。所以同一条命令，在把命令接成纯管道的执行器上根本不会挂，在给命令分配了伪终端（pty）的执行器上就会挂。很多 Agent 的终端面板为了显示彩色和进度条正是走 pty，这一类才因此成为常客。判断方法也直接：如果你的 Agent 面板里能看到彩色输出和会自我覆盖的进度条，说明它有 pty，分页器这条嫌疑就成立；如果输出永远是纯白文本、进度条打印成一长串重复行，那它更可能是纯管道，你该往等确认、等凭据那几类去查。

三种解法：命令自带的 --no-pager（如 git --no-pager log、systemctl --no-pager status）、环境变量（GIT_PAGER=cat、PAGER=cat）、或者管道给 cat。我倾向前两种，管道会改变某些工具的着色行为。

第三类，编辑器。git commit 不带 -m 会拉起编辑器；变基、合并信息、标签说明也一样。原则很简单：凡是会写一段文本的 git 操作，都要在命令行里把文本给全。

git commit -m "fix: 修正边界条件"
git merge --no-edit 分支名
git tag -a v1.2.0 -m "release"

交互式变基这类天然需要人来编辑清单的操作，不要交给 Agent。真要在自动化流程里屏蔽编辑器，可以设 GIT_EDITOR=true，让编辑器变成一个立刻成功返回的空操作。这一招的效果要分两种情况看，别一概而论：合并、回退这类操作本身带一条默认信息，编辑器空转就等于直接接受了那条默认信息，命令会照常完成；而 git commit 不带 -m 时并没有默认信息可用，模板里全是注释行，注释被剥掉之后信息为空，git 会中止提交并报错退出，不会替你生成一个信息空白的提交。也就是说它在 commit 场景下的作用更接近”把挂死换成一条明确的报错”，而不是”帮你把提交做完”。这个区别值得记住：以为设了它就万事大吉，结果流水线在提交那一步失败，回头还要重查一遍。

**第四类，凭据与认证。**HTTPS 方式访问私有仓库、推送到需要登录的远程、发布包时的二次验证，都会弹提示等输入。这里有一个非常好用的止损开关：

GIT_TERMINAL_PROMPT=0 git clone https://.../私有仓库.git

设成 0 之后 git 不再弹提示，而是直接失败。失败比挂死好一万倍：你立刻拿到一条明确的错误，知道该去配凭据助手或换 SSH 方式，而不是盯着转圈猜。很多 CLI 也支持用环境变量注入令牌来跳过登录流程，具体变量名各家不同，以该工具官方说明为准。另外，部分海外工具的登录与授权流程官方对中国大陆有区域限制、不支持直连，这类步骤不要指望在自动化里跑通；市面上存在第三方中转，我不做背书也不给渠道，只提醒它会让凭据经手第三方。

**第五类，REPL 与交互式终端。**不带参数敲解释器名会进 REPL，数据库客户端不带执行参数也是。数据库客户端一般都有”执行一条语句就退出”的参数（psql 的 -c、mysql 的 -e），用它。容器场景里最典型的是分配了交互式终端：

# 会挂：分配了交互式 TTY，容器里的 shell 在等输入
docker run -it 镜像 bash

# 不会挂：一次性执行，跑完就退
docker run --rm 镜像 python -c "print('ok')"

远程连接同理，首次连一台新主机会问是否信任主机指纹。可以用批处理模式让它在需要交互时直接失败：

ssh -o BatchMode=yes 用户@主机 '一条会自己退出的命令'

BatchMode=yes 只是禁止提示、让失败更快暴露，它不会替你跳过主机指纹校验；真要预置指纹，正确做法是提前把主机公钥写进 known_hosts，而不是无脑关掉校验——关掉校验等于放弃中间人防护。

**第六类，前台常驻。**开发服务器、tail -f、watch、测试运行器的 watch 模式，这些不是在等输入，但对 Agent 来说效果一模一样：命令永不返回，后面的步骤全堵住。处置手法是后台化加日志：

nohup npm run dev > /tmp/dev.log 2>&1 &
sleep 5
tail -n 30 /tmp/dev.log

先起后台，睡几秒等它就绪，再读日志的尾部确认启动成功。这样 Agent 拿到的是一段有限输出，而不是一个永不结束的流。测试和构建则优先用一次性模式，或者在环境里设 CI=1。这个变量是社区约定而非哪个标准，多数工具链的判断逻辑只是看它存不存在且非空，所以设成 1 还是 true 一般都吃，认了之后会关掉 watch 常驻和交互式提问。但它只是约定，遇到不认的运行器还是得回去翻它自己的一次性执行参数，不要把它当保证。关于后台任务本身悄悄失败的坑，后台 Agent 静默失败那篇讲得更细。

四、通用四板斧：不认识的命令怎么办

上面列不全，也永远列不全。遇到没见过的命令，按下面四步套，成本从低到高。

**第一板斧，查它有没有官方的非交互开关。**先跑 命令 --help，在输出里找 -y、--yes、--non-interactive、--no-input、--assume-yes、--batch 这类词，优先挑帮助文本里明确写着”不提示 / 不询问”的那个。有官方开关就用官方开关，这是语义最准确、副作用最小的做法。顺带提醒两个容易误用的：--quiet 多数时候只是少打印，跟提不提问没关系；--force 在有些工具里确实顺带跳过确认，但它同时还放宽了别的安全检查，能不用就别用。

**第二板斧，用环境变量统一收口。**给 Agent 的执行环境预置一组变量，能一次性消掉大半麻烦：

export CI=1
export PAGER=cat
export GIT_PAGER=cat
export GIT_TERMINAL_PROMPT=0
export DEBIAN_FRONTEND=noninteractive

好处是不用逐条命令改写，坏处是它是全局的，会影响你自己在同一个 shell 里的手动操作。所以我建议把这组变量放进 Agent 的执行环境或项目脚本里，而不是写进你个人的 shell 配置。

第三板斧，掐 stdin。在命令后面加 < /dev/null。这一招的价值不在于让命令跑通，而在于把挂死转成失败。挂死没有信息量，失败有——报错会告诉你它想要什么。作为一种更激进的变体，yes | 命令 会持续喂 y，但这招要非常克制，理由见第六节避坑清单的第一条。

**第四板斧，加超时。**给不确定的命令套一层时间上限：

timeout 120 你的命令 > /tmp/out.log 2>&1; echo "exit=$?"

超时后进程被杀，退出码非零，Agent 拿到明确结果继续走。注意两点：一定要把输出留到文件里，否则超时之后你连它卡在哪一句都不知道；退出码要打出来，Agent 才能据此分支。至于超时设多久，看命令类型自己定，不同任务差异极大。还有个跨平台的坑：timeout 来自 GNU coreutils，Linux 发行版一般自带，macOS 默认没有这个命令，得先装 coreutils 再用它提供的那个（安装后通常带 g 前缀）。所以别把带 timeout 的写法直接写死进跨平台脚本，先确认目标机器上它存在。

如果你用的工具支持钩子或规则文件，把上面这些约定固化进去，让每次生成的命令天然带非交互写法，比事后逐条抢救划算得多。

五、什么时候别再折腾了

排查这类问题有明确的止损点，越过就该换路子，硬耗只是在烧时间和额度。

**止损点一：改到第三种写法还挂。**同一条命令你已经试过官方开关、掐 stdin、加超时，还是挂——那它大概率不是”等输入”这一类，回到分层判断重新定位，别在改写上继续投入。

**止损点二：命令需要人的身份。**凡是要密码、要二次验证、要在浏览器里点授权的步骤，直接判定为不可自动化。你自己在本地跑完认证，让登录状态落到凭据存储里，再让 Agent 接着做后面的事。这不是技术能力问题，是边界问题：把凭据交互塞进自动化流程，既容易挂死又容易泄漏。

**止损点三：命令有副作用且已经跑了一半。**推送、发布、数据库迁移这类操作，如果它挂在中途，先别急着强杀。搞清楚它到底做完了哪一步——远程状态可能已经改了，重跑不一定幂等。安全顺序是：先看远程或数据库的实际状态，再决定是重跑、补做，还是回滚。

**回滚点在哪儿。**如果这次执行已经让工作区乱了（半截改动、冲突标记、临时文件），先把代码状态收干净再谈别的：

git status
git stash        # 想留着改动
# 或
git checkout -- 路径   # 确认不要了再用

工作区脏着排查，你会分不清哪些问题是命令挂死造成的、哪些是改动本身造成的。

**换条路的信号：**当你为了让一条命令非交互化写出了一串又长又怪的参数，而这条命令你自己手动跑只要五秒——那就手动跑。人机分工的合理位置是：需要判断和身份的一次性操作人来做，可重复、可脚本化的部分交给 Agent。

六、避坑清单

**坑一：拿 yes | 当万能药。**为什么会踩——它看起来能通杀所有确认，试一次成功就上瘾了。怎么避——它对危险确认（覆盖、删除、强制推送）也会一路回 y，而且只喂 y，遇到要求输入名称、路径、序号的提示照样卡住甚至填出错误值。只在你完全清楚每一个确认语义的场景用它，优先级永远排在官方非交互开关后面。

**坑二：以为 < /dev/null 一定能救。**为什么会踩——把”掐掉输入”直觉理解成”跳过提问”。怎么避——程序读到 EOF 之后行为分三种：走默认值、直接报错、继续阻塞在别的地方。所以掐 stdin 的定位是诊断手段，不是修复手段；修复还得靠官方开关或改命令形态。

**坑三：把开发服务器当一次性命令跑。**为什么会踩——本地手跑时你自己开着一个终端窗口，感觉不到它不会退出。怎么避——凡是名字里有 dev、serve、watch、start 的命令，默认按常驻处理，一律后台加日志，起完之后用读日志的方式确认状态。

**坑四：全局改掉 pager 配置。**为什么会踩——为了修 Agent 那边的挂死，顺手把 git 的分页器全局设成了 cat，结果自己看长日志时满屏刷过。怎么避——用环境变量或命令级 --no-pager 做局部覆盖，把变量放进 Agent 的执行环境，别动你自己的全局配置。

**坑五：只加 timeout 不留日志。**为什么会踩——加了超时就以为万事大吉，命令被杀掉，问题看起来”解决”了。怎么避——超时只是止血，输出必须重定向到文件，退出码必须打印。否则下一次它还会挂，你手里依然没有任何证据。

**坑六：忽略 Windows 与 POSIX 的写法差异。**为什么会踩——网上抄来的非交互写法基本都是 POSIX 风格。怎么避——先确认 Agent 起的是哪个 shell。/dev/null 在 PowerShell 里叫 $null（cmd 里是 NUL），设环境变量是 $env:VAR = 'x' 而不是 export，nohup 命令 & 那套后台化写法也没有一一对应的翻译——旧版 PowerShell 命令行末尾根本不接受一个孤零零的 &，新版虽然接受但走的是后台作业那一套语义，不是 POSIX 的 fork。如果混用，你会看到一些莫名其妙的报错，而真正的问题从没被解决。

**坑七：提示语被缓冲吞掉，误判成”没反应”。**为什么会踩——很多程序发现输出不是终端就开启全缓冲，那句 请输入： 卡在缓冲区里没刷出来，Agent 看到的是彻底的空白，于是所有人都以为是模型卡了。怎么避——遇到”零输出 + 进程活着”的组合，优先怀疑这一条；Python 脚本用 python -u 关掉缓冲重跑，提示语一般就现形了。输出侧的其他异常可以对照输出被截断的排查。

**坑八：为了不挂而关掉安全校验。**为什么会踩——主机指纹、证书校验这类提示确实会造成阻塞，关掉最快。怎么避——分清”禁止提示”和”跳过校验”是两回事：前者让失败快速暴露，后者是真的放弃了一层防护。预置 known_hosts、装好内网根证书，才是正解。

收尾：一份可以贴在手边的自检清单

这类问题的核心判断就一句：**没有报错的挂死，优先怀疑有人在等你说话。**顺着这个直觉往下查，命中率相当高。

• 输出最后一行是不是长得像提问？(y/N)、Password:、孤零零的 : 都算。
• 进程还在吗？CPU 是不是趴在零？
• 命令 < /dev/null 重跑，是立刻退还是照样挂？
• 命令 --help 里有没有 -y / --yes / --non-interactive / --no-input？
• 是不是分页器？接个 | cat 试试。
• 是不是常驻进程？改后台加日志。
• 是不是需要人的身份（密码、二次验证、浏览器授权）？是就别自动化。
• 有没有给它套 timeout、留日志、打退出码？
• 三次改写还挂？回到分层判断，别耗了。

把这套顺序跑一遍，通常两分钟内就能定性。真正值得投入的功夫不在临时抢救，而在把非交互约定沉淀进项目的执行环境里——写一次，以后所有命令都自带这层保险。