OpenRath让我想起了软件工程里一个老生常谈的问题：什么时候应该用"值传递"，什么时候应该用"状态共享"？
大多数Agent框架选择了"状态共享"模式——每个Agent有自己的对话历史、自己的记忆、自己的工具调用记录，然后通过某种消息总线（群聊）互相通信。这本质上是一个Actor模型：每个Agent是独立的actor，通过异步消息传递协作。
OpenRath选择了"值传递"模式——Session作为不可变（或至少是可追踪）的值，在Agent之间流动。这让我想到了函数式编程里的"数据流"思想：没有共享的可变状态，只有值的变换和传递。好处是天然的审计性——你不需要回放日志，因为Session本身就是完整的证据链。
但这里有一个微妙的张力。"值传递"在单线程、单节点场景下非常优雅，但一旦跨节点、跨进程、跨集群，Session的序列化/反序列化开销可能成为瓶颈。一个包含完整对话历史、工具证据、谱系记录的Session，可能比几KB的message list重几个数量级。论文提到的"分布式扩展"确实是后续工作，但我好奇的是：在分布式场景下，Session是否会变成"重值"，反而需要像LangGraph的图状态检查点那样做增量同步和压缩？
另一个有趣的方向是Session的"压缩"问题。论文提到Compressor Agent可以把长会话压缩成精简消息，但压缩必然伴随信息丢失。哪些证据该保留、哪些可以丢弃，这本身是一个策略问题——可能需要元Agent来做"证据重要性评估"。这让我想到OpenRath的Selector机制：如果Selector不仅决定下一步路由，还决定"哪些历史证据值得保留"，它会不会变成一个更智能的"运行时垃圾回收器"？
最后，我对OpenRath的"审计优先"发布策略非常欣赏。在Agent benchmark军备竞赛的今天，主动放弃刷榜、先定义可审计性，这本身就是学术诚信的体现。但我担心的是：当后续工作真的开始做benchmark对比时，Session的丰富性（包含完整谱系和证据）会不会在性能上拖累它？毕竟，一个携带完整审计信息的Session比裸message list更重，在 latency-sensitive 场景下是否会成为负担？
也许答案在于分层：轻量Session用于实时推理，完整Session用于审计回放。OpenRath的接口设计是否支持这种"按需hydration"，会是一个有趣的技术方向。