Subagent 一多电脑就卡死，先减并发还是先换机器？

先看每个子任务在本机实际启动了什么

给待并行的工作列一个清单，注明它只是在阅读资料，还是会启动浏览器、运行构建、处理图片或调用本地模型。再检查主任务是否已经运行了同类工具。子代理数量容易看到，背后启动的程序和重复工作也需要一起记录。

把彼此独立的工作与存在先后关系的步骤分开安排。例如需要等代码修改后才能开始的构建，可以等到输入稳定再运行。若多个任务正在反复读取同一份材料，就先整理共用输入，观察是否还需要为每个角色重新执行一遍。

用可重复的任务观察并发增加的影响

先单独完成一项熟悉工作，记录用时、启动的本机程序和系统资源变化，再逐步增加独立任务。每次尽量保留相近输入，观察总完成时间、交互是否流畅，以及有没有遗留进程。这样比较才更容易解释变化来自哪里。

如果卡顿集中在某个阶段，可以先把那类工作排队，让其他轻量步骤继续进行。遇到失败时先保存已经完成的结果和失败位置，再缩小任务范围重跑。根据自己的记录调整并发，比直接照搬别人设置的代理数量更容易维护。

给共享文件的修改安排清楚交接顺序

多个代理需要修改同一批文件时，先明确各自负责的范围，约定由谁整合结果、何时开始构建和验收。每一段工作结束后保存可确认的结果，交接时说明仍在运行的任务。这样也便于区分资源拥挤与互相覆盖造成的返工。

本文讨论的是如何观察自己的开发任务，没有测试 Claude Code 或相关电脑，也没有推荐某个通用并发上限。若减少任务后仍反复卡死，可以带着具体时间、进程和资源记录继续排查；是否需要换机器，应结合已经找到的瓶颈决定。

把讨论变成可检查的小任务

可以把同一个测试仓库的并发从一项逐步增到两项、四项，每轮固定任务并记录内存压力、交换使用和最长等待。出现失败时保留进程名，先检查是模型请求受限还是本机资源不足。不要把所有等待都算成 CPU 太慢。本文没有对作者设备或其他电脑做性能测试。