ARTICLE · 1077368
散落在 7 个 AI 工具里的会话,怎么找回来、怎么管起来
散落在 7 个 AI 工具里的会话,怎么找回来、怎么管起来上周二晚上十点，我打开 Codex，想让它接着把白天 Claude Code 没干完的那件事做完。 它上来问我：这个项目现在打算用哪个方案？ 我愣了一下。 那个方案是白天我跟 Claude Code 磨了四十分钟磨出来的——三种做法摆在一起对比，否掉两种，定了第三种，顺手还记了三条「以后别再这么干」的教训。这些东西全在 Claude Code 那个 session 里，Codex 一个字都不知道。 我只好从头讲。讲到一半我自己都烦了，因为这不是第一次。 说起来，我电脑里现在装着七个能「吃」上下文的 AI 工具。Claude Code、Codex、Cursor、Gemini CLI，加上我自己跑的那套 Agent，还有几个平时用得少的。每一个都有自己的记忆系统，每一个都只认自己那份。 我的项目上下文，被切成了七份。 01 混乱的根不是模型不够聪明，是上下文没有归属 一开始我以为这是工具的问题。是不是哪个工具的记忆做得不好？ 后来发现不是。每个工具的上下文都做得挺好的。问题在于——它们做的是「自己这个会话的上下文」，而不是「你这个项目的上下文」。这两件事差别很大。 会话是什么？是一次对话。你关掉窗口它还在，但你换个工具它就没了。会话是易失的，而且锁在工具里。 项目是什么？是你手上真正在推进的那件事。它会跨越几十次会话、十几个工具、好几个星期。 而我们所有的决策、踩过的坑、定下来的规矩，都散落在会话里。 于是就有了三种乱。 第一种在会话层。今天在 Claude Code 里聊明白的事，明天换到 Codex 就得重讲一遍，上下文跟着窗口一起关掉了。 第二种在项目层。三个月前为什么否掉那个方案？当时记在哪了？翻聊天记录，翻半天，翻到一句「算了先这样」，然后你完全想不起来「这样」是哪样。 第三种在账单层，这个最隐蔽。工具用积分制，积分把单价藏在规则里，你连自己是涨价了还是用多了都感知不到。 三层乱叠在一起，就变成了一个挺荒诞的状态——我在 AI 上花的时间越来越多，但真正沉淀下来的东西，几乎没变多。 02 我扒了一圈，这个赛道已经挤得不像样了 为了搞清楚别人怎么解这个问题，我把 GitHub 上相关的项目扫了一遍。每个 star 数都是昨天用 GitHub API 实时读的，不是二手转述，免得被过期数据带偏。 先看「把记忆从工具里解耦出来」这一派。 规模最大的是 OpenClaw，390,425 star。它本身就是个能跑的 Agent 框架，记忆是框架内建的能力。 第二是 Hermes Agent，248,730 star。这个数比我预想的高很多，跨会话持久记忆加上多消息网关，体量已经是平台级别了。 再往下是 claude-mem，94,654 star。它把每个 Agent 在会话里做过的事全部捕获、压缩，再跨会话复用，明确支持 Claude Code / Codex / OpenClaw / Hermes 这些不同 Agent 共用同一份上下文——这是我这次核对时最大的意外发现，我原本完全漏了它。 然后是 Mem0，65,955 star，向量抽事实加图记忆，AWS 的 Agent SDK 里集成的就是它的记忆层。排第五的 MemPalace 有 59,262 star，它靠结构化索引硬扛，召回过程不调用大模型。 后面还有 MemTensor 的 memmy-agent（1,979，本地共享记忆中枢）、Graphiti（31,140）、agentmemory（28,809）、Letta（24,870）、ai-memory（8,348）……从 OpenClaw 往下数，我数出十五个以上。 再看「让账单透明起来」这一派，就是模型网关。LiteLLM，59,570 star，企业级的开源网关标杆；New API，48,860 star，自部署网关加面板；One API，37,019 star，很多商业中转站底层跑的就是它；还有 BricksLLM，1,229 star，只记计量元数据、不存对话内容。这一派也有七八个。 两派加起来二十多个项目，看起来挺热闹。但真正把我卡住的是这个数字。 在这二十多个项目里，把「记忆能跨 Agent 迁移」和「账单完全透明」打包在一起、做成一个本地优先的项目代理的——我只找到一个。 Orbital，305 star。 三百零五。跟前面那些二十万、三十九万的放在一起，几乎是个小数点级别的存在。说实话这个反差有点扎心——它说明行业现在还在比谁的模型强、谁的上下文窗口大，真正在意「上下文归谁」的人，还是少数。 03 Orbital 做对的一件事：把上下文当文件，不是当状态 Orbital 的理念一句话就能说完——上下文是你的，Agent 是可以换的。仓库地址 github.com/zqiren/Orbital，README 里那句话写得很直白：Context is yours. Agents are replaceable. 
它的实现很克制：项目上下文全部存成本地 .md 文件。项目的状态、做过的决策、踩过的教训、排队中的任务，每个都是一份人能打开、能检索、能被 git 管起来的纯文本。 我第一眼看到的时候有点意外。因为在「记忆」这件事上，大家默认的答案都是向量数据库，Orbital 反着来，用最笨的办法。但恰恰是笨办法最让人信。 向量库的问题是它是个黑盒。你没法 diff，没法 code review，出问题的时候也没法打开看一眼「它到底记住了什么」。.md 文件可以。你能打开它，能改它，觉得它记错了就删掉那一行。 而真正的分水岭不在存储格式，在三个具体问题上。这三个问题是它 README 里的自问： ① 上一个 Agent 干到一半的任务，下一个接得上吗？它靠 Claude Code 的 SDK、Codex 的 app-server、Cursor 的 PTY/ACP 通道，把不同 Agent 接进同一个项目。 ② 排在那里的任务，会不会有一天悄悄消失了？在它的设计里，任务最终必须落到两个状态之一——完成了，或者被明确阻塞了。它不允许任务凭空蒸发。 ③ 预算、审批、审计，跟着项目走还是跟着工具走？它的答案是跟着项目走。 
这三个问题，每一个都戳在我身上。尤其是第二个。 我想了想自己过去几个月那些「做到一半就没下文」的任务——它们大多不是在某个地方被明确否决的，而是根本没被记录，然后被下一个新想法盖掉了。 04 我自己的三层治理，五分钟就能开始 研究完我没有直接去用。305 star 的早期项目，我不建议一上来就把身家性命押上去。但它那套数据模型可以直接抄。 
第一层，给每个项目一个文件夹。里面就四份文件——现在的状态、做过的决策、踩过的坑、还没做的任务。 规则只有一条：这份东西不属于任何工具。它就是一个文件夹，谁都能读，谁都能改。Claude Code 能读，Codex 能读，我明天换一个没听说过的工具，它照样能读。 第二层，规定什么时候写。这一层我以前最容易漏——写文档最大的障碍不是不会写，是不知道什么时候该写，于是一直不写。 我的办法是：每个任务结束前，留三十秒，写三句话。就三句，做了什么、为什么这么做、下次注意什么。 一开始我觉得这三十秒是浪费。坚持两周之后我发现，省下来的时间远不止三十秒。以前每换一次工具，我大概要重讲二十分钟的上下文；现在打开那几个文件，两分钟看完。 第三层，账单透明。我现在用量都走透明的网关，用了多少、单价多少、剩多少，全部能看到原始数字。 为什么要专门提这一层？因为上下文混乱和账单混乱其实是同一个病的两个症状。你都不知道你的资产在哪，那它怎么可能真是你的。 05 但也别急着高兴，有三盆冷水要泼 第一盆，体量。305 star 和 390,425 star 之间的差距是真实存在的。记忆这件事有网络效应，用的人越多、沉淀越多、越好用，Orbital 的窗口期不会太长。 第二盆，它绑的 TokenDance 是商业 SaaS，不是开源。这里指的是观猹做的「TokenDance 词元跳动」网关（官网 watcha.cn），GitHub 上那几个同名仓库是无关的第三方小项目，别搜错了对象。「上下文是你的」这半句成立，但「账单也是你的」这半句，建立在背后那家创业公司不出问题的基础之上——这跟它自己反对的「被大厂绑架」，逻辑上是有一点张力的。 第三盆，近邻在追，而且追得比我预想的近。claude-mem 有 94,654 star，做的就是「每个 Agent 共享同一份上下文」；OpenClaw 的共享会话也在做上下文迁移，只是粒度是会话级而不是项目文件级；agentic-stack 那个可移植文件夹加成本遥测的设计，跟 Orbital 几乎同构。 它们都还缺「账单透明 + 项目级治理」这一环。但要想清楚——这一环不是护城河，是还没人认真做。 我的判断是：方向是对的，但别指望有个现成答案替你搞定。你该抄的是它的思路，不是它的代码。 06 最后 我最近脑子里老转一个念头。 现在所有人都在比模型。谁家又发新版本了，谁的上下文窗口又长了，谁的推理能力又强了。这些当然重要。 但我越来越觉得，模型是会长期趋同的。今天你比别人强 20%，三个月后这个差距就抹平了。真正不会被抹平的，是你手上那份属于你自己的上下文——你做过什么决策、为什么做、踩过什么坑。 模型会换，工具会换，Agent 是可替换的。只有上下文是你的。 所以别再让对话烂在聊天框里了。今天就能开始：打开你手上正在推进的那个项目，新建一个文件，把最近一个决策写进去，就三句话。 三年以后，等大家的模型都一样强的时候，你手里那几十个文件，才是别人拿不走的东西。 最后补一个能立刻动手的东西：我把那四份文件做成了模板，PROJECT_STATE、DECISIONS、LESSONS、QUEUE 各一份，每份带填写示例，拿到就能用。公众号后台回复「上下文」自取。 
参考信息： 仓库：github.com/zqiren/Orbital（GPL-3.0 / Python 73.4% + TypeScript 25.6% / v0.14.2，main 分支） 数据口径：文中全部 star 数取自 GitHub API 实时读取，2026-09-25 对照项目：OpenClaw 390,425 · Hermes Agent 248,730 · claude-mem 94,654 · Mem0 65,955 · MemPalace 59,262 · Graphiti 31,140 · LiteLLM 59,570 · New API 48,860 架构图与治理图为本机自绘 SVG 渲染，非官方图片
仓库首页：GPL-3.0 / v0.14.2 / 950 commits / 305 star（2026-09-25 实拍）
Orbital 四层结构：接入层 / 编排层 / 能力层 / 运行时层（自绘，依据 v0.14.2 main 分支）
三层治理：乱在哪，就在哪治（自绘）
仓库文件结构：能力层就是几个平铺的 .md，没有黑盒索引