marimo 评测：用纯 Python 存储的响应式笔记本，能否取代 Jupyter 和 Streamlit？
Python 的反应式笔记本：运行可重复的实验，使用 SQL 查询，作为脚本执行，作为应用程序部署，并使用 git 进行版本控制。存储为纯 Python。一切都在现代的人工智能原生编辑器中。
秒懂
- 它是什么？
- marimo 是一个将笔记本保存为纯 Python 文件的响应式环境，主打可复现、可脚本化、可部署。本文基于其 README 与仓库状态，分析其运行机制、上手方式与适用边界。
- 适合谁用？
- 适合受困于 Jupyter 隐状态和手动重跑单元格的 Python 数据工作者，尤其是需要把分析脚本化、用 git 管理或部署成内部工具的人。不适合重度依赖既有 Jupyter 扩展生态、需要复杂交互回调或不愿改变执行心智模型的用户。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 Jupyter 的根子问题
传统笔记本的痛点不在编辑体验，而在状态管理。手动重跑单元格导致变量与输出脱节，隐藏状态让结果难以复现。marimo 的 README 直接点名这些问题，并把响应式执行作为核心承诺：运行一个单元格，引用其变量的下游单元格自动运行，删除单元格则其变量从内存中清除。这个机制把笔记本从线性脚本改造成了依赖图。对做数据探索的人来说，这意味着不再需要反复手动刷新所有下游代码。它的目标用户很明确，就是那些已经受够了 Jupyter 隐状态、又不想迁移到纯脚本工作流的 Python 使用者。
存储格式是纯 Python，执行模型是图
marimo 的笔记本文件是 .py 文件，不是 JSON 或 ipynb。这一点直接决定了它的 git 友好性，diff 和 merge 可以按普通代码处理。文件内部每个单元格是一个函数，变量通过返回值传递，而不是靠全局命名空间。这就是它能保证无隐状态的原因。执行时，marimo 根据变量依赖关系构建执行图，运行一个单元格就触发下游更新。README 还提到可以配置为懒执行模式，把受影响单元格标记为 stale 而不是自动运行，这是对昂贵计算场景的妥协设计。SQL 单元格也在这个模型内工作，查询结果作为 dataframe 返回给 Python，但文件本身仍然是纯 Python，这个设计保持了存储格式的统一。
安装与启动：一条命令，但有前置条件
README 给出的启动路径是 pip install marimo 然后运行 marimo tutorial intro。这是最直接的入口。安装后，CLI 提供创建、编辑和运行笔记本的命令。编辑器是浏览器界面，也提供 VS Code 和 PyCharm 插件，以及通过文件监听在 neovim 或 Zed 中编辑的方式。SQL 功能内置，不需要单独安装数据库驱动即可查询 dataframe，但要连外部数据库或 Google Sheets 需要额外驱动。包管理是内置的，可以在笔记本内声明依赖。部署方面，笔记本可以作为脚本执行，也可以作为交互式 web 应用或幻灯片发布，还支持 WASM 在浏览器中运行。这些能力都写在 README 里，但具体配置项需要查阅文档，README 没有给出部署命令的完整示例。
一个明显的权衡：响应式模型的代价
响应式执行解决了一类问题，也引入了新的约束。单元格不能依赖执行顺序，只能依赖变量名，这要求写代码时更明确地声明依赖。对习惯从上到下顺序执行的人来说，这种心智模型需要适应。另一个限制是，README 强调的懒执行模式只是把自动运行改为标记 stale，用户仍然需要手动触发，这并没有消除昂贵单元格误触的风险，只是把决定权交还给用户。还有一个实际问题是生态替换。marimo 声称替代 Jupyter、Streamlit、Jupytext、ipywidgets 和 papermill，但替代意味着迁移成本，现有 Jupyter 扩展和 ipywidgets 交互组件不能直接搬过来。对于重度依赖这些生态的项目，这不是一个无痛切换。
和 Streamlit 的定位差异：开发范式不同
Streamlit 是脚本即应用，每次交互都重跑整个脚本，用缓存装饰器控制重算范围。marimo 是响应式单元格，只重跑依赖链上的单元格。两者的性能特征不同，Streamlit 的全局重跑在大型脚本上代价高，marimo 的粒度更细。但 Streamlit 的上手门槛更低，不需要理解依赖图，写一个线性脚本就能出应用。marimo 要求用户先组织好单元格和变量边界，这既是约束也是优势。另一个差异在存储，Streamlit 脚本天然是纯 Python，marimo 也做到了这一点，但多了响应式执行层。如果你的目标只是快速把一个分析脚本变成网页应用，Streamlit 的学习曲线更平缓。如果你需要笔记本形态的交互探索，同时又要脚本化输出，marimo 的设计更贴近这个需求。
AI 功能是卖点，但依赖外部服务
README 花了不少篇幅讲 AI。编辑器内置 AI 助手，能感知当前内存中的变量，生成上下文相关的代码。也支持 marimo pair，配合 Claude Code、Codex 或 OpenCode 这类外部代理协作。系统提示词可自定义，可以用自己的 API key，也可以接本地模型。这个设计把 AI 定位为数据工作流的辅助，而不是噱头。但要注意，这些能力都依赖外部模型服务，本地模型需要额外配置。对数据敏感的环境，这可能是采用障碍。README 没有给出离线模式的承诺，也没有说明内置 AI 的具体数据流向。如果团队有严格的数据合规要求，这一点需要先确认。
维护状态与升级成本：活跃但需自行验证
仓库显示最近一次推送是 2026 年 8 月，最新版本 0.24.0 在同日发布，之前有 0.23.16 和 0.23.15 两个版本，间隔约三周。这说明项目处于活跃开发状态，版本号仍为 0.x，意味着 API 可能变动。许可证是 Apache-2.0，商用和修改都允许，这是宽松的许可。升级成本方面，0.x 版本之间可能存在破坏性变更，README 没有提供迁移指南的链接，需要查阅文档确认。另外，编辑器是浏览器界面，部署为 web 应用需要额外的服务端配置，这部分文档没有给出默认配置示例。对生产环境使用者来说，锁定版本并定期测试升级是必要步骤，但 README 没有提供版本兼容性矩阵。
编辑结论
适合受困于 Jupyter 隐状态和手动重跑单元格的 Python 数据工作者，尤其是需要把分析脚本化、用 git 管理或部署成内部工具的人。不适合重度依赖既有 Jupyter 扩展生态、需要复杂交互回调或不愿改变执行心智模型的用户。采用前应验证三件事：项目是否仍保持当前发布节奏，你的浏览器与 VS Code 插件版本是否匹配，以及 SQL 引擎对目标数据源（如 Google Sheets）的驱动是否已安装。marimo 的定位清晰，但它要求你接受一种与经典笔记本不同的执行模型，这个转换成本是真实的。
社区笔记