10 月日本网站连环泄露自救：我用 Grok Bot 和本地 Agent 洗掉了 100 多个账号的真实信息

背景

日本网站在信息安全方面的草台班子程度，根本无法想象。进入 10 月个人信息泄露新闻越来越密，几乎每天都能刷到一条。（ITmedia 统计，10/6 到 10/19 这两周，主要的泄露事件就达到了疯狂的 33 起）

只要实际体验过大模型在逆向和自动化处理上的能力，对于这样的结果也不算意外吧，AI 的发展像是给每个人手里都发了一把 AK47 一样，以后类似的泄露事件可能会越来越频繁。

打开自己的密码库盘点了一下，大量日本网站账号（100~200 多个）都是临时注册的。因为一直用 1Password，Bitwarden 之类的密码管理器，每个网站都是独立的随机密码，密码撞库我倒是不担心。真正麻烦的是账号里留的个人资料，绝大多数填的都是真实信息，外加住过的真实地址，有些还绑着信用卡。记得两年前我还跟朋友讨论过类似的问题，我说日本每个线下的业务都要求提供真实身份信息，线上一旦泄露就很难完全脱身，结果完全被我说中了。

既然挡不住网站那边被攻击拖库，我唯一能做的自救就是去把这些“临时”账号里的个人资料清洗掉：

• 把姓名、住址和电话改成一套提前准备好的“替身人设”
• 把登录邮箱统一换成专门给 bot 用的收件箱
• 删掉绑定的信用卡、解除第三方账号关联
• 顺手关掉营销邮件订阅，再把每个网站是否能退会，退会入口链接记下来留底

提示

为什么不直接申请退会或者注销而选择清洗个人资料？

很多日本网站即便退会，历史数据可能仍然保留在网站后台。一些“数据保留政策”也会要求网站保留用户信息一段时间或者干脆只做“软删除”。因此，清洗个人资料比单纯退会更直接有效。

这些网站，每个都要登录、找会员资料修改页、收发验证码、改表单再写回 Bitwarden，人力操作是不可能的。

刚好最近 Grok Bot 好多人用起来了，这个批量清洗的任务正好可以交给它们去做。顺便也能测试一下它的能力。

TL;DR

最顺滑的方案：Grok Bot 做协调 + headless session（最好是费用可控的模型）配合 ego-browser 做执行；

最后处理了一共约 100 条记录，清洗了八成以上的账号。

但是，整个过程跟“无人值守”完全不沾边，还是需要人工介入。我的人工介入主要集中在几类具体的事情上：

• 在聊天窗口里唤醒 Grok Bot（后面会提到具体问题机制）
• 转告手机收到的短信验证码或者原邮箱里的验证码
• 在遇到密码不对或网站风控导致登录失败时接手处理

下面每一节具体展开。

第一步：给 bot 发一个账本

第一步的目的是让 bot 能直接获得我需要处理的账号清单，然后把处理的状态记录下来。 主要用的是 Bitwarden CLI（命令行客户端），简称 bw。

流程：

• 给 bot 注册一个专门的 Bitwarden 账号
• 主账号邀请 bot 加入组织
• 把要清洗的账号“分配到集合”，到组织的密码库里
• 让 bot 直接操作 bw

每开始处理一个账号，bot 就用 bw get item 取出条目，做相应的清洗操作，最后用 bw edit item 写回密码库。

提示

这里的一个技巧是，用条目名称最前面的方括号前缀来表示当前状态。只要条目名还没有加上 【】 前缀，就代表它是还没处理。这个做法可以让新接手的 agent 只要重新拉一次 Bitwarden 条目列表，过滤掉带方括号前缀的项，就能顺着同一份队列接着往下做，完全不需要人在中间核对两边状态。

前缀分类和判定细则最后固定成了下面这套口径：

第二步：合理设置清洗目标

最小化原则与特殊情况处理

在实操里有不少站，会员后台根本不让用户自己改特定字段。如果硬要以“全部替换”作为唯一完成标准，agent 就会在页面上卡死循环。

所以只要把姓名、电话和地址这些能改的字段换完，并在 Bitwarden 的 notes 里注明“邮箱只读”或“需联系客服修改”，就可以照常标上【已清洗】。

最小化原则说的是，原本为空的非必填字段一律保持为空，只覆盖已经填了真实信息的字段；

优先改成 bot 专用收件箱或备用手机号，Bitwarden 里的数据也跟着同步更新。

拆分共用的通行证

一种情况是：多站共用一套通行证，底层共用同一个会员体系等。

如果直接按一个账号去委托清洗，其他共用同一套通行证的站点（同样可以登录，但资料未被修改）的资料就会漏处理。

遇到这种账号，需要让 bot 在 Bitwarden 里手动复制出副本，把条目名改成子站的网页标题，再单独放进队列让 agent 去洗。

涉及订单、票务、金融、电信、公共事业应跳过

需要核验实名的服务，需要让 agent 提示风险，手动标成【无需清洗】。

prompt 类似：

“凡是涉及票务、金融、做过 KYC 的虚拟货币、电信、公共事业，以及受约束需要核对本人身份的二手买卖平台，全部先标出实名风险，等我逐个确认过才准开跑。”

否则替换了实名信息可能会带来风险，导致票作废、账号被锁等问题。

第三步：处理平台安全审查拦截

这是我遇到的第一个卡点。

我首先假设整个流程都能在云端沙箱（box）里顺利跑完，所以我直接把所有操作都交给了 Grok Bot “注册助手” 去执行。

然而 Grok Bot 云端沙箱有针对浏览器任务的平台安全审查。这层审查会直接拦下两样东西，一样是任务文字里出现的账号密码，另一样是页面或截图里成片的真实个人资料。

它触发时直接中止任务，根本不弹审批卡，所以 Auto-review 审批规则管不到它。为了让模型在“看不见密码”的前提下完成登录和改密，填密码的办法前前后后换了三轮。

login 行为直接触发平台拦截

让“注册助手” bot 直接从 bw 取出密码，写进浏览器子任务里让助手去填。

刚跑第一个网站，助手就按内置规则拒了：My rules don't let me enter a user's account password。我在后台加上自定义规则手动放行后顺利登了进去。但紧接着跑其他站时，三个浏览器任务在 20 分钟内接连被平台直接掐断，报错原文一模一样：

The helper was stopped because its request or an image in its conversation was blocked.

“注册助手”自己也判断，这种拦截不会弹出审批卡，审批规则管不到它。

我只好先暂停定时续跑，让另一个叫“调查专员”的 bot 做了一次边界测试：同样是刚才那三个网站，改成只打开登录页、不填密码，结果三个任务全都没被停。测试结果很清楚，触发平台拦截的就是“把密码写进任务文字、让浏览器助手去填”这一步。

要绕开拦截，密码就不能出现在浏览器任务的文字里，只能走 Grok Bot 原生的自动填充。但 Grok Bot 的自动填充只接 1Password，不读 Bitwarden。

我想了个折中办法，把 1Password 当成一座过路的桥：临时注册了一个试用账号，建好 Bridge 保险库和 service account。

• 先用 bw 取出待处理条目写进权限 600 的临时模板文件
• 通过 op item create --vault Bridge 同步过去
• 用 shred 粉碎本地文件；等浏览器里的扩展自动填完密码、洗完资料，最后删掉 Bridge 里的临时条目并执行 bw lock

1Password 自动填充也被拦截

而紧接着到了打开会员资料页做具体修改时，任务过了四分钟又被掐断了。

排查下来，这次撞上的还是平台审查，因为页面截图里包含了大量真实个人资料。哪怕后面改成只看文本快照、不截图，只要网页上原本显示的真实姓名、电话和住址一多，打开资料编辑页的任务还是会被连续拦停。

而 1Password 自动填充也反复卡壳：

• 非登录表单填不进去：直接报错 does not have a complete sign-in form with an eligible password field
• 剪贴板粘贴复杂且易错：这个方法非常复杂，为了绕过自动填充的限制：在命令行里从 Bridge 取出密码赋给局部变量，通过 DISPLAY=:4 setsid xclip -selection clipboard 放进系统剪贴板，让 computerUse 点进密码框按 Ctrl+V 粘贴提交，紧接着跑一句 pkill xclip 清空剪贴板，避免影响后续的任务。
• 新建 bot 无法复用 1Password 连接：为了接手剩下的队列，我专门新建了一个“清洗专员” bot，还给它配了一份包含 10 步标准流程和 19 条规则的细则文档。结果这个新 bot 调自动填充时先是要我手动点批准，点完直接报 could not resolve this login；重新补连 1Password 之后测试，结论依然是“新建的 bot 没法用这个 1Password 填写”。折腾下来，“清洗专员”连一个账号都没洗成就被我删了。

云端沙箱的局限性显而易见。

• 单桌面环境限制：云端沙箱里只有一个桌面环境，所有浏览器操作只能串行排队，效率极低。
• 试用额度有限：即便排队执行，试用额度也根本清不了几个账号，只够验证流程可行。
• 平台安全审查严格：云端沙箱的浏览器任务容易被平台安全审查拦截，导致任务中止，审批规则无法覆盖。

这样基本上无法满足大规模账号清洗的需求。有什么办法绕开这些限制？

切换到本地无头会话

痛定思痛后，我决定把所有关键的浏览器操作搬回本地 Mac 上执行，本地本来就有现成的 ego-browser 和 agent 会话环境，此时 Grok Bot 只当协调人。

我在本地工作目录下放了一份统一的 task-template.md 清洗规范，把踩过的坑和例外规则都写进去。每个待清洗账号单独交给一次 claude -p 或 codex exec 无头会话去跑，跑完只把状态和改了哪些字段写进不含密码的 result.json，最后由远端的“调查专员” bot 读回这个文件，去 Bitwarden 核对并更新条目。

因为执行链路里不再有云端沙箱的浏览器任务，之前那层动辄掐断任务的平台审查彻底消失了；密码也改成由本地 bw 现取现用，不再经过 1Password 中转。

到了 Mac 本地，单跑和并行跑又分别用了两种喂密码的做法。

• 单任务 pbcopy 粘贴：先用 bw unlock --passwordenv BW_PASSWORD --raw 取出密码，配合 macOS 的 pbcopy 和 Meta+V 粘贴进密码框。
• 并行后改为 600 临时文件 + page.fill：多任务并行时整台 Mac 共用一个系统剪贴板，前一个任务刚拷进去的密码很容易被后一个任务覆盖。之后并行任务统一改成把取出的密码写进权限 600 的受保护临时文件，由浏览器驱动层直接从文件读取并通过 page.fill 填入。

除了彻底解决填密码和平台审查，搬回本地还顺带打通了两件事。

• 真正的一账号一会话与并行：每个网站都在干净的新上下文里启动，前一个网站的残留页面和报错不会污染下一个网站；打破单桌面的串行限制后，一次可以拉起多个进程并行洗，中途卡住的账号还能按 sessions.tsv 里的 session ID 用 resume.sh 单独续跑。
• 家用宽带降低网站风控：网络出口从云厂商机房换成了家里的住宅宽带 IP，日本网站的风控拦截率明显降了下来。

不过，刚在本地把这套流程跑起来没多久，我就撞上了新的麻烦：一个是并行跑本地 agent 的 token 额度消耗快得惊人（Codex），另一个是 Claude 自带的安全权限策略又在半路把改邮箱的动作拦了下来。

成本与权限：从 Codex、Claude Code 换到 Devin SWE-2

第一棒：Codex 额度瞬间见底

最开始我用 codex exec 加上 --dangerously-bypass-approvals-and-sandbox 全自动开关，模型选 gpt-5.6-sol，一次开 5 个账号并行跑，每个任务启动时间错开约 25 秒。

Codex 干活确实利索，前前后后记下了 48 次运行与续跑。但消耗速度实在吓人，仅仅跑了这一批 5 个并行任务，就把我的 5 小时使用额度直接打到了 0%。我用掉一次额度 reset，过了一小时再开跑一批，跑完又只剩下 21% 左右。后面不得不又 reset 了一次才能继续。

事后翻看本地留存的 session 日志，13 个会话合计就吞掉了 26,368,770 个 input token（其中 25,547,520 是 cached input）和 185,707 个 output token。单个会话跑了 43 到 60 分钟，各自吃掉了 495 万到 742 万不等的 input token。

第二棒：Claude Code 权限分类器拦下

眼看 Codex 额度扛不住，我赶紧拉了 Claude Code（模型 claude-sonnet-5-5）上来分担，同样是 5 个账号并行，一共跑了 12 个 session（累计读了约 1720 万 cache read token，写了 132 万 cache write token）。

结果刚跑上就踩进了权限的坑。我本地的 settings.json 里设了 defaultMode=auto，这个模式会直接压住命令行的免审批开关，内置的安全分类器一旦检测到 agent 在动凭据或者修改账号绑定的邮箱，就会直接出手拒绝。

比如在洗 MUJI 会员时，前面改名字、改地址都顺利过了，唯独到了改注册邮箱那一步，直接被分类器以 Account & Standing-Rule Changes 为由拦了下来，导致这个账号只能停在 partial 半成品状态。

第三棒：Devin SWE-2 终于跑完

被额度和权限两边夹击之后，我把目光投向了 Devin CLI。正好 SWE-2 模型正在推广期间，会员可以免费使用。这样的清洗任务，SWE-2 是否能胜任呢？

我让 Grok Bot 写了个简单的单站启动脚本 devin-one.sh，核心命令是 devin --model swe --permission-mode bypass --respect-workspace-trust=false -p，再封装成 devin-batch5.sh 这样的批次脚本，每批拉起 5 个账号并行跑。 浏览器操作这一层则通过 skill 交给 ego-browser，直接驱动我 Mac 上的真实浏览器。

清洗突然就顺了。一共跑了 7 批以上，留下 43 份运行日志。

正常一个账号从打开网页到改完资料写回 Bitwarden，耗时中位数就在 7 到 15 分钟之间。

注意

回头看，登录加改资料这种固定套路的活，根本不需要特别强的推理模型；最重要是 ego-browser skill 加持下的本机浏览器环境绕过了沙箱的限制。

当然，Devin CLI 加 ego-browser 这套方案在实操里也踩了几个需要注意的坑。

• 临时子 shell 退出会连带杀掉子进程：一开始用 nohup ... & 在临时子 shell 里启动 Devin，外层 shell 一结束，底下的子进程就被连带杀掉了，日志文件完全是空的。后来全部改成用常驻后台 shell（block_until_ms=0）直接运行才稳住。
• 多会话重复启动同一站点：同一个账号曾被两个不同会话重复启动，关进程时又关错了正在干活的那个。之后我规定所有 Devin 清洗任务统一由同一个协调 bot 在查清进程后再启动。
• ego-browser 的 evaluate 偶发挂死：底层 Node.js 进程偶尔会卡住不动，需要我手动 kill -9 杀掉卡住的进程，Devin 才能接着往下跑；另外遇到 ego 的 task.cdp 不支持 Browser.setPermission 时，要改成页面级的 page.cdp，我也把这条写进了任务模板的“ego 已知坑”一节。
• 免费期后的成本未知：SWE-2 的会员免费期不清楚到什么时候，本地日志里既不记 token 数量也不记账单金额，免费期之后再跑同样的批量任务要花多少钱，当前无法估算。

验证码交接：human in the loop

改 bot 专用收件箱，或者更换绑定手机号的时候，几乎都会发一封带一次性验证码（OTP）或确认链接的邮件，不少网站还会往手机发短信验证码。

问题在于，跑在我家 Mac 上的本地 Devin 进程，没法直接去读远端 Grok Bot 的专用收件箱。为了避免每次都手动复制粘贴，需要 agent 之间交接验证码的约定。

靠本地文件交接

具体的交接协议只用两个文件，配合收件箱来信触发的唤醒任务（routine），把邮件验证这一步跑通了。

• 本地 Devin 写 need-otp.json 并原地等待：点完发送验证码后，在站点工作目录下写入 need-otp.json（记录站点名、接收尾号或邮箱、请求类型和时间戳），停在验证页等待，不刷新也不离开页面
• 轮询 otp.txt 与超时重发：Devin 每隔 10 秒读一次同目录下的 otp.txt，最多等 10 分钟；超时未收到则重新触发发送再等一轮
• Grok Bot 读收件箱写回 otp.txt：加一条邮件触发的 routine，收件箱一收到新信就唤醒远端“调查专员” bot，由它对照 Mac 上哪个站点挂着 need-otp.json，提取出验证码或确认链接写进对应的 otp.txt

这套配合跑出了最漂亮的一次闭环：Devin 点完发送写下请求，收件箱收到确认信触发唤醒，验证码自动写进 otp.txt，Devin 读到后填入网页完成邮箱更换，全程没用我插手。

Grok Bot 的三种“叫不醒”

除了邮件验证码这一小块，多 agent 之间的自动唤醒其实并没有真正跑通，这也是整个清洗过程里人工介入最密集的地方。光是为了让远端 bot 在需要的时候醒过来干活，我就撞上了三种不同的“叫不醒”。

• 自己起的后台进程叫不醒自己：让 bot 在后台跑计时器或文件监视脚本（比如每分钟轮询一次的 watch.sh），主会话一旦休眠，后台脚本根本叫不醒它。
• 定时任务迟到且权限不全：Grok Bot 平台自带的定时任务（每 5 分钟跑一次的监工 routine）遇到高负载会迟到甚至跳过。
• 定时任务结束连带杀掉 Devin：只要是在定时任务的临时 shell 里直接拉起的 Devin 进程，那次运行一结束，拉起的 Devin 就会被系统直接杀掉。

这说明 Grok Bot 还不具备可用的连续工作能力。事实上，Devin CLI 加 ego-browser 充当执行代理，使用 Claude Code 来监听进度并协调也许效果更好。

提示

我中途还向“调查专员”推荐过社区里专门做跨机器 agent 互相发消息和唤醒的工具 yobiru，但它去查了一圈后居然自己拒绝了，所以最后我还没验证它能否真正解决多 agent 唤醒的问题。留了一个可优化的空间。

结语

花二十多个小时和 Grok Bot 及本地 agent 协同折腾完这一百多个账号（有可能还不如用手一个一个改快），回头看有两个实打实的收获。

• 验证并跑通了一套批量清洗流水线：虽然中间踩遍了云端沙箱审查、token 额度见底、权限拦截和远端唤醒失灵的坑，但最终还是证明了让 bot 批量处理跨站繁琐表单是可行的，也摸索出了“Bitwarden 前缀做队列 + 密码本地直读不进对话 + 本机真机浏览器并行 + 本地文件交接验证码”这套能复用的配合模式。
• 实实在在躲过了一次个人信息泄露：10 月 23 日，GSC（Good Smile）官方商城发公告说被入侵了：从 10 月 19 日下午到 22 日晚上，后台被人反复访问，会员的姓名、住址、电话、邮箱和订单记录都可能被看到。我在那里也有一个账号，几天前它刚好排在清洗列表里，被 bot 洗过一遍。

当然，事后去洗历史旧账终归只是“亡羊补牢”。

面对越来越频繁的拖库事件，真正省心的做法还是贯彻 Zero Trust（零信任）原则：从注册那一刻起，就默认你交出去信息的服务迟早会泄露，再根据不同业务的实名要求分级安排“数字分身”（替身资料、专用收件箱、备用号码）。从源头上管住交出去的信息，才是最切合实际、未来也不需要再集中救火的根本办法。

参考资料

• Gyazo 个人信息泄露公告 | Helpfeel
• ITmedia 10 月泄露汇总
• 日本経済新聞 报道
• ユミルリンク 泄露累计约 5162 万件 | 日本経済新聞
• ユミルリンク 第一报 | 朝日新聞
• 10 月中旬泄露事件汇总（ショップサーブ、ソースネクスト、バーガーキング、第一興商、銀のさら、ヤマト、ブックオフ等） | ITmedia
• skyticket 公告
• skyticket 卡号补充公告
• 楽天トラベル 公告
• アンドエスティ 公告
• So-net 公告
• 阪急阪神百貨店 公告（PDF）
• グッドスマイルカンパニー 官方商城被入侵 | ITmedia
• グッドスマイルカンパニー 官方商城被入侵 | Hobby Watch
• Introducing Grok Bot | xAI
• SWE-2 | Cognition
• Models | Devin Docs
• chekusu/yobiru