企业官网建设流程全解析

上下文工程实战：2026 年 LLM 工程化的核心战场，从 Prompt 到 Context Pipeline

Andrej 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(limit=128_000) print(b.allocate(system=4_000, tools=2_000, history=60_000, retrieval=90_000)) # {'system': 4000, 'tools': 2000, 'history': 42700, # 'retrieval': 79300, 'cut_off': 28000}

注意 `cut_off`：28000 个 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 年论文《Don't 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《Don't Break the Cache》(2026)；Phil Schmid 上下文工程系列；Karpathy 2025 年 6 月 X 帖。

时效性提示：本文基于 2026 年 7 月各厂商缓存定价与 A2A/MCP 生态现状，缓存定价政策可能季度性调整，建议上线前复核。