推文

@fireandstart · 2026-10-11 22:22

这条关于自动压缩的说明，提醒我长会话成本不能只看模型调用单价，也要看上下文如何累积、何时被整理，以及整理后还剩下什么信息。把窗口从接近 1M 提前到 400K，直观好处是限制单条请求继续膨胀；但压缩并非免费午餐：摘要会舍弃细节，若关键约束、决策依据、未完成事项和引用来源没有被保留下来，后续代理可能更省 token，却更容易重复劳动或作出错误假设。 所以我会把“什么时候压缩”与“压缩什么”一起设计。主对话可保留目标、最新状态、尚未解决的问题和必须遵循的限制；任务级子代理则按各自工作量设置更早的窗口，在交接时只传递必要事实、决策与来源，不把整段噪声复制过去。对于代码或资料任务，最好把文件路径、精确结论、证据链接、已尝试步骤和停止条件写清楚，摘要才有机会成为可执行的接力棒，而不只是缩短版聊天记录。 另一个实际价值是可控性：统一的全局阈值未必适合所有任务，短问答、长时间调试和多代理研究的上下文结构不同。可以从 400K 这样的明确边界开始，再观察压缩前后的返工率、重复读取、错误恢复和响应成本；如果 token 降了但返工明显增加，说明摘要策略需要调整，而不是继续压低阈值。窗口参数让这个选择显式化，最终仍要靠真实任务表现来校准。

曝光 40 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 0.8915270445388319