#WorkBuddy# 多个 AI 会话抢一台电脑：浏览器实例端口的"查名+探测"防冲突实践

#WorkBuddy# 多个 AI 会话抢一台电脑：浏览器实例端口的"查名+探测"防冲突实践

场景

我让多个 AI 会话在同一台电脑上并行干活：这个会话在跑数据采集，那个会话在发布文章，还有的在做批量操作。它们都要开带远程调试端口的浏览器实例——端口一撞，轻则实例起不来，重则 A 会话清理实例时把 B 会话正干到一半的活连带杀掉，半宿成果归零。我两种都经历过，疼完之后把防冲突做成了固定动作。

过程

踩出来的事故主要有两类。第一类是"盲占"：会话 A 看台账说某端口登记的是自己的名字，直接就用了，其实那是上次残留的注册信息，真正的监听进程还活着——两个实例挤一个端口，调试协议乱成一锅粥。第二类是"误杀"：会话 B 只知道"这个端口之前归我"，起不来就清理重开，顺手杀掉的却是 A 会话刚起的进程。

复盘之后我立了规矩：用端口必须两步确认，缺一不可。

坑一：只查台账不探测——台账会骗人

台账（登记文件）记录"谁申请了哪个端口、干什么用、常驻还是临时"，这是第一步。但台账是手动或脚本写入的静态数据，进程崩了没注销、实例被外部杀掉没来得及更新，台账就与现实脱节。所以第二步必须实测：对目标端口做 TCP 探活，连得上=有进程在监听，连不上才算真空闲。探活只测监听、不发业务请求，零副作用。

坑二：只探测不查台账——空端口未必能用你

反过来也不行。探测发现端口空闲就上手，可能撞上两件事：一是这个端口属于预留段（给特定常驻用途锁死的），占了当下没事、下次真正的主人来了互相打架；二是有些端口有固定用途约定，随口占用会破坏别人的自动化假设。台账说"允许用"，探测说"真的空"，两个条件同时满足才能动手——这就是"查名+探测"。

坑三：算占用要算上"相关进程"

还有个隐蔽坑：判断端口是否可用时，只看监听还不够。有的实例虽然监听进程刚死，但它的一串子进程/工作进程还活着，这时候复用端口，新旧进程混在一起排查起来极其痛苦。我们的分配器后来把"活着的同类进程"也计入占用，宁可多等一轮分配新端口，也不在尸体旁边开工。

总结

把这套实践压缩成三条军规：

1. 先查名再探测：台账确认资格，探活确认现实，缺一不可；
2. 用完必注销：实例关掉的同时更新台账，别让下一班人读到的全是过期情报；
3. 占用判定宁严勿松：监听进程、相关子进程、预留段，都算占用；冲突的代价远大于多探测一次的成本。

附上实测用到的关键命令和探活脚本，可直接复制：

:: 第一步: 探测端口是否有监听
netstat -ano | findstr LISTENING | findstr :9511

:: 第二步: 有监听时, 用 PID 反查是谁(避免误杀别人的活)
tasklist /FI "PID eq 21408"

:: 第三步: 脚本化探活(零副作用, 只测监听)
python -c "import socket;s=socket.socket();s.settimeout(0.5);print(s.connect_ex(('127.0.0.1',9511))==0 and 'BUSY' or 'FREE')"

共享机器上跑多个 AI 会话，"我以为没人用"是所有事故的开头——查名加探测，一句话的事，省的是半宿白干。