现代浏览器扩展环境下的端侧 AI 推理系统架构与工程实现规范

摘要

本文档系统阐述在现代浏览器 Manifest V3（MV3）沙箱规范及跨平台（Chromium / Gecko）扩展环境下，构建端侧大语言模型（LLM）推理、本地向量密集检索（Dense Retrieval RAG）及多模态交互系统的工程架构与实现规范。针对浏览器后台 Service Worker 缺乏 DOM 与 WebGPU 支持、进程生命周期短暂（30秒至5分钟闲置销毁）、内容安全策略（CSP script-src 'self'）限制外部二进制加载、以及端侧硬件显存/内存物理受限等核心问题，本文提出基于离屏宿主容器（Offscreen Document Host）、动态 Token 预算调节器、本地自托管 ONNX Runtime Web 算力引擎与基于 IndexedDB 的向量索引系统的完整技术实现方案。

1. 系统设计目标与约束边界

1.1 系统定位与功能边界

端侧 AI 浏览器扩展系统旨在将自然语言理解、长文本层次化总结、网页语义检索及启发式行为识别等 AI 计算全量下沉至用户端侧设备（CPU / GPU / NPU / 统一内存）。系统架构必须满足以下刚性工程约束：

  1. 绝对网络隔离（Zero Network I/O for Inference）：除首次拉取经过哈希校验的静态模型权重切片外，所有推理计算、向量提取、特征匹配及数据持久化必须在本地闭环完成，禁止向任何远端服务器发起与推演相关的 HTTP/WebSocket 数据包；
  2. 零依赖离线执行（Offline Resilience）：在断开互联网物理连接的情况下，核心功能（包括本地大模型问答、阅读分析、时光胶囊知识库检索）保持 100% 可用；
  3. 低资源占用与系统稳定性（Resource Concurrency & Stability）：显存占用受控在 1.5 GB 以内，推理期间主界面保持 60 fps 渲染帧率，杜绝阻断浏览器主事件循环。

1.2 运行时沙箱限制（Manifest V3 Sandbox Constraints）

在现代浏览器的安全模型下，扩展执行环境具有高度碎片化与隔离性特征：

+-------------------------------------------------------------------------------+
| Chromium / Gecko 浏览器主进程                                                  |
+-------------------------------------------------------------------------------+
       │                                                 │
       ▼                                                 ▼
+-----------------------------+           +-----------------------------+
| Background Service Worker   |           | 渲染进程 / 标签页 DOM        |
| - 严格无 DOM 树             |           | - Content Scripts 隔离沙箱  |
| - 无法获取 navigator.gpu     |           | - 受页面 CSP 及脚本隔离限制  |
| - 闲置 30s ~ 300s 强制终止  |           | - 页面刷新即销毁            |
+-----------------------------+           +-----------------------------+
       │                                                 │
       │ (跨进程通信)                                     │ (跨进程通信)
       ▼                                                 ▼
+-------------------------------------------------------------------------------+
| 算力托管沙箱 (Offscreen Document / Gecko Hidden Document)                       |
| - 具备完整 DOM 环境                                                            |
| - 支持原生 WebGPU (navigator.gpu) 与 WebAssembly SIMD                          |
| - 独立事件循环与独立显存上下文                                                 |
| - 缺陷：无直接 `chrome.storage` 访问权限                                       |
+-------------------------------------------------------------------------------+
  • Service Worker 算力阻断：Chrome MV3 彻底移除了具备持久 DOM 的 Background Page，采用基于事件激活的 Service Worker。Service Worker 环境不暴露 window、document 以及 navigator.gpu 接口，无法直接挂载 WebGPU 计算管线；
  • 进程生命周期非预期销毁：Service Worker 在无待处理事件时会自动进入休眠状态，最长存活时间被限制在 5 分钟以内。若推理任务状态保存在 Worker 内存中，会导致严重的推演中断；
  • 内容安全策略（CSP）对动态二进制的封锁：MV3 默认策略包含 script-src 'self'; object-src 'self'，禁止通过 eval()、new Function() 或远程 CDN URL 加载执行任何 JavaScript 与 WebAssembly 模块。

1.3 核心性能与服务等级指标（SLO / QoS）

性能维度 衡量指标 目标阈值（Target SLA） 降级阈值（Degraded SLA）
首字延迟 (TTFT) Time to First Token $\le 800\text{ ms}$（显存就绪状态） $\le 2500\text{ ms}$
生成吞吐率 Inference Throughput $\ge 15\text{ tokens/s}$（Apple M系列 / RTX系列） $\ge 5\text{ tokens/s}$（核显环境）
显存驻留限制 Resident VRAM Cap $\le 1200\text{ MB}$（1.5B INT4） $\le 2500\text{ MB}$（3B INT4）
向量检索耗时 Vector Search Latency $\le 15\text{ ms}$（10,000 切片数据量） $\le 50\text{ ms}$
主线程阻塞时长 Main Thread Block Time $0\text{ ms}$（完全交由独立 Offscreen 线程） $\le 16\text{ ms}$

2. 跨进程协作与多宿主隔离拓扑

2.1 整体拓扑三层模型

为解决上述沙箱隔离矛盾，系统划分为三层松耦合物理架构：

  1. 表现层（Presentation Layer）：由 popup/、sidepanel/、options/ 及注入页面的 content/ 脚本组成。负责用户交互渲染、DOM 文本抽取及指令派发；
  2. 路由协调层（Orchestration Layer）：由 background.js（Service Worker）充当无状态中央路由网关。负责监听扩展全局事件、维护配置缓存、管理算力容器生命周期及调度长连接通道；
  3. 计算宿主层（Execution Host Layer）：由独立运行的 offscreen.html / offscreen.js 容器构成。在隔离的沙箱内持有 WebGPU 设备实例、模型静态图、ONNX Runtime Web 运行时以及 IndexedDB 数据库引擎。

2.2 Chromium Offscreen 宿主容器机制

在 Chromium 109+ 中，系统调用 chrome.offscreen.createDocument 声明初始化参数：

// background.js: 动态算力容器托管
const OFFSCREEN_PATH = 'offscreen.html';

async function ensureOffscreenHost() {
  if (await chrome.offscreen.hasDocument?.()) {
    return;
  }
  await chrome.offscreen.createDocument({
    url: OFFSCREEN_PATH,
    reasons: [chrome.offscreen.Reason.WORKERS || 'WORKERS'],
    justification: 'Hold WebGPU device context and execute local LLM inference pipelines.'
  });
}

离屏文档生命周期由协调层统一监控，当所有推理会话与后台索引任务完结且闲置超过指定阈值时，可由路由层发出销毁指令以彻底归还 GPU 显存。

2.3 Gecko (Firefox) 宿主兼容抽象与降级

Firefox 目前的 MV3 实现尚未支持 chrome.offscreen API，但其 Background 环境允许声明包含 DOM 的脚本宿主。为了实现同一套代码库构建跨平台扩展，系统在底层构建了适配器接口：

// shared/runtime-adapter.js: 跨引擎算力宿主自适应
export async function initializeComputationHost() {
  // 1. Chromium 体系：采用 Offscreen Document
  if (typeof chrome !== 'undefined' && chrome.offscreen?.createDocument) {
    if (!(await chrome.offscreen.hasDocument())) {
      await chrome.offscreen.createDocument({
        url: 'offscreen.html',
        reasons: ['WORKERS'],
        justification: 'WebGPU runtime container'
      });
    }
    return;
  }

  // 2. Gecko (Firefox) 体系：在 Background DOM 挂载隐藏 iframe 作为隔离算力环境
  if (typeof document !== 'undefined') {
    if (!document.getElementById('omni-compute-sandbox')) {
      const sandbox = document.createElement('iframe');
      sandbox.id = 'omni-compute-sandbox';
      sandbox.src = chrome.runtime.getURL('offscreen.html');
      sandbox.style.display = 'none';
      document.documentElement.appendChild(sandbox);
    }
    return;
  }

  throw new Error('UNSUPPORTED_HOST_ENVIRONMENT: Neither offscreen nor DOM iframe is available.');
}

2.4 基于双向 MessagePort 的流式 RPC 通信协议

由于大语言模型生成具有序列依赖性与长时间计算特征，传统的 chrome.runtime.sendMessage 基于单个请求响应的无状态通信模型无法支撑 Token 级别的平滑流式推送。系统在底层建立了命名为 omni-offscreen 的长连接通道（chrome.runtime.Port）。

2.4.1 协议数据帧规范 (Protocol Frame Specification)

通信信元划分为四类标准结构体：

  1. 推演发起帧 (INFER_STREAM)：
    interface InferStreamRequest {
  type: 'INFER_STREAM';
  requestId: string;           // UUIDv4，用于单路多路复用上下文路由
  promptKey: string;           // 对应 PROMPT_SPEC 规则集键名
  prompt: string;              // 组装后的完整 Prompt 输入
  settings: ResolvedSettings;  // 协调层预先解包的用户偏好数据
}
  2. 增量数据切片帧 (INFER_CHUNK)：
    interface InferChunkResponse {
  type: 'INFER_CHUNK';
  requestId: string;
  text: string;                // 当前步增量生成的文本片段 (Delta)
}
  3. 推演终止帧 (INFER_END)：
    interface InferEndResponse {
  type: 'INFER_END';
  requestId: string;
  metrics?: {
    promptTokens: number;
    completionTokens: number;
    totalDurationMs: number;
  };
}
  4. 异常帧 (INFER_ERROR)：
    interface InferErrorResponse {
  type: 'INFER_ERROR';
  requestId: string;
  errorCode: 'NO_WEBGPU' | 'CONTEXT_OVERFLOW' | 'MODEL_LOAD_FAIL' | 'ABORTED';
  message: string;
}

3. 端侧大语言模型（LLM）推理引擎与显存生命周期

3.1 模型选型矩阵与端侧量化权衡

在端侧消费级设备运行，权衡核心在于：模型规模（参数量）、权重精度（量化比特数）与推理质量（困惑度/指令遵循度）。

系统在底层维护的基准模型选型策略矩阵如下：

                ▲ 推理能力 / 逻辑深度
                │
                │                           [Qwen2.5-3B-Instruct]
                │                           - q4f32_1 (~2.35 GB)
                │                           - 复杂长文论证 / 深度反方分析
                │
                │        [Qwen2.5-1.5B-Instruct] (默认主力)
                │        - q4f16_1 (~1.15 GB)
                │        - 中英双语平衡 / 极佳结构化输出 / 吞吐率 > 20 tps
                │
                │   [Llama-3.2-1B-Instruct]
                │   - q4f16_1 (~0.88 GB)
                │   - 英文逻辑严密 / 极低显存开销
                │
                │ [SmolLM2-360M-Instruct]
                │ - q4f16_1 (~320 MB)
                │ - 秒级冷启动 / 保底轻量分类
                └────────────────────────────────────────────► 部署轻量化 / 硬件普适性
  • 量化方案 q4f16_1 机制：将模型权重（Weights）量化为 4-bit 整数存储，矩阵乘计算时在 GPU 着色器内部反量化为 16-bit 浮点数（FP16）与激活值（Activations）相乘。相较于 FP16 原始权重，显存占用直降 72%，同时在 MMLU、GSM8K 等主流评测集上精度损失控制在 2.5% 以内。

3.2 WebGPU 计算管线与 WGSL Shader 编译机制

系统采用基于 Apache TVM 深度学习编译技术栈的 WebLLM（MLCEngine）运行 WebGPU 计算图。与传统图形渲染不同，LLM 推理包含大量自注意力机制（Multi-Head Attention）与转置矩阵运算（GEMV / GEMM）。

在 WebGPU 环境下，着色器由 WebGPU Shading Language（WGSL）编写，并在客户端设备驱动中进行即时编译（JIT Compilation）。为消除首轮交互中的卡顿问题，引擎在加载流程中内置预热协议（Warmup Protocol）：

[模型权重文件加载完毕]
          │
          ▼
[触发 Dry-Run 预热推理] ──► 输入虚拟微型序列 (Length = 4)
          │
          ▼
[驱动强制编译 WGSL Shader 管线并固化至 GPU 硬件 Cache]
          │
          ▼
[对外发出 MODEL_STATUS: ready 广播]

3.3 显存防抖与加载竞态锁（Race Condition Defense）

在实际运行环境中，用户频繁切换配置模型或快速触发操作，极易引发加载竞态条件。在底层推理库设计中，engine.reload() 通常内部顺序执行 unload() 与 load()。如果上一次 reload() 尚未结清即发起新的重载，会导致底层的异步 Promise 被以 AbortError 终止，进而出现外部感知成功、内部管线实际为空的“假就绪状态”，导致随后的每一次推演抛出 ModelNotLoadedError。

为彻底解决该竞态缺陷，系统在 offscreen.js 中构建了基于单例 Promise 的并发锁与排队状态机：

// offscreen.js: 单实例原子化加载互斥机制
let loadedModelKey = null;
let modelLoadPromise = null;
let pendingModelId = null;

export async function ensureModel(modelKey, modelId) {
  const targetId = modelId || resolveModelId(modelKey);

  // 1. 幂等判定：当前模型已就绪且无在途加载，直接返回
  if (loadedModelKey === targetId && !modelLoadPromise) {
    return;
  }

  // 2. 竞态排队处理：已有在途加载时，严禁并发调用 reload()
  if (modelLoadPromise) {
    if (pendingModelId === targetId) {
      return modelLoadPromise; // 同目标任务，直接合并等待
    }
    // 异目标任务：等待当前运行中任务结算完成后串行发起，杜绝中止引起的底层泄漏
    return modelLoadPromise
      .catch(() => {})
      .then(() => ensureModel(modelKey, modelId));
  }

  pendingModelId = targetId;
  modelLoadPromise = (async () => {
    loadedModelKey = null;
    broadcastStatus('downloading', 0, `Initializing ${targetId}`);

    try {
      const gpuAvailable = await verifyWebGPUAdapter();
      if (!gpuAvailable) throw new Error('NO_WEBGPU');

      const engine = await getMLCEngineInstance();
      await engine.reload(targetId);

      // 强校验：通过内部状态检查确保模型计算图实际已映射
      assertEngineUsable(engine);

      loadedModelKey = targetId;
      broadcastStatus('ready', 1, targetId);
    } catch (err) {
      loadedModelKey = null;
      broadcastStatus('error', 0, err.message);
      throw err;
    }
  })().finally(() => {
    modelLoadPromise = null;
    pendingModelId = null;
  });

  return modelLoadPromise;
}

3.4 KV Cache 动态管理与显存上限保护

在自回归生成解码阶段，键值缓存（KV Cache）的内存消耗随生成序列长度呈线性递增。若长文本对话多轮累积且不进行显存回收，极易触发 WebGPU 设备的 Out of Memory (OOM) 致命错误。

系统在底层运行时中应用了精细化缓存淘汰策略：

  1. 单次推理上限硬绑定：基于当前任务分配的最大 Token 数（$T_{\text{out}}^{\text{req}}$），预先分配固定尺寸的显存环形缓冲区（Ring Buffer），杜绝无限制动态再分配引发的显存碎片化；
  2. 会话重置显存清空（Explicit KV Eviction）：在单次推演结清（INFER_END）或用户发起重置时，显式调用引擎的底层清除接口释放已缓存的前向激活张量，将显存回缩至基线驻留水位。

4. 长文本动态 Token 预算系统与分层摘要算法

4.1 物理上下文窗口的刚性约束与分词膨胀

消费级端侧小模型的编译上下文窗口（Context Window）通常硬性限制为 $4096$ Tokens（低内存模式为 $2048$ Tokens）。然而，在浏览器应用场景中，长篇深度报道、研报或技术文档的字数常在 $10,000$ 至 $50,000$ 字符之间。

特别对于中文等非拉丁语系，分词算法（BPE / Byte-Fallback）通常具有很高的 Token 膨胀比：
$$\text{Tokens}{\text{Chinese}} \approx 0.95 \sim 1.15 \times \text{Chars}{\text{Raw}}$$
若不加控制将整页文本拼接输入，模型将直接报错终止。

4.2 动态 Token 预算分配数学模型

系统建立了数学化的动态预算调配器（shared/token-budget.js），在每次推演前精确划定净可用预算：

$$T_{\text{avail}} = W_{\text{ctx}} - T_{\text{out}}^{\text{req}} - T_{\text{tmpl}}$$

其中：

  • $W_{\text{ctx}}$：当前加载模型的硬性上下文窗口上限（如 4096）；
  • $T_{\text{out}}^{\text{req}}$：当前业务场景所需的最小补全 Tokens（Clamped Completion Target）；
  • $T_{\text{tmpl}}$：Chat Template（如 <|im_start|>system...）固化的元控制字符保留预算（设为 64）。
// shared/token-budget.js: 动态上下文预算分配
export function calculateDynamicBudget(contextWindow, requestedOutputTokens) {
  const CHAT_TEMPLATE_MARGIN = 64;
  const MIN_COMPLETION_FLOOR = 128;

  // 输出预算约束：生成配额不得挤占整个物理窗口的 40% 以上
  const maxOutputAllowed = Math.floor(contextWindow * 0.4);
  const clampedOutput = Math.max(
    MIN_COMPLETION_FLOOR,
    Math.min(requestedOutputTokens, maxOutputAllowed)
  );

  // 计算留给输入上下文（System + User Prompt）的绝对安全上限
  const maxPromptTokens = contextWindow - clampedOutput - CHAT_TEMPLATE_MARGIN;

  return {
    completionTokens: clampedOutput,
    promptTokenCeiling: maxPromptTokens
  };
}

针对不同的交互指令，系统定义严格的静态规划表（PROMPT_SPEC）：

export const PROMPT_SPEC = {
  tone:          { maxTokens: 1024, source: 'text',    longInput: 'head' },
  roast:         { maxTokens: 192,  source: 'text',    longInput: 'head' },
  summary:       { maxTokens: 1024, source: 'article', longInput: 'merge' },
  bias_advocate: { maxTokens: 1024, source: 'article', longInput: 'digest' },
  margin_notes:  { maxTokens: 768,  source: 'article', longInput: 'digest' }
};

4.3 递归 Map-Reduce 长文本分层提炼引擎

当输入文章规模突破单次安全预算 $T_{\text{avail}}$ 时，系统触发流式 Map-Reduce 分层处理管道：

[原始文章长文本流]
        │
        ▼ (按标点与自然段落实施分片)
{ Chunk 1 }      { Chunk 2 }      { Chunk 3 } ... { Chunk N } (每个分片 <= 600 Tokens)
    │                │                │               │
    ▼ [Map 阶段]     ▼ [Map 阶段]     ▼ [Map 阶段]    ▼ [Map 阶段]
(提取核心要点)   (提取核心要点)   (提取核心要点)  (提取核心要点)
    │                │                │               │
    ▼                ▼                ▼                ▼
[ Point 1 ]      [ Point 2 ]      [ Point 3 ] ... [ Point N ]
        │
        └─────────────────┬───────────────────────────┘
                          │ (拼接中间笔记并重新校验 Token 预算)
                          ▼
                  [ Reduce 阶段 ]
         (执行全局结构化整合与逻辑终审)
                          │
                          ▼
            [ 最终输出结构化高精要报 ]
  1. Map 阶段（局部提炼）：
    • 输入文本被顺序切割为多个固定安全分片（每片最大 600 Tokens）；
    • 各分片采用轻量 Prompt 进行单轮要点提取，输出配额限定在 CHUNK_MAX_TOKENS = 320；
  2. Reduce 阶段（全局收敛）：
    • 将各分片提取出的要点文本重新组装为紧凑上下文；
    • 在统一的全局 Prompt 指令下生成综合性结论；
  3. 熔断与断尾保护（Circuit Breaking）：
    • 设置单任务处理分片硬上限 MAX_CHUNKS = 20。当超长文本（如数十万字的小说或完整代码库）输入时，处理完第 20 分块后触发熔断，并向前端回传诚实的状态截断通知，防止端侧计算资源发生死锁式无休止消耗。

5. 纯本地向量检索（RAG）系统设计与实现

5.1 本地知识库索引架构与数据流图

“时光胶囊（Time Capsule）”与“知识星图”功能由基于纯前端技术的检索增强生成（RAG）系统驱动。整个流水线包含数据抓取、语义切片、高维向量嵌入、本地存储与余弦相似度匹配：

[用户浏览网页] ──► [Readability 正文提取] ──► [语义感知重叠分块]
                                                     │
                                                     ▼
                                          [Local Embedding Model]
                                          (bge-small-zh-v1.5)
                                                     │
                                                     ▼ 提取 512维 Float32Array
                                          [写入 IndexedDB 数据库]
                                          (stores: capsules, vectors)
                                                     │
                                                     ▼ 用户查询
[用户侧栏提问] ──► [查询向量化] ──► [内存点积扫描] ──► [Top-K 注入 Prompt 上下文]

5.2 ONNX Runtime Web 深度本地化与 MV3 CSP 规则兼容

在现代浏览器扩展中引入向量嵌入模型（Embedding Model），通常采用 transformers.js。然而该库默认行为会动态从公网 CDN（jsdelivr / huggingface.co）拉取底层 ort-wasm-simd-threaded.wasm 文件。该行为会直接违反 Chrome Web Store 针对 MV3 的强制性内容安全策略（script-src 'self'），导致请求直接被浏览器网络层阻断。

工程化重构实现方案：

  1. 将 ONNX Runtime Web 编译后的全量 .wasm 静态资产解压内嵌至扩展的安装包目录 npm/onnxruntime-web.../dist/ 中；
  2. 在 offscreen.js 中显式重载底层环境配置，强行劫持 WASM 文件的加载基准路由：
// offscreen.js: 本地 WASM 资产劫持与线程隔离
import { env, pipeline } from './vendor/transformers/transformers.js';

// 强制指向扩展根目录本地静态资源，彻底切断外部网络请求
const LOCAL_ORT_ASSETS = 'npm/onnxruntime-web@1.31.0-dev.20260914-8d85527a0/dist/';
env.backends.onnx.wasm.wasmPaths = chrome.runtime.getURL(LOCAL_ORT_ASSETS);

// 禁用多线程以消除跨域隔离（Cross-Origin-Isolation）对 SharedArrayBuffer 的硬性依赖
env.backends.onnx.wasm.numThreads = 1;
env.allowLocalModels = true;
env.allowRemoteModels = false; // 严禁远程拉取模型，必须从本地 CacheStorage 或包内读取

5.3 标点感知的重叠滑动窗口切片算法

为确保向量表示能够精准捕获段落的核心语义，避免由于固定字符硬切断导致的语义碎裂，切片引擎（shared/capsule-chunk.js）实现了基于标点与滑动重叠（Sliding Overlap）的切分算法：

// shared/capsule-chunk.js: 语义感知重叠切片
export function chunkForEmbedding(text, maxChunkLen = 300, overlapLen = 40) {
  // 匹配中英文句子终止标点符号
  const SENTENCE_DELIMITERS = /(?<=[。！？；\n!?;]+)/;
  const rawSentences = text.split(SENTENCE_DELIMITERS).filter(s => s.trim().length > 0);

  const chunks = [];
  let currentChunk = '';

  for (const sentence of rawSentences) {
    if ((currentChunk + sentence).length <= maxChunkLen) {
      currentChunk += sentence;
    } else {
      if (currentChunk.trim().length > 0) {
        chunks.push(currentChunk.trim());
      }
      // 提取前一个分块末尾的 overlapLen 长度字符串作为新分块的前置上下文
      const overlapContext = currentChunk.slice(-overlapLen);
      currentChunk = overlapContext + sentence;
    }
  }

  if (currentChunk.trim().length > 0) {
    chunks.push(currentChunk.trim());
  }

  return chunks;
}

5.4 基于 IndexedDB 的向量存储与点积相似度检索

系统通过底层的 shared/idb.js 维护浏览器原生 IndexedDB 实例。由于每次保存的向量均为单位化向量（L2-Normalized Embedding），向量间的余弦相似度计算被直接等价简化为向量点积（Dot Product）：

$$\text{Sim}(\vec{Q}, \vec{D}) = \vec{Q} \cdot \vec{D} = \sum_{i=1}^{d} Q_i \cdot D_i$$

// shared/idb.js: 内存级向量点积与 Top-K 堆排序
export function searchSimilarChunks(queryVector, candidates, topK = 5) {
  const scores = [];
  const dim = queryVector.length;

  for (let i = 0; i < candidates.length; i++) {
    const targetVector = candidates[i].embedding;
    let dotProduct = 0.0;
    
    // 循环展开加速单精度浮点连续乘加计算
    for (let d = 0; d < dim; d++) {
      dotProduct += queryVector[d] * targetVector[d];
    }
    
    scores.push({
      item: candidates[i],
      similarity: dotProduct
    });
  }

  // 排序并截取相似度最高的 Top-K 结果注入上下文
  scores.sort((a, b) => b.similarity - a.similarity);
  return scores.slice(0, topK);
}

在单次针对几千条切片的扫描过程中，纯 JavaScript 执行单精度浮点向量点积运算仅需 5 ~ 12 毫秒，完全满足人机交互的即时响应标准。

6. 特征工程与端侧复合判决流水线

6.1 网页暗黑套路雷达（Dark Pattern Radar）双层判决流水线

针对电商、资讯等网页中存在的“虚假倒计时紧迫感”、“误导性默认勾选”、“退订陷阱”等暗黑模式（Dark Patterns），全量调用 LLM 分析会导致极其高昂的计算负载。系统设计了“启发式正则引擎（Heuristic Filter）+ 端侧大模型语义裁决”的双层混合过滤架构：

[页面内容进入 Content Script]
              │
              ▼
    [第一层：轻量规则启发式引擎]
    - 正则模式匹配（如 "仅剩\s*\d+\s*件"）
    - DOM 结构异常扫描（如透明度接近 0 的表单隐藏元素）
    - 时间消耗：< 2ms，CPU 占用率忽略不计
              │
              ├─── [未命中任何特征] ──► 静默终止，不干扰浏览
              │
              ▼ [命中可疑模式候选集]
    [第二层：端侧 LLM 意图裁决]
    - 仅抽取命中特征的上下文小片段（<= 150 字符）
    - 发送至 Offscreen 模型进行意图分类判断
    - 区分“正常商品库存提示”与“虚假倒计时诱导”
              │
              ▼
    [在页面原位注入高亮警告 Badge]

6.2 观点客观度天平（Bias Meter）多维度打分与反方推演

系统通过对网页论述中的情感修饰词密度、单向信息源引用率进行特征统计，构建客观度基础量化分值：

$$\text{BiasScore} = \alpha \cdot \frac{N_{\text{extreme_words}}}{N_{\text{total_words}}} + \beta \cdot \text{SentimentPolarity}$$

当文章得分突破设定阈值时，自动激活端侧大模型的辩证推理（Devil's Advocate）模块，要求其基于现有事实，推导并生成至少两个相反视角的合理反论，辅助读者破除信息茧房。

6.3 页面结构化正文提纯算法实现

针对网页复杂的广告悬浮层、导航菜单栏、侧边推荐及版权页尾噪点，系统在 Content Script 阶段集成了自包含的 Readability 启发式提纯引擎：

  1. 候选节点评分（Node Scoring）：遍历 DOM 树中的 <p>、<div>、<article> 节点，根据其内部包含的逗号、标点符号频率以及文本长度累积分值；
  2. 链接密度惩罚（Link Density Penalty）：计算节点内部 <a> 标签所占字符长度占总文本的比例，若链接密度超过 0.25 则大幅扣除评分，精准剥离导航条与推荐列表；
  3. 清洗输出：剥离所有内联样式与潜在追踪代码，仅将标准 Markdown 结构化纯文本传递给下游推理引擎，显著削减 Token 浪费。

7. 底层工程边界缺陷分析与系统加固

7.1 Offscreen Document 环境下 chrome.storage 访问违规

  • 缺陷机理：Chrome 官方虽然允许在 Offscreen Document 中执行基础 Web API，但在其内部 JavaScript 运行上下文中，chrome.storage 命名空间是未定义的（undefined）。如果在 Offscreen 内部直接调用，会导致抛出未捕获的全局异常；
  • 加固方案：架构规定“Offscreen 纯算力容器原则”。Offscreen 严禁直接导入或调用任何扩展存储 API；所需的所有用户配置（模型键名、温度系数、偏好语言等）必须由 Background Service Worker 统一读取，并在派发推演消息帧时作为附加字段（msg.settings）透传注入。

7.2 WebGPU Adapter 探测与降级矩阵

  • 缺陷机理：部分旧款集成显卡或虚拟机环境下虽然存在 navigator.gpu 对象，但调用 navigator.gpu.requestAdapter() 时会返回 null。若直接进入模型初始化，底层 C++/Wasm 模块会引发不可恢复的崩溃；
  • 加固方案：实现严密的防御性探测函数：
export async function verifyWebGPUAdapter() {
  if (!navigator.gpu) return false;
  try {
    const adapter = await navigator.gpu.requestAdapter({
      powerPreference: 'high-performance'
    });
    return !!adapter;
  } catch {
    return false;
  }
}

7.3 Service Worker 闲置终止对抗与连接持久化

  • 缺陷机理：MV3 下的 Service Worker 极其容易在标签页切换或用户无输入 30 秒内被浏览器挂起或彻底关闭，导致连接中断；
  • 加固方案：
    1. 心跳保活：在推演运行期间，UI 端通过持续的 Port 交互触发 Worker 事件循环，阻止其进入休眠；
    2. 断连重试（Reconnection Backoff）：在前端 UI 维持弹性连接器，捕获 port.onDisconnect 事件，一旦检测到连接掉线，在 500ms 内发起自动重连并尝试恢复当前任务状态。

7.4 TypedArray 内存池优化与垃圾回收调优

在高频处理多页长文本向量化与分词编码时，若频繁调用 new Float32Array(...)，会触发 V8 引擎新生代（Young Generation）垃圾回收器的高频回收停顿。

加固对策：

  • 在 offscreen.js 内部建立单例的 ArrayBuffer 静态内存池（Memory Arena），多次推演过程复用预分配的缓冲区内存视图；
  • 向量点积计算完成后，主动解绑超大中间数组的闭包引用，将长生命周期大对象及时移出堆栈，确保进程物理内存常驻集（Resident Set Size, RSS）平稳受控在安全水位。

8. 网络隔离验证与扩展权限安全边界

8.1 零外部网络传输（Zero Network I/O）的形式化验证

为确保系统对隐私承诺的技术可审计性，任何构建产物均须通过严格的网络活动静态扫描与动态黑盒审计：

  1. 静态代码审查：扩展源代码目录中严禁引入任何包含远程数据上报的 SDK（如 Google Analytics、Sentry 或外部广告网络）；
  2. CSP 强制约束：在 manifest.json 中配置严密的内容安全策略：
    "content_security_policy": {
  "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; object-src 'self';"
}
  3. 动态网络抓包验证：使用 Wireshark 或 Chrome DevTools Network 面板监控扩展背景进程，在执行模型问答、向量化、网页解析全流程中，对外发包计数器恒定为 0。

8.2 应用商店权限申报合规映射

根据 Google Chrome Web Store 与 Mozilla AMO 政策，针对扩展声明的核心权限建立一对一的技术必要性映射准则：

权限声明 (Manifest) 技术使用目的说明 权限最小化合规依据
storage 保存用户配置、本地向量索引及阅读历史 仅在设备本地 IndexedDB 存储，不向外部同步
activeTab / scripting 在用户主动触发时提取当前网页正文供本地模型分析 仅在当前激活标签页运行，执行完毕即释放 DOM 引用
offscreen 声明独立的算力沙箱容器，挂载 WebGPU 与本地 Wasm 推理管线 替代已废弃的 Background Page，确保多任务并行不阻塞主线程
declarativeNetRequest 本地规则比对过滤广告与追踪元素，提升正文解析信噪比 采用浏览器底层静态规则表过滤，扩展本身无需监听明文网络流量
<all_urls> 使得划词浮球、暗黑套路雷达与广告净化能够在任意用户阅读的网站生效 100% 本地运算消化，在开发者后台“数据收集”类别中全部保持留空

9. 结论

通过将现代浏览器标准的 WebGPU 硬件加速技术、WebAssembly 高性能计算容器、基于分词感知边界的动态 Token 预算调节器与自托管向量检索系统紧密结合，本文提出的系统架构验证了在 Manifest V3 严苛沙箱体系下构建生产级、纯本地、端到端隐私保护的端侧 AI 运行时系统的工程可行性。

该技术方案彻底摆脱了传统 AI 助手对云端算力基础设施与网络连接的刚性依赖，消除了数据外泄与云端推理计费风险，为下一代隐私优先的桌面智能化人机交互范式提供了具备参考价值的工业级实现范本。

posted @ 2026-09-30 11:30  SuperEden  阅读(8)  评论(0)    收藏  举报