AI应用开发核心：上下文工程构建指南，从入门到精通，建议收藏！

上下文工程是AI应用开发的核心技术，本质是优化AI模型接收的输入内容(system、tools、messages)。通过精心设计上下文内容、结构和容量管理，可显著提升AI响应质量和效果。无论是开发者构建AI产品，还是用户使用AI工具，掌握上下文工程都能让AI更"懂你"。文章解析了各种AI技术背后的上下文工程原理，提供了实用的构建策略和最佳实践。

上下文工程的构建指南

一、AI 能看到什么？

在讨论任何 AI 技术之前，我们需要先回答一个最基础的问题：LLM 到底能"看到"什么？

答案比你想象的简单。无论你用的是 ChatGPT、Claude、还是任何其他大模型，当你发起一次请求时，从"内容"层面看，模型主要接收的是两大块信息：

（注：不同 API 的具体结构略有差异，比如 Claude API 把 system 作为单独字段，但本质相同。此外还有 temperature、top_p 等超参数影响解码方式，这里聚焦于"内容"层面。）

从概念上，我们可以把输入内容分为三类：

• •system（系统提示）：定义 AI 的身份、行为准则、基础能力，通常在 messages 的开头
• •tools（工具描述）：告诉 AI 它可以调用哪些外部能力
• •messages（对话历史）：用户输入、AI 回复、工具调用结果等

无论产品做得多复杂、功能多花哨，最终都要归结到一个问题：往这些字段里填什么。

这就是上下文工程（Context Engineering）的本质。

二、两类人，同一个问题

2.1 策略工程师的视角

对于 AI 产品的开发者来说，上下文工程是他们的核心工作。

他们每天面对的问题是：

System Prompt 怎么写？

• • 基础指令如何定义
• • 什么领域知识需要注入
• • 边界条件如何设置
• • 人设如何保持一致

动态信息怎么注入？

• • 用户画像什么时候加载
• • RAG 检索结果放在哪里
• • 实时数据如何格式化
• • 多少信息量是合适的

Messages 如何管理？

• • 历史对话保留多少轮
• • 超出 token 限制怎么压缩
• • 哪些信息是关键的不能丢
• • 如何避免上下文污染

成本如何控制？

• • 每次请求的 token 消耗
• • 信息冗余如何减少
• • 缓存策略如何设计
• • 效果和成本的平衡点在哪里

一个优秀的 AI 产品和一个平庸的 AI 产品，底层可能用的是同一个模型。差距就在于上下文工程的水平。

正如 Manus 团队所说：他们选择不自己训练模型、不靠微调，而是全力投注在上下文工程上。这让他们能够"在数小时内发布改进，而不是数周"。

2.2 用户的视角

普通用户通常被屏蔽了这些细节。他们面对的只是一个聊天框，输入自然语言，等待回复。

但问题是：如果你只用聊天框，你就只能获得"平均水平"的体验。

AI 不知道：

• • 你是谁
• • 你的专业背景
• • 你的偏好习惯
• • 你之前的使用经历
• • 你对输出格式的期望

每一次对话，对 AI 来说都是"第一次见面"。

这就是为什么很多用户觉得 AI “不懂我”、“不稳定”、“需要反复解释”——因为你没有做上下文工程。

用户侧的上下文工程，就是主动告诉 AI 那些它无法自动获取的信息。

现在很多产品开始提供这种能力：

这些机制的本质都一样：让用户参与上下文的构建。

2.3 一个类比

想象你去看医生。

如果你只说"我不舒服"，医生很难帮你。他需要知道：

• • 你的病史
• • 过敏情况
• • 最近的生活状态
• • 具体哪里不舒服
• • 持续多长时间

这些信息，就是"上下文"。

医院会有你的病历档案（持久化的上下文），医生会先问诊（动态收集上下文），然后结合专业知识给出诊断。

AI 也是一样。它的专业能力已经在参数里了，但它需要足够的上下文才能发挥出来。

三、统一视角：所有"进化"都是上下文管理

现在，让我们用这个视角重新审视 AI 领域的各种技术概念。

3.1 Tool 的本质

当我们说"给 AI 加上工具"时，本质上是在做什么？

往 tools 字段里填充工具描述。

AI 并不是真的"学会了"搜索。它只是：

1. 1. 看到了工具描述
2. 2. 理解了什么时候该用
3. 3. 生成了调用请求
4. 4. 收到了调用结果（注入到 messages 里）
5. 5. 基于结果继续回答

Tool 是上下文的一部分——它告诉 AI “你可以做什么”，以及调用结果"世界反馈了什么"。

3.2 Memory 的本质

当我们说"给 AI 加上记忆"时，本质上是在做什么？

把持久化的信息注入到 system 或 messages 里。

ChatGPT 的 Memory 功能，当你说"记住我是素食者"后，下次对话时，system prompt 里会多出一行：

用户偏好：素食者

就这么简单。AI 并没有真的"记住"——它只是每次请求时都能看到这条信息。

Memory 的各种实现方式：

• •显式存储：用户主动设置，系统持久化
• •自动提取：从对话中自动识别关键信息并存储
• •RAG 检索：根据当前问题，动态检索相关的历史信息

无论哪种方式，最终都是往那些字段里"填东西"。

3.3 RAG 的本质

RAG（Retrieval-Augmented Generation）是什么？

根据用户问题，动态检索相关文档，注入到 messages 里。

用户问题：公司的报销流程是什么？[RAG 检索] → 找到《员工手册第5章：报销制度》实际发给 LLM 的 messages：- system: "你是公司的 HR 助手..."- user: "公司的报销流程是什么？\n\n参考资料：\n《员工手册第5章》\n报销流程如下：1. 填写申请表..."

AI 不是"学会了"公司制度，而是每次提问时都能"看到"相关资料。

RAG 的核心挑战：

• •检索质量：能否找到真正相关的内容
• •信息量控制：塞太多会超出 token 限制，塞太少会信息不足
• •格式组织：怎么排列才能让 AI 更好地理解

这些都是上下文工程的问题。

3.4 Agent 框架的本质

当我们说"AI Agent"时，通常指的是一个能够：

• • 自主规划任务
• • 调用多种工具
• • 根据反馈调整行动
• • 完成复杂目标

的系统。

但从协议结构来看，Agent 的每一步都是：

1. 1. 构建上下文：整合当前任务、历史行动、环境状态
2. 2. 请求 LLM：把上下文发给模型，获取下一步行动
3. 3. 执行行动：调用工具、与环境交互
4. 4. 更新上下文：把执行结果加入历史
5. 5. 循环：回到第 1 步

Agent 框架做的事情，就是自动化管理这个上下文的构建和更新过程。

不同的 Agent 框架（LangChain、AutoGPT、CrewAI……）本质上是不同的上下文管理策略。

3.5 一张统一的图

四、上下文工程的核心问题

理解了本质之后，我们可以更清晰地定义上下文工程要解决的问题。

4.1 放什么？（内容选择）

不是所有信息都值得放进上下文。需要考虑：

相关性：这个信息对当前任务有帮助吗？

把公司所有制度都塞进去，不如只放和当前问题相关的那几条。

时效性：这个信息还有效吗？

用户三年前的偏好，可能已经过时了。

可靠性：这个信息准确吗？

错误的上下文比没有上下文更糟糕——它会导致 AI 自信地给出错误答案。

4.2 怎么放？（结构设计）

同样的信息，不同的组织方式效果差异巨大。

层次结构：

## 用户背景- 职业：后端工程师- 经验：5年- 主要技术栈：Python, Go## 当前项目- 名称：订单系统重构- 阶段：设计评审## 本次任务- 目标：评审数据库 schema 设计

比起一大段散乱的描述，结构化的信息更容易被 AI 理解和使用。

优先级：重要的信息放前面。

LLM 对上下文开头和结尾的内容更敏感（这被称为"位置偏差"）。关键信息不要埋在中间。

格式：选择合适的表达方式。

有时候一个表格比十句话更清晰；有时候代码示例比文字描述更准确。

4.3 放多少？（容量管理）

LLM 有 token 限制（Context Window）。GPT-4 Turbo 是 128K，Claude 3 是 200K，但这不意味着你应该把它塞满。

实际考虑：

• • Token 越多，成本越高
• • 信息过载可能导致"迷失在中间"——AI 忽略中间的内容
• • 响应速度随 token 增加而变慢

策略：

• • 保持精简：只放必要的信息
• • 动态加载：根据需要才检索和注入
• • 压缩摘要：用摘要代替原文
• • 分层管理：核心信息常驻，详细信息按需加载

4.4 什么时候更新？（动态策略）

上下文不是一成不变的。需要考虑：

何时添加：

• • 用户提供了新信息
• • 检测到新的偏好模式
• • 任务执行产生了有价值的经验

何时更新：

• • 旧信息被证明过时或错误
• • 用户明确要求修改
• • 发现了更好的表达方式

何时删除：

• • 信息不再相关
• • 信息被证明有害（导致错误输出）
• • 容量需要腾出空间

五、来自 Manus 的实战经验

Manus 是一个 AI Agent 平台，他们在构建过程中积累了大量上下文工程的实践经验。他们把这个不断试错、调整、重构的过程戏称为"随机研究生下降"（Stochastic Graduate Descent）——因为这确实是一门实验科学，他们已经重构了四次 Agent 框架。

以下是他们分享的几条关键经验：

5.1 KV-Cache 命中率是核心指标

在生产环境中，KV-Cache 命中率直接影响延迟和成本。

以 Claude Sonnet 为例：

• • 缓存的输入 token：0.30 USD / 百万 token
• • 未缓存的输入 token：3 USD / 百万 token
• •相差 10 倍

在 Manus 中，平均输入输出 token 比例约为 100:1。如果缓存命中率低，成本会急剧上升。

实践建议：

1. 1. 保持 prompt 前缀稳定：由于 LLM 的自回归特性，即使只有一个 token 的差异，也会导致后续缓存失效。一个常见错误是在 system prompt 开头放精确到秒的时间戳。
2. 2. Append-Only 上下文：不要修改之前的 action 或 observation，只追加新内容。确保序列化是确定性的——连 JSON 的 key 顺序都要保持一致。

5.2 用 Masking 而非增删 Tools

动态增删 tools 会破坏 KV-Cache，而且可能让模型困惑。

Manus 的做法是：保持 tools 列表稳定，通过状态机 + logit masking在解码阶段约束工具选择。

具体来说：

• • 工具命名使用一致的前缀（如browser_表示网页相关，shell_表示命令行相关）
• • 通过 logit masking 高效地强制执行工具组约束
• • 不需要有状态的处理器

这样既保持了缓存完整性，又能根据上下文动态控制 Agent 行为。

5.3 文件系统作为外部记忆

Context Window 即使有 128K+ tokens，对于复杂任务往往也不够用。Agent 天然需要访问所有历史状态，而你无法预测哪些 observation 在后续步骤会变得关键。

Manus 的解法：把文件系统当作无限大小的外部记忆。

Agent 学会读写 sandbox 中的文件。需要时读取，不需要时只保留路径。这让 context 保持轻量，但 Agent 却像有无限记忆一样。

压缩策略的设计原则：可恢复。

• • 网页内容可以丢弃，只要 URL 保留
• • 文档内容可以省略，只要文件路径可访问

5.4 通过 todo.md 进行目标重述

复杂任务可能需要约 50 次工具调用。随着执行推进，Agent 很容易"忘记"最初的目标——这就是所谓的"lost-in-the-middle"问题。

Manus 的解法：让 Agent 不断重写 todo.md。

# Current Task- [x] 分析用户需求- [x] 检索相关文档- [ ] 生成初稿 ← 当前- [ ] 用户确认- [ ] 最终输出

通过持续更新 todo 列表，全局目标被"推"到模型最近的注意力范围内，避免在长轨迹中迷失。

这是对 Transformer 注意力模式的深刻理解：与其期望模型记住很久以前的内容，不如主动把重要信息拉到最近。

5.5 保留错误信息

这是一条反直觉的经验：不要从上下文中删除失败的操作。

当模型看到它执行了某个 action 并且失败了，它会隐式地更新内部信念，学会不再重复这个错误。

[Action] shell_run: rm -rf /important_data[Result] Error: Permission denied[Action] shell_run: sudo rm -rf /important_data # 模型不会再这样做

保留错误轨迹是让 Agent 真正"agentic"的关键元素之一——从错误中学习的能力。

5.6 多智能体上下文隔离

Manus 采用多智能体架构，子智能体的主要目标是隔离上下文。

架构包括：

• •Planner：分配任务
• •Knowledge Manager：审查对话，决定什么应该保存到文件系统
• •Executor：执行 Planner 分配的任务

每个子智能体有自己的上下文窗口。当需要执行子任务时，相关上下文被传递给子智能体，而不是污染主上下文。

这样做的好处：

• • 主上下文保持精简
• • 子任务的中间状态不会干扰全局规划
• • 不同类型的任务可以有不同的上下文策略

5.7 避免 Few-Shot 陷阱

Few-shot prompting 对 LLM 很有效，但在 Agent 场景下可能适得其反。

当上下文中充满太多相似的 action-observation 对时，Agent 会陷入模仿模式——机械地重复之前的行为模式，而不是根据当前状态做出最优决策。

Manus 的解法：引入可控的多样性。

• • 在序列化模板中引入小变化
• • 措辞和格式上保持适度差异
• • 避免上下文过于"整齐划一"

这样 Agent 会把上下文当作参考，而不是要遵循的脚本。

六、实践指南

6.1 用户侧：如何做个人上下文工程

如果你想让 AI 更"懂"你，可以从这些方面入手：

利用产品提供的机制

构建个人提示词模板

为常用场景准备模板，每次使用时填充具体内容：

## 背景我是 [职业]，正在做 [项目]。## 任务我需要 [具体目标]。## 约束- [约束1]- [约束2]## 输出格式请用 [格式] 呈现结果。

主动提供上下文

不要假设 AI 知道你没说的东西。如果你问"这段代码有什么问题"，记得把代码贴上；如果你说"按照之前讨论的方案"，记得说明是哪个方案。

6.2 工程师侧：系统设计原则

System Prompt 设计

1. 身份定义：你是谁，擅长什么2. 行为准则：应该做什么，不应该做什么3. 领域知识：必要的背景信息（保持精简）4. 输出规范：格式、风格、长度要求5. 边界情况：遇到特殊情况如何处理

注意 KV-Cache 友好性

• • Prompt 前缀保持稳定
• • 动态内容放在后面
• • 避免在开头放时间戳等易变信息

动态信息注入

上下文压缩策略

当对话变长时，需要压缩历史：

方案 A：滑动窗口 - 只保留最近 N 轮方案 B：摘要压缩 - 用 LLM 生成历史摘要方案 C：关键信息提取 - 只保留关键决策和事实方案 D：文件外化 - 详细内容写入文件，只保留路径引用

6.3 一个完整的例子

假设你在构建一个代码助手：

每一个优秀的代码助手（Cursor、Copilot、Claude Code），背后都是这样一套精心设计的上下文架构。

七、哲学层面的思考

7.1 上下文即存在

对于 LLM 来说，它看到的就是它的世界。

没有出现在上下文里的信息，对 AI 来说就是不存在的。即使它在训练时"学过"，如果上下文不触发，那些知识就是沉默的。

这有点像人类的意识。神经科学告诉我们，我们的大脑储存了海量信息，但每一刻我们只能意识到其中很小一部分——那些被"激活"的部分。

上下文之于 AI，就像工作记忆之于人类：它定义了当下的认知边界。

7.2 人类也在做上下文工程

如果我们诚实地审视自己，会发现人类一直在做"上下文工程"。

会议之前：我们准备材料、整理思路、预判问题——本质上是在为自己和他人构建上下文。

写作之时：我们考虑读者是谁、他们知道什么、不知道什么——本质上是在为读者设计上下文。

教学之中：我们循序渐进、由浅入深、用类比和例子——本质上是在帮助学生建立理解所需的上下文。

AI 让这个过程变得更加显式和可操作。我们过去凭直觉做的事情，现在需要明确地设计和优化。

7.3 从"教 AI 说话"到"给 AI 配眼镜"

Prompt Engineering 的隐喻是"对话"：如何和 AI 说话，让它理解你的意图。

Context Engineering 的隐喻是"配眼镜"：AI 的视力（参数能力）是固定的，但你可以通过调整它看到的世界（上下文），让它看得更清楚。

一个近视的人，换一副更合适的眼镜，立刻能看清更多细节。不是他的眼睛变好了，而是他获得了更好的"视觉上下文"。

同样，一个 LLM 配上精心设计的上下文，能解决更复杂的问题。不是模型变强了，而是它获得了更好的"认知上下文"。

好的上下文工程，能让小模型媲美大模型。

7.4 上下文工程是 AI 时代的读写能力

在印刷时代，读写能力是基本素养。不会读写，你就无法有效地获取和传播信息。

在 AI 时代，上下文工程可能成为类似的基本素养。不懂如何为 AI 构建有效的上下文，你就无法充分利用这个时代最强大的工具。

这不是说每个人都要成为"提示词工程师"。而是说，理解 AI 的工作原理、知道如何有效地与 AI 协作，将成为越来越重要的能力。

就像今天，你不需要成为作家才能有效地写邮件；未来，你不需要成为 AI 工程师才能有效地使用 AI——但你需要理解上下文工程的基本原理。

八、结语

让我们回到最初的问题：AI 能看到什么？

从内容层面来说，主要就是 messages 和 tools。这些字段构成了 LLM 的主要输入。

所有让 AI "变聪明"的技术——Tool、Memory、RAG、Agent——本质上都是在回答同一个问题：如何更好地填充这些字段。

理解这一点，你就理解了 AI 应用的底层逻辑。

正如 Manus 团队所说：“模型可能在变强、变快、变便宜，但再多的原始能力也无法替代对记忆、环境和反馈的需求。你如何塑造上下文，最终定义了你的 Agent 如何行为：它跑多快、恢复得多好、能扩展多远。”

对于策略工程师来说，上下文工程是设计 AI 产品的核心。你需要决定：放什么内容、用什么结构、保持什么规模、何时更新、如何优化缓存。这些决策直接影响产品的效果和成本。

对于普通用户来说，上下文工程是深度利用 AI 的钥匙。当你开始主动思考"我应该告诉 AI 什么"，而不只是"我想问 AI 什么"，你就迈入了上下文工程的大门。

LLM 的参数是静态的，但上下文是动态的。参数决定了能力的上限，上下文决定了能力的发挥。

你给 AI 看什么，决定了 AI 能为你做什么。

这就是上下文工程的本质，也是 AI 时代的必修课。

随着大模型的持续火爆，各行各业纷纷开始探索和搭建属于自己的私有化大模型，这无疑将催生大量对大模型人才的需求，也带来了前所未有的就业机遇。**正如雷军所说：“站在风口，猪都能飞起来。”**如今，大模型正成为科技领域的核心风口，是一个极具潜力的发展机会。能否抓住这个风口，将决定你是否能在未来竞争中占据先机。

那么，我们该如何学习大模型呢？

人工智能技术的迅猛发展，大模型已经成为推动行业变革的核心力量。然而，面对复杂的模型结构、庞大的参数量以及多样的应用场景，许多学习者常常感到无从下手。作为一名热心肠的互联网老兵，我决定把宝贵的AI知识分享给大家。

为此，我们整理了一份全面的大模型学习路线，帮助大家快速梳理知识，形成自己的体系。我已将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

一、大模型全套的学习路线

大型预训练模型（如GPT-3、BERT、XLNet等）已经成为当今科技领域的一大热点。这些模型凭借其强大的语言理解和生成能力，正在改变我们对人工智能的认识。为了跟上这一趋势，越来越多的人开始学习大模型，希望能在这一领域找到属于自己的机会。

L1级别：启航篇 | 极速破界AI新时代

• AI大模型的前世今生：了解AI大模型的发展历程。
• 如何让大模型2C能力分析：探讨大模型在消费者市场的应用。
• 行业案例综合分析：分析不同行业的实际应用案例。
• 大模型核心原理：深入理解大模型的核心技术和工作原理。

L2阶段：攻坚篇 | RAG开发实战工坊

• RAG架构标准全流程：掌握RAG架构的开发流程。
• RAG商业落地案例分析：研究RAG技术在商业领域的成功案例。
• RAG商业模式规划：制定RAG技术的商业化和市场策略。
• 多模式RAG实践：进行多种模式的RAG开发和测试。
  

L3阶段：跃迁篇 | Agent智能体架构设计

• Agent核心功能设计：设计和实现Agent的核心功能。
• 从单智能体到多智能体协作：探讨多个智能体之间的协同工作。
• 智能体交互任务拆解：分解和设计智能体的交互任务。
• 10+Agent实践：进行超过十个Agent的实际项目练习。

L4阶段：精进篇 | 模型微调与私有化部署

• 打造您的专属服务模型：定制和优化自己的服务模型。
• 模型本地微调与私有化：在本地环境中调整和私有化模型。
• 大规模工业级项目实践：参与大型工业项目的实践。
• 模型部署与评估：部署和评估模型的性能和效果。

专题集：特训篇

• 全新升级模块：学习最新的技术和模块更新。
• 前沿行业热点：关注和研究当前行业的热点问题。
• AIGC与MPC跨领域应用：探索AIGC和MPC在不同领域的应用。

掌握以上五个板块的内容，您将能够系统地掌握AI大模型的知识体系，市场上大多数岗位都是可以胜任的。然而，要想达到更高的水平，还需要在算法和实战方面进行深入研究和探索。

1. AI大模型学习路线图
2. 100套AI大模型商业化落地方案
3. 100集大模型视频教程
4. 200本大模型PDF书籍
5. LLM面试题合集
6. AI产品经理资源合集

以上的AI大模型学习路线，不知道为什么发出来就有点糊，高清版可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

二、640套AI大模型报告合集

这套包含640份报告的合集，全面覆盖了AI大模型的理论探索、技术落地与行业实践等多个维度。无论您是从事科研工作的学者、专注于技术开发的工程师，还是对AI大模型充满兴趣的爱好者，这套报告都将为您带来丰富的知识储备与深刻的行业洞察，助力您更深入地理解和应用大模型技术。

三、大模型经典PDF籍

随着人工智能技术的迅猛发展，AI大模型已成为当前科技领域的核心热点。像GPT-3、BERT、XLNet等大型预训练模型，凭借其卓越的语言理解与生成能力，正在重新定义我们对人工智能的认知。为了帮助大家更高效地学习和掌握这些技术，以下这些PDF资料将是极具价值的学习资源。

四、AI大模型商业化落地方案

AI大模型商业化落地方案聚焦于如何将先进的大模型技术转化为实际的商业价值。通过结合行业场景与市场需求，该方案为企业提供了从技术落地到盈利模式的完整路径，助力实现智能化升级与创新突破。

希望以上内容能对大家学习大模型有所帮助。如有需要，请微信扫描下方CSDN官方认证二维码免费领取相关资源【保证100%免费】。

祝大家学习顺利，抓住机遇，共创美好未来！