编者摘要：
本文介绍清华团队提出的OpenRath，一套以Session 会话为一等运行时对象的多智能体框架，旨在解决现有Agent 系统运行时状态碎片化、难以审计、分支复现困难的痛点。现有工具日志、沙箱操作、记忆交互、分支轨迹分散存储，无法统一溯源。OpenRath 借鉴PyTorch 架构思想，设计Session、Agent、Sandbox、Memory 等七大核心组件，统一遵循Session→Session 转换契约。Session 作为贯穿程序的可流转活态对象，原生支持fork、merge、回放，完整留存对话、工具证据、沙箱环境、记忆读写、分支谱系等信息。框架兼容LangGraph、MCP、AutoGen 等主流生态而非替代，通过分层后端隔离工具与记忆执行环境。论文提出审计优先评估体系，以可复现证据包验证运行时能力，区分已实现模块与待完善模块。当前已完成会话核心、本地沙箱、多Agent 工作流实现，记忆模块、远程沙箱仍待补充。该工作核心价值是为智能体系统提供统一、可观测、可分支的运行时载体，为调试、审计、系统化评测提供底层支撑.
作者：清华大学温福康、王智杰、徐瑞林团队
常见三个问题问与答
Q1：OpenRath 解决了现有Agent 系统的什么问题？
A1：解决运行时状态碎片化问题。传统Agent 仅依靠聊天记录存储交互，工具日志、沙箱文件修改、记忆读写、并行分支、上下文丢弃证据分散在各类独立侧通道，无法溯源分支来源、工具修改记录、压缩丢弃信息，难以审计、调试、复现；OpenRath 将所有执行痕迹统一绑定在Session 对象中，全链路可观测。
Q2：OpenRath 借鉴PyTorch 的设计思路体现在哪里？
A2：并非复用张量数值计算，而是借鉴统一流动值+ 可复用变换模块+ 显式设备绑定架构。Session 对应Tensor 作为贯穿全流程的运行时值；Sandbox 对应Device 绑定执行后端；Agent、Workflow 类似网络层/ 模块，统一采用输入输出Session 接口；Selector 承担动态控制流，Memory 类比持久参数，实现模块化、可组合的智能体编程范式。
Q3：OpenRath 和LangGraph、OpenAI Agents SDK 等工具是替代关系吗？
A3：不是替代，属于互补衔接层。LangGraph 侧重调度检查点、OpenAI SDK 侧重追踪日志、MCP 标准化工具调用，它们缺少跨层统一流转的状态载体。OpenRath 以Session 作为中间交换对象，串联调度器、追踪系统、沙箱、工具协议，不替换原有模块，仅统一承载所有执行证据，打通各层状态孤岛。
清华团队开源OpenRath：面向智能体系统的会话中心式运行时状态管理框架论文标题：OpenRath: Session-Centered Runtime State for Agent Systems（清华团队，arXiv:2606.19409，2026）
定位：面向多智能体系统、以Session 会话为一等运行时核心对象的新型运行时框架，解决现有Agent 系统运行时状态碎片化、不可审计、难以复现/ 分支/ 合并的工程痛点，类比PyTorch 张量流式编程范式，兼容主流Agent 生态工具而非替代。
一、研究背景与核心问题
1.1现有Agent 系统核心缺陷：碎片化运行时状态
传统Agent 仅依靠聊天消息列表存储交互记录，工具日志、沙箱文件修改、记忆读写、分支尝试、上下文压缩丢弃证据、模型调用消耗、多角色分工等数据分散在独立侧通道，存在严重隐藏运行时状态问题：
无法溯源：无法定位哪条分支生成最终答案、哪个工具修改文件、压缩阶段丢弃了哪些证据；
多智能体/ 长流程场景失效：当工作拆分多角色、并行分支、中断续跑、沙箱执行代码时，单纯消息列表无法承载完整执行轨迹；
审计、调试、复现困难：状态散落在控制器日志、工具服务、内存库、追踪系统中，无法统一回溯。
1.2三类运行时记录的本质区别（论文核心划分）
现有系统三类存储载体定位完全不同，均无法作为Agent 程序直接传递的运行时值：
表格
载体 |
服务对象 |
核心存储内容 |
短板 |
图检查点Graph checkpoint |
调度器 |
控制流执行位置，用于断点续跑、时间回溯 |
仅服务调度，不能被Agent 自由分支、合并、传递 |
追踪跨度Trace span |
观测者 |
执行观测事件（模型调用、工具调用），用于事后监控 |
后置日志，不是程序运行时原生对象 |
OpenRath Session 会话 |
Agent 程序本身 |
可直接流转的活态对象：对话片段、溯源元数据、沙箱环境、工具证据、记忆操作、Token 消耗、分支谱系 |
原生支持fork/merge/ 回放，所有执行证据随对象绑定 |
1.3生态定位：互补而非替代
当前主流Agent 基础设施（AutoGen、LangGraph、OpenAI Agents SDK、MCP 工具协议、沙箱、追踪系统）各司其职，但缺少统一跨层流转的状态载体。
OpenRath作为中间衔接层：不替换调度器、追踪、工具协议、沙箱、评测框架，仅提供Session 统一状态对象，串联所有模块，解决“跨层状态不互通” 问题。
二、论点与PyTorch 类比设计思想
2.1中心论点
多智能体系统需要一等公民（First-class）运行时状态对象，OpenRath 将Session 定义为该对象；所有Agent、工具、工作流的变换均遵循 Session → Session 统一接口，让分支、合并、转交、回放成为原生运行时操作，而非事后从日志重建。
2.2 PyTorch架构类比
不模仿张量数值计算，借鉴PyTorch“单一流动值+ 可复用变换模块+ 显式设备绑定” 的架构范式，建立Agent 运行时映射：
表格
PyTorch 概念 |
OpenRath 对应对象 |
作用 |
Tensor 张量 |
Session 会话 |
贯穿全流程的流动运行时值，承载全部执行证据 |
Device 设备 |
Sandbox 沙箱 |
执行环境绑定，session.to(backend) 指定运行后端 |
Parameter 参数 |
Memory 记忆层 |
持久化状态，与临时对话上下文分离 |
Function 算子 |
Tool 工具 |
可调用执行单元，带结构化入参校验 |
nn.Linear 网络层 |
Agent 智能体 |
可复用会话变换单元，封装提示词、模型、工具策略 |
nn.Module 模块 |
Workflow 工作流 |
嵌套组合多个Agent / 工具/ 分支的容器 |
控制流逻辑 |
Selector 选择器 |
运行时根据Session 动态路由下一步工作流，替代硬编码流程 |
2.3关键设计约束
所有组件不私藏独立状态：溯源归属Session、工具执行依赖沙箱、记忆读写暴露为Session 事件、工作流不创建私有编排日志，保证全链路可观测。
三、OpenRath 对象编程模型
框架仅定义7 个极简核心组件，统一围绕Session 完成变换、标注、执行：
Session（核心）
唯一流转运行时值，存储：对话片段、分支谱系、沙箱绑定、工具执行证据、记忆读写事件、Token 用量、待执行任务；原生支持fork（分支复制）、detach（新建独立谱系）、merge（合并多分支并保留双亲溯源）、持久化JSONL 导出、回放。
Agent智能体
可复用变换单元，固定输入输出Session；内置专属提示词、模型服务商、工具权限、记忆读写策略。
Tool工具
带JSON 模式校验的可调用单元，接收Session 与参数，通过沙箱分发执行负载，执行结果/ 错误全部写入Session 证据流。兼容MCP 标准工具协议。
Sandbox沙箱
执行边界，隔离文件、命令、代码运行；区分本地后端与可选OpenSandbox 远程沙箱，Session 绑定沙箱句柄统一管理资源生命周期。
Memory记忆层
独立于对话上下文的持久化平面，recall读取、commit写入均为Session 可见运行事件，不隐藏在Prompt 文本中；本地嵌入、外部记忆服务均可接入。
Workflow工作流
组合容器，支持嵌套Agent、工具、分支、上下文压缩、子工作流；对外仅暴露forward(session)统一接口，隐藏内部复杂逻辑。
Selector路由选择器
动态控制流核心：读取当前Session 状态，运行时选择下一条执行工作流，无匹配任务则终止；分支、循环路由记录全部写入Session，避免硬编码逻辑丢失溯源。
四、运行时架构与Session 完整生命周期
4.1 Session生命周期六阶段（同一对象贯穿全程，不生成独立状态）
Create创建：初始化用户输入、Agent 提示、角色、对话分片；
Place绑定环境：通过session.to()指定执行后端，绑定沙箱工作空间；
Transform变换：Agent / 工具/ 压缩器修改Session，记录模型调用、工具返回、报错、资源消耗；
Branch分支：fork 复制父会话保留谱系、detach 生成全新根会话、merge 合并兼容会话（沙箱一致才可合并）；
Persist持久化：导出JSONL 溯源文件，包含会话ID、父分支ID、操作类型、对话片段、用量统计，支持命令行直接解析；
Release释放：回收沙箱资源、销毁后端句柄。
4.2工具执行分层架构
模型侧：仅感知标准化FlowToolCall 工具模式；
Session层：校验工具参数、绑定当前沙箱；
后端层：沙箱执行命令/ 代码/ 文件操作，捕获stdout、产物、报错；
回流层：所有执行结果结构化写入Session 工具证据分片，无日志丢失。
五、多智能体、多会话协同设计
5.1多Agent 统一契约
无论单Agent 多会话、多Agent 共享状态、嵌套工作流，全部遵循输入输出Session 规范，不会引入额外私有消息总线、状态对象：
单Agent 多会话：同一智能体参数复用，每个fork 会话独立保存沙箱、分支、工具记录；
多Agent 协作：规划、编码、QA 等专家Agent 依次消费并返回Session，每一步中间状态均可审计；
嵌套工作流：子工作流封装内部逻辑，父层仅接收最终Session，无需感知内部编排；
全链路可观测：故障、预算超限、分支来源、中断记录全部绑定Session。
5.2框架生态衔接逻辑
Session作为跨层“交换对象”，对接各类主流Agent 基础设施：
对接图运行时：提供可调度、可断点的会话状态；
对接追踪SDK：所有追踪事件挂载到唯一Session 主体；
对接MCP 工具协议：外部工具执行结果转化为Session 证据；
对接沙箱环境：统一管理执行资源与文件修改记录；
对接评测基准：完整执行轨迹可导出，用于任务结果溯源校验。
六、论文四大技术贡献
以Session 为中心的数据流：将对话、沙箱、分支、工具、记忆、用量等分散数据统一为单一可观测流转对象，替代控制器分散记账；
PyTorch式轻量化Agent 对象模型：7 个核心组件统一Session→Session变换接口，支持可复用、嵌套、动态路由；
后端解耦边界：将工具执行后端、记忆持久后端与运行时状态分离，本地环境、远程OpenSandbox、MCP 工具、外部记忆服务均可接入；
审计优先的发布验证协议：基于证据包（evidence packet）做可复现校验，区分已验证、待验证、受限能力，不盲目宣称SOTA 性能。
七、实现落地与验证方案
7.1工程实现现状（Python 软件包）
已完成可运行代码快照，分模块实现：会话核心、执行后端、工具/ Agent / 工作流、LLM 服务商层、溯源持久化；各模块验证状态区分：
✅已完整验证：Session 分支/ 合并、本地沙箱、标准化工具调用、多阶段工作流、JSONL 溯源导出、单元测试；
⚠️可选未配置：OpenSandbox 远程沙箱；
⏳待完善：本地记忆模块（仅完成接口定义，无完整测试样例）；
超出本文范围：LLM 模型推理质量、大规模基准对比。
7.2审计优先评估协议（区别于传统性能benchmark）
论文不做横向性能跑分，专注运行时正确性验证，采用「证据包+ 声明台账」机制：
证据包：每条技术结论配套可复现运行包，包含执行命令、环境元数据、Session 日志、输出产物、边界说明；
声明台账：分类管理所有论文结论，区分完全支持、部分支持、前置条件支持、待验证、仅理论定位；
评测边界：仅验证运行时可观测、可分支、可回放能力；模型效果、记忆检索质量、大规模调度性能留到后续工作。
7.3适用业务案例（定性验证，无定量指标）
代码仓库编辑：多角色规划、沙箱文件修改、QA 校验、工作空间溯源；
长周期代码开发：中断续跑、上下文压缩、预算管控、沙箱持续复用；
科研文献综合：多分支文献检索、分支独立压缩、结果融合；
记忆增强工作流：记忆读写作为显式Session 事件（当前证据待补齐）；
沙箱隔离执行：本地命令、代码执行全链路日志留存（已完整验证）。
八、现有局限（明确范围，不夸大能力）
论文清晰划定当前版本边界，所有未完成能力作为后续研究方向：
基准评测：仅小规模确定性测试，无跨框架大规模对比基线；
后端兼容：仅本地沙箱充分验证，OpenSandbox 无完整适配包；
记忆模块：仅定义抽象层，本地记忆实现缺少完整测试用例；
多Agent 权限：无角色权限、工具操作管控、人工审核策略；
安全能力：未做Agent 安全基准测试，存在间接..
OpenRath Git 仓库地址
GitHub 仓库链接
https://github.com/Rath-Team/OpenRath
克隆命令
git clone https://github.com/Rath-Team/OpenRath.git
配套项目资源
-
官网：https://www.openrath.com/ -
文档站：https://docs.openrath.com/ -
PyPI 安装： pip install openrath -
开源协议：BSD-3-Clause