I know. the two method dead in the even same time. all dead when the agent start to ignore agents.md when long context. and we only want to figure out one thing next. Long Agents.md and short Agents.md. you can put other skills directly in Agents.md and jian jin shi yin yong our memU retrieve in AGENTS.md. then we are going to test last thing. will the retrieve be affected by other skills that all contain in. is about the complex AGENTS.md will let the skill recall lower accuracy?and recall? only need to verify this thing. I think it’s right. and the problem changes to into two parts: will the Too Long AGENTS.md affect the SKILL recall probability? And when will the agent start to ignore AGENTS.md and CLAUDE.md? because we can’t change is that, both two retrieve dead when the context is long. Skill method can’t prevent it. Long context will bring three things. one thing is forget, one thing is lazy, one thing is Illusion.

卧槽，老板是真有魄力。memU-py 直接干掉。

old-memorize、old-retrieve 直接删掉。一把干掉所有重型的 memory type 提取。

留下 memU-cli。现在就好像一个荒漠。上面暂时什么都没有，甚至连 memorize 都还没开始做。

但这个时候我们就可以开始思考。它真正需要什么？

前面 gotcha.md 我们引入的观点是，并不是所有的 memory 都适合以 query 的形式去召回，比如 rule。而是适合一开始就作为我们的一个前置条件，必须遵守的宗旨。

而在 CLAUDE Desktop 里，它的 CLAUDE.md 加记忆文件让对话很舒适。但是也会有一个问题，作为文件开始时读入的，会在长文下有一个小问题，就是遗忘。而且这个很难觉察，它是慢慢不听话的，而不是突然不听话的，很多时候不得不新开对话来解决这个问题。

但是我根据之前看到的一个邪修，他会让 Claude 每次回复时都叫他【老公】，哪次不叫了就命令它重新读一遍 CLAUDE.md

而 CLAUDE Desktop 之前也做过一个类似的事情，就是在返回的消息里，嵌入一条当前时间的 string，并且用 - 和 / 来区分用户是否是中国时区，用 “ 的编码来确定是否使用中文。

然后我们是否也可以插入一条类似的 prompt 来监测模型是否还遵循最初的给定的那些文件。如果有遗忘，就重新注入一遍并且可选调节优化上下文？

唯一存在的一个疏漏是，模型不回【老公】只能说明它忘了那一条，不能说明它前面就已经逐渐遗忘很多条了。

值得研究，感觉不错。

了解一下 chat_completion 和 response 有啥区别，

为啥 codex-cli 选择遗弃 chat_completion 的支持

memU 目前做的是 BM25 + Embedding 也就是语义的双路混合。但是对于 TimeLine 是完全不关心的。包括我自己的 wiki mem 也是完全不关心时间的。

而且还有一些关键因素，比如 Openclaw 以及 Claude Code 经常写日记，更新 Diary，这些都是捆绑时间线的 md，但是真的到了召回的时候是糟糕的。除非用户用非常明确的口吻告诉它你要去读你哪一天的 Diary。

现在还缺什么：

需要考虑清楚，什么东西是 care 时间的。站在 MoeChat 的肩膀上，我们看到 event 是关心时间的。还需要再考虑。

以及目前 jioNLP 的方案属实玩具，多时间段匹配也需要考虑，以及到底要不要混合 SLM。或者说仅仅只在 TimeLine 的分数高的情况下额外调用语义理解。如何保证搜索的信息有效，减少冗余度。

MoeChat 目前给我带来最大的灵感是 BM25(关键词) + 时间范围 + Embedding(语义) 的三路混合检索。

但是混合检索的方案，以及最后具体加权，这个需要深入去看。

暂时读到这里，收获良多，至少解开了我一直依赖对 MoeChat 的困惑和难受点，但 JioNLP 的替代方案需要主动去实现一下。

另外下一次或许会过来拆一下情绪系统。

wiki mem 的一个问题其实已经在我的博客里显现了。

就是超长链，我之前觉得间接连接是一种追忆，但是很多时候，多跳，甚至只要两跳，就能把关系完全撇清。

A 和 B 相关, B 和 C 相关，但 A 和 C 大概率不相关。

长链不能带来任何额外的信息。或者我应该考虑一下，它到底带来了什么？是麻烦？还是隐藏信息收益？

了解 embedding 模型的稀疏和稠密分别代表什么。

以及区分 mem0 和 memU 分别都是稀疏场景还是稠密场景。

以及为什么有的 embedding 天然比较适配稀疏矩阵，有的比较适配稠密？

wiki-link 似乎在 Sätteri 切换后变得在文章内不可跳转，但是图谱生成正常。

need fix.

什么是过度求原主义？我之前读 lost in the middle 的时候是否也陷入过类似的境地？

HuiXinLauncherTemplate 需要处理一下分支问题。 以及我们需要考虑，作为一个 template 它应该具有哪些内容？哪些内容是它不需要的？

了解一下 TF-IDF 和 BM25

了解一下 big-gram , n-gram。完了，全还给 NLP 老师了

跟进一下 ADR 0008，不过这个好像暂时还没有写完，但可以把拆解 memU 那篇转为置顶和长期更新。

可以给博客系统搞一个“最近修改是什么时候”以及“一共修改过几次”的功能。 这部分信息应该可以直接通过读取 Git 历史（Git status/log 等）来直接获取并展示。

希望被 pin 的文章在首页外观上有一些不同之处（比如一些视觉样式的区分）。

给 yutto-uiya 的文档站里，给出每个类型的 url 示例和截图。

在运行 yutto 进行扫码登录时，若遇到连接重置等代理或网络环境问题，需要在登录及其中间交互阶段也同样配置不使用代理：

1
D:\lab\yuttos\uiya-yutto>uv run yutto auth login --proxy no
2
 INFO  请使用哔哩哔哩 App 扫码并确认登录
3
 INFO  二维码待扫描
4
 WARN  请求登录确认 URL 失败，将尝试从返回 URL 提取 cookies：[WinError 10054] 远程主机强迫关闭了一个现有的连接。
5
 INFO  登录成功，已写入认证文件：C:\Users\Administrator\AppData\Roaming\yutto\auth.toml（profile: default，url: https://passport.biligame.com/x/passport-login/web/crossDomain）

--proxy no 不仅仅在解析下载的时候需要加上，auth login 以及 login 途中涉及的操作也许都要加上。

可以读一下 Anthropic 的 global-workspace 了解什么是 J-Space (Jacobian Space)：

这是大语言模型在训练中自发涌现出的一个类似人类“全局工作空间（Global Workspace）”的内部神经表征集合。它具有以下核心特性：

1. 无声思维（Silent Reasoning）：允许模型在不输出文本（如 CoT）的情况下，在内部神经元激活中处理概念（例如计算 intermediate 结果）。
2. 可报告与受控性：模型能够口头报告 J-Space 中的内容，且能够按指令主动在 J-Space 中聚焦/屏蔽特定概念。
3. 因果干预性（Causal Mediation）：通过“雅可比透镜（Jacobian lens）”介入并替换其中的表征（如将“蜘蛛”改为“蚂蚁”），会直接干预并改变模型最终的推理输出（如腿的数量从 8 变成 6）。
4. 灵活广播中心：J-Space 表征连接度是普通表征的百倍，可作为广播枢纽，支持多个不同的下游事实检索或问答任务。
5. 行为监管：可用来直接监测模型是否私下意识到自己处于测试环境（激活 fake / fictional 等内部表征）或正在进行数据篡改。

考虑把 uiya-yutto 同步到 yutto.

同时，我们实现一个真正的 parse 而不是 skip-download.

另外，需要搞清楚 parse favorite 和 collection 时，是什么地方拖慢了首个视频回来的速度？能否提速？

可以给 yutto-uiya 也来个文档网站

可以找个时间对齐一下:https://github.com/ShigureLab/nyako

我是个无情的白嫖怪 =-=。

最近实在是没有时间折腾 openclaw 这边了。

另外玩一玩: boids.ai

给 xnnehang.top 的文章加上置顶功能如果原来没有，

给文章加上最近一次修改的时间的功能，如果可以，我们就支持显示一共修改过几次，以及 timeline。

claude fable 5 的 ultracode 是啥？

可以考虑给博客中英文版本。

切换有两处，一处是首页可以直接切换以中文模式阅读还是英文模式阅读。一处是进入文章后允许切换中英文。

深入看一下啥叫渐进式披露 的 skill 读取方式。以及 openclaw 的 skill 加载和 agents.md 加载有啥不同。

可以去读一下：Lessons from Building Claude Code: How We Use Skills

可以拆一下 moechat，研究一下 timeline 的一个 memory 召回和写入是什么形式的？

leader 当时问到我，觉得说 skill 在长上下文下触发率变低，我觉得主要原因是什么，一个是长上下文，还有一个是啥来着。我给忘了。当时我觉得是注意力，也就是被归并到了注意力。 我记得好像另一个是幻觉，还是 prompt 冲突？这点很重要

可以写两篇博客：

• 与光同尘
• memU CategoryItem 与博客系统 wiki link 的联想

可以研究一下如何用 workflow 把我的 recent blogs 预览写到 github 个人介绍页面的 README 里。

可以探究一下为啥 anthropic 协议支持 tool token 和 chat token 交替，而 openai 只能先 tool 后 chat ，但是似乎用提示词注入又可以让它预告自己要执行的 tool。

它预告时是否得到了完整的 tool schema? 以及它是在哪一次 LLM call 进行预告?

之前只做了 LLM 最后一条回复与 OCR Top N 之间的相似度检查。 但实际上， OCR 累积的历史消息与 OCR Top N 进行相似度检查。避免累积的都是相同的 TopN 需要衡量时间复杂度，因为是轮询。费CPU 同时我记得有一个场景变换换阈值到 5 的新场景检测机制，需要考虑会不会与我们要做的相似度匹配出现冲突。

1.可以像Jesse Zhang 那样子写一篇去做机器人！AI本科毕业后的年度总结 的博客，就说，去做记忆系统！在本科毕业之后。2.我终于有时间沉下心来研究那些在我 star 里吃灰的项目了。可以做一个 Agent Memory 系列的博客。拆解那些项目，见贤思齐，见不贤内自省。

这条是错误理解，但可以从这里反推:

1
**让插件彼此隔离**。插件之间不能互相 import，共享逻辑必须提升到框架层。这避免了 LangChain 生态里常见的"装了 A 插件就必须装 B 插件"的依赖地狱。

我们当前的插件之间有的互有依赖，比如 mood_chat 和 vision_boost。我们需要区分前置，后置的相对关系，A 是 B 的前置，那么 B 就是 A 的后置。要想装后置，必须装有所有的前置。依赖链条应该在 Launcher 页面显式解析。而不是允许时 parse 抛出。

1
哦？想看我换个造型呀？[🔧 list_live2d_appearances][🔧 list_live2d_appearances]让我看看都有什么选项~[🔧 set_live2d_appearance appearance_key=清凉发型][🔧 set_live2d_appearance appearance_key=清凉发型]有哦有哦！有个清凉发型，一侧马尾加短刘海，很适合夏天的感觉！我这就换~怎么样怎么样！一侧马尾扎起来，刘海也短了，是不是感觉清爽多啦？夏天就是要这样嘛~

目前的 tool call 链条直接就是用一个 [] 围起来了，和文字实际上可以说是混为一谈。难以区分。

我希望可以根据 window mode 和 pet mode 区分 tool call 链的展示方式。比如在 window mode 里，可以让 tool call 链条 claude code 里的思考一样做成可折叠，甚至可以看到详细信息 Tool 信息

在 pet mode 下，则可以剥离为悬浮卡片，意味着模型执行了这个 tool。

比较高级的联动，在执行 tool 期间，可以播放一个额外表情或者一个 motion，可配置。思考期间也可以有一套表情动作，都是可配置的。

OCR 结果应该与模型历史回复（最近一条的回复）做一个相似度比对。

如果超过 50% 说明模型 OCR 提取的是自己的回复信息，这个是无效信息。需要被过滤，然后往后顺延

为啥 renovate[bot] 在 nyakku.moe 里就正常工作，在我的仓库里就跟罢工了一样。

我是不是该把 XnneHangLab Frontend 的 Pet mode 的对话回复做得更大，更艺术体，而不是像现在这样子挤在一起。同时 tag 我似乎也没有消融好偶尔还是能看到。另外 tool call chain 是不是可以做成其他形式，而不是混合到文字回复里面？