AI客户端架构演进：从套壳插件到C++原生护城河

做一款 AI 浏览器，最大的陷阱就是停留在"套壳"。

很多团队的初始思路是用 Web 技术拼凑一个壳，调一调大模型的 API。这在早期确实能以最快速度跑通 MVP，但它的天花板极低。正如我们经过验证后得出的结论：Phase 1 MVP 极易复制；Phase 3 原生极难复制，构建竞品难以复制的壁垒。如果只做浏览器插件（Manifest V3 + Side Panel），最后拼的只能是算力成本和微弱的 UI 体验差异。

为了真正拉开差距，AI 客户端的架构演进必须是一场从外向内"啃内核"的硬仗。我们将其拆解为"三步走"演进路线：

Phase 2：深度集成与 Chromium 定制

当验证了核心需求后，必须迅速摆脱纯 Web 扩展的限制，走向 Chromium 内核的深度定制（周期 4-6 周）。

纯插件模式下，想要读取本地资源、控制系统级窗口或者获取高权限是举步维艰的。在这一阶段，架构的核心动作是本地化与引入原生 Bridge：

实现 myai:// 自定义协议 ：允许浏览器直接从本地 biz/ 目录加载核心业务代码，极大降低前端加载的白屏时间（目标 <100ms）。
开发 neotix 风格的 JSBridge ：通过 C++ 层的 WebUIMessageHandler 注册原生能力。例如，赋予 AI 助手直接读取系统剪贴板和执行原生截图的权限：

cpp 复制代码

// myai_bridge.cc
class MyAIBridge : public WebUIMessageHandler {
public:
  void RegisterMessages() override {
    RegisterHandler("screenshot", &HandleScreenshot);
    RegisterHandler("getLLMConfig", &HandleGetConfig);
    RegisterHandler("clipboard.read", &HandleClipboardRead);
  }
  // ...
};

这一阶段的定制它在架构上实现了前后端的分离与提权，是通向终极护城河的必要跳板。

Phase 3：深入 C++ 原生，打造终极护城河

真正的壁垒，在于利用底层系统级能力，实现纯 Web 技术无法触达的体验。这个阶段是 AI 浏览器拉开代差的关键。

绕过 WebRTC 的全局语音

网页端调用麦克风存在一个体验限制：需要每个标签页单独授权，且无法做到真正的全局唤醒。

我们的架构决策是放弃 Web 层 API，直接在 Chromium 内核层实现全局音频采集，绕过 WebRTC 权限检查。只要按下全局快捷键 Ctrl+Shift+V，C++ 层的 GlobalVoiceService 就会利用 VAD（静音检测）和本地化引擎实时捕获并转写系统音频，响应时间可压榨至 <500ms。

cpp 复制代码

// global_voice_service.cc
class GlobalVoiceService {
public:
  void StartListening() {
    // 绕过 WebRTC 权限检查，直接采集系统音频
    audio_input_->Start(this);
  }
  
  void OnAudioData(const float* data, size_t frames) {
    if (vad_.IsSpeech(data, frames)) {
      transcriber_.Process(data, frames);
    }
  }
};

浏览器级本地 RAG 系统

另一个关键差异化能力是对用户历史浏览记录的"语义接管"。传统的做法是将数据打包发给云端，不仅面临严重隐私风险，且 token 开销巨大。

我们设计了一套纯本地执行的浏览器级 RAG 架构：本地 embedding (e5-small) + SQLite+Vec 向量索引。

cpp 复制代码

// browser_rag_service.cc
class BrowserRAG {
  void IndexPage(const GURL& url, const std::string& content) {
    // 1. 提取正文 (Readability)
    auto text = readability::Extract(content);
    // 2. 分块
    auto chunks = Chunker::Split(text, 512);
    // 3. 本地 embedding 并入库
    for (auto& chunk : chunks) {
      auto vec = embedder_.Encode(chunk);
      vector_db_.Insert(url, chunk, vec);
    }
  }
  // ...
};

在这个架构下，用户所有的历史记录、书签收藏，都在后台静默生成了向量特征。当用户询问"我上周看过的一篇关于 React 性能优化的文章在哪"时，系统能直接从本地 SQLite+Vec 进行 Top-K 召回。

为了验证这条演进路线，我们接下来的测试重点是：在 10 万条书签和历史记录的数据量下，这套纯本地 SQLite+Vec 架构的检索延迟能否稳定压在 200ms 以内。