AI 浏览器开发故事：一个失败项目如何重获新生

Source: Dev.to

背景

我在公司负责 AI 项目的前端工作。2024 年上半年，我在维护一个进展平平的 AI 项目，为了在绩效评估中脱颖而出，我需要一个亮点。我的同事 Tan（AI 应用的产品经理）和我开始了为期两个月的探索，尝试更具野心的想法。

初始概念

在调研竞争对手的应用后，我们决定做一个“Jarvis 风格”的助手：

• 用户提出问题。
• 代理自主收集信息、调用各种工具并给出答案。

这个概念受到 Fellou 的 AI 浏览器的启发，它的交互方式和 UI 给我留下了深刻印象。

技术挑战

控制浏览器

核心问题是以编程方式控制浏览器以实现网页任务自动化。我很快放弃了公司遗留的 C++ 客户端，凭借前端背景转向 Electron 来构建桌面应用。

我尝试组合多种工具：

• browser‑use – 用于浏览器自动化的 Python 服务。
• Playwright – 另一个自动化引擎。

我询问了 Cursor（一个 AI 助手）Electron + browser‑use + Playwright 是否可以集成。答案是“可以”，但经过多次尝试后发现集成几乎不可能。我在 Cursor 上花了 200 美元的积分，却没有得到可运行的演示，这让我认识到 AI 只能在你已经熟悉的领域加速工作。

寻找替代技术栈

研究过程中我发现了 Eko 框架（由 Fellou 团队开源）。我了解到 Eko 可以在 Electron 中运行，只需进行一些兼容性工作。

为了嵌入本地前端服务，我选择了 Next.js。在多次使用 AI 辅助失败后，我手动按照 Next.js 文档操作，成功在 Electron 中嵌入了一个自定义服务器——这与开源项目 bolt.diy 的做法类似。

构建原型

• 学习了 React 基础（我之前的技术栈是 Vue）。
• 研究了 Electron 的主进程/渲染进程以及 IPC 通信。
• 使 Eko 框架兼容 Electron，以便在视图窗口中控制网页。

实现的代理

我尝试了屏幕共享（受 Fellou 启发）和全语音输入，但两者都有显著局限，最终被放弃。

最终得到的是一个“弗兰肯斯坦”演示，结合了三个代理，足以支撑一次展示。

项目被否决

当我向领导层演示原型时，尽管投入了两个月的工作，项目仍被否决。我被调到公司其他 AI 项目，演示文件只好留在硬盘上。

开源项目

一个月后，我想知道是否还有人遇到类似的难题。借助 Claude Code，我在一个周末重新构建了一个干净的开源版本，这次没有企业约束。

仓库现已公开：

👉 GitHub:

已实现的功能（深夜与周末完成）

• 历史任务回放
• 人机交互能力
• 语音输入支持
• 多语言国际化
• 代理配置系统
• 定时任务
• 工具箱页面

体会

• AI 并非万能。 它能在熟悉的领域加速工作，但无法替代对底层技术的扎实理解。
• 在 Cursor 上花的 200 美元换来的是一堂宝贵的课：面对不熟悉的技术时，仍需自行学习。
• 开源可以保存本可能被尘封的知识，并帮助他人避免相同的坑。

未来工作

• 🎨 主题定制（暗黑模式）
• 🔌 插件市场（MCP 工具生态）
• 📊 可视化工作流编辑器
• 🌐 更多代理（Shell、Email、Notion 等）

贡献方式

如果你感兴趣：

• ⭐ 给仓库加星 – 有助于提升可见度。
• 🐞 提交 Issue 或 Pull Request。
• 💬 在 GitHub Issues/Discussions 中参与讨论。
• 📥 下载并试用工具，然后提供反馈。

从一个内部、以绩效为导向且被否决的项目，到一个在周末重建的开源努力，这个“失败”的项目获得了新生。开源不仅是共享代码，更是共享经验与想法。