上下文工程：长上下文窗口下的代码检索与压缩策略
一、长上下文不是万灵药
模型上下文窗口越来越长，从 8K 到 128K 甚至更多。
有人觉得：把整个仓库塞进去，问题全解决。
现实很快打脸：窗口越长，噪声越多，注意力越散。
模型不是"读得越多越懂"。
无关代码挤占了关键信息的权重。
长上下文反而带来"找不到重点"的新问题。
上下文工程因此成为独立课题。
不是往窗口里塞多少，而是塞什么、怎么压。
让有限的注意力落在最有价值的内容上。
本文探讨长上下文下的检索与压缩策略。
二、上下文构造的机制
上下文工程分两步：检索与压缩。
检索决定"取哪些"，压缩决定"怎么放"。
两者配合，把大仓库凝练成模型够用的小窗口。
检索按任务相关性，召回函数、调用链、配置。
压缩则去掉冗余、折叠稳定代码、保留接口契约。
目标是"信息密度最大化"。
上下文构造的关键在"压缩不丢接口"。
实现细节可折叠，但函数签名、类型、约束必须留。
模型要的是"怎么调"，不是"怎么实现"。
三、生产级压缩实现
下面用代码描述基于重要度的上下文裁剪。
from dataclasses import dataclass from typing import Callable @dataclass class ContextItem: """上下文中的一个候选片段""" text: str score: float keep_signature: bool = True def compress(items: list[ContextItem], budget: int) -> list[str]: """按预算截断，优先保留高分项，签名项强制保留""" kept: list[str] = [] used = 0 # 先保签名类，再按分数补普通项 signatures = [i for i in items if i.keep_signature] for i in signatures: if used + len(i.text) <= budget: kept.append(i.text) used += len(i.text) rest = sorted( (i for i in items if not i.keep_signature), key=lambda x: x.score, reverse=True, ) for i in rest: if used + len(i.text) > budget: # 预算耗尽则停止，保证不超窗 break kept.append(i.text) used += len(i.text) return kept if __name__ == "__main__": items = [ ContextItem("def login(): ...", 0.9), ContextItem("class Repo: ...", 0.8, keep_signature=True), ContextItem("verbose log block", 0.2), ] out = compress(items, budget=200) print(f"上下文保留 {len(out)} 段")真实系统会用"分层上下文"：始终保留接口层，按需展开实现。
并对长文件做摘要替代，避免占满窗口。
四、边界分析与架构权衡
长上下文策略有效，但边界清晰。
检索质量决定上限。压缩救不了"取错东西"。
检索不准，再会压也白搭。
应先把检索做准，再谈压缩。
压缩的信息损失。折叠实现可能漏掉关键细节。
安全相关、边界处理的代码不宜过度压缩。
应对这类块设"禁止压缩"标记。
窗口≠理解。模型对超长内容的后部记忆下降。
关键指令应放在上下文首尾，而非中段。
这是注意力分布的客观规律。
成本随窗口线性增长。塞得越多，token 越贵。
压缩省下的不只是注意力，还有钱。
应以"最小够用"为准则。
上下文工程的"成本可视"容易被忘记。检索与压缩每步都吃 token，长链路累积下来不便宜。建议在拼接上下文时记录各块的 token 占用，超标即告警，避免无意识地把窗口填满。另一个实践是"分层注入"：始终保留接口契约层在窗口内，实现细节按需展开，关键指令固定放在首尾。最后，不同任务类型应配不同预算，简单改 bug 用小上下文，复杂跨模块设计用大上下文，按任务动态调，而非一刀切，既保质量又控成本。
五、总结
长上下文窗口下，上下文工程比堆量更重要。
机制上靠相关性检索取准、靠压缩提密度。
工程上守住"签名必留、安全不压"的底线。
落地路线：先建任务相关检索；再对召回项按重要度压缩；强制保留接口契约；关键指令置首尾。窗口再长，装对东西才有用。
