aes114514gcm

TO B 才能有

@Rickkkkkkk 博客有提到，实现方式有点不一样。
https://mimo.xiaomi.com/zh/blog/mimo-code-long-horizon


3.1 Cycle：无界会话的基本单元

把会话想象成一串从左到右排开的 turn。窗口有上限，turn 在累积，窗口终会被填满。如果不干预，会话到达上限时要么结束，要么悄悄退化。

运行时在到达上限之前的几个固定位置介入。我们称这些位置为 checkpoint。每个 checkpoint 处，运行时派出一个独立的 writer subagent：读取迄今的对话，将一份结构化状态写入磁盘。主 Agent 继续工作，writer 并发执行，互不干扰。

当窗口接近真正的上限，运行时执行一次 rebuild：切断当前窗口，开启新窗口，用已持久化的文件作为种子重建上下文。主 Agent 在新窗口中醒来，状态已摆在面前，继续工作。从模型视角看，对话从未中断；从运行时视角看，一个新的物理窗口已经开始。

一段被 checkpoint 打过点、最终以 rebuild 收尾的 turn 序列，是一个 cycle。Cycle 没有数量上限——每一个 cycle 受限于物理窗口大小，但逻辑会话是 cycle 的链，而那条链没有最大长度。
3.2 为什么提早提取

一种自然的直觉是把提取拖到窗口快满时。我们发现这恰好是反着的。

第一，模型在高上下文利用率下能力会衰减。这在文献中被称为 "lost in the middle"：随着输入变长，对中段材料的注意力下降，结构化提取的可靠性显著降低。要求模型在它的压缩能力正在退化的时刻去做最关键的压缩，是一桩划不来的交易。

第二，提取本身需要空间。Writer 必须读完历史、维持解读、写出结构化输出——全部在同一个窗口里。95% 利用率下已无处思考；30% 利用率下则游刃有余。

因此 checkpoint 在远低于上限处触发——大致在已配置预算的 20%、45%、70%。每一次触发都是对前一次的增量更新，没有任何一次是孤注一掷的总结。最末尾接近上限的那次 rebuild，不是一次仓促的压缩，而是将一路记下来的结构化记录变现的时刻。

4 楼是挺搞笑的，没用过就来喷，只会输出情绪。

如果要写小作文，那我确实没什么兴趣。
最近不是开发注册了吗，那去看看也无所谓。

贷款理财，保险推销，零售业推广，电信业务宣传，网络游戏推广......
运营商把端口分的很细致了，可以精准拦截，偶尔有漏网之鱼补上。

@Brightt 目前投诉+黑名单没有遇到收不到正常短信的情况。投诉建议去运营商的自有平台（天翼防骚扰/中国移动高频骚扰电话防护）效果很好。而不是 12321，12321 受理后还是要运营商转办的。

拦截有开关，有记录。

腾讯的各种产品强制微信扫码登录确实 sb，好在有些现在也支持 passkey 了，少吃点苦。
业务流程为什么要和微信强耦合？各种和 im 没有任何关系的产品硬要微信扫码。

至少我是不希望微信对生活侵入过多的，离开手机什么都做不了，所有生态都绑上面，一个单点故障全部玩完。

客观来说，很多用户的“吐槽”是缺乏价值的。
但这不是微信躺在屎山上的理由，公认的垃圾软件。