我的 agent 前台被批量举报了：顺手拆出一个 uv 进程幻影
摘要 ：agent 前台因发送节奏过于规律被批量举报，修复后排查进程列表时又发现"双开"假象------真相是 uv 虚拟环境里的
python.exe只是启动器壳，真正的解释器以子进程形式运行，导致按进程数判断的逻辑永远误报。本文记录了两次修错的过程，并给出按进程树而非进程数判断的通用修正思路。
一、先认个错
那天早上我打开后台，发现自己那个跑在浏览器里的 agent 前台发出去的评论少了一大片。提示很干脆：该评论已被作者删除。
我第一反应是文案烂。改词、换句式、让模型每次生成不一样的开场------折腾一晚上，第二天又被删三条。
然后我把四十条发送记录按时间戳排了一遍：间隔稳定在 11~14 分钟 ，最后一条发在 凌晨 00:12。
一个人不会在半夜十二点给三天前的视频写一百二十字真诚好评，更不会连续六小时每十一分钟一次、误差不到两分钟地做同一件事。作者点进我主页，看到同一句式出现在七个视频下面，一次性全点了举报。
批量举报不是因为某一条写得差，是节奏一眼暴露了你不是人。
修复就三行字的事：日限额 40 → 8，间隔固定 → 随机 60~150 分钟，全天 → 只在 10 点后发。文案侧加了一个黑名单函数，产品名、"我主页"、"欢迎交流"、引流动词全部拦掉，宁可不发。对照组里活下来的两条留言，通篇是开发心路（卡住→绕过去→突然通了），一个推销词都没有。
这部分没什么好展开的。真正值得写的是修完之后撞上的第二个坑------我差点为了一个根本不存在的 bug 重构整个守护逻辑。
二、"双开"
前台由一个 vbs 守护脚本拉起：进程没了就重启，日志里写一行"已上岗"。某天我查状态，进程列表里躺着两个 frontdesk 的 python 进程：
arduino
wmic process where "name='python.exe'" get ProcessId,CommandLine两个 PID，两条一模一样的命令行，都指向 frontdesk.py。共享同一份日志、同一个去重文件。
我第一反应：守护逻辑炸了，双开了。准备动手改 vbs 加单例锁。
手已经放在键盘上了，我多做了一步------把父子关系也拉出来：
arduino
wmic process where "name='python.exe'"
get ProcessId,ParentProcessId,CommandLine /format:csv结果两个进程互为父子。
不是双开。日志里"已上岗"从头到尾只出现过一次，也是这个原因。
三、uv 的 venv 里，python.exe 不是解释器
这是整件事最冷的知识点：用 uv 创建的虚拟环境，venv\Scripts\python.exe 根本不是 Python 解释器，它是一个壳（shim / launcher）。
传统 venv 你会默认 Scripts\python.exe 就是解释器本器。uv 不这么干。它的流程是：
- uv 自己管理解释器，真正的 CPython 装在
AppData\Roaming\uv\python\cpython-3.11-...\python.exe； - venv 里那个
python.exe只是一枚极小的启动器，职责是读pyvenv.cfg、定位 base 解释器； - 启动器 spawn 一个真解释器作为子进程，把参数原样递过去，然后自己退出。
所以在任何时刻抓进程表，你看到的"一个 python 程序"其实是父子两个 python：父进程命令行是 venv 路径，子进程命令行是 Roaming\uv 路径，跑代码的是儿子，爹还挂在那儿。
我的守护脚本按命令行匹配进程数，于是永远数出"两个"。
鉴别方法，一句话：看父子。
| 现象 | 真双开 | shim 幻影 |
|---|---|---|
| 两进程关系 | 互不为父子 | 父=venv python，子=Roaming\uv python |
| 初始化日志 | 出现两次 | 只出现一次 |
| 内存/句柄 | 各持一份锁 | 只有子进程真正持有 |
杀进程也有讲究：只杀爹，儿子变孤儿继续跑，你以为杀干净了；只杀儿子，爹退出触发守护脚本"进程异常"分支，又拉起一套。正确姿势是把父子两个 PID 一起杀：
bash
wmic process where "name='python.exe'" get ProcessId,CommandLine /format:csv \
| grep frontdesk.py | sed 's/.*,//' \
| while read p; do taskkill /f /pid $p; done杀完守护脚本十秒内自动拉回单例，干净。
四、这个坑的通用价值
不止 uv。Windows 上"启动器 + 真身"的进程结构到处都是：py launcher、某些 Node 全局包、包管理器的 trampoline。任何按进程数量做判断的逻辑------单例锁、监控告警、"重复实例检测"------都会被这类壳误报。
写法的修正方向只有一个：按进程树判断，不按进程数判断。 拿到候选 PID 集合后先看 ParentProcessId，能约成父子的算一个实例；再配合"初始化日志只出现一次"做交叉验证。
我差点给一个不存在的 bug 加锁。锁加上去，真双开的那天反而会被这个假锁逻辑坑死。
五、两次修错
回头看，这次翻车最狠的地方是我修错了两次：第一次以为文案烂，第二次以为进程双开。两个错误方向，都因为我没先看数据就动手------没排时间戳，没查父子关系，全凭直觉。
agent 最容易骗自己的地方就在这儿：它每天替你干活，于是你默认它坏的时候，也一定坏在你猜的那个地方。
下篇想聊一个更阴的：当 agent 前台开始自己写文案、自己判断该在哪个视频下面留言，它是怎么一步步把"我在测试"这句话真的发出去的。