Yuu💖

Know you will wake, on winds rise again 知道你终会醒来，从那之后天空即为极限 For this journey's end but one step forward to tomorrow… 而这旅途的终焉，即为迈向明天的开始

ありがとう、KALEIDXSCOPE！ #maimai_art #KALEIDX_SCOPE

@BH3GEI_CN 有道理，不然通话时长要不足了（

@QuantumTransf 就当给猫充话费了（bushi

真的没有人想过把 token 翻译成话费吗 你想想，llm 说的每个 token 都要钱，那可不就是话费吗 我知道你看到这里肯定想骂我了 但是骂，骂也要 token

@BH3GEI_CN 确实，因为你昨天 v 了我 50

@QuantumTransf 为什么我感觉我被prompt注入了

@StarNekOvO 对，token 本义就是代币的意思（ 但是话费更中文特色一点（不

@QuantumTransf 窝感觉叫代币xxx 街机厅里的投币也是叫 token

@ukitheocog @garrulous_abyss 可以找循环节吧，既然模数这么小的话

@garrulous_abyss 5^141 (mod 7) ＝ 5^6^23 x 5^3 (mod 7) ＝ 1 x 125 (mod 7) ＝ 6 (mod 7)，也就是 1+6=7 星期天...但即便不用费马小定理也能总结 mod 7 的循环规律.

一眼就是费马小定理。如果不知道的话，只能多试试，找规律了（？

@goocarlos 好有意思的广告，喜欢 dify

@hawtim_z @0xNeoHeng @TaNGSoFT 不不不，这个东西并没有直接提升模型的上下文窗口大小

@QuantumTransf @0xNeoHeng @TaNGSoFT 没，agent 每次对话只是把上次的内容一起带过去，只是命中缓存费用会低，但也不是不要钱。比如我实现一个 workflow 就来做生码，调用一次代码输出完成就结束了，这种没必要塞很多东西吧？我是这么理解

消化了一下MSA，Memory Sparse Attention：本质上是利用attention机制对本地文本的学习，包括与LLM交互的trajectory文本。 MSA 填补了"单次会话内的超长上下文"这个格子。这个格子之前要么靠 RAG 外挂（不是真正的 in-context），要么靠暴力扩窗口（计算不可行），现在 MSA 提供了一个端到端的原生解法。 从 NTT（Next Turn Prediction）的框架看：MSA 让单个 turn 内的推理能够访问更完整的历史，这提升了每个 turn 的质量上限。但 turn 与 turn 之间的连续性问题——这个 M-step vs. E-step 的边界问题——MSA 没有触及，也不应该触及。这是两个不同层级的问题。 最终判断： MSA 是序列轴上的真实突破，不是炒作。但它解决的是会话内的超长记忆，不是跨会话的持久记忆。"让大模型原生拥有超长记忆"这个描述是准确的——但"超长"的边界仍然是单次推理上下文，不是真正意义上的情节记忆（episodic memory）。 真正的持久记忆问题，在 TASTE.md 和 GOTCHAS.md 的工程层面依然需要解决——因为那个问题的本质是M-step 结果的跨会话持久化，而 MSA 优化的是 E-step 内部的信息访问效率。两者都需要，在不同的层级上工作，没有一个能取代另一个。

@hawtim_z @0xNeoHeng @TaNGSoFT 其实这个 cache 是一个类似 disk 的东西，大模型厂商如果真跟进的话应该会提供获取这个 cache 的 api 而一般 agent 实现都是多次会话，不可能单次会话的

@QuantumTransf @0xNeoHeng @TaNGSoFT 我就没懂这个地方，什么需求要直接塞完整所有可能相关的信息的。如果只是单次会话不是费用爆炸？还是那个巨大上下文直接命中 cache？

@0xNeoHeng @TaNGSoFT 你好，agent 不可能一直挂着一个 react loop 然后一直等外面 append 消息的，这不现实，真上生产成本能把你吓死

@TaNGSoFT 你要不再想想你说了啥？上下文窗口大到一定程度还用得着什么多次会话吗？会话一直维持在一个上下文窗口里你所谓的长期记忆不就实现了吗？

@LotusDecoder 草才知道 bun 是 anthropic 的

openai 拿走了 uv ， anthropic 抱走了 bun ， 我们都有美好的未来

@kehao95 有可能，等我们发布就知道了（

@QuantumTransf 想起来是搜 unix 才关注的你，期待但好奇我们是不是走上了同一条路

我的架构永远领先于我的代码实现 我感觉两者之间已经差了好几个版本了 写不完，根本写不完（

#maimai_art 完成していますが

@Miyu__Z @0x88FFA357 草

@QuantumTransf @0x88FFA357 超过了99.4%的玩家，说明还有人画出了101%（

mirrors.zju.edu.cn/delivery/math-… 嘿嘿

@0x88FFA357 @Miyu__Z 怎么不给她个 SSS，都 100.0 怎么只有 S+

@Miyu__Z @QuantumTransf ？

@Miyu__Z @0x88FFA357 怎么还有这种画法？？？

@QuantumTransf @0x88FFA357 我刷到了也试了一下 吓我一跳（

@repsiace 嗯，我们想了一下最终得出的架构是类似于组件化内核的做法，我觉得它非常的 fantastic，但具体该在 plugin 和 module 上开放到什么程度，也许只有实践了才能得出答案 我们最终的构想也许是一个基于我们这套 protocol 的 agent network，但目前离那还太过遥远

我们在看到 bub 能工作还不错的时候就在想，哪些能力重要，哪些能力不需要， frostming 在上面边思考边实践，他很快写了《创造一只龙虾，需要些什么?》 而我的幻觉在那段时间无限放大，如果未来存在 Agent 与人共生的时刻，那么什么样的 Agent 会是 bub 。遵循 bub 的理念的，那可能就是了。 所以最后我们觉得 bub 可能需要变成一个不同的样子，和 piglei 的《AI 编程是一种“框架”》共鸣之下，框架化可能是一个不错的方向。

bub 从一个群聊的助手变成一个基本框架就是因为我们很难让其为所有可能的方向优化 我更推荐从一个基础的状态开始，让 bub 在业务中生活，构建符合真实场景的插件和技能

@Hydrogen0E7 而写完代码把架构和代码一起改的程度远高于单独改架构（不

@QuantumTransf 应该就是如此，改架构的麻烦程度远高于改代码

@TKongtou agent os（这么说会不会被打 但我们确实在认真用 os primitive 做这方面的东西 而不是像上个时代的 aios 一样套个壳

@QuantumTransf 这个是什么相关的ovo

@rien7z 感觉自己还什么都没有做🥺

@QuantumTransf 好年轻

2005 fo 纪念（这是我的出生年w） （我才不会说是 2000 fo 没截上（（（