大模型上下文工程实战指南：让AI表现提升10倍的秘诀，建议收藏！

摘要上下文工程是优化AI性能的核心技术，通过精心设计输入内容（system提示、工具描述、对话历史）来提升模型表现。开发者需要解决系统提示编写、动态信息注入、对话管理和成本控制等问题；用户则需主动提供个性化信息以获得更好体验。文章揭示了工具调用、记忆功能、RAG检索和Agent框架的本质都是上下文管理，并提出了内容选择、结构设计、容量管理和动态更新等核心问题。最后分享了Manus平台的实战经验，

我算是程序猿

610人浏览 · 2026-01-12 22:22:11

我算是程序猿 · 2026-01-12 22:22:11 发布

上下文工程是AI应用的核心，所有让AI"变聪明"的技术本质上都是在优化如何填充AI的输入字段（system、tools、messages）。从策略工程师到普通用户，理解并实践上下文工程是充分发挥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 那些它无法自动获取的信息。

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

产品	机制	本质
ChatGPT	Custom Instructions / Memory	用户可编辑的持久化 system prompt
Claude	CLAUDE.md 文件	项目级别的上下文注入
Gemini	User Context	结构化的用户偏好存储
Cursor	.cursorrules	代码项目的规则定义

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

2.3 一个类比

想象你去看医生。

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

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

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

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

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

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

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

3.1 Tool 的本质

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

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

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

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

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. 请求 LLM：把上下文发给模型，获取下一步行动
1. 执行行动：调用工具、与环境交互
1. 更新上下文：把执行结果加入历史
1. 循环：回到第 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. 保持 prompt 前缀稳定：由于 LLM 的自回归特性，即使只有一个 token 的差异，也会导致后续缓存失效。一个常见错误是在 system prompt 开头放精确到秒的时间戳。
1. 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 更"懂"你，可以从这些方面入手：

利用产品提供的机制

产品	入口	建议内容
ChatGPT	Settings → Personalization	职业背景、回答偏好、常用场景
Claude	项目根目录创建 CLAUDE.md	项目上下文、代码规范、技术栈
Cursor	.cursorrules 文件	编码风格、架构约定、禁止事项

构建个人提示词模板

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

## 背景我是 [职业]，正在做 [项目]。## 任务我需要 [具体目标]。## 约束- [约束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大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

在这里插入图片描述