云电脑三通道并行方案 · 可实施性评估

一台无影云电脑 · 一个抖音号(野荞) · DM 一触 / RC 楼中回复 / 二触三连 | 2026-06-17

一句话结论: 一台机一个号做不到"两条 GUI 同时点屏幕"(物理铁律),但能做到 「1 条 GUI 车道发 DM + N 条 API 车道发评论」同机同号同一秒并发。核心是把 RC / 二触从"占窗口 1–2 分钟的 GUI 操作"改成"不碰桌面的签名 HTTP 请求"。技术链路 90% 已存在(读评论的签名机制在生产跑),唯一真门槛 = 评论发布接口要自己签 + 必须先小流量验证不封号。

1. 约束与目标

维度	锁定值
硬件	1 台阿里无影云电脑(国内 IP)
账号	1 个抖音号(野荞)
通道	DM 一触 · RC 楼中回复 · 二触(点赞+评论1+评论2)
目标	三通道并行 —— 不接受"二选一手动切换"、不加机、不加号

2. 物理铁律:两条 GUI 永远不能并行(已验证)

执行器全程用 pyautogui(douyin_dm_grounded.py 实证):光标 / 截屏 / 键盘焦点都是桌面会话单例。

一台无影 = 一个桌面会话 ┌──────────────────────────────────────────┐ │ 🖱️ 一个光标 🖥️ 一块屏幕 ⌨️ 一个焦点 │ └──────────────────────────────────────────┘ DM执行器想点(300,400) 二触执行器想点(800,200) └──► 抢同一个光标 ◄──┘ 💥 互相打断 · 点错 · 字打错窗口 ⇒ GUI 动作 = 桌面独占,同一瞬间只能一个。这条绕不过。

而且每条 GUI 发送是大块占用:DM ≈ 40 秒,RC ≈ 1 分钟,二触三连 ≈ 1–2 分钟。塞不进彼此的缝里。

3. 破局点:只有"发送那一下"需要桌面

一条任务的生命周期(以 DM 为例): ① claim ─► ② 抖音号反查 ─► ③ LLM备料 ─► ④ 发送 ─► ⑤ 回写查DB 打主页接口生成话术点屏幕写DB 不碰桌面不碰桌面不碰桌面 ★独占桌面★ 不碰桌面 └────────── 80% 时间可并行 ──────────┘ └ 唯一串行 ┘

关键洞察:RC 和二触的"发送"本质是 HTTP POST(评论 / 点赞),连桌面都不需要。把它们移出桌面,就和 GUI 发 DM 不再争抢。

4. 核心架构:GUI 车道 + API 车道同机并行

一台无影(国内IP) · 一个号(野荞) ┌─────────────────────────────────────────────────────────┐ │ 车道A:GUI(独占桌面) 车道B:签名API(不碰桌面) │ │ ┌────────────────┐ ┌─────────────────────────┐ │ │ │ DM 一触 │ │ RC 楼中回复 (httpx POST) │ │ │ │ pyautogui 发私信 │ 同时 │ 二触=点赞+评论1+评论2 │ │ │ │ (收件箱只能GUI) │ ◄────► │ (digg + comment×2 API) │ │ │ └───────┬────────┘ └────────────┬────────────┘ │ │ 14:00:03 打DM 14:00:03 POST评论 │ │ └──────── 字面同一秒在发 ────────┘ │ │ 共享:claim 4h锁(去重) + 独立日预算桶(DM桶/评论桶) │ └─────────────────────────────────────────────────────────┘

车道 A · GUI 专跑 DM

私信收件箱 UI 只有 GUI 能可靠操作 → 留在桌面
沿用现有 douyin_dm_grounded.py,逻辑不动
独占光标 / 屏幕 / 焦点,一次发一条

车道 B · API 跑 RC + 二触

评论 = comment/publish,点赞 = commit/item/digg
签名 httpx POST,不碰桌面,几百毫秒一条
车道内 RC / 二触用 async 还能互相并行

5. 「httpx 发评论」怎么操作

抖音读评论现在已经用签名 httpx 在跑(comment_api.py)。发评论 = 把同一套签名机制从 GET 换成 POST,只差三处:

	读(现有 GET)	发(要做 POST)
方法	GET	POST
参数	aweme_id	aweme_id + text 正文 [+ reply_id 给RC]
cookie	匿名 ttwid 够	野荞登录态 cookie(sessionid)
签名 a_bogus	完全复用 ABogusManager.model_2_endpoint
验证	status_code==0	status_code==0 + 返回新评论 cid

async def publish_comment(aweme_id, text, login_cookie, reply_id=None):
    from f2.apps.douyin.utils import ABogusManager
    params = _common_browser_params(aweme_id)   # 复用!设备指纹 + 新 msToken
    params["text"] = text                       # 评论正文
    if reply_id: params["reply_id"] = reply_id  # RC 楼中回复才带
    endpoint = ABogusManager.model_2_endpoint(  # 签名,与读评论同一函数
        _USER_AGENT, ".../aweme/v1/web/comment/publish/", params)
    async with httpx.AsyncClient(timeout=15) as client:
        r = await client.post(endpoint,
            headers={"User-Agent": _USER_AGENT, "Referer": "https://www.douyin.com/"},
            cookies=login_cookie)               # ★ 登录态(非匿名)
    return r.json().get("status_code") == 0     # 0 = 发成功

对比:GUI 发评论 = 搜人→开视频→暂停→点赞→点评论框→打字→发送(1–2 分钟占窗口);httpx 发评论 = 拼参数→签名→POST(几百毫秒,桌面全程空着)。

6. 落地三步(每步独立验收)

⛔ 第 1 步是总开关(gate): 发布接口验不通 / 被风控 → 整个并行方案不成立,只能退回 GUI 串行轮转。先验证,再投入。

第 1 步 · 探针验证 1 天

写 _probe-comment-publish.py:用野荞 web cookie + f2 签名,手动实发 1–2 条评论 / 1 个点赞,看返回 status_code==0 且账号无异常(无验证码、无限流、无封禁)。

第 2 步 · 建 API 车道 2–3 天

comment_api.py 补 publish_comment / digg_item 两个签名 POST
二触:digg 点赞 + 评论1(LLM 评视频)+ 评论2(搬 DM 正文,过 DM_VIOLATION_RE 违规闸)全走 API
RC:楼中回复走 publish(带 parent_cid / reply_id)

第 3 步 · 双车道同机并发 1–2 天

poll agent 拆成两个独立 loop(或两进程):loopA = GUI 发 DM(现有不动);loopB = async 发 RC+二触
共用 claim 4h 锁去重;各记各的日预算桶

7. 卡点与风险

🔴 没有现成发送接口 — comment_api.py 现在只会读。发评论 / 点赞要自己加签名 POST。
解:第 2 步开发,技术可行(签名机制已封装在 f2)。

🟡 缺登录态 cookie — 无影上野荞通常只 GUI 登录、没导 web cookie。API 发评论必须用他自己的 sessionid。
解:用 Cookie-Editor 导一次(onboarding 现成流程),15–30 天换一次。

🔴 封号风险未知 — 发布类接口反爬比读取严,自动评论可能触发风控。
解:第 1 步小流量探针硬 gate,通过才放量。

🟡 二触评论2 违规闸 — DM 含微信/报价/促销词的(恰是高意向那批),搬到公开评论区会被 DM_VIOLATION_RE 砍掉,只剩评论1。
解:已有逻辑,接受;高意向触达仍以 DM 为主。

🟢 重复发送 — claim 按 (org_id, douyin_user_id) 锁 4h,跨车道也锁;DM 池(新人)与二触池(已DM未回)天然分离。
不会对同一人同时发两条。

8. 可实施性评估

70/100

总体:可实施,但有一个硬 gate。
技术链路成熟(签名机制已在生产),工作量小(约 4–6 人天);成败完全押在第 1 步探针——发布接口能否签通且不被风控。这是不确定性的全部来源。

评估维度	评分	说明
技术可行性(签名/POST)	高	a_bogus / msToken 签名已封装且生产验证;POST 是标准操作
代码改动量	小	复用 90% 现有链路;新增约 4–6 人天
架构契合度	高	无影是国内 IP(API 能签通,东京被封才走 GUI);claim 去重 / 预算桶现成
发布接口可行性	未知	端点确切契约(text 放 query/body、a_bogus 是否签 body)需探针实测
封号风险	需验证	发布类反爬严;自动评论可能被风控 → 第 1 步硬 gate
运维复杂度	中	多一份 web cookie 要定期换;双 loop 比单 loop 略复杂

两种结局

探针通过 → 投 4–6 人天建双车道,得到一台机一个号的真物理并行:DM 走 GUI、RC/二触走 API,同一秒并发,且评论桶与 DM 桶分别填,当天总触达更多。

探针失败(发不通 / 被风控)→ 并行方案到此为止。退回方案 B:单桌面自动轮转调度器(DM/二触/RC 按配额自动轮流发,窗口够用,一天三通道全跑完),仍解决"二选一手动切换"的痛点,只是不是物理并行。

9. 建议下一步

先写 _probe-comment-publish.py 实发 1–2 条评论验证 —— 它是整个方案的总开关。 低成本(1 天)、决定性:发得通且不封,后面 4–6 人天才值得投;发不通,立刻省下后面全部工作量、改走轮转调度器。

评估基于源码实证:worker/services/comment_api.py(签名读取链路)、 worker/scripts/wuying-dm/douyin_dm_grounded.py(pyautogui 桌面单例)、 wuying_poll_agent.py(现 A→B→C 串行轮询)、 scripts/gen-second-touch-comments.py(二触评论2=搬DM正文+违规闸)。本文档为方案设计,未改动任何生产代码。