用pi agent时会出现一条指令卡很久的现象，可能有哪些原因呢？

@群友 1463 你这条刚问过，前面那条长回复应该已经发出去了；没收到的话我再给一遍精简版，同时补个可验证的来源。 核心思路还是先分「在算」和「在等」：看 pi 进程 CPU 有没有在动、流式 token 还来不来。CPU 贴 0 又长时间不冒字，就是在等 IO。 工具层最常见。pi 的 bash 工具没有默认超时，只要跑了一条不退出或者等 TTY 的命令（vi/vim、top、watch、fzf、各种 repl），这一轮就永远等下去，不是慢，是等不到。另外 write 大文件会超时、MCP server 或扩展卡在启动握手时，整个 turn 会停在工具调用之前。 模型/provider 层：流本身没有 idle 超时，响应头回来了事件不来就一直挂着（pi-agent-core 的 issue #5778 报的就是这个，hang indefinitely on unresponsive streams）。会话中途切 provider 也可能把 loop 挂死，官方仓库 #3258 记过一个 GLM-5.1 和 Gemini 互切之后 RPC 完全无响应的情况，只能重启进程。还有配额/限流那类，特征是完全没有报错，纯不动。 扩展和上下文层：自己写的扩展边界情况下死循环会 CPU 常驻近 100%；扩展装太多；agents.md 引用了已经不存在的旧文件也会卡在解析上（Reddit 那帖的楼主就是修好 agents.md 才恢复）。 排查顺序：先 Esc 中止这一轮，看它停在哪一步工具调用，那一步基本就是元凶；然后禁用 extensions / skills / MCP，换个 provider 跑最小环境，换 provider 就不挂是 provider 问题，只有挂上某个扩展才复现就是扩展问题；已经是切过 provider、压缩过好几轮的会话，直接开新会话比抢救划算。 想深入看机制可以搜《Pi Agent 长任务处理：从工具超时到会话恢复的六层机制》，讲得比较细。 你如果能说一下卡的时候具体是什么状态——有没有流式输出、停在哪个工具、什么 provider、装了什么扩展——我可以帮你把范围缩到更窄。