最近我手头常开着五个 AI 编程 Agent——Cursor 的 Composer、Claude Code、Codex CLI、Aider、Continue——来回切换处理不同仓库的活。多 AI 协作听起来很爽，但真正的问题不是谁好用，而是：我坐在那看五块屏幕，到底哪个在等我喂下一句，哪个在默默跑测试，哪个其实已经卡死了？
“同时开五个 Agent”这件事，听着很极客，真做起来其实是场灾难。因为每个 Agent 自己的聊天窗口都长一个样：没有光标闪烁，没有“我在等你”的明确提示，输出可能几秒钟不动，然后突然哗啦哗啦吐出一大段。你要是猜错了状态，要么在一个已经死等的 Agent 面前干耗十分钟，要么在一个正在跑任务的 Agent 后面又补一句指令，把它当前的工作彻底打断。
这篇东西不是科普“Agent 框架怎么选”，也不是吹哪个 AI 编程工具好用。我打算从“如何判断哪个在等你”这个小切口，把多 Agent 并行开发里真正值得做的事情捋一遍：怎么用进程、输出日志、终端状态、API 调用记录这些底层信号判断 Agent 的真实状态，以及我实操下来觉得靠谱的几个管理土办法。适合正在折腾多个 AI 编程 Agent、同时管好几个任务的开发者，尤其是那种一开就收不住、最后自己变瓶颈的人。
1. 先搞清楚：所谓“在等你”到底指什么
1.1 等待状态分三种：真锁死、在思考、等你决策
我一开始以为“等待”就是字面意思：Agent 停下来，等你打字回车。后来发现完全不是。同一个“没动静”的窗口，背后至少藏着三种完全不同的状态。
第一种是真锁死。进程还挂着，但内部已经出了异常——比如调了一个不存在的工具、解析输出卡进死循环、会话上下文爆掉导致请求永远发不出去。这种状态你等多久都没用，必须强制终止或者重开会话。
第二种是在思考。Agent 正在调模型接口，或者正在等某个工具执行完，比如它是真的在等你提供东西，但它这个“等你”被包装成了“继续干活”的假象。
第三种才是真正的“等你决策”。Agent 在输出里抛出了问题，比如“这个函数你希望用同步实现还是异步实现？”“这个接口返回格式我拿不准，你来定一下”，然后停在那里等你输入。这种等待是你最不应该错过的——因为整个链条里，只有你替代不了，其他的等待都可以靠配置或耐心解决。
为什么要把“等待”拆细？因为不同状态的应对策略完全不同。真锁死要杀进程，思考中要等，等你决策要赶紧给答案。如果你只会看“有没有输出”这一个信号，必然翻车。
1.2 Agent 的“等待”和传统编程工具的等待不是一个量级
传统 IDE 的等待很简单：编译在跑就是进度条，跑完了就是绿勾，停在断点就是等你。你永远不会把“编译中”误解为“等我操作”。
AI 编程 Agent 不一样，它本质是一个基于上下文循环的程序：读输入、调大模型、拿返回、执行工具、把结果塞回上下文、再调大模型……这个循环里任何一个环节都可能阻塞，而且阻塞的原因五花八门。
我自己用 async 编程的经验做了个类比：传统工具是同步阻塞，调一个函数就知道当前要等什么；Agent 是异步事件循环，表面上它“活”着，但很可能在等某个永远不会来的事件。这也是为什么很多人管理 Agent 时总觉得不对劲——你没法像看普通进程那样一眼看出它卡在哪个环节。
更麻烦的是 Agent 的“思考”普遍是流式输出。大模型生成 token 是一个一个蹦出来的，终端里表现为一段文字慢慢出现。但如果你用的是不支持流式输出的接入方式，或者命中缓存之后生成速度特别快，你看到的可能是一大段瞬间刷完，然后长时间不动——这其实是“大量的请求-响应”过程中正常的停顿，不是死等。
1.3 多开之后，“等待”为什么特别难判断
单开一个 Agent 的时候，状态判断压力不大：反正只有它一个，等就是了。但五个同时开，问题就变了。
首先，你的视觉注意力被分散。五个窗口你不可能轮流盯死，往往看一眼没输出就划走，真正的“等你输入”反而被淹没在正常停顿里。
其次，多 Agent 并行通常意味着每个都在处理不同的异步任务。A 在编译大型项目、B 在重构代码、C 在写测试、D 在等模型响应、E 在等你拍板——如果你没有一套统一的信号系统，全靠肉眼看窗口滚动，基本就是开盲盒。
我试过一段时间在五个终端标签页之间来回切换，用余光观察“哪个动了”。结论是：人类根本不适合做这种任务。你的注意力切换成本远高于 Agent 的计算成本，最后累死的是你自己，不是机器。
所以核心问题不是“怎么让 Agent 不等待”，而是“怎么让等待状态变得可见、可查询、可报警”。下面要讲的都是围绕这个目标展开。
2. 多 Agent 协同的第二战场：终端、IDE、远端
2.1 五种常见 Agent 形态：CLI、IDE 插件、编辑器原生
先盘点一下常见的 AI 编程 Agent 形态，因为形态直接决定你能从哪一层观察它的状态。
CLI 类最常见，Claude Code、Codex CLI、Aider 都是这一类。它们的共同点是：一个独立的终端进程，有自己的 stdin/stdout，交互方式是命令或者自然语言对话。这类 Agent 状态最好观察，因为进程模型清晰，有真实的 PID，有标准的输入输出流，日志也可以重定向到文件。
IDE 插件类，比如 Continue，通常跑在 VS Code 或者 JetBrains 里。它不是一个独立进程，而是编辑器的扩展，你可能要在扩展的输出面板里才能看到日志。这类 Agent 能访问编辑器的文件系统、光标位置、选中文本，但它的“状态”藏得比较深，需要借助 IDE 的日志系统。
编辑器原生的，比如 Cursor 的 Composer/Agent 模式。Cursor 背后往往是独立进程在处理任务，但 UI 层完全在编辑器内。好处是它的运行状态有内置的可视化提示，比如任务进度、文件修改列表；坏处是你很难把它和普通的编辑器操作区分开，有时候你以为 Agent 在干活，其实是你在乱按导致的索引重建。
形态决定了你至少要从两个层面做观察：进程层面（PID、CPU、IO）和会话/日志层面（输出流、会话历史、状态文件）。
2.2 建立统一的可观测视角：日志、进程、会话文件
我在实际工作中把“多 Agent 状态判断”做成了一个三件套：
第一套是统一的日志目录。我给每个 Agent 项目建一个logs/目录，并把 CLI 的输出用tee或者直接重定向进去。比如 Aider 本身有--log参数，Claude Code 在 verbose 模式下会打出非常详细的步骤日志，Codex CLI 支持--output-format结构化输出。没有内置日志的，我就用终端重定向：启动命令加上2>&1 | tee log.txt。这样至少每个 Agent 都有一个“最终历史输出文件”可以查。
第二套是进程列表。每个 Agent 启动后我都会在 tmux 的窗口标题里记下 PID 和启动时间，然后每隔一段时间用ps -o pid,stat,etime,cmd扫一遍。这一步已经能发现大部分“假死”问题，下面会详细展开。
第三套是会话文件。CLI Agent 基本都会把多轮对话存到本地目录，比如 Claude Code 的~/.claude/projects/，Codex CLI 的~/.codex/sessions/，Aider 则在项目目录里写.aider.chat.history.md。这些文件不仅能看聊天内容，还能看到最后一条消息的时间戳——这是判断“是否在等你”的关键证据。
2.3 命名、隔离、切分：给每个 Agent 一个“独立网格”
五个 Agent 都在同一个大仓库里乱干，那出问题根本不是判断状态的问题，是代码互相覆盖的问题。我现在的做法是按任务切分支、按分支开独立目录，给每个 Agent 一套互不干扰的环境。
具体来说，我会用 tmux 开五个窗口，每个窗口的标题写成[v0.6.0] claude-code这种格式，对应的目录是/workspace/agent-a、/workspace/agent-b。所有输出日志都写在各目录自己的logs/下。这样我只看文件名，就知道哪个 Agent 属于哪个任务、状态文件是哪一份。
隔离还有一个隐藏好处：如果你发现某个 Agent 卡死了，可以直接把这个 tmux 窗口杀掉重启，而不会影响其他四个 Agent 正在运行的进程。如果不做隔离，五个任务共用一个终端或者一个进程，一个挂全挂，排查起来血压直接拉满。
3. 实操：五个信号灯帮你判断“真等待 vs 假死”
3.1 信号一：进程的 CPU 占用和 IO 状态能说明什么
很多人以为“CPU 高 = 在干活”，这在 AI Agent 场景里经常是错的。
大模型请求本质上是网络 IO，Agent 调用远端模型接口时，本地进程基本不占 CPU，处于睡眠等待网络返回的状态。所以你看到 CPU 很低，完全可能是“正在等模型”，不是死等。反过来，CPU 很高的情况，往往发生在 Agent 在做本地计算：编译打包、跑测试、解析大量输出、做语义索引、启动本地模型推理。比如我用 Ollama 跑本地模型的时候，CPU/GPU 会明显拉高，那是 Agent 在“思考”的表现，不代表它卡住。
所以我说的第一个信号，不是“CPU 高不高”，而是“CPU 状态和预期任务是否匹配”。如果当前任务是重构代码，CPU 应该主要花在编辑和模型调用上，低 CPU 大概是等待；如果当前任务是跑测试，CPU 就该上去，它还在那低着，八成是卡在某个同步等待上了。
用 Linux 的话，可以看ps -o pid,stat,%cpu,cmd里的 STAT 列。R表示正在跑，S表示睡眠，D表示不可中断的 IO 等待，T表示被停止。Agent 等待网络响应时通常显示S，这没问题；要是长时间D，那基本是 IO 异常，可能是网络盘挂死、文件锁没释放，这种情况等再久也没结果。
3.2 信号二：最后输出时间戳和滚动日志
肉眼盯终端永远不可靠，我用的是“每分钟看一眼最后修改时间”的简单办法。
把每个 Agent 的日志重定向到独立文件后，用tail -n 20 log.txt配合stat -c %Y log.txt查看文件的最后修改时间。如果某个日志已经 10 分钟没变，并且最后一行不是自然的段落结尾，那大概率进入异常状态。
我踩过的一个坑是：流式输出时，日志文件可能在很短时间内频繁更新，然后突然长时间静默，这是大模型生成完成后，Agent 在内部做函数调用、工具调用、代码写入，这个阶段可能完全没有任何 stdout 输出。如果单靠“日志最后修改时间”判断，会把一个正常工作的 Agent 误判为卡死。
解决办法是同时看 Agent 的活动痕迹：这 10 分钟里它有没有创建、修改过项目文件？如果有，它就是在做“静默阶段”的工具操作；如果连文件系统都没有动静，那就要怀疑真卡住了。
3.3 信号三：终端输出流的“吐字节奏”
这一条靠经验。流式输出有节奏，大模型生成 token 的速度相对稳定，通常是一行一行慢慢冒出来。如果你发现一个 Agent 在正常输出中，突然停在句子的半截，既不继续也不结束，而且持续超过两到三分钟，那通常不是“思考中”，而是流卡住了。
卡住的原因一般是模型服务端异常、API 超时没有触发重试，或者本地代理把请求挂起了。这时候你按几下回车或者发一个空指令，大概率也不会得到响应，因为它根本没在监听 stdin。
反过来，如果输出流已经完成了一个完整段落，然后停顿，但终端能正常接受输入，这才是真正“等你决策”。最简单的测试方法是按回车，发送一个空行。大多数 CLI Agent 会把空行当作“继续/确认”的信号，如果按完之后有新的输出，说明它还活着且等待输入；如果按了没反应，就要重点怀疑了。
3.4 信号四：Agent 的心跳和状态文件
这是最符合工程思维的一招：让 Agent 自己报告状态。但现实是，大部分 Agent 没有内置的心跳机制，所以只能自己做。
我现在的做法是在每个 Agent 的独立目录里放一个status.md文件，里面约定一段简单的格式，比如“当前任务、进行到哪一步、等什么”。在 Prompt 里告诉 Agent：每个阶段完成之后，更新一下这个文件。虽然会多消耗一些 token，但它带来的收益极大——你只要cat status.md，就知道这个 Agent 是不是在等你回答，而不是靠猜。
有一些 Agent 自己带状态查询命令。Claude Code 有/status，Aider 有/help之外的对话指令，Codex CLI 有交互模式下的状态指示。但要注意，这些状态通常是会话内部的视角，不一定能反映底层进程的健康度。所以我更倾向于“外部状态文件 + 进程信息”组合，两者交叉验证。
3.5 信号五：LLM API 调用日志
如果你用的是自建网关、统一代理，或者能在本地记录 LLM 请求日志，那这简直是上帝视角：每一条 API 调用的开始时间、结束时间、token 用量都一清二楚。
我把五个 Agent 的流量都指向同一个本地转发层，转发层里记录每次请求的时间。这样我一眼就能看到：Agent A 上次请求是在 3 分钟前，说明它还在等模型返回；Agent B 上次请求是在 20 分钟前，说明它要么在等你，要么卡了；Agent C 的请求频率忽高忽低，说明它处于工具调用阶段，task 循环正常。
如果你的模型走云端 API，没有自建网关，也可以退而求其次，看项目目录里的会话文件，比如 Codex CLI 的 session JSON 里包含每条消息的 timestamp。看最后一条消息的方向很有价值：如果最后一条是 assistant 发出的，下一步大概率是等用户输入；如果最后一条是 user 发出的，那它应该还在干活。
4. 从判断“等待”到管理“多 Agent 并行”：几个不成熟但有效的土办法
4.1 给每个 Agent 一亩三分地：独立目录、独立分支、独立终端
多 Agent 并行最大的悲剧不是判断状态，而是两个 Agent 同时修改同一个文件，然后互相覆盖。我试过 C 在写 test，D 在重构实现，结果 D 直接把 C 的测试文件当成旧代码清理了，C 那边还一脸无辜地在等反馈。
现在的规矩很硬：“一个 Agent 一个分支 + 一个独立目录”。如果任务必须改同一份代码，那就用 git worktree 拉出不同版本的目录，互不干扰。终端也分开，tmux 窗口之间几乎不共享任何上下文。
这样做的好处不仅在于代码安全，还在于状态判断更清晰：每个 Agent 目录里都有一份自己的状态文件、日志文件和会话历史，你想知道它在干嘛，进它自己的工作区看就行，不用在一个大仓库里翻各种混淆的记录。
4.2 超时与提醒：让人而不是机器去盯屏幕
盯屏幕这件事，机器比人强。我在做法上很简单：写一个轮询脚本，每 30 秒扫一遍各日志文件的最后修改时间，如果某个日志超过设定阈值（比如 3 分钟）没更新，就输出一条提醒到一个汇总面板里。
汇总面板用 tmux 下方的小窗格显示，一行一个 Agent，格式就是“Agent名：状态/最后修改时间/最后一行摘要”。这样我不需要开五个窗口盯，只需要偶尔瞟一眼汇总，哪个需要处理一目了然。
提醒不能做得太频繁，否则会产生“狼来了”效应。我实际调了几次阈值之后，标准做法是：按任务类型分两档，跑大编译的日志阈值放宽到 10 分钟，普通对话场景 3 分钟就行。
4.3 每个 Agent 一个滚动日志，用 tail 或 multitail 统一查看
这是低成本高回报的配置。启动 Agent 时把输出重定向到日志文件，然后开一个multitail或者写一个小脚本tail -f多个文件。虽然有点朴素，但比在几个终端之间切来切去舒服多了。
更关键的是，日志文件要区分“会话信息”和“调试信息”。可以把 verbose 级别的信息打到单独文件里，正常对话级别打到另一个文件。我一般只 tail 正常对话级别，发现异常才会去翻 verbose 日志，避免刷屏刷到看不清。
还有个细节：日志文件命名要带 Agent 名和时间戳，比如claude-code-branch-log-0201.log。不然多开几天之后，面对一堆log-1.log、log-2.log，光是找文件就能气死。
4.4 定时送“活性探测”指令
有些 Agent 卡死之后，你正常发任务它不理你，但如果你按回车、发送空行，它有可能会被唤醒，或者至少给出错误提示。这听起来很傻，但确实有用。
我在某些场景下会写一个循环脚本，每隔一段时间往 Agent 的 stdin 发送一个空行或者查询命令，比如 Claude Code 的/status。如果 Agent 活着且在等你，它会有响应；如果活着但是正在跑任务，它可能会忽略或者排队处理；如果已经死锁，它可能连空行都不响应。
但要注意，这个方式有风险：某些 Agent 会把空行当成“继续当前操作”，你如果不想让它继续干活，可能反而会触发一次它还没准备好的行为。所以这个“活性探测”更多用于“判断真死假死”，而不是常规心跳。
4.5 控制并发的真正关键：把自己从循环里抽出来
这可能是最重要的一条经验。多开 Agent 之后，原本应该是“人指挥，Agent 干活”，但实际操作里经常变成“Agent 等你，你被五个 Agent 来回使唤”。
你会发现，自己变成了整个并行系统的瓶颈。五个 Agent 每个 3 分钟问你一个问题，看起来每个等你的时间都不长，但合在一起你的注意力就被切成了碎片。往往刚回复完 A 的决策，B 的输出就刷出来了，你又要切过去处理，中间还会漏掉 C 的请求。
所以我后来给自己定了个规矩：同一时刻最多三个 Agent 是需要我主动决策的，其余两个要么是纯自动化任务，要么就明确告诉它“方案你自己定，最后向我汇报”。把需要人类决策的节点尽量压缩，并行度反而上去了。
5. 常见问题与排查技巧实录
5.1 现象：CPU 100% 但是终端没输出，是不是在等我？
不是。终端没输出 + 高 CPU，大概率是 Agent 正在做面向本地的计算，比如编译、测试、代码索引、本地模型推理。这种情况不用管，更不要往终端里发新指令。你需要确认的是它到底在做哪件事：翻一下项目目录里的文件修改时间，或者直接看进程的子进程列表，比如pstree -p <agent_pid>，能看到它在跑gcc、pytest还是node，一目了然。
5.2 现象：Agent 停在大模型请求阶段，既不输出也不报错
最常见的原因是上游模型接口慢，或者多路请求被限流。我之前遇到过同网关下五个 Agent 同时请求，触发限流后，有的 Agent 在做指数退避重试，这个阶段完全没有输出是正常的。判断方法是看 API 日志：如果请求还在（未被服务端返回），那就在等，可以放宽阈值；如果请求已经报错、但 Agent 没响应，多半是重试逻辑写得不健壮，要手动干预。
5.3 现象：两个 Agent 同时改同一个文件，怎么避免？
我现在的做法是：文件级别加“任务锁”——在项目目录里放一个agent.lock文件，Agent 开始改动前先检查锁文件，如果是别人持有就暂停。虽然 Agent 不一定会严格遵守，但至少我在 prompt 里明确写过多次之后，大部分情况下它们会先检查。更保险的是用 git worktree 做物理隔离，不同的 Agent 根本看不到对方改到一半的文件。
5.4 现象：“token 还没用完”是不是意味着一切正常？
不一定。token 剩余多少只能说明预算，不能说明状态。有过几次，Agent 明明 token 富余，但对话上下文已经太长了，超过模型窗口之后发送请求失败，Agent 就在原地站桩。这种问题靠“token 多少”是判断不出来的，要看会话文件里的上下文长度和最后请求的报错信息。遇到这种情况，最干净的办法是开新会话，把关键需求用简洁的方式重新描述一次。
5.5 现象：异步子任务卡死，但主进程还活着
某些 Agent 会用后台子任务执行操作，主界面看起来正常，但子进程已经僵死。你按回车它也有反应，你发指令它也说“好的”，但隔一段时间看，发现它什么都没干。排查方法：看子进程列表，发现有一个sleep infinity或者类似的僵尸进程挂起，直接kill掉那个子进程，主进程通常会重新同步状态。如果 Agent 不自动恢复，那就是它的内部状态机坏了，需要重启会话。
5.6 一个经验：把“等待”判断写进工作流，而不是靠临场反应
多 Agent 或者多任务协作，最忌讳的就是没有制度、全靠现场发挥。我现在会把“谁来更新状态文件”“多久汇报一次”“什么情况必须等我”这些规则，直接写进初始 Prompt，让 Agent 从一开始就按规范工作。虽然偶尔有 Agent 不听话，但大部分时候效果极好，至少比每次都靠猜强得多。
最后再分享一个我实际用下来最省心的组合：每个 Agent 独立目录 + 独立 tmux 窗口 + 滚动日志 + 状态文件 + 超时提醒脚本。这套配置不需要什么高级工具，但能让“同时开五个 AI 编程 Agent”这种看起来很乱的事情变得可控。核心思路就一句话：别靠肉眼判断它是否在等你，把“等待”变成一个可以查询、可以报警、可以记录的工程指标。你省下的注意力，才是多 Agent 并行真正赚到的东西。
