当AI替你做了三天调研：deep-research工作流是如何工作的

刚完成一次深度调研：98个Agent、345万token、1350次工具调用、27分钟。这篇文章就是它产出的副产品——一边写过程，一边讲技术。

核心观点 / 起源

背景：管线的”最后一公里”

几个月前，我搭了一套自动化社媒分发系统：一篇文章写完后，AI自动生成小红书文案、X推文串、LinkedIn帖子、知乎回答，写入飞书多维表格，再喂给视频管线——DeepSeek写脚本、Edge TTS配音、观点卡片做画面素材、FFmpeg合成为竖屏视频。整个过程行云流水……到”发布”这一步彻底卡住。

因为我得打开每个平台的网页，手动复制粘贴。六个平台，一篇文章。一个月十篇文章——大半天的机械劳动。

我当然想过用 API。X 有 API，LinkedIn 有 API——但小红书、知乎、B站、抖音没有公开 API。唯一的办法是浏览器自动化：让程序像人一样打开网页，填表单，点发布。

这就引出一个核心问题：平台怎么知道我是在用程序操作？

普通浏览器自动化为什么会被检测

你的浏览器在访问每个网站时，会暴露几百个特征：Canvas 渲染结果、WebGL 显卡型号、已安装字体列表、音频处理器的输出、屏幕分辨率、navigator.webdriver 属性……这些特征组合在一起，形成了你的浏览器指纹。

标准的 Playwright 或 Puppeteer 的自动化浏览器，会留下几个明显的破绽：

• navigator.webdriver 返回 true（正常浏览器返回 false）
• CDP 协议通道上有自动化工具的特征握手数据
• 运行时注入了 __pw 或 __puppeteer 等内部标记
• 某些指纹向量的返回结果与真实浏览器有细微差异

反爬服务（Cloudflare、DataDome、Akamai）就是靠检测这些痕迹来判断来访者是不是机器人。

针对这个问题，市面上出现了多种解决方案。我挑了两个最受关注的：CloakBrowser 和 nodriver。它们走了完全不同的技术路线。

为了搞懂哪个适合我的场景，我启动了一次深度调研。这也是这篇文章想讲的核心——不光是结论，更是调研本身的方法。

传统的”搜索+总结”有什么问题

在 Claude 的 deep-research 工作流出现之前，我如果想知道 CloakBrowser 是否靠谱，通常会这么做：

1. 搜索 CloakBrowser review，看几篇博客
2. 问 ChatGPT “CloakBrowser 好不好用”
3. 看几个评测视频，大概判断一下
4. 拍脑袋做决定

这种方法有三个致命的坑。

第一个坑：AI 幻觉。 如果你直接问大模型”CloakBrowser 的反检测能力如何”，它可能自信地回答”有58个C++补丁，通过30/30项检测，reCAPTCHA得分0.9”，然后补一句”建议使用”。这些数字看起来很具体，但它们实际上来自项目方的 README——大模型只是在复读厂商的营销文案。

第二个坑：信息茧房。 你搜到的前几个结果很可能是项目方的 GitHub 首页和几篇中文技术博客，它们都引用同一组数据。你看不到还有一份独立评测报告做了31个 Cloudflare 目标、651次测试，发现 CloakBrowser 只通过了26个。

第三个坑：无法验证。 每篇文章都说”0.9的reCAPTCHA得分”，但仔细看它们引用的是同一个来源——项目方自己的 Docker Hub 页面。没有独立第三方复现过这个测试。

deep-research 工作流就是为了解决这些问题而设计的。

过程 / 推演

五阶段管线：一次深度调研的内部解剖

这次 CloakBrowser 调研历时27分钟，消耗了98个Agent和345万token。听起来很多，但分解来看，每个阶段都有明确的目的和产出。

阶段1：Scope（拆解）

不是搜索”CloakBrowser”，而是把问题拆成5个互补的搜索角度：

1. CloakBrowser 核心技术与 Chromium 补丁分析 — 它到底改了 Chromium 的哪些代码？
2. CloakBrowser Python/Playwright 集成实践 — 怎么在代码里用它？
3. 社交平台自动化发布与 social-auto-upload-web-ui 架构 — 实际项目是怎么用的？
4. CloakBrowser Docker 部署与低资源服务器运行 — 我的1.8GB阿里云能跑吗？
5. CloakBrowser vs 替代方案对比评测 — 有没有更好的选择？

这就像去图书馆之前先列书单。你明确知道要找什么书、去哪个书架、问什么问题。

阶段2：Search（并行搜索）

5个Agent同时出发，每个返回6个高质量来源。这是深度的第一次乘法效应——你不是读一篇文章，而是同时读30篇文章的不同角度。

关键机制：去重。相同的论断来自5个不同的来源和相同的论断来自同一个来源的5次复读，权重完全不同。

阶段3：Fetch（提取论断）

抓取Top来源的全文，然后做一件事：把大段文章拆成”一句一论断”的结构化数据。

这是最容易低估价值的步骤。一段华丽的营销文案，拆开来看就几个可验证的点：

• “通过30/30项检测” → 30/30具体指哪些检测？谁测的？
• “58个C++补丁” → 这个数字是所有平台统一还是只有Linux？
• “reCAPTCHA 0.9分” → 谁测的？来源是哪里？

拆完之后，真正能拿去验证的不是整篇文章，而是这些具体的、可被证实或证伪的陈述。

阶段4：Verify（对抗性验证）—— 核心机制

这是整个流程的核心。每个论断交给3个独立的Agent去验证，它们被prompt要求：

“尽可能去反驳这个论断。”

每个Agent会：

1. 搜索证据来源
2. 检查来源的可靠性（厂商自报？独立评测？学术论文？）
3. 判断这个论断是否真的有数据支撑
4. 给出”推翻”或”不推翻”的判决

三个Agent投票，≥2/3推翻则该论断被淘汰。

这就是一个精简版的法庭审判。你不是在问”这个说法对不对”，而是在问”谁能推翻它”。3个独立的验证者，从不同角度寻找反例——这种对抗性能最大程度地消除单一Agent的偏差。

这次调研中，25个论断进入验证，12个被推翻，13个被确认。

被推翻的例子：

• “reCAPTCHA v3 得分 0.9，服务端验证” → 实际上这是项目方自报数据，独立调查发现没有任何第三方复现过这个测试
• “58个 C++ 源码级补丁” → Docker Hub 说26个，中文博客说49个，GitHub 说58个——项目自己的文档互相矛盾
• “social-auto-upload 使用三层架构” → 独立源码分析发现不存在所谓的 TypeScript MCP 服务层

被确认的例子：

• “CloakBrowser 是 C++ 源码级修补，不是 JS 注入” → 多个独立来源一致确认
• “CloakBrowser 是 Drop-in 替代 Playwright” → 源码和文档一致
• “nodriver 在独立测试中表现更好（28/31 vs 26/31）” → 多方引用同一份基准测试，方法论公开，数据可复现

阶段5：Synthesize（综合）

最后一步是把确认的论断合并语义重复项，按置信度排序，标注来源，生成结构化报告。

读这份报告时你会发现：每个结论后面都跟着来源链接和置信度评估。不像 AI 聊天那样”好像是这样的”——你随时可以点进去验证。

345万token，正常吗？

这是很多人最关心的问题。分解一下token去向：

验证阶段占了近四分之三的token。每个论断×3个Agent×多次网络搜索×全量上下文分析，等于指数级膨胀。

这合理吗？这是”校准过的过剩”。

如果减少验证轮次（3→1），可以省60%的token。但那意味着每个论断只有一个Agent在判断——它可能漏掉关键的反面证据，它可能没有注意到来源是营销文案。

类比一下：买保险。不买最省钱，但出了事更贵。验证阶段的token消耗就是一重质量保险——我不需要100%的准确率，但我需要知道”这个结论经过交叉验证，置信度在某个水平以上”。

对于一次能影响后面几百行代码的技术选型决策来说，345万token（按当前的API价格大约几美元）是极其划算的投入。

还能更优吗

可以，但都有代价。

不能动的是Scope拆解——问题拆错了，后面全歪。验证可以省，拆解不能省。

当前配置（5个搜索角度、Top15来源、3轮验证）是”高质量调研”的甜点区。不是最便宜的，但产出的结论经过了充分的交叉验证。

调研结论是什么

回到最初的问题：CloakBrowser 适合我的场景吗？

结论很明确：nodriver 更适合。

但真正有价值的不是这个答案本身，而是这个答案是怎么来的。它不是某个博客说的，不是 AI 幻觉编的，而是经过了5个阶段的拆解、25个论断的对抗性验证后得到的。

这就是 deep-research 工作流的价值。