2026年8月，DataHub发布的《上下文管理状态报告》给出一个硬数据：82%的IT和数据领导者认为，单靠提示词工程已经撑不起生产级AI Agent。95%的数据团队计划在2026年内投入上下文工程培训。这不是概念炒作，是真金白银的预算迁移。
Anthropic、Sourcegraph、DataHub三方口径一致：提示词工程优化的是一句话怎么写，上下文工程优化的是模型每次推理时看到的全部信息。前者是子集，后者是整套系统。生产环境的瓶颈早就从”提示词写不好”变成了”该进上下文的信息没进来，不该进的全挤进来了”。
提示词工程为什么不够用了
提示词工程覆盖的技术仍然有效。Few-shot示例校准输出风格，链式思维外化模型推理，角色设定给模型一个身份，输出约束强制结构化。这些技巧在单轮任务里依然好用。
问题出在Agent上。Agent不是聊天机器人。聊天机器人一轮回答完事，上下文窗口里装的就是这一轮的信息。Agent跑在循环里，调用工具，积累状态，到第47步做决策时，前46步的残留还塞在上下文窗口里。Token预算有限，注意力预算也有限。Sourcegraph的工程团队给出一个判断：大多数上下文失败的根因，出在预算怎么花，前置提示词写得差反倒次要。
举个具体场景。一个编程Agent被要求修复Kubernetes的bug。它失败的原因通常不是底层模型不会推理。失败的原因是grep在一个百万行代码库里返回4000条命中，Agent把窗口烧在无关信息上，真正的根因从未进入上下文窗口。上下文工程要解决的，就是让根因进得来。
四根支柱：生产Agent的骨架
Sourcegraph在2026年5月的工程指南里把上下文工程拆成四根支柱，每一根对应Agent每一步必须回答的问题。
第一根：指令层。 指令层是模型在看到用户第一条消息之前，对自己角色、约束、输出格式的认知。难点在于找到脆性if-else规则和模糊套话之间的黄金区间。要足够具体以引导行为，又要足够灵活让模型能泛化。最常见的失败在于和模型训练默认的工具使用启发式相冲突，长度问题反倒次要。详细指令如果和模型默认行为打架，每一轮都会出现混乱。
第二根：检索。 检索决定外部数据怎么进入上下文窗口。包括向量数据库上的经典RAG、SQL存储的结构化查询、文件系统读取，以及Anthropic提出的即时检索——系统只在需要时用文件路径或查询字符串这类轻量标识符把底层内容拉进上下文。这一层的产出是模型可以推理的接地事实。生产Agent里幻觉和非接地答案的最大来源之一，就是糟糕的检索。
第三根：记忆。 Agent记忆分两种。短期记忆是到目前为止的对话历史，包括工具调用和工具结果。长期记忆是跨会话持久化的信息，比如用户偏好、项目约定、过往对话的摘要。生产记忆系统通常两者都维护，窗口快满时执行压缩步骤，把较早的轮次浓缩成摘要。Anthropic描述了一种结构化笔记模式：模型把自己的草稿写到上下文窗口之外的文件里作为持久记忆，需要时再读回来。
第四根：工具。 工具是Agent可调用的可执行面。这是上下文工程最需要下狠手的地方。Token在工具层累积极快：每个工具定义占Token，每次工具调用返回的结果占Token，语义重叠的工具集迫使模型烧轮次在近义工具之间做选择。Anthropic的经典观察反复被验证：最常见的失败模式是工具集臃肿，覆盖功能过多，导致工具选择出现歧义。如果人类工程师在某个场景下说不清该用哪个工具，AI Agent也做不到更好。可用工具的正确数量，几乎总是比团队第一版发布的要少。
Token预算管理：每个Token都有机会成本
上下文不是手工拼装的，是每轮都跑的流水线产出。典型组装流程从用户输入开始，并行跑多个检索步骤——向量搜索、关键词搜索、结构化查询、代码图查询——把结果合并成当前任务的候选集。记忆层提供相关历史轮次的短期记忆和过往会话的持久笔记。系统指令和工具定义分层叠加。整套系统把完整上下文传给语言模型。
每个Token都有机会成本。标准稠密注意力下，成本随序列长度二次方增长。即便有稀疏注意力和Flash Attention优化，更大的上下文窗口仍然推高延迟、开销和检索难度。Chroma的研究和Anthropic的标注都指向同一个问题——上下文腐烂：窗口里Token越多，模型准确召回其中信息的能力越差。
Token预算管理的核心动作是在低信号内容进入窗口之前砍掉它，而不是进去之后再清理。具体操作包括截断工具输出、把旧对话压缩成滚动摘要、丢弃低于相关性阈值的检索块、限制每次检索调用能贡献的候选数量。合并步骤产出的候选几乎总是超过预算。一个重排序器——通常是较小的交叉编码器或廉价模型——对每个候选打分，只保留top-k。检索50个高召回候选再重排序到精确top-5，通常比把50个块全塞进提示词指望模型自己挑要好得多。
编程Agent：上下文工程的实验室
代码是上下文工程最具体、最可测量的领域。Sourcegraph在2026年2月的7.0版本里把代码智能平台定位为”开发者和AI Agent共享的智能层”。底层观察一句话能说清：AI系统在企业代码库上挣扎的原因和人类一样——跨仓库依赖、埋在旧提交里的历史决策、没有任何可读文档记录的架构模式。
Sourcegraph的MCP服务器是检索支柱的一个具体答案。它向任何MCP兼容的Agent暴露13个工具，能力覆盖关键词搜索和语义搜索、符号解析和依赖追踪、跨仓库导航、提交和差异历史、文件读取。底层是同一套代码图，用SCIP协议索引，提供编译器精度的跨仓库导航。
2026年3月发布的CodeScaleBench结果给出了实测数字。同一Agent在两种配置下跑370个企业级任务：本地grep/文件读取对比Sourcegraph MCP。接入MCP后，文件召回率从0.127升到0.277，Precision@5从0.140升到0.478，F1@5从0.099升到0.262。一个Kubernetes单仓库任务在基线配置下两小时超时，接入MCP后89秒完成，得分0.90。一个跨文件重构任务，基线配置用了96次工具调用、84分钟，MCP配置用了5次工具调用、4.4分钟，奖励翻倍。
Stripe是公开案例之一。Stripe的Minions Agent接入MCP，用来收集内部文档、工单详情、构建状态、通过Sourcegraph搜索获取的代码智能。对任何构建多Agent代码系统的人来说，生产级检索支柱很少是单一向量数据库。它是一个通过标准协议接入Agent的代码感知检索层，有结构的地方用确定性结构，没结构的地方用语义搜索。
三个经典失败模式
上下文过载与分心。 团队最常做的第一件事是把所有东西倒进上下文窗口，因为感觉安全。实际不安全。除了成本和延迟，模型对任何单条信息的注意力随输入增长而衰减。Sourcegraph见过Agent在10万Token的代码库摘要上表现比5千Token的定向检索更差。两个相关失败模式反复出现：上下文分心，无关材料挤占重要上下文；上下文混乱，输入中不同方面的冲突信号把模型往不同方向拉。解药不是更少上下文，是更精准的上下文，加重排序器强制硬上限。
陈旧检索。 仓库变更时向量索引会过期，嵌入不刷新，上个季度嵌入的代码块已经不反映生产环境里跑的函数。不追踪新鲜度的检索系统会悄悄用无关数据毒化Agent的上下文窗口。代码场景尤其恶劣——Agent在旧README里找到废弃API，会自信地调用它。
迷失在中段。 Liu等人2023年的论文现在是领域基础文献。核心发现：模型性能在相关信息出现在输入开头或结尾时最高，出现在长上下文中段时显著下降，即便是显式长上下文模型也是如此。组装上下文的顺序有影响。把最高信号的材料放在顶部或底部，别埋在3万Token检索块堆的中段。
开发者该从哪动手
上下文工程不是一次性的提示词调优，是每轮都跑的流水线工程。DataHub报告里被追踪最多的指标是数据发现时间缩减（57%）、上下文检索准确率（51%）、成本效率提升（49%）、自动化覆盖率（47%）、查询成功率（46%）。这些指标指向同一个问题：正确的上下文有没有在正确的时刻到达模型。
对Python开发者来说，起步路径很清晰。先搭检索支柱，用向量数据库加重排序器，把召回和精度分开优化。再加记忆层，短期记忆用对话历史，长期记忆用文件持久化的结构化笔记。工具层做减法，砍掉语义重叠的工具，输入参数保持无歧义。最后做Token预算管理，在内容进窗口之前截断、压缩、丢弃。四根支柱立住，Agent才能在生产环境里扛住长程任务。
苏公网安备32010502011527号
发表回复