Context Engineering：决定 Agent 成败的，从来不是 Prompt

> **企业 AI 化的四层工程体系 · 第 ④ 篇** > 从 Prompt 到 Context：设计你的"信息流系统" --- ## 引言：在错误的那一层上，使再大的劲也没用 如果你的团队做过 Agent，下面这一幕你一定不陌生。 为了让 Agent 答得更准，工程师陷入了无止境的 prompt 调优。今天在系统提示里加一句"请仔细思考、逐步推理"，明天换一组 few-shot 示例，后天又把指令的措辞改了三遍。效果呢？时好时坏，像在抽奖。无论怎么调，那个准确率的天花板就是顶不上去。 很多团队的结论是："模型不够强，等下一代吧。" 但真相往往是另一回事：**你在错误的那一层上使劲。** 当一个 Agent 给出离谱的答案时，底层的大模型通常工作得好好的——它没坏。坏的，是你喂给它的信息。它要么没拿到该有的上下文，要么被一堆无关信息淹没，要么被互相矛盾的内容带偏。**模型再聪明，喂错了料，也做不出好菜。** 这就引出了本系列工程段的第一个、也是最被低估的真相：决定一个 Agent 成败的，往往不是 prompt，而是 **Context（上下文）**。 但在展开之前，我得先拆掉一个正在到处流传、却极具误导性的说法——"Prompt 工程已死，被 Context 工程取代了"。这句话错得很微妙，也很危险。纠正它，正是理解这一切的起点。 --- ## 一、先纠正一个流行的误导："Prompt 工程已死" 2025 年，"context engineering（上下文工程）"这个词火遍全网。Andrej Karpathy 等人在社交媒体上的推动，让它迅速成了热词，Cognition 等团队也在博客里正式使用了它。伴随而来的，是一种流行叙事：**prompt engineering 已经过时，被 context engineering 取代了。** 这个叙事，把两者的关系描绘成一条"进化时间线"——好像我们从 prompt 时代毕业，进入了 context 时代，prompt 成了昨日黄花。 **这是错的。它们不是取代关系，而是嵌套关系。** 回想本系列第一篇那张同心圆：LLM 是 CPU，外面一圈圈是 runtime。在那张图里，**Prompt 是最内环，Context 包在它外面。**两者从来不是先后接替的两个阶段，而是同时存在、层层包裹的两个圈。Prompt 没有过时，它只是从"全部"退回到了"最内核那一层"——而那一层，依然承重。 事实上，连 Karpathy 本人对 context engineering 的定义，也从不是"废掉 prompt"。他的原意大致是：**为任务提供让它"可被合理解决"所需的全部上下文。**注意，这是"加一层"，是在 prompt 之外再包一层信息的设计，而不是把 prompt 扔掉。 把它讲成"进化"，会让企业得到一个危险的错误心智模型——"我已经进化到 context 阶段了，prompt 不重要了"，于是放松了对最内环的打磨。而最内环一旦松动，外面包再多 context 也救不回来。 这种危害在落地时非常具体。一个团队如果信了"prompt 已死"，往往会做两件错事：一是把 prompt 全权交给框架的默认模板和抽象层，自己不再过问——结果模型一升级，藏在黑箱里的 prompt 行为悄悄变了，系统莫名其妙地退化，团队却查不到根因；二是把所有精力一股脑投到检索、记忆、向量库这些"外环"基建上，却忽略了最内环那个输出格式约束、那组 few-shot 示例，导致模型产出的结构忽好忽坏，外面再精巧的 context 编排也接不稳。**最内环和外环不是替代关系，是串联承重关系——任何一环垮了，整条都垮。**这正是"嵌套"这个词比"进化"准确得多的地方：进化暗示旧的可以丢，嵌套则提醒你每一层都还在、都还在承重。 正确的心智模型只有一个： > **Prompt 是最内环（仍然 load-bearing），Context 是包在它外面的状态空间（决定性更强）。两者相乘，缺一不可。**  理解了这一点，我们就能分别看清这两环各自的职责。先看最内环。 --- ## 二、Prompt 这一最内环，到底还管什么 既然 prompt 没死，那它现在的职责是什么？ 它管的是**单次调用里那些相对稳定的东西**：system prompt 里的角色设定、行为约束、输出格式的规范；few-shot 示例；指令的结构和措辞。这些是模型在每一次思考时都要遵循的"底层指令"，是认知的基本盘。 一线工程实践对这一层有个明确的纪律——「12-Factor Agents」里叫"掌控你自己的 prompt"：**对生产级系统，要手写、要拥有你的 prompt，而不要依赖框架那些把 prompt 藏起来的抽象层。**因为当模型迭代、当你要调 token 顺序和角色分工时，你必须能直接改到它。最内环越是承重，就越不能交给黑箱。 举个具体的例子，说明这一层为什么仍然致命。在招投标 Agent 里，"报价建议"这个决策点的输出格式，必须被 prompt 牢牢约束成一个固定 schema——报价区间、依据、置信度、风险等级，一个字段都不能少、不能乱。这个约束写在 prompt 里、由 few-shot 示例强化。如果这一层松了，模型今天给你一段散文、明天漏掉风险等级，后面所有的程序化处理（校验、入库、人工复核）就全断了。**最内环的指令质量，决定的是整个系统的"接口稳定性"——它不显眼，但一旦崩，外面包再多 context 也接不住。**这正是它依然 load-bearing 的含义。 但 Prompt 这一层有它与生俱来的三个局限，正是这三个局限，把决定权交到了外面那一圈手里： - **无状态**：一次调用就是一次调用，它不知道上一轮发生了什么。 - **无记忆**：它记不住跨任务、跨会话的信息。 - **无系统性**：它管不了"该检索哪些信息、该屏蔽哪些噪音、该如何组织当前任务的全部状态"。 换句话说，Prompt 决定了模型"怎么思考"，但决定不了模型"基于什么思考"。而"基于什么思考"——也就是喂什么信息进去——恰恰是决定答案对错的关键。这件事，归外面那一环管。它的名字，叫 Context。 --- ## 三、Context 是什么：当前任务的"状态空间" 给 Context 一个工程上严谨的定义： > **Context = 在当前这一步，喂给模型的、关于这个任务的全部状态空间。** 这里要立一条贯穿整个工程段的边界判据，记住它，后面每一篇都会用到： > **Context 层，管的是"喂什么进模型"。** （与之对应，下一篇要讲的 Harness 层，管的是"模型之外的执行"。这条线把两层切得干干净净。） 那"喂什么"具体包括哪些？在一个真实的 Agent 里，Context 至少由五类状态组成。我们用上一篇拆解过的招投标 Agent 来说明： - **RAG 检索信息**：从招标文件、能力库里检索出的、和当前判断相关的片段。 - **工具输出**：上一步工具调用返回的结果，比如"竞品查询"返回的竞争格局。 - **用户状态**：当前用户/任务的设定，比如这次投标的预算上限、风险偏好。 - **历史决策**：这条链路上之前已经做过的判断，比如"已确认满足硬性资质"。 - **schema 状态**：当前要求模型产出的结构化格式，比如报价建议必须填哪些字段。  这五类状态，共同构成了模型在某个决策点上"思考的依据"。它们组织得好不好，直接决定了答案的质量。 为什么说"组织得好不好"是决定性的？拿"测算报价"这个决策点做个好/坏对照就清楚了。 **坏的 Context**：把整份招标文件、整个能力库、过去三年所有投标记录，一股脑全塞进去，让模型"自己看着办"。结果是，真正该参考的那两三个同类项目的中标价，淹没在几百页噪音里；模型可能抓到了一个完全不相关的项目报价，给出离谱的建议。 **好的 Context**：只精准喂入——本次招标的评分权重（schema 状态）、本公司在同类项目上的成本结构（用户状态）、三个最相似历史项目的中标价与利润率（RAG 检索 + 历史决策）、刚查到的两家主要竞品的报价区间（工具输出）。信息少，但每一条都直接服务于"报价"这个判断。 **同一个模型、同一个 prompt，喂这两种 context，产出的质量天差地别。**这就是为什么我们说 Context 是决定项——它不是锦上添花，它是地基。组织 context 的能力，本质上就是"在每个决策点，把刚好够用的、最相关的状态，干净地呈现给模型"的能力。 由此，我们能写出 Agent 效果的"公式"： > **AI 效果 ≈ Prompt 质量 × Context 质量。** 但请注意现实中的权重：**在大多数生产场景里，Context 才是那个决定项。**这不是一句口号，而是被业界反复验证的发现——**大多数 Agent 的失败，是 context 的失败，而不是 model 的失败。** 为什么 Context 这么关键，又这么容易出错？因为它有一个极其反直觉的特性。 --- ## 四、决定性的证据：为什么"塞更多"反而更差 几乎所有团队的第一直觉都是：**上下文窗口越大越好，把能塞的都塞进去，模型自然判得准。** 这个直觉，是错的。而且是被实证狠狠打脸的那种错。 2025 年，多项研究指向同一个反直觉的结论，业界给它起了个名字叫 **context rot（上下文腐烂）**：Chroma 的研究报告显示，**随着输入 token 增多，模型性能会下降——即便检索是完美的、需要的信息确实都在里面。**另一篇论文的标题更直白：仅仅是上下文变长本身，就会损害模型性能，哪怕检索毫无问题。还有研究发现，模型在多轮对话里会"越聊越迷失"。 这意味着什么？意味着**把信息塞进更大的窗口，不仅不能解决问题，反而会制造问题。**多余的信息会稀释注意力、引入噪音、让模型抓不住真正重要的那几句。 所以，请彻底扭转一个认知： > **Context 工程的本质是减法，不是加法。** 它不是"想办法塞进更多"，而是"想办法只喂刚好够用的、最相关的那部分"。curate（精选）、compress（压缩）、prune（剪枝）——这些减法动作，才是 context 工程的核心。那些指望"等更大上下文窗口出来就能解决一切"的企业，正在押注一个错误的方向。 把"更大窗口陷阱"再演示得具体一点。假设你的招投标 Agent，在只喂入关键信息时，报价判断准确率不错。然后有人说"信息越全越好"，于是把整份招标文件附录、历年所有无关投标、整个行业白皮书都堆了进去——窗口确实没爆，模型也"读"完了。但准确率不升反降：因为关键的那几条评分权重，现在被埋在几十万 token 的噪音里，模型的注意力被严重稀释。**你给了它更多信息，却让它变得更笨。**这不是假设，正是 context rot 在生产里的真实形态。它的反直觉之处就在于：在传统软件里，"数据更全"几乎总是好事；但在 LLM 里，"上下文更全"经常是坏事。理解这一点，是从"调 prompt 的人"成长为"做 context 工程的人"的分水岭。 既然问题出在"喂错了、喂多了"，我们就需要一份诊断手册，搞清楚 Context 到底会以哪些方式出错。 --- ## 五、Context 的四种失败模式（一份诊断手册） 工程师 Drew Breunig 在《How to fix your context》里，把上下文的失败归纳成四种典型模式。把它们记下来，当你的 Agent 出错时，别急着改 prompt，先按这四类排查 context——这是一份能直接用的诊断手册。  逐个看，并配上招投标的例子： - **污染（Context Poisoning）**：一条错误的信息混进了上下文，之后所有判断都被它带偏。比如检索时误把另一个项目的报价当成了本项目的历史价，后面整套报价建议全错。**防法**：对进入上下文的信息做来源校验，宁缺毋滥。 - **分心（Context Distraction）**：相关信息被淹没在大量无关信息里，模型抓不住重点。比如把整份三百页招标文件全塞进去，真正关键的那几条硬性要求反而被忽略。**防法**：只检索、只喂入当前这一步需要的片段。 - **混淆（Context Confusion）**：上下文里有相似但不相关的内容，模型选错了对象。比如能力库里有两个名字相近的资质，模型张冠李戴。**防法**：检索时加强去重和区分度，必要时显式标注。 - **冲突（Context Clash）**：上下文里存在互相矛盾的信息，模型无所适从。比如历史决策说"已确认满足资质"，但新检索的文件又显示某项不达标。**防法**：在写入上下文前做一致性检查，矛盾要么解决、要么显式呈现给模型让它知道这是冲突。 这四种模式的共同点是：**它们看起来都像"模型出错了"，但根因全在 context。**下次 Agent 翻车，先过一遍这四类，你会发现绝大多数问题在这里就能定位。 诊断清楚之后，下一个问题就是：如何主动地、动态地把 context 管好？这就进入了更高级的 Context Orchestration。 --- ## 六、Context Orchestration：把"喂什么"升级成"信息流系统" 如果说前面讲的是"喂什么"，那 Context Orchestration（上下文编排）讲的就是"在一条不断循环的链路里，如何动态地决定每一步喂什么、压什么、存什么"。这是把零散的 context 处理，升级成一套**信息流系统**。 业界一个好用的组织框架（来自 LangChain 的总结），把这些手法归为四个动作：**写入（write）、选择（select）、压缩（compress）、隔离（isolate）**。我们结合实证解法来看： - **选择 / 路由（Select / Routing）**：不是把所有信息都喂进去，而是按当前决策点的需要，精准检索、按需路由。这是对抗"分心"和"context rot"的第一道防线。 - **压缩（Compress）**：当历史越积越长，必须压缩。目前有两条主流路线——**观察屏蔽（observation masking）**：把冗长的工具输出折叠/屏蔽掉，只留关键；**LLM 摘要（summarization）**：用模型把长历史总结成短摘要。JetBrains 在 2025 年的研究还给出了两者结合的混合方案，能显著降本。此外，Anthropic 提出的 **context editing / compaction**，是在运行时用规则剪枝，把窗口主动压住。 - **隔离 / 外置（Isolate / Offload）**：把不需要一直在场的信息，挪到上下文窗口之外，需要时再取回。Letta（MemGPT）、Mem0 这类**外部记忆系统**就是干这个的——让 Agent 拥有"长期记忆"，而不必把一切都堆在当前窗口里。 - **写入与演化（Write / Memory Evolution）**：把这一步产生的新状态、新决策写回记忆，让上下文随任务推进而演化。上一篇讲的 self-heal（把错误信息喂回上下文让模型自我修正）也是一种"写入"——它本质上是在动态地编辑 context。  看这张图你会发现，Context 早已不是"写一段提示词"那么简单，而是一个**有检索、有压缩、有记忆、会演化的动态系统**。这，才是 context engineering 这个词真正的分量所在。 把这套系统落到一次真实调用上，你就能看清它每一步在干什么。当招投标 Agent 走到"测算报价"这个决策点时，信息流系统会这样为它组装一份 context：先从**外部记忆**里取回本公司的成本基线和风险偏好（隔离/外置，不必一直在场）；再**按需检索**三个最相似的历史中标项目和当前竞品报价（选择/路由，而不是把全库倒进来）；把上一步冗长的工具原始输出**压缩**成一句关键结论（masking 或摘要）；最后按报价 schema 把这些**组装**成一份"刚好够用"的上下文，喂给 LLM。模型产出报价建议后，再把"本次报价依据"**写回**记忆，供后续步骤复用。 注意，这整个过程里，没有一步是"把更多东西塞进去"——**每一步都在做选择、压缩、隔离，都是减法。**一份好的 context，不是被堆出来的，是被"编排"出来的。当你的团队能为每个决策点都设计出这样一条信息流，你就真正从"写 prompt"跨进了"做 context 工程"。 --- ## 七、企业结论：未来 AI 工程的核心，是设计"信息流系统" 走到这里，本篇最想传达的判断已经呼之欲出： > **未来企业 AI 工程的核心，不是写更好的 prompt，而是设计更好的"信息流系统"。** Prompt 仍然重要，它是承重的最内环；但真正拉开 Agent 之间差距的，是外面那一环 Context——是你能不能为每一个决策点，精准地、干净地、刚好够用地，组织出它所需要的状态空间。 把它放回那张同心圆：Context 这一环，**往内**承接 Prompt（它决定喂什么给 prompt 之上的思考），**往外**则要靠 Harness 来供给（信息从哪检索、工具怎么执行）。这也正好把我们带到了下一层的边界： > **Context 管"喂什么进模型"；而"信息从哪来、工具怎么被可靠地执行"——那是 Harness 的事。** Context 工程的价值，是把"模型基于什么思考"这件事做对。但它依赖一个前提：那些要被喂进来的信息和工具输出，本身得是可靠的。而保证这一点的，是模型之外那套执行运行时——Harness。 --- ## 结论：Agent 出错时，先别调 Prompt 这篇文章想留给你的，是一个能立刻改变工作方式的判断： > **当 Agent 出错时，先别急着调 prompt——先查 context。** 按那四种失败模式（污染、分心、混淆、冲突）排查一遍，你会发现绝大多数"模型不行"的问题，根子在"信息喂错了"。而修复它的方向，不是塞进更多，而是减得更准。 把本篇的几个核心判断收拢成一句话： > **Prompt 没死（它是最内环），Context 才是决定项（它是状态空间）；大多数失败是 context 失败，而 Context 工程的本质是减法。** 如果你是技术决策者，现在就可以推动团队做一件事：**建立"先查 context、再调 prompt"的排障纪律，并开始把零散的提示词拼接，重构成一套有检索、有压缩、有记忆的信息流系统。**这一步，往往比再等一个更强的模型，性价比高得多。 最后，留一个问题，作为下一篇的引子： 我们说 Context 决定"喂什么进模型"。可这些信息和能力——检索、工具调用、外部记忆——它们本身是怎么被**可靠地执行**的？当一次工具调用失败了、当模型产出的结构不合规、当成本开始失控，是谁在模型之外撑住整个系统、让它从一个 demo 变成一个 production system？ 这套"模型之外的执行运行时"，正是让 LLM 从一颗 CPU 变成一台真正能干活的机器的关键。它叫 Harness。如何构建它，正是本系列**第⑤篇《Harness 工程：企业 AI 系统真正的核心》**要深入的内容。 我们下一篇见。 --- *本文为「企业 AI 化的四层工程体系」系列第 ④ 篇。从这一篇起，我们正式从内到外逐层拆解四层 runtime。下一篇，我们走出 Context 这一环，进入它外面那层真正决定"能不能上生产"的执行运行时——Harness。*