博客提示词写得好已不再是智能体成败的关键。Anthropic 官方指出上下文管理才是首要失败原因。本文拆解上下文工程三层架构、六种失败模式，以及从 Demo 到生产的实战路径。
Anthropic 工程团队在 2025 年 9 月发表的指南中明确指出：智能体失败的首要原因不是提示词写得不好，而是上下文管理失败——信息太多模型忽略关键指令，信息太少无法正确决策[2]。2026 年，上下文工程（Context Engineering）正在成为区分"能跑 Demo"和"能在生产环境稳定运行"的那道分水岭。
过去两年，行业几乎把所有精力都投在提示词上。写 system prompt 像在雕花——角色定义、输出格式、边界约束、Few-shot 示例，越写越长。2024 年甚至有团队把 system prompt 写到了 4000 token，把能想到的 edge case 全部硬编码进去。
这条路走到 2025 年下半年就撞了墙。原因很简单：
一位在 LangGraph 上构建了三年多模块系统的工程师总结得很直接："提示词没问题，模型也没问题，Jupyter notebook 里跑得干干净净。一到生产环境，系统在步骤之间崩溃——不是因为某个步骤推理失败，而是上下文在步骤之间丢失了。"[3]
两个概念的边界经常被混淆。核心差异在于：提示词工程关注"怎么说"，上下文工程关注"基于什么来思考和行动"。下面这张表把关键维度拆开：
| 维度 | 提示词工程 | 上下文工程 |
|---|---|---|
| 核心对象 | 一段指令文本 | 整个上下文状态 |
| 关注重点 | 指令怎么写 | 信息怎么流 |
| 适用场景 | 单轮、短任务 | 多轮、长任务、工具调用 |
| 主要手段 | system prompt、few-shot | 检索、压缩、记忆、状态管理、工具结果筛选 |
| 典型失败模式 | 提示词模糊 | 上下文污染、状态丢失、信息过载、历史失真 |
| 工程本质 | 语言学设计 | 系统架构设计 |
Anthropic 工程博客把两者的关系定位得很清楚：上下文工程是提示词工程的"自然演进"。提示词只是上下文的一部分——真正决定智能体表现的，是系统指令、工具定义、检索结果、历史消息、任务状态、失败反馈共同构成的"上下文拼图"。[2]
在多次生产部署的复盘里，一个反复出现的发现是：大多数团队对"上下文"的理解还停留在聊天记录层面。实际上，生产级系统的上下文至少包含三个层次[3]：
第一层：持久上下文——用户目标、领域约束、合规规则、长期记忆。这些信息在系统初始化时注入，贯穿整个任务生命周期，不应该被任何中间步骤丢弃。一个医疗场景的智能体如果把患者病史在第三个工具调用后就从上下文里清掉了，后面的诊断推理就是在盲猜。
第二层：时效上下文——检索到的文档、本次工具调用的返回结果、上一轮推理的结论。这是 RAG 真正发挥作用的地方——但难点不在"检索"，而在"决定哪些检索结果以什么粒度、什么格式继续往下传"。RAG 作为共享记忆层的设计思路，在多模块协作场景中尤为关键，我们在多智能体协作实战中有更详细的拆解。
第三层：瞬态上下文——原始 API 响应体、冗余的中间推理过程、上一轮的工具调用日志。这些信息在当前步骤有用，但应该被果断丢弃。每一个不必要的 token 都在和必要的 token 争夺有限的注意力预算。
这套分层思路在腾讯云开发者社区的一篇 2026 年 5 月实战文章中也得到了印证。该文提出的"文件即状态"架构，用 5 个文件（run_state.json、last_success.json、dedupe_index.json、execution_log.jsonl、handoff.md）实现了三层上下文的精确管控，在不引入重型编排框架的前提下，将多步任务失败率从 40-60% 降到可控范围[4]。
基于行业一线的实战复盘，生产环境的表现不佳，绝大多数可以追溯到以下六种上下文管理失误[5]：
这六种模式有一个共同特征：它们都不是"模型能力不够"导致的。换一个更强的模型并不能解决上下文管理的问题——因为问题的本质是信息架构，不是推理深度。我们在之前的工程化分析中也得出过同样的结论：95% 的失败率，问题不在模型而在工程。
Gartner 预测到 2027 年将有 40% 的智能体类 AI 项目被取消[1]。这不是因为 AI 没用，而是因为很多团队低估了让自主系统在生产环境稳定运行所需的工程投入。一个被行业反复引用的"冰山模型"指出：构建一个真正可用的智能体，90% 的工作是软件工程，仅 10% 是 AI 技术。
第一块拼图：状态机而非脚本。把每一步执行看作状态迁移，而不是线性脚本。每个节点明确声明它需要读什么状态、产出什么状态。这样下游模块不需要"猜"上游发生了什么——状态文件里有明确答案。Towards AI 那位工程师在重构金融研究系统时的关键改动，不是改任何 prompt，而是重新设计了状态结构定义[3]。
第二块拼图：上下文路由而非广播。不要把所有上下文发给所有执行模块。代码模块不需要看到医学文献检索模块的原始输出。摘要模块不需要看到数据抓取模块的 API 原始响应。按角色路由上下文——就像你不会在每次会议前把全公司的人都叫来旁听。
第三块拼图：可观测性不只是日志。生产级系统需要追踪的不是"这个函数有没有报错"，而是"这一轮推理时，模型实际看到了什么上下文"。当前头部厂商已经在推动基于 OpenTelemetry 的生成式 AI 可观测性标准[1]。当你的系统在 step 6 崩溃时，你需要能回溯到 step 4 的上下文快照——否则 debug 就是盲人摸象。
问：上下文工程和提示词工程到底是什么关系？
提示词是上下文的一个子集。Anthropic 的官方定位是"上下文工程是提示词工程的自然演进"——单轮任务时代提示词是主角，多轮多工具 Agent 时代上下文管理才是主战场。
问：小团队现在开始做上下文工程需要投入多少？
不一定需要重型框架。腾讯云社区那套"文件即状态"方案，7 天即可跑通 MVP，核心开销是设计状态文件和验收标准，而非引入额外的中间件。
问：上下文工程能解决智能体幻觉问题吗？
能缓解，不能根治。幻觉是大模型概率输出特性的固有表现。但上下文工程可以减少"因为信息缺失或信息错误导致的幻觉"——那种明明看到了正确信息但因为上下文污染而忽略掉的典型场景。
问：我的系统在 Demo 里表现很好，一到生产就崩，最可能的原因是什么？
90% 的概率是上下文在步骤之间丢失或被污染。检查你的多步任务中，step N 看到的上下文是否真的包含了 step N-1 的关键决策结果。如果交接机制是隐式的（靠模型自己记住），大概率就是这里出问题。
问：MCP 协议跟上下文工程有什么关系？
MCP（模型上下文协议）本质上是上下文工程在工具层的标准化实践——它定义了一套统一的方式让模型发现工具、理解工具参数、消费工具返回结果。截至 2025 年底，已有超过 10,000 个公开 MCP 服务端部署，正在成为上下文工程的基础设施层[3]。我们在MCP 协议 2026 企业落地指南中有更详细的技术选型分析。