同时运行多个 WorkSwarm 智能体时，CPU 和内存占用持续偏高，直接判断是“哪个智能体拖累资源”很容易出错。建议先按进程身份把 WorkSwarm 的智能体从系统进程里分离出来，再采集一段稳定运行数据作为基线，配合业务日志定位峰值触发点，最后通过调整并发数验证改动效果。这一套方法只依赖 ps、top、pidstat 和日志文件，不需要额外安装探针。

场景判断：当多个 WorkSwarm 智能体共用一台服务器时，如果 CPU 或内存持续走高、任务响应变慢，先不要直接调低所有并发数。用 ps 按命令行区分各智能体进程，再用 pidstat 每 10 秒采样，记录 CPU、内存、IO 基线；把日志时间戳和资源曲线对齐，找到具体任务触发点；最后按 2、4、8 三组并发数依次实验，观察响应时间和资源占用。整个判断基于进程监控和日志对照，不依赖 WorkSwarm 内部调度算法。若进程无法按命令行区分，或日志没有时间戳，则需要先补充可观测性信息，否则实验结论不可信。

先确定WorkSwarm智能体对应的进程身份

WorkSwarm 的智能体可能会以 python、node 或专用二进制形式运行，不能只看进程名。用 ps 全命令行过滤可以避免把同名的系统进程混进来。例如：

ps -eo pid,ppid,%cpu,%mem,cmd | grep -i workswarm

如果智能体是通过脚本启动的，可以先用启动脚本或 systemd 单元里的命令行参数来确认。一个智能体对应一个 PID，后续采样就以这个 PID 为对象。若在输出里看到多个 PID，可以按 cmd 列中的 agent-id、agent-name 或工作目录区分。如果启动命令里没有唯一标识，需要通过进程的启动时间或父进程 PID 来甄别。注意，不要直接用 grep 匹配“agent”或“worker”，容易混入其他项目进程。先用 WorkSwarm 安装目录、配置文件路径或端口参数缩小范围。必要时可以重启一个智能体，观察 PID 变化来确认对应关系。

采集CPU、内存、IO时的基准曲线

建立正常基线要选在业务相对平稳的时段，连续采集至少 10 个采样点，而不是只看瞬时值。用 pidstat 每 10 秒采样一次，可以同时看到 CPU、内存和磁盘读写。以 PID 为 12345、12346、12347 的三个智能体为例：

pidstat -p 12345,12346,12347 -u -r -d 10 6

上面命令每 10 秒输出一次，共 6 次。输出中会包含 %CPU、RSS 和 KB_rd/s、KB_wr/s 等字段。由于不同系统 pidstat 的列位置略有差异，先运行一次不带参数的 pidstat 确认列顺序。记录每个智能体稳定后的 CPU 均值、内存占用量和磁盘读写。同时用 free -m 观察系统总内存，用 vmstat 看 swap 和 CPU 队列。这里的关键点是：如果某个智能体频繁产生 IO，单独看 CPU 高不一定能定位，要结合磁盘读写列。

为了说明采样结果，这里给出一个示意输出，数值不对应任何真实环境：

10:00:01  12345  12.3  1.2  13.5  8.0  0.0  0.0  12.0
10:00:01  12346  42.1  3.4  45.5  10.0  0.0  2.0  5.0
10:00:01  12347  8.9  0.8  9.7  5.0  0.0  0.0  0.0

连续记录 10 次后取平均值或中位数，作为“正常”参考。如果业务有明显的波峰波谷，需要分别记录两个时段，避免把高峰误判为异常。基线本身不是固定值，而是相对值，后续调整并发数后的数据要和同一时段的基线对比。

关联业务日志定位资源消耗峰值

资源曲线只能说明“什么时候高”，不能说明“为什么高”。把 pidstat 的采样时间戳和 WorkSwarm 业务日志的时间戳对齐，就能看出 CPU 飙升前发生了什么任务。先确保两份文件的时间格式一致，例如都转换成 Unix 秒。假设性能数据在 perf.log，每行第一列是时间戳、第二列是 PID、第三列是 CPU 使用率；业务日志在 app.log，每行第一列是时间戳、第二列是任务 ID、第三列是任务类型。用 awk 可以按时间点关联两个文件：

awk -v thr=70 'NR==FNR {
  # perf.log: 列1=epoch秒, 列2=PID, 列3=CPU%
  if ($3+0 > thr) hot[$1]=1;
  next
}
{
  # app.log: 列1=epoch秒, 列2=任务ID, 列3=任务类型
  if (hot[$1]) print $1, $2, $3;
}' perf.log app.log

如果两个文件的列顺序不同，需要先调整 awk 的字段读取。若时间戳包含日期而不是 epoch 秒，可以在采集时用 date +%s 生成时间戳，或者用 date -d 预先转换。有时日志时间与采样时间有秒级偏移，可以按最近邻匹配，例如把日志时间取整到 10 秒，再与采样时间对齐。这个步骤的目标是找出“CPU 超过 70% 的时刻落在哪类任务上”，而不是每条日志都匹配。

按实验调整智能体并发数并复测

找到峰值触发点后，需要验证调整并发数是否有效。WorkSwarm 的并发数通常在配置文件或启动参数里，比如 max_agents、concurrency 等。修改前先备份当前配置，并把系统恢复到一个稳定的初始状态。设计三组实验：并发数设为 2、4、8，分别运行同一批固定任务，用第二节的 pidstat 命令重新采集，同时记录每次任务的响应时间（从提交到完成）。每组的运行环境尽量一致，避免混入无关任务。

建议每组实验至少运行 10 分钟，让资源数据稳定。记录格式如下表，数值留空，在实验中填写：

选值依据：如果响应时间满足业务要求，并且 CPU、内存仍有 20% 以上余量，可以取当前最大并发数；如果 CPU 接近 100% 或响应时间明显变慢，则降一档继续复测。每次修改并发数后，需要重启 WorkSwarm 或触发配置热加载，再等待 5 分钟让任务队列稳定，然后开始采样。注意，并发数还会受到任务类型、外部依赖延迟影响，所以实验结论只对当前机器和当前任务有效。如果换了任务或增加机器，需要重新跑一遍。