上下文的线性成本问题Agent 不是无状态的 API 调用——它需要记住对话历史。每一轮对话都会累积到上下文窗口里，直到触发两个问题：Turn 1: 1K tokens ← 便宜 Turn 10: 5K tokens ← 还好 Turn 50: 25K tokens ← 开始贵了 Turn 100: 50K tokens ← 每次调用都是重新喂一遍历史这不是理论问题。一个 30 轮的项目讨论对话，全量历史 ~2,500 tokens；100 轮之后这个数字是 ~8,000 tokens，且线性增长。常见的三种应对策略：策略做法直觉上的代价Naive全量历史传入贵，但准Sliding Window只保留最近 N 条省，但可能丢信息Rolling SummaryLLM 压缩旧消息 + 保留近期均衡？本文用真实 benchmark 验证"直觉上的代价"是否准确。Demo 设计对话构造30 轮项目讨论，覆盖数据库选型、缓存配置、迁移责任、部署平台、CI/CD、认证方案等 30 个技术决策。关键设计：重要决策刻意放在第 1-4 轮（最早期），后续才是"近期内容"。这样可以强制暴露上下文丢失问题。三种策略实现Strategy 1：Naive（基准）defrun_naive(history:list,query:str,keywords:list[str])-StrategyResult:msgs=[SystemMessage(content=SYSTEM_PROMPT)]+history+[HumanMessage(content=query)]tokens=count_messages_tokens(msgs)t0=time.time()text=str(llm.invoke(msgs).content)returnStrategyResult(text,tokens,time.time()-t0,recall_score(text,keywords))Strategy 2：Sliding Window（截断）defrun_sliding_window(history: