智叟云集系统
品牌 AI 智能监测与自动化采集系统
当用户开始通过 AI 助手查询品牌、产品和服务时，企业需要了解的不只是"搜索结果里有没有自己"，还包括：AI 如何描述品牌、哪些竞品被一起提及，以及这些结论引用了什么资料。
智叟云集系统围绕这类需求建设一条可追溯的采集链路：向多个 AI 工具提交问题，保存回答、界面截图、对话分享链接和引用来源，再为品牌监测与跨平台分析提供数据基础。
本文介绍系统的分层架构、任务调用流程、证据模型与可靠性设计。示例代码仅展示公开接口和框架组织方式，不包含平台操作定位、回答完成检测、引用解析和异常恢复等核心实现。
一 业务目标与功能边界
一次品牌监测可以从一组问题开始。例如，对虚构品牌"示例品牌 A"，分别设置品牌认知、产品选型、竞品对比和服务评价等问题，在多个平台保留同一批问题的回答快照。
系统关注四类结果：
| 结果 | 用途 |
|---|---|
| 回答文字 | 支持关键词检索、品牌提及识别与后续内容分析 |
| 界面截图 | 保留当时的展示上下文，便于人工复核 |
| 对话分享链接 | 在平台提供分享能力时定位对应对话 |
| 引用来源记录 | 保存来源标题、网址及平台提供的引用信息 |
采集记录可以支撑品牌提及率、跨平台描述差异、竞品共现和来源分布等分析。情感评分、自动化趋势告警和品牌看板属于后续分析层建设内容；目前已验证的重点是采集与证据管理，不能把"数据已经采到"等同于"分析结论已经可靠"。
还需要区分三种链接：对话链接指向一次分享的问答，引用链接来自平台明确列出的参考资料，而回答正文中出现的网址不一定是引用来源。系统应分别保存，避免在统计时混用。
二 系统架构
架构分为业务入口、任务控制、采集执行、平台适配和证据存储五层。图中用虚线表示尚未完成联通的真实任务 API 调度，用浅色区域表示规划中的分析与生产存储能力。
业务入口与任务控制
业务入口接收监测对象、问题集合和目标平台，建立任务标识。任务控制层负责幂等校验、状态查询、设备分配和执行尝试记录。
当前已有 FastAPI 任务接口及本地模拟 Worker，用于验证任务创建、领取、结果查询和附件访问。真实采集目前通过独立 CLI 执行器运行；API 到真实设备执行器的贯通仍是后续集成工作。
采集执行与平台适配
执行器负责时间预算、重跑次数和设备互斥，平台适配层负责将统一采集目标转换为各工具的操作过程。
不同工具在输入、分享、引用展示以及登录后的界面行为上并不一致，因此适配器不能只依赖一套固定坐标。执行过程必须检查当前状态，在界面不符合预期时保留失败证据，而不是继续盲目操作。
证据与分析层
证据层保存原始文字、截图、引用记录、时间信息和文件校验值。分析层读取这些产物，而不直接干预设备操作。这样的分离使采集失败、平台回答变化和分析规则变化可以分别定位。
当前证据保存在本地目录，可输出 HTML 报告与 ZIP 结果包。对象存储、生产数据库、多租户部署和品牌分析看板是扩展方向，不属于本轮已完成的生产能力。
三 一次监测如何执行
一次采集可拆为以下步骤：
-
建立任务上下文，固定问题、平台和设备。
-
获取设备锁，检查该设备是否已有采集任务运行。
-
创建独立执行目录，启动平台采集进程。
-
提交问题，等待回答达到可采集状态。
-
保存文字、覆盖回答的截图和对话链接。
-
提取平台明确提供的引用记录；快速路径不可用时按适配器能力处理。
-
检查结果完整性，输出状态、证据清单与报告。
"回答已可用"和"完整证据已收集"应是两个不同事件。前者可以尽早展示，后者必须等截图与引用检查完成。当前部分本地流程已生成中间结果；统一 API 的分阶段返回仍需要继续接入。
四 可公开的代码框架
以下为简化的设计示例，不是当前真实任务 API 的生产契约，也不是直接运行即可控制设备的完整项目。
from dataclasses import dataclass
from typing import Protocol
@dataclass(frozen=True)
class MonitorTask:
task_id: str
platform: str
question: str
@dataclass
class CollectionResult:
answer: str
conversation_url: str | None
screenshots: list[str]
sources: list[dict]
status: str
class PlatformAdapter(Protocol):
def collect(self, task: MonitorTask) -> CollectionResult:
"""具体平台交互、状态检测和证据提取由内部模块实现。"""
...适配器对外暴露统一结果结构，业务层不需要知道某个平台的分享按钮位于哪里。设备身份、认证信息和内部策略由执行环境管理，不进入公开示例。
面向未来统一入口的请求可以抽象为：
{
"request_key": "brand-demo-001",
"brand": "示例品牌 A",
"question": "示例品牌 A 的产品有哪些特点",
"platforms": ["platform_a", "platform_b"],
"capture": ["answer", "screenshots", "conversation", "sources"]
}框架目录可以按职责组织：
brand_monitor/
├── api/ # 任务入口和查询接口
├── scheduler/ # 队列、设备绑定和运行预算
├── adapters/ # 平台适配接口，核心实现不公开
├── evidence/ # 证据记录、校验和结果打包
├── analysis/ # 品牌指标与对比分析，规划模块
└── reports/ # 报告输出生产集成还需要处理租户认证、权限隔离和幂等键作用域。仅凭一个任务编号或分享链接，不应取得其他租户的证据文件。
五 超时与重跑机制
真实设备操作可能受到网络、页面加载、登录状态和平台响应的影响。可靠的执行器需要"有限重试"，而不是遇到错误就重新提交问题。
当前本机真实采集执行器使用以下默认策略，参数可按任务调整：
| 控制项 | 默认行为 |
|---|---|
| 单次执行预算 | 300 秒，超时终止本次采集进程树 |
| 任务总预算 | 960 秒，覆盖执行与退避，进程清理存在少量额外开销 |
| 最多尝试 | 3 次，包含初次执行 |
| 重跑退避 | 首次 5 秒，第二次 10 秒 |
| 登录与验证码 | 停止并标记待处理 |
| 已识别的界面异常、限流 | 停止自动重问，保留日志 |
| 明确的网络瞬时错误与超时 | 在次数与时间预算内重跑 |
部分平台的分享链接已经生成，但公开数据尚未就绪。这种情况应先针对原链接做有界等待，而不是立即重新提问。等待时间必须计入来源阶段，否则会得到一个看似很快、实际遗漏等待的指标。
每次整题重跑都可能得到新的答案，因此必须建立独立的 attempt。不同 attempt 的截图、分享链接和引用不能拼接成一个"完整结果"。成功任务重复调用同一输出目录时直接返回已有状态；失败或中断目录保留用于检查。
当前设备锁作用于同一本机执行入口。跨主机租约、监督器被强杀后的孤儿进程回收，以及统一服务端重试调度仍需进一步建设。
六 性能优化应该看哪里
完整耗时并不等于模型生成时间，可以拆成：
完整耗时 = 启动与输入 + 回答等待 + 文字与截图
+ 对话分享 + 引用采集 + 重试与恢复通常先优化可控部分：减少不必要的页面打开、用状态检查代替无条件等待、避免重复截图，并在平台公开分享数据可用时批量读取明确的引用记录。页面结构变化或分享数据不可用时，仍需回到适配器的失败处理流程。
在一次同题采集实验中，得到以下记录：
| 平台 | 单次完整流程 | 引用记录 | 说明 |
|---|---|---|---|
| DeepSeek | 约 215.7 秒 | 11 条 | 采用手机逐条打开来源的路径 |
| 元宝 | 约 34.7 秒 | 21 条 | 20 个网址，1 条平台不提供网址的插件引用 |
| 文心 | 约 48.7 秒 | 9 条 | 采用公开分享数据提取引用 |
| 豆包 | 约 217 秒 | 29 条 | 包含人工恢复与分享数据延迟，不作为自动化性能样本 |
该实验使用一台云手机串行执行，各平台返回内容和引用数量不同。表格反映特定流程的实际记录，不是模型能力排名，也不能据此推导稳定 SLA。
元宝和文心这两次的来源数据下载解析分别约为 0.30 秒和 0.39 秒；这个口径不包含逐个打开引用网页验证正文。豆包在数据可用后的读取约为 0.56 秒，其前置等待不能省略。
七 多设备并行的设计
一台手机固定对应一个平台，可以降低应用切换和状态串扰，也能让不同平台并行推进。在设备充足、任务相互独立且资源没有竞争的理想条件下，串行总时间近似为各平台耗时之和，并行批次时间近似为最慢平台耗时加调度开销。
设备 A → 平台 A → 独立任务队列
设备 B → 平台 B → 独立任务队列
设备 C → 平台 C → 独立任务队列
同一设备串行执行，不同设备并行推进，完成一个返回一个。这能提升吞吐量、缩短批次等待，但不会直接加快单个平台的模型生成。当前已实现本机同设备互斥，四台手机并发与服务端设备分配尚未完成验收。
八 品牌监测如何建立可复核的数据基础
分析一组回答时，至少要保留问题版本、平台、采集时间、尝试编号、原始回答和证据关联。否则，同一个问题在不同时间得到的答案变化，容易被误认为采集程序出错；不同问题得到的差异，也可能被错误归因于品牌表现。
对品牌提及率这类指标，还应固定问题集和统计口径，并保存人工复核入口。引用记录只能说明平台列出了某项资料，不能自动证明资料可信，也不能证明回答中的每个事实都由该资料支持。
文件哈希用于检查保存后的证据是否变化，不等同于证明回答内容真实。完整性、可追溯性和事实可信度是三个不同层次，应分别处理。
