上百个Agent，该怎么管？清华团队新思路：重做Session

新智元报道 【新智元导读】 当Agent数量增多时，管理混乱成为难题。OpenRath提出用Session作为核心，代替Agent为中心的设计，使多个Agent能共享状态，实现更清晰的协作与控制。 Agent越来越多，Session却越来越乱。 这是几乎所有人把多智能体系统真正跑大之后，都会撞上的一堵墙。 一个Agent维护一份上下文，另一个Agent又复制一份历史；一个任务分叉出好几条推理路径，最后没人说得清哪条分支产出了最终答案；模型调用、工具执行、沙箱环境、长期记忆各管各的状态——demo 跑得挺好，可当系统扩到几十上百个 Agent，调试、复现、编排全部开始失控。 最近，一个来自清华大学与中山大学的团队（Rath Team）把他们的解法开源了，叫 OpenRath ：这是一个像PyTorch的多智能体、多会话运行时。 它的主张是： 别再围着Agent转了。真正该被当成 一等公民 的，是Session。 官网：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是变换这份