最近我手头常开着五个 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结构化输出。没有内置日志的我就用终端重定向启动命令加上21 | 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 场景里经常是错的。大模型请求本质上是网络 IOAgent 调用远端模型接口时本地进程基本不占 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 有/statusAider 有/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 在写 testD 在重构实现结果 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 并行真正赚到的东西。