网页 AI 聊天记录导入链路技术文档

util6大约 11 分钟

网页 AI 聊天记录导入链路技术文档

记录日期：2026-06-11
项目背景：AssetIWeave 对话管理功能扩展
目标：在不开发浏览器插件的前提下，通过 AI + CLI + 用户目录脚本，实现 Gemini Web、Qwen Web 等网页 AI 聊天记录的采集、解析、持久化、导入和展示。

一、核心目标

这个功能的目标不是简单“导出一份 JSON”，而是搭建一条完整链路：

用户向 AI 提问
  -> AI 判断需要导出某个网页 AI 的聊天记录
  -> AI 调用 AssetIWeave CLI
  -> CLI 在用户目录下运行对应 harvester 脚本
  -> 脚本复用用户浏览器登录态，反向请求网页 API
  -> 脚本保存 raw 数据和 normalized sessions.json
  -> CLI / Engine 将 normalized 数据导入 AssetIWeave 数据库
  -> App 在对话管理页面展示和管理这些网页记录

它本质上是一种“轻插件化网页数据采集系统”：

应用核心只提供执行器、适配器协议、导入器和展示层。
具体网站的逆向 API、字段路径、解析修复脚本放在用户目录或 harvester 模板里。
AI 可以根据网页变化调整脚本，而不必频繁修改应用核心代码。

二、总体架构

关键分层

层级	职责	可变性
App UI	展示、搜索、导出、管理导入后的记录	稳定
Tauri / Engine	数据库导入、适配器执行、数据模型校验	稳定
CLI	auth 检测、harvester 安装/更新/运行、sync 入口	稳定
Harvester 模板	每个网站的采集入口、配置、脚本	中等可变
用户目录脚本	具体逆向 API、字段解析、修复逻辑	高频可变
AI	根据失败信息、raw 数据、网页变化更新解析细节	动态

三、目录设计

推荐的用户目录结构类似 Codex、Gemini CLI、vfox 一类工具：

~/.assetiweave/
  harvesters/
    gemini-web/
      harvester.json
      web-harvester.json
      conversation-adapter.json
      adapter.js
      requests/
        auth-probe.json
      scripts/
        harvest.js
        gemini-normalize.cjs
      output/
        raw/
          20260611T065958Z/
            context.json
            list-flag-0-page-1.json
            details/
              0001-c_xxx.json
        normalized/
          sessions.json
    qwen-web/
      ...

这个设计有几个好处：

应用本身不需要内置所有网站的复杂解析逻辑。
AI 修改的是用户目录下的脚本或 harvester 模板，不直接污染应用核心。
raw 数据和 normalized 数据分开保存，便于调试、回放、回归测试。
每个网站是一个独立 harvester，未来可以像插件一样安装、更新、替换。

四、登录态与授权检测

1. 为什么需要登录态

Gemini Web、Qwen Web 的聊天记录都属于用户私有数据。CLI 不能凭空访问，必须复用用户已经登录过的浏览器状态。

前提条件：

用户默认浏览器或指定浏览器中已经登录目标网站。
CLI 有权限读取浏览器 Cookie 数据库。
在 macOS 上，如果 Cookie 被 Keychain 加密，需要用户授权解密。

2. auth-detect

auth-detect 的职责是：

找到浏览器 profile，比如 Edge Default。
读取 Cookie 数据库。
通过 Keychain 解密 Cookie。
组装成 requests/auth-probe.json。

示例：

assetiweave-cli conversation web auth-detect \
  ~/.assetiweave/harvesters/gemini-web \
  --browser auto \
  --profile Default \
  --domain google.com \
  --credential cookie \
  --probe-url https://gemini.google.com/app

3. auth-check

auth-check 不能只看 HTTP 200。

原因是：Gemini 在未登录状态下也可能返回 200 页面，但页面其实是匿名首页或带登录入口的 shell 页面。

更可靠的成功条件应该是：

HTTP status = 200
响应体包含登录态才能获得的关键字段，例如 Gemini 的 "SNlM0e" token

Gemini harvester 的配置应类似：

{
  "auth_probe": {
    "request": "requests/auth-probe.json",
    "success": {
      "status": 200,
      "body_contains": "\"SNlM0e\""
    },
    "expired_when": {
      "status": 401
    }
  }
}

这个点很关键：否则 CLI 会把“匿名页面 200”误判为“已登录”，后续采集时才失败。

五、网页 API 逆向采集

1. Qwen Web

Qwen Web 更接近常规 REST / JSON 接口。

主要技术点：

复用 qianwen.com Cookie。
请求网页端真实使用的会话列表接口。
分页拉取全部会话。
请求每个会话详情。
兼容不同响应字段：
- response_messages
- qwen_response_messages
- plugin / card / think / text 等不同消息类型

Qwen 的解析关键是过滤非最终答案内容，只保留用户问题和 assistant 可读文本：

request_messages -> user_text
qwen_response_messages / response_messages -> assistant parts

已验证快照：

Qwen Web: 293 sessions / 1279 turns

2. Gemini Web

Gemini Web 更复杂，它使用 Google 内部的 batchexecute RPC。

已识别的关键 RPC：

RPC ID	服务名	用途
`MaZiqc`	`BardFrontendService.ListConversations`	会话列表
`hNvQHb`	`BardFrontendService.ListConversationTurns`	会话详情 / turn 列表
`EqPOKe`	`BardFrontendService.GetConversationTurn`	单 turn 获取，后续可研究

列表请求大致流程：

GET https://gemini.google.com/app
  -> 提取 SNlM0e / FdrFJe / cfb2h
POST /_/BardChatUi/data/batchexecute?rpcids=MaZiqc
  -> 拉取 conversation list
  -> cursor 分页
POST /_/BardChatUi/data/batchexecute?rpcids=hNvQHb
  -> 拉取每个 conversation 的 turns

Gemini 的难点：

token SNlM0e 有时不出现在匿名 200 页面里，必须 auth-check 收紧。
列表分页通过 cursor，不是普通 page number。
turn 内容是高度嵌套数组，没有稳定字段名。
assistant 回复不止纯文本，还包含：
- 生成图片
- 上传图片引用
- immersive / canvas 生成的 HTML artifact
- googleusercontent 临时资源链接
- continuation / suggestion 类型的无显式用户输入 turn

已验证快照：

Gemini Web UI Recent: 153 sessions
Gemini normalized: 153 sessions / 982 turns / 988 parts
Gemini SQLite web records: 153 sessions / 982 turns

六、数据标准化模型

所有网站最终要归一化为统一结构：

{
  "sessions": [
    {
      "external_id": "c_xxx",
      "title": "会话标题",
      "project_path": null,
      "started_at": null,
      "updated_at": "2026-03-16T03:34:08.023Z",
      "source_locator": "https://gemini.google.com/app/c_xxx",
      "source_fingerprint": "sha256...",
      "turns": [
        {
          "external_id": "r_xxx",
          "turn_index": 0,
          "user_text": "用户问题",
          "parts": [
            {
              "role": "assistant",
              "kind": "text",
              "text": "回答内容"
            }
          ]
        }
      ]
    }
  ]
}

part 类型映射

现有数据模型支持：

text
code_block
command
tool
file_change
subagent
metadata

网页 AI 的特殊内容需要映射到这些通用类型：

网页内容	归一化策略
普通回答	`assistant/text`
代码块 / HTML artifact	`assistant/code_block`
生成图片 URL	`assistant/text`，用 Markdown 链接保存
上传附件 URL	追加到 `user_text` 的 `User attachments` 段落
无显式用户输入的 continuation	使用占位 user_text：`[Gemini continuation without visible user prompt]`
结构化但暂不展示的数据	`metadata_json` 或后续扩展为专门类型

这样做的目标不是完美还原网页 UI，而是保证信息不丢失，并能被搜索、导出和展示。

七、持久化与导入

1. Harvester 输出

每次运行 harvester 会生成两类数据：

output/raw/{run_id}/
output/normalized/sessions.json

raw 用于排错和回放：

列表响应
详情响应
context/token 提取状态
detail failure 信息

normalized 用于导入：

应用不直接理解每个网站的 raw 格式。
只消费统一的 sessions.json。

2. Adapter 协议

每个 harvester 同时提供 conversation-adapter.json 和 adapter.js。

adapter 的职责是把目录输入转换为标准 NDJSON 输出：

source.location = ~/.assetiweave/harvesters/gemini-web/output/normalized
adapter.js 读取 sessions.json
adapter.js 按协议输出 session item
engine 接收并导入

3. SQLite 表

网页记录导入到 web record 表，而不是混入 Codex/Claude/OpenCode 的 live conversation 表：

web_record_sessions
web_record_turns
web_record_parts
web_record_questions
web_record_question_turns

导入流程：

根据 source 清理旧 web records。
插入 sessions。
插入 turns。
插入 parts。
根据 turn 自动生成 question 分组。
更新 conversation_sources.last_synced_at 和 last_sync_status。
写入 conversation_sync_runs。

八、AI + CLI 的协作方式

这个方案的核心不是让 AI “打开浏览器截图点按钮”，而是让 AI 做更适合它的事情：

调用 CLI 检查登录态。
运行 harvester。
分析失败日志和 raw 响应。
修改用户目录或模板里的解析脚本。
编写最小回归测试。
重新运行采集。
同步数据库。
用 SQLite 或 App UI 验证结果。

也就是说，AI 是“解析器维护者”，CLI 是“稳定执行器”。

这个分工很重要：

CLI 不应该把 Gemini/Qwen 的所有细节写死在核心里。
AI 不应该绕过 CLI 直接写数据库。
脚本可以变，协议和导入模型要稳定。

九、关键技术点清单

1. 浏览器登录态复用

Chrome / Edge / 默认浏览器 profile 探测
Cookie DB 读取
macOS Keychain 解密
domain cookie 过滤
User-Agent / Cookie header 复用
登录态 false positive 检测

2. 网页 API 逆向

查找网页端真实接口
区分 App API 和 Web API
处理 batchexecute frame 格式
提取动态 token
处理 cursor 分页
处理列表去重
处理详情失败重试

3. Raw 数据留存

每次 run 独立 raw_run_dir
保存 list page
保存 detail response
保存 context 信息
允许后续离线重放 parser

4. 标准化解析

session / turn / part 统一模型
user text 多路径提取
assistant text 多候选提取
过滤 think/plugin/card 噪声
保留 artifact、media、attachment
生成稳定 external_id 和 fingerprint

5. 插件化执行

harvester.json 描述包
web-harvester.json 描述 auth/list/detail/output 配置
conversation-adapter.json 描述导入协议
scripts/harvest.js 执行真实采集
adapter.js 把 normalized JSON 转成 engine 可读协议

6. 数据库导入

source 级幂等导入
web record 与 live conversation 分表
turn -> question 自动聚合
sync run 记录
dry-run 支持

7. App 展示

Web Records 独立入口
按 adapter/source 过滤
session/turn/question 计数
detail 展示 parts
Markdown 导出

8. 测试与验证

parser 单元测试
harvester install/update/run 测试
auth-check 测试
normalized 文件统计
SQLite 表计数验证
UI 列表与网页列表对照

十、主要风险

1. 非官方接口变化

网页 API、DOM、batchexecute payload 都可能变。

缓解方式：

保留 raw 数据。
parser 脚本外置。
用 AI 快速根据 raw 修复解析器。
给关键解析路径加测试。

2. 登录态失效

Cookie 可能过期，Keychain 授权可能失败。

缓解方式：

auth-check 必须做内容级检查。
错误提示要明确要求重新 auth-detect。
不把 200 页面等同于登录成功。

3. 数据隐私

聊天记录是用户私有数据。

原则：

raw 和 normalized 都保存在本机用户目录。
不上传第三方。
文件权限使用 0600 / 目录 0700。
CLI 执行脚本需要显式 --yes。

4. 脚本执行安全

harvester 本质上是本地脚本执行。

需要：

官方模板和外部包区分。
manifest 校验。
trusted hash / trust state。
用户确认执行。
尽量限制脚本职责：采集和标准化，不直接写核心数据库。

5. 内容完整性

网页 AI 不只有文字。

Gemini 已经出现：

图片生成
图片上传
HTML artifact
continuation turn

后续可能还有：

Canvas 多版本
视频
notebook
文件附件
多分支回答

这要求 normalized model 后续可能扩展专门的 image / artifact / attachment part kind。

十一、后续增强方向

1. Harvester SDK

把常见能力封装成 SDK：

loadAuthProbe()
fetchAppContext()
batchExecute()
parseFrames()
writeRaw()
writeNormalized()

这样不同网站脚本只写差异逻辑。

2. Parser 回放命令

新增命令：

assetiweave-cli harvester replay gemini-web --raw-run 20260611T065958Z

用于不重新请求网页 API，只根据 raw 数据重跑 parser。

3. 内容类型扩展

考虑扩展数据模型：

image
attachment
artifact
link
reference

这样 Gemini/Qwen 的多模态内容能更自然展示。

4. 并发和限流

当前详情请求偏串行，稳定但慢。

后续可以：

限速并发
失败重试
断点续采
只增量更新 changed sessions

5. 站点包分发

让 harvester 像插件一样：

assetiweave-cli harvester install gemini-web
assetiweave-cli harvester update gemini-web
assetiweave-cli harvester install community-site --from &lt;url&gt;

同时区分：

official
community
local

6. AI 修复工作流

当采集失败时，可以形成固定 prompt/workflow：

1. 读取 context.json
2. 查看失败 list/detail raw
3. 对比旧 parser 输出
4. 定位字段变化
5. 修改 scripts/*normalize*
6. 添加 fixture test
7. replay raw
8. live harvest
9. sync database

这就是“AI + CLI + 外置解析脚本”的真正价值。

十二、当前实现状态

截至 2026-06-11，已验证：

Qwen Web:
  normalized: 293 sessions / 1279 turns

Gemini Web:
  webpage Recent UI: 153 sessions
  normalized: 153 sessions / 982 turns / 988 parts
  SQLite web records: 153 sessions / 982 turns

Gemini 已补齐的内容：

原先被跳过的 assistant-only continuation turn
HTML artifact 代码块
generated media 链接
uploaded media 链接
更严格的 auth-check 成功条件

十三、结论

这条链路技术上可行，而且比浏览器插件更适合作为 AssetIWeave 的“扩展能力”：

浏览器插件适合实时注入、DOM 监听、用户主动点击导出。
AI + CLI + harvester 适合离线采集、逆向 API、批量导入、自动修复解析器。

最佳架构不是把所有网站逻辑写死到 App 中，而是：

App 核心稳定
CLI 负责执行
Engine 负责导入
Harvester 负责采集
用户目录保存脚本和产物
AI 负责根据变化维护解析器

这样既保留了插件化扩展能力，也避免了每个网站变化都污染应用核心代码。