Why Context Engineering Now / 为什么是上下文工程

Why Context Engineering Now / 为什么是上下文工程

凌晨两点,某跨境电商平台的客服 Leader 收到了一封紧急邮件。一个使用了三个月的客服 Agent 在白天的"黑五大促"流量高峰中"集体失忆"——大量用户在第 18~25 轮对话后,Agent 开始混淆订单号、把"退货政策"和"换货政策"内容交叉,甚至直接否认自己在三分钟前说过的报价。日志显示,模型本身没有报错,Token 计数正常,但"看上去像一个金鱼记忆的实习生"。

Post-mortem 复盘发现:不是模型变笨了,不是 API 抽风了,是 Prompt 里塞满了过去几周的工单历史、用户的购物车、过往会话摘要、营销文案模板、工具调用结果……上下文窗口在第 20 轮时被无声地撑爆。开发团队写下了一句后来被钉在工程 Wiki 上的话:"我们以为是模型在回答,其实是 Context 在拖模型下水。"

如果你在过去两年里交付过任何一个真正上线的 LLM 应用,这个故事你大概率听过类似的版本。这一章的核心问题就是:为什么"Context"——上下文——突然从一个工程细节变成了 LLM 系统最核心的瓶颈?为什么更大的模型、更长的上下文窗口并没有自动解决它? 我们会沿着一条清晰的演进路径,把这个看似突发、实则必然的范式跃迁拆给你看。

从 Prompt Engineering 到 Context Engineering 的范式跃迁 / The Paradigm Shift

Prompt Engineering 是过去三年 LLM 圈最被过度神话、也最被低估的概念。它在一开始的确是有效的——当模型能力还停留在 GPT-3.5 时代,一个写得好的 few-shot prompt 真的能让模型从"勉强能用"直接跳到"看上去很聪明"。但 Prompt Engineering 的隐含假设是:"我把指令写好,剩下的交给模型。" 这个假设在 demo 场景里成立,在生产环境里几乎从来都不成立。

生产环境的真实结构是这样的:用户说的每一句话、检索出来的每一段知识、每一次工具调用的结果、每一次状态变化、每一段历史的引用——这些统统都会进入 prompt。到 2024 年末,一个典型的企业 RAG Agent 的 prompt 构成已经变成这样:

• 1 个 5~30 行的系统提示(System Prompt)
• 5~80 个被检索召回的文档片段,各 200~800 token 不等
• 1~3 个工具的 schema 描述(每个工具 150~400 token)
• 之前 10~40 轮的对话历史
• 几张用户当前页面的结构化数据(可能带 JSON 字段)
• 一段"中期总结 memo",由上一轮 LLM 生成

把所有这些塞进一个 Prompt,然后期望模型"聪明地处理"。这不是 Prompt Engineering,这是堆叠工程(stacking engineering)——一个注定脆弱的工程模式。

那么,从 Prompt Engineering 到 Context Engineering 的跃迁到底体现在哪里?我们看一张图。

```mermaid flowchart LR P1[Prompt Era<br/>Hand-written instructions<br/>Hand-written few-shot<br/>Static templates] P2[Chain Era<br/>Multi-step pipelines<br/>Retrieval + LLM<br/>Memory summarization] P3[Context Era<br/>Curated, structured context<br/>Tool + memory + state<br/>Dynamic, observable, debuggable] P1 -->|2022-2023| P2 P2 -->|2024-2025| P3 ```

这三个阶段不是替代关系,是叠加关系。第一阶段没有消失,只是被第二阶段包进去了;第二阶段也没有消失,正在被第三阶段接管。真正的范式跃迁发生在第二阶段到第三阶段之间——也就是从"把 prompt 串成 pipeline"升级为"把 context 作为一等公民来设计、装配、观测、迭代"。

什么是"一等公民"?四个判断标准:

1. 有独立的命名空间和契约:Context 不再是 `prompt = "\n".join([system, history, docs, query])` 这样临时拼出来的字符串,而是一个有 schema、有版本、有 trace ID 的对象。 2. 有可观测性:能告诉你"这一轮回答用了哪 5 段知识" "忽略了哪 3 段,为什么"。 3. 有可调参数:不是只能换 prompt 模板,而是可以调节 retrieval 粒度、压缩策略、记忆窗口、token 预算。 4. 有失败模式清单:知道在这个系统里 context 会怎么烂、烂了之后怎么修。

Prompt Engineering 时代一个好的 prompt 是个文本产品,Context Engineering 时代一个好的 context pipeline 是个软件系统。这是质的差别。

上下文成本:Token 经济学与延迟-精度权衡 / Context Cost & The Latency-Precision Tradeoff

接下来要撕开一个让很多产品经理和工程师不愿意直视的事实:context 是有成本的,而且是非线性增长的。

我们用一个真实场景做计算。假设你做了一个企业知识库问答系统,目标 SLA 是:首字延迟 ≤ 1.5 秒,答案准确率 ≥ 90%,每千次问答的总成本 ≤ 8 美元。你可以选择不同复杂度的上下文方案,看它怎么影响这三个数字。

方案 A:朴素全量塞入。把检索到的 Top-10 文档原样塞入 prompt,不做任何裁剪、压缩、重排。如果每文档平均 600 token,这一项就是 ~6000 input token。加上 system prompt ~500 token、对话历史 ~800 token、用户问题 ~150 token,单次推理的 input token 大约 7500。在 GPT-4o 这种 $2.5/M input 的定价下,光 input 成本就是 $0.019 一次。1000 次就是 $19——已经超预算一倍多。

方案 B:重排序 + 截断。用 bge-reranker 把 30 个候选 chunk 重排,只留 Top-5,每 chunk 切到 400 token。这一项 input 降到 ~2000。加上摘要化的对话历史 (~300 token),单次 input ≈ 3000 token,成本约 $0.0075,千次 $7.5,刚好压进预算。

方案 C:分层上下文(Context Hierarchy)。把 system prompt 设计成"分段寻址"结构,检索层只注入与当前问题强相关的"激活上下文",对话历史用 LLM 压缩成 ≤ 200 token 的状态摘要,工具 schema 按需展开。这一项 input 可以压到 ~1500 token,千次成本 $3.75——而且因为 context 更"干净",精度反而更高。

三个方案的区别不是 prompt 写得好不好,而是context 工程做没做。Token 经济学告诉我们一个残酷公式:在多轮对话场景下,假设用户平均对话 8 轮,每轮 query 都把之前所有对话重新塞进 prompt,累积 input token 是 8 × 平均每轮 prompt,大约是单轮 4~6 倍的成本。在某些 Agent 场景里,这个数字是 10 倍以上。

这里有一条行业内部的经验法则:"$0.01 per request" 是一个心理学门槛。一旦单次推理成本超过一分钱,产品的可商业化空间就被压缩——尤其当 LTV 有限、对话深度不可控的时候。Context Engineering 不是奢侈品,它是把单位经济学(economics)拉回可商业区间的唯一方法。

第二个被忽视的成本是延迟成本。表面看,模型推理时间似乎是固定的(input 越长,首字时间越长,这不是秘密)。真正被忽视的是预处理成本——retrieval、reranking、压缩、记忆写入、工具调用前解析,这些环节每多 200ms,用户体感就像换了一个更慢的产品。在一个 1.5 秒 SLA 场景里,你的"retrieval + assembly"预算只有大概 600ms——在这个预算里你需要完成 embedding、向量召回、keyword 召回、reranking、去重、压缩、拼装,做完之后还要留给模型至少 800~1000ms 的首字返回时间。这意味着 context pipeline 不能是 I/O 链路上的累赘,必须被设计成有 SLA 的组件。

第三个被严重低估的成本是精度税(accuracy tax)。大量研究表明,在长上下文里,模型对"中间部分"的注意力显著低于开头和结尾——即所谓 *lost-in-the-middle* 现象。Liu et al. (2024) 在 Stanford 的实验里展示,即使是 GPT-4-class 模型,把关键信息放在 4k~8k token 的中间位置时,检索准确率会比放在开头/结尾下降 20~30 个百分点。这意味着:不是塞进 context 就被读到,塞进 context 反而可能让重要信息被淹没。

精度税的存在彻底反过来了一个常见误解——"context 越多越好"。事实是,在精度—成本—延迟三角形里,context 是一个 0-1 跳变函数:超过某个临界点之后,加 context 不再涨精度,只涨成本和延迟。Context Engineering 的艺术就是把上下文控制在有效区间里。

真实业务场景对长记忆、复杂状态的需求 / Real Business Scenarios Demand Long Memory and Complex State

模型厂商的 demo 永远会被优化得漂漂亮亮。三个精心筛选的检索片段、一段干净的对话历史、一个"完美对齐"的问题,然后模型给出漂亮答案。这是 demo。生产环境从来不是这样。

我们随机挑选几个 2024–2025 年真实在跑的高复杂度场景,看看它们的 context 实际长什么样:

场景一:多 Agent 协作的法律尽调(legal due diligence)。一个买方律所的 LLM 系统需要对一家中型 SaaS 公司做尽调。流程涉及:① Reading Agent 读 200 页合同并抽取关键条款;② Financial Agent 把这些条款映射到财报科目;③ Risk Agent 交叉比对行业判例;④ Composer Agent 起草尽调报告。这四个 Agent 之间共享的不是文字,是结构化状态——一个动态更新的 `deal_facts.json`,每一次新发现都可能让前面的结论被推翻。Context 在这个场景里不是"上文",是共识数据库(shared scratchpad)。这是传统 prompt 工程完全没法处理的。

场景二:多日陪伴的心理健康 Agent。一个面向青少年用户的心理健康支持产品,设计目标是每天陪伴、累积了解用户,逐步建立"关系 context"——用户的家庭结构、学业压力曲线、最近发生了什么事件、用户的语言风格、之前用过的隐喻。断电一次,关系就回退 30 天——这是不能接受的。这意味着 context 必须包含跨越数十次 session 的长记忆,而且记忆本身要被组织、压缩、增量更新,而不是简单"全量 dump"。

场景三:实时多文档协作的编程 Agent。类似 Cursor、Devin 这类系统,在用户"接受/拒绝"几次 diff 之后,Agent 必须在已经修改的文件、未修改的文件、git 状态、linter 输出、测试结果之间保持 100% 一致。任何一个"它忘了哪个文件被改过"都会导致幻觉。Context 在这里不是一个文本问题,是一个事务一致性问题。

场景四:跨语种、跨渠道的零售客服(就是我们开篇那个事故)。用户在网页开聊,跳到 WhatsApp,再回到 App。三个渠道的身份会被合并、订单会被跨渠道查询、退货政策在不同地区不同。Context 系统需要做 entity resolution(身份合并)、policy routing(策略路由)、state handoff(状态交接)——任何一个环节失效,Agent 都会"表现得像个金鱼"。

把这些场景的特征抽出来,你会看到五个反复出现的真实需求:

• **多轮深度**:不是 3~5 轮 demo,是 20~100 轮、跨 session、跨渠道的长链路;
• **知识密度**:不是 5 个检索片段,是上百个候选、多个知识源(memory、vector DB、graph DB、tabular)、需要 disambiguation;
• **多模态**:文字只是入门券,截图、表格、PDF、语音转写、工具输出;
• **状态可写**:对话过程中要持续更新"我们已经知道的事实",并且这些事实要被未来的推理使用;
• **失败可观测**:必须有 trace、replay、A/B、对抗测试,不能"开盲盒"。

这些需求里,没有一条能被更大的模型自动满足。更大的模型只能装得更宽,不能装得更准、装得更便宜、装得更可调试。Context Engineering 不是被更大模型消灭的中间产物,而是被真实业务强制推上舞台的工程学科。

头部实验室的技术路线收敛:上下文即工程 / Top Labs' Convergence: Context as Engineering

这一节要回答一个潜在的反对意见:"这会不会只是中国一线工程师圈子里自嗨的概念?国际头部实验室真的认同这一套吗?" 我们用证据说话。

Anthropic:在 2024 年的多篇工程博客和内部技术分享里,Anthropic 团队(包括参与 Claude 项目的工程师)明确提出 *Context Engineering* 这个术语,并开始把它和 *Prompt Engineering* 区分开来。他们在描述 Claude Computer Use 和长任务 Agent 时,多次强调"模型不是被 prompt 驱动的,是被 context 驱动的"。在他们的"building effective agents"系列工程文章里,核心论点可以概括成一句话:"真正决定 Agent 表现的,不是模型权重,而是你喂进去的 context。" 这是一次非常明确的术语背书。

OpenAI:2024 年 OpenAI 在发布 Assistants API 和后来的 memory 特性时,工程文档里反复出现一个概念——"the context you assemble matters more than the model you choose"。他们在 Reasoning 系列模型(o1、o3)的技术报告里也间接支持:reasoning 模型对 context 的结构化和噪声控制更敏感,context 不再是"塞进去就行",而是要"按 thinking budget 分层塞进去"。

DeepMind/Google:在 Gemini 的技术白皮书和团队博客里,他们提出了 *long context as a feature, structured context as a discipline* 的说法。Gemini 1.5 Pro 提供了 1M token 的上下文窗口,但工程团队在内部技术报告里也指出,单纯靠窗口大小无法应对"信噪比下降"问题,必须配合 context pruning、summarization、selective attention 等技术。

学界:Stanford、CMU、Berkeley、清华、北大等团队在 2024–2025 年的多篇论文中开始系统性地量化"context quality 对最终输出的影响"。其中一项关键结论是:在多步推理任务里,context 工程的边际效用远高于模型升级的边际效用——也就是说,花同样的钱提升 context 质量,比花钱训练一个更大的模型,效果更直接、更可测量。

把这些点连起来看,你会发现一个清晰的工业级共识正在形成:Context 不是一个工程细节,而是一个工程学科。它的命名空间、它的工具链、它的可观测性、它的失败模式清单,正在被工业界共同定义。这不是概念炒作,是一个已经发生的事情。

需要强调的是:"更大的模型能自动解决问题"是一个错误的乐观主义。在 2023 年,这个论点还有道理——GPT-4 出来时,很多 prompt 调优工作被模型能力直接吸收掉了。但到了 2025 年,前沿模型的边际能力进步主要体现在推理深度、工具使用、多模态理解,而对 context 噪声的鲁棒性提升非常缓慢。换句话说,模型在变得更"聪明",但在变得更"能容忍烂 context"这件事上进步有限。一个被 30k token 噪声淹没的系统,不会因为从 GPT-4 升级到 GPT-5 自动变好。这才是 context 工程必须存在的原因。

上下文工程能力矩阵:一份自评问卷 / The Context Engineering Capability Matrix

理论讲了这么多,如果不给你一份可以直接拿去诊断自己系统的工具,前面的内容就只是炫技。下面这张矩阵是我的团队在 2024 年内部用过的一个简化版,经过两次迭代后稳定下来,基本能覆盖 90% 的 LLM 应用在 context 维度上的自评需求。

四个阶段按成熟度从低到高排列:

阶段 1:Prompt 手写(Prompt-craft Era)。

• 你的 context 是 hardcoded 字符串,通常写在代码里或 jinja 模板里;
• 没有 retrieval,或者 retrieval 是一次性无重排序;
• 没有对话记忆,或记忆就是最近 N 轮的纯文本;
• 失败时只能靠"改 prompt"修复,改完不知道影响范围。

如果你在这里,这个系统基本上是一个聪明的 chatbot,但不是产品级 Agent。多数 demo 停留在这里。

阶段 2:链式拼接(Chain Assembly Era)。

• 开始有 retrieval + reranking pipeline,但拼