垂直和领域 Agent 的下一课：上下文工程

推荐语

上下文工程是智能体进化的关键，让AI真正理解任务背景和团队需求，实现自然可控的输出。

核心内容：
1. 从场景案例看上下文工程如何提升智能体表现
2. 提示词到上下文工程的技术演进路径
3. 构建有效上下文工程的实用策略与方法

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

    01  从一个场景开始，感受上下文工程的魔力

    02  提示词->提示词工程->上下文工程的演进

    03  上下文工程不等同于上下文

    04  构建上下文工程，从编排设计开始

    05  上下文工程的一些常见策略

技术术语的更迭，不仅是语言表达的更替，更代表着思维范式的转变。上下文工程这一新术语，之所以能引起业内共鸣，折射的是智能体复杂性的演化和应对策略的转变，是对现实中算法和工程挑战的一种集体回应，尤其是垂直和领域智能体。

图源：宝玉@X

现有的大模型已经非常智能。但即便是最聪明的人，如果不清楚自己要做的事情的上下文，也很难给出令人满意的交付。两款产品可能在做完全相同的事情，一款给人感觉充满魔力，但另一款却像个廉价的演示品。差别在哪里？就在于上下文工程的构建上。

01

从一个场景开始，感受上下文工程的魔力

场景设定：你是某款智能体的产品经理，正在钉钉上收到研发发来的私信：“有个问题想确认一下，新版的导入功能是不是只支持 CSV？我们这边需要开始写接口了。”

一个普通的智能助手可能会直接帮你草拟一句回复：“是的，目前只支持 CSV，后续可能会扩展。”表面上看没错，但没有考虑到项目当前阶段、上下游依赖、语气风格、团队共识等细节，容易引起误解或返工。

而一个具备“上下文感知”的智能体，会先主动检索：

• 项目状态：按照项目规划，导入功能这周进入开发阶段。
• 需求文档：设计稿明确列出 V1 支持 CSV 和 JSON，但后者会延后一周上线。
• 团队氛围：研发那边人手吃紧，担心 scope 变化影响进度。
• 任务历史：曾有一次因需求细节未澄清导致返工，刚复盘过。
• 个性化语气设定：直接、细节清楚、减少异步往返。

最终生成的消息可能是：“目前计划 V1 支持 CSV 和 JSON，但 JSON 要到下周才能接接口。你这边这两天先按 CSV 做没问题，接口格式我一会儿就在需求列表上进行补充。”

魔力在哪？

它不是因为模型算法更好，而是因为它理解了：

• 当前的任务规划
• 团队过往的沟通隐患
• 对方的工作状态与担忧
• 文档/知识库的实时状态

这正是“上下文工程”的魔力所在，用足够有结构的信息输入，换来更自然、更可控、更满意的输出行为。这种上下文工程的设计才会让智能体更像一个人去思考任务。

02

提示词->提示词工程->上下文工程的演进

提示词，是擅于利用大模型的用户手上的魔力笔。

通过具象的提示词可以获得尽可能满意的输出。我们在教大模型理解我们的同时，也在学习如何被理解。每个提示词都是一面镜子，映照出我们对“理解”本身的理解。比如提示词大师李继刚提供过大量、高质量的提示词。来看个例子：

这种用结构化的提示词挖掘大模型能力的体验，早期造就了大量围绕提示词调优的 Prompt Hacker 群体，也使得写提示词在一段时间里，成为优化大模型输出的核心技巧。然而，这种做法的核心问题也很快暴露出来：过度依赖个体经验，缺乏系统性、稳定性和可复用性，同一个提示词在不同模型或不同时间段下的表现千差万别，一套提示词很难横跨多个任务、多个上下文等等。

由此延伸出了提示词工程，Agent Builder 们试图将对大模型的调试经验固化为规则，将试错过程转化为一套可维护、可迭代的编排流程，打造相比通用大模型在某个场景下更具竞争力的行业智能体。例如，在实际项目中，你会看到团队构建了一组系统提示词模板，输入变量、角色说明、指令目标都被结构化封装。在电商文案生成、法律文书生成、客服问答等典型场景中，提示词工程的方式确实显著提高了输出的一致性与产品化效率。来看个例子。

下方是通义千问提供的诸多领域的垂直/领域智能体，已经把提示词内化成智能体的系统能力。用户不再需要输入“你是一个善于起爆炸标题党的作者”之类的提示词，降低了用户获得定向输出效果的使用门槛。

但是，随着用户的需求进一步升级，比如多轮对话、多角色协作、深度研究、用户状态追踪等复杂任务的不断涌现，模型应用从短指令走向长流程、从静态调用走向动态交互之后，大家会发现：真正影响输出质量的，是整个输入结构的系统设计能力，而不止是用户或系统提示词本身。于是，上下文工程应运而生。它不只是对提示词工程的简单补充，而是关注整个上下文的组织方式、信息来源、结构设计和动态调度。这预示着围绕“如何获取更好输出”这一核心目标的方法论，正在发生根本性的变化。

例如在文章开头，我们举的产品经理和工程师之间的那一段对话，一个高质量智能体，不再只是让大模型回答用户的问题，而是通过上下文工程，帮助大模型在回答前获得更加结构化的输入，包括项目状态、需求文档、任务历史、甚至团队氛围，实现大模型更好的理解当前的任务规划、团队过往的沟通隐患、对方的工作状态与担忧、文档/知识库的实时状态等等。上下文工程就成了一个结构化信息池，一个模型输出前的思维工作台。我们想想，两个人执行同一个任务时，除了各自的专业知识和技能储备以外，比得不就是各自对任务上下文的理解能力吗？

我们正在进入一个更具结构化的时代。

03

上下文工程不等同于上下文

构建上下文听起来像是把信息填进 prompt 这么简单的事情，为什么还需要专门搞一套工程？（注意，这里的工程还包括了模型的 RL，本文第五章的常见策略会提到具体案例。）其实任何有过多轮交互、系统协作、信息调度经验的人都知道：信息失败除了是因为缺失，还会是因为乱、冲突、不连贯。

我们曾经通过 RAG、Function Calling、MCP 等外部信息接口，让大模型变得更加聪明。但事实证明，工具太多也是有后果的，更多的补充信息、更长的上下文并不一定会产生更好的响应。上下文过载可能会导致智能体以意想不到的方式失败。上下文可能会变得有害、分散注意力、令人困惑或产生冲突。这对于依赖上下文来收集信息、综合发现并协调行动的智能体来说尤其成问题。这也一定程度上抑制了 RAG、Function Calling、MCP 的热情。例如当你设计的智能体对接几十个 MCP 时，对 Tool 信息的管理就会成为新的工程课题（Nacos Router 和 Higress 的 Toolset 是解决这一工程课题的不同技术手段）。

Drew Breunig[1] 对常见上下文失败归类为以下4种，这对我们进一步理解“上下文工程不等同于上下文”，很有帮助。

上下文中毒

过往训练和评估大模型时，研究者长期聚焦于单轮、任务全量给定的情况。但现实使用中，用户往往采用多轮对话逐步补充、不完全描述需求的交互方式，这会引发错误信息出现的概率。当错误的信息，比如用户误输、工具输出异常等被写入上下文时，模型会将其当成事实反复引用，并执着于实现不可能或无关的目标，甚至后续每一步决策都在错误基础上前行，越走越偏。

就像互联网提升了我们获取信息的效率和信息面积，但也更容易被虚假信息误导。当我们误把一个虚假信息当真，讲给更多人听，结果就形成了自己的潜意识，还会在后续其他的讨论和推理中引用该虚假信息。

情境干扰

指的是上下文过长或冗余信息过多，导致模型注意力资源被稀释，过度关注上下文，忽略了原本通过训练获得的内容，输出质量下降。虽然现在的大模型都已经支持百万级别的 token 上下文输入，但是 Gemini 2.5 的一份技术报告[2]中指出，随着上下文超过 10 万个 token，大模型倾向于多步骤生成推理的长上下文，而非用于检索的长上下文。对此我们都有真实的体验，例如考前复习，突然布置了一大包模拟题，太杂太多，混淆了原本积累的知识和理解，反而考砸了。

根据 Databrick 的一项报告[3]，大多数模型的性能在达到一定上下文规模后就会下降。Llama-3.1-405b 的性能在 32k 个 token 后开始下降，GPT-4-0125-preview 的性能在 64k 个 token 后开始下降，并且只有少数模型能够在所有数据集上保持一致的长上下文 RAG 性能。

语境混淆

是指模型使用上下文中多余的内容来生成低质量的响应。例如 Agent 配置了16个 MCP，当用户发起请求，即便该请求只和其中2个 MCP 有关，大模型也会把16个 MCP 全部检索一遍，导致模型有可能将这些无关片段也纳入推理，生成了偏题或低质量的响应。

下方截图是伯克利今年6月发布的函数调用排行榜[4]，是对外部工具调用的基准，用于评估模型使用工具进行响应的能力。该排行榜显示大模型在引入函数调用或使用工具的时候，几乎所有大语言模型的性能都会比原始文本生成任务中有所下降，在多函数调用场景中，准确率显著低于单函数调用。

语境冲突

指的是当上下文中积累的新信息和外部工具或训练知识库中的信息相冲突，导致模型输出不稳定。这在我们生活中也常遇见，例如网约车司机安装了两台导航软件，同一个目的地若在两个导航软件中出现不同的导航路线，司机就会犯难，然后随机选择一个。

总的来看，上下文既是提升输出的魔力笔，又会因为信息太多带来上下文中毒、情景干扰、语境混淆、语境冲突的挑战，因此通过上下文工程的构建来保障上下文的交付质量，是构建高质量智能体的关键。

上下文工程包括上下文从哪来？保留哪些？丢弃哪些？是否要压缩？如何压缩？是否需要隔离？谁来写？谁来拼接？所有这些问题构成了上下文工程的工作边界。

04

构建上下文工程，从编排设计开始

目前业内还未出现构建比通用大模型更加智能的 Agent 的标准方法论。但从业内领先实践者的分享中，我们或许能得到一些启发，至少能了解到如何开始。例如近期 Cognition 发布的一篇技术博客[5]，就是不错的参考。文中列举了 Agent 处理复杂长任务时的4种编排流程，并对输出可靠性进行了比对。

1️⃣ 并行执行，无上下文共享

主任务拆分为多个子任务，分别由不同的 SubAgent 独立执行，彼此之间没有共享上下文信息，也没有交互。优势是实现简单、便于并行计算、token 消耗更经济，充分利用不同 Agent 的专业能力。但是任何子任务一旦失败，整合阶段将难以进行，且没有补救机制。像拼图游戏，每块都找不同人拼，但没人知道最终图长啥样，最后发现拼不上。

2️⃣ 并行执行，有上下文共享

子任务执行前都能访问一个共享上下文，但执行仍是独立完成，子任务间没有交互。优势是比方式一更可靠，任务理解更统一。但仍可能遇到输出冲突、不协调的情况。就像菜品采购、切配工、厨师协同做一道菜，大家看了同一份菜单，固然各自有岗位分工，但是三者间没有交流，按照自己的理解去执行，做出来的菜品就不如娴熟搭配的后厨团队。

3️⃣ 串行执行，逐步构建上下文

任务由多个 SubAgent 串行完成，前一个 Agent 的输出成为后一个 Agent 的输入，构建一种“任务接力”模式。优势是子任务之间能被相互看到，任务理解更统一。但是任务过长时，串行产生的上下文会迅速膨胀，最终可能超过模型上下文窗口的容量限制，导致上下文溢出。工程中，如果我们设计的流水线很长，最终导致缓存溢出的可能性就会变大，其实是同样的原理。

4️⃣ 串行执行，引入压缩模型

在原有流程中加入一个专门的“上下文压缩模型”，用于将过往的对话、行动历史压缩为少量关键细节与事件，供下一个模型继续使用，保持决策连贯。优势是突破上下文窗口限制，实现更长任务的处理；提高 Agent 的长期记忆能力。但这很难做好，需要投入精力去弄清楚哪些是关键信息，并创建一个擅长此的系统，一旦压缩模型压缩质量不高，压缩过程中就会因为丢失细节，影响输出稳定性。从事技术服务的，既要懂产品和技术，还要深入客户的业务理解场景，不然很难给出令人满意的交付。

05

上下文工程的一些常见策略

在 Cognition 提出的4类 Agent 编排流程中，所有失败的根源都可以追溯到“上下文策略的不合理”：共享不足、信息断裂、冗余失控。这就构成了上下文工程在处理复杂长任务时的真实使命，帮系统“看得更加清晰”。

1️⃣ 智能检索

大模型的输出会因为过多的外部工具，降低输出性能。例如由 MCP 定义的工具。这篇论文中[6]，团队在对 DeepSeek-v3 进行提示时，发现当工具数量超过 30 种，工具描述开始重叠，极易造成混淆。超过100 种工具后，该模型几乎肯定会失败。因此通过智能检索，选择正确的工具至关重要使用。

该团队引入了 RAG-MCP，通过一个检索增强生成框架，减轻工具发现的负担。RAG-MCP 使用语义检索，在调用 LLM 之前从外部索引中识别与给定查询最相关的 MCP。只有选定的工具描述才会传递给模型，从而大幅减少提示大小并简化决策。论文中的实验表明，RAG-MCP 显著减少了提示标记（例如，减少了 50% 以上），并在基准任务上将工具选择准确率提高了两倍以上（43.13% 对比基准的 13.62%）。RAG-MCP 为 LLM 实现了可扩展且准确的工具集成。

Nacos 近期发布的 MCP Router 就是 RAG-MCP 的开源实践。Nacos MCP Router 会根据任务描述和关键词检索出合适的 MCP 服务器后，再由大模型进行调用。

2️⃣ 上下文隔离

上下文隔离是将不同任务/子目标拆成独立线程或 Agent，让它们在各自的“泳道”里运行，任务分解成更小、更独立的工作，每个工作单元都有各自的上下文，防止上下文共享导致的信息干扰或语义冲突。

工程上的技术手段是相通的。

做过微服务的同学一定对“泳道”一词不陌生。想象你有一个多租户的微服务平台，每个租户都能访问订单服务。如果没有泳道机制，某个大客户突然请求暴涨，可能拖垮整个系统；而有了泳道，每个客户有独立资源，不互相干扰。同理，在大模型应用中，如果多个用户/任务共享一份上下文空间，模型可能混淆角色指令、任务状态，导致幻觉频发。用隔离结构就能较好的解决这种问题。不同的是，微服务治理中的“泳道”是用来控制访问流量，大模型应用中的“泳道”是用来控制语义信息流。

3️⃣ 上下文修剪

上下文修剪是指剔除无关、过时或冗余的上下文片段，降低上下文混淆的风险。因为随着对话或任务的持续推进，原始上下文越积越多。但是模型的上下文窗口是有限的，堆叠会带来两个问题：模型注意力稀释和 token 成本失控。

这和我们维护我们手机上内存很像，一开始所有应用和历史信息都保留，但当手机出现运行缓慢的时候，就会开始清理手机内存，例如把下载到本地的大文件删除，删除微信聊天中的不重要的历史信息。不同的是，在大模型应用中，上下文的修剪并非执行单一指令这么简单，还需要基于重要性得分删减对话历史、基于意图匹配清理无关检索结果，甚至使用小模型做冗余句子识别。这些策略的质量将决定上下文的修剪质量。

这篇论文[7]提到的 Provence 方法，使用了用于上下文剪枝的大模型和预训练的重排序器（用于重排序分数）创建合成训练目标，并基于合成数据调整预训练的重排序器，以便最终的统一模型能够高效地执行上下文剪枝和重排序。Provence 从上下文的段落中删除了和用户问题不相关的句子，减少上下文噪声，加快大模型内容生成，并且对于任何大模型或检索器来说，都能以即插即用的方式实现。

4️⃣上下文压缩&总结

不同于上下文的修剪，压缩是更进一步的工程策略。当我们对上下文修剪完后，再对剩下的上下文进行压缩，把长文本压缩成语义密度更高的表达，进一步释放上下文空间，让模型能聚焦真正关键的信息。

业内主流的压缩方式有：

• 提取式压缩：直接从原始上下文中筛选出关键句子或段落，将它们拼接成新 prompt，不进行改写。实验室效果可实现高达 10× 的压缩比，同时几乎不损失模型准确性，在多类任务（单文档、多文档 QA、摘要）中表现比较好。优劣势包括保留原文措辞、信息可靠、输出质量高；操作低改动、执行路径简单。不足之处是压缩比受限于原段落长度，需要有效的关键内容识别机制。
• 抽象式压缩：通过生成模型（比如摘要模型）将上下文概括成新文本，替代原内容，不保留原句。在高压缩比条件下，性能比提取式略差（尤其是长期任务），多文档 QA 场景中，若使用“query-aware summary”，即依据问题生成摘要，可提升性能达 10 个百分点。方案优势是压缩比高，能实现更短 prompt，但容易出现信息遗漏或歪曲，且依赖摘要模型质量。
• 令牌修剪：逐 token 剔除冗余或低价值内容，只保留关键 token，不重排句子结构。对于摘要任务，仅展现出边缘性能提升，总体落后于提取式压缩。实现简单，无需生成额外文本，但是稳定性较差，对于需要语义完整性的任务支持不足，且难以识别复杂语义依赖。

这四种策略并非孤立存在，而是从入口（检索）到单元化（隔离）、到清理（修剪）、再到提炼（压缩），组成了一整套上下文的工程能力，是构建大模型应用的基础。理解并创造性的应用这些策略，像打造产品一样，去构建这些上下文工程，将成为 Agent Builder 们的核心竞争力。