MCP 与上下文工程

这篇适合谁，读完能做到什么

适合已经会用大模型和 MCP 工具、开始遇到“上下文太长、信息选错、模型前后矛盾”问题的开发者。读完你应该能说清上下文工程关心哪几件事，知道 MCP 在设计上回应了哪些挑战，并能在自己的项目里挑一两种做法试验，同时设计一个能判断效果的办法。

先说清楚：这还是一个形成中的概念

上下文工程（context engineering）在 AI 领域是一个新提法，关注的是信息在用户、应用和模型之间如何组织、传递和维护^[1]。它和提示词工程（prompt engineering）不同，目前还在由实践者一边摸索、一边定义，因此本文讲的很多内容是探索方向，不是成熟的最佳实践^[1]。读这篇时，请把它当作一份思路清单，而不是操作手册。

上下文工程关心哪几件事

上下文工程可能涵盖的内容可以分成五个方面^[1]：

上下文选择：判断哪些信息与当前任务相关。
上下文结构化：组织信息，让模型更容易理解。
上下文交付：决定信息怎样、什么时候送到模型面前。
上下文维护：管理上下文的状态，以及它随时间的变化。
上下文评估：衡量并改进上下文的效果。

这五件事正好对应 MCP 的应用场景，因为 MCP 提供了一种标准方式，让应用把上下文提供给大模型^[1]。

把上下文看成一段旅程会更直观。用户输入进来之后，系统要做上下文组装，把用户输入、系统上下文、对话历史和检索到的其他信息拼在一起；然后模型处理这些上下文，生成回应；系统再更新内部状态，为下一轮交互做准备^[1]。每一步都可能出问题，所以每一步都值得单独检查。

三条正在形成的原则

第一条原则是尽量完整地共享上下文，而不是把它拆散到多个智能体或进程里。上下文一旦分散，一个部分做出的决定可能和另一个部分的决定冲突^[1]。

第二条原则是，模型的每一个动作都隐含着对上下文的理解。多个组件如果基于不同的上下文行动，这些隐含判断就可能相互矛盾，导致结果不一致^[1]。对 MCP 应用来说，这意味着复杂任务宁可线性处理，也不要在上下文被割裂的情况下并行执行；后面的步骤也应该能看到前面决定的完整上下文^[1]。

第三条原则是在上下文深度和窗口限制之间取得平衡。对话和流程变长以后，上下文窗口迟早会被撑满。目前探索中的做法包括压缩上下文、按相关性逐步加载，以及对历史做摘要，同时保留关键决定和事实^[1]。

MCP 在设计上回应了哪些挑战

下面是五类挑战，以及 MCP 的设计如何回应^[1]：

窗口有限：模型的上下文窗口大小固定。MCP 支持结构化、基于资源的上下文，可以高效引用，资源还可以分页并逐步加载^[1]。
相关性判断：很难确定哪些信息最该放进上下文。MCP 的工具机制允许按需动态检索，结构化的提示词也有助于保持组织方式一致^[1]。
上下文持久：跨多轮交互管理状态需要仔细追踪。MCP 标准化了会话管理，并定义了上下文演进的交互模式^[1]。不过，2026-07-28 版规范已经去掉了协议层的会话 ID 和 initialize 握手，实际开发时应以当前版本为准^[2]。
多模态：文本、图像、结构化数据的处理方式各不相同。MCP 设计上兼容多种内容类型，并提供多模态信息的标准化表示^[1]。
安全与隐私：上下文常常包含敏感信息。MCP 明确客户端和服务器的职责边界，并提供本地处理的选项，减少数据暴露^[1]。

这一部分的价值在于：它解释了协议设计的出发点，而不是承诺哪种用法一定有效。

四种探索中的做法

第一种是单线程线性处理。有实践者发现，它比分散上下文的多智能体架构结果更稳定。它看起来效率不如并行，但每一步都建立在前面决定的完整理解之上，结果往往更连贯、更可靠^[1]。

第二种是分块与优先级排序。把大量文档切成小块，计算每块与问题的相关性，只取最相关的几块作为上下文。这里给出的是一段概念性草图，函数都没有实现，只用来说明思路：

# Conceptual Example: Context Chunking and Prioritization
def process_with_chunked_context(documents, query):
    # 1. Break documents into smaller chunks
    chunks = chunk_documents(documents)
    # 2. Calculate relevance scores for each chunk
    scored_chunks = [(chunk, calculate_relevance(chunk, query)) for chunk in chunks]
    # 3. Sort chunks by relevance score
    sorted_chunks = sorted(scored_chunks, key=lambda x: x[1], reverse=True)
    # 4. Use the most relevant chunks as context
    context = create_context_from_chunks([chunk for chunk, score in sorted_chunks[:5]])
    # 5. Process with the prioritized context
    return generate_response(context, query)

真正落地时，chunk_documents、calculate_relevance 这些函数要自己实现，相关性打分可以用向量相似度，也可以用关键词^[1]。

第三种是渐进式加载。先只给模型最少的上下文，需要时再扩展。对简单问题，这可以明显减少 token 用量；遇到复杂问题时，依然能够处理^[1]。

第四种是压缩与摘要。去掉冗余信息，概括长内容，提取关键事实，保留关键要素，并尽量节省 token。长对话和大文档都可以用这种办法保持在窗口之内^[1]。

分层与检索

常见的建议是把上下文分成四层：核心层（模型总是需要的信息）、情境层（与当前交互直接相关的信息）、辅助层（可能有用的补充）和兜底层（只在必要时才读取）^[1]。

检索方式也有几种可以组合：用嵌入做语义搜索、用关键词查具体事实、两者混合使用，以及按类别、日期或来源做元数据过滤^[1]。

多智能体要慎重

多智能体架构在很多框架里很流行，但它对上下文管理有几个明显的问题：上下文分散会导致决定不一致；并行执行可能产生难以调和的冲突；智能体之间的通信开销可能抵消性能收益；还需要复杂的状态管理才能保持连贯^[1]。在很多情况下，一个掌握完整上下文的单智能体，结果可能比多个各自掌握部分上下文的专门智能体更可靠^[1]。