Agentic Coding场景下基于职责分离的上下文管理思路，提升编码效率

本文提出了一种在Agentic Coding场景下基于职责分离思想的上下文管理新思路将工具调用解耦为行为和影响通过结构化、模块化、动态组装的上下文设计替代传统做法。同时引入行为-影响分离、“记忆/遗忘机制”、事实与行为记忆区分等策略系统性缓解长上下文导致的注意力稀释、信息过载等问题提升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编码。StringreadFullFile(String path){⚠注意⼯具的返回值也是上下⽂或者说提示词的⼀部分read_full_file有⼀个显⽽易⻅的问题“完整的⽂件可能很⼤”导致上下⽂快速膨胀。此外还有⼀些和模型的特点相关的问题在找不到路径时需要明确告知模型 “xx路径不存在”⽽不能告知模型“”否则模型可能会陷⼊⼯具调⽤的⽆限循环qwen系列⽐较明显。模型输⼊的path不⼀定准确可能输⼊的是类的限定名、⽂件名或是缺失部分路径、缺失⽂件后缀等。对于path不准确的问题可以基于⼀个简单的思路来进⾏处理即先搜索在读通过关键词匹配对path进⾏搜索如果能定位到唯⼀的⽂件则读取此⽂件否则明确告知模型现在有多个相似的⽂件需要模型重新再⽣成⼀次⼯具调⽤。在read⼯具和write⼯具混⽤的情况下read_full_file还会出现⼀个新的问题我们先不关注write⼯具的具体实现只需要知道write后⽂件内容肯定发⽣了变化同⼀份⽂件内容在编辑后已经失效了需要重新读取⽂件内容⽽历史⼯具调⽤的respone和新的response存在⼤量重复如果是多次编辑则会导致上下⽂快速膨胀。这是因为我们将⽂件内容放在⼯具调⽤的返回值中发送给模型的消息类似于下⾯的格式tool_call:read_full_file filePath为什么模型需要读取多次或者说为什么我们希望模型读取多次在使⽤ai coding⼯具时我们有时会看到模型输出“让我看看是否已经完成了所有变更”因为模型在进⾏write时能够感知到的只是进⾏了这个⾏为⽽并没有看到这个⾏为的“影响”。在coding场景中“影响”指的是修改后代码的内容。为了解决read_full_file ⼯具的⻓上下⽂问题可以引⼊按块读取⼯具read_block_file即模型在调⽤⼯具时可以选择读取的⾏的数量在理想情况下模型可以只读取部分内容StringreadBlockFile(String path,int startLine,int lineCount){但这个⼯具同样也存在其他问题模型并不知道需要的内容在哪可能还是会多次调⽤块读取⼯具最后把整个⽂件都读取这反⽽导致了和模型的更多次交互增加了成本。模型读取块的时候可能忽略了后续代码的影响导致思路错误。输⼊的token也是会计费的⽤块⼯具读取完整的⽂件内容⽐直接读取完整的⽂件内容会增加多次重复上下⽂的调⽤导致成本的上升。在最坏情况下需要的逻辑在⽂件末尾⽐read_full_file花费更多的成本且上下⽂更多因为还有⼯具调⽤并且和write⼯具联合使⽤时的问题仍然存在。为了解决write⼯具联合使⽤时的问题我试图引⼊“按需卸载”的策略即在发现write⼯具后判断⽂件内容已经变更时就去掉历史调⽤中的read⼯具的返回值于是我将⼯具划分为两个类型即读和写当读写在操作同⼀个实体这⾥指⽂件时如果有写操作则卸载掉上次的读操作但这导致模型的幻觉现象变得更加严重深⼊分析了模型的输出后我发现并不能实时卸载应该延迟⼀段“时间”⼀些读写操作后再卸载否则模型很难感知到上次的⾏为容易出现重复操作。简单来说就是保持最近的⼏次操作例如50次。在aone copilot中使⽤了类似的思路⼤约只会保留最近250次的操作内容可以右键打开 devtools来查看交互的对话内容。但是这个思路只能解决read、write⽂件的⻓上下⽂问题难以推⼴到grep、getDependency等⼯具上并且在⼯程上实现不够优雅。暂且记下这些问题回过头来先看write⼯具write⼯具⾄少需要2种块替换完整覆写Stringreplace(String path,String search,String replace){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中显示⽂件内容”。实时更新是指每次发送给模型前进⾏更新StringopenFile(String path){每次组装发送给模型的内容时重新⽣成IDE的内容IDE中包括“⽂件内容”。参考这个思路我们可以将“⽬录”、“搜索”、“引⽤关系”、“变更清单”、“TODOLIST”等⼯具都视为IDE中的模块并提供“⾏为⼯具”来调整这些块的内容。同时甚⾄可以将这些块的展示/隐藏也全权交给模型决策即由模型⾃主管理。例如我们现在打开的⽂件较多可以在上下⽂中增加“警告信息”让模型将不重要的⽂件进⾏关闭。打开的某个⽂件较⼤让模型聚焦到某个块打开的⽬录已经使⽤完毕了搜索过程模型⾃主的关闭⽬录打开的⽂件已经不需要再使⽤了模型⾃主的关闭此⽂件等等但⼈和模型还是有本质上的区别抛开逻辑能⼒的差异最重要的是“记忆”⼈可以“记住”刚刚打开的⽂件即使现在关闭了⼤概也能记得内容并基于“记忆”中的内容来对当前打开的⽂件进⾏操作⽽LM模型我们知道它是没有记忆的之所以有“记忆”的假象只是因为在上下⽂中包含了完整的信息。为了解决这个问题我们可以给ide⼀个专⻔的“记忆”模块。记忆和遗忘说到记忆我们的根本⽬的是让模型“记住”那些“需要”的信息并且基于这些信息给出准确的“判断”最佳⽅式是把所有的“⾏为”和“影响”都放在上下⽂中只要模型⾜够“聪明”就⼀定能做出最准确的判断但我们知道语⾔模型的上下⽂是有限的且基于语⾔模型的原理我们知道上下⽂中的内容不能过多否则会导致模型“性能”下降。当⼈在阅读了⽂件后可以直接关闭或切换到其他⽂件进⾏后续⼯作这是因为⼈记住了⽂件中的“关键”内容⽽⾮记住了完整的⽂件内容。我们则需要⼿动在上下⽂中增加“关键信息”以便让模型“记住”关键信息在上下⽂充⾜的情况下⾸选保留完整的⽂件内容随着模型的逐步深⼊上下⽂也开始捉襟⻅肘了此时在系统提示词的引导下模型会开始试图关闭或⼯程上主动出发关闭⽂件时需要对即将关闭的⽂件进⾏⼀次关键信息提取然后将关键信息记录到⼀个较⼩的备忘录中以实现让模型仍然记得刚刚关闭的⽂件中的关键信息我们仍然可以借助⼀个subagent来进⾏关键信息提取⽽如何判断⽂件的关键信息则由主agent给出当主agent打开⼀个⽂件时需要同时给出此操作的⽬的让subagent基于“⽬的”进⾏关键信息提取。随着探索的继续深⼊备忘录的⼤⼩也到达了上限我们需要从上下⽂中真正的删除内容最佳⽅式仍然是让模型⾃主管理哪些部分需要被移除哪些部分需要保留但也可以使⽤简单的先进先出或者策略。同时因为⾏为和影响的分离我们可以针对每个部分的特点来单独设计压缩、裁剪、合并等⾏为更加⾼效的利⽤上下⽂来释放模型的能⼒。▐****事实和⾏为在“记忆”中有⼀部分⾮常特殊的内容即⼯具调⽤的记录这是告知模型“已经做过”的内 容。但有些模型的训练过程中会专⻔对⼯具调⽤进⾏训练⽀持functioncalling的模型因⽽导致了⼀些特殊的规则例如function call 和function response需要成对出现unction call 和function response需要使⽤特殊格式传递给模型例如下⾯⼀个询问天⽓的简单示例user:今天天气怎么样在⼀些instruct模型中如果不使⽤这种形式模型可能会出现⽆限循环调⽤⽅法。因此在agent应⽤中需要将“记忆”划分为两部分事实记忆和⾏为记忆。⾏为记忆使⽤function call/response 的形式在上下⽂中体现⽽事实记忆则通过诸如打开的⽂件内容、操作过的⽂件列表、diff内容、备忘录、todo等形式。通过上述⽅式组织上下⽂可以使得上下⽂保持在⼀定⼤⼩内既能够充分利⽤上下⽂窗⼝也可以避免上下⽂快速膨胀导致的性能快速下降。▐****传播和继承按照上述思路上下⽂被划分成⼀些固定的块例如diff、路径、备忘录、todo等我们可以通过xml将这些块进⾏区分组织成⼀个结构化的上下⽂。ide⚠在使⽤chat和模型进⾏交互时需要将ide内容放⼊system prompt否则容易被模型遗忘。在上⽂的思路下模型的⾏为和影响被拆分且每个部分也被⾃然的拆分因此我们可以针对每个任务的特点来组装上下⽂信息充分利⽤有限的上下⽂。⽽“影响”天然就是上⼀次⼯作的结果和过程的直观展现新的⼯作可以基于上⼀轮的“影响”继续进⾏。在⾯向multi agent或是sub agent时“影响”被继承并转向另⼀个维度的⼯作例如deep search收集知识的过程中可以被“评估者”直接评估知识是否收集完全、代码⽣成时则可以直接利⽤deep search收集的知识进⾏⼯作。在多轮对话中“⾏为”和“影响”均可以被继承模型可以⽆缝的接受⽤户新的输⼊后开始新的⼯作。结语在我看来上下⽂⼯程是⼀个复杂且不断发展的⼤模型下的⼯程产物本质上是由于语⾔模型能⼒的不⾜⽽出现的⼀种⼯程上的妥协随着语⾔模型能⼒的增强或许在未来的某⼀天我们可以直接依赖模型的能⼒⽽不再需要复杂的上下⽂⼯程但是以⼯程应⽤的视⻆来看资源的⾼效利⽤、性能的极致优化永远是⼯程师的追求。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】