完整教程：上下文工程驱动智能体向 透明化推理日志

上下文工程如何重塑智能体的“思考方式”？
服务器/存储 编辑：陶然 时间：2025-07-22 09:25:24 2519 2
问题，真正决定其能否成为开发者得力助手的关键，在于它“能不能理解上下文”。就是在大模型能力日益强大的今天，AI“会不会写代码”已不再

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



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

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

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

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

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

项目状态：按照项目规划，导入功能这周进入开发阶段。

需求文档：设计稿明确列出 V1 支持 CSV 和 JSON，但后者会延后一周上线。

团队氛围：研发那边人手吃紧，担心 scope 变化影响进度。

任务历史：曾有一次因需求细节未澄清导致返工，刚复盘过。

个性化语气设定：直接、细节清楚、减少异步往返。

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

魔力在哪？

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

当前的任务规划

团队过往的沟通隐患

对方的工作状态与担忧

文档/知识库的实时状态

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

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

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

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



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

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

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



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

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

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

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

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

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

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

上下文中毒

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

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

情境干扰

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

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



语境混淆

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

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



语境冲突

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

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

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

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

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



1. 并行执行，无上下文共享

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

2. 并行执行，有上下文共享

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

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

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

4. 串行执行，引入压缩模型

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

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

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

1. 智能检索

大模型的输出会因为过多的外部程序，降低输出性能。例如由 MCP 定义的设备。这篇论文中，团队在对 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，让它们在各自的“泳道”里运行，任务分解成更小、更独立的工作，每个工作单元都有各自的上下文，防止上下文共享导致的信息干扰或语义冲突。

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

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

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

3. 上下文修剪

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

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

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

4. 上下文压缩&总结

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

业内主流的压缩方式有：

提取式压缩：直接从原始上下文中筛选出关键句子或段落，将它们拼接成新 prompt，不进行改写。实验室效果可实现高达 10× 的压缩比，同时几乎不损失模型准确性，在多类任务（单文档、多文档 QA、摘要）中表现比较好。优劣势包括保留原文措辞、信息可靠、输出质量高；操作低改动、执行路径简便。不足之处是压缩比受限于原段落长度，需要有效的关键内容识别机制。

压缩比高，能实现更短 prompt，但容易出现信息遗漏或歪曲，且依赖摘要模型质量。就是抽象式压缩：通过生成模型（比如摘要模型）将上下文概括成新文本，替代原内容，不保留原句。在高压缩比条件下，性能比提取式略差（尤其是长期任务），多文档 QA 场景中，若使用“query-aware summary”，即依据问题生成摘要，可提升性能达 10 个百分点。方案优势

令牌修剪：逐 token 剔除冗余或低价值内容，只保留关键 token，不重排句子结构。对于摘要任务，仅展现出边缘性能提升，总体落后于提取式压缩。实现简单，无需生成额外文本，但是稳定性较差，对于需要语义完整性的任务支持不足，且难以识别复杂语义依赖。

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