• 我的帖子已经打上 开源推广 标签： 是
• 我的开源项目完整开源，无未开源部分： 是
• 我的开源项目已链接认可 LINUX DO 社区： 是
• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

hi～各位佬友！

这算是我加入L站以来第一个帖子，连续潜水了一段时间，发现大家其实都对跨agent/session的上下文漂移问题有很多苦恼！

我潜心研究了一阵子，今天正式准备把我的这份skill------「RecallLoom」开源啦～希望能给大家提供一个比较合理的、系统化的解决方案（skill形式），同时也算是新人报道了吧！

敬请各位大佬批评指正！

先给自己叠个甲吧

背景

正如前文所说，现在大家越来越高频使用codex、claude code等这类agent产品，来辅助开展日常各项工作和学习任务，同时，大家也游走于各大公益站、中转站来降低tokens的平均使用成本，这就导致在开展某些长期的、依赖历史决策过程的连续性项目时，在频繁切换不同agent、对话线程过程中，搞乱了甚至丢失了之前的一些决策细节、演进历史，我们还得花时间手动把项目背景重新和agent拉齐，我把它称作"重启税"。

谁都不想承担这份额外负担，因此，我带着RecallLoom来了！感觉这会是大家的刚需！

开发过程

RecallLoom项目的诞生源起我在某ai产品公司实习时，使用codex推进一份PRD写作过程中遇到的真实痛点。

大家都知道，PRD不是一蹴而就的，在写文档内容之前需要经历市场分析、用户研究、需求和痛点分析、竞品分析等过程，后续才开始进行方案转化、产品功能设计、原型产出等步骤，最后还要经过多轮需求评审，才能打磨好一份真正意义上的产品需求文档。

在这过程中，可能需要开好多session，又要历经很长一段时间，可能今天推进一点这个步骤，明天又完善一些别的部分，需求评审了又得回去看好几天之前写的内容。

如果重新拉回一个超长session，可能自己都不记得当时在讨论啥了，上下文窗口爆了，即使自动compact可能也丢失了一些细节。其实还是蛮痛苦的，那只能自己再开一个session，再把这条线凭印象重新给ai讲一遍。

所以我到处找，有什么好的解决办法，一看大家其实普遍都或多或少有这样的困扰。我看到大家比较省事的做法就是在项目的agent.md等入口文档下功夫，或者更进一步，干脆自己写个memory.md当作项目笔记，把很多过程、想法和细节记录下来，之后ai优先参考，可能会更快地拉齐状态。这确实是个好办法，给我提供了思路！

同时，我也观察到，其实有很多产品级别或者agent架构级别的记忆、上下文优化项目，其方案都做的很成熟了，但是他们的形态都比较重，可能我需要额外安装，行动成本也有点点高。那究竟有什么形态是轻量级的、同时又普遍通用的呢？我想到了skill。

其实，RecallLoom的第一个版本就是一个SKILL.MD文档，记录了一套我从各大平台拼凑出来的一份我觉得比较好的上下文状态解决方案，基本上就是大家熟悉的三层架构------高层、滚动层、日报层（这个架构的原始提出者我已经无法找到啦，感谢思路）。这样我每天只要说个上班，ai就能从项目本地恢复进展，过程中ai会自己做一些进度的记录写到滚动层里，也会形成一份当日日报。等我要收工了，我就说个下班，ai会完整执行一次全量更新动作。我觉得，这还真的能一定程度上解决"重启税"的问题。

后来，我发现单靠SKILL.MD文档来约束ai对于上下文的记录还是太信任它了，往往就会出现你为啥这个也要记录？你记的乱七八糟的、格式去哪了？你咋这个不记下来啊？------就是记录的质量和稳定性太差了。于是，开启了正式迭代之路。

由于在日常使用中发现越来越多问题，我其实也对这个vibecoding很有兴趣，脑子里每天都在冒出很多关于它的新想法和下一步迭代思路，那我就干脆把它作为一份正式的项目推进吧！

因为这份实习太占据我的研发时间，于是我毅然决然辞职了（其实是天天都在干dirtywork受不了了啊，还不如让我做这个事情！）专心迭代。

直到今天，大家看到了我正式发布的0.3.3版本，从0.1.0上线到今天，刚好10天啦～！

当然，由于受限于我自己的真实使用需求场景和技术能力，skill肯定存在很多不足和需要远期慢慢迭代的部分，我已经有了下一个大版本的升级思路了！（剧透）

项目目标

当一个项目需要跨agent、跨session、跨线程持续推进时，之前花了很多时间才形成的背景、决策、阶段判断、细节约束，很容易在切换过程中变碎、变浅，甚至直接丢掉。然后我们就得重新解释、重新拉齐、重新回忆，我把它叫作「重启税」。RecallLoom想做的，就是尽量把这份税降下来。

项目架构和实现原理

1. 把原本散落在不同对话里的项目连续性内容，挪到一个跟着项目走的sidecar文件夹里，让ai按照RecallLoom约定的标准协议和安全边界在旁边单独维护一套continuity文件。默认情况下，这套内容会放在项目根目录的一个隐藏文件夹【.recallloom/】里，不过也支持可见模式。

2. 当前大体是这样一套分层结构：

• context_brief.md
  放相对稳定的高层背景，比如项目在做什么、边界是什么、现在大概处在哪个阶段

• rolling_summary.md
  放当前状态，也就是"现在到底是什么情况"，这部分会随着项目推进持续滚动更新

• daily_logs/
  放日报式、里程碑式的记录，承接当天做了什么、确认了什么、还有什么风险、下一步要做什么

• config.json 和 state.json
  放机器可读的信息，用来记录版本、状态、修订号之类的东西，方便后面的校验和安全写入

• update_protocol.md
  给具体项目留一个"项目级特殊规则"的位置，防止所有项目都只能套同一套死模板

如果说，只用一个memory.md或类似文档来记项目状态，那么随着时间推移，会把高层背景、当前状态、历史过程、当日进展全部糊在一个文件里，时间一长其实非常容易失控。要么越来越啰嗦，要么越来越乱，要么看着什么都记了，其实真正有用的东西反而淹没了。

所以RecallLoom把他们拆开了：

• 稳定背景归稳定背景
• 当前状态归当前状态
• 日常证据归日常证据

这样恢复的时候，AI不需要把所有历史全吞下去，也能先从最关键的几层把项目状态接起来。

1. 如果它只是一个SKILL.md，其实是不够的，只靠prompt去约束记录行为，太容易失控了，于是后面我给它补了一层 helper scripts，来专门控制一些不好的事情发生。

总结下来，其架构就是

• 用skill规定工作流和使用方式
• 用sidecar承载项目连续性
• 用helper去给关键读写动作加护栏

实现原理其实就是

• 先把项目连续性拆成不同层次
• 再给每一层一个相对明确、相对稳定的落点
• 最后用一套尽量窄但尽量可靠的读写规则，把恢复和记录这两件事固定下来

特性

截止0.3.3版本，RecallLoom基本实现了：

• 轻量：不用上一个很重的上下文系统，不用额外搭复杂基础设施，一个skill完事～
• 项目本地化：产生的文件跟着项目走，不锁死在某个agent自己的记忆里
• 分层存储：高层背景、当前状态、日报证据拆开管理，不堆成一锅粥
• 适合长期项目：比较适合那种跨天、跨session、跨agent持续推进的事情
• 尽量减少「重启税」：让重新开一个会话就又要从头讲一遍的事儿少发生一点
• 支持中英文workspace
• 写入有护栏：不是瞎写、瞎覆盖，会做结构和修订检查，尽量减少出现越写越跑偏
• 尽量不污染项目主体：所有产物默认放sidecar，不往你项目原本代码和正文文档里乱拉屎
• 可移除：如果不想用了，删了sidecar基本就相当于卸载，不动任何你的东西

快速开始

1. 先把skill包接进你的agent

npx skills add https://github.com/Frappucc1no/recall-loom --skill recallloom

1. 第一次使用时，显式唤起RecallLoom

比如可以这样：

• @recallloom
• 用RecallLoom接管这个项目
• 或者直接在agent的skill选择器里选择它

1. 如果项目还没初始化，就先初始化

• 输入rl-init
• 或者明确让agent帮你初始化RecallLoom

如果RecallLoom在初始化或cold start时读取了你项目里的原始文档、说明、历史材料，这些内容只是被用来参考，不会被删除，也不会从你的项目里搬走。

1. 然后就按正常项目节奏使用

比如：

• 继续这个项目
• 先帮我恢复项目上下文
• 从上次停下的地方继续
• 记录今天的关键进展

1. 如果不想用了

通常情况下，删掉sidecar基本就等于移除RecallLoom～
如果你额外启用了bridge，那就先移除bridge，再删sidecar，会更干净一点。

我需要佬友们的帮助

RecallLoom迭代到现在这个版本，我觉得它已经适合搬到台面上让大家来尝尝咸淡了，如果能一定程度上解决佬友们的问题我觉得，这是我的荣幸！

但是！版本的迭代光靠我自己一个人反复测，其实始终有局限！因为我自己可能就陷在codex里了（因为确实用习惯了，没有怎么在其他agent里重度实测，但是skill毕竟还是比较通用的，我觉得没有非常结构性的大问题），而看不到很多特殊角度的问题。很多可能是我觉得理所当然的设计，但是大家用起来觉得，“太重了”、“浪费时间”、"浪费我的token"之类的。

所以，我很希望能尽早听到真实反馈！

GitHub链接

GitHub - Frappucc1no/recall-loom: Portable continuity layer for long-running AI...

Portable continuity layer for long-running AI projects across models, agents, and sessions.

如果真的帮到了你，欢迎star，并且帮我推荐给更多需要它的佬友们！十分感谢！

致谢

感谢各大中转站、公益站提供的GPT资源！

3 个帖子 - 2 位参与者

阅读完整话题