agent记忆压缩方法

大家一定要记住，为什么会有龙虾？龙虾为什么会这么火？是因为以前的大模型有几个缺陷，包括刚刚企业私有化， ai 没有做好的一个核心点，就首先他是没有记忆的，记你就全记吧，记不下来。大家知道大模型有个叫上下门窗口，上门窗口几百 k 也就存几十万字， 那很多数据都往里 c， 而且它 c 多了还有什么问题？你知道上门太长还你知道什么问题吗？记模糊了就是他找不到重点了， 这就是为什么上就他记了很多东西以后，你就发现他在写东西有时候会变笨，他变笨的核心原因是他以前的东西记太多以后，你再想他的原理什么是根据这么多词的概率推荐下一个词， 当那边词太多以后，他不就模糊了吗？所以他抓不住重点了。所以在在这个很多这个大模型产品里，对记忆都是一个非常头头的东西， 再一个就他也没有办法主动去记，对吧？有的新东西来了，不断出现的事，他也没有办法变成一个重点的归类。所以呢，今天龙虾 tcclor 就 有了文件记忆，文件记忆又分好几层啊，再一个就是定时器，再一个就是用工具，再用机制等等这些。所以你们一定要把这几这两个东西记住，一个叫 cron， 一个叫工具， 这两件事情还有他的记忆。就有的时候我跟三万交流的时候，我会说我们曾经发生过什么什么事，前天我让你做个什么文档，你先想一下，你以为我是真的让他想吗？我让他想一下，是把我关注的文档给他调到他的上文里，他 想完之后他会把那文档吐给你们，他吐给你，过程就装到他大脑里。这个事我在这有次文档跟他讲，所以这里面有个很重要的那个，就是你真的要跟他记忆搞好，要一个长问题，至少分两步，你看刚才我是怎么把一个国产模型用的这么好的， 我都是在跟他分两步，我第一步是说我要一个什么什么你经典啊什么，然后我跟他说，我说怎么样，你这个工作步骤都给我讲一遍，看见没有？这是第一步，就我不会让他直接干活，让他直接干活他就要去把这个任务分的很长，他很多地方就太碎了嘛。所以我第一步让他总结这个工作步骤， 这就第一步，等他总结步骤完了，再再让他去做这第二步，然后再让他发一个测试，这样是第三步， 也就说你今天要真的去理解他的时候你才知道，哦，原来我去训他的时候，我是要一点一点的层层递进的去聊 这个基因怎么去利用它，你去问龙虾，你跟他探讨你就知道了。大家去要 c m c 点 b o t 啊，去下载一键就知道了，就可以跟着我的教程一点点往前走，非常简单的原理，但是得花点时间真正实践养龙虾就用 ez curl。

你让 agent 读了十篇论文，结果他只记得大概方向，可你追问细节，比如第三篇用什么数据集，他却答不上来。 其实哪怕给他百万 topen 的 窗口，也不等于能记住所有细节。就像我们看完十小时视频，还是会忘记具体片段。真正的难点不是能装多少信息，而是关键时刻能不能精准提取。记忆系统要解决的就是这种智能的遗忘与剪辑。 今天我们会拆解记忆系统的四个核心问题。首先，为什么即使有超长上下文， agent 依然会遗漏细节？接着我们会比较短期记忆和长期记忆，看看他们各自解决什么难题。然后你会了解向量数据库如何帮助 agent 精准找回关键信息。 最后，我们还会介绍一种让 agent 主动反思和总结经验的方法。学完这些，你就能真正理解智能 agent 的 记忆到底难在哪里。 很多人以为上下文窗口越长， agent 就 能记得越多，其实不是这么简单。比如 gpt4， 虽然能处理十二万多个 token， 但输入太多不仅成本高、响应慢，而且模型反而容易漏掉细节。你让他回忆中间的内容，准确率会大幅下降。这就像强行背完字典，关键时刻却找不到某个词 场。上下文不是万能钥匙，记忆系统要做的是在海量信息中精准解锁，而不是全都塞进去。其实人类的大脑早就给了我们示范。 心理学把记忆分成三层，最短的是感觉记忆只有半秒，像一闪而过的画面。接下来是短期记忆，大约能维持三十秒，通常只能处理七个左右的信息。最后才是长期记忆，把真正重要的内容沉淀下来，让 a 阵变聪明。也需要借鉴这种分层结构，高效管理信息的存取和遗忘。 那具体怎么给 agent 装上短期记忆呢？最常见的方法就是只保留最近几轮对话，比如四到八千个 token， 大 概能覆盖三到五轮。这样 agent 既能记住你刚刚提到的地点和话题，又不会因为信息太多而混乱。像刚才的例子，用户问明天天气，再接着问后天， agent 就 需要靠短期记忆把北京这个条件延续下去。 这里的关键是用固定结构记录用户和助手的对话，既方便模型理解，也能防止信息越积越多导致系统崩溃。转期记忆只能记住最近几轮对话，但很多重要的信息其实早就被遗忘了。比如用户突然问之前推荐的 ai 框架叫什么，如果没有长期记忆， agent 根本答不上来。 现在我们用向量数据库帮 agent 保存历史经验。每次用户提问，系统都会把问题转成语义向量，在对话库里快速解锁相似内容，像三周前说过的 line chain， 就 能立刻找到。 这种方式不仅容量大，还能避免塞满上下文，解锁到的都是最相关的信息。存储信息其实并不难，难点在于怎么精准找到你要的内容。比如有人问上次那个戴眼镜的专家推荐了什么书，系统需要理解专家推荐和书之间的语义关系，而不是死板的匹配关键词。 解决这个问题，我们会把每条记忆变成一个高维向量，然后用和用户问题的向量算相似度，数值越接近一就越相关，最后挑出最相关的几条。为给大模型处理人脑其实不会记住所有细节，而是自动抓住关键特征。比如看完一部电影，我们往往只记得主角背叛了谁，哪些场景让人激动，结局有没有反转。 aj 的 记忆系统也是一样，不能死记硬背原始对话，而要把重要信息提取出来。比如用户喜欢红色尺码，四四二要买鞋子，这样解锁时就能快速锁定重点，避免被大量无用信息干扰。 如果 aj 把所有对话全都保存，比如三个月前用户说喜欢咖啡，昨天又说自己戒了咖啡，两条记忆都在，反而容易让 aj 混乱。 实际应用里，我们会得旧信息设置时间衰减，让新消息自动覆盖。老习惯还会定期清理掉不再重要的内容，比如过期的天气， 这个过程叫记忆反思，帮助 a 阵始终聚焦于最新最相关的信息。这里我们来看传统搜索和羽翼搜索的区别。 传统方法只会死板的匹配关键词，比如便宜和餐厅，结果经常不够准确。而羽翼搜索会结合上下文理解你真正的意图。比如你问上次那个便宜的餐厅在哪，他能推断出你想要之前提到价格低还需要具体地址的那家。最终他给出的是让你一下就能想起来的答案。 这其实就是查找及推理，不只是查找，更是理解和推断。这段代码就是短期记忆的典型实现， 它用一个列表保存最近几轮对话，每次加新消息时，如果超过设定的上限，就自动删掉最早的内容。这样无论对话多长， agent 总是只聚焦在最新的几轮，大大简化了上下文处理，也避免了内存被历史消息占满。 这种简单方式其实能满足绝大多数日常场景。这里用的是项链数据库，实现长期记忆。每次有新对话，系统都会用预训练模型把文本转成像料，和原文一起存下来， 解锁的时候，把你的问题也转成像料，然后算和每条记忆的相似度，找出最相关的几条。这样无论历史多长，都能精准定位到你想要的信息，效率和准确率都很高。 很多时候， a 证既要记住最近几轮对话的细节，又不能忘记用户长期的偏好。这段代码就是把短期记忆和长期记忆结合起来。每次用户发消息，短期模块先记录重要内容，再存进长期记忆。 a 证在生成回复时，会把当前对话和最相关的历史信息一起拼接，既保证对话连贯，又能用到很久以前的背景。这样无论用户怎么跳跃提问， a 证都能做到既不过载，也不遗漏关键信息。 除了简单存储，真正聪明的 agent 还要学会反思。比如每隔几条对话，系统就会让大模型总结这些内容的共同点，把核心模式提炼出来，形成高层次记忆。这样用户经常查不同城市天气， agent 就 能推断出他可能经常出差，下次推荐旅行装备时，建议就会更贴合实际。 这种定期反思，让 a 阵不仅记住细节，还能把握整体趋势。有时候单靠语义搜索，会遗漏像订单号这样的精确信息。这段代码先用关键词过滤，比如直接找出包含一二三四物的对话，然后再用语义排序，筛出和用户问题最相关的几条。 这样既保证了查找的准确性，也能理解上下文，让 agent 在 面对具体细节时不再犯糊涂。其实，大多数对话内容并没有长期保存的价值，我们可以像大脑一样按重要性给记忆分集，比如天气和闲聊只保留一小时，任务进展则在任务结束后清理，只有用户偏好和关键决策才永久保存。 代码里，我们给每条记忆打上标签和有效期，系统在定时自动清理过期内容，保证 agent 只记住真正重要的信息。这次的作业挑战就是让你为客服 agent 设计一个健忘的大脑，比如对话超过五轮，前面三轮内容要自动压缩成摘要，避免信息堆积。 遇到用户提订单号，系统要优先到长期记忆里查找相关订单。每聊十条，还要出发一次反思总结用户常问的问题。你需要用短期记忆管理当前对话，长期记忆保存历史订单，再用大模型生成摘药和反思。 想一想，如果用户要求删除信息，怎么让系统选择性遗忘？哪些内容又值得长期留存记忆？系统解决了 a 阵能记住什么，但真正决定 a 阵行为的是他到底是谁？为什么同样的记忆克服 a 阵和投言 a 阵反应完全不同，关键就在于系统提示，也就是 a 阵的 dna。 下集，我们会聊怎么用一句话定义 a 阵的人格，哪些系统提示最容易让 a 阵出错，以及如何防止 a 阵在复杂场景下人格分裂？ s 一 一八，我们一起来捏一个有灵魂的 agent。

家人们，生信圈又出黑科技了。之前小龙虾火遍全网，本以为分析效率够顶了，结果阿斯利康直接推出一个首款单细胞 rna 测序 ai 智能体 celtia， 把原本十五小时的手工单细胞分析，硬生生压缩到十分钟就搞定， 不用再手动八文献写脚本调参数了，丢个论文网址或 pdf， 它就能自动解析数据，跑全套标准化流程，还能全程追溯结果，一点不跑偏，二十五个癌症数据级测试全成功。 当然，它也并非完美，只能基于 clexpress 运行，不支持外部工具，对非标准数据格式的处理也稍显生硬。但这丝毫不影响它成为单细胞分析的效率利器， 以后再也不用被繁琐分析绊住，把精力聚焦于更有价值的假设验证，这才是科技赋能科研的真正意义。关注生信人，科研不迷路！

不管你的 a g 的 跑多久，服务器重启多少次提升， metal 的 agent 上下文都能瞬间无缝衔接，这才是真正的全天候助手，永远记得你是谁，你想要什么？没有长效记忆的 agent 永远只能做一次性的搜索引擎，成不了懂你的管家，每天早上都要重新加他一次。你喜欢什么？这你受得了吗？ 只需要一行配置，你的 a 技能就能用为蛤蟆体，它能把庞大的内存化变成结构化的相当数据库，随用随取，绝不超载。我们来具体看一下，如果没有记忆的话，他可能服务器崩溃，重启之后他就会醒来，就像个白痴。但如果有了记忆之后呢？他就能够从硬盘中恢复所有的偏好设置，来直接给你一个完美的一个答案。我们来看一看。 好，他现在已经想起来了，这完全模仿人类的大脑运动一致短期记忆在脑海里的过滤，有用的知识被提成语义记忆，并在需要时进行压缩巩固。这又是全天候智能的终极体验。你不再有上文耗尽的焦虑，哪怕你跟他聊了一年，他的回答依然敏捷精准，充满了对你的专属理解。 没有记忆的大脑只是计算记。记忆是将工具生活为伴侣的唯一桥梁。如果你也想让你的 ai 有 记忆，可以去试试，我是安迪，教你用 ai 解除工作自由。

在前两期内容里，我们深入探讨了写入上善乡和选择上善坊。这一期，我们来学习上善工程的第三个核心操作，压缩。 在开始之前，我们要精确界定压缩的对象，它针对的是那些即将进入上下文窗口原始且未经处理的信息流，其中最典型的就是永常的对话历史或者一次 api 返回的海量文本，其目的是在这些信息进入新一轮调用之前为其降噪和减负。 landchain 把压缩清晰地分为两大类，核心技术，上下文总结和上下文裁剪。我们可以通过宏观对比 来理解这两种策略的本质区别。从核心机制来看，总结是利用大语言模型进行智能提炼，它会理解并重写内容。 而裁剪则是基于规则的过滤，它直接丢弃部分内容。在优缺点方面，总结的优点是智能，能保留核心语义， 但缺点是速度慢且成本高，并且是一种有损压缩。相对而言，裁剪的优点是快速，成本几乎为零， 且对保留部分的信息能做到百分之一百保证。但缺点是比较笨拙，可能会粗暴地丢弃早期的重要信息。从适用场景来看，总结更适合处理那些信息量巨大且非结构化的关键节点，比如处理巨型工具返回结果总结长对话历史。 而裁剪则更适合作为一种常规的、低成本的维护手段，比如管理常规、对话历史，或者清理已消化的旧信息。接下来，我们深入了解这两种策略的具体实现。上下文总结是一种利用 l l m 自身能力来压缩信息的高级技巧，其本质是一个理解并重写的过程。 在智能体的设计中，它有三个非常核心的应用场景，一是总结对话历史。当一个 agent 与用户的交互轮次过多时，我们可以截取早期的对话部分，通过一次独立的 l l m 原调用， 将其提炼为任务概览、关键决策等核心摘药，然后用这份摘药替换掉宕长的原文。二是后处理工具反馈。 这在工程实践中极其重要。当 agent 调用了一个返回海量信息的工具，比如爬取了整个网页，我们不应该直接将几万字的 dtmail 原文作为观察结果喂给 agent。 正确的做法是先通过一个专门的总结提示，对这个返回结果进行处处理，提取出核心要点， 然后再将这份精炼后的摘要送入驻 agent 的 上限薄。三是 agent 间知识交接。在多智能体架构中， 当一个子 agent 完成研究任务需要向主 agent 汇报时，他提交的不应是完整的思考过程日记，而是一份通过总结提炼出的浓缩的工作报告。当然，总结也面临着核心挑战，那就是信息保真度。 正如原文所示的，过度激进的压缩可能导致微妙，但关键的上滑将丢失。这需要我们通过精心设计的压缩 prompt， 并配合分层的记忆系统来管理风险，确保关键的结论性信息能被写入更持久的结构化笔记中， 而不是在对话历史的压缩中被意外丢失。下面我们来看上下文裁剪。与需要 l l m 深度参与的总结不同，裁剪是一种更直接、更机械的过滤方法， 他不改变内容，只决定丢弃哪些内容。主要有两种实现方式，一种是硬编码启发式，最经典最常用的策略就是滑动窗口。我们设定一个固定规则，例如，在上下文中 永远只保留最近的十轮对话，当新的对话产生时，最旧的那一轮对话就会被自动机械的丢弃。它的优点是极其简单快速，成本几乎为零。但缺点也同样明显，这种一刀切的方式可能会粗暴的丢弃掉早期对话中砥砺任务基础的重要信息。另一种是训练一个裁剪器， 这是一个更高级的思路，可以看作是智能过滤。他不再依赖简单的硬编码的规则，而是通过训练一个专门的轻量级的分类模型，来判断上下文中的每一条信息是应保留还是可丢弃。 例如，这个模型可能会学到，如果一条消息是用户提出的核心问题，即使他很老，也不应丢弃。 这种方式比滑动窗口更智能，但缺点是需要额外的模型训练和维护，成本，实现更为复杂。总结一下， 今天我们学习了压缩上下文的两种核心策略。总结是，智能但昂贵的金链适用于高价值、信息量大的场景，而裁剪是快速但机械的丢弃适用于常规低成本的维护。在复杂的 a 阵的系统中，两者往往需要组合使用。至此， 我们已经掌握了写入、选择和压缩这三大操作。但在一个真正复杂的系统中，可能同时运行着多个任务、多个 agent， 如何确保它们各自的上下文互不干扰？这就引出了上下文工程的最后一个核心操作 隔离。下一期我们将探讨如何通过上下文隔离来构建稳定、可扩展的多任务和多智能体系统。感谢各位的观看，如果觉得有用，欢迎一键三连。

面试官问你， a 证的长短期记忆在生产环境里到底怎么落地实战？这是一道让百分之九十后人都会翻车的面试题。如果你张口就答，短期记忆靠滑动窗口上下文，长期记忆用下量库，那面试官多半已经在心里给你打叉了。 因为这种理论派的标准答案，在千万级并发症的生产环境里，纯粹是给自己挖坑。这坑有多深？咱看看这些纸上谈兵的惨痛代价。 用户报了个手机号，是幺三八开头，系统给错误召回成幺三九，这就叫事实扭曲。 再比如，用户第一轮明确说对花生过敏，聊到第五十一轮，系统把这事给忘了， 反手推荐个海鲜花生拼盘，这种致命遗忘，你敢直接上生产线吗？为什么会犯这种低级错误？因为大家都上了第一个伪命题的当。滑动窗口， 大家看这把剪刀， f i f o， 先进先出，他如果只顾着局部连贯，就会无情斩断用户的核心状态。像林冲花生过敏这种开局的核心信息， 聊着聊着就被剪掉扔进垃圾桶了。那大厂是怎么抢救失忆症的？大家看这儿，用 res 做双层动态缓存，第一层高频对话流， 保留最近五到十轮原始对话，负责聊天不冷场。最核心的是第二层动态状态机 stat， 咱们用轻量模型实时抽取关键事实， 像钉子一样钉死在 system prompt 里。只要绘画不断，核心记忆永远不丢，短期记忆保住了，咱们再看长期的坑。第二个伪命题来了，千万别迷信项链库，大家一定要记住，与意相似，绝不等于事实准确。 在姓名、手机号这种零容错场景下，纯靠模糊的项链解锁，那就是一场召回灾难。 既然单靠项链库不行，那大厂的长期记忆底线是什么？本视频的代码笔记，我放在这份两百万字 java 与 ai 模型学习笔记里了，里面包含 jvm、 reddit、 mq、 微服务、 ai 模型等三十多个技术站与一百多个项目场景实战笔记，还有不同工作年限同学的简历模板，以及一份 java 加 ai 的 三十天面试突击学习路线。需要的话再直接拿去 看。这座易购混合存储金字塔，塔尖必须是 mycircle 或 mongod db 存强势式标签要求零容错，腰部是 elastic search， 用 bm 二五算法做长文本的精确召回。最底层才是 vector db 向量库， 它只配做模糊语义的发散补充，强势时必须依赖精准读写下，量库绝不是核心塔建好了，咱们得拉开工业级引擎盖儿，看看真实的数据流转。第一波同步组装， 用户请求进来， readme recycle e s 并发去查主链路 r t 必须严格控制在五百毫秒以内。这时候大模型只是个没有感情的计算 cpu， 真正的记忆过滤全是成熟的存储组件干的。组装完，大模型给出回复了，那新记忆怎么存？第二波异步落盘，为了保障接口高可用，主链路必须零等待。我们把事件投递进 m q 消息队列， 走旁路去做意图分类和易购路由更新。把更新扔给 m q 之后，这步非常关键，千万别做算力刺客，如果让大模型定时定量去无脑总结，算力成本会直接爆炸。优 雅的解法是引入清量意图识别，只有当发现状态变更或新事实时，才事件驱动出发落盘，做到资源极简。 为了让这套架构坚不可摧，生产环境还会加上四大进阶防御。引入图数据库解决多实体关联，用标量前置过滤，极大降低召回错误，配合实时加离线，双链路覆盖隐性偏好。最后用严格的分级， t t l 控制成本 解锁和性能都优化到极致了。但在千万级病发下，还一个终极拷问等着你， 如果 ai 状态不一致怎么办？假设 m q 积压了，长期记忆没落盘，用户又提问了大模型读到了旧数据，产生致命幻觉，这就是经典的脏毒危机。别慌，咱们用分布式架构的四层兼顾防线来兜底， 第一， session 内状态永久优先。第二， res 双写临时兜底。第三，核心数据切分走同步入库。第四，套用版本号乐观锁加标记重试，彻底闭环兜底完成，闭环形成。到这里，咱们复盘一下，退去 ai 的 这层滤镜， 你看透它的系统本质了吗？ a 阵的记忆本质上就是多级缓存加一勾，同步加读写分离加事件驱动 进位，数据一致性。记住，大模型只是个计算节点，绝不是万能存储。这张图是工业级 agent 架构的全景阵型， 建议直接截图保存，从打破误区到一致性兜底，以图甚千言。我是 fox， 专注真实的硬核实战坑，觉得有用的兄弟点赞关注，咱们下期见！

哈喽大家，我们又来闲聊小龙虾吧，你们既然这么关心小龙虾这个 agent， 然后关于他这个怎么记得住啊？记忆问题，其实这个都是 agent 的 这个通用问题，那很多人一聊记忆就觉得这个很高深莫测，这个非常复杂，什么 rag 啊，什么这个 context 上下文，什么都来了。 我简单的跟大家说这个 agent 记忆，其实我们理解几个就行了，如果你想让你的这个小龙虾更具记忆，或者是你的任意的 agent 更具记忆，我们现在有很多取巧的方式，然后呢，第一种就是现在 cloud 的 推的这个，呃， md 格式，对吧？就这种说明书型的这个记忆， 然后说像 cloud， md， 还有小龙虾里面它有这个 memory， md 或者是 soul md 啊，本质上就通过一个 md 的 文档啊，一个一个文档的形式， 然后呢让这个 agent 能够去阅读这个文档，然后去发现，哦，原来我是这么回事啊，这，这个我的风格是什么？然后我需要固定一些什么样的规则，大概就这么一个逻辑，它是人设卡形式的这种记忆啊，就是以文档的形式存在这个 agent 本地的。然后还有一种的话，就是这种知识库型的记忆，之前我们 在说知识库，知识库，其实这里给大家推荐一个好用的 skills 啊，叫这个 obsidian skill。 那 obsidian 呢，是一个非常成熟的这个本地知识库的管理工具啊，或者是说一个 技术型的这种本地支付管理工具吧。那我们可以通过这个 obsidian skill 呢，让 agent 和 obsidian skill 形成绑定。 agent 之前学过什么，读过什么，记了什么，都可以放在这个 obsidian 里面形成标签和双向链接。到时候比方说我们 agent 想到了这个东西，或者是想引用它，就可以随时从这个支付里面去移动，那 这个的话就是叫记忆的基础设施，我们说 ai inf 就是 ai 的 这个基础设施层的，那这个的话，就现在有些项目叫，比方说 m e m 零啊这个项目， 再比方说了解到的 zap 这个项目，这两个项目呢，它都属于记忆的基础逻辑层，它们会从你的对话行为文档里面去给你沉淀这个记忆，然后形成一个就是比较 basic， 比较底层的一个记忆体系，所以这个是相对来说更高一层的这个记忆逻辑。 然后在最容易被忽略的是现在在这个项目，哎，这个项目进行当中，他还有一个叫什么状态记忆，那状态记忆就是他不是记住你的风格，也不是记住你的这个人设，然后他主要是记住这个任务到哪一步了，然后接下来应该做什么啊？这个状态记忆他其实也是也是有的， 那其实呢，想要你的 a 键有更好的记忆能力，那我们可以就从这几个维度去给它补充嘛。刚我们讲到的说明书， memory 点 m d 的 格式的，然后到 p 点的这种知库格式，然后状态记忆以及就是基础设施 ai inference 的 这个 memory， 或者是 zip 这种形式来去强化它记忆啊，大概就是这些， 如果你想了解更多呢？后面我会专门出一期这个操作的教程，然后来告诉大家怎么去做，其实这个都不用去买课，这个也不是什么玄幻的东西，然后给大家也一起科普一下，就这么着，拜拜。

上个视频我们介绍了 astropik 在 做 deep research 场景时使用的多 agent 的 架构，以及在使用过程中踩过的坑和避坑指南。那有很多小伙伴会提出疑问， 我应该在什么时候起用 sub agent？ 什么样的工作适合分配给 sub agent 去做？而针对竹子 agent 上下文隔离的问题，我又应该怎么去管理上下文和记忆，来确保任务的尝试运行？ 我结合 astropik 最近发的一篇博课，以及谷歌的 agent sdk 在 do agent 上下文管理的经验，通过这个视频一次性把这几个问题说清楚。 首先是什么场合适合做 do agent， 并不是越复杂效果就越好。往往一个设计良好的单一 agent， 配合你改进的提示词，能达到同样甚至更好的效果。 就像是你本来可以一个人高效完成的工作，你却非要组建一个团队，结果大家要花更多的时间在开会和协调上，反而效率更低。 那多 agent 的 架构只在解决单 agent 没有办法克服的一些特定限制时，它才会有价值。根据 astropic 的 经验，有三个场景使用多 agent 可以 持续展现出正向的收益。 第一是上下文保护。我们知道，当 agent 的 上下文积累了大量与后续任务无关的信息的时候，就会发生上下文污染，导致推理质量下降。 比如说智能客服需要通过查询客户的订单历史来诊断问题，你去查订单记录，系统会返回大量的信息，订单的详情、历史的购买记录、物流信息、支付信息等，这些信息就会占用你的工作记忆，造成上下文污染，那 agent 分 析问题的能力就会退化， 这个时候就可以通过一个订单查询的子 agent， 子 agent 处理完订单历史，提取关键信息，只返回五十到一百个 token 的 招标给到主 agent， 那 主 agent 的 上下文始终保持清爽，专注客户的问题。 所以如果你的子任务会产生大量的信息，但是大部分信息对于主任务无关，并且你的子任务是有明确的标准，不需要依赖复杂的上下文，就知道该提取什么信息的时候，就可以起用子 agent。 第二个场景是并行化，有些任务可以分解成多个独立的不相关的子任务，并行执行可以探索更大的搜索空间。 比如说你要研究一个复杂的问题，气候变化对全球经济的影响。那这个问题可以分为多个角度，对农业的影响，对能源的影响，对房地产的影响。如果你用一个 agent， 它就只能一个一个研究，如果用多个 agent， 它就可以同时去研究不同的角度， 那 deep research 是 非常典型的多 agent 的 场景之一。这里通过此 agent 并行化带来的价值不仅仅是速度的提升，更重要的是分析的会更加全面。 但是正是因为全面，总的计算量也会增加， token 的 成本也会很高，大概是单 agent 三到十倍左右。 所以是否要用多 agent 还需要考虑它的任务价值。杀鸡不要用牛倒。第三个场景是智能化， 专业化也有几个典型的维度，比如说工具的专业化，如果你的 agent 有 很多的工具，并且这个工具要跨很多个不相关的领域，很难选择，也可以根据的专业领域，工具的专业领域来划分。 第二个是提示词的专业化，不同的任务有的时候是需要不同的角色的，不同的约束以及不同的指令， 比如说客户支持需要共情和耐心，但是代码审查则是需要精确和批判。一个智能体，它不能同时兼顾这种冲突的行为模式，那分离成专业化的 agent 可能会产生更一致的效果。 最后一个是领域的专业化，这个就比较常见，比如说有些任务像法律、医学，他是需要某个领域非常深度的上下文，这种也是适合去做拆分。 ok， 经过上面的判断，现在你确定你就是需要做 agent， 那 作为老板，我们又该怎么去分配任务呢？ 核心的原则是按照上下文的边界拆分，而不是按照问题的类型拆分。这个是多 agent 的 架构设计中最重要的一个决策。 astropic 观察到很多团队都经常在这里犯错，导致协调的开销抵消了多智能体的好处。 比如在软件开发的时候，你按照问题的类型来拆分产品，一个 agent 开发，一个 agent 测试一个 agent， 看起来很合理， 大家解决的问题不同了，但是实际上呢？开发不知道为什么要这么设计测试，不知道开发的时候做了哪些权衡取舍，就像一个传话游戏，每传一次信息就失真一次，那你要让信息不失真，就要花大量的 token 去做协调，协调的 token 可能比工作消耗的还要多， 所以要按照上下文的边界来拆分。比如负责这个功能模块的开发，也需要负责这个功能的测试，因为他自己有所有的上下文，只有在上下文可以真正隔离的时候才去拆分工作。哪些是有效的拆分边界呢？ 比如说可以按照功能模块拆分用户认证，一个 agent 支付，一个 agent 用户认证去处理登录注册权限的问题，支付去处理支付的流程。也可以按照数据源去拆分，一个 agent 去查数据库，一个去查 api， 一个去查文件， 或者是按照系统来拆分，前端一个，后端一个，以及还有最常见的按照独立研究方向去拆分。 那反面的典型案例呢？前面说到的按照开发阶段去分，每个阶段都依赖上个阶段的上下文， 还有是按照技能去分的，一个写代码，一个写文档，那每个都需要去理解用户的意图。还有按照步骤分的步骤一一个，步骤二一个，那各个步骤之间也是有依赖的，那这些场景只是增加了协调的开销，并没有带来任何的好处。 按照上下文来分，能保证每个 agent 各自的上下文都会相对独立，可以并行执行，也不会被其他方向的信息干扰。 子 agent 只需要提炼自己的发现，返回信息就可以了，最大限度地降低了协调的成本。上述的拆分方案是最大化的减少 agent 的 协调问题。但是主子 agent 总是要通信的，依然会面临上下文管理的问题。 在每次交接时传递完整的上下文，或者让子 agent 去访问主 agent 完整的历史，没有监控上下文的限制，让 agent 在 接近限制的时候持续运行，这些都会让系统去陷入上下文爆炸或者信息丢失的困境。 那如何在隔离和共享之间找到一个平衡？如何在尝试任务中去保持连贯性？谷歌的 agent sdk 的 经验是把上下文分成四个层级来进行管理。 第一个是工作上下文把模型调用时候需要的上下文信信息进行一个临时的拼装，这些信息包含系统的指令、 agent 的 身份、你的工具调用、输出的结果记忆以及文件的引用等。这些信息都是临时的，月后记分，不用存储。 那长期记忆是包含绘画记忆还有文件，绘画主要是用来记录系统的交互日记需要的信息，压缩之后拼装进 working context 记忆是存储长期可解锁的知识。比如说主 agent 的 任务规划，即使上下文超过限制，任务规划也不会因为截断而丢失，可以随时加载 记忆也会存储长时运行的任务，产生的阶段性的工作总结等。还有一个是独立的这个文件系统， 它的场景是自 agent 产生了大量的输出给到主 agent 的 药物，满足不了需求的时候，就可以调用工具将这些内容存储成外部的文件，返回一个轻量级的引用给到主 agent， 主 agent 按需加载渐进式批录。 当然像 open cloud 这样的产品，它的记忆本身也是用 markdown 文件存储的，那记忆和文件就是可以合并成一个。 当然在具体的实践过程中，可能还会碰到很多细节的问题，如果想快点上手，也可以基于一些开源的项目去做搭建。比如说 launching 团队的 open deep research， 它是基于 long graph 搭建的一个多智能体架构， 这个产品是 launching 团队官方认证的复刻的 astropica 的 架构，它的流程是，当你系统启动之后，首先是进入与用户需求澄清的节点，先澄清需求， 需求澄清之后会进入到这个 right 节点去钻研研究。检报嵌套的子图是一个独立的多智能体循环系统， supervisor 会根据检报 调用工具执行具体的工作，然后通过 react 的 进行循环，最后再进入到一个生成的节点，生成内容加信息源的整合。 我自己用这个模式，整体上的体验还是比较好的。有一个卡点是最后在生成环节会非常慢，因为要汇总的内容特别多。这个我目前还没有想好怎么优化，大家如果有好好的方案也欢迎跟我分享。

哈喽大家好，昨天懂了 react agent 的 概念，今天上硬菜抠抛 agent 原码拆解，别怕，新手也能看懂。先看这个引力的初死函数，一堆参数看着唬人，其实都是控制 agent 的 开关，比如 max items 是 最多迭代五十次，怕它死循环。 max input ness 是 上下文窗口大小决定能记多少内容。再看核心步骤，其实就五步，超简单。 第一步，保存参数，把刚才的开关存好。第二步，创建工具集，给 aint 装手脚，让它能做事。第三步，加载技能，装用户自定义功能，比如日报生成。 第四步，构建系统提示词，告诉大模型这个 aint 到底是做什么的。第五步，创建大模型实力。最后一步最关键，抽象父类 react aint， 把名字、大模型、系统提示词、工具集、记忆都传进去，相当于给 agent 配齐了五脏六腑，它就能干活了。整个过程就是设参数，装手脚，加技能，定身份，配大脑，给记忆， 一步不绕，逻辑贼清晰。重点来了， coco agent 是 在 react agent 的 基础上扩展的，多了工具集、技能、系统、记忆、管理这些实用功能，这才是它强大的原因。 我是卷毛，每天拆解一个 ai 开发小知识点，从概念到代码，一步步带你吃透。关注我，明天看真实案例实操别掉队哦！

各位技术大牛好，今天我们聊一个极其硬核且痛点满满的话题，大模型的上下文压缩。我们都用过所谓两百 k 甚至一 m 窗口的模型，但真正在生产环境跑过复杂 agent 的 人都知道，长窗口根本不是银弹。今天我们将拆解行业最前沿的上下文管理机制。 这是一个非常反直觉的真相，很多开发者单纯依赖硬件层面的长窗口，觉得把所有历史记录塞进去就完事了。但现实是，超过一定的 token 水位线模型不仅会犯错，还会产生极高的延迟和成本。这就是为什么头部大厂都在悄悄转向另一种策略。 为什么我们需要专门做上下文压缩。左边是我们过去常用的滑动窗口策略，也就是硬截断。这就像一个失忆症患者，走着走着把出发的目的忘了。而右边行业正在转向语义压缩，他的目标不是简单的扔掉数据，而是提炼出核心事实，让有效对话长度直接翻十倍。 接下来我们先明确一下什么是上下文压缩，以及他在工程上到底解决了什么具体问题。 举个最具体的例子，你让 agent 帮你重构代码干了三个小时，前三十分钟定好的数据库表结构， 到了第三个小时，因为 token 满了，早期对话被硬生生切掉，结果 agent 突突然开始凭空捏造自断。这种挫败感写过复杂 agent 的 的人一定懂，这就是 context route 带来的灾难。 我们用数据流图来看这个过程，用户的核心意图在最开始进入工作记忆，但随后大量的工具调用日制报错信息像洪水一样灌进来， 一旦触及两百 k 限制，系统被迫驱逐最早的规则，直接导致最终的幻觉。我们要干掉的就是中间这个被动驱逐的环节。这是一个清晰的对比 应阶段，虽然在计算上几乎零开销，但对于长周期任务是致命的。语义压缩虽然需要消耗一次额外的 l l m 调用来做总结，但它能把早期定下的基调约束和当前进度浓缩成一段系统提示词保留在上下文中。 这就好比你在交接工作时，给继任者留了一份详尽的文档，而不是直接走人。我们快速停顿一下，答案显然是 b。 其实，羽翼压缩再触发的那一瞬间，并不会帮你省钱，甚至还要花钱去跑一次摘药模型。它的核心价值在于保命，保住整个推理链路和业务规则不崩盘。如果这点达成了共识，我们进入深水区。 既然羽翼压缩这么重要，大厂和主流框架在底层，到底是怎么实现它的？我们来拆解它的三层核心技术架构。 行业里目前有三大流派并存，第一种是全量羽翼摘药，简单粗暴但有效。第二种是像外科手术一样，只切除无用的容肠锐志保留对话。第三种则是学术界和顶尖实验室正在搞的 u t a c a。 基于模型生成时的不确定性动态调整窗口，我们逐一来看 什么时候触发压缩最合适。传统的做法是设一个死线，比如一百八十 k 触线就压，但这很生硬。现在的高级 agent， 比如 long chain deep agents， 采用的是机会主义触发，也就是在任务的自然边界，比如刚写完一个文件，或者刚查完一个资料， 趁着逻辑闭环，顺手把前面的废话压缩掉，这才是真正的高级感。给各位工程师透个底，这是目前行业里几家头部框架和模型的预值设定。 lion king 比较保守，百分之八十五就开始动手了， openai 的 c i i 工具敢推到百分之九十五，而 clark 三点七 sonic 官方给的最佳实践是在一百五十 k 左右进行拦截和压缩，记住这些数字调餐时能省很多事。 这里要讲一个最前沿的 utac 机制，它的底层逻辑非常惊艳，模型在逐字生成 token 时，系统会实时监控它的 legit 边缘差值。如果发现模型不够自信，有幻觉风险，系统会立刻触发回滚机制，把上下文窗口拉大，解锁更多精确信息塞进去，然后再重新生成。 这是一种极其精密的动态内存管理理论。讲完了，我们来看看大厂在工程上是怎么把这些概念落地的，直接上代码和架构 antropic 在 cloud api 里直接做了一个 beta 版的特性，你只要传一个 compaction strategy 进去，设定域值到了一百五十 k， api 服务器会在底层自动帮你做总结阶段。注意，这里有个极其关键的参数， pause after compaction， 它会在生成招标后暂停，把控制权交还给你。 来看 slide 十六的核心 forgot 是 怎么做的，它不光看 token， 还看对话轮次，最绝的是右边这个推理链保留。 对于像 cloud 三点七这种具备深度思考能力的模型，如果你把它的历史思考过程直接暴力压缩掉它，接下来的回答就会像断片一样失去逻辑连贯性。所以 forge code 会特意把最近的推理过程提取出来，像接力棒一样塞给下一轮对话。 这是 forge code 的 实际配置文件。看到 preserve reasoning true 和下面的 reasoning text 了吗？在执行压缩时，框架会扫描被淘汰的历史消息，用正则或者解析器把这些 dot 标签里的内容抠出来， 强制附加到新的上下文中，这就是资深工程师解决问题的优雅方式。并非所有的压缩都要动用 l l m 去写小作文，像 open code 这种工具采用的是外科手术室的修剪。写代码时最占 tok 的是什么？是那些动辄几万行的报错日制和 get diff。 open code 会直接把历史轮次里的长日制删掉，只保留最新一次的报错，这既省了 tok， 又完全不破坏对话语义。 检查一下大家的专注度，答案是， b 服务器帮你做完 java 后暂停，是为了让你有机会把最近几轮及其关键的对话，或者你系统里特有的上下文对象原封不动地拼接到 java 后面，然后再让模型继续回答，这赋予了开发者极大的控制权。 看到这里，你可能觉得上下文压缩很完美，但作为 staff 级别的工程师，我们必须看到它在实际落地时的暗坑和 trade offs。 这是所有压缩算法面临的终极矛盾。做招标必然丢失细节。对闲聊机器人来说，保留大意就够了。但对于写代码的 agent， 如果压缩时把某个特定函数的入参类型给概括没了，接下来的代码全得报错。 所以在复杂的分析场景中，纯摘要是危险的，必须配合我们前面讲的修剪和推理保留策略。这里有个极容易踩坑的工程细节，你为了监控一百八十 k 的 域值，如果在每次请求前都把几十万字的上下文扔进 tokyo 字儿算一遍，你的系统延迟会直接爆炸。 大厂的做法是使用 loggerimac sampling 对 数参照或者基于字母长度做快速计算，只在逼近红线时才做精确计算。这是一个非常实用的性能优化点。 另一个深水区是 k v cash， 你 辛辛苦苦积累的上下文缓存，一旦执行压缩，历史内容变了，缓存直接失效，下一次请求会慢得像蜗牛。解决办法是利用大模型 api 的 cash breakpoints 特性，把系统提示词、核心文档放在最顶端并锁定缓存， 不管下面怎么压缩，顶部的缓存永远生效。学术界对上下文管理有一个著名的论断，叫做苦涩的教训。 他告诉我们，不要试图用极其复杂死板的硬编码规则去管理模型的记忆，把压缩上下文封装成一个托儿交给大模型，让他在觉得脑容量不够用的时候，自己调用工具清理自己的记忆，这才是未来的终极形态。 最后，我们站在现在，看未来下一代向下文管理技术会往哪个方向引进。 未来的方向非常明确，混合优化与软硬协调。软件层面，我们会把量化技术和语义压缩结合起来，不重要的历史记录不仅被总结，甚至在显存里直接被降级为四倍的存储。 硬件层面，未来的 ai 芯片会像现代操作系统的虚拟内存一样原生，支持 kvatch 的 快速换页和淘汰 快速复习。以下今天涉及的三个核心黑化， semantic compression 是 我们的核心武器， u t s o a 是 未来动态分配的终极形态，而 retention window 是 你在写配置时，为了保证最近对话不出现断层，必须设定好的保留参数。 总结一下今天的核心洞察，上下文压缩绝不是写一个拍档脚本截断数组那么简单，它正在从一种被动的防御机制演变成由 a 阵自主驱动的具备推理链保留能力的基础设施及组建。这是从死记硬背到懂得规范的进化。 这句话是我希望大家带走的。硬件的二百 k 只是物理极限，但通过优秀的上下文管理工程，你可以让 a 阵的跑完相当于两千 k 的 超长任务而不会崩溃，这就是工程架构的魅力。 落地建议回去立刻看一眼你们公司的 agent 业务，如果还在用无脑的数组切片做硬截断，赶紧把它换成基于总结和修剪的混合策略，特别是涉及到深度思考的模型，一定要把它的 reasoning thought 提取并保留下来。感谢各位的时间，我们下期硬核技术拆解，再见！

长期记忆是我们刚刚讲的跨绘画存储的关键信息，这个框架大家有兴趣去看一下，都是一些算法博士搞出来的，大家只需要理解长期记忆大概会存什么东西。第一个就是我们讲的，比如说 a 准做事方法库，有一个东西叫 char， 翻译过来就任务链。什么叫任务链呢？比如说我们等会用那个找房助手啊，比如说我今天要找一个什么学区房什么的。哦，那他任务链就是第一步干嘛？第二步干嘛？第三步干嘛？第四步干嘛，不断的可能缩圈儿， 我先去找到商圈，再找到这个商圈里面的小区，然后再用学区去找到对应的符合学区范围的小区，反正就不断地缩圈儿。这个所谓的一二三四这个东西就是 taskchain， 必须完成第一步才能干第二步，才能干第三步才能干第四步，每一步 它和前面的步骤之间可能是有依赖关系，也可能没有依赖关系。这个等会讲啊，这个东西就是就是 a 证做事的方法库，所以 a 证并不是让它随意去发挥，它有很多的做事的方法和步骤的，这个东西都是要通过 prompt 来写的。哈， 这第一个大家记一下就行了。第二个就是比如说羽翼记忆，比如说这个 pvc 是 上海浦东机场，这个是什么？这个就客观信息吧， pvc 不 可能是其他的机场，它一定是上海浦东。 第三个就是我们讲的在你的用户的对话当中，你的用户的画像，历史的交互日记记用户的行为偏好，历史的交互日记这件事情也是要放在长期记忆里的，什么意思呢？就是 用户在十二月二十一号买了一张飞机票，预定成功，这个 c 票是从北京到上海五百块钱。这个是已经发生了一条真实的行为日记对不对？ 它是要被永久保存的。永久保存为的目的是什么？为了后续做审计？大家用 manage 的 时候经常有一个词叫回看吗？还是叫什么回放？就是把你 manage 里面所有的步骤再回放一遍， 就是去看。哎，当时它经过了一些任务什么的，虽然它的任务已经执行完成了，但是它所有经过的东西都已经被保存了吧，其实为的目的是做审计用哈，去看后面到底比如说出了问题的时候，当时它整个的任务执行步骤是怎么做的， 但这个里面最重要的其实就是这个情景记忆，就是我们讲的，大家把它理解为就是行为偏好就行了。所以你看短期记忆就是随绘画擦除这个绘画结束了以后，你的那些什么草尾信息啊什么的就清除了。长期记忆的话就是会跨对话的，永久保存哈，大家理解这个概念就好了。