用于社交媒体营销的反检测浏览器：实用搭建指南
代理机构的完整工作流：每个客户一个工作区，每个账号一个配置文件并匹配代理和时区，用角色完成交接，再配合 API 自动化。
社交媒体代理机构的运营难题很少出在内容上，而是出在基础设施：分布在多个平台上的一大堆客户账号，一个必须同时在这些账号上工作又不能互相绊脚的团队，以及会读取每个会话环境的平台。本文介绍如何让这套基础设施保持平稳无趣，以 PowerOps 为例，从头到尾走一遍。
结构：工作区、分组、配置文件
不要忍不住把所有配置文件排成一张长长的列表。规模增长后，能让整套方案撑得住的是结构，三个层级就够了。
- 每个客户一个工作区。客户的配置文件、代理和备注放在一起，在处理另一个客户时，屏幕上不会出现这个客户的任何东西。交接离场也只是对一个工作区的操作，而不是一场考古。
- 工作区内每个平台一个分组。客户的 Facebook 配置文件放一组，Instagram 放另一组，TikTok 放第三组。批量操作以分组为单位，所以这样划分之后，一个动作就能启动或停止某个平台的全部配置文件。
- 每个账号一个配置文件。其余一切都建立在这条规则之上。一个配置文件只持有一个账号的存储、身份和线路，其名称会说明它是哪一个。
命名值得花三十秒定个规矩：依次为客户、平台、账号名。配置文件有编号且可搜索，所以在嘈杂的办公室里，任何人喊一声“打开 41 号”，同事都清楚指的是哪一行。
结构还能在有人发问之前就解决审计问题。当客户想知道谁在什么时候动过他们的账号，成员明确、配置文件一次只能由一人打开的工作区，本身就内置了答案。
每个配置文件的身份与线路
每个配置文件都会获得一套自洽生成并保存下来的设备身份，因此每次打开都报告同一台合理可信的机器。这部分是自动的。需要人来判断的是线路。
- 在客户账号所在运营的国家购买粘性地址，每个账号一个。
- 将它们添加到代理库并测试。测试会报告观察到的地址和国家，这才是平台会看到的，无论发票上写的是什么。
- 在首次登录之前为每个配置文件分配一个，并在同一次操作中把该配置文件的时区和语言设置为线路所在的国家。
- 按计划定期重新测试代理库。端点会悄悄变差，而变差的线路往往早在出现连接错误之前，就以账号异常的形式表现出来。
不共享密码的交接
代理机构之间的账号交接是家常便饭。实习生负责排期，经理负责审批，总有人要顶周末。传统做法是一张密码表格，代理机构就是这样把客户的账号留在了一台没人找得到的笔记本上。
角色可以取代这种做法。工作区成员获得其工作所需的权限：队友可以打开配置文件并在其中工作，经理还能编辑配置文件和线路，所有者还能管理成员资格本身。账号凭据只需随配置文件保存一次，把账号交给新同事意味着授予访问权限，而不是发送一个密码。有人离开时，撤销其成员资格即可一次性关闭其在所有地方的访问权限，而他从未见过的密码也不需要更换。
让交接顺利进行的习惯是关闭配置文件。配置文件同一时间只在一台机器上打开，因此同事可以看到当前是谁持有它，而不是以最糟糕的方式才发现会话冲突。完成本轮工作后关闭配置文件，下一个人打开时，会话已被干净地写出。
新客户入驻，逐步说明
入驻是结构要么被建起来、要么被跳过的环节，所以值得有一套自己的流程。一个新客户应该只需要一个下午的设置，不必大动干戈。
- 在接触任何账号之前，先创建工作区和各平台分组。
- 向客户收集账号清单：账号名、平台、每个账号服务于哪个国家，以及目前由谁持有凭据。
- 为每个账号购买并测试一条粘性线路，国家要对，并让代理库的测试确认实际到达的是什么。
- 创建配置文件，按客户、平台、账号名命名，并在同一轮操作中分配线路、时区和语言。
- 在各自的配置文件内重新登录每个账号，客户随时在场以应对二次验证和确认邮件。
- 为团队授予角色，向团队说明该客户的发布节奏，并废弃凭据当初送达所经的渠道。
团队最想走捷径的就是重新登录这一步，想从账号原来所在的地方导入 Cookie。请克制。导入的会话带着它来源那台机器的历史，而入驻的意义在于：客户账号今后持有的每一个会话，都是在继续使用它的环境里建立的。
把重复性工作自动化
一条有用的界线：人做判断性的工作，脚本做流转性的工作。检查十几个收件箱的未读数、为周五的报告收集粉丝数、打开早晨要用的那一批配置文件，这些都是流转。本地 API 可以处理它们，而无需任何人重新解决环境问题，因为通过 API 启动的配置文件，带着的身份和线路与人从列表行里打开时完全相同。
const { profiles } = await api(`/profiles?groupId=${clientInstagramGroup}`);
for (const profile of profiles) {
const { ws } = await api("/browser/start", { profileId: profile.id });
try {
const browser = await chromium.connectOverCDP(ws);
const context = browser.contexts()[0];
const page = context.pages()[0] ?? await context.newPage();
// The profile's identity, storage and route are already attached.
await collectForReport(profile.name, page);
} finally {
await api("/browser/stop", { profileId: profile.id });
}
}一次只运行几个，中间留出停顿，并在账号所在地的工作时段运行。表现得像坐在办公桌前的人一样的自动化，才能一直有用。猛烈冲击平台的自动化，只是为同一个教训付两次学费。
这套方案下的一周
这种结构带来的好处体现在日常里。周一早上，团队打开客户的 Instagram 分组，逐个配置文件处理收件箱。周五的报告通过 API 自动跑出来，团队则把下午用在更有价值的事情上。交接离场就是归档一个工作区。这一切都不花哨，这正是重点：这套方案的使命，是让环境问题不再成为有趣的话题。
有两个数字可以告诉你它是否稳固。第一个是有多少次有人输入平台密码，入驻结束后这应当趋近于零。第二个是会话有多少次出人意料地触发验证，这应当很少，并且能追溯到原因：线路变更、异常的流量突增、被催得太快的新账号。当其中任何一个数字上升时，答案就在线路和节奏里，而最先该查的是最近变化最大的那一项。
规则，直说
这套工作流涉及的每个平台，都有关于账号和自动化的条款，而这套方案不会改变其中任何一条。隔离让客户之间不会互相污染。角色让凭据远离表格。API 消除琐碎的重复劳动。这一切都不构成对违禁账号、违禁自动化或平台所禁止行为的许可，对于我们无法控制的平台上的任何结果，这里也不作承诺。能长久经营的代理机构，会把平台规则视为客户工作的一部分，而把工具视为干净地完成这项工作的方式。
搭建清单
- 为每个客户创建一个工作区，并在其中为每个平台创建一个分组。
- 为每个账号购买一个位于其运营国家的粘性地址，并测试代理库中的每个端点。
- 为每个账号创建一个配置文件，按客户、平台、账号名命名，并在首次登录之前分配好线路。
- 将每个配置文件的时区和语言设置为其线路所在的国家。
- 给每位团队成员授予角色，而不是给任何人发送密码。
- 通过本地 API 自动化流转性工作，节奏像真人一样。
- 每轮工作结束时关闭配置文件。
