open-science
只要还有什么东西不知道，就永远应当学习。——小塞涅卡
Open Science：把研究过程留在桌面，把证据留在结果身边
科研工作从来不只是提出一个问题，再等待一句答案。
一个真正完整的研究过程，往往要在多个空间之间反复穿梭：聊天窗口里梳理思路，Notebook 中执行代码，本地脚本里处理数据，科学数据库中查找信息，文件浏览器里管理材料，报告工具中组织结果。每一次切换都可能带走一部分上下文，每一次复制粘贴都可能让过程变得难以回溯。
AIPOCH Open Science 试图把这些分散的环节重新拉回同一个工作台。
它是一款开源、以本地优先为原则、模型无关的 AI 科研工作台，面向 macOS、Windows 与 Linux，服务于可复现的科学研究。项目将科学智能体、Python 与 R Notebook、数据连接器、项目文件、生成产物与溯源信息汇集到统一的桌面工作区中，让研究不只停留在对话里，也能够持续保留执行过程、文件关系和结果证据。
项目地址：https://github.com/aipoch/open-science
Open Science 想解决的，不是单纯的文本生成问题，而是研究任务在真实工作中如何被组织、执行、审阅与延续的问题。
研究不该在工具切换中失去来处
很多研究任务并不是一步完成的。
一个问题提出之后，可能需要上传数据文件，查找文献，运行 Python 或 R 代码，执行命令，读取表格，生成图形，整理报告，再回头检查结果是否满足最初的约束。研究的价值不仅存在于最终产出，也存在于产出如何形成。
Open Science 以项目和会话组织工作内容。
项目可以承载相关的会话、上传文件、生成文件与预览状态。会话则保留智能体回答，以及命令执行、文件读取、编辑、搜索和连接器调用等活动。生成的报告、图形与表格会继续附着在会话中，同时也会被收集到项目文件库中。
于是，研究过程不再像散落在不同应用里的碎片。
它可以有一个持续存在的工作空间：任务在这里开始，文件在这里汇集，执行在这里发生，结果在这里生成，证据也在这里被查看。
从任务到产物，让每一步都有迹可循
Open Science 的一个核心方向，是让研究结果保持可追溯性。
生成的产物拥有不可变的版本。每一个版本可以保留经过校验和确认的内容，以及系统能够提供的生产证据，例如生成代码、执行历史、精确输入引用、环境清单等信息。对于无法获得的证据，系统也会明确标记其不可用状态。
这让结果不只是一个静态文件。
一份报告可以有自己的生成背景。
一张图表可以回到产生它的会话。
一个数据结果可以与输入材料、执行动作和环境信息重新连接。
在 Open Science 中，产物不必孤零零地躺在某个文件夹里。它们更像研究过程留下的节点，既承载成果，也保留通往成果的路径。
对话可以分叉，原来的研究方向不会消失
研究常常需要回头。
一个已经完成的任务，可能因为新的数据、新的限制条件或新的研究想法而需要重新提问。传统对话模式中，修改一条较早的信息，经常意味着后续内容被覆盖，原本的思路也随之消失。
Open Science 为这种情况提供了消息分支能力。
用户可以编辑已经完成的提问，并从该位置重新发送。系统会创建新的消息分支，而不会删除原有分支中已经发生的后续内容。用户可以在不同的研究方向之间切换，也可以通过消息修订控制回到不同路径。
这种设计很适合研究本身的节奏。
研究并不总是直线前进。有时需要保留原始假设，同时尝试另一种分析思路；有时需要在相同数据基础上使用新的约束重新执行；有时则需要把一次探索与另一次探索并行保留。
分支让这些不同方向不必彼此覆盖，而是能够共同存在。
智能体不只回答，也能参与执行
Open Science 中的智能体不只是生成建议。
在用户授权的前提下，它可以执行命令、运行 Python 与 R、编辑文件、搜索信息、调用数据连接器，并生成研究产物。工作台会记录这些工具活动，让研究执行过程能够被检查。
自然语言任务仍然是入口。
用户可以在会话中描述研究目标、输入数据、约束条件、预期输出与验证方式。随后附加源文件，选择已经验证的模型，再选择合适的授权模式。任务发送之后，用户可以检查智能体的工具活动，对敏感操作进行批准，并在预览面板中查看生成的产物。
这一过程让语言描述、代码执行、文件处理与研究记录不再彼此割裂。
研究者可以从问题出发，同时保留对执行行为的观察与控制。
Python、R 与 Notebook 进入同一份研究记录
计算与数据密集型研究常常离不开 Notebook。
Open Science 支持 Python 与 R Notebook 运行环境，也支持持久化的 Python、R 与 REPL 控制平面内核。代码和输出历史可以持续保留，而无状态的 Shell 命令也会被记录在相同的运行历史中。
Notebook 执行是可选能力。
在首次设置阶段，用户可以选择由应用管理 Python 与 R 环境，也可以启用系统检测到的解释器，或手动注册解释器。研究者无需把 Notebook 当作孤立工具，而可以让它与项目、会话、文件、智能体活动和产物证据处于同一个研究空间。
当代码运行结果、数据文件、智能体操作和最终报告可以并排出现时，研究工作更容易保持连续性。
科学技能与数据连接器成为可组合的能力
Open Science 内置了一组面向科研工作的能力。
README 中列出了 22 项精选的文件型研究技能，其中包括 AlphaFold2、Boltz、Borzoi、Chai-1、DiffDock、ESM-2、ESMFold2 与 Evo 2 等。它也提供了 24 个内置研究连接器，覆盖 Literature Graph、PubMed、bioRxiv、Genes & Ontologies、Genomes、BioMart、Variants、Human Genetics、Clinical Genomics、Structures & Interactions 等方向。
这些能力并不只是隐藏在系统深处的固定功能。
技能、连接器、模型、预览能力以及未来的计算后端，被视为可以组合与替换的组成部分。用户也可以添加技能与 MCP 连接器，而不必等待封闭式插件体系给出固定答案。
这种设计让工作台不只服务于某一种单一研究流程。
机器学习、统计学、生命科学、化学、材料科学、物理学与环境科学等计算和数据密集型研究场景，都可以在项目与会话的框架中展开自己的工作路径。
模型无关，不把研究工作绑定在单一入口
Open Science 在产品层面采用模型无关的思路。
用户可以使用内置云端提供方，连接兼容的自定义网关，也可以复用 Claude 或 Codex 订阅。每次会话都能够选择模型与推理强度，并与智能体后端共同构成具体的执行环境。
在首次设置时，模型提供方是一个独立步骤。用户可以连接并测试希望使用的模型，选择内置提供方、自定义网关，或使用已有订阅登录。
应用也支持多种智能体运行时，包括 Claude Code、OpenCode、Codex 与 CodeBuddy。应用管理的运行时可以完成安装准备，而无需 Node.js、npm 或管理员密码。
这种方式让研究工作台不必围绕某一个模型或某一个智能体框架建立封闭边界。研究者可以在工作空间中管理任务、文件、执行与证据，同时根据自身条件选择模型提供方式与智能体运行时。
本地优先，不意味着忽略外部数据流
Open Science 将项目数据、应用设置、产物版本与溯源证据保存在本地计算机上。API Key 也会本地保存，并尽可能使用操作系统提供的安全凭据存储能力。
本地优先意味着项目和状态由用户自己的计算机承载，但 Open Science 也没有把外部数据流藏在不可见的地方。
当用户调用模型时，提示词和必要上下文会发送给所选模型提供方。
当用户进行网络搜索或使用远程连接器时，显示的参数会被发送至外部服务。
本地连接器可能执行被信任的本机命令。
附件、文件引用、日志与生成报告中也可能包含敏感研究数据。
因此，Open Science 把权限控制纳入了研究流程。
人始终在研究流程中
智能体可以执行任务，但执行范围由权限配置决定。
Open Science 提供三种会话权限模式。
| 模式 | 行为 |
|---|---|
Ask for approval |
在编辑文件、执行命令、访问网络与调用连接器前请求批准 |
Auto-approve edits |
自动允许工作区文件编辑，但仍会为命令、网络与连接器请求批准 |
Full access |
自动允许编辑、命令、网络与连接器调用 |
这三种模式让自动化不必只有开启或关闭两种状态。
研究者可以在探索陌生脚本、处理敏感数据或开始新流程时，选择更严格的批准方式。对于受控的文件编辑任务，可以自动允许编辑，同时继续约束外部访问。对于范围明确、完全可信的无人值守工作，也可以使用完整访问权限。
Open Science 把文件编辑、命令执行、网络访问与连接器调用放在可见且可选择的控制框架中。智能体不必被设定为无条件行动者，人仍然是研究流程中的判断者。
第一次启动，从环境检查开始
Open Science 的首次启动包含五个引导步骤。
第一步是环境检查，用于检查兼容性、应用存储、安全凭据存储和网络访问。
第二步是数据位置选择，用于确定大型产物、Notebook、上传内容与运行环境的存放位置。
第三步是智能体运行时选择与准备，可以选择 Claude Code、OpenCode、Codex 或 CodeBuddy。
第四步是模型提供方配置与测试，用于连接希望使用的模型。
第五步是 Notebook 运行时配置，可以选择准备应用管理的 Python 与 R 环境，也可以启用检测到的解释器。
完成这些设置后，研究项目便可以开始建立。
创建项目，填写稳定的研究名称和描述。
创建会话，描述目标、输入、约束、输出与验证要求。
附加源文件，选择模型和权限模式。
发送任务，查看工具活动，批准敏感操作，检查生成产物。
这条路径不只是安装后的使用说明，更像是在告诉研究者：一项研究任务如何从准备环境开始，逐步进入可执行、可检查、可延续的状态。
预览不只是打开文件，而是留住上下文
研究产物经常有不同形态：数据表、科学数据文件、PDF、报告、图形与其他生成文件。
Open Science 提供多标签的响应式预览能力，用于查看常见科学数据，也支持 PDF 中的可选文本、区域选择、目录与缩略图导航、文档搜索和页面导航。
预览的意义不只在于方便查看。
当活动结果始终可见，而研究历史、会话内容和项目文件仍然留在同一个工作区里，用户不必频繁切换应用，也不必在“文件在哪”“这个结果来自哪次运行”“当时用了什么输入”之间来回寻找。
数据与研究历史可以并排出现。
产物与会话可以彼此对应。
结果不再脱离产生它的上下文。
可审阅的工具活动与可选的结果复核
Open Science 会以类型化的工具活动卡片呈现智能体执行过程，并按声明的目的进行分组。用户能够在工作过程中观察智能体做了什么，而不是只在最后接收一个结果。
项目还提供可选的审阅能力。
审阅器可以根据已经完成的对话记录、执行日志和产物，对一个完成的任务回合进行检查，并输出通过、警告或失败等结果。它也可以在受限范围内执行后续检查。
这种机制并不把生成内容包装成天然正确的答案。
Open Science 对科学边界有明确表述：生成结果不能代替专业判断、统计审查或对原始证据的验证。它是研究执行与记录保存工具，而不是科学判断的替代者。
这种边界意识，让工作台的角色更加清楚。
它可以帮助组织研究，推动执行，保存过程，呈现证据。
但研究方法是否合理、结果如何解释、隐私如何保护、科学结论是否成立，仍然需要研究者承担责任。
桌面应用，也能以本地服务方式运行
Open Science 是基于 Electron 构建的应用，使用 React、TypeScript、Prisma、SQLite 与基于 ACP 的智能体运行时。
从源码启动开发环境时，需要 Node.js 22、npm 与 Git。如果需要执行 Notebook，则还需要 Python 3。
1 | git clone https://github.com/aipoch/open-science.git |
安装依赖时，项目会自动生成 Prisma Client，并安装 Electron 原生依赖。启动开发模式后，系统会构建 Electron 主进程与预加载包，启动渲染层并打开桌面应用。
常用开发命令包括：
| 命令 | 用途 |
|---|---|
npm run dev |
启动开发应用 |
npm run dev:web |
启动开发应用与本地 Web 界面 |
npm run dev:headless |
启动开发后端与 Web 界面，不打开 Electron 窗口 |
npm run lint |
运行 ESLint |
npm run typecheck |
检查主进程与渲染层代码类型 |
npm test |
运行 Vitest 测试套件 |
npm run build |
类型检查并构建应用 |
npm run build:web |
构建可选的本地 Web 界面 |
npm run build:mac |
打包 macOS 构建产物 |
npm run build:win |
打包 Windows 构建产物 |
npm run build:linux |
打包 Linux 构建产物 |
打包后的输出文件会写入 dist 目录。
本地 Web 与无界面模式，让同一工作台拥有更多入口
Open Science 的桌面后端可以选择将相同的渲染界面提供给本机浏览器。该功能默认关闭，并且仅绑定到 127.0.0.1。
1 | npm run build:web |
无界面模式则可以启动后端、托盘、智能体运行时和本地 Web 服务，而不打开 Electron 窗口。
1 | npm run dev:headless |
项目还提供无界面 CLI 和零依赖 Node.js SDK。它们使用与桌面端和 Web 界面相同的本地守护进程、项目、会话、凭据与权限体系。
CLI 可以启动服务、创建项目、运行任务、列出产物并下载结果。
1 | open-science start --no-open |
同一个研究空间可以拥有桌面、浏览器、命令行与 SDK 等不同入口，但它们仍然围绕同一套本地项目、会话、权限与产物记录运行。
不只是聊天界面，也不是科学判断的替身
Open Science 明确说明，它不是通用聊天外壳，不是其他 AI 研究应用的非官方客户端，也不是科学审查的替代品。
它不是只负责展示对话的界面，因为它围绕持久化项目、执行过程、文件、产物和可审阅工具活动组织。
它不是某个既有产品的代理或重制，因为它拥有独立的代码库、数据模型、界面与路线。
它也不替代研究者的专业判断。模型输出仍需要领域审阅、统计验证与原始证据核查。
恰恰因为这些边界被明确写出，Open Science 的定位反而更加稳固。
它不试图把科研压缩成一句提示词和一段回答，而是希望为研究过程提供一个更完整的容器。
当研究过程可以被保留，结果才更有机会被理解
Open Science 的价值，存在于它对科研工作流的整体理解之中。
研究不是只有问题和答案。
研究还包括项目如何建立，数据如何进入，模型如何选择，任务如何执行，工具如何调用，文件如何变化，结果如何生成，分支如何保留，证据如何查看，权限如何控制，以及工作如何在之后继续。
Open Science 将这些环节收拢到一个本地优先、可检查、可扩展的桌面工作台中。
它让智能体拥有参与执行的能力，也让用户保留审阅和批准的权利。
它让生成的产物能够持续存在，也让产物的来处不至于随会话结束而消失。
它让研究可以借助模型与自动化继续向前，也提醒人们：真正的科学判断，始终需要研究者回到证据、方法与验证本身。