上下文工程

上下文工程是把有限的上下文窗口当作稀缺资源来系统管理,三大支柱:(1) 系统提示——固定角色、行为规则与格式约束,独立于每轮对话,并随版本迭代(如"不确定时直说"、输出 JSON 结构);(2) 记忆分层——按稳定性与时效性分层:系统提示/规则 > 用户当前意图 > 对话历史 > 检索证据与工具结果,历史太长时压缩(摘要式 context compaction)或按相关度截断;(3) token 预算——显式分配窗口:窗口上限 $W$ 内划分指令、历史、检索、输出预留 $W_{\text{out}}$,确保 $\sum_i t_i + W_{\text{out}} \le W$,成本近似 $\text{cost} = c_{\text{in}} \cdot t_{\text{in}} + c_{\text{out}} \cdot t_{\text{out}}$,超预算即截断或摘要。

长对话助手、RAG 问答、Agent 系统的 prompt 体系设计;多轮记忆裁剪与上下文压缩;成本优化(按 token 计费);面试高频"给一个 200K 窗口的 Agent 设计上下文管理策略"。

无管理的堆砌会让关键指令被淹没(呼应 Lost-in-the-Middle)、历史膨胀吃掉预算、成本随上下文线性上升;上下文工程把"提示词怎么写"升级为"窗口怎么分",在准确率、成本、延迟之间做显式权衡。

系统提示设计有哪些原则?如何与用户输入、检索内容分层避免互相覆盖?

记忆分层的常见层级与各层寿命是什么?上下文压缩 (compaction) 何时触发、怎么触发?

给一个 200K 窗口设计 token 预算:指令/历史/检索/输出各分多少?为什么必须预留输出?

上下文成本模型:输入/输出 token 计费下,长历史重发 vs 摘要缓存(如 prompt caching)怎么选?

上下文工程与 Lost-in-the-Middle 的关系:关键信息放窗口哪个位置最能保证被利用?