标准回答
为什么要抽象成引擎
到 2026 年，业内的共识是 Agent 的效果七分靠上下文工程：模型再强，喂进窗口的信息选错了、组织乱了，输出照样跑偏。问题在于"该放什么进上下文"没有标准答案——客服、代码、深度研究各有最优策略。于是把这套决策从 Agent 主循环里抽离成独立的 Context Engine：主循环只问引擎"这一步给我组装好上下文"，引擎内部决定取舍。这样策略可替换、可单独调优、可 A/B 对比，业务代码保持稳定。
能支持哪些策略
- 滑动窗口 / 截断：只保留最近 N 轮，简单但会丢早期信息；
- 摘要压缩：把旧历史滚动总结成短摘要，在窗口和信息量间折中；
- 相关性检索注入（RAG 式记忆）：把历史/知识存外部库，按当前 query 检索 top-k 注入，实现近似无限记忆；
- 重要性打分与淘汰：给每条记忆打分（时效、频次、显著性），预算紧张时淘汰低分项；
- 结构化记忆与工具结果裁剪：长工具返回只留关键字段或摘要，避免噪声占满窗口；
- token 预算分配：给系统提示、历史、检索、工具结果各划定额度，超额按优先级裁剪；
- 分层组织：把上下文分为系统层 / 任务层 / 会话层 / 检索层，各层独立管理、按需拼装。
带来的好处
核心是可调优 + 可对比 + 与业务解耦。引擎背后接统一接口，换"截断"换"摘要+检索"只是配置或实现替换，Agent 逻辑零改动；还能对同一任务跑多套策略离线评测，用数据选最优，而不是拍脑袋。
常见误区
⚠️ 常见踩坑
别迷信"长上下文窗口就能把所有历史全塞进去"——窗口越长成本和延迟越高，且模型存在"中间遗忘"（lost in the middle），关键信息被淹没反而降质。上下文工程的本质是主动取舍：选最相关、最少够用的信息并放在显著位置，而不是堆满。也别把检索、摘要、淘汰逻辑散落在各处，那样无法统一调优和对比。
追问
追问 1：摘要压缩和检索注入这两种策略如何选择，能否组合？
摘要压缩适合需要保留对话连续脉络的场景（如多轮咨询），代价是压缩会损失细节、且生成摘要本身有成本和延迟；检索注入适合知识量大、按需取用的场景（如文档问答），但依赖检索质量，召回差会漏关键信息。两者常组合：近期历史用摘要维持连贯，远期与外部知识用检索按相关性补回，再由 token 预算统一裁剪，兼顾连续性与覆盖面。
追问 2：token 预算紧张时，多个来源（系统提示、历史、检索、工具结果）如何分配与裁剪？
先给不可压缩项（系统提示、当前用户输入、关键约束）保底额度，剩余预算按优先级和相关性动态分配给历史、检索结果、工具输出。裁剪顺序通常是：先压缩或丢弃低分历史与冗长工具返回，再削减检索 top-k 数量，系统提示和当前任务最后才动。实现上由 Context Engine 统一估算 token 并按规则裁剪，避免各来源各自为政导致超限或失衡。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习