核心内容摘要
背调不仅是流程，更是风控的底线
本文提出基于职责分离思想的上下文管理新思路将工具调用解耦为行为和影响两部分通过结构化、模块化、动态组装的上下文设计替代传统直接将大量原始数据塞入上下文的做法。
同时引入行为-影响分离、记忆/遗忘机制等策略系统性缓解长上下文导致的注意力稀释、信息过载等问题提升Agent在复杂编码任务中的稳定性与效率具备跨任务复用潜力。
引⾔本⽂主要是S1尝试进⾏模型为主的⾃动化编码过程中遇到了⻓任务下上下⽂的爆炸以及短任务中注意⼒的分散问题尝试了模型压缩、FIFO、多agent上下⽂隔离等各种策略后在摸索过程中逐渐演变出的的⼀个设计思路核⼼思想是⼯具的职责分离。
下⽂会基于语⾔模型的原理、特点以及在实践过程中遇到的问题从⼯程中职责分离的⻆度出发尝试⼀种新的上下⽂管理的思路通过将⼯具分为⾏为和影响通过结构化上下⽂的动态管理来尝试解决上下⽂中的各类问题虽然是在coding场景下的尝试但思路也许也可以被复⽤到其他类型的场景中。
什么是上下⽂⼤型语⾔模型LLM本质上是⼀个基于已有 token 序列预测下⼀个 token 的概率系统。
当接收到⼀段⽂本时模型将其转换为 token 序列通过神经⽹络计算后输出下⼀个 token 的概率分布并将该 token 追加到序列末尾循环往复直⾄⽣成结束符。
在⼀次请求中“我们”输⼊给模型的完整内容即为上下⽂Context。
简单来说上下⽂就是模型“看到”的、⽤于理解当前语义或预测下⼀个词的所有前置信息。
在⼀个典型的 Agent 应⽤中上下⽂通常包含以下四类内容⽤户输⼊User Input⼯具调⽤与返回Tool Calls Responses历史对话Conversation History⼯具定义包括 MCP 等元信息对⽤户⽽⾔可控部分仅限于“⽤户输⼊”⽽对 Agent 开发者来说其余三部分才是可设计、可优化的核⼼——这正是上下⽂⼯程Context Engineering 的核⼼任务在正确的时间以正确的结构向模型传递正确的信息使其做出最恰当的响应或决策。
token的多次⽣成循环是发⽣在模型内部的在这次请求中“我们”输⼊的完整内容就是上下文。
简单来说上下⽂就是模型“看到”的、⽤于帮助它预测下⼀个词或理解当前语义的前⾯的⼀段⽂字。
在⼀个典型的agent应⽤中上下⽂由下⾯的部分组成⽤户输⼊⼯具调⽤历史对话⼯具的定义包括mcp。
对⽤户来说能够掌握的部分只有“⽤户输⼊”对于agent的开发者来说则是除了“⽤户输⼊”以外的所有内容上下⽂⼯程指的就是agent开发者在软件开发过程中对上下⽂中包含的内容的组装。
上下⽂⼯程关注的是如何把正确的信息在正确的时间以正确的结构传递给模型使其能做出最恰当的响应或决策。
▐上下⽂⼯程的核⼼⼯作活动说明上下⽂设计Context Design规划上下⽂应包含哪些元素如系统提示、对话历史⼯具输出记忆⽚段等。
上下⽂组装Context Assembly在运⾏时动态拼接过滤排序相关信息形成最终输⼊。
上下⽂压缩Context Compression在有限 token 窗⼝内通过摘要、选择性保留、向量检索等⽅式精简冗余信息。
上下⽂缓存与管理Context Management维护短期对话状态和⻓期记忆⽀持跨轮次⼀致性。
上下⽂评估与优化Context Optimization通过 A/B 测试、⼈⼯评估或⾃动指标迭代改进上下⽂结构。
上下⽂的影响为何“⻓了反⽽变笨”模型本质上是⼀个么得感情的计算机器⽤户输⼊是模型被动感知环境的⽅式⽽⼯具则是模型主动感知和影响环境的⼿段。
基于语⾔模型的原理我们知道模型的输出取决于输⼊和模型的固有参数对应⽤层开发来说模型的固有参数⽆法调整能控制的只有输⼊内容。
同时我们知道模型的参数维度是固定的因此模型能感知到的特征是有限的当⽤户的输⼊过多时能明显感觉到模型似乎在“变笨”。
这种现象通常被称为“上下⽂⻓度增加导致性能下降”或“⻓上下⽂退化”long-context degradation是当前⼤语⾔模型LLM在处理超⻓输⼊时常⻅的⼀种局限性。
具体表现为注意⼒稀释随着输⼊⽂本变⻓模型的注意⼒机制需要在更多 token 之间分配注意⼒权重。
关键信息可能被⼤量⽆关或冗余内容“稀释”导致模型难以聚焦于真正重要的部分从⽽影响推理、问答或摘要等任务的准确性。
位置编码失效或失真⼤多数模型使⽤位置编码如 RoPE、ALiBi 或绝对位置嵌⼊来感知 token 的顺序。
当输⼊远超训练时的最⼤上下⽂⻓度例如训练时最⼤为 4K但推理时输⼊ 32K tokens位置编码可能⽆法准确表示远距离 token 的相对关系造成时序混乱进⽽影响理解。
信息过载与噪声⼲扰输⼊内容越多越可能包含重复、⽭盾或⽆关的信息。
模型缺乏有效的信息筛选机制容易被噪声⼲扰甚⾄“迷失”在冗⻓⽂本中导致输出变得模糊、不相关或逻辑混乱——看起来像是“变笨了”。
训练-推理不匹配模型在训练阶段很少⻅到极⻓的上下⽂样本因此对⻓⽂本的泛化能⼒有限。
即使通过外推技术如 YaRN、NTK-aware scaling扩展上下⽂窗⼝其在⻓上下⽂下的表现仍可能显著弱于短上下⽂。
计算资源限制带来的近似处理为应对⻓上下⽂带来的计算开销如注意⼒复杂度为 O(n²)⼀些系统会采⽤滑动窗⼝、稀疏注意⼒或缓存截断等策略这些近似⽅法可能⽆意中丢弃关键信息进⼀步降低模型表。
⼯具的上下⽂LLM 本质是 token 预测器仅能输出⽂本。
要使其成为⽣产⼒⼯具需通过⼯具调⽤机制扩展其能⼒模型输出结构化指令 → 程序解析并执⾏ API → 将结果作为新上下⽂返回。
。
若将 LLM ⽐作⼤脑⼯具就是眼睛、⼿、脚若⽐作⼈类⼯具就是电脑、书本。
所有输⼊——⽤户指令、⼯具定义、调⽤记录、系统提示——本质上都是上下⽂的⼀部分。
在单轮 Agent 场景中上下⽂膨胀主要来⾃⼯具调⽤返回⼤量数据如读取整个⽂件⽤户上传⻓⽂档开发者虽⽆法控制⽤户输⼊但可优化⼯具的上下⽂表达⽅式。
⼯具上下⽂分为两类静态定义⼯具功能描述编码时确定动态交互调⽤参数与返回结果运⾏时⽣成本⽂并不讨论⼯具定义的⽅式⽽是直接讨论会导致上下⽂快速增⻓的动态交互部分。
▐⼯具实现的思路和问题在coding场景中最经典的⼯具就是read_file和write_file即⽂件读写⼯具。
在提供read_file⼯具时最简单的⽅式就是直接读取并返回完整的⽂件内容为⽅便起⻅我们叫这个⼯具read_full_file。
需要注意的是部分⽼项⽬或不规范项⽬中可能会存在编码不⼀致的问题例如utf8和gbk混⽤的情况如果未使⽤准确的编码读取⽂件内容可能导致注释、⾮英⽂常量⽆法被模型识别导致⽆法正确理解“业务含义”代码逻辑之外的信息。
在java项⽬中推荐这两个库 juniversalchardet 和 cpdetector 来通过部分字节推测⽂件编码以避免此类问题。
当然最佳实践是通过改造来完成项⽬编码的统⼀最佳实践是统⼀使⽤utf-8编码。
String readFullFile(String path){ //这里去读取文件内容然后return出去 }⚠注意⼯具的返回值也是上下⽂或者说提示词的⼀部分read_full_file有⼀个显⽽易⻅的问题“完整的⽂件可能很⼤”导致上下⽂快速膨胀。
此外还有⼀些和模型的特点相关的问题在找不到路径时需要明确告知模型 “xx路径不存在”⽽不能告知模型“”否则模型可能会陷⼊⼯具调⽤的⽆限循环qwen系列⽐较明显。
模型输⼊的path不⼀定准确可能输⼊的是类的限定名、⽂件名或是缺失部分路径、缺失⽂件后缀等。
对于path不准确的问题可以基于⼀个简单的思路来进⾏处理即先搜索在读通过关键词匹配对path进⾏搜索如果能定位到唯⼀的⽂件则读取此⽂件否则明确告知模型现在有多个相似的⽂件需要模型重新再⽣成⼀次⼯具调⽤。
在read⼯具和write⼯具混⽤的情况下read_full_file还会出现⼀个新的问题我们先不关注write⼯具的具体实现只需要知道write后⽂件内容肯定发⽣了变化同⼀份⽂件内容在编辑后已经失效了需要重新读取⽂件内容⽽历史⼯具调⽤的respone和新的response存在⼤量重复如果是多次编辑则会导致上下⽂快速膨胀。
这是因为我们将⽂件内容放在⼯具调⽤的返回值中发送给模型的消息类似于下⾯的格式tool_call:read_full_file filePath tool_response:filePath.content //第一次读取 tool_call:write_file filePath xxxx tool_response: 更新成功 tool_call: read_full_file filePath tool_response:filePath.content //第二次读取为什么模型需要读取多次或者说为什么我们希望模型读取多次在使⽤ai coding⼯具时我们有时会看到模型输出“让我看看是否已经完成了所有变更”因为模型在进⾏write时能够感知到的只是进⾏了这个⾏为⽽并没有看到这个⾏为的“影响”。
在coding场景中“影响”指的是修改后代码的内容。
为了解决read_full_file ⼯具的⻓上下⽂问题可以引⼊按块读取⼯具read_block_file即模型在调⽤⼯具时可以选择读取的⾏的数量在理想情况下模型可以只读取部分内容String readBlockFile(String path,int startLine,int lineCount){ //这里去读取文件内容然后return出去 }但这个⼯具同样也存在其他问题模型并不知道需要的内容在哪可能还是会多次调⽤块读取⼯具最后把整个⽂件都读取这反⽽导致了和模型的更多次交互增加了成本。
模型读取块的时候可能忽略了后续代码的影响导致思路错误。
输⼊的token也是会计费的⽤块⼯具读取完整的⽂件内容⽐直接读取完整的⽂件内容会增加多次重复上下⽂的调⽤导致成本的上升。
在最坏情况下需要的逻辑在⽂件末尾⽐read_full_file花费更多的成本且上下⽂更多因为还有⼯具调⽤并且和write⼯具联合使⽤时的问题仍然存在。
为了解决write⼯具联合使⽤时的问题我试图引⼊“按需卸载”的策略即在发现write⼯具后判断⽂件内容已经变更时就去掉历史调⽤中的read⼯具的返回值于是我将⼯具划分为两个类型即读和写当读写在操作同⼀个实体这⾥指⽂件时如果有写操作则卸载掉上次的读操作但这导致模型的幻觉现象变得更加严重深⼊分析了模型的输出后我发现并不能实时卸载应该延迟⼀段“时间”⼀些读写操作后再卸载否则模型很难感知到上次的⾏为容易出现重复操作。
简单来说就是保持最近的⼏次操作例如50次。
在aone copilot中使⽤了类似的思路⼤约只会保留最近250次的操作内容可以右键打开 devtools来查看交互的对话内容。
但是这个思路只能解决read、write⽂件的⻓上下⽂问题难以推⼴到grep、getDependency等⼯具上并且在⼯程上实现不够优雅。
暂且记下这些问题回过头来先看write⼯具write⼯具⾄少需要2种块替换完整覆写String replace(String path,String search,String replace){ //找到search块并替换为replace } String write(String path,String content){ //直接覆盖path的内容如果不存在则创建一个文件 }write⼯具的主要问题是⼯具调⽤内容较多相⽐read⼯具write只需要确保内部替换逻辑是准确的且在出现问题时能够准确反馈问题可以让模型重新推理即可但在实际测试中和模型及框架有关的两个点需要注意模型⼏乎不会产出\r符号因此如果项⽬是在windows下操作的需要注意\r符号。
模型在输出\t时容易多⼀次转义例如参数需要为\t但模型输出\t这应该是通过json格式约束模型输出⼯具调⽤导致的问题。
write⼯具中也有path参数因此也需要类似read⼯具的路径推测能⼒来降低模型进⾏⼯具调⽤失败的概率。
其他的读⼯具都可以参考read_file的问题即信息过期、冗余等问题。
完整读 的缺陷上下⽂爆炸⼤⽂件直接塞⼊上下⽂。
路径模糊模型可能传⼊类名、缺后缀等需⽀持模糊匹配。
内容过期write 后未刷新 read 内容导致历史响应冗余。
部分读 的局限模型不知关键代码位置可能多次调⽤反⽽增加成本。
与 write 联⽤时仍存在重复内容问题。
最坏情况下需读末尾⽐全读更耗 token。
“按需卸载”策略的陷阱早期尝试在 write 后⽴即移除旧 read 响应结果加剧幻觉——模型因缺乏⾏为反馈⽽重复操作。
实践表明应延迟卸载例如保留最近 50–250 次操作让模型充分感知⾏为影响。
⼯具的⾏为和影响回过头来思考⼈在coding场景下的⾏为当⼈在进⾏编码时⼀直在观察ide中打开的代码⽂件通过键盘对代码⽂件进⾏编辑光标位置当需要切换编辑的位置时将光标移动到新的位置随后开始⼀段新的输⼊。
通过拟态来优化⼯具的设计思路当⼈在进⾏编码时⼀直在观察的是IDE的界⾯同时通过⿏标键盘在和这个界⾯中的元素进⾏交互屏幕是有限的所以我们观察到的内容也是有限的这和我们期望的agent的上下⽂是“固定”的⾮常类似。
当模型试图进⾏⼀次⼯具调⽤时本质上是为了“观察”或“影响”环境也可以说是为了“读”和 “写”环境这是模型主导的“⾏为”环境则是agent的具体业务需要的信息例如在coding场景中可以把代码⽂件、⽂档等视为“环境”。
当⼯具调⽤结束时将⼯具返回的内容组装到上下⽂中就实现了让模型观察环境或是了解造成的影响。
在现有思路下⼯具包含了两个职责⾏为影响的反馈以read_file为例实际上这个⼯具的⽬的是“获取⽂件内容”并发送给模型⾏为是获取指定⽂件的内容影响是在上下⽂中增加⽂本的内容最终发送给模型使得模型看起来像是阅读了代码似的。
⽽当⼈在阅读⽂件时实际上是进⾏了⼀次“打开⽂件”的⾏为然后造成了IDE现在显示我们“打开⽂件”的内容所以我们语⾔模型可以通过“看”屏幕来阅读⽂件内容。
基于这个思路我在system prompt中增加了⼀个固定存在但内容“实时”更新的块这个块存储模型看到的事实同时不再有读⽂件的⼯具⽽是变成了open_file和close_file两个操作当模型调⽤open_file⼯具时是进⾏了⼀次“⾏为”⽽⼯具的影响是“⾏为的结果”以及“IDE中显示⽂件内容”。
实时更新是指每次发送给模型前进⾏更新String openFile(String path){ //如果成功在ide中记录path被打开返回已经成功打开文件 //如果失败原因是什么 }每次组装发送给模型的内容时重新⽣成IDE的内容IDE中包括“⽂件内容”。
参考这个思路我们可以将“⽬录”、“搜索”、“引⽤关系”、“变更清单”、“TODOLIST”等⼯具都视为IDE中的模块并提供“⾏为⼯具”来调整这些块的内容。
同时甚⾄可以将这些块的展示/隐藏也全权交给模型决策即由模型⾃主管理。
例如我们现在打开的⽂件较多可以在上下⽂中增加“警告信息”让模型将不重要的⽂件进⾏关闭。
打开的某个⽂件较⼤让模型聚焦到某个块打开的⽬录已经使⽤完毕了搜索过程模型⾃主的关闭⽬录打开的⽂件已经不需要再使⽤了模型⾃主的关闭此⽂件等等但⼈和模型还是有本质上的区别抛开逻辑能⼒的差异最重要的是“记忆”⼈可以“记住”刚刚打开的⽂件即使现在关闭了⼤概也能记得内容并基于“记忆”中的内容来对当前打开的⽂件进⾏操作⽽LM模型我们知道它是没有记忆的之所以有“记忆”的假象只是因为在上下⽂中包含了完整的信息。
为了解决这个问题我们可以给ide⼀个专⻔的“记忆”模块。
记忆和遗忘说到记忆我们的根本⽬的是让模型“记住”那些“需要”的信息并且基于这些信息给出准确的“判断”最佳⽅式是把所有的“⾏为”和“影响”都放在上下⽂中只要模型⾜够“聪明”就⼀定能做出最准确的判断但我们知道语⾔模型的上下⽂是有限的且基于语⾔模型的原理我们知道上下⽂中的内容不能过多否则会导致模型“性能”下降。
当⼈在阅读了⽂件后可以直接关闭或切换到其他⽂件进⾏后续⼯作这是因为⼈记住了⽂件中的“关键”内容⽽⾮记住了完整的⽂件内容。
我们则需要⼿动在上下⽂中增加“关键信息”以便让模型“记住”关键信息在上下⽂充⾜的情况下⾸选保留完整的⽂件内容随着模型的逐步深⼊上下⽂也开始捉襟⻅肘了此时在系统提示词的引导下模型会开始试图关闭或⼯程上主动出发关闭⽂件时需要对即将关闭的⽂件进⾏⼀次关键信息提取然后将关键信息记录到⼀个较⼩的备忘录中以实现让模型仍然记得刚刚关闭的⽂件中的关键信息我们仍然可以借助⼀个subagent来进⾏关键信息提取⽽如何判断⽂件的关键信息则由主agent给出当主agent打开⼀个⽂件时需要同时给出此操作的⽬的让subagent基于“⽬的”进⾏关键信息提取。
随着探索的继续深⼊备忘录的⼤⼩也到达了上限我们需要从上下⽂中真正的删除内容最佳⽅式仍然是让模型⾃主管理哪些部分需要被移除哪些部分需要保留但也可以使⽤简单的先进先出或者策略。
同时因为⾏为和影响的分离我们可以针对每个部分的特点来单独设计压缩、裁剪、合并等⾏为更加⾼效的利⽤上下⽂来释放模型的能⼒。
▐事实和⾏为在“记忆”中有⼀部分⾮常特殊的内容即⼯具调⽤的记录这是告知模型“已经做过”的内 容。
但有些模型的训练过程中会专⻔对⼯具调⽤进⾏训练⽀持functioncalling的模型因⽽导致了⼀些特殊的规则例如function call 和function response需要成对出现unction call 和function response需要使⽤特殊格式传递给模型例如下⾯⼀个询问天⽓的简单示例user:今天天气怎么样 assistant:function_call getDate agent:function_response
assistant:function_call getWether
agent:function_response 晴天 assistant:今天是
天气睛在⼀些instruct模型中如果不使⽤这种形式模型可能会出现⽆限循环调⽤⽅法。
因此在agent应⽤中需要将“记忆”划分为两部分事实记忆和⾏为记忆。
⾏为记忆使⽤function call/response 的形式在上下⽂中体现⽽事实记忆则通过诸如打开的⽂件内容、操作过的⽂件列表、diff内容、备忘录、todo等形式。
通过上述⽅式组织上下⽂可以使得上下⽂保持在⼀定⼤⼩内既能够充分利⽤上下⽂窗⼝也可以避免上下⽂快速膨胀导致的性能快速下降。
▐传播和继承按照上述思路上下⽂被划分成⼀些固定的块例如diff、路径、备忘录、todo等我们可以通过xml将这些块进⾏区分组织成⼀个结构化的上下⽂。
ide open_file文件路径/open_file todo待办/todo note_book备忘录/note_book /ide⚠在使⽤chat和模型进⾏交互时需要将ide内容放⼊system prompt否则容易被模型遗忘。
在上⽂的思路下模型的⾏为和影响被拆分且每个部分也被⾃然的拆分因此我们可以针对每个任务的特点来组装上下⽂信息充分利⽤有限的上下⽂。
⽽“影响”天然就是上⼀次⼯作的结果和过程的直观展现新的⼯作可以基于上⼀轮的“影响”继续进⾏。
在⾯向multi agent或是sub agent时“影响”被继承并转向另⼀个维度的⼯作例如deep search收集知识的过程中可以被“评估者”直接评估知识是否收集完全、代码⽣成时则可以直接利⽤deep search收集的知识进⾏⼯作。
在多轮对话中“⾏为”和“影响”均可以被继承模型可以⽆缝的接受⽤户新的输⼊后开始新的⼯作。
结语在我看来上下⽂⼯程是⼀个复杂且不断发展的⼤模型下的⼯程产物本质上是由于语⾔模型能⼒的不⾜⽽出现的⼀种⼯程上的妥协随着语⾔模型能⼒的增强或许在未来的某⼀天我们可以直接依赖模型的能⼒⽽不再需要复杂的上下⽂⼯程但是以⼯程应⽤的视⻆来看资源的⾼效利⽤、性能的极致优化永远是⼯程师的追求。
最后近期科技圈传来重磅消息行业巨头英特尔宣布大规模裁员2万人传统技术岗位持续萎缩的同时另一番景象却在AI领域上演——AI相关技术岗正开启“疯狂扩招”模式据行业招聘数据显示具备
年大模型相关经验的开发者在大厂就能拿到50K×20薪的高薪待遇薪资差距肉眼可见业内资深HR预判不出1年“具备AI项目实战经验”将正式成为技术岗投递的硬性门槛。
在行业迭代加速的当下“温水煮青蛙”式的等待只会让自己逐渐被淘汰与其被动应对不如主动出击抢先掌握AI大模型核心原理落地应用技术项目实操经验借行业风口实现职业翻盘深知技术人入门大模型时容易走弯路我特意整理了一套全网最全最细的大模型零基础学习礼包涵盖入门思维导图、经典书籍手册、从入门到进阶的实战视频、可直接运行的项目源码等核心内容。
这份资料无需付费免费分享给所有想入局AI大模型的朋友扫码免费领取全部内容部分资料展示
AI大模型学习路线图
全套AI大模型应用开发视频教程从入门到进阶这里都有跟着老师学习事半功倍。
大模型学习书籍文档
AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。
大模型大厂面试真题整理了百度、阿里、字节等企业近三年的AI大模型岗位面试题涵盖基础理论、技术实操、项目经验等维度每道题都配有详细解析和答题思路帮你针对性提升面试竞争力。
大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。
学会后的收获• 基于大模型全栈工程实现前端、后端、产品经理、设计、数据分析等通过这门课可获得不同能力• 能够利用大模型解决相关实际项目需求 大数据时代越来越多的企业和机构需要处理海量数据利用大模型技术可以更好地处理这些数据提高数据分析和决策的准确性。
因此掌握大模型应用开发技能可以让程序员更好地应对实际项目需求• 基于大模型和企业数据AI应用开发实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能 学会Fine-tuning垂直训练大模型数据准备、数据蒸馏、大模型部署一站式掌握• 能够完成时下热门大模型垂直领域模型训练能力提高程序员的编码能力 大模型应用开发需要掌握机器学习算法、深度学习框架等技术这些技术的掌握可以提高程序员的编码能力和分析能力让程序员更加熟练地编写高质量的代码。
扫码免费领取全部内容这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。
本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。
这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】