OpenScience:开源AI科研工作台

解决什么

科研工作流程通常需要研究者在文献检索、假设提出、代码实现、实验执行、数据分析和论文撰写之间反复切换,耗时且容易中断思路。OpenScience将这些环节整合到一个AI驱动的工作台中,研究者只需设定研究目标,系统就能自动完成从文献综述到实验报告的完整科研循环。它特别针对机器学习、生物学、物理和化学领域,内置290+专业技能(如DeepSpeed训练、分子生物学分析、化学信息学)和30+学术数据库接口(UniProt、PDB、arXiv、PubChem等),让AI真正理解科研语境。

为何火

该项目在4天内获得1186星标,核心吸引力在于三点:一是全流程自动化,不是简单的文献总结工具,而是能独立完成"读论文→写代码→跑实验→出报告"的完整链路;二是模型中立设计,支持Anthropic、OpenAI、Google等任意前沿或开源模型,用户自带API Key即可,无需绑定特定服务商;三是真实科研能力,集成DeepSpeed、PEFT等ML工程工具,连接ChEMBL、Ensembl等专业数据库,而非通用聊天机器人的简单包装。其浏览器工作空间提供文件树、编辑器、终端和分子结构可视化,接近IDE级别的交互体验。

核心功能

• 研究Agent体系:默认research agent,外加biology/physics/ml专科agent,配备critique(批判性审查)和literature-review子agent,支持只读计划模式
• 290+科研技能库:涵盖模型训练(DeepSpeed/PEFT/TRL)、评估、数据集处理、分子生物学、化学信息学、LaTeX论文排版、科学绘图、云计算对接(Modal/Tinker)
• 学术数据库工具化:直接查询UniProt(蛋白质)、PDB(结构)、ChEMBL(药物)、arXiv(预印本)、OpenAlex(文献图谱)、Semantic Scholar等30+数据库
• 浏览器工作空间:文件树、代码编辑器、终端、会话历史,内联渲染分子结构、基因组、科学图表
• 可扩展架构:支持LSP集成、MCP服务器、自定义插件、TypeScript SDK,可在项目根目录的.openscience/配置自定义agent和工具

安装

全局安装(推荐):

npm install -g @synsci/openscience
openscience

或即时运行无需安装:

npx synsci

首次运行会引导配置模型供应商,可选择Atlas托管模型、自有API Key或免费演示模型。也可从GitHub Releases下载平台二进制文件。配置API Key后启动:

export ANTHROPIC_API_KEY=sk-ant-...
openscience ~/my-project  # 可指定项目目录

适合谁

• ML研究者:需要快速迭代实验、对比模型训练效果,利用其DeepSpeed/PEFT技能和云计算对接能力
• 生物/化学学者:频繁查询UniProt/ChEMBL等数据库,需要分子结构可视化和化学信息学分析
• 跨学科团队:希望AI助手理解专业术语(如"训练LoRA适配器"或"查询PDB晶体结构"),而非泛泛而谈
• 注重数据主权的用户:所有API Key和会话数据存储在本地,请求直达模型提供商,无需第三方账号(Atlas为可选增值服务)

中国大陆用户注意:需自备可访问的LLM API Key(国内可用通义千问等兼容OpenAI接口的服务),部分国际学术数据库(如PubMed、arXiv)可能需要网络代理。

社区评价

暂无足量社区公开讨论,以下为基于项目本身的中立评估:该项目技术实现较为扎实,从TypeScript + Bun的技术栈选择、LSP/MCP集成设计、290+技能库的工程量来看,是认真面向科研场景的产品而非概念验证。Apache 2.0许可和模型中立架构降低了使用门槛,但4名贡献者的团队规模意味着社区生态尚在早期。其"agent非沙箱化"的安全提示表明当前更适合个人研究环境,生产部署需额外隔离措施。

选型对比

vs Elicit/Consensus AI(商业文献综述工具):OpenScience覆盖全流程(含代码执行和实验),而非仅文献总结;支持本地部署和自有模型,但Elicit的文献解析准确度经过商业打磨,OpenScience依赖通用LLM可能在专业文献理解上有差距。

vs Jupyter + Copilot:Jupyter需手动切换文献检索、代码编写、数据分析工具,OpenScience将这些环节自动串联;但Jupyter生态成熟度更高,OpenScience的290+技能库能否覆盖所有科研场景仍需验证。

vs 自建Agent框架(如LangChain):OpenScience开箱即用,预置科研数据库连接器和领域技能;自建方案灵活性更高,但需自行对接学术API和调试agent逻辑。

已知坑

1. 非沙箱执行:README明确警告"agent非沙箱化",代码直接在本机执行,建议在容器或虚拟机中运行,避免误操作影响宿主系统
2. 模型成本:全流程自动化意味着高Token消耗,复杂研究任务可能产生数美元API费用,需提前评估预算
3. 学术数据库限流:频繁调用PubMed、UniProt等API可能触发速率限制,项目未提及缓存或请求队列机制
4. 中文文献支持:集成的学术数据库以英文为主,中文期刊(如知网、万方)未见对接,国内科研场景适配度有限
5. 依赖Bun运行时:开发需Bun 1.3+,虽然用户安装仅需npm,但贡献代码或深度定制需熟悉Bun生态
6. 4人团队维护:核心贡献者仅4人,复杂bug修复或新领域技能扩展可能响应较慢,建议关注issue活跃度再投入生产使用