清华大学研究者提出"会话对象"，让AI智能体系统告别"失忆"难题

这项由清华大学研究团队主导完成的研究，以预印本形式发布于2026年6月，论文编号为arXiv:2606.19409，有兴趣深入了解的读者可通过该编号查询完整论文。

当你雇了一个助理来帮你完成一项复杂任务——比如整理文件、查阅资料、修改报告，然后还要请同事帮忙核查——你会理所当然地期待，每个参与其中的人都清楚地知道：谁做了什么、改动了哪里、依据了什么资料、最终的结论是怎么来的。但假如这个助理每换一个合作者，就把之前的工作记录藏进一个旁人看不到的抽屉，那么当最终报告出错时，你根本无从追究——这份记录散落在每个人的私人笔记本里，没有人能拼出完整的图景。

这恰恰是当今AI智能体系统正在面临的困境。清华大学的研究团队在这篇论文中将这个困境称为"隐藏运行时状态问题"，并为此提出了一个名叫OpenRath的框架，试图用一个名为Session（会话对象）的核心设计来彻底解决它。

一、当AI助手多了起来，"记录"就开始失控

要理解这个问题，可以从一个具体的场景出发。假设你让一套AI系统帮你完成一项软件开发任务，这套系统里有负责规划的AI、负责写代码的AI、负责测试的AI，还有负责查阅文档记忆的AI。它们之间相互配合、传递工作，每个AI还可能同时尝试几条不同的解决路径（类似"先试试这个方案，不行再换那个"）。

在这个过程中，每个AI调用了哪些工具、修改了哪些文件、从记忆库里提取了什么信息、最终选择了哪条路径、放弃了哪条路径——这些内容本应是完整记录的一部分，就像工程项目的施工日志。但在许多现有系统里，这些记录被分散地存储在各个子系统的私有日志里，有些根本就没被记录下来。等到任务结束，你只能看到一个最终答案，却完全无法回溯"这个答案是怎么来的"。

研究团队把这个场景总结得很精准：一份AI生成的最终输出可能是正确的，但产生它的运行路径却已经碎片化散落在各处——工具日志、内存存储、沙箱操作记录、提供商追踪系统……没有任何一个地方能把它们完整地拼在一起。对于需要审查、复现或调试这套系统的人来说，这是一场噩梦。

正是为了解决这个问题，研究团队从一个意想不到的地方找到了灵感——PyTorch。

二、从深度学习框架借来的一把钥匙

PyTorch是深度学习领域广为人知的编程框架，但研究团队说，他们从PyTorch借鉴的不是"用来训练神经网络的数学计算"，而是它的一种工程哲学：让一个核心的数据对象在整个系统里流动，所有的操作都作用在这个对象上，结果也都附着在这个对象里。

在PyTorch里，这个核心对象叫做"张量"（Tensor），它携带着数据和计算历史，在网络的各个层之间流动。每一层神经网络（比如nn.Linear）都接收张量、处理张量、返回新的张量。数据放在哪块设备（CPU还是GPU）上运行，用tensor.to(device)这一个操作就能明确指定。训练过程中需要持久保存的状态，被当作"参数"（Parameter）独立管理，而不是藏在某个函数的内部状态里。

OpenRath把同样的哲学搬到了AI智能体系统里。在这个类比框架下，Session扮演的角色相当于张量——它是那个在整个系统里流动的核心对象，承载着一次AI工作任务的全部运行状态。Agent（智能体）的角色类似于神经网络里的一层，它接收一个Session、处理它、返回一个新的Session。Workflow（工作流）则类似于整个神经网络模块，负责把多个Agent的工作组合起来。Sandbox（沙箱）对应的是"设备"的概念，明确说明当前的工具调用和文件操作是在哪个执行环境里进行的。Memory（记忆）对应的是"参数"，是需要跨次任务持久保存的状态，而不应该悄悄地混入对话文本里。此外还有Tool（工具）和Selector（选择器），前者相当于系统可以调用的函数，后者则能在运行时根据当前的会话状态决定下一步跑哪个工作流，把动态的控制流也纳入了可追踪的范畴。

这个类比框架的精妙之处在于，它让每个组件的分工变得非常明确，而且每个组件都遵守同一个契约：接收Session，返回Session。这意味着不管系统变得多复杂，都不需要为多智能体协作专门发明一套新的、私有的状态格式。Session就是那个所有人都在读写的共同账本。

三、Session到底装着什么

既然Session是整个系统的核心，那它具体装着什么内容，就值得仔细了解一下。

Session并不只是一份对话记录——它更像是一份完整的"工作档案"，同时记录着若干维度的信息。

对话内容层面，它存储的是有序排列的"块"（chunks），也就是用户输入、AI回复、工具调用请求、工具返回结果、错误信息等，每一条都有时间顺序和身份标记。工具操作层面，工具的调用过程和结果都作为"证据包"附着在Session里，而不是消失在执行器的日志里。执行环境层面，Session通过session.to(backend)这样的操作明确记录当前的工作是在哪个沙箱环境里进行的，文件修改、命令执行、代码运行都有迹可循。谱系信息层面，如果这个Session是从另一个Session派生出来的（比如测试一条新路径时），父子关系会被记录下来，放弃了哪条路、采纳了哪条路一目了然。使用量统计层面，token（语言模型处理文本的基本单位，类似于"字数"的计量单位）的消耗被持续追踪，为预算控制和事后审计提供依据。记忆边界层面，记忆的调用（recall）和提交（commit）作为显式的运行时事件被记录在Session里，而不是悄悄地注入到提示词的文本中。

这种设计的核心价值在于：因为Session本身就是程序运行时传递的那个值，所以"分叉"、"合并"、"重放"这些操作不需要从外部日志里重建，它们本来就是对这个对象的普通程序操作。就像你在版本控制系统里操作代码分支一样直接和自然。

四、Session的一生：从诞生到归档

研究团队还详细描述了一个Session在典型任务里的完整生命周期，这个过程就像追踪一份工程项目从立项到归档的全过程。

Session首先被创建，记录下用户输入的原始文本、当前的角色设定、初始的对话块状态。接下来，它被"放置"到一个执行后端——也就是明确指定接下来的工具调用和文件操作会在哪个沙箱环境里运行，这相当于确认了"施工现场"在哪里。

然后，Session进入变换阶段。每次模型调用、工具请求、工具结果、错误处理、上下文压缩，都会在Session上留下痕迹，就像施工日志上一条条记录下来的操作。

当任务需要并行探索多条路径时，Session会被"分叉"（fork）——复制出一个子Session，它继承了父Session的相关状态，然后独立开展工作，并在Session里保留与父Session的关联关系。如果某条路径的结果被证明有价值，它可以通过"合并"（merge）操作重新并入主Session，而合并操作同样会在Session里记录下"这个结果来自哪两个源头"。值得注意的是，合并操作还包含了一个对沙箱环境的兼容性检查：两个Session要么共享同一个活跃的沙箱句柄，要么都指向同一个未绑定的后端，这样才能合并——这使得"在哪里执行"的信息成为了运行时图谱的一部分，而不是外部的执行细节。

任务完成后，Session可以被持久化存储，以JSONL（一种每行一条记录的简单文本格式）格式导出谱系信息，包括会话标识符、父标识符、谱系操作类型、块数量、累计使用量等字段。这种格式被研究团队刻意设计得"无聊"——简单到用命令行工具就能直接检查，方便随时附加到发布证据里，或者之后转换成可视化图表。最后，当沙箱资源不再被需要时，Session会触发释放操作，清理执行环境。

五、工具调用的边界：一个分层的证据链

工具调用是AI智能体系统里最容易"留下黑洞"的地方。一个工具被调用了，文件被修改了，命令被执行了——但如果这些操作的细节只存在于执行器的内部状态里，那对于Session来说它们就是透明的，无从追踪。

OpenRath通过一个分层的路径来处理工具调用，使得整个过程对Session可见。语言模型看到的是工具的"门面"——名称、描述、JSON格式的参数描述（schema），这些决定了模型知道有哪些工具可以调用、每个工具期望什么样的输入。当模型决定调用某个工具时，Session所在的循环会接收到这个调用请求，验证参数格式，然后根据工具的类型分发到对应的后端执行。如果工具需要产生副作用（比如修改文件、运行命令、执行代码），它会通过Session当前绑定的沙箱来完成这个操作。无论调用成功、参数格式错误、工具不存在，还是执行过程中抛出异常，结果都会作为"工具结果块"附着到Session的记录流里，而不是消失在控制流里。

这个设计的效果是：工具调用的请求、执行环境、返回结果或错误，形成了一条对Session可见的完整证据链。任何想要审查"这个工具调用到底发生了什么"的人，都可以直接从Session里找到答案。

六、多智能体协作：一个账本，多个角色

OpenRath在多智能体设计上刻意保持了极简主义——因为研究团队认为，很多现有的多智能体框架在从单智能体扩展到多智能体时，都犯了同一个毛病：引入了一个新的共享可变对象，或者一个隐藏的消息总线，或者一个只有控制器才能看到的追踪格式。这些"第二个运行时状态对象"的出现，恰恰制造了新的黑洞。

在OpenRath里，多智能体协作的基本模式是：每个专家智能体都接收Session、处理Session、返回Session，工作流把返回的Session向前传递。无论是工程场景里的规划者、专家和质检者这三个角色，还是研究场景里的文献搜索者、复现者、压缩者和输出者这四个阶段，用的都是完全相同的运行时契约。角色换了，但传递的对象没有换，也不需要换。

这种设计还有一个有趣的连锁效应：子工作流可以把内部的智能体结构隐藏在forward(session)这个统一接口后面，父工作流只需要看到一个返回的Session，而不需要关心内部是一个智能体还是十个智能体的协作结果。这使得工作流可以像积木一样自由组合，而且组合的复杂度不会泄漏到外部。

值得专门说一说的是Selector这个组件。通常情况下，一个工作流系统会在设计时就把"下一步走哪条路"硬编码进去。Selector打破了这个限制：它在运行时读取当前的Session状态，从几个候选工作流中选择一个来执行，当任务完成时返回一个空的工作流作为终止信号。这样，动态的控制流决策本身就成了Session记录的一部分，而不是藏在控制器代码里的隐式逻辑。

七、记忆，一个被刻意克制的承诺

关于记忆功能，研究团队在论文里作出了一个罕见的、主动的克制声明。

OpenRath为记忆设计了正确的边界：记忆的调用（recall）和提交（commit）是显式的运行时事件，它们出现在Session的记录里，而不是悄悄地被注入到提示词文本里。本地记忆提供词法匹配检索，可选接入嵌入向量和外部后端。这个设计意图是正确的——让"记得"和"想起"成为可以被审查的操作，而不是黑盒里的隐式注入。

然而，论文明确表示：这份报告不声明记忆的检索质量。在什么语料库上、用什么嵌入模型、采用什么提交策略，能让记忆系统在具体任务上表现多好——这是一个经验性问题，留待后续评估。与此对应，论文的实现状态表里也诚实地标注：记忆平面目前仍是"预期的运行时平面，尚未被本地模块与示例和测试实质化"，属于"证据门控"状态，要等本地记忆的API、示例和测试准备好之后，才能升级为"已支持"状态。

这种主动划定边界的做法，在AI系统论文里并不常见，却恰恰体现了整篇论文的核心气质：只声明能用证据支撑的内容，把做不到的事情说清楚。

八、"证据优先"的发布协议：把承诺写进账本

整篇论文最独特的部分，可能是它的发布评估协议。研究团队设计了一套"声明账本"机制，把论文里出现的每一个可验证声明都映射到一个具体的证据包（evidence packet）上，然后对每个声明的支撑状态进行分类。

这套机制的运作方式是：声明账本是面向审查者的契约，它列出了当前十个声明的状态——五个被证据包完全支撑、一个部分支撑、一个只支撑了前提条件、一个是文献背书的定位性声明、一个是视觉层面的冒烟测试，还有一个是"证据门控"状态（也就是意图正确但尚无证据的记忆平面）。

每个证据包的格式被刻意设计得极简：包含产生这次运行的命令、清单文件、源码和环境元数据、任何Session JSONL或工具日志、生成的输出制品，以及一段简短的说明——这个包证明了什么，没有证明什么。这种格式给了审查者一条从论文声明到可复现制品的直接路径，也给了维护者一个清晰的发布门槛：一个声明只有在对应的证据包在文档化的环境里能跑通时，才能从"证据门控"升级为"已支持"。

用这套协议来衡量当前的实现状态：Session核心（有序块、分叉/分离/合并操作、使用量统计、JSONL谱系导出）由聚焦测试验证，已支持。本地沙箱的执行和工具分发路径已验证，可选的OpenSandbox后端和LLM提供商层已存在但依赖环境或提供商，不在当前报告范围内。工作流的示例由自定义工具、MCP（一种标准化工具访问协议）和脚本化工作流示例展示，已支持。最终生产级别的智能体质量和跨基准测评，明确留待后续评估。

九、它和那些你可能听说过的AI系统有什么不同

为了更清楚地理解OpenRath的定位，研究团队做了一个三方对比，区分了三种不同的运行时记录及其面向的读者。

图调度系统（如LangGraph）维护的是"检查点"——记录的是执行在控制流里走到了哪个位置，让调度器知道任务从哪里恢复、往哪里回溯。追踪系统（如OpenAI Agents SDK所用的追踪框架）维护的是"追踪跨度"——记录的是运行过程中被观测到的事件，比如模型调用、工具调用、权限控制触发等，这是给事后调试和监控用的，面向的读者是观察者。而OpenRath的Session面向的读者是智能体程序本身——它是程序在运行时实际传递和操作的活值，证据附着在这个值上，而不是从旁路重建。

这三种记录并不互相替代，而是各司其职。图调度器可以调度Session，追踪系统可以观测Session相关的事件，MCP协议可以暴露工具让Session调用，沙箱提供者可以执行Session里的工具操作——OpenRath不替代任何一层，它的角色是"连接对象"：一个可以被调度、被追踪、被分发、被持久化、被分叉、被合并、被压缩、被审查的统一状态对象，而不需要迫使每一层都发明自己的、不兼容的智能体状态表示方式。

十、诚实地说：这篇论文没有声称什么

研究团队在论文的限制章节里，用了一种颇为罕见的坦诚态度，把"这篇报告不声明什么"列得清清楚楚。

在基准测评方面，当前只有确定性的冒烟测试运行器和证据包，没有与其他系统的广泛基准对比。要做出更强的声明，需要固定的工作负载、基线适配器、度量指标、实时提供商运行和经过人工评分的制品。在后端一致性方面，本地后端的证据通过了验证，OpenSandbox在当前环境里是明确跳过的可选项。在记忆方面，状态已如上所述。在多智能体控制方面，Session暴露了分叉、合并、工具和谱系证据，但并不构成策略层——角色权限、工具授权、记忆提交门控、合并策略和人工审查要求，都不在当前范围内。在安全性方面，论文明确表示不声明任何安全属性，工具使用和交互式环境会扩大攻击面，包括间接提示注入这类已知风险（即恶意内容通过工具的返回结果影响AI的行为）。在可复现性方面，证据包支持对确定性声明的检查和无需密钥的重放，但实时输出仍依赖提供商和环境。

归根结底，这篇论文在做的事情是：先把地基打扎实，再告诉你地基在哪里、边界在哪里，然后把更高的楼层留给后续工作去建造。

这是一种构建AI系统基础设施时少见的工程诚实，也是OpenRath这套框架能够真正被审查和信任的前提。

如果说过去十年，深度学习领域因为有了张量这个核心流动值，才使得神经网络的构建、调试、部署变得系统化而可靠，那么这项研究者们希望提出的问题是：AI智能体系统是否也需要一个同样地位的核心流动值？他们给出的候选答案是Session——一个让分叉、合并、重放、审查不再是需要从外部重建的事后工作，而是程序运行时本身就具备的能力的运行时对象。

这个问题本身，或许比任何一个当前已经测量的实验结果都更值得思考。

Q&A

Q1：OpenRath中的Session和普通的AI对话记录有什么区别？

A：普通的对话记录通常只保存用户和AI的文字来回，而OpenRath的Session是一个完整的"工作档案"，同时记录了工具调用的请求和结果、操作在哪个执行环境里进行、任务路径的分叉和合并关系、token使用量统计，以及记忆调用和提交事件。普通对话记录只能告诉你"说了什么"，Session还能告诉你"怎么做到的、在哪里做的、走了哪条路"。

Q2：OpenRath的Session和LangGraph这类图调度系统有什么本质区别？

A：LangGraph的检查点是写给调度器看的，记录的是执行在控制流里走到了哪个位置，用于恢复和时间旅行。OpenRath的Session是写给智能体程序本身的，它是程序运行时实际传递和操作的活值。简单说，前者是"执行进度记录"，后者是"程序自己携带的证据"，两者定位不同，可以并行使用而不互相替代。

Q3：OpenRath的记忆功能和其他AI系统把记忆注入提示词有什么不同？

A：很多系统会悄悄地把记忆内容混入发给AI的提示词文本里，外部根本看不出来记忆被调用了。OpenRath的设计要求记忆的调用（recall）和提交（commit）作为显式的运行时事件出现在Session记录里，这样审查者可以清楚看到"这次任务用到了哪条记忆"，而不是被藏在提示词的黑盒里。不过论文也坦诚，记忆模块目前还处于"有设计意图但尚未完全实现和测试"的状态。