当我们谈论 Python 数据科学工作流时，Jupyter Notebook 几乎是无处不在的选择。然而，这种传统的线性执行模型在面对复杂的多 Agent 协作任务时暴露出一个根本性缺陷：隐藏状态（hidden state）导致的执行不确定性。当多个 Agent 需要在同一个计算环境中协同工作时，单元格的执行顺序、变量的生命周期以及状态的传递都成为难以追踪的问题。Marimo 作为新一代响应式 Python Notebook，通过有向无环图（DAG）驱动的执行模型和专为 Agent 设计的交互接口，为这一困境提供了系统性的解决方案。

响应式执行模型与计算图基础

Marimo 的核心创新在于其响应式执行机制。不同于 Jupyter 那种线性、顺序执行的模式，Marimo 在每个单元格运行时静态分析该单元格读取了哪些变量、定义了哪些变量，并据此构建一张有向无环图。当某个单元格的代码发生变化时，系统会自动识别所有下游依赖单元格，并仅重新执行那些确实需要更新的部分。这种机制与电子表格的响应式计算极为相似，但却针对 Python 程序的复杂数据流进行了专门优化。

从工程实现角度来看，Marimo 的 DAG 构建过程包含三个关键步骤：首先是对单元格进行静态分析，提取变量引用和定义关系；其次是建立单元格间的依赖边，形成完整的计算图；最后是检测是否存在循环依赖，确保执行顺序的可确定性。当用户在 notebook 中编辑或运行某个单元格时，Marimo 会遍历该单元格的所有下游节点，触发必要的重新计算，同时保留那些不受影响的计算结果。这种设计不仅显著提升了执行效率，更重要的是保证了计算结果与代码之间的确定性对应关系。

这种响应式模型对于多 Agent 协作场景具有特殊意义。在传统的 Jupyter 环境中，多个 Agent 轮流执行代码时，往往会出现「状态污染」问题：某个 Agent 修改了某个全局变量后，后续 Agent 在不完全了解前期状态的情况下继续执行，可能产生与预期截然不同的结果。Marimo 通过自动化的依赖追踪和状态清理，从根本上消除了这类隐患。每个单元格的变量定义都是显式的、可追溯的，删除一个单元格时，系统会自动清理该单元格在内存中留下的所有变量。

Marimo Pair：Agent 的交互式工作空间

2026 年 4 月发布的 Marimo Pair 将这一响应式模型的适用范围扩展到了 AI Agent 领域。传统的 Coding Agent 通常在「编辑代码 - 运行测试」的循环中工作，这对于软件工程任务来说足够有效，但面对探索性研究和数据分析工作时却显得力不从心。研究者更习惯于增量式执行代码、随时检查内存中的中间变量，依据即时反馈决定下一步操作。Marimo Pair 正是为填补这一空白而设计，它允许 Agent 完全控制一个运行中的 Marimo Notebook 会话。

具体而言，Marimo Pair 以 Agent Skill 的形式实现，支持 Claude Code、Gemini、Codex、OpenCode 等主流 Agent 的接入。Agent 获得的能力远超传统 REPL：它可以直接读取 notebook 中的所有变量，在临时 Scratchpad 中执行任意代码来验证逻辑而不影响原始 notebook，通过添加或删除单元格来持久化状态，甚至可以安装新的 Python 包。整个交互过程被完整记录在关联的 notebook 文件中，而 Marimo Notebook 本身就是一个纯 Python 文件天然支持版本控制。

这种设计带来一个关键优势：Marimo 成为 Agent 的「结构化工作记忆」。在传统方案中，Agent 只能通过 prompt 或外部存储与人类共享上下文，信息传递存在显著的带宽限制。而在 Marimo Pair 模式下，Agent 和人类共享同一个 notebook 作为协作画布，双方都能看到实时的变量状态、计算结果和代码演进。这种共享心智模型的方式极大降低了人机协作的沟通成本。

Code Mode：面向模型的 REPL 扩展

Marimo Pair 的技术核心在于「Code Mode」—— 一个专为语言模型设计的半私有接口。Code Mode 将 Marimo 转换为一个增强型 REPL，但它与传统 REPL 存在本质区别：Marimo 的 REPL 增量式构建的是一个可重现的 Python 程序，而非一系列孤立的命令执行。每个单元格的执行都遵循数据流图的语义约束，Agent 的操作被自动纳入到依赖关系网络中。

这种机制为 Agent 提供了强有力的执行保障。当 Agent 在 Code Mode 中运行时，它受到与人类用户相同的「护栏」保护：运行某个单元格会自动触发下游依赖单元格的重新执行，删除某个单元格会自动清理该单元格在内存中留下的所有变量。这些护栏在传统 REPL 环境中是不存在的，Agent 的误操作可能导致难以追踪的内部状态损坏。Marimo 通过将响应式执行模型延伸至 Agent 交互层面，实现了计算环境的自我一致性保证。

从工程实践角度看，Code Mode 不是一个公开的、版本化的 API，而是一个内部接口。这种设计选择反映了团队对 Agent 行为模型的深刻理解：传统软件 API 需要在版本间保持严格兼容性，但与语言模型的交互契约更接近「运行时与解释器」的关系 —— 模型能够阅读文档、理解接口语义并自适应调整。只要底层语义保持稳定，接口层面的迭代不会破坏已有的 Agent 工作流。

多 Agent 协作的状态管理参数

在实际的多 Agent 协作场景中启用 Marimo 时，以下工程参数值得关注。首先是响应式执行策略的选择：Marimo 支持两种模式 —— 自动重算模式（下游单元格自动执行）和手动模式（下游单元格标记为 stale 而不立即执行）。在多 Agent 环境中，建议对计算密集型的下游单元格使用手动模式，避免某个 Agent 的操作触发大量不必要的重算。其次是 Cell 的粒度设计原则：每个单元格应遵循「单一职责」原则，清晰定义输入输出变量，这不仅便于 Marimo 构建准确的依赖图，也使得多个 Agent 可以在不同单元格上并行工作而不会产生意外的相互干扰。

另一个关键配置是 Session 隔离策略。Marimo 的 notebook 以 Python 文件形式存储，默认情况下每个 notebook 对应一个独立的内核进程。在需要多 Agent 并发访问同一 notebook 的场景中，可以考虑使用 Marimo 的实验室功能标志（lab feature flag）启用共享内核模式，但需要注意此时的状态一致性完全由响应式执行模型保障 —— 这既是安全保障，也是行为约束。

面向多 Agent 场景的监控与调试

虽然 Marimo 的响应式模型极大简化了状态管理，但在复杂的多 Agent 协作中仍然需要适当的监控手段。Marimo 提供了依赖图可视化功能，可以直观展示单元格之间的数据流关系，这在调试多 Agent 引入的异常行为时尤为有用。建议在多 Agent 项目中定期检查依赖图的完整性，确保新增的单元格都被正确纳入 DAG 结构中。

另一个实用的调试策略是利用 Scratchpad 的临时性。Agent 在验证某个假设时，可以在 Scratchpad 中执行探索性代码，确认逻辑正确后再将关键操作持久化到正式单元格中。这种「先试后写」的工作模式有效降低了试错成本，也使得 Agent 的决策过程对人类协作者更加透明。

从长期演进的角度看，Marimo 团队正在探索将 Marimo 作为递归语言模型的上下文扩展工具 —— 通过将模型连接到 Marimo 内核，利用响应式 REPL 消除隐藏状态并生成可重放的 Python 程序。这种方向如果成功，将为自主研究（autoresearch）场景中的模型自我修正和迭代优化提供全新的基础设施。

资料来源：本文技术细节主要参考 Marimo 官方博客文章《Introducing marimo pair》（2026 年 4 月 7 日发布）以及 Marimo 文档中关于响应式执行模型和有向无环图机制的说明。