模型够强了，问题出在哪

有句话说，给一个人再好的脑子，把他关在一间什么都没有的房间里，他也做不出什么像样的决策。大模型 Agent 面对的困境与此如出一辙。

2025 年以来，主流大模型的推理能力已经非常强悍——逻辑链、数学证明、代码生成、多步规划，样样拿得起来。但当这些模型被包装成 Agent 投入实际业务场景后，表现却经常让人失望：回答牛头不对马嘴，忽略关键背景信息，在多轮对话中前后矛盾。

问题不在模型本身。

问题在于上下文。 你给模型看的信息决定了它能做出什么判断。一个上下文混乱、信息缺失、噪声泛滥的系统，即便底层跑着千亿参数的顶级模型，输出也只能是垃圾。

这就是为什么过去一年多，越来越多团队把精力从"怎么挑更好的模型"转向了"怎么喂更好的上下文"。这个转向有一个正式的名字：Context Engineering——上下文工程。

Prompt Engineering 做到了极限

它解决了什么问题

2023 到 2024 年，Prompt Engineering 几乎是大模型应用的全部技术含量。怎么写指令让模型听话、怎么设计 Few-shot 示例让模型模仿、怎么用 Chain-of-Thought 引导推理——这些技巧确实让模型输出质量有了明显提升。

但 Prompt Engineering 有一个天然的边界：它只处理"你主动告诉模型的话"。

一个典型的 Agent 调用中，用户编写的 Prompt 可能只占整个输入 token 的 3%-5%。剩下的 95% 以上全部是系统自动组装的上下文——系统指令、对话历史、工具返回结果、检索片段、用户画像。Prompt Engineering 管不到这 95%。

它管不到的地方才是关键

来看一组真实的对比：

你精心打磨的那段 Prompt，在模型的整个输入中只是一小撮调味料。真正决定菜好不好吃的，是那一大锅汤底——上下文。

如果说 Prompt Engineering 是在精心写一封邮件的正文，那 Context Engineering 是在设计整个邮件系统的信息架构——谁该收到什么、什么时候收到、以什么格式呈现。

从 Prompt 到 Context：不只是多了几个字

本质区别在哪

Prompt Engineering 和 Context Engineering 的区别，不是量变，而是质变。

Prompt Engineering 是单点优化。 你写的是一段固定文本，目标是让模型"听懂你的话"。它是一次性的、静态的、面向单次调用的。

Context Engineering 是系统设计。 你设计的是一个动态的信息供给体系，目标是让模型在每次调用时都能"看到正确的东西"。它是持续的、动态的、面向整个交互生命周期的。

具体来说，区别体现在三个维度：

维度一：信息范围。 Prompt Engineering 关注你手写的那段指令。Context Engineering 关注模型"看到"的所有信息——包括你手写的，也包括系统自动注入的。

维度二：时间跨度。 Prompt Engineering 是一次性设计，写好了就不变。Context Engineering 需要管理信息的时间线——哪些是历史数据、哪些是实时数据、哪些信息已经过期需要剔除。

维度三：决策主体。 Prompt Engineering 由人来决策。Context Engineering 中，很多决策是 Agent 自己做的——它需要判断什么时候该查什么数据、查多少、怎么组织。

一个直观的类比

想象你是一个新来的律师助理，需要帮合伙人准备一场庭审。

Prompt Engineering 相当于合伙人给你说了一句话：“帮我准备一下张三诉李四合同纠纷案的材料。"——指令清晰，但仅此而已。

Context Engineering 相当于合伙人给你一整套工作体系：案件档案管理规范、证据分类标准、法律条文检索系统、历史判例数据库、当事人信息库，外加一套明确的操作手册告诉你什么情况下该调取什么材料。

同样的合伙人，同样的指令，在两种体系下，你交出来的材料质量天差地别。

MCP 协议：上下文的标准化管道

为什么需要一个协议

在 MCP 出现之前，Agent 获取上下文的方式极其原始：每个数据源一套定制代码，每种工具一个适配层。接入 CRM 写一套、接数据库写一套、接文档系统又写一套。不仅开发成本高，更致命的是——各数据源返回的格式五花八门，Agent 根本无法统一管理。

MCP（Model Context Protocol）的核心贡献，是给上下文管理提供了一套标准化的协议层。它不关心你的数据存在哪里、用什么格式存储，它只定义了一套统一的接口规范：Agent 怎么请求数据、Server 怎么返回数据、数据应该携带哪些元信息。

MCP 改变了什么

MCP 协议对上下文管理的改变，可以归纳为三点：

第一，上下文有了"身份”。 在传统 RAG 中，检索回来的就是一段纯文本，模型不知道它从哪来、什么时候更新的、可信度如何。MCP 的 Resource 机制让每条数据都携带结构化元信息——来源、时间戳、可信度等级、权限级别。模型在推理时可以据此调整对信息的信任权重。

第二，上下文变成了"按需获取"。 传统方案是预先检索、一次性灌入。MCP 的 Tools 机制让 Agent 可以在推理过程中主动发起查询——发现信息不够就去查、发现数据可疑就去验证。上下文从"静态注入"变成了"动态构建"。

第三，上下文来源可插拔。 通过 MCP 协议，新增一个数据源只需要开发一个 MCP Server，不需要改动 Agent 核心代码。这让上下文系统的扩展变得像插 USB 设备一样简单。

一个简单的架构示意

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

用户提问
  │
  ▼
Agent 核心（推理引擎）
  │
  ├──→ MCP Server A（用户画像）  → 返回结构化偏好数据
  ├──→ MCP Server B（业务知识库）→ 返回带时间戳的文档片段
  ├──→ MCP Server C（业务系统）  → 返回实时业务数据
  │
  ▼
上下文组装器 → 分层、排序、裁剪 → 最终输入
  │
  ▼
大模型推理 → 输出

这个架构的关键在于中间的"上下文组装器"——它不是简单地把所有 MCP 返回的数据拼在一起，而是根据任务需求、token 预算、信息优先级做精细化的组装决策。这就是 Context Engineering 的核心工程环节。

三种记忆架构：你的 Agent 该记住什么

记忆架构是 Context Engineering 的骨架。一个 Agent 能记住多少、记多久、怎么检索，直接决定了它在长周期交互中的表现。

架构一：无状态——阅后即焚

最简单的方案。Agent 不保留任何记忆，每次对话都是全新开始。

• 工作方式：用户提问 → 检索外部知识库 → 拼装上下文 → 生成回答 → 清空一切
• 适用场景：一次性问答、匿名客服、知识库搜索
• 核心优势：实现简单、无状态污染、容易水平扩展
• 致命缺陷：对话了 50 次，第 51 次 Agent 还是不认识你

这种架构下，Agent 本质上是一个"高级搜索引擎"。它能回答问题，但不能积累关系。用户每次都要重复自我介绍、重复说明背景、重复表达偏好。

架构二：短期记忆——对话窗口内的连贯

中等复杂度的方案。Agent 保留当前会话的对话记录，用滑动窗口或摘要压缩来管理长度。

• 工作方式：保留最近 N 轮对话 + 更早内容的摘要 → 拼装上下文 → 推理
• 适用场景：单次客服会话、多轮对话机器人
• 核心优势：能在单次会话中维持连贯性
• 致命缺陷：会话结束即遗忘，摘要过程丢失关键细节

一个典型的翻车场景：用户在对话开头说了"我是高级会员"，中间聊了 20 轮其他话题后，摘要系统把这句话压缩成了"用户提及了账户信息"。到最后 Agent 给出方案时，完全没考虑高级会员的专属权益。

架构三：长期记忆——跨会话的持续认知

最成熟的方案。Agent 拥有持久化的结构化记忆，跨会话保留用户的关键信息。

• 工作方式：长期记忆自动注入 → 当前会话上下文 → MCP 按需获取 → 分层组装 → 推理
• 适用场景：个人助理、长期客服、编程助手
• 核心优势：越用越懂用户，体验随时间递增
• 核心挑战：记忆的写入判断、冲突处理、遗忘策略

三种架构的详细对比：

选择哪种架构，取决于业务场景的交互深度。如果用户跟你的 Agent 只打一两次交道，无状态就够了。如果用户是长期使用者，长期记忆架构带来的体验提升是碾压级的。

工程化落地：上下文怎么裁剪、排序、压缩

理念层面的东西聊完了，接下来进入真正的工程环节。Context Engineering 最难的部分不是"知道该做什么"，而是"在有限的 token 预算内，把最有价值的信息塞进去"。

上下文裁剪：不是所有信息都值得上桌

一个 Agent 在运行时可以获取到的信息量，往往远超模型的上下文窗口。CRM 里几万条客户记录、知识库中上千篇文档、对话历史上百轮记录——全部塞进去不现实，也不该塞。

裁剪策略的核心是相关性过滤：

策略一：任务相关性裁剪。 根据当前任务类型，只加载与该任务相关的信息类别。比如用户问的是退款问题，就不需要加载他的浏览历史和收藏记录。

策略二：时效性裁剪。 设定时间阈值，丢弃超过一定期限的信息。一个月前的工单记录在回答当前问题时通常没有参考价值——除非用户主动提及。

策略三：去重裁剪。 多条信息源可能返回重叠内容。需要在组装阶段做去重，避免同一段信息占用多份 token。

优先级排序：好的信息先上桌

裁剪之后，剩下的信息也不是平等地堆在一起。需要有一套排序机制，确保最重要的信息出现在模型注意力最集中的位置。

排序的优先级通常遵循这个逻辑：

1. 系统指令和安全约束——绝对优先级，永远在最前面
2. 当前任务的直接上下文——用户刚刚说了什么、正在做什么
3. 用户画像和偏好——影响回答策略的关键信息
4. 高相关度的检索结果——直接回答问题的知识片段
5. 补充性背景信息——空间允许时才加入

一个容易忽略的细节：信息在 Prompt 中的位置影响模型对它的关注度。 多数模型对开头和结尾的信息关注度更高，中间部分容易被"遗忘"。所以最重要的信息应该放在上下文的首尾两端，次要信息放中间。

压缩策略：同样的信息，更少的 token

当裁剪和排序都做完了，token 预算还是不够，就需要压缩。

摘要压缩： 对长文本做摘要提取。但不是简单地用另一个模型去"总结"——这太慢了。更好的做法是预设模板，对结构化数据做格式化精简。比如：

1
2
3
4
5
6
7

压缩前（380 tokens）：
"客户张先生于2026年6月15日通过在线客服渠道提交了一个退款申请，
申请原因是他在6月12日购买的商品（订单号：ORD-20260612-8847）
存在质量问题，具体描述为商品外包装破损且内部零件缺失……"

压缩后（45 tokens）：
"[退款] 张先生/ORD-0612-8847/质量问题(包装破损+零件缺失)/6月15日提交"

信息量几乎没有损失，但 token 消耗降低了 88%。

选择性提取： 对一个完整的数据对象，只提取与当前任务相关的字段。用户画像可能有 50 个字段，但如果当前任务是处理退款，只需要加载"会员等级、历史退款记录、账户状态"这几个字段。

引用而非内联： 对于大段文档，不在上下文中内联全文，而是给出一个简短摘要加上引用标识。如果模型在推理过程中需要查看原文，再通过 MCP 工具按需加载。

实战案例：客服 Agent 准确率提升 40%

说了这么多理论，来看一个真实案例。

改造前的困境

一个中型电商平台的客服 Agent，日均处理 3000+ 条用户咨询。底层用的是某主流大模型，能力不差，但实际表现让人头疼：

• 回答准确率 62%：大量回答跟用户的实际情况对不上
• 多轮对话崩溃率高：超过 5 轮后，Agent 经常"忘记"前面说过的内容
• 用户重复描述率 45%：近一半的用户需要在对话中途重新说明自己的问题

分析后发现，问题几乎全部出在上下文管理上：

1. 信息缺失：Agent 不知道用户的会员等级、历史订单、之前的投诉记录
2. 信息过时：上下文里混入了几个月前的旧工单，干扰当前判断
3. 信息冗余：同一通对话里，知识库检索回来了 8 段高度相似的政策文本
4. 缺乏结构：所有信息平铺在一起，模型分不清哪些是用户说的、哪些是系统返回的

改造方案

整个改造围绕 Context Engineering 做了四件事：

第一，接入长期记忆。 为每个用户建立结构化画像——会员等级、历史订单摘要、偏好渠道、过往投诉类型。这些信息在每次对话开始时自动注入，不再需要用户重复自我介绍。

第二，MCP 化数据源接入。 把订单系统、物流系统、退换货政策库分别封装成 MCP Server。Agent 在推理过程中根据用户的问题类型，按需调用对应的 Server 获取数据，而不是预先把所有可能相关的信息全部检索出来。

第三，实施上下文分层。 每次调用模型时，上下文按照"系统指令 → 用户画像 → 当前会话记录 → MCP 按需数据 → 补充知识"的优先级分层组装，每层有明确的 token 预算上限。

第四，压缩与裁剪。 对历史对话记录做结构化压缩（提取关键事实和结论，丢弃寒暄和重复内容）；对检索结果做去重和排序（同一政策只保留最相关的一条）；对超过 7 天的旧工单做时效性裁剪。

改造结果

最值得注意的是"平均对话轮次"的下降。从 7.2 轮降到 4.8 轮，意味着用户不需要反复解释，Agent 能在更少的交互中理解并解决问题。这直接归功于长期记忆和结构化上下文的引入——Agent 在对话开始时就已经"认识"这个用户了。

一个细节的对比

改造前，用户问"我的退款到哪了"，Agent 收到的上下文是：

1
2
3
4

[系统指令] 你是一个客服机器人...（2000 tokens）
[对话历史] 过去10轮完整对话...（3000 tokens）
[检索结果] 8段退款政策文本...（4000 tokens）
[用户当前问题] 我的退款到哪了（15 tokens）

改造后，同样的问题，Agent 收到的上下文变成了：

1
2
3
4
5
6

[系统指令] 精简版客服指令...（500 tokens）
[用户画像] 王女士/金卡会员/近3月2笔退款/偏好快捷处理...（120 tokens）
[当前会话] 前3轮关键事实摘要...（200 tokens）
[MCP:订单系统] 最近一笔退款单/ORD-0702/审批中/预计7月10日到账...（80 tokens）
[MCP:退款政策] 金卡会员退款时效条款（仅此一条）...（150 tokens）
[用户当前问题] 我的退款到哪了（15 tokens）

总 token 从近 10000 降到了约 1000，但信息密度提高了数倍。模型拿到的每一条信息都跟当前问题直接相关，没有噪声、没有冗余、没有过时数据。

被忽视的工程细节

Context Engineering 看起来是"管理信息"的事情，但实际操作中有几个容易被忽略的工程细节，它们往往决定了系统是停留在 Demo 阶段还是能真正上线。

Token 预算是硬约束

不管模型的上下文窗口有多大，token 都是有成本的——不仅是金钱成本（API 按 token 计费），更是延迟成本（输入越长，推理越慢）和质量成本（信息过多导致注意力分散）。

一个成熟的系统会为每次模型调用设定明确的 token 预算，并且有预算超支时的降级策略。比如：当可用 token 不足时，先砍背景层、再砍按需层、最后才动高优层。

上下文的一致性校验

当上下文来自多个 MCP Server 时，信息之间可能互相矛盾。CRM 系统说用户是"金卡会员"，订单系统说用户"上个月已降级为银卡"。如果两条信息同时进入上下文，模型会困惑。

解决办法是在上下文组装阶段加入一致性校验：对于同一实体的同一属性，只保留最新版本的数据，并在元信息中标注"此数据已于 XX 日期更新"。

可观测性

你必须能看到每次模型调用时，上下文到底长什么样。这不仅是为了调试，更是为了持续优化。一个基本的可观测性方案应该记录：

• 每次调用的完整上下文快照
• 各层级信息的 token 占用比例
• MCP 调用的延迟和返回状态
• 模型输出质量与上下文组成之间的相关性

这些数据积累下来，就能回答一个关键问题：哪些信息对模型表现有正向贡献，哪些是噪声。

从"手艺人"到"工程师"

Context Engineering 的兴起，本质上反映了 AI 应用从手工作坊走向工程化生产的必然趋势。

在 Prompt Engineering 时代，AI 应用的质量高度依赖个别"写 Prompt 很厉害的人"。这些人对模型的脾气了如指掌，能写出精妙绝伦的指令，让模型输出质量翻倍。但他们的能力难以复制、难以规模化、难以系统化。

Context Engineering 把这个重心从个人能力转移到了系统设计上。好的上下文管理不依赖于某个天才写了一段绝妙的 Prompt，而是依赖于一套可复用、可迭代、可监控的工程体系。团队里任何一个人都能维护和优化这套系统，不需要特殊天赋。

这就像软件工程从"个人英雄主义"走向"工程化协作"的历程。早期编程靠的是个人天才的灵光一现，现代软件开发靠的是架构设计、代码规范、测试体系、持续集成。Context Engineering 正在把大模型应用带入同样的轨道。

当行业越来越成熟，你会发现一个规律：那些真正跑在生产环境里、每天服务百万用户的 Agent 系统，背后都不是靠一段精妙的 Prompt 在支撑，而是靠一套扎实的上下文工程体系在运转。模型会换代、Prompt 会过时，但好的信息架构设计方法论是持久的。

上下文工程的本质，是承认一个朴素的事实——再聪明的脑袋，也需要好的信息环境才能做出好的判断。这个事实不会因为模型越来越强而改变，反而会因为模型越来越强而被放大：当模型能力不再是瓶颈，上下文质量就成了唯一的胜负手。