Agent 越来越多了，但 Session 却越来越乱了。

这不是某一家公司的困境。从硅谷到中关村，几乎所有人把多智能体系统真正跑大之后，都会撞上同一堵墙：一个 Agent 维护一份上下文，另一个 Agent 又复制一份历史；一条任务分叉出好几条推理路径，最后没人说得清哪条分支产出了最终答案；模型调用、工具执行、沙箱环境、长期记忆各管各的状态——Demo 跑得挺好，可当系统扩到几十上百个 Agent，调试、复现、编排全部开始失控。

最近，一个来自清华大学、中山大学和香港中文大学的联合团队（Rath Team）把他们的解法开源了，叫 OpenRath。它的主张一反常态：别再围着 Agent 转了。真正该被当成一等公民的，是 Session。

目前 OpenRath 已在 PyPI 发布到 v1.2.1，BSD-3-Clause 协议，pip install openrath 即可安装。但这远不是"又一个 Agent 框架"——它真正想做的事情，是用一套深度学习开发者熟悉的抽象，彻底重构多智能体系统的运行时底座。

一、Agent 动了手，证据该存在哪

要理解 OpenRath 的出发点，先回到一个看似简单的问题：当 Agent 真的对世界动了手，它的行动证据存在哪？

第一代大模型应用可以概括为"提示词进、回答出"。但 Agent 系统改变了这条边界。一个有用的 Agent 不只是产出文本——它会检索、规划、调用工具、读文件、写代码、跑测试、操作浏览器，有时还会改动外部状态。如果一次工具调用读了文件，我们需要它的参数和结果；如果它改了仓库，我们需要 diff；如果它失败重试了，我们需要那条失败路径；如果有人批准或否决了某个动作，我们需要那个校验信号。

一份聊天记录顶多叙述这些事，却不足以还原这些事。

举个例子：一个软件任务中，研究 Agent 读了 issue、检索了笔记；编码 Agent 改了仓库；沙箱跑了测试；校验 Agent 否决了第一版补丁，于是工作流分叉；记忆后端记下这次失败，免得以后重犯。如果这些事件散落在各自的日志里，最终答案几乎是最不重要的产物——真正有价值的，是那条"工作如何一步步推进"的证据链。

这就是 OpenRath 的出发点：把 Session 当成证据的载体，而不只是聊天历史。

二、别人解决 Agent 之间怎么说话，它问说完之后谁拥有工作

多智能体这个词，常让人想到一个群聊：一个 Agent 提议，一个批评，一个执行，一个主管决定什么时候收尾。这个模式有用，但不够。

这条路上已经有不少工作：AutoGen 把多 Agent 对话做成了实用的编程模型；CrewAI 把 Agent 团队和结构化流程分开；LangGraph 用图状态和 supervisor 节点表达路由与控制。它们都解决了 Agent 之间怎么说话的问题。

OpenRath 接着往下问了一句：Agent 们说完话之后，谁来拥有这份工作的状态？

一个生产级的 Agent 集群，需要决定：当前这个 Session 该交给哪个 Agent？它该看到什么上下文？读了哪些记忆？下一条命令在哪个沙箱跑？继续之前需要什么校验信号？这些都是控制平面的问题，靠往群聊里再加一个角色是解决不了的。

OpenRath 的答案是：让 Session 成为路由的单位，让 Session Graph 成为那张控制平面——Agent、工具、工作流、记忆、沙箱位置，都在这张图上交汇。用官方的话说就是：Agent 是工人，Session 才是工作本身。

从 Agent 数量 × Session 数量两个维度看，多智能体系统分成四象限：单 Agent 单 Session 是 ChatGPT 式聊天；多 Agent 单 Session 是子代理协作；单 Agent 多 Session 是分支扇出；而多 Agent 多 Session（MAMS），正是 OpenRath 面向的方向。

它的判断很干脆：真正需要被 fork（分叉）、merge（合并）、复用、追踪的，是整条 Session 数据流——而非某个 Agent 内部那份各自维护的消息列表。大多数框架攒的是一屋子聪明的工人，OpenRath 先把工位、工单和流水线建好。

三、从 PyTorch 借来的三根支柱

OpenRath 最聪明的一步，是把深度学习开发者最熟的那套抽象，整套搬到了 Agent 系统上。

PyTorch 为什么好用？因为它把复杂计算拆成了清晰的积木：Tensor 是流动的数据，Module/Layer 是变换数据的可组合单元，device 决定算在哪，而整张计算图是跑起来才长出来的。OpenRath 给 Agent 系统做了几乎一一对应的映射：

Tensor → Session，Module/Linear → Workflow/Agent，Device → Sandbox/Backend，Parameter → Memory，Function → Tool，控制流 → Selector。

这套映射不是噱头。拆开来，是理解 OpenRath 的三根支柱：

支柱一：Agent 是变换层，不是全能助手。 PyTorch 里，nn.Linear 不是一个应用，它只是一层变换：吃进一个 Tensor，吐出一个 Tensor。OpenRath 把 Agent 设计成了同一种东西——forward(session) -> session。进来一个 Session，出去一个 Session。同样这个接口形状，可以装下调工具的 Agent、压缩上下文的 Compressor、读写记忆的 Memory Agent、做摘要或校验的专用 Agent。它们都对外是同一个接口，于是能像神经网络的层一样任意堆叠、任意嵌套。管上百个 Agent，从拼提示词变成了搭模块。

支柱二：Sandbox 与 Memory 是可插拔后端。 PyTorch 把"算在哪"从"算什么"里剥了出来，.to("cuda")就上 GPU，换后端就换卡。OpenRath 把这个思想用在了两个最容易被写死的地方：执行环境和长期记忆。Sandbox 绑在 Session 上，工具跑在哪由 Session 当前的 backend 决定，本地进程、容器沙箱、未来任何第三方执行后端都可以接入。Memory 同样是可插拔的：基础安装有零依赖的本地后端，配了 embedding 能用向量排序，想更强的可以接外部记忆服务。执行环境和记忆都成为可替换的 device，状态、执行、记忆、编排彼此解耦，却又都串在同一个流动的值——Session——上。

支柱三：Session Graph 是动态图。 PyTorch 的图是代码跑到哪、图就长到哪，不要求事先画死。OpenRath 的 Session Graph 是同一性格：Session 能 fork 分支、能 detach 切断父链、能 merge 合并，还能序列化成 JSONL 交给下一个 Workflow。这张图是 Agent 们跑起来、一步步演化出来的，而非事先画死的剧本。

为什么这件事对 Agent 集群是决定性的？因为集群规模一大，你迟早要回答：这个结论到底是哪个 Agent、走哪条分支、调哪次工具、在哪个 workspace 产出的？散落的日志答不了，一张带血缘的动态图能答。Session Graph 于是从实现细节升格成了集群的可观测层与控制层——路由、复现、回滚、审计，全在同一张图上做。

这里还有一个精妙的设计：Selector。很多框架把流程提前编排死——if 走 A，else 走 B。OpenRath 的 Selector 是一个由大模型驱动的路由器，在若干个"会自我描述"的 Workflow 之间做选择，让 Agent 之间的 if/while 仍然是普通的 Python 代码。流程从写死的剧本，变成了运行时才定下来的路由——和 PyTorch 动态图里"代码跑到哪、图就长到哪"是同一种自由。

四、从 Demo 到生产，它到底能不能用

最能说明问题的，是 OpenRath 的 example/ 目录——一条编号递进的学习阶梯，每个脚本只讲一个概念，前一个的产出正好是后一个的输入：

• 01_hello_agent：最小程序，构造 Agent、在 Session 上调用、流式输出
• 02_session_lineage：用 fork 分叉、detach 切断血缘、查看 session graph、导出 JSONL
• 03_sandbox_backend：把同一个 Session 放到 local 或 opensandbox，看工具在哪执行
• 04~06：内置工具、自定义工具、MCP 工具
• 07~10：流式、上下文压缩、记忆、换模型厂商
• 11_dynamic_selector：用 Selector 做 if 分支和 while 循环

从"先让一个 Agent 跑起来"到"让一群 Agent 动态协作"，11 步走完，核心也就理解透了。安装也分层：基础 pip install openrath，要容器沙箱加 [opensandbox]，要外部记忆加 [openviking]。

更值得说的是这套 example 的设计取向：官方强调，例子的目标是产出一份"证据档案"，而不是一张截图。一个软件任务跑完，理想的产物不该只停在一句"成功了"，而该是一整份可回溯的卷宗——issue 原文 → Session Graph → 调了哪些工具 → 副作用落在哪个 sandbox → 被否决的那条分支 → 最终采纳的补丁 → 测试结果 → 这次往 Memory 里写了什么。这份卷宗，正是"一个 Demo"和"一个能拿来做技术报告的运行时"之间的区别。

五、结语：从 Prompt 工程走向系统工程

OpenRath 的版本演进本身就是一条干净的线。v1.1 解决"持久"——如果一个 Agent 的工作是跨时间展开的，凭什么唯一被保存的只有最终答案？于是有了持久 Session，把干活的证据完整留下。v1.2 再抬高一层：让 Session 从"单个 Agent 事后可查的记录"，升级成"能在多个 Agent 和工作流之间被路由的对象"。一行代码就概括了这个转变：session = workflow.forward(session)。

它意味着，工作的单位从一个 prompt、一个答案或一个 Agent 角色，挪到了一份持久、可路由的 Session 状态上。

如果说过去的 Agent 框架面向的是"一个智能助手"，那么 OpenRath 面向的是"一个智能体系统"。在 PyTorch 里，你定义 Module，让 Tensor 在网络中流动；在 OpenRath 里，你定义 Agent 和 Workflow，让 Session 在系统中流动。剩下的——血缘记录、工具调度、沙箱绑定、长期记忆、动态路由——交给框架。

而这件事的起点，朴素得有点反直觉：不是再多造一个 Agent，而是先把 Session 当回事。

---

参考资料：

1. 上百个Agent，该怎么管？清华团队新思路：重做Session - 51CTO
2. OpenRath 官网
3. OpenRath 文档
4. OpenRath GitHub
5. OpenRath 博客