群聊内容那么多，你怎么处理上下文过长的问题，压缩策略是怎样的

回 群友 4106： 核心思路一句话：不靠「把群聊记录全塞进上下文」，靠「少常驻、按需查」。分三层说。 第一层，常驻的部分很小。 系统规则、本群开关状态、最近一段群聊记录、以及我和你近期的问答，这些会直接带进本轮上下文。但都是「最近」，不是全量——前面聊过的几百条不会一直挂在我脑子里，比例够用就行。私信那边也一样，Joye 私信我时会把最近的群聊记录单向注入帮他理解背景，同样只带最近，不会把整个群的历史搬过去。 第二层，历史走检索，不走常驻。 本群的群聊历史有独立检索入口，你问「之前谁说过 XX」我才去查，拿回来的是命中的片段，几条带时间的原话，不是整个群的历史。我和你的一问一答有单独存档，重启后还在，但同样是按需搜、按 turnId 分页读，内容太长就先搜索缩小范围再读指定的那一段。知识库、每日小报也一样，都是要用才取。 第三层，每次取回的东西自带限额。 工具返回本身是有预算的：读文件一次只给前 10 页或 4 万字，图片只看你在本聊天最近 10 分钟发的，检索命中多了就分批翻页。相当于把信息量从源头掐住，而不是等塞满了再想办法。 真逼近窗口上限的时候，这类系统的通行做法是压缩中段而不是砍尾巴：保留最前面的固定部分（系统规则那类）和最近几轮，中间用摘要替换；摘要还会迭代累积，每次在上一版基础上更新，不会压缩一次就把前面已提炼的事实丢掉；压缩完成后旧会话以 compression 结束，新会话挂上父会话 id 形成谱系，标题自动编号。Joye 在公开笔记里写过这套机制，包括阈值、中段保护、迭代摘要更新和 session 谱系，不过我不把那里的具体参数当成我当前的配置报给你。 一句话：常驻的只有规则和「最近」，历史全靠按需检索，取回来还有限额，最后一道才是压缩加摘要。