Context is all you need：一文彻底搞懂上下文工程（含牛马实战指南）

缘起

最近，“上下文工程（Context Engineering）”这个词汇的热度持续提升，从 Karpathy 发的推文，到 Claude Code 以文件系统为上下文核心，再到 Manus 团队最近的深度实践分享，国内自媒体铺天盖地的分享。给人一种强烈的感觉：上下文工程似乎已经成为 Agent 领域新的“银弹”。

作为AI时代的个体，面对“上下文工程”这个看起来为Agent开发者量身定制的构造Agent的“新技术范式”，觉得那不过是少数人需要掌握的知识，离自己过于遥远。真的是这样吗？

要搞清楚这些问题，我们得先回到原点，把“上下文工程”这个词一分为二：（模型）上下文 与 工程。

01 / 什么是模型上下文？

首先，我们需要了解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产品动态拼接的上下文。无论是哪个部分，其目的都是为了得到更好的模型回复以便可以解决问题。因此我们可以有一个初步的认知：

关于模型上下文，我们先粗浅了解至此。接下来我们要回答另外两个问题：

1. 模型上下文从LLM问世就一直存在，为何在2025年当前这个节点，“模型上下文工程”会突然爆火？

2. 提示词工程已死的论断是真相还是危言耸听？

要回答这两个问题，我们需要从上帝视角回顾一下这两年的AI发展的变化。

02 / 从 L1 到 L3：模型上下文的演进之路

OpenAI 曾为 AI 的发展规划了清晰的路线图，从 L1 级的 ChatBot，到 L2 级的 Reasoner，再到 L3 级的 Agent。这条路，也是一部模型上下文技术不断演进的历史。

L1：静态的提示词工程

ChatGPT 问世之初，对话是其核心能力。彼时，我们与 AI 交互的唯一载体就是 Prompt（提示词）。如何把需求描述得更清晰、更精确，成了提升效果的关键。因此，社区涌现出大量的提示词工程技巧与方法论，例如结构化提示词（LangGPT），就是一套帮助我们规范化表达需求的优秀实践。

这个阶段，我们能感知的上下文主要是用户输入，但如前所述，背后还藏着一些“看不见”的部分。总体而言，模型上下文由三部分构成：

1. 1. SystemPrompt：系统级指令，用于设定 AI 的角色、能力边界和行为准则。它通常由开发者预设，对普通用户不可见。
2. 2. UserPrompt：用户输入的指令、问题和提供的信息。
3. 3. HistoryMessage：历史对话记录，确保 AI 能够理解连续对话的语境。
4. 
   

一个典型的 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层面动态拼接的逻辑。如下图所示：

因此我把这个阶段叫做静态的提示词工程。

L2：推理模型带来的动态提示词工程

时间来到2024年下半年，随着 O1、DeepSeek-R1 等强大的推理模型出现，行业正式迈入了 L2 时代。所谓推理模型是相对于之前的文本模型而言的。

• 文本模型仿照了人类大脑的“快思考”模式，模型直接给出答案。就像我们回答1+1=几的问题时，不需要经过任何复杂的思考。
  
  
• 推理模型则仿照的是人类大脑的“慢思考”模式，模型需要经过一段时间的“思考”过程，再给出答案。就像我们在解一道复杂的数学题一样，需要先拆解步骤，一步步运算，最终才能得到答案。

随着OpenAI的O1模型提出的新的“推理时长”的Scaling Law（扩展原则），在往后的一段时间内模型的推理能力（Reasoning）得到大幅增强，带来的一个显著的变化是：

这个时期的关键变化，是增加了COT思考过程数据作为模型推理的上下文。像O1这样模型产品还支持内置工具（网页搜索、Computer Use、Code Interpreter等）的使用。 很多Agent产品也增加了很多动态上下文的逻辑：

1. 1. Rag Context：通过检索增强生成（RAG）从知识库中获取的、与用户问题相关的背景知识，动态注入到提示词中。
2. 2. Web Search Context：通过接入网页搜索能力，在用户开启网页搜索开关后，Agent会先调用搜索工具完成相关信息的搜集，再拼接到推理上下文中去。以便获取更丰富更实时的信息
3. 3. Attachment Context：用户上传的文件，如 PDF、图片、代码库等，经解析后成为模型可以理解的文本信息。
4. 4. Tool Context：模型内置工具描述和工具执行结果

此时的 Agent 产品，更像是一个封装了特定工具集的“超级助理”，能有限地动态调用工具来丰富上下文，例如查询最新的天气信息或检索网页，读取文件等，再结合COT的思考数据，可以更精准地理解用户的意图，结合这些上下文模型可以得到更为精准和丰富的回答。

L3：动态的上下文工程

时间来到2024年底，随着Claude 3.7等模型在Agentic任务和编程能力上的极大提升，基座模型的 Agentic（智能体）能力实现了质的飞跃。一批如 Cursor、Manus 、Fellou、Claude Code这样的 Agent 如雨后春笋般涌现，Claude Code和Cursor能够自主完成从需求分析到代码实现、再到调试运行的复杂任务。

一个复杂的软件开发任务，可能需要运行数小时，执行成百上千次工具调用。这种全新的Agent工作模式，对模型上下文的管理带来了前所未有的挑战。加上2024年11月份MCP协议的发布和出圈，模型拥有了前所未见的可以使用的标准工具套件，正是这些变革催生了真正的“上下文工程”。 

此时的上下文类型急剧膨胀，变得高度动态和复杂：

1. 1. SystemPrompt
2. 2. UserPrompt
3. 3. HistoryMessage
4. 4. Rag Context
5. 5. Attachment Context
6. 6. [新增] Planning Todolist：模型生成的、用于追踪任务进度的计划列表。
7. 7. [新增] ToolCalls & ToolResults：海量的工具调用及返回结果。
8. 8. [新增] ReAct Result：模型在每一步执行后的观察（Observation）和反思（Thought）。

因为 Agent Loop 的存在，第 6、7、8 项会反复出现，导致上下文内容暴增。随之而来的，是三个核心的工程难题：

1. 1. 窗口溢出：上下文总长度轻易就突破了模型支持的窗口上限。
2. 2. 成本与延迟：海量 Token 带来了推理成本和响应时间的爆炸式增长。
3. 3. 注意力稀释：在庞杂的上下文中，如何组织信息才能让模型精准捕捉到最关键的部分，避免“大海捞针”？

03 / 什么是上下文工程？

至此，我们可以为“上下文工程”下一个相对严谨的定义了。

这里的使用者，可以细分为两类：Agent 产品的最终用户，和 Agent 产品的开发者。

A：面向用户的上下文工程

对于普通用户而言，上下文工程已经从单纯的“写提示词”，演变为“组织和连接上下文”。我们不再仅仅是下达命令的人，更像是为 AI 准备“案头资料”的研究员。

以 Claude Code 为例，假设我们要开发一个复杂的系统，比如一个能自动分析 GitHub 项目健康度的机器人。我们不再是写一个空泛的 Prompt，而是会进行一系列的上下文准备工作：

1. 1. 搜集信息：找到 GitHub API 的最新官方文档，了解如何获取 a. star 历史，b. issue 关闭率，c. PR 合并时间等关键指标。
2. 2. 定义规范：撰写一个 Markdown 文档，清晰定义“项目健康度”的评估标准和打分规则。
3. 3. 提供需求：将原始需求文档、API 文档、评估标准文档，同时提供给 AI。
4. 4. 编排任务：最后，用一个“总括性”的 Prompt 将这些上下文串联起来。
5. 
   

# 这是一个示意性的 Prompt
你是一位资深的软件工程师。请遵循以下步骤，为我开发一个 GitHub 项目健康度分析机器人：

1.  **理解需求**：阅读我上传的《需求文档.md》，明确机器人的核心功能。
2.  **学习 API**：仔细研究《GitHub_API_v4.json》，这是你唯一可以使用的接口。
3.  **遵循标准**：严格按照《健康度评估模型.md》中的规则来计算分数。
4.  **生成方案**：首先，输出一份详细的技术方案文档，包括架构设计、关键函数定义和数据结构。
5.  **编写代码**：待我确认方案后，再开始编写完整的 Python 代码。

在这里，提示词（Prompt）本身变得简洁，其核心作用从“描述需求”转变成了“编排上下文”。

B：面向 Agent 开发者的上下文工程

对于Agent开发者而言，上下文工程的复杂度呈指数级上升。我们不再是简单地把所有信息丢给模型，而是要在 效果、效率、成本 这个“不可能三角”中寻求动态平衡。

这场博弈主要围绕以下几个核心问题展开：

• 效果 (Effectiveness)：
• 信息源：如何获取最全面、精准、新鲜的上下文？（比如，是读取本地旧文档，还是实时爬取网页？或者检索Rag知识库，用户的长期短期记忆该如何生产和消费？）
• 组织方式：如何排列上下文的顺序？是把关键指令放最前还是最后？（即所谓的“开卷考试”与“闭卷考试”模式）
• 裁剪与压缩：当上下文超出窗口时，舍弃哪些信息？是丢弃最早的对话，还是压缩工具调用的中间结果？如何用更少的 Token 表达同样的信息？
• 效率 (Efficiency)：
• 执行策略：Agent 的多个工具调用，哪些可以并行以节省时间，哪些必须串行等待结果？
• 路径优化：如何设计提示词和工具集，引导模型走上解决问题的最短路径，避免不必要的“反思”和“兜圈子”？
• 成本 (Cost)：
• KV Cache：如何设计上下文结构，使其前缀尽可能保持不变，从而最大限度地利用模型的 KV Cache 机制，降低重复计算的成本？
• 信息过滤：如何主动过滤掉无关紧要的上下文（如冗长的 API 返回日志），只保留核心信息，既降低 Token 成本，又不影响最终效果？
• 工具集修剪：在 Agent Loop 的每一轮，是否需要把完整的工具列表都发给模型？还是可以根据当前任务，只提供一个最小可用子集？

这些问题的答案没有定式，需要开发者根据具体的业务场景和模型特性，进行大量的实验和权衡。正如 Manus 团队在其分享中所述，优秀的上下文工程，是现代 AI Agent 产品能够脱颖而出的核心竞争力之一。

04 / 上下文工程祛魅

论点1：提示词工程已死？上下文工程才是未来？

这是最常见也最极端的误导。它错误地将两者对立起来。实际上，通过前文介绍可知，上下文工程（Context Engineering）是提示词工程（Prompt Engineering）的演进和拓展，而非替代。

一个精心准备的上下文，依然需要一个清晰、精准的提示词来引导模型去理解和使用这个上下文。把两者对立，非黑即白，是典型的流量话术。

论点2：上下文工程能瞬间打破模型瓶颈，让推理能力翻倍

这种说法，是将实验室中特定任务的成果，包装成了无所不能的奇迹。现实是，简单粗暴地“灌输”超长上下文，效果往往适得其反。强行加长上下文，不仅会急剧增加计算成本，还可能引入大量无关的“噪音”信息，反而干扰了模型的精准判断。

如第三部分内容所述，上下文工程实践的终极目的是获取必要的、精准的上下文，以最经济、可靠的方式拼接起来给模型进行推理。

对于Agent开发者而言，上下文工程很重要，但也并非可以让端到端效果瞬间翻倍的银弹，依然需要老老实实去做很多苦活累活，譬如构建高质量的知识库，做科学的评估测试反馈闭环。

论点3：零门槛，个人也能靠上下文工程做工业级智能体

这也是一种典型的营销话术，它刻意混淆了“搭建演示（Demo）”和“交付产品”的巨大差异。使用现成的工具，个人确实能快速拼出一个看起来很酷的AI智能体。但从“演示”到真正稳定可靠的“工业级”应用，其间有一道巨大的工程鸿沟。

论点4：上下文工程是普通人弯道超车的机会

这种论调迎合了人们希望走捷径的心理，但现实远比口号复杂。开源框架和各类教程，确实极大地降低了入门门槛，但这不等于降低了成功的门槛。真正的竞争壁垒，从来不是会不会使用某个工具，而是能否在实践中持续优化。

有经验的团队，为了找到一个稳定高效的上下文策略，可能需要反复试验、重构框架，并建立复杂的评测体系来量化效果。这是一场考验数据质量、迭代能力和工程纪律的“耐力赛”，而不是一次投机取巧的“弯道变线”。想凭一个“技巧”就超越别人长期的体系化深耕，既不现实，也风险极高。

05 / 实战：职场牛马如何用好上下文工程？

作为一个AI时代的新牛马，要通过使用AI工具让自己成为领域内的超级个体，学好上下文工程非常有必要。试想这样的画面：

• 当别人还在和碎片化的AI工具模糊表达，抱怨得不到精准可靠的高质量回答时，你用一次问答就得到了你想要的结果；
• 当同事还在抱怨Cursor解不了复杂工程的代码问题，写出一堆一堆屎山时，你用上下文工程的工作流程，让模型变的像一个听话懂你的资深大神，一次次高质量完成需求。

准备工作1：工欲善其事必先利其器

首先我们需要根据自己的日常工作内容和特点，选择一个强大的、可深度协同的AI工具。今天我们可以数出上百个AI助理工具，但理想的选择是能操作本地文件系统的AI助理工具，例如Cursor或已集成文件系统能力的Claude Desktop、Claude Code等。这类工具能让AI完整地“看到”你的工作环境，是实践上下文工程的绝佳平台。

如果你不是工程师，也可以选择具备强大文件上传和Connector连接能力的在线AI助理（如ChatGPT、豆包桌面版）也是不错的起点。

具体工具安装和使用教程不再赘述，相信大家都可以通过AI 搜索搞定。

接下来，我们将针对几个典型的职场角色，提供具体的实践心法与案例作为启发。

准备工作2：认知 / 心态转变

拥抱上下文工程，需要有两个关键的认知转变：

• 把AI当实习生而不是万能工具

• 以文件系统为中心

1. 把AI当实习生而不是万能工具

过去，程序员遇到问题，会把一小段代码或一个错误信息丢给AI，期望它给出一个解决方案。现在，你的角色更像一个项目负责人或架构师，你的核心工作不再是“写代码”，而是“构建和编排让AI能够高效写代码的上下文环境”。你负责提供完整的项目蓝图、规范和物料，AI则负责具体的砌砖工作。

产品经理撰写的文档（PRD、MRD）不再仅仅是写给人类同事看的，更是喂给AI进行加工的“结构化数据源”。 你的角色从单纯的文档创作者，演变为一个“上下文策展人”。你的核心工作是搜集、整理、连接所有与产品相关的信息——用户访谈录音、竞品分析报告、数据后台截图、UI/UX草图、技术可行性分析——并将它们组织成一个逻辑清晰、互相关联的上下文包，然后用一个精准的指令，驱动AI完成高质量的初步产出，如PRD草稿、用户故事、发布会文案等。

市场研究人员和咨询顾问的认知转变在于：从繁重的二手资料搜集、清洗和总结工作中解放出来，转变为一个“研究策略师”。 你的核心价值不再是“写报告”，而是“设计研究框架”和“解读洞察”。你负责定义研究目标，圈定信息源（如指定行业报告、财经新闻网站、社交媒体话题），并构建分析框架。然后，利用AI强大的信息处理能力，进行大规模的信息抓取、聚合、翻译、提炼和初步分析，最终形成报告草稿。你的主要工作，是在AI的草稿基础上进行批判性思考、深度洞察和最终呈现。

2. 以文件系统为中心

过去，我们的注意力分散在各个云端的AI工具上，一会儿用豆包，一会儿用DeepSeek，一会儿又在Cursor或者ChatGPT上。遇到问题Cursor解答不好，就换到其它AI工具上试试。 做市场调研也是，用完ChatGPT的DeepResearch，把结果复制到在线文档里，然后不断修修补补。 

这个过程中用户体验极度的碎片化和割裂，很难想象干一件事情沉淀的上下文分散在各处所带来的管理和组织的成本。而在上下文工程实践中，我主张以本地文件系统为中心，譬如使用Cursor，或者Claude Code。 

它既可以帮你使用各种命令行、MCP工具完成信息搜集、爬虫爬取，需求撰写、架构设计、数据清洗等上下文准备工作。同时，这些过程数据全部以文件的形式保存在你指定的某个目录下。这就拥有了一个非常好的上下文管理基础，之后你就可以可以写一个Prompt来编排这些上下文实现自己的任务目标了。

最为重要的是，像Claude Code或者Cursor这样以文件系统为中心的AI工具，他们的能力边界非常宽泛，他们可以使用操作系统中的命令行工具，互联网几十年的沉淀都可以为它所用，相比云端AI工具提供的有限的工具，要强大的多的多。

譬如，如果你碰巧本地有一堆视频文件需要转换格式并完成封面图抽帧，你只需要在Claude Code中把这个目录设置为工作目录，一句话就可以完成了。

案例（软件工程师）：用Claude Code重构遗留模块

• 任务场景：你需要重构一个名为 data_processor.py 的陈旧模块。目标是：
• 1）解决其中一个由性能分析报告指出的性能瓶颈；
• 2）严格遵循团队的 coding_style.md 编码规范；
• 3）增加一个在 feature_spec.md 中定义的新功能。
• 上下文准备 (Context Preparation)：

1. 工作区搭建：在Claude Code或Cursor中，直接打开包含这个模块的整个项目文件夹。
2. 核心文件：将 data_processor.py 文件打开在编辑区。
3. 关键参考：将 coding_style.md（编码规范）、profiling_report.txt（性能报告）和 feature_spec.md（新功能需求文档）这三个文件也一并@在AI的上下文中打开。

• 指令编排 (The "Orchestrator" Prompt)：
你是一位资深的Python软件工程师，擅长代码重构和性能优化。你的任务是重构我当前打开的 `data_processor.py` 文件。

请严格遵循以下步骤：
1.  **分析瓶颈**：首先，仔细阅读 `profiling_report.txt` 的内容，定位并理解性能瓶颈的根本原因。
2.  **代码重构**：基于你的分析，对 `data_processor.py` 进行重构以解决性能问题。在整个过程中，你必须严格遵守 `coding_style.md` 中定义的所有编码规范。
3.  **实现新功能**：在完成重构和优化后，根据 `feature_spec.md` 文档中的描述，为模块添加新的功能。
4.  **交付**：请直接在 `data_processor.py` 文件中进行修改，并使用注释简要说明你重构的关键部分和新增功能的代码逻辑。



• 效果：通过这种方式，AI不再是盲人摸象。它拥有了和你几乎同等的信息视野：知道目标、知道约束、知道现状。产出的代码质量和任务完成度，将远超碎片化提问。




案例（产品经理）：用AI草拟新功能规格与FAQ

• 任务场景：为即将上线的“第三方账号一键登录”功能，撰写一份面向用户的FAQ文档，和一份给开发团队的技术实现规格（Technical Spec）草案。
• 上下文准备 (Context Preparation)：
1. 核心需求：social_login_prd.md（你撰写的功能需求文档）。
2. 市场洞察：competitor_analysis.xlsx（包含主流APP该功能截图和流程分析的表格）。
3. 用户声音：user_feedback.txt（整理了用户关于注册登录流程的抱怨和疑问）。
4. 技术约束：oauth_docs.pdf（包含了微信、Apple等开放平台官方OAuth2.0接入文档的PDF）。
• 指令编排 (The "Orchestrator" Prompt)：
你是一位顶尖的互联网产品专家，拥有丰富的社交功能设计经验。

基于我提供的四个文件，请完成以下两项任务：
1.  **撰写用户FAQ**：结合 `social_login_prd.md` 的功能定义、`competitor_analysis.xlsx` 的市场通用做法，以及 `user_feedback.txt` 中用户的真实困惑，为“一键登录”功能撰写一份清晰、友好的FAQ文档。请覆盖用户可能关心的所有问题，例如安全性、数据隐私、如何解绑等。
2.  **草拟技术规格**：仔细阅读 `oauth_docs.pdf`，理解不同平台的技术实现差异。然后，为我们的研发团队撰写一份技术规格草案。草案需要明确定义前端交互流程、需要请求的API接口、成功/失败的回调处理逻辑以及关键的数据字段。




打开场景想象空间

• 用户故事批量生成：上传3-5份深度用户访t谈的录音转录稿，让AI基于这些一手资料，提炼并生成符合标准格式（As a... I want to... so that...）的用户故事卡片墙。
• A/B测试方案设计：提供某个功能页面的用户行为数据报告、当前的UI截图和原始PRD，要求AI设计3个不同的A/B测试方案，以提升用户转化率为目标，并说明每个方案的假设、变量和预期收益。
• 产品发布文案矩阵：提供PRD、产品Slogan和品牌语调指南（Tone of Voice Guide），让AI为新功能生成一套适用于不同渠道（如应用商店、公众号、微博、小红书）的宣发文案。




案例（市场研究）：用AI生成行业竞品分析报告

• 任务场景：为公司新进入的“企业级项目管理SaaS”赛道，撰写一份详尽的竞品分析报告。
• 上下文准备 (Context Preparation)：
1. 竞品清单：competitors_list.txt（包含Asana, Monday.com, Trello等主要竞品名单和官网链接）。
2. 行业报告：上传3份最新的权威行业研究报告PDF（如Gartner魔力象限、艾瑞咨询报告等）。
3. 用户评论：customer_reviews.csv（从G2、Capterra等平台抓取的上千条真实用户评论数据）。
4. 分析框架：analysis_framework.md（你预先定义好的分析维度，如产品功能、定价策略、市场声量、目标客群、优缺点等）。
• 指令编排 (The "Orchestrator" Prompt)：
你是一位资深的市场战略分析师，正在为我准备一份关于项目管理SaaS市场的竞品分析报告。

你的工作流程如下：
1.  **学习框架**：首先，完全理解我在 `analysis_framework.md` 中定义的报告结构和分析维度。这是你最终输出的格式标准。
2.  **信息源学习**：深入阅读我上传的3份行业报告PDF，并访问 `competitors_list.txt` 中的每个竞品官网（如果AI具备联网能力），以建立对市场的宏观认知。
3.  **数据分析**：对 `customer_reviews.csv` 文件进行处理。你需要为每个竞品提炼出用户提及最多的优点和缺点，并进行情感倾向分析。
4.  **生成报告**：最后，严格按照 `analysis_framework.md` 的框架，将你从所有信息源中获取和分析的内容，整合成一份结构化的分析报告。报告需以Markdown格式输出。




打开场景想象空间

• 舆情监控与趋势发现：设定好关键词和信息源（如特定新闻网站、Twitter话题），让AI持续监控，并每日/每周自动生成舆情摘要报告，识别新出现的趋势、关键事件和意见领袖。
• 用户画像（Persona）构建：上传大量的用户调研问卷数据（已脱敏）和访谈记录，让AI基于数据聚类，自动生成3-5个详细的用户画像，包含人口统计学特征、核心需求、痛点和使用场景。
• 自动化SWOT分析：提供一家上市公司的年报、最新的季度财报、以及过去一年的相关新闻报道，让AI自动生成一份关于该公司的SWOT（优势、劣势、机会、威胁）分析报告。




🌟

上述介绍的方法论和实践案例，完全可以赋能到各种岗位，篇幅所限，不再赘述，大家可以自行脑补和发挥




06 / MCP：对模型上下文的终极抽象

本文讲的是上下文工程，文章的最后我想再回到Anthropic发布的MCP协议，聊一聊MCP协议和上下文工程的关系。AI技术的发展并不是孤立的，每一个产品爆火，技术的出圈都是相互关联和作用的结果。




聊完上下文工程，我们再回过头来看 MCP（模型上下文协议），便会有一种豁然开朗的感觉。MCP 协议的设计，并非凭空创造，而是对上述所有复杂性的深刻洞察与高度抽象。它将纷繁复杂的模型上下文，精炼地拆解为三个核心概念：

1. 1. Prompt：指令。
2. 2. Tools：工具。
3. 3. Resources：资源。

这三个概念，精准地映射了上下文工程所要处理的全部内容：

• Prompt：这不仅是用户的单次提问，更是整个 Agent 的灵魂所在。它包含了 SystemPrompt、核心任务指令、以及在 Agent Loop 中动态生成的 ReAct 思考链 和 Planning 计划。它是驱动 Agent 思考和行动的核心引擎。
• Tools：这囊括了模型可以调用的所有外部能力，以及这些工具的执行结果（ToolCalls & ToolResults）。在 MCP 的设计中，工具是“活”的，可以被动态地提供、更新和组合，完美地解决了 L3 Agent 对动态工具集的需求。
• Resources：这对应了所有相对静态的、供模型“阅读”和“参考”的背景信息。无论是用户上传的 PDF、代码库（Attachment Context），还是通过 RAG 检索到的知识片段（Rag Context），都可以被规整为一种标准的“资源”形态，供 Prompt 和 Tool 使用。




MCP 协议的精髓，在于它提供了一套标准化的语言，来描述和组织 L3 级别 Agent 所需的、高度动态和异构的上下文。它将开发者从繁琐的、面向特定模型的上下文拼接工作中解放出来，让他们可以专注于更高层次的 Agent 逻辑和策略设计。




我们可以这样理解：如果说上下文工程是“烹饪”的艺术，那么 MCP 就是那套标准化的、符合人体工学的现代厨具。它让“烹饪”过程本身变得更加模块化、可预测和可交换。







结语：

模型是地基，代码是砖瓦。

而上下文，是那张指引所有工匠的、不断演进的建筑蓝图。

从简单的提示词，到复杂的 Agent Loop，我们对“上下文”的认知在不断深化。它不再是静态的输入，而是一个动态的、与模型共舞的生命体。

上下文工程，并非遥不可及的屠龙之术，而是我们驾驭这头“AI巨兽”的缰绳。它要求我们从“对话者”转变为“引导者”，从“使用者”转变为“设计者”。

而 MCP 协议，则为这场宏大的工程，铺设了坚实的第一块基石。它定义了标准，降低了熵增，让知识的流动与组合，有了清晰的脉络。

本质上，我们正在从“与模型对话”，走向“为模型构建世界”。

这座桥梁，连接着“知”与“行”。

路，才刚刚开始。