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 助手直接读取系统剪贴板和执行原生截图的权限：
// 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。
// 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 向量索引。
// 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 以内。
