本文深入探讨了如何通过上下文工程（Context Engineering）提升AI Agent的表现。文章首先通过电商售后案例对比了上下文匮乏与充分时Agent的表现差异，随后详细阐述了上下文工程的核心内容，包括与Prompt Engineering的区别、内存管理类比、具体管理内容等。接着，文章分析了上下文失效的原因，如窗口大≠效果好、Context Rot与Lost in the Middle等，并提出了提升信噪比的重要性。此外，文章还介绍了运行时上下文加载策略、长任务中上下文的处理方法，以及Context Engineering的落地实战步骤和常用工具。最后，文章强调了高信噪比、长任务上下文管理、先跑通最简方案等关键点，指出Context Engineering的目标是将“看心情塞Prompt”升级为“有预算、有优先级、有证据链的上下文装配”，从而提升AI Agent的整体表现。

---

文章目录

• 前言
• 一、同一个 Agent，为什么效果差这么多

• 1.电商售后案例
• 2.关键差异在哪
• 3.两个改写对比

• 二、Context Engineering 到底在管什么

• 1.和 Prompt Engineering 的本质区别
• 2.内存管理类比
• 3.它具体管哪些东西

• 三、上下文为什么会失效

• 1.窗口大≠效果好
• 2.Context Rot 与 Lost in the Middle
• 3.Attention 视角的解释
• 4.信噪比才是核心

• 四、怎么评估上下文工程的效果
• 五、运行时上下文怎么加载

• 1.预检索为什么不够
• 2.Just-in-Time 按需加载
• 3.混合策略的选择

• 六、长任务里上下文怎么撑住

• 1.Compaction：窗口快满时压缩历史
• 2.Structured Note-taking：让 Agent 记笔记
• 3.Sub-agent：别让一个 Agent 扛所有状态

• 七、Context Engineering 落地实战

• 1.Context Assembler 全流程
• 2.静态规则：先把 System Prompt 写清楚
• 3.工具上下文：工具描述先讲边界
• 4.动态上下文：RAG、记忆、工具结果别一股脑塞
• 5.示例上下文：Few-shot 别堆太多
• 6.Token 预算：单次调用内的优先级

• 八、做 Context Engineering 会用到哪些工具
• 九、真正落地时，要盯住什么

• 1.高信噪比比信息量更重要
• 2.长任务里，上下文一定会变脏
• 3.先跑通最简方案

• 十、总结
• 结尾

前言

DeepSeek-V4、GPT-5.5、Claude Opus 4.7——这些模型都把上下文窗口推到了 1M 级别（当然实际能用多长取决于不少因素）。既然窗口这么大，把材料多塞进去，让模型自行消化不就可以了？

讲真，我之前也这么想。但真正下场实践后才发现，事情远没这么简单。

Agent 每次调用 LLM，窗口里到底装着什么、装得干不干净、排片顺序对不对、工具描述写没写到位——这些东西对最终效果的影响，远超多数人的直觉判断。

这也解释了为什么很多人困惑：同一个模型、同一个 Agent 框架，凭什么别人的效果就是比你好？

本文只聊一件事：怎么把 Agent 的上下文伺候好。读完你能搞明白：

• 上下文如何左右 Agent 表现，为什么窗口大了效果未必好
• Context Engineering 与 Prompt Engineering 的分工边界
• 工程落地怎么组装上下文：静态配置、动态信息、Token 预算、按需加载
• Compaction、结构化笔记、Sub-agent 三板斧怎么对抗长任务上下文腐化

不管你是刚入门的 Agent 新人，还是在一线落地 AI 应用的架构师，读完这篇基本就算打通了上下文工程的任督二脉。

开搞！

一、同一个 Agent，为什么效果差这么多

1.电商售后案例

拿电商售后来打个样。用户抛来一句话：“你卖我上星期买的耳机右耳不响了，咋整？”

2.关键差异在哪

上下文匮乏时，Agent 大概率这样回应：

“抱歉给您的体验带来了困扰。能否告知您的耳机型号、订单编号和具体的故障细节？”

答话本身没啥硬伤，但在售后场景里特别败好感——它只会机械地反问，完全没有主动去搜集信息。

3.两个改写对比

换成上下文充分的情况来看：系统在调用 LLM 之前，把所有能查的先翻了一遍：

• 订单系统检索到了上周的购买记录：索尼 WH-1000XM5，3 月 25 日下单
• 保修状态核实：7 天无理由退换期内，未超期
• 历史工单检索：老客户，零纠纷记录
• 预装了 create_return_order 和 check_inventory 两个工具

Agent 的回复于是变成了：

“您好，我查到您 3 月 25 日买的索尼 WH-1000XM5 还在退换期内。我直接帮您提交换货申请，仓库显示同款还有库存，预计 2~3 天就能发新件。要我操作吗？”

前后对比非常明显——一个在反复问，一个直接把事办了。

当然，Agent 表现不好不能全怪上下文——工具定义、任务拆分、状态追踪、验证机制通常也得一起查。但有一条确凿无疑：上下文不够，模型再强也只能瞎猜；上下文喂到位，中档模型也能把活干顺。

二、Context Engineering 到底在管什么

1.和 Prompt Engineering 的本质区别

Shopify CEO Tobi Lutke 有句话我特别认同：

the art of providing all the context for the task to be plausibly solvable by the LLM

翻译过来就是：给 LLM 塞入足够上下文，让任务在模型能力边界内"有可能被搞定"。关键词在 plausibly——不是说上下文到位了就必定解决，而是说没有这些上下文，任务连"可能被解决"的前提都谈不上。

这两者常被混为一谈，但它们关注的东西确实不一样：

维度	Prompt Engineering	Context Engineering
🎯 专注点	指令怎么措辞	窗口里放什么信息
📝 管控范围	措辞、排列、格式、语气	信息选取、结构设计、注入时机、淘汰逻辑
🍳 类比	教大厨这道菜怎么做	帮大厨备厨房——食材归位、刀具就位、调料分级、火候参考贴墙上

2.内存管理类比

我更喜欢另一个类比：Context Engineering 就是 LLM 的内存管理。

上下文窗口好比一块容量有限的内存。Context Engineering 管的就是：内存里装啥、什么时候换出、什么时候读、什么时候写。一旦满了就要做淘汰，这跟 OS 的页面置换是一个套路——LRU、优先级策略这些概念都能直接借鉴。后面提到的 Token 降级，其实也是在干这件事。

3.它具体管哪些东西

分块来看：

🏗️ System Prompt（静态规则）
像 .cursorrules、.claude/rules、AGENTS.md 之类的配置文件，里面写好角色定位、任务目标、限制条件、执行步骤和输出规范，相当于给 Agent 定下一套"基础操作守则"。

💬 User Prompt（用户指令）
看起来简单，实际上真实项目里常常是自然语言、业务字段、历史状态、附件材料的混合物。处理不好就会把上下文搞脏。

🧠 Memory（记忆系统）
分为短期和长期。短期通常靠 Session 滑动窗口解决；长期方案不止向量库——文件存储、KV 系统、关系库、图数据库、向量检索层都可以承担。关键命题是：存什么、何时写、怎么更新、如何遗忘、被召回后怎样拼入上下文。

📚 RAG & Tools（检索与工具）
RAG 负责从外部文档中检索相关内容并写入上下文；Tools 负责挂载工具说明、参数定义和调用结果。RAG 本身可看作 Context Engineering 的一种实现流派——它要回答的就是"找什么、怎么找、找到的怎么进入上下文"这几个问题。

📋 Structured Output（结构化输出）
JSON Schema、Function Calling 参数结构和返回约束这些会作为本次调用的约束进入上下文，虽非业务知识但直接影响解析质量。工具调用的返回值属于运行时 Observation，需要在保留原文、摘要压缩和直接清理三者间做好取舍。这一步很多人写 Agent 时会漏掉，到了解析阶段就一堆脏活等着。

✂️ Token 优化（节约开销）
做摘要压缩、历史剪裁、Context Caching，目标很单纯：在不明显丢信息的前提下压住 Token 消耗。

三、上下文为什么会失效

1.窗口大≠效果好

这里挺反直觉。多数人（包括以前的我）天然觉得：窗口越大、能塞的内容越多，模型表现也会水涨船高。

但现实是：上下文有边际收益递减，塞过头了结果反而可能更糟。

类比开卷考试——资料带得多不代表答得快，关键的那几页可能淹没在无关纸张里。

模型也类似。窗口变大了只是容纳空间增加，不代表它能自动识别重点。就拿分析一份长需求文档来说，核心限制条件可能只有两三句，却埋在大量背景描述中，模型很容易把中间的硬约束给看漏了。

2.Context Rot 与 Lost in the Middle

这就是 Context Rot（上下文腐化）——上下文越长、内容越杂，模型利用它的稳定性就越差。

与之并行的经典现象是 Lost in the Middle——模型对上下文首尾部位的信息敏感度高，中间段落很容易"扫过就忘"。所以有时候资料分明给全了，模型还是答偏——不一定是没读到，很可能是关键信息在冗长的上下文里不够显眼。

3.Attention 视角的解释

（偏学术，跳过不影响理解主线）

Transformer 不像人类逐行阅读，而是靠 Attention 机制判断：当前问题应该重点关注上下文里哪些部分。可以把 Attention 看作"相关性打分器"——你问"为什么接口超时"，模型就去上下文里搜索跟接口、超时、日志、SQL、缓存、外部依赖有关的内容。上下文短时干扰少，定位精准。

可一旦塞入几十页文档、几百条日志、十几段背景说明，局面就变了。候选信息越多，干扰项越多，注意力越容易分散。按标准 full attention 理解，每个 Token 都要跟其他所有 Token 计算注意力——Token 越多，计算压力和筛选压力同步上升。当然现在的长上下文模型普遍用了稀疏注意力、分块、缓存、压缩等降本手段，所以也不是简单地说"一长就一定差"。

更严谨的表述：长上下文增加模型的筛选难度和推理开销；退化程度由模型架构、上下文结构和任务类型共同决定。

这也解释了：为何有些模型标称 100K / 200K 窗口，实际却不一定能稳定吃满——装得下，和用得好，是两码事。

4.信噪比才是核心

真实的开发场景里，这种体验太常见了：你把项目文档、接口说明、会议纪要、历史需求一股脑塞进去，然后问"这个改动会影响老用户的登录链路吗"。

关键信息可能就那么一句——“旧版 token 校验逻辑仍在老用户链路上，不能直接切到新鉴权模块”——但它埋在数十段无关内容中，模型很容易一扫而过，最后输出一个看似合理、实则高危的方案。

所以长上下文真正的瓶颈不是"塞不进去"，而是**“模型能否稳定找到关键内容”**。

这也正是 Context Engineering 的发力点——不是把所有材料都推进 Prompt，而是提高信噪比。具体做法：

• 删除重复和无关段落
• 将硬约束放在更显眼的位置
• 长文档先分段、摘要或检索，避免整篇硬塞
• 把任务目标、业务背景、约束条件、输出要求分门别类
• 对关键事实做标记，减少模型自行猜测的空间

一句话总结：长上下文不是垃圾箱，不能什么都往里扔。 它更像一张工作台——台面大当然好，但图纸、工具、废纸、旧零件堆得乱七八糟，人都找不到重点，何况模型。工程上真正该关心的不是窗口有多宽，而是当前任务究竟需要哪些信息。宁肯上下文短点但信噪比高点，也别往里头塞一堆"可能有用"的内容。

🎯 记住：Context Engineering 的目标不是"塞越多越好"，而是"放对东西"。

四、怎么评估上下文工程的效果

不能靠体感。最常见的一种错觉是：改完之后 Agent 看上去更"有模有样"了，但任务成功率没涨，成本反而涨了。

建议至少盯这五类指标：

指标类型	具体看什么
✅ 任务成功率	是否达成目标、要不要人工介入、能否稳定复现
🔧 工具质量	选错/漏调用工具、参数填错、重复调用、高危操作拦截率
💰 上下文成本	输入/输出 Token 数、缓存命中率、压缩后的信息保留度
⏱️ 延迟指标	首 Token 延迟、端到端耗时、工具等待时间、p95/p99
📊 结果质量	幻觉占比、证据引用精度、摘要遗漏率、关键字段缺失率

🧠 实操建议：从真实任务中挑 20~50 条做个小型评测集。然后改检索、压缩、工具 Schema、Prompt 这些——一次只改一个变量，不然根本分不清效果来自哪一步改动。

五、运行时上下文怎么加载

1.预检索为什么不够

传统 AI 应用偏爱预检索——调 LLM 之前，先拿 Embedding 相似度找出最相关的上下文，然后一次性全塞入 Prompt。简单的问答场景下这套很顶用，但到了复杂的 Agent 任务就不够用了。

根本原因在于：预检索拿到的是"调用前看起来相关"的信息，而 Agent 在执行过程中会不断发现新线索，这些线索在做预检索时根本还不存在。

2.Just-in-Time 按需加载

Just-in-Time 正好反过来：不预设把全部信息装好，而是运行时先维持轻量引用——文件路径、数据库查询、Web 链接——等确实需要了，再借助工具动态拉取数据。

Claude Code 是典型代表。它分析大型代码库时不会一股脑把所有文件吞进上下文，而是先靠目录结构、文件名、搜索命令锁定目标，再用 head、tail、grep 逐步读入。做法跟人一样——靠文件名和目录结构推测信息位置，靠文件大小和时间戳推敲重要程度，绝不会一上来就把整库灌进去。

⚠️ 有个容易忽视的细节：元数据自己就在传递信息。tests/test_utils.py 和 src/core_logic/test_utils.py 语义差异很显著，Agent 光扫路径名称就能判断出两个文件大概率服务于不同目的。

Anthropic 把这种思路叫做 Progressive Disclosure（渐进式披露）。Agent 不是一次性获取全部上下文，而是通过多轮探索逐步理解任务全貌。文件大小暗示复杂度，时间戳暗示时效性，目录结构传达语义关系。Skills 机制就是这一思想的具体实践。

不过按需加载也有代价——比预检索慢速，同时在导航工具（glob、grep、tree 这些）的易用性上要求更高。工具不好用或者启发式规则不够精确，Agent 很容易陷进死胡同，浪费上下文和调用次数。所以 Just-in-Time 不是真的"不做预处理"，恰恰相反——它对工具集和导航策略的要求比预检索更高。

3.混合策略的选择

实际项目里更常见的是混合策略：对确定性高的静态知识做预检索，对运行中动态发现的信息做按需拉取。Claude Code 就是这种模式——CLAUDE.md 文件可以预加载，但代码文件内容靠 Agent 自己探索。

不同场景各有侧重：

• 代码分析、信息检索

  这类探索空间大、动态内容多的，以 Just-in-Time 为主

• 法律文书审阅、财报分析

  这类上下文稳定、动态内容少的，预检索加点运行时补充就够了

策略	优点	代价	更适合的任务
📦 预检索	速度快、链路简单稳定	容易混入噪声且运行中无法调整	FAQ、固定知识库、稳定文档审阅
🔍 Just-in-Time	上下文干净、证据按需进入	工具调用多、端到端延迟偏高	代码分析、故障排查、开放式研究
🔄 混合	兼顾启动速度与运行时弹性	需预算管理+导航机制配合	复杂业务 Agent、长任务、多源检索

选型时别只看"哪个更先进"，而是看四个约束：上下文稳不稳、探索空间多大、实时性要求多高、证据是否必须可追溯。

六、长任务里上下文怎么撑住

1.Compaction：窗口快满时压缩历史

Agent 要连续跑数小时、迭代几十轮，单靠常规上下文管理肯定撑不住——它需要跨窗口持久化。Compaction 是其中最常用的手段：上下文即将满载时，把历史内容交给 LLM 做一轮摘要，然后拿着摘要开启新窗口继续运作。

Anthropic 官方文章提到了 Claude Code 的一个实现方向：将历史消息交给模型归纳，保留架构决策、未修复 Bug、关键实现细节，丢弃冗余的工具调用结果。然后 Agent 拿着压缩后的上下文以及最近访问的几个文件继续推进。

⚠️ 但这个"几个文件"最好理解为官方示例，不建议当成固定规则。真正要学的是背后的策略：压缩历史、保留关键决策、维持近期工作上下文，让 Agent 重启后还能接上。

做这一步的难点在取舍——留太多，压缩意义不大；留太少，关键上下文又断了。比较实际的做法是拿复杂轨迹反复调试压缩 Prompt，先保证重要信息被保留，再逐步删减冗余。一次写不准，必须迭代。

还有个更省 Token 的手段：把已经消化完的工具调用结果清理掉。工具调完了，结果也被模型引用过了，后续没必要继续保留完整原始输出。Anthropic Developer Platform 现已支持 context editing / tool-result clearing，可以在保留 tool_use 记录的前提下单独删掉对应的 tool_result——既省空间又不影响后续工具调用链路的可追溯性。

2.Structured Note-taking：让 Agent 记笔记

Structured Note-taking 是另一种策略——让 Agent 主动把关键阶段性结论写进外部文件（例如 NOTES.md），上下文重置后通过读文件恢复进度。

这个思路跟人类工程师写 to-do、技术备忘没两样。Claude Code 在长时段任务里会自动管 to-do list；自定义 Agent 同样可以在项目根目录维护一份 NOTES.md，记录已完成的进度、尚未解决的问题、下一步的计划。

有个挺有意思的例子：Claude 玩宝可梦（Pokémon）。好几千轮游戏过程里，Agent 自己搞了一套数值追踪——“1 号道路练了 1234 步皮卡丘，升到 8 级，离目标还差 2 级”。它还自建了地图、成就清单、战术备忘。上下文重置之后读取这些笔记即可无缝续上，所以才能跑好几个小时不中断。Sonnet 4.5 发布时 Anthropic 也推出了 Memory Tool 公测，靠文件持久化帮 Agent 建立跨会话的知识体系。

3.Sub-agent：别让一个 Agent 扛所有状态

Sub-agent 的策略很直接——不让单一 Agent 背负整个项目的状态，而是将专门任务拆分给专业子 Agent，主 Agent 只管分配和汇总结果。

每个子 Agent 可以自由探索大量上下文（可能消耗数万 Token），但最终只向主 Agent 回传一段 1000~2000 Token 的精炼摘要。这样主 Agent 的窗口就不会被冗长搜索过程淹没——详细内容被封锁在子 Agent 内部，主 Agent 只专注于分析与决策。

Anthropic 在《How we built our multi-agent research system》一文中对这个模式有详细描述。在复杂研究场景下，Sub-agent 能有效隔离检索过程、压缩传回的结果，从而减轻主 Agent 上下文负担。但 Sub-agent 用不用，要看任务能否合理拆分、子任务彼此耦合程度有多深、最终汇总会不会丢掉关键证据。

技术	适用场景
🔄 Compaction	需要持续对话和上下文连贯性的长流程
📝 Note-taking	有清晰里程碑的多步迭代任务
🤝 Sub-agents	复杂研究、并行探索、需汇总多路结果的任务

七、Context Engineering 落地实战

把前面的运行时加载和长任务持久化串起来，放到一条完整流程里看。

1.Context Assembler 全流程

工程落地的真相就是一句话：每次调 LLM 之前，跑一次 Context Assembler。

# 入参：用户任务 + 会话状态 + 业务上下文
input: user_task, session_state, business_context
# ① 加载系统约束：策略规则、权限边界、限制条件
constraints = load_system_constraints()
# ② 从用户输入和会话上下文中解析出当前的具体目标
goal = extract_current_goal(user_task, session_state)
# ③ 拉取 RAG 证据：从文档库、知识库、业务数据库中检索与目标相关的资料
evidence = retrieve_rag(goal, business_context)
# ④ 召回记忆：用户偏好、历史对话摘要、模型持久化记忆
memory = recall_memory(goal, session_state)
# ⑤ 按目标 + 证据 + 记忆筛选本轮需要挂载的工具集
tools = select_tools(goal, evidence, memory)
# ⑥ 压缩会话历史，为跨窗口的上下文续接做准备
history = compact_history(session_state.messages)
# ⑦ 合并所有部件，并按重要性排序
context = rank([
constraints,
goal,
evidence,
memory,
tools,
history
])
# ⑧ 按 Token 上限做截断或裁剪
context = fit_token_budget(context)
# 出参：组装完毕的消息序列 + 工具 schema + 附加元信息
output: messages, tool_schema, metadata

有两个环节需要特别重视：rank 决定信息谁前谁后，fit_token_budget 决定哪些保原文、哪些压摘要、哪些仅留引用。这两步如果做得粗糙——检索到什么就传什么、历史能塞多少就塞多少——最终的窗口里有一半会是噪声。

下面把每个输入拆开细讲。

2.静态规则：先把 System Prompt 写清楚

静态规则可以理解为 Agent 启动时的"初始配置"——那些不会随对话变动的底层设定。建议用结构化 Markdown 组织 System Prompt，按角色、目标、约束、执行流程、输出格式分段，比混在一起写更清晰可控。

故障排查 Agent 的示范：

## 角色
你是一个后端服务故障排查专家，擅长通过日志和监控数据定位问题根因。
## 约束
- 只调用必要的工具，不重复调用相同逻辑的工具
- 发现关键信息时立即停止搜索，输出结论
- 优先使用实时数据而非历史推断
## 执行流
1. 查监控指标（CPU/内存/网络）
2. 查对应时间范围的日志
3. 如发现异常调用链，追踪上下游依赖
4. 输出结构化报告：问题描述→根因→建议修复方案
## 输出格式
使用 JSON，包含字段：incident_summary, root_cause, evidence, recommendation

这些规则可以写到 .cursorrules、AGENTS.md 之类的地方固化下来。它不只提升模型表现，更重要的是方便团队维护——每个人都口头传规则，后面一定会乱。

写 System Prompt 有两个常见极端：

极端	表现	后果
过度设计	大量 if-else 逻辑往里塞，试图精确控制每一步	Prompt 又长又脆，边缘情况照样翻车
过度抽象	一句"做个有帮助的助手"	模型拿不到决策依据，要么反复追问用户，要么输出偏离业务预期

最好的状态是：具体到能约束行为，抽象到能覆盖常见变化。 Anthropic 工程博客称之为 Goldilocks zone——"刚刚好"的位置。

🧠 实操建议：先用最简 Prompt 跑出一个基线效果，再针对 failure case 一条条往里补规则。Anthropic 把这种方式称为 Calibrating the system prompt——System Prompt 应该当作需要长期调校的参数对待，而不是写一次就锁起来的配置文件。

3.工具上下文：工具描述先讲边界

工具定义质量直接决定了 Agent 是选对还是选错。一份好描述得说清楚：什么时候该调？什么时候不该调？ 如果连人类工程师都看不出这个工具是干嘛的，Agent 必定犯错。

最常见的坑是造一个"大而全"的工具，什么都能干。Agent 选工具时犹豫，填参数时也被一堆无关字段干扰。边界清晰 > 描述详尽。一个工具只做一件事，参数描述里给格式示例——做到这几点，误调用率通常会显著下降。

4.动态上下文：RAG、记忆、工具结果别一股脑塞

检索时机和策略前面已讲过。这里只说检索结果进入窗口之后的处理。

短期记忆靠滑动窗口管理，长期事实从外部存储中检索。API 报错日志、工具返回值这类 Observation 可以先裁剪或摘要，但排障类信息必须保留原始引用——traceId、时间戳、错误码、日志存放位置、工具调用参数、原始结果摘要链接，缺一不可。

只写一句"接口报错了"，后面排查会断线；原始日志洪流全塞进去，模型又被淹没。

真正容易翻车的地方通常不是"有没有做检索"，而是检索命中了错误的文档、记忆已过时、工具响应超时、摘要过程把关键证据弄丢了：

失败路径	典型表现	兜底方案
RAG 无结果	检索不到相关文档或召回过于发散	回退到关键词检索，必要时由 Agent 反问用户补足缺口
工具超时	外部 API 卡死，Agent 一直阻塞	限定超时/重试上限/熔断，关键路径预留人工接管入口
摘要丢失	压缩后丢失了异常栈、版本号、边界值	保留 traceId、原始证据位置、关键字段和可回查链接
记忆污染	旧状态被误认为当前事实	写入前做校验，读取后标记来源、时间戳和可信度
多工具冲突	两个工具都能处理，Agent 选错路径	用优先级规则、状态机、副作用等级约束调用次序

5.示例上下文：Few-shot 别堆太多

Few-shot prompting 是个好工具，但用法不对就容易翻车。常见误区：往 Prompt 里堆几十个 edge case，以为能覆盖所有规则——结果模型把示例表面写法学了过去，真正的处理逻辑反而没抓住。

更稳的做法是挑 3~5 个多样化的典型示例（canonical examples），每个覆盖一类标准场景，而不是列全所有边界情况。对模型来说，示例应该展示"什么场景用什么策略"，而不是"这个输入必定对应那个输出"。

6.Token 预算：单次调用内的优先级

⚠️ 注意：这里讲的是单次调用内的优先级，不是跨窗口的历史压缩——后者在 Compaction 那节已经说了。窗口快满时这两层需配合使用。

优先级	内容	处理方式
🔴 高优先级（固定区）	System Constraints、当前任务目标、安全边界	固定槽位常驻，确保关键约束不被挤掉
🟡 阶段性优先级	当前阶段需用的工具描述、Schema、少量示例	按阶段动态挂载，卸载后保留可重新发现的入口
🟠 中优先级（可精简）	RAG 背景资料、旧工具结果	做二次精简，仅留关键段和可回溯引用
🟢 低优先级（可折叠）	早期对话历史	让模型自己做摘要后折叠

大规模并发场景下还可结合 Prompt / Context Caching。对支持缓存的模型，把稳定不变的 System Prompt 和工具说明做成缓存前缀，可以减少重复计费，或者降低首 Token 延迟。命中与否要看厂商怎么实现的、前缀是否变化、缓存生命周期，最终都得拿业务负载实测一遍。

八、做 Context Engineering 会用到哪些工具

不用一上来就全家桶。落地时会接触到几类东西，它们不是同层的，也不是每个项目都得全上。

类别	代表	核心用途
🏗️ 编排	LangChain、LangGraph	控制流、状态管理、循环调度
📊 数据	LlamaIndex	数据摄取、索引构建、检索优化
🗄️ 向量库	Pinecone、Weaviate、Chroma、Qdrant	Embedding 存储与语义搜索
🔌 协议	MCP	工具标准化接入宿主
🧠 Memory	Mem0、LETTA（原 MemGPT）、ZEP	记忆生命周期管理

逐项拆一下：

• 编排框架

  ：控制 Agent 流程——何时调工具、何时回退、状态如何在节点间传递

• 数据框架

  ：LlamaIndex 偏 RAG，侧重点在如何把文档组织好、检索做准

• 向量数据库

  ：小项目本地 Chroma 够用，企业级再看 Qdrant、Milvus、Pinecone

• 通信协议

  ：MCP 解决工具如何标准化挂入宿主程序。以 2025-03-26 这版规范为例，底层走 JSON-RPC 2.0，划分出 Host、Client、Server 三个角色，由 Server Features 来对外暴露 Resources、Prompts、Tools 这类能力

• Memory 产品

  ：通常在向量库之上封装写入、检索、遗忘等生命周期管理

🧠 顺带提一下 MCP。工具一旦暴露给 Agent，就不仅是能力入口，也可能变成副作用入口。读文件、查数据库、发请求、改配置——边界没卡住的话排查极其痛苦。

九、真正落地时，要盯住什么

Context Engineering 做到底，关注点不是"Prompt 写得精不精彩"，而是每次调 LLM 之前窗口里究竟放了什么。换一个检索策略、改一种摘要方式、调一下工具 Schema 的挂载顺序——有时比换模型还管用。

1.高信噪比比信息量更重要

宁缺毋滥。Dex Horthy 提过 40%~60% 上下文利用率这个经验区间，但别把它当铁律。真正要找的是能让模型做出准确判断的最小高密度信息集，而不是"塞得下就多塞点"。窗口一大就下意识加料，噪声多了判断力反而下降。

2.长任务里，上下文一定会变脏

这是客观规律，不是设计缺陷。持续运行的 Agent 迟早会让早期判断、旧结论、已修复的问题全混进来，只靠"继续对话"撑不住。Compaction、笔记、Sub-agent 要组合着用——它们解决的是不同维度的问题。

但也不建议一开始搞太重——长任务还没跑起来呢就先搭复杂记忆层和检索体系，最后调系统比做业务还累。

3.先跑通最简方案

Anthropic 反复强调一个原则：do the simplest thing that works。

基线都没跑通就搞记忆分层、复杂检索、长期状态管理——效果差时根本不知道是检索错了、摘要丢了、工具描述歪了还是模型不行——系统越复杂排查链越长。

更务实的路线：先理清 System Prompt 和工具边界 → RAG 检索做准 → 加摘要压缩和上下文预算 → 长任务真遇到瓶颈了再考虑记忆层、Sub-agent 或更复杂的运行时检索。

结语：抓住大模型时代的职业机遇

AI大模型的发展不是“替代人类”，而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作，却催生了更多需要“技术+业务”交叉能力的高端岗位。对于求职者而言，想要在这波浪潮中立足，不仅需要掌握Python、TensorFlow/PyTorch等技术工具，更要深入理解目标行业的业务逻辑（如金融的风险控制、医疗的临床需求），成为“懂技术、懂业务”的复合型人才。

无论是技术研发岗（如算法工程师、研究员），还是业务落地岗（如产品经理、应用工程师），大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情，紧跟技术趋势，就能在AI大模型时代找到属于自己的职业新蓝海。

最近两年大模型发展很迅速，在理论研究方面得到很大的拓展，基础模型的能力也取得重大突破，大模型现在正在积极探索落地的方向，如果与各行各业结合起来是未来落地的一个重大研究方向

大模型应用工程师年包50w+属于中等水平，如果想要入门大模型，那现在正是最佳时机

2025年Agent的元年，2026年将会百花齐放，相应的应用将覆盖文本，视频，语音，图像等全模态

如果你对AI大模型入门感兴趣，那么你需要的话可以点击这里大模型重磅福利：入门进阶全套104G学习资源包免费分享！

扫描下方csdn官方合作二维码获取哦！

给大家推荐一个大模型应用学习路线

这个学习路线的具体内容如下：

第一节：提示词工程

提示词是用于与AI模型沟通交流的，这一部分主要介绍基本概念和相应的实践，高级的提示词工程来实现模型最佳效果，以现实案例为基础进行案例讲解，在企业中除了微调之外，最喜欢的就是用提示词工程技术来实现模型性能的提升

第二节：检索增强生成（RAG）

可能大家经常会看见RAG这个名词，这个就是将向量数据库与大模型结合的技术，通过外部知识来增强改进提升大模型的回答结果，这一部分主要介绍RAG架构与组件，从零开始搭建RAG系统，生成部署RAG，性能优化等

第三节：微调

预训练之后的模型想要在具体任务上进行适配，那就需要通过微调来提升模型的性能，能满足定制化的需求，这一部分主要介绍微调的基础，模型适配技术，最佳实践的案例，以及资源优化等内容

第四节：模型部署

想要把预训练或者微调之后的模型应用于生产实践，那就需要部署，模型部署分为云端部署和本地部署，部署的过程中需要考虑硬件支持，服务器性能，以及对性能进行优化，使用过程中的监控维护等

第五节：人工智能系统和项目

这一部分主要介绍自主人工智能系统，包括代理框架，决策框架，多智能体系统，以及实际应用，然后通过实践项目应用前面学习到的知识，包括端到端的实现，行业相关情景等

学完上面的大模型应用技术，就可以去做一些开源的项目，大模型领域现在非常注重项目的落地，后续可以学习一些Agent框架等内容

上面的资料做了一些整理，有需要的同学可以下方添加二维码获取（仅供学习使用）