当Agent数量增多时，管理混乱成为难题。OpenRath提出用Session作为核心，代替Agent为中心的设计，使多个Agent能共享状态，实现更清晰的协作与控制。
agent越来越多，session却越来越乱。
这是几乎所有人把多智能体系统真正跑大之后，都会撞上的一堵墙。
一个Agent维护一份上下文，另一个Agent又复制一份历史；一个任务分叉出好几条推理路径，最后没人说得清哪条分支产出了最终答案；模型调用、工具执行、沙箱环境、长期记忆各管各的状态——demo 跑得挺好，可当系统扩到几十上百个 Agent，调试、复现、编排全部开始失控。
最近，一个来自清华大学与中山大学的团队（Rath Team）把他们的解法开源了，叫OpenRath：这是一个像PyTorch的多智能体、多会话运行时。
它的主张是：别再围着Agent转了。真正该被当成一等公民的，是Session。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
官网：https://www.openrath.com/
文档：https://docs.openrath.com/
博客：https://blog.openrath.com/
GitHub：https://github.com/Rath-Team/OpenRath
开源协议：BSD-3-Clause ｜ 当前版本：v1.2.1（PyPI）
目前OpenRath已在PyPI发布到 v1.2.1，pip install openrath就能装，BSD-3-Clause协议，官网、文档、博客、GitHub一应俱全。
本文将从「为什么」一路讲到「怎么用」，重点拆OpenRath和AutoGen、LangGraph这些框架到底不一样在哪——以及它为什么敢借PyTorch的名字。
Agent运行时用「聊天记录」思考
第一性问题：当Agent真的动了手，证据该存在哪？
第一代大模型应用，可以概括成「提示词进、回答出」。Agent系统改变了这条边界。
一个有用的Agent不只是产出文本。它会检索、规划、调用工具、读文件、写代码、查API、跑测试、操作浏览器，有时还会改动外部状态。ReAct让推理和行动在一个循环里交替，Toolformer 让模型学会何时调用工具，再到Model Context Protocol把工具变成协议级的边界，这条线一直在往前走。
可一旦Agent真的对世界动了手，一个运行时层面的问题就冒出来了：这些动作的证据，到底存在哪？
如果一次工具调用读了文件，我们需要它的参数和结果；如果它改了仓库，我们需要diff；如果它跑在某个沙箱里，我们需要沙箱的身份；如果它失败重试了，我们需要那条失败路径；如果有人批准或否决了某个动作，我们需要那个校验信号。一份聊天记录顶多叙述这些事，却不足以还原这些事。
举个具体例子。
一个软件任务：研究Agent读了issue、检索了笔记；编码Agent改了仓库；沙箱跑了测试；校验Agent否决了第一版补丁，于是工作流分叉；记忆后端记下这次失败，免得以后重犯。如果这些事件散落在各自的日志里，那么最终答案几乎是最不重要的产物，真正有价值的，是那条「工作如何一步步推进」的证据链。
这就是OpenRath的出发点：把Session当成证据的载体，而不只是聊天历史。
为什么是Agent Cluster
单个Agent会膨胀成一个巨大的prompt，于是要把它拆开。
早期一个Agent基本够用：接收输入、理解任务、调用工具、返回结果，像个增强版聊天机器人。但真实任务很快超出单个Agent的边界。
一个像样的软件工程任务，往往要拆成需求理解、资料检索、架构设计、代码实现、测试验证、结果审查。不同环节要的能力并不一样——有的擅长规划，有的擅长写码，有的擅长挑错。继续让一个Agent全包，它就会膨胀成一个巨大的prompt和一个越来越混乱的上下文窗口。
于是有了Agent Cluster：让Planner、Researcher、Coder、Reviewer、Executor、Memory Agent各司其职，围绕一个复杂目标协作。
多个专业Agent围绕共享的Session协作：各自读取当前状态、完成局部任务、把结果写回，供下一个Agent接力。
可一旦真把它跑起来，难题就冒出来了：这些Agent怎么共享上下文？某个结论到底来自哪个Agent、哪条分支、哪次工具调用？一个Agent出了错，能不能回滚到对应分支重来？
说白了，Agent Cluster真正的挑战，从来都不在「造更多Agent」——难的是管住这些Agent之间的状态怎么流动。
OpenRath多问了一句
别人解决Agent之间怎么说话，它问说完之后谁拥有这份工作。
多智能体这个词，常让人想到一个群聊：一个Agent提议，一个批评，一个执行，一个主管决定什么时候收尾。这个模式有用，但不够。
这条路上已经有不少工作：AutoGen把多Agent对话做成了一个实用的编程模型；CrewAI把Agent团队和更结构化的流程分开；LangGraph用图状态和supervisor节点来表达路由与控制。它们都解决Agent之间怎么说话。
OpenRath接着往下问了一句：Agent们说完话之后，谁来拥有这份工作的状态？
一个生产级的Agent Cluster，需要决定：当前这个Session该交给哪个 Agent、它该看到什么上下文、读了哪些记忆、下一条命令在哪个沙箱跑、继续之前需要什么校验信号。这些都是控制平面的问题，靠往群聊里再加一个角色是解决不了的。OpenRath的答案是：让Session成为路由的单位，让Session Graph成为那张控制平面——Agent、工具、工作流、记忆、沙箱位置，都在这张图上交汇。
一句话：Agent集群不是群聊，而是建立在持久Session状态之上的运行时控制平面。
这也是为什么，从Agent数量×Session数量两个维度看，多智能体系统会分成四象限：
单Agent单Session是ChatGPT式聊天；多Agent单Session是子代理协作；单Agent多Session是OpenClaw式分支扇出；而多Agent多Session（MAMS），正是OpenRath面向的方向。
OpenRath把这套思路称为MAMS（Multi-Agent Multi-Session）。它的判断很干脆：真正需要被fork（分叉）、merge（合并）、复用、追踪的，是整条Session数据流——而非某个Agent内部那份各自维护的消息列表。
换个说法：大多数框架攒的是一屋子聪明的工人，OpenRath先把工位、工单和流水线建好。用官方那句话说就是——Agent是工人，Session才是工作本身。
像PyTorch一样搭Agent集群
这不是蹭名字。
PyTorch之所以好用的三个设计，OpenRath一一对应搬了过来。
OpenRath最聪明的一步，是把深度学习开发者最熟的那套抽象，整套搬到了Agent系统上。
PyTorch为什么好用？因为它把复杂计算拆成了清晰的积木：Tensor是流动的数据，Module/Layer是变换这份数据的可组合单元，device决定算在哪，而整张计算图是跑起来才长出来的。OpenRath给Agent系统做了几乎一一对应的映射：
核心映射：Tensor→Session、Module/Linear→Workflow/Agent、Device→Sandbox / Backend、Parameter→Memory、Function→Tool、控制流→Selector。
下面三节，正是把这张表里最关键的三组对应，从术语对照讲成为什么这么设计。
这套映射不是噱头。把它拆开，PyTorch真正教给OpenRath的，其实是三件事——下面三节，正好是理解OpenRath的三根支柱。
支柱一：Agent是变换层 ，不是全能助手
Layer不持有数据；Agent也不持有状态。
PyTorch里，nn.Linear不是一个应用，它只是一层变换：吃进一个Tensor，吐出一个Tensor。一个网络的本事，来自很多这样的层被叠起来。
OpenRath把Agent设计成了同一种东西。Agent就是Session上的一层变换。它的核心，就是一条forward(session) -> session的路径：进来一个Session，出去一个Session。
关键在于，变换层不止一种。同样是forward(session) ->session这个形状，可以装下完全不同的活儿：
- 一个Agent调工具、改workspace里的文件，把执行结果写回Session；
- 一个Compressor把跑了几十轮的长会话压缩成一条精简消息（官方example第 8课就是它）；
- 一个Agent在跑之前recall记忆、跑之后commit记忆，相当于给这次会话做了一次「索引与归档」；
- 你也可以写一个只做摘要、只做校验、只做改写的Agent。
它们对外都是同一个接口，于是能像神经网络的层一样任意堆叠、任意嵌套。这正是Workflow（对应nn.Module）的意义：子类只要实现一个 forward(session) -> session，里面就能串联多个Agent、fork Session、压缩上下文、调用工具、分发到子工作流。因为每一层进出都是 Session，Workflow能像nn.Module一样层层包起来，每层不必重新发明一套状态格式。
管上百个Agent，于是从拼提示词变成了搭模块。Layer不持有数据，数据是 Tensor；Agent 也不持有状态，状态是Session。
这里还藏着一个容易被忽略的好处。因为Agent不拥有整个世界——Session loop仍是引擎，Sandbox仍是执行位置，Memory仍是独立store——所以单个Agent的场景足够简单，同一个Agent又能被原样塞进更大的 Workflow，不用改一行。
至于工具本身，OpenRath抽象成了FlowToolCall：一手攥着给模型看的name / description / JSON schema，一手攥着真正在Python里执行的行为，让工具长什么样」和工具干什么始终待在一起。内置了文件、shell、代码执行工具，stdio的MCP工具也能直接适配进同一个循环。底层还有个清晰的分层：FlowToolCall是flow层模型可见的函数，BackendTool*才是沙箱后端真正消费的载荷。
支柱二：Sandbox与Memory是「可插拔后端」
把后端写死，等于把模型焊在CPU上。
PyTorch第二个聪明的地方，是把「算在哪」从「算什么」里剥了出来。同一份模型代码，.to("cuda")就上GPU，换个后端就换块卡，计算逻辑一行不用动。device / compute backend是可插拔的。
OpenRath把这个思想用在了两个最容易被写死的地方：执行环境和长期记忆。
Sandbox（对应 Device）——工具到底在哪运行。很多框架把「对话历史」和「工具实际执行的位置」分开管，模型以为自己还在某个工作区，shell或容器其实早就切走了。
OpenRath把Sandbox绑在Session上：工具跑在Session当前的backend上，返回的Session会记住自己的执行位置，不会悄悄漂移。
而它真正的巧思，是把Sandbox做成了可插拔的backend：本地进程始终可用（session.to("local", spec="./")），容器化的OpenSandbox是可选项（pip install "openrath[opensandbox]"），未来任何第三方执行后端，只要接到同一套 Session placement 模型后面就能用。执行环境，从此不再硬编码进某一个 shell。
Memory（对应 Parameter）——跨运行保留的记忆。
它是独立的一层持久状态，能绑定到 Agent、运行前 recall、运行后 commit；既不像工具结果那样用完即弃，也不只是塞进 prompt 的几行文本。
基础安装自带零依赖的本地后端，把数据存在 .openrath/memory/，不用 LLM 也能做BM25词法检索；
配了embedding就能用向量排序；想要更强的，可以接OpenViking这类外部记忆服务。和Sandbox一样，Memory同样是可插拔backend——recall不绑死在某一个数据库上。
这一招对自带本地状态的团队尤其友好：你已经有自己的容器调度、有自己的向量库或知识库，不必推倒重来，只要把它包成一个backend接进去，就能复用OpenRath的整套Session / Workflow抽象。说到底，把执行环境和记忆都做成可换的device，OpenRath才能让状态、执行、记忆、编排彼此解耦到足以各自替换，却又都串在同一个流动的值——Session——上。
支柱三：Session Graph是动态图
PyTorch的图是跑起来才长出来的，OpenRath的Session Graph也是。
PyTorch还有第三个让人上瘾的设计：动态图（define-by-run）。它不要求你先把整张计算图画死再喂数据，而是代码跑到哪、图就长到哪。控制流就是普通的Python if / for，灵活到可以在运行时根据中间结果改变走向。
OpenRath的Session Graph，是同一个性格的东西。
先看Session长什么样。它远不止一串聊天记录——而是一张结构化的chunk表，大致是这个形状：
它能fork出分支，能detach切断父链，能merge合并，还能序列化成JSONL直接交给下一个Workflow。而这张由fork / merge织出来的图，是Agent们跑起来、一步步演化出来的，并非事先画死的剧本——这正是「动态图」的含义。
Session沿着fork / merge演化，每一步都留下血缘；工具运行环境则由Sandbox backend绑定。这张图不是预先编排好的，而是随Agent运行实时生长。
为什么这件事对Agent Cluster是决定性的？因为集群规模一大，你迟早要回答：这个结论到底是哪个Agent、走哪条分支、调哪次工具、在哪个workspace产出的？散落的日志答不了，一张带血缘的动态图能答。Session Graph于是从实现细节升格成了集群的可观测层与控制层：路由、复现、回滚、审计，全在同一张图上做。
它现在到底能不能用？
能装、能跑、能照着学——不是一份PPT。
最能说明问题的是它的example/目录——一条编号递进的学习阶梯，每个脚本只讲一个概念，前一个的产出正好是后一个的输入：
已在GitHub开源，BSD-3-Clause协议，可直接pip install openrath。
01_hello_agent：最小程序，构造Agent、在Session上调用、流式输出
02_session_lineage：用fork分叉、detach切断血缘、查看session graph、导出JSONL
03_sandbox_backend：把同一个Session放到local或opensandbox，看工具在哪执行
04_tools_builtin / 05_custom_tool / 06_mcp_tool：内置工具、自定义工具、借用MCP工具
07_streaming / 08_compress / 09_memory / 10_provider_variation：流式、上下文压缩、记忆、换模型厂商
11_dynamic_selector：用Selector做if分支和while循环
从「先让一个Agent跑起来」到「让一群Agent动态协作」，11步走完，OpenRath的核心也就理解透了。
安装也分层：基础 pip install openrath，要容器沙箱加 [opensandbox]，要外部记忆加 [openviking]，模型则走 OpenAI 兼容的环境变量或 ~/.openrath/config.json。
更值得说的是这套 example 的设计取向：官方强调，例子的目标是产出一份「证据档案」，而不是一张截图。一个软件任务跑完，理想的产物不该只停在一句「成功了」，而该是一整份可回溯的卷宗——
issue 原文 → Session Graph → 调了哪些工具 → 副作用落在哪个 sandbox → 被否决的那条分支 → 最终采纳的补丁 → 测试结果 → 这次往 Memory 里写了什么。
这份卷宗，正是「一个 demo」和「一个能拿来做技术报告的运行时」之间的区别。按团队自己的说法，他们在内部已经用 OpenRath 组织起接近 Transformer 结构的 Agent Workflow——不过这更偏系统能力验证，还不是公开 benchmark，这点他们说得很坦白。
从持久Session，到Agent Cluster
v1.1让单个Agent的工作可追溯，v1.2让一群Agent的协作可追溯。
把视野拉远一点：OpenRath的版本演进本身就是一条干净的线。v1.1解决「持久」——如果一个Agent的工作是跨时间展开的，凭什么唯一被保存的只有最终答案？于是有了持久Session，把干活的证据完整留下。v1.2再抬高一层：让Session从「单个Agent事后可查的记录」，升级成「能在多个Agent和工作流之间被路由的对象」。一行代码就概括了这个转变：
- session = workflow.forward(session)
它意味着，工作的单位从一个prompt、一个答案或一个Agent角色，挪到了一份持久、可路由的Session状态上。
从Prompt 工程走向系统工程
OpenRath的意义，不只是「又一个Agent框架」。
它真正想解决的是：当Agent Cluster成为主流形态，开发者能不能像写深度学习那样，获得一套可组合、可追踪的工程体验。这正是它借PyTorch之名的底气——同一套直觉迁移了过来：层是变换（Agent），device可插拔（Sandbox / Memory backend），图是动态的（Session Graph）。
在PyTorch里，你定义Module，让Tensor在网络中流动；在OpenRath里，你定义Agent和Workflow，让Session在系统中流动。剩下的——血缘记录、工具调度、沙箱绑定、长期记忆、动态路由——交给框架。
如果说过去的Agent框架面向的是「一个智能助手」，那么OpenRath面向的是「一个智能体系统」。
而这件事的起点，朴素得有点反直觉——不是再多造一个Agent，而是先把Session当回事。
参考资料：
https://www.openrath.com/
本文来自微信公众号“新智元”，作者：新智元，36氪经授权发布。
