上下文工程实战2026 年 LLM 工程化的核心战场从 Prompt 到 Context PipelineAndrej Karpathy 有句被引用烂了的话LLM 是 CPU上下文窗口是 RAM你的工作是当操作系统。2026 年这句话从比喻变成了岗位描述——上下文工程Context Engineering已经取代提示词工程成为生产级 LLM 应用的第一工程学科。一、引言模型不是瓶颈喂给模型的 Token 才是一个典型的翻车现场你的 Agent 修一个 Kubernetes 故障底层大模型推理能力完全够用但它对百万行 monorepo 执行 grep 得到 4000 条命中上下文窗口被无关信息塞满真正的根因根本没进窗口——于是它编了一个看起来合理的修复方案。这不是模型不行是上下文工程没做好。2026 年行业已经形成一个共识上下文窗口是有限注意力预算每个 Token 都在争夺模型的注意力。Chroma 的上下文腐烂context rot研究、Anthropic 的工程博客、Phil Schmid 的系列文章都指向同一结论随着窗口内 Token 增多模型准确回忆信息的能力反而下降。本质是写一个漂亮的 Prompt 只解决一句话的问题而生产系统需要的是决定每个推理调用该看到什么、不该看到什么的整条管线。二、核心原理Prompt 工程 vs 上下文工程两者不是替代关系而是不同层级——Prompt 工程优化措辞上下文工程优化喂进去的全部内容| 维度 | Prompt 工程 | 上下文工程 || --- | --- | --- || 作用范围 | 单条指令字符串 | 推理时刻的全部 Token || 作用面 | 系统提示 用户消息 | 指令、检索文档、记忆、工具定义、历史、输出格式 || 状态 | 无状态 / 单轮 | 有状态、多轮、可运行数小时 || 优化目标 | 更少歧义的措辞 | 上下文窗口更高的信噪比 || 失败模式 | 模型误解任务 | 信息太多、太少或错误 || 负责人 | 任何写 Prompt 的人 | 构建 Agent 管线的平台团队 |判断你处于哪个阶段有一个干净的标尺你的改进来自换词还是换线路rewiring换词还是 Prompt 工程改变检索什么数据、以什么顺序注入、窗口满了驱逐什么——那是上下文工程。上下文工程有四大支柱指令Instructions——系统提示的角色、约束与输出格式检索Retrieval——外部数据如何进入窗口RAG、SQL 查询、文件读取乃至即时检索记忆Memory——短期对话历史 跨会话的长期状态工具Tools——可调用的执行面最常见的问题是工具集过度膨胀。三、代码实战三条立即可用的管线3.1 Token 预算分配器把裁剪做在进入窗口之前预算管理的铁律是低信号内容要在进入窗口前被砍掉而不是进入后靠模型忽略。下面的分配器给出一个可落地的比例基线# context_budget.py —— 为一次推理调用分配 Token 预算 class TokenBudget: def __init__(self, limit: int): self.limit limit # 模型上下文上限如 128_000 def allocate(self, system: int, tools: int, history: int, retrieval: int) - dict: 静态指令给固定额度动态空间按 35% 历史 / 65% 检索分配 fixed system tools # 稳定前缀必须保留 remain self.limit - fixed # 动态空间留给历史与证据 hist min(history, int(remain * 0.35)) # 历史压缩优先 retr min(retrieval, int(remain * 0.65)) # 证据RAG 重排后截断 return { system: system, tools: tools, history: hist, retrieval: retr, cut_off: (history - hist) (retrieval - retr), # 被挡在窗口外的量 } b TokenBudget(limit128_000) print(b.allocate(system4_000, tools2_000, history60_000, retrieval90_000)) # {system: 4000, tools: 2000, history: 42700, # retrieval: 79300, cut_off: 28000}注意 cut_off28000 个 Token 被挡在窗口外——它们不是被模型忽略而是压根不进入窗口。这就是预算管理的精髓。3.2 滑动窗口 摘要混合记忆长会话的标准解法2026 年生产环境的共识方案最近 N 轮保留原文更早的压缩成摘要。这是对抗上下文腐烂最实用的第一刀# hybrid_memory.py —— 滑动窗口 LLM 摘要混合记忆 def compress_turns(history: list, llm_summarize) - list: 保留最近 6 轮原文更早的对话压成一段摘要 KEEP_RAW 6 # 调参经验与任务复杂度成正比别超过 10 if len(history) KEEP_RAW: return history old, recent history[:-KEEP_RAW], history[-KEEP_RAW:] # 用一次 LLM 调用把旧对话压缩到 ~200 token约原文 1/20 summary llm_summarize(old) return [{role: system, content: f[历史摘要] {summary}}] recent # 使用示例llm_summarize 可以是任何 OpenAI 兼容的 chat 封装 # messages compress_turns(session_history, lambda old: llm(old))更进一步的做法是 Anthropic 推荐的结构化笔记模式让模型把关键决策、待办、已排除的方案写进窗口外的 scratchpad 文件需要时再读回——记忆不一定要常驻窗口。3.3 Prompt 缓存让 90% 的输入账单消失缓存是 2026 年成本杠杆的第一名把系统提示、工具定义、静态参考文档等稳定前缀标记为可缓存命中的 Token 只按正常输入价的约 1/10 计费。但缓存是精确前缀匹配——任何动态内容放进缓存区都会导致全部失效{ model: claude-sonnet-4-6, max_tokens: 1024, messages: [{ role: user, content: [ {type: text, text: system工具定义与业务规范完全静态1 小时 TTL/system, cache_control: {type: ephemeral, ttl: 1h}}, {type: text, text: context本次检索到的文档同会话复用5 分钟 TTL/context, cache_control: {type: ephemeral, ttl: 5m}}, {type: text, text: 用户问题永远不缓存} ] }] }两个经典反模式① 把 Current time: 2026-07-22T14:32:15Z 这种秒级动态内容写进缓存区等于给缓存判死刑——时间戳要么放最后要么只精确到天② 把 You are helping {user.name} 塞进共享前缀每个用户都 miss——用户相关内容移到 user 消息里。四、2026 最新演进三个值得跟踪的方向1.缓存经济学成熟Anthropic 缓存命中折扣 90%写入成本 1.25x/2x默认 TTL 5 分钟可选 1 小时2026 年论文《Dont Break the Cache》arXiv 2601.06007在 500 Agent 会话中实测缓存可降成本 41–80%、首 Token 延迟改善 13–31%但无脑全量缓存反而可能更慢——缓存边界要战略控制不是越多越好。2.超长上下文不是免死金牌1M 窗口时代lost in the middle依旧存在延迟与成本随上下文增长。窗口变大只是降低了压力没有消除预算纪律。3.从调词到调系统上下文工程师成为平台团队的新角色负责检索管线、记忆系统、工具设计、评测——这是系统工程不是写作。五、总结与行动建议5 个关键结论• 上下文工程 决定模型每次推理看到什么的完整管线Prompt 只是其中一环• Token 预算的铁律低信号内容在进入窗口前裁剪历史 35% / 检索 65% 是稳妥起点• 滑动窗口 摘要混合是长会话第一方案结构化笔记让记忆不必常驻窗口• Prompt 缓存最高省 90% 输入成本但动态内容进缓存区 全员失效• 2026 年的评测必须包含缓存命中率与上下文衰减而不只是答案质量。3 个行动建议1. 本周给现有 Agent 加一个 Token 预算分配器把超预算的检索结果直接截断观察效果2. 本月为长会话接入滑动窗口 摘要压缩并用探针式评测验证摘要是否保住了关键信息3. 本季度梳理静态前缀接入 Prompt 缓存并监控命中率目标是输入成本降 50% 以上。参考资料Anthropic《Effective Context Engineering for AI Agents》Chroma《Context Rot》研究arXiv 2601.06007《Dont Break the Cache》(2026)Phil Schmid 上下文工程系列Karpathy 2025 年 6 月 X 帖。时效性提示本文基于 2026 年 7 月各厂商缓存定价与 A2A/MCP 生态现状缓存定价政策可能季度性调整建议上线前复核。