面试被问Agent上下文管理，80%的人卡在这套压缩逻辑上 #Ai #Ai大模型 #Agent #人工智能 #大模型

每天体验一场大场面试。 今天我们要面的是：如何优雅地设计向神问亚索。 某扣的源码泄漏有一阵子，但你发现没有，全网都在讲他多能写代码，几乎没人拆他那套上下文亚索的黑箱逻辑，这玩意才是真正值钱的地方。 今天就干你一件事，以源码为蓝本，带你从里头往外扒，看看他到底怎么在20万Token的窗口里，做到跟个没事人一样，跟你聊几千轮还不带忘事的。 你可能会想，20万不少了。但你想想，每一次对话发出去的不光是你打的那行字，还有一整套系统提示词、所有可用工具的说明书、项目级的记忆文件，再加上从第一轮开始，你们俩所有的聊天记录全得塞进这同一个窗口。 前面那些固定的东西先占掉一部分，模型自己回答还得预留空间，真正留给聊天记录的，大概也就18万左右。 拿一个重构订单模块的真实场景来说，你让模型把Out of Service读一遍。好，一个800行的文件进来了，跑完测试，控制台吐出200行日志也进来了。你让它改个方法，改之前啥样、改之后啥样，LIFE对比又占一块。你俩聊个十几轮，光这些文件内容、命令结果就吃进去一两万Token。真正干活的时候，几十轮下来，十几万Token就没了，窗口马上就要见底。 那怎么收拾呢？直接把旧内容扔给模型，让它帮我总结一下。你猜后果是什么？每次总结，都是一次全新的API调用。 十几万Token全量计费。 钱花得你肉疼。 还有干等好几秒，而且总结完好多细节就真丢了，再也找不回来。 所以Mode的设计哲学就四个字：省事优先。 能不花钱就不花钱，能少丢信息就少丢。 它手里攥了一套组合拳，从最轻量到最重量，一层一层往上加码，咱们一层一层扒。 另外给小鸿的粉丝免费分享一份AI大模型的学习路线和面试题库，它涵盖了Agent智能体、RAG检索增强、Transformer架构、大模型深度陷阱等内容。粉丝进群，在置顶自取即可。 你同时让模型读三四个文件，结果全挤在一条消息里返回，这条消息本身就可能超限了。 Cloud Code的处理特别像搬家：大件家具别全往车上塞，先暂存到楼下的储物间，身上只带一本目录。它会把那些超大的文件内容写到本地硬盘，消息里只保留一个缩略版的开头，模型真要用到完整内容的时候，拿着目录再去读一次就行了。 这里有个非常冷门，但极关键的设计叫决策冻结。一个文件第一次被处理的时候，系统就会决定它是被看成缩略版，还是保留完整内容，而且这个决定一旦做了，后面永远不会变。 为什么？因为服务端的KV缓存，是从请求的开头一个token、一个token往后比对的，中间但凡有一条消息变了样，从那条往后的缓存全部失效，全都得重新计费。所以整条消息一个字都不能动，才能让缓存一直命中。 上一招只是把消息里的附件缩小了，消息本身还在。 这一招更狠，整轮对话直接删除。 你之前说不对，路径错了，换一个路径还是不对。这几个来回走完之后，后面根本用不上，模型也不需要记住这些试错的过程。 Claw code直接把它们铲走，铲完以后，它也会告诉你后面几道工序腾出来多少空间了，避免后面的误判，不至于一激动，就把最重的那招扔出来。 读到第三十轮的时候，你那个order service，早就被改过好几把了。第一轮读进来的那份完整文件内容，现在看着就是个占地方的过期货。 压缩钉上的就是这些东西，所有读文件、跑命令搜索、改文件产生的旧结果，本质上都是某一个时刻的快照，过期了就清掉了。 但注意你的提问、模型的思考、你给它反馈，这些是对话骨架，它不会动。 这招最骚的地方，在它分两条路走。当你连续聊，缓存还是热的时候，问题来了：想清掉旧结果腾位置，但直接改消息内容缓存就废了。那它怎么做？它不碰你本地的消息，而是给服务端发一个编辑指令，说把第几条消息里那个旧文件结果从缓存里抹掉。 服务端收到请求，拿来一对比，发现消息本体和上次一模一样，缓存全部命中，然后单独执行抹除操作。结果就是空间腾出来了，但请求内容一个字没改，缓存照样省。 但你如果中间开会去了，一个多小时没聊，服务端那边缓存早凉了，下次请求，反正整个前置都要重算。 那它还客气什么？直接简单粗暴，把旧文件结果全换成一句“内容已清除”。这条路人称留五条，最近五条结果保留，更早的全换成占位服务。前三招都是在删东西，这招开始有了存档的味道。比如你重构订单模块，经历了三个阶段：到处翻文件的探索器、确定方案的设计器、落地实现的编码器。上下文折叠这个环节，可能只把最早的探索器压成一小段摘要，但设计和编码器的原文原封不动给你留着。它不像粗暴的全文总结那样，把所有细节搅成一锅粥，而是有选择性地折叠掉最不重要的部分，把最有价值的上下文保住。只要折叠后腾出来的空间够用，最后一季最重的杀招就不会触发。前面四招都扛不住了，才轮到它完整压缩。但这个东西贵而且重，所以CodeCode不会傻到把整个对话重新发给模型说“帮我总结一下”，那样缓存就全废了，十几万Token按全新请求计费。它的骚操作是这样的：它派了一个分身Agent，但这个分身为了蹭主对话的缓存，把请求内容伪装得跟主对话一模一样，前面那一大坨系统提示词、工具定义、历史消息完全不改，只在整个请求的最后偷偷摸摸加了一句“请给我总结”。因为前缀完全一致，服务端的缓存命中率几乎100%，等于这趟总结的绝大部分计算是蹭来的，只给最后那点新内容付费。但它有个要命的副作用，分身为了伪装，必须带着全套工具定义，模型一看见工具列表。 就容易手痒。 你让它乖乖写总结，它可能忍不住真的去调一个搜索，或读文件的工具。一旦它调了工具，这些任务就是用嘴说话，手不准碰任何工具。你敢调用工具，直接判定你本次任务失败。 万一哪个不听话的分身，还是手贱调了，就直接切到普通模式，老老实实发一个新结构的总结请求。贵是贵点，但好歹能拿到结果。 总结出来的东西，是个固定的九段式结构：你最初要干什么，用了哪些技术栈，动过哪些文件和关键代码，踩过什么坑，又是怎么提案的，你说的每一句关键指令，还有哪些没做完，现在正在做什么，以及下一步该干什么。就是怕模型在层层总结的过程中，悄悄把你的意思给掰弯了。 总结写完还不算完，系统还得重建现场。总结里写着，我们改过order service，但模型接下来要接着改，它不能只对着描述改，它要的是文件现在的真实内容。所以系统会把最近读过的、最多五个文件，重新从硬盘捞出最新版本贴回去，同时把当前的计划、用过的技能、全套工具定义再声明一遍，最后把这些拼好，打上一个分界标记，再把那篇九段式总结贴上去。 如果这次压缩是系统自动触发的，它会偷偷在你耳边加一句：直接接着干，别打招呼别复述，就当你刚才什么都没看见，什么也没看见。这就是为什么你聊着聊着，根本感觉不到压缩发生过。 以上五招是压缩链，但Cloud Code还有一个更省钱的玩法。 叫绘画记忆。你正常聊天的时候，后台一直有个绘画提取器在跑。每当新增的对话内容攒到一定量，它就悄悄派个分身，把刚才那一段增量里的要点，寄到一个笔记文件里。这个分身确实调用模型，也确实计费，但它每次只处理从上次记录到现在这一点新内容，量小，便宜，而且是趁你聊天的间隙偷偷干的，不占用你的主线。等到真需要压缩的时候，Cloud Code一看，这份笔记刚好是最新的，直接拿来就当总结用了，连让模型通读几十万token的步骤都省了。本来一次压缩是搬一整座山，它把它拆成了平时没事捡两颗石子，攒着攒着山早就搬完了。当然这整套机制也不是万无一失，如果自动压缩连续失败三次，系统直接拉闸，这场对话里再也不自动尝试。这不是说说而已，Cloud Code真的出过一场对话连续压缩失败三千多次的事。说到底Cloud Code的上下文，本质上是一场在性能、成本、体验三者之间走钢丝的艺术，每一层策略的目标都指向同一个结果：让你感觉它永远记得住，却永远不用为这份技术多花冤枉钱，甚至根本察觉不到，它在背后替你干了这么多事。