替代系统内置的搜索条：将传统的搜索框替换为智能助手，提供更加灵活和自然的提问方式，通过语音或文本直接与系统对话，摆脱传统的静态搜索体验。
独立的 AI 应用程序：提供一个独立的 AI 应用，用户可以在其中保存对话历史，进行深入交互，并且可以针对不同的问题进行持续追问，帮助用户记录工作进度和问题的解决方案。
CCC（Control + C + C 快捷键）交互集成：实现用户在选中文本或文件后，能够直接交由 AI 处理和提问，配合系统的无障碍功能，实现更直观的交互体验，让用户可以更加高效地完成信息查找和处理。
系统文档和代码的整理与交互：通过将系统文档和源码整合形成知识图谱，利用 AI 来辅助用户理解和操作。这需要进行 RAG（检索增强生成）和 Agent 的开发，使得 AI 不仅能处理用户的直接提问，还能主动建议下一步操作。

0x2 实现步骤

替换系统搜索条

在 MVP 的第一阶段，我们的目标是替换系统的主菜单搜索条。用户可以直接在主菜单内输入自然语言提问，系统会将用户的输入跳转至 AI 界面进行回答（一次性提问），或者用户可以选择打开完整的 AI 应用，进行持续的对话和历史记录保存。在这个阶段， AI 实际上是一个「套壳 GPT」的 AI 工具，但它已经为用户提供了更智能的搜索体验，使得操作系统的使用更加直观和高效。

CleanShot 2024-10-07 at 19.32.26.png

CCC（Control + C + C）集成与悬浮窗

第二阶段的目标是通过监听用户按下Control + C + C快捷键，将剪贴板中的最新内容直接发送给 AI 处理。在这个阶段，AI 被集成为系统的悬浮窗，使得用户可以随时利用 AI。

CleanShot 2024-10-07 at 19.33.15.gif

在 Chromium OS 中，由于缺乏传统的 X11 窗口系统，无法方便地自定义窗口，这使得实现悬浮窗变得非常困难。然而，我们最终发现可以继承和复用系统剪贴板管理（通过 Search 键 + Q 弹出的浮窗）的代码逻辑来实现悬浮窗，这使得我们能够顺利实现所需的功能。最终，我们选择使用SWA（System Web App）来实现这一功能。SWA 类似于一个独立的浏览器窗口，具有独立的协议（例如 ai-app://），类似于每个 Chromium 浏览器插件都有一个chrome-extension://这样的协议 Url。因此，所有通过这个应用程序打开的窗口在系统看来都是同源的标签页（尽管实际情况更复杂，但这样解释也足够准确）。窗口之间可以通过BroadcastChannel进行通信。而 SWA 应用本身可以通过 C++ 进行逻辑扩展，类似于对 Chromium 进行二次开发，可以将系统原生功能与 JavaScript 交互。

SWA 的逻辑架构如下：

SWA 本身主体的更新跟随系统更新（要被编译到系统中），所以我们需要在 SWA 的页面上使用WebView来展示内容，WebView 的内容可以随时更新，以便灵活适应用户的需求和改进用户体验。
系统层面的 SWA 应用，通过 C++ 层逻辑向页面注入 JS-Bridge，使得 SWA 的页面可以直接调用系统功能。
SWA 本身的 Web 页面可以通过 WebView 显示独立的 Web 项目，使用 postMessage 与 SWA 进行通信。

在悬浮的工具条中，我们实际上需要两个部分，一个是主输入框，用户可以在其中输入或显示复制的内容或文件。主输入框在识别内容后，会调用不同的功能逻辑，在下方的功能区显示相应的界面。最理想的做法是使用两个 WebView，一个用于主输入框，另一个用于功能区，由 C++ 进行通信和交互。主输入框（实际上就是悬浮窗的主体程序）可以控制下方功能区的生命周期，从而实现更灵活的功能调用和管理。

然而，初期开发时，为了降低成本，我们选择使用一个 WebView，其中包含一个主输入框和一个iframe以实现与用户的交互。主输入框控制整体逻辑，而 iframe 则负责具体的插件调用和内容处理。主输入框和 iframe 之间通过 postMessage 进行通信。我们编写了一个 JS SDK 来提供通信功能，使得 iframe 内的页面也可以调用系统的功能，从而实现系统与插件的紧密结合。通过这种设计，我们能够以较低的开发成本实现基本的功能，同时为后续的扩展奠定基础。

0x3 插件化

CleanShot 2024-10-07 at 19.39.51.png

AI 的核心是插件化架构。所有功能都基于插件开发，每个插件就像一个独立的应用，只是最终在 AI 中集成显示。这种插件化的设计使得 AI 可以灵活地扩展新功能，用户可以通过插件处理文本、文件等输入。

最理想的插件打包方式是将每个插件打包为一个独立文件，用户只需将文件复制到系统中即可完成安装。然而，由于初期的开发成本限制，我们选择将插件以 PWA 形式进行开发，利用浏览器的缓存和更新机制来保存插件。这样，插件的开发和更新变得更加灵活，同时也减轻了用户安装和使用的复杂度。通过内置的「功能配置」这个插件，用户只需复制插件 URL，系统就会自动识别并开始安装，进一步简化了插件的安装过程。

插件的配置信息存储在 PWA 的manifest.json中，并添加了一些额外的属性。例如，一个用于 Base64 编码和解码的部分插件配置如下：

"matches": [
    {
      "name": "Base64 编码",
      "type": "code",
      "content": "*"
    },
    {
      "name": "Base64 解码",
      "type": "regexp",
      "content": "^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$"
    }
  ]

通过这种配置，主输入框可以在内容变化后自动匹配相应的插件和功能，供用户选择调用。这种动态的匹配机制使得用户的操作体验更加流畅，同时能够有效减少用户在复杂任务中的操作步骤。

0x4 数据存储

数据存储同样采用渐进式策略。我们定义了一套 store 接口，接口中包括 set、get 等方法。在初期版本中，使用localforage（基于IndexedDB）实现这些接口，通过不同的分区模拟轻量级的 NoSQL 数据库，用于存储 AI 需要的数据。未来如果可以直接使用本地磁盘进行存储，可以通过实现相同接口无损替换。

数据大致分为以下几部分：

AI 应用设置项：例如用户偏好、API Key 等。
对话记录：保存用户通过 App 进行的对话和插件交互的记录，方便后续查阅。用户可以在任何时候查看这些对话，以便追踪问题的解决进度。
插件安装信息：包括插件的关键字、匹配方式、logo 等。这样，系统可以在用户需要时快速匹配到相应的插件，提升用户体验。
每个插件独立的存储空间：每个插件有单独的存储，用于保存插件内部的配置信息，由 JS SDK 提供存储接口，插件可以自由地使用这些接口进行数据的增删改查。

所有数据都可以进行序列化，并通过的云服务进行同步，用户更换设备后可以快速恢复自己原有的 AI 工具集和配置。这种云同步功能极大提升了用户的体验，使得用户在不同设备间切换时不会丢失自己的偏好和历史数据。

0x5 总结

我们希望 AI 从一个简单的搜索条替代品逐渐演进为一个全面集成的智能助手。通过插件化架构和系统级的交互方式，让 AI 为用户提供了自然语言的无缝体验。尽管在开发过程中面临了一些技术和成本的限制，但通过系统化的设计和合理的技术取舍，我们实现了 MVP 版本的核心功能，也为未来的扩展打下了坚实的基础。

未来，我们计划进一步丰富 AI 的插件生态，使其能够支持更多的场景和需求，例如跨应用的协同操作、对系统设置的深度集成控制以及通过学习用户行为来主动提供建议。我们的最终目标是打造一个真正能够理解用户需求的智能助手，使得 FydeOS 在使用体验上达到新的高度。

0xFFF 展望

在这里附上我们对 AI 的想象，看一下我们制作的「Introducing the inaugural AI-native operating system: FydeOS with FydeOS AI.」

YouTube：https://www.youtube.com/watch?v=UtnBDaB_pSg
Bilibili：https://www.bilibili.com/video/BV1oL411X7Gt

关于 AI 是如何诞生的

0x0 为什么要做这个项目

0x1 路线图