首先，我们需要了解LLM推理的本质，其本质是对一段输入的文本序列进行续写。理解这个本质至关重要，因为一切的模型上下文工程都是围绕如何构建这个输入序列来工作的。
#输入序列
你是谁？
#模型输出序列
我是LLM。
这是一个非常简单的例子，但说明了一个基本的认知：
输入序列 = 模型上下文
普通人日常接触不到模型底层的工作机制，更多的是使用诸如ChatGPT、DeepSeek、元宝、豆包这些AI助理产品。作为用户（User）我们可以干预的模型输入序列叫UserPrompt。
但当我们在这些AI助理产品中提出一个问题时，这个UserPrompt并不是模型底层的输入序列的全部。这些产品就像是一个黑盒的上下文加工厂，会对你的UserPrompt进行各种拼接最终才会把一个比UserPrompt复杂的多的多的完整的输入序列给到模型进行推理。
例如：
# 你输入的
请你扮演一位资深的投资分析师，基于我上传的这份 PDF 财报，总结其核心财务亮点，并评估其潜在的投资风险
# 拼接后给到模型推理的
<|System|>你是一个有用的助理....</|System|>
<|User|>
<file-context>
上传的文件清单：
-文件名：xxx财报.pdf
-文件内容：xxxxx
</file-context>
请你扮演一位资深的投资分析师，基于我上传的这份 PDF 财报，总结其核心财务亮点，并评估其潜在的投资风险
</|User|>到这里，我们知道了所谓模型上下文，不仅仅是用户视角的输入，而是更复杂的存在。因此我们需要迭代一下上面的认知公式：
模型底层的输入序列 = 模型上下文
这个上下文构建范式天然把模型上下文分割为两个部分：用户输入上下文、Agent产品动态拼接的上下文。无论是哪个部分，其目的都是为了得到更好的模型回复以便可以解决问题。因此我们可以有一个初步的认知：
模型上下文直接影响模型推理效果
模型上下文普通用户和Agent产品开发者皆可干预
关于模型上下文，我们先粗浅了解至此。接下来我们要回答另外两个问题：
模型上下文从LLM问世就一直存在，为何在2025年当前这个节点，“模型上下文工程”会突然爆火？
提示词工程已死的论断是真相还是危言耸听？
要回答这两个问题，我们需要从上帝视角回顾一下这两年的AI发展的变化。
OpenAI 曾为 AI 的发展规划了清晰的路线图，从 L1 级的 ChatBot，到 L2 级的 Reasoner，再到 L3 级的 Agent。这条路，也是一部模型上下文技术不断演进的历史。
ChatGPT 问世之初，对话是其核心能力。彼时，我们与 AI 交互的唯一载体就是 Prompt（提示词）。如何把需求描述得更清晰、更精确，成了提升效果的关键。因此，社区涌现出大量的提示词工程技巧与方法论，例如结构化提示词（LangGPT），就是一套帮助我们规范化表达需求的优秀实践。
这个阶段，我们能感知的上下文主要是用户输入，但如前所述，背后还藏着一些“看不见”的部分。总体而言，模型上下文由三部分构成：
一个典型的 OpenAI ChatCompletions API 调用，清晰地揭示了这种结构：
import openai
client = openai.OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "你是一位专业的软件架构师。"},
{"role": "user", "content": "我需要设计一个高并发的秒杀系统，有哪些关键技术点？"},
{"role": "assistant", "content": "当然。一个高并发秒杀系统需要关注几个核心要点：前端静态化、流量削峰、库存预扣减和数据一致性。"},
{"role": "user", "content": "能具体讲讲流量削峰的实现方案吗？"}
]
)
print(response.choices[0].message.content)这个阶段的上下文管理相对静态，每一次交互都是对这个messages列表的简单追加。
这个阶段，所谓的提示词工程针对不同的群体干预的上下文内容不同，普通用户可以干预的上下文主要是UserPrompt和可上传的文档附件，对于Agent开发者而言，干预的就是SystemPrompt，并无太多需要再Agent层面动态拼接的逻辑。如下图所示：
因此我把这个阶段叫做静态的提示词工程。
注：
这个阶段还有另外一个动态上下文技术值得一提就是RAG，为了降低认知负担，不再详述。
此外，从时间上看，FuncitonCalling API最早出现在这个阶段，是Agent工具调用技术的最早实现方案。但由于L1阶段模型能力还不够强，Function Calling的可用率不高，基座模型厂商也没有重点优化这块的能力，因此并没有出现类似于Manus、Lovart这样的现象级的Agent产品。
时间来到2024年下半年，随着 O1、DeepSeek-R1 等强大的推理模型出现，行业正式迈入了 L2 时代。所谓推理模型是相对于之前的文本模型而言的。
随着OpenAI的O1模型提出的新的“推理时长”的Scaling Law（扩展原则），在往后的一段时间内模型的推理能力（Reasoning）得到大幅增强，带来的一个显著的变化是：
许多在 L1 阶段奉为圭臬的提示词技巧，如复杂的角色扮演、Few-shot 示例，逐渐被更底层的 CoT（Chain-of-Thought）能力所内化和取代。
这个时期的关键变化，是增加了COT思考过程数据作为模型推理的上下文。像O1这样模型产品还支持内置工具（网页搜索、Computer Use、Code Interpreter等）的使用。 很多Agent产品也增加了很多动态上下文的逻辑：
此时的 Agent 产品，更像是一个封装了特定工具集的“超级助理”，能有限地动态调用工具来丰富上下文，例如查询最新的天气信息或检索网页，读取文件等，再结合COT的思考数据，可以更精准地理解用户的意图，结合这些上下文模型可以得到更为精准和丰富的回答。
这个阶段的用户输入上下文并没有太大的变化，甚至因为推理模型的特性，输入变得更为简洁。
而Agent层面因为模型工具调用能力和推理能力的提升，可以适应更为复杂的任务，所以Agent后台的上下文获取和拼接逻辑增加了许多动态的逻辑，但因为工具还仅限于有限的几个通用内置工具，因此复杂度处于可控范围内，所以这个阶段我把它叫做动态提示词工程。
时间来到2024年底，随着Claude 3.7等模型在Agentic任务和编程能力上的极大提升，基座模型的 Agentic（智能体）能力实现了质的飞跃。一批如 Cursor、Manus、Fellou、Claude Code这样的 Agent 如雨后春笋般涌现，Claude Code和Cursor能够自主完成从需求分析到代码实现、再到调试运行的复杂任务。
L3 阶段的范式核心是一个Agent Loop：模型进行规划、执行工具、观察结果、反思修正，循环往复，直至最终目标达成。
一个复杂的软件开发任务，可能需要运行数小时，执行成百上千次工具调用。这种全新的Agent工作模式，对模型上下文的管理带来了前所未有的挑战。加上2024年11月份MCP协议的发布和出圈，模型拥有了前所未见的可以使用的标准工具套件，正是这些变革催生了真正的“上下文工程”。
此时的上下文类型急剧膨胀，变得高度动态和复杂：
因为 Agent Loop 的存在，第 6、7、8 项会反复出现，导致上下文内容暴增。随之而来的，是三个核心的工程难题：
至此，我们可以为“上下文工程”下一个相对严谨的定义了。
所谓上下文工程，其核心本质，是在模型的输入端进行一系列精巧的组织、筛选、压缩和编排，以干预和引导模型的思考路径与输出结果，从而高效、经济、精准地达成使用者目标的方法论与技术实践的总和。
这里的使用者，可以细分为两类：Agent 产品的最终用户，和Agent 产品的开发者。
对于普通用户而言，上下文工程已经从单纯的“写提示词”，演变为“组织和连接上下文”。我们不再仅仅是下达命令的人，更像是为 AI 准备“案头资料”的研究员。
以 Claude Code 为例，假设我们要开发一个复杂的系统，比如一个能自动分析 GitHub 项目健康度的机器人。我们不再是写一个空泛的 Prompt，而是会进行一系列的上下文准备工作：
# 这是一个示意性的 Prompt
你是一位资深的软件工程师。请遵循以下步骤，为我开发一个 GitHub 项目健康度分析机器人：
1. **理解需求**：阅读我上传的《需求文档.md》，明确机器人的核心功能。
2. **学习 API**：仔细研究《GitHub_API_v4.json》，这是你唯一可以使用的接口。
3. **遵循标准**：严格按照《健康度评估模型.md》中的规则来计算分数。
4. **生成方案**：首先，输出一份详细的技术方案文档，包括架构设计、关键函数定义和数据结构。
5. **编写代码**：待我确认方案后，再开始编写完整的 Python 代码。在这里，提示词（Prompt）本身变得简洁，其核心作用从“描述需求”转变成了“编排上下文”。
面向开发者的上下文工程，是一场在 Token 限制下，与模型注意力和推理成本博弈的艺术。
对于Agent开发者而言，上下文工程的复杂度呈指数级上升。我们不再是简单地把所有信息丢给模型，而是要在效果、效率、成本这个“不可能三角”中寻求动态平衡。
这场博弈主要围绕以下几个核心问题展开：
这些问题的答案没有定式，需要开发者根据具体的业务场景和模型特性，进行大量的实验和权衡。正如 Manus 团队在其分享中所述，优秀的上下文工程，是现代 AI Agent 产品能够脱颖而出的核心竞争力之一。
这是最常见也最极端的误导。它错误地将两者对立起来。实际上，通过前文介绍可知，上下文工程（Context Engineering）是提示词工程（Prompt Engineering）的演进和拓展，而非替代。
一个精心准备的上下文，依然需要一个清晰、精准的提示词来引导模型去理解和使用这个上下文。把两者对立，非黑即白，是典型的流量话术。
真正的情况是：
提示词工程依然重要，只是仅仅优化提示词边际收益已经越来越低了，Agent时代要继续优化效果，上下文工程才是一个ROI更高的事情。
这种说法，是将实验室中特定任务的成果，包装成了无所不能的奇迹。现实是，简单粗暴地“灌输”超长上下文，效果往往适得其反。强行加长上下文，不仅会急剧增加计算成本，还可能引入大量无关的“噪音”信息，反而干扰了模型的精准判断。
如第三部分内容所述，上下文工程实践的终极目的是获取必要的、精准的上下文，以最经济、可靠的方式拼接起来给模型进行推理。
对于Agent开发者而言，上下文工程很重要，但也并非可以让端到端效果瞬间翻倍的银弹，依然需要老老实实去做很多苦活累活，譬如构建高质量的知识库，做科学的评估测试反馈闭环。
真正的情况是：
对于普通用户而言，如果上下文工程实践掌握得法，相较于此前蹩脚的提示词工程能力，在使用诸如Claude Code这样强大的AI Agent时，从体感上是很容易有效果翻倍，碾压之前AI工具的效果的。
这也是一种典型的营销话术，它刻意混淆了“搭建演示（Demo）”和“交付产品”的巨大差异。使用现成的工具，个人确实能快速拼出一个看起来很酷的AI智能体。但从“演示”到真正稳定可靠的“工业级”应用，其间有一道巨大的工程鸿沟。
真正的情况是：
一个工业级系统，需要有稳健的数据处理流程、严谨可靠优雅的前端交互体验、高效的向量检索策略、持续的服务监控与评估体系。一个因上下文管理不善而动辄“精神错乱”的智能体，是完全无法在生产环境中稳定服务的。人人都能快速入门，但要打造出专业产品，背后依然需要系统化的工程能力和团队的持续护航。
这种论调迎合了人们希望走捷径的心理，但现实远比口号复杂。开源框架和各类教程，确实极大地降低了入门门槛，但这不等于降低了成功的门槛。真正的竞争壁垒，从来不是会不会使用某个工具，而是能否在实践中持续优化。
有经验的团队，为了找到一个稳定高效的上下文策略，可能需要反复试验、重构框架，并建立复杂的评测体系来量化效果。这是一场考验数据质量、迭代能力和工程纪律的“耐力赛”，而不是一次投机取巧的“弯道变线”。想凭一个“技巧”就超越别人长期的体系化深耕，既不现实，也风险极高。
作为一个AI时代的新牛马，要通过使用AI工具让自己成为领域内的超级个体，学好上下文工程非常有必要。试想这样的画面：
首先我们需要根据自己的日常工作内容和特点，选择一个强大的、可深度协同的AI工具。今天我们可以数出上百个AI助理工具，但理想的选择是能操作本地文件系统的AI助理工具，例如Cursor或已集成文件系统能力的Claude Desktop、Claude Code等。这类工具能让AI完整地“看到”你的工作环境，是实践上下文工程的绝佳平台。
如果你不是工程师，也可以选择具备强大文件上传和Connector连接能力的在线AI助理（如ChatGPT、豆包桌面版）也是不错的起点。
具体工具安装和使用教程不再赘述，相信大家都可以通过AI 搜索搞定。
接下来，我们将针对几个典型的职场角色，提供具体的实践心法与案例作为启发。
拥抱上下文工程，需要有两个关键的认知转变：
把AI当实习生而不是万能工具
以文件系统为中心
过去，程序员遇到问题，会把一小段代码或一个错误信息丢给AI，期望它给出一个解决方案。现在，你的角色更像一个项目负责人或架构师，你的核心工作不再是“写代码”，而是“构建和编排让AI能够高效写代码的上下文环境”。你负责提供完整的项目蓝图、规范和物料，AI则负责具体的砌砖工作。
产品经理撰写的文档（PRD、MRD）不再仅仅是写给人类同事看的，更是喂给AI进行加工的“结构化数据源”。你的角色从单纯的文档创作者，演变为一个“上下文策展人”。你的核心工作是搜集、整理、连接所有与产品相关的信息——用户访谈录音、竞品分析报告、数据后台截图、UI/UX草图、技术可行性分析——并将它们组织成一个逻辑清晰、互相关联的上下文包，然后用一个精准的指令，驱动AI完成高质量的初步产出，如PRD草稿、用户故事、发布会文案等。
市场研究人员和咨询顾问的认知转变在于：从繁重的二手资料搜集、清洗和总结工作中解放出来，转变为一个“研究策略师”。你的核心价值不再是“写报告”，而是“设计研究框架”和“解读洞察”。你负责定义研究目标，圈定信息源（如指定行业报告、财经新闻网站、社交媒体话题），并构建分析框架。然后，利用AI强大的信息处理能力，进行大规模的信息抓取、聚合、翻译、提炼和初步分析，最终形成报告草稿。你的主要工作，是在AI的草稿基础上进行批判性思考、深度洞察和最终呈现。
过去，我们的注意力分散在各个云端的AI工具上，一会儿用豆包，一会儿用DeepSeek，一会儿又在Cursor或者ChatGPT上。遇到问题Cursor解答不好，就换到其它AI工具上试试。 做市场调研也是，用完ChatGPT的DeepResearch，把结果复制到在线文档里，然后不断修修补补。
这个过程中用户体验极度的碎片化和割裂，很难想象干一件事情沉淀的上下文分散在各处所带来的管理和组织的成本。而在上下文工程实践中，我主张以本地文件系统为中心，譬如使用Cursor，或者Claude Code。
它既可以帮你使用各种命令行、MCP工具完成信息搜集、爬虫爬取，需求撰写、架构设计、数据清洗等上下文准备工作。同时，这些过程数据全部以文件的形式保存在你指定的某个目录下。这就拥有了一个非常好的上下文管理基础，之后你就可以可以写一个Prompt来编排这些上下文实现自己的任务目标了。
最为重要的是，像Claude Code或者Cursor这样以文件系统为中心的AI工具，他们的能力边界非常宽泛，他们可以使用操作系统中的命令行工具，互联网几十年的沉淀都可以为它所用，相比云端AI工具提供的有限的工具，要强大的多的多。
譬如，如果你碰巧本地有一堆视频文件需要转换格式并完成封面图抽帧，你只需要在Claude Code中把这个目录设置为工作目录，一句话就可以完成了。
你是一位资深的Python软件工程师，擅长代码重构和性能优化。你的任务是重构我当前打开的 `data_processor.py` 文件。
请严格遵循以下步骤：
1. **分析瓶颈**：首先，仔细阅读 `profiling_report.txt` 的内容，定位并理解性能瓶颈的根本原因。
2. **代码重构**：基于你的分析，对 `data_processor.py` 进行重构以解决性能问题。在整个过程中，你必须严格遵守 `coding_style.md` 中定义的所有编码规范。
3. **实现新功能**：在完成重构和优化后，根据 `feature_spec.md` 文档中的描述，为模块添加新的功能。
4. **交付**：请直接在 `data_processor.py` 文件中进行修改，并使用注释简要说明你重构的关键部分和新增功能的代码逻辑。你是一位顶尖的互联网产品专家，拥有丰富的社交功能设计经验。
基于我提供的四个文件，请完成以下两项任务：
1. **撰写用户FAQ**：结合 `social_login_prd.md` 的功能定义、`competitor_analysis.xlsx` 的市场通用做法，以及 `user_feedback.txt` 中用户的真实困惑，为“一键登录”功能撰写一份清晰、友好的FAQ文档。请覆盖用户可能关心的所有问题，例如安全性、数据隐私、如何解绑等。
2. **草拟技术规格**：仔细阅读 `oauth_docs.pdf`，理解不同平台的技术实现差异。然后，为我们的研发团队撰写一份技术规格草案。草案需要明确定义前端交互流程、需要请求的API接口、成功/失败的回调处理逻辑以及关键的数据字段。打开场景想象空间
你是一位资深的市场战略分析师，正在为我准备一份关于项目管理SaaS市场的竞品分析报告。
你的工作流程如下：
1. **学习框架**：首先，完全理解我在 `analysis_framework.md` 中定义的报告结构和分析维度。这是你最终输出的格式标准。
2. **信息源学习**：深入阅读我上传的3份行业报告PDF，并访问 `competitors_list.txt` 中的每个竞品官网（如果AI具备联网能力），以建立对市场的宏观认知。
3. **数据分析**：对 `customer_reviews.csv` 文件进行处理。你需要为每个竞品提炼出用户提及最多的优点和缺点，并进行情感倾向分析。
4. **生成报告**：最后，严格按照 `analysis_framework.md` 的框架，将你从所有信息源中获取和分析的内容，整合成一份结构化的分析报告。报告需以Markdown格式输出。打开场景想象空间
上述介绍的方法论和实践案例，完全可以赋能到各种岗位，篇幅所限，不再赘述，大家可以自行脑补和发挥
本文讲的是上下文工程，文章的最后我想再回到Anthropic发布的MCP协议，聊一聊MCP协议和上下文工程的关系。AI技术的发展并不是孤立的，每一个产品爆火，技术的出圈都是相互关联和作用的结果。
聊完上下文工程，我们再回过头来看 MCP（模型上下文协议），便会有一种豁然开朗的感觉。MCP 协议的设计，并非凭空创造，而是对上述所有复杂性的深刻洞察与高度抽象。它将纷繁复杂的模型上下文，精炼地拆解为三个核心概念：
这三个概念，精准地映射了上下文工程所要处理的全部内容：
MCP 协议的精髓，在于它提供了一套标准化的语言，来描述和组织 L3 级别 Agent 所需的、高度动态和异构的上下文。它将开发者从繁琐的、面向特定模型的上下文拼接工作中解放出来，让他们可以专注于更高层次的 Agent 逻辑和策略设计。
我们可以这样理解：如果说上下文工程是“烹饪”的艺术，那么 MCP 就是那套标准化的、符合人体工学的现代厨具。它让“烹饪”过程本身变得更加模块化、可预测和可交换。
模型是地基，代码是砖瓦。
而上下文，是那张指引所有工匠的、不断演进的建筑蓝图。
从简单的提示词，到复杂的 Agent Loop，我们对“上下文”的认知在不断深化。它不再是静态的输入，而是一个动态的、与模型共舞的生命体。
上下文工程，并非遥不可及的屠龙之术，而是我们驾驭这头“AI巨兽”的缰绳。它要求我们从“对话者”转变为“引导者”，从“使用者”转变为“设计者”。
而 MCP 协议，则为这场宏大的工程，铺设了坚实的第一块基石。它定义了标准，降低了熵增，让知识的流动与组合，有了清晰的脉络。
本质上，我们正在从“与模型对话”，走向“为模型构建世界”。
这座桥梁，连接着“知”与“行”。
路，才刚刚开始。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |