Open Science - 本地优先的 AI 科研工作台

解决什么

科研工作者在使用 AI 辅助研究时面临三大痛点:数据隐私风险(上传敏感实验数据到云端)、工具碎片化(需在多个平台间切换完成文献检索、代码执行、报告生成)、结果不可复现(缺乏完整的操作历史追溯)。Open Science 提供一个本地运行的桌面工作台,让 AI 代理在用户自己的电脑上执行 Python/R 代码、读取本地文件、调用科学数据接口,生成带完整审计日志的可复现研究报告,数据全程不离开本地环境。

为何火

项目在一个月内获得 1354 星,核心吸引力在于"本地优先 + 模型无关"的设计。与 Elicit、Consensus 等商业工具相比,它允许研究者自主选择模型提供商(Claude、OpenAI、本地模型均可),敏感数据完全留在本地;与传统 Jupyter Notebook 相比,它通过自然语言驱动 AI 代理自动完成数据分析流程,并记录每一步工具调用历史。特别适合生物信息学、医学研究等对数据合规要求严格的领域,以及需要在离线环境工作的场景。

核心功能

项目化工作流:创建独立研究项目,用自然语言描述任务目标、输入数据、约束条件和预期输出格式,AI 代理自动规划执行路径。

多语言代码执行:内置 Python 和 R 运行时管理,可使用应用托管的环境或接入系统已有解释器,代理自动编写和运行分析脚本。

可复现性保障:所有工具调用、代码执行、文件操作均记录在活动历史中,支持消息分支编辑和回溯,确保研究路径可追溯。

模型灵活切换:支持 Claude、OpenAI、自定义网关或本地模型,同一项目可在不同会话中更换模型对比效果。

审批机制:敏感操作(如文件写入、网络请求)可配置为需人工审批,防止代理执行危险指令。

科学数据连接器:通过 MCP(Model Context Protocol)集成外部科学数据库和工具,扩展代理的知识获取能力。

安装

1. 访问 GitHub Releases 页面,根据操作系统下载对应安装包:

   • macOS Apple Silicon(M1 及以上):选择 ARM64 DMG
   • macOS Intel:选择 x64 DMG
   • Windows:选择 x64 安装程序
   • Linux:选择 AppImage 或 Debian 包

2. 首次启动完成五步引导配置:

   • 环境检查(存储、网络、凭证管理)
   • 代理运行时选择(Claude Code/OpenCode/Codex)
   • 模型提供商配置(输入 API Key 并测试连接)
   • Notebook 运行时准备(可选,安装或检测 Python/R)
   • 数据存储位置设定

macOS 或 Windows 若提示"未识别的开发者",需在系统安全设置中手动允许,或参考项目文档从源码构建。

适合谁

科研机构研究者:需处理受保护健康信息(PHI)、基因数据等敏感资料,必须满足本地化存储合规要求。

生物信息学工作者:频繁进行序列分析、统计建模,需要 AI 辅助编写 Python/R 脚本但不想上传原始数据。

独立研究人员:预算有限,希望使用开源工具替代 Elicit 等商业订阅服务,同时保留模型选择自由度。

离线环境用户:在内网或无外网接入的实验室工作,可配合本地部署的 LLM(如 Ollama)完全离线运行。

中文用户注意:调用 Claude、OpenAI 等国际模型需自备网络访问方案,或在设置中配置支持国内访问的自定义网关;也可使用阿里通义、智谱等国产模型 API,或部署本地模型完全规避网络限制。

社区评价

暂无足量社区公开讨论,以下为基于项目本身的中立评估:

从 GitHub 活跃度看,项目在一个月内快速迭代至 v0.9.1,最近更新距今不到 24 小时,显示开发团队响应积极。19 个开放 issue 中多为功能请求和细节优化,未见严重阻塞性 bug 报告。项目提供详细的安全验证文档(SECURITY.md)和构建指南,体现对企业级用户的重视。

技术选型上,Electron 跨平台方案保证了 macOS/Windows/Linux 一致体验,但也意味着较大的安装包体积(通常 200MB+)。集成 Prisma ORM 和 SQLite 用于本地数据管理,避免了额外数据库依赖。支持 MCP 协议是亮点,理论上可接入 Anthropic 生态的各类工具扩展。

潜在顾虑:作为新兴项目(创建于 2026 年 7 月),长期维护承诺尚待观察;10 位贡献者的团队规模相对小众,若核心开发者离开可能影响迭代速度。

选型对比

vs Elicit/Consensus(商业工具):后者提供云端托管、预训练的科研语料库和协作功能,但数据必须上传且按月订阅。Open Science 牺牲了云端协作便利性,换取数据完全自主可控和零订阅成本,适合对隐私敏感或预算受限的场景。

vs Jupyter Notebook:传统 Notebook 需手动编写每个分析步骤,Open Science 通过 AI 代理自动生成代码并执行,降低编程门槛;但 Jupyter 生态更成熟,扩展库支持更全面,适合需要精细控制的高级用户。

vs Cursor/GitHub Copilot:代码编辑器插件侧重辅助编程,Open Science 定位于端到端的研究工作流,包含文件管理、结果可视化、历史追溯等科研场景专属功能,但代码编辑体验不如专业 IDE。

vs 本地 LLM + LangChain 自建方案:自建方案灵活度最高但需投入开发成本,Open Science 提供开箱即用的 GUI 和预配置的科研工具链,适合非工程背景的研究者快速上手。

已知坑

首次配置门槛较高:需依次完成代理运行时、模型连接、Notebook 环境等多步设置,任一环节失败会阻塞启动,建议预先准备好 API Key 和网络环境。

模型 API 依赖:虽然支持本地模型,但主流使用场景仍依赖 Claude/OpenAI 等外部服务,国内用户需自行解决网络访问或寻找兼容的国产模型 API。

Electron 应用体积:安装包通常超过 200MB,运行时内存占用较高(约 500MB-1GB),低配设备可能卡顿。

Windows/macOS 安全警告:未签名的安装包会触发系统拦截,需手动在安全设置中允许,或从源码自行构建签名版本。

Python/R 环境隔离:应用管理的运行时与系统环境独立,若需使用特定版本的科学计算库(如特定版本的 TensorFlow),需在设置中手动注册外部解释器。

MCP 工具生态待完善:虽然支持 Claude MCP 协议,但当前可用的科学数据连接器数量有限,扩展能力取决于第三方工具开发进度。

项目成熟度风险:作为不到两个月的新项目,API 和数据格式可能在后续版本变动,早期采用者需关注升级兼容性问题。