claude压缩上下文技巧

如何在不增加新工具的前提下拓展 agent 的 动作空间？本期我们继续精读 seeing like an agent， 看看 cloud 团队是如何通过渐进式批录机制巧妙解决这个难题的。过去，如果我们希望 agent 掌握新的能力，最直接的方法就是给他增加一个新工具。 但目前 cloud code 只有大约二十个工具，添加任何新工具的门槛都非常高，因为每多给一个工具， 就是在给模型增加一个需要思考判断的选项。如果不加新工具，模型怎么获取新能力呢？随着模型能力增强，他已经可以通过搜索工具自己去寻找并构建上下文。这种主动探索能力促成了渐进式批录机智的诞生。他的核心思想是 不要一次性把所有能力暴露给模型，而是在需要的时候逐层展开，让模型按需获取信息。这项技术可以在不增加工具的情况下为 agent 添加新的能力。在解决 cloud code 不知道该如何使用自己这个实际难题时，这套机具就派上了用场。 如果按照传统思路，我们要么给他增加一个专门的查询工具，要么把整本使用手册全部塞进系统提示词。但用户其实很少问这些问题，这样做反而会增加上下文负担，干扰 cloud 写代码的主任务。他们尝试用渐进式批录的思路来解决，只给 cloud 的 一个文档入口，让模型自己去查。 虽然这样也能工作，但模型为了找到一个小答案，往往会把大量无关内容加载进上下文。于是，为了保持主 agent 上下文的纯净，它们最终构建了一个叫做 guide 的 专用子代理，当用户提出相关问题时， 主 agent 会触发 guide。 这个组。代理会按照自己的指令去阅读完整文档，然后只把最精确的答案返回给主 agent。 虽然这套机制还在不断迭代，但它验证了一件非常重要的事情，你不仅可以向 agent 的 动作空间里增加新能力， 还可以把这些能力收纳在主干网络之外的子节点中。这样即使系统功能越来越多，也不必在 cloud 的 核心工具列表里不断增加新的图，从而避免主模型的认知膨胀。最后，总结一下这篇文章，它贯穿始终的一条方法论是 seeing like an agent， 也就是把工具当成产品，把模型当成真实，用户用实验和观测信号去验证工具到底好不好用，然后持续迭代。基于这个理念，他们总结出了三个实践要点，第一， 工具设计要匹配模型的能力边界，工具是否有效，取决于模型能不能稳定正确的使用它。第二， 工具需要随着模型能力一起迭代淘汰。模型变强之后，旧工具可能会变成干扰选项，需要及时升级，甚至大胆做减法。第三， 用渐进式，譬如避免工具膨胀，把静态的工具列表转化为动态的能力网络，最终实现了 agent 的 能力在不断增长。但工具列表并没有膨胀。正如文章最后所说，工具设计没有固定公式，它既是一门科学，也是一门艺术。变量来自模型能力、任务目标和运行环境。 唯一可靠的方法仍然是不断实验，观察结果，持续调整 see like an agent。 这里是慢学 ai， 我 们下期再见。

我之前 cloud code 订阅的是 pro， 一 不小心就把限额用超了，所以特别焦虑，隔一会儿就强迫症一样用 slash usage 去查限额，现在还剩多少。直到有一次我看到朋友的 cloud 终端底下直接显示了这些信息， 我立马就问他装了什么，拿过来就用上了。这个插件的名字叫 cloud hard， 是 一个澳洲的开发者叫 grog watts 写的， github 上已经现在有四千多个 star 了。装上以后， cloud 的 底部会多一条状态栏。 就拿刚才说的限额焦虑来说吧，用 pro 或者 max 的 人应该都被限速过对吧？写到一半突然告诉你，请稍等几分钟，节奏全断了。装完这个插件，状态栏会直接显示你限额还剩多少，然后什么时候刷新， 快到上线的时候，你可以缓一缓，也不至于直接被卡住了。所以再也不用强迫症一样切出去用 slash usage 了。限额的问题解决了，但还有一个更隐秘的坑，上下文窗口。你跟 cloud 的 所有对话，他读的文件，跑的命令，全都挤在一个上下文窗口里，满了大模型会自动压缩，但压缩是有损的，之前你们聊好的设计决定具体的文件路径， 报错信息都可能被模型直接丢掉。而且很多大佬测过 cloud 的 回答质量，其实从上下文用到百分之三十到四十的时候就开始下降了，不是等满了才出问题了。所以最好的做法是，当你看到这个进度条过半了， 那么做完手头这个功能，或者修完这个 bug， 直接用 slash clear 清空上下文，比主动压缩或者被动压缩都要好得多，因为你能挑一个干净的时间点来做状态栏，还会显示你现在用的是哪个模型。 这个为什么重要？我个人的工作流程是这样的，在一开始的项目规划阶段，我会无脑一直用 opus。 这个阶段目的就一个，把项目所有的需求落实到文档里面，比如产品的需求文档、技术架构文档、测试文档、部署文档等等。然后用其他的模型，比如 codex 或者 gemini， 让他们来评估文档里是不是有些不清楚的逻辑不通，或者不符合最佳实践的地方。然后继续让 opus 迭代， 直到这些文档里其他文模型提不出任何问题。那么继续到项目实施阶段，那么我会就用 slash model 切换到 sonet， 那 么它只要按照写好的文档去执行就行了，不需要考虑太复杂的情况和特别深的推理。状态栏上一眼就看到自己现在挂的模型是哪个。不用猜，这个插件的安装也非常简单，你只要跟着 github 上这个 install， 三步直接就装完了，我就不赘述了。所以总结一下，这个插件就干了三件事情，限额快到了，提前预订，上下文快满了，提前知道当前的模型，一眼就看到三条命令，装完零配置。 其实这期内容是因为之前好多粉丝在问我 cloud 底下那个状态栏是什么，所以我才想起来专门介绍一下。所以以后你们如果看到了我用什么东西，感兴趣的工具或者配置，直接留言告诉我，我都可以出一期讲一讲。

重磅消息！十七 k star 的 开源神器来了！ cloud mem 让 cloud code 拥有长期记忆，彻底解决 ai 失忆症。用 cloud code 的 朋友都懂，每次新绘画都要重新解释项目背景、需求、架构，明明昨天刚聊过，今天却像失忆一样， 这种 ai 失忆症严重影响开发效率。 cloud mem 是 一个专为 cloud code 设计的持久化记忆插件。十七 k star 采用 cyk 架构，自动捕获工具调用 ai 语义压缩，让 cloud 真正记住你说过的每一句话。 cloud mem 有 三大核心，第一， 自动捕获 agent 生命周期中的工具调用和观察结果。第二， ai 语义压缩，提取关键信息。 第三，智能注入在新绘画中按需回注相关上下文。不同于被动的向量数据库查询， cloud mem 采用侵入式 side 架构，直接拦截 cloud code 的 生命周期钩子， 主动捕获压缩回注上下文，实现跨 session 无缝衔接。最厉害的是， ai 语义压缩不是简单存储原始对话，而是用 ai 理解对话含义，提取关键信息，压缩成结构化记忆， 既节省存储，又提高剪辑精度。 cloudmen 还提供了 web ui， 打开 local host 三七七七七，实时查看记忆流，搜索历史、操作管理、隐私标签记忆不再是黑盒，完全可识化可控。隐私方面完全放心， 所有记忆数据本地存储，支持隐私标签过滤敏感信息，你的代码、项目信息完全不会上传到云端，数据主权在你手里。安装特别简单，一行命令， cloud plugin installs， cloud 简 main， 重启 cloud code 记忆功能立即生效，无需配置，开箱即用，对比效果惊人。以前每次绘画都要五分钟解释背景，现在 cloud 自动知道项目架构技术栈 你的偏好，开发效率提升十倍，真正做到开箱即用。还有实验性功能， endless mode 仿生记忆架构，支持超长绘画，不丢失上下文，适合大型项目重构复杂架构设计，让 cloud 陪你完成史诗级任务。三类人最适合长期项目开发者，跨绘画保持上下文， 复杂架构设计者。 ai 记住每个决策团队合作共享项目记忆，新人快速上手，这就是 ai 记忆的未来。当 ai 能真正记住一切，人机合作将进入全新时代。 cloudmail 指示开始，未来的 ai 助手将拥有真正的长期记忆能力。感谢收看，明天见！点赞加关注赛博杨千焕，获取更多 ai 工具神器推！

anthropic 最近悄悄上线了一个叫做 auto dream 的 新功能，根据大家的讨论，这个功能基本上会定期运行一个子代理来整合 cloud 的 记忆文件，以便更好地进行长期存储。 我还看到 anthony 发了一条推文说这真的很疯狂，因为这基本上就是人类通过睡眠来储存长期记忆的方式。 你可以看到，在这个项目里，我就在尝试使用 auto dream。 由于这个功能还在逐步推出，而且属于实验性功能，我就在我的项目里尝试运行了一下，结果确实可以用。 正如你所见，他正在做梦，因为在我的状态栏这里，你可以看到他显示的是 dreaming。 然后我往下翻，按回车，进入任务查看页面，你就能看到他正在做什么。他一开始会说，让我在最近的绘画中搜索更多用户反馈偏好和与新项目相关的信息。 他基本上会查阅我们所有的消息，以及我们让他做过的各种事情。接着进入第三阶段，也就是整合信息的阶段。所以这里列出了自上次运行以来，他需要用来更新内存文件的所有关键发现。 你可以看到，这其实是一个相当全面的任务，他已经运行了将近十分钟了，他已经回顾了十三个会话，并且正在处理不同的内存文件。 基本上这整个过程的目的就是为你的 cloud 记忆提供一个自动的后台清理和整理系统，这样每次你开启新绘画时，感觉会很清晰，而不是模糊或杂乱。 现在 cloud code 已经具备自动记忆功能，它可以在 memory d m d 文件中记住你项目的一些信息。这些内容通常会在你绘画和对话开始时被自动注入。 这也是为什么目前 cloud code 能够在上下文上更好地理解正在发生的事情。但 auto dream 有 些不同，因为它不是简单地注入一些信息，而是持续地压缩、修剪，并让那个文件变得越来越好。它让一切都保持得更加新鲜，因为它基本上会把所有进入你 memory md 文件的不同信息都处理一遍。当他执行 alter dream 时，会将这些信息合并、修剪、刷新并进行压缩。这样所有不同的记忆文件都会变得更加整洁。所以，如果我切换回这个项目，你可以看到它改进了五个记忆点，这大约花了十分钟， 它优化了所有这些不同的 md 文件。现在项目就可以使用这些文件了，而且它们都更加整洁和更新。那么你要到达这里的方法是进入 memory。 你可以在这里看到我们有编辑 cloud 记忆文件。当你打开它时，你会注意到这里显示 auto dream 已开启。正如你们刚才看到的，这个功能上一次运行是在十一分钟前，我们可以用 dream 来运行它。现在当你打开这个时，它默认是关闭的。你只需要把鼠标悬停在上面，按下回车键，它就会变成开启状态。 而且默认情况下，你的 card 的 自动记忆功能很可能已经是开启的。你会注意到，记忆功能是全局开启的，适用于你所有不同的项目。但每个 auto dream 都有自己独立的文件进行操作。所以在另一个绘画中，你可以看到 auto dream 也是开启的。它上一次运行是在十一分钟前。 现在如果我切换到我的 hurt 二项目，在这个项目里，我从未开启过 auto dream 功能。然后我去查看记忆， auto dream 功能已经是开启状态，但你可以看到它显示从未运行过。 当然内存文件也是不同的，因为在这里我有很多不同的文件。而回到另一个项目，那其实更像是一个演示。你可以看到我们只有这三个主要文件，分别是 project user 和 auto memory 文件夹。 所以现在如果我在我的 herk two 项目里，并且我知道我的 auto dream 已经被开启了，它提示我可以使用 dream 来运行。 所以如果我在这里输入 dream， 会发生什么呢？它基本上只是显示未知技能，我们也没有看到任何反应。 所以现在你其实可以用自然语言来调用它。尽管 cloud code 本身可能对你想做什么有点困惑，所以我就直接说运行你的 auto dream， 我 们来看看它会怎么处理这个信息。 所以现在他说我没有 auto dream 技能，而且他有点困惑。但你可以在这里的状态栏看到，我们确实看到他正在做梦。如果往下看，进入任务列表，我们可以看到他正在运行这个梦境整合， 他会先让自己适应环境，然后我们会看到一系列操作，比如我正在获取这个文件，我正在查看这些绘画。 而现在，因为这是我一个比较大的项目，你可以看到它正在回顾两百八十五个绘画，所以这可能会花费比八到十分钟更长的时间。所以在我们让它运行的时候，让我们再多聊一下为什么这很重要。 很明显，这个功能刚刚发布，我还没有时间真正深入测试，看看它到底值不值得用。但根据我目前看到的情况，我确实认为它值得。让我们来谈谈为什么会这样。第一个重要的点是，你会减少重复。 即使有自动记忆功能，我有时候还是觉得自己在重新解释一些事情，或者试图把一个绘画的上下文带到另一个绘画中，而减少重复显然是一件好事。我们还有另一个在后台运行的好处，就是减少溶于。因为系统的一部分功能就是在压缩和修剪内容。 修剪基本上就是只去除那些不必要的内容，精简多余的部分。当我们去除所有多余的内容和多余的 tokens 时，这显然有助于减少溶于，也有助于我们进行上下文管理。 我们还拥有更好的回忆能力，因为他去除了我们实际上不需要的内容，所以查找信息变得更容易。想象一下，球池里有一百个球，你要在篮球中找一个粉球，如果我们把一半的篮球拿走，结果会怎样？ 找到那个粉色球就会更容易了。我觉得特别有趣的一点是，这基本上就像睡眠一样，无论这个过程以什么样的节奏运行。我们稍后会谈到，当他到达那个节点时，基本上就像重置一样，所以这就像一个检查点。每次你到达一个新的检查点，实际上就是在为自己保存进度。 以前你会有所有这些不同的文件，对吧？你会有这些庞大臃肿的上下文文件， md 文件。但现在，澳洲 dream 会把所有这些内容提取出来，只保留你需要的重要信息，可能只是几条要点，而不是上百行内容。 他的实际工作方式是，第一步，一旦被激活，他会收集绘画信息。之后他会读取当前已有的记忆文件，然后将其加载到一个子代理中。这个子代理会执行实际的梦境提示， 所以我不能完全确定。但我想象中的梦境提示大概是这样的，你正在执行一次梦境操作。对你的记忆文件进行反思性梳理， 将你最近学到的内容整合成持久且有条理的记忆，以便未来的绘画能够快速定位。请将 memory 保持在行数限制内，它是一个缩影，而不是全部内容的堆砌。用一句话描述并链接到记忆文件。不要把完整的记忆内容复制进去。 在运行完这个提示之后，它会进行整合和修剪。就像我之前说的，这其实就是在整理和清理内容，然后它会把所有的结果都存储下来。 接着，每当他下次醒来去做梦时，基本上就是每次都重复这个流程。那么一旦你开启了自动记忆和自动梦境，除了你用 dream 命令或者直接告诉他去做梦之外，自动梦境实际上是如何发生的呢？ 其实基本上有两种不同类型的触发方式，或者两者兼有，它可以基于时间。比如说每隔十二小时我就会自动做一次梦，或者也可以基于绘画次数。所以也许当你达到三百次绘画时，它就会自动进行一次梦境。 不过这一点还没有官方文档确认，这基本上只是根据一些 x 平台的讨论和 ready 上的讨论得出的结论，但请大家记住这一点，这很可能就是他的工作方式，但我不能百分之百确定。现在一旦他开始运行，你基本上会看到几种不同的状，你可以看到他正在运行， 也可以看到他从未运行过，还可以看到他上次运行的时间，或者什么都看不到，处于空闲状态。这里需要注意的是，他只会操作内存文件。正如你们在第一个例子中看到的，他说我更新了五个文件， 这些全都是上下文文件，所以这里所有显示我改进了五个记忆的全部都是 md 文件。这些都不是代码、脚本或类似的东西。那么我们该如何理解云端代码中这些不同类型系统之间的不同层级呢？ 对于普通绘画，我们基本上只具备编写代码、调试重构以及与云端代码交互的能力。 然后在中间层，我们有自动记忆功能，它会记录决策模式以及关于实际项目或你的重要信息。 但除非你自己拼凑出一套解决方案，否则并没有一种很好的方法可以持续的清理这些内容。所以自动梦境 auto dream 基本上就是在后台运行，无需你手动介入或提示，它会自动检查所有内容，清理一切并修复许多问题。 这也是为什么让这三层协同工作会创造出一个非常强大的系统。这个系统很可能能帮助你更好的扩展，并让你的所有绘画都保持更清晰，更像一个能记住你信息的人类，而不是一个聊天机器人。 所以现在这个程序已经运行了超过六分钟，等他完成后，我会再和大家汇报一下，我们可以看看他更新了哪些记忆文件。这次其实只花了八分钟，这很有意思，尽管他需要检查的绘画多的多，二百八十五个，而不是大约十三个， 但他还是能够更新这三个不同的记忆文件。你现在可以看到目前没有任何后台任务在运行。如果你想要更清楚的了解他具体做了什么，你可以直接看到他的操作，他添加了这几条记录，并且移除了这些部分。现在如果我想恢复这些内容，或者添加更多见解，我都可以做到。 当然，如果我想确保一切都准确无误，也可以去查看这个文件。而且很酷的一点是，随着你越来越多的使用 auto dream， 他 会越来越擅长理解哪些上下文对你来说是重要的，哪些不是。 好了，今天就到这里，如果你喜欢这个视频或者学到了新东西，请点个赞，这对我帮助很大，一如既往，感谢你们看到视频的，最后，我们下期再见，谢谢大家。

今天学习了一下可乐的扣子的原码，就是把他的原码下下来，然后让 ai 读原码，根据他的原码，然后画了一个他的业务流程图啊，长这个样子，感兴趣的同学可以点暂停看一下。 呃，可以看出来就是有点超乎于一些，就是比较简单，比想象的简单太多了。 他总的来说其实就两个部分啊，第一个部分就是用户的内容输入进来之后呢，他会去 做一个上下文的组装，这个上下文里面他包含的内容可能就稍微细一点，然后主要是环境那种，比如甚至有没有自己的仓库这种啊，他都会包进去。然后呢我也给大魔仙进行第一次处理，第一次处理之后呢就开始进入一个循环，然后这个循环也很简单啊，就是魔性决策， 然后工具执行，执行结果再为回位的模型，然后再小模型自己去决策。 其实则部分呢也很简单，有也比我想象的简单的多，就是它没有特别复杂的流程啥的东西，它没有写那些东西， 它写的都是相对来说是边界性或者原则性的东西啊，比如安全策略问题，然后还有比如对一些细节，比如对 u r l 的 处理问题，然后还有 比如，哎，就是设计这一原则，比如不能过度设计啊，然后呢就是不要保留荣誉代码，不要为了兼容性去写那些荣誉代码，就是类似的这种东西， 就他没有指导下的东西，就是说你必须得先怎么样怎么样，然后再怎么样啊，他没有这这种类似的其实词，他都是边界性质的和原则性质的其实词， 这个就怎么说呢，现在现在就很不解啊，因为你这么简单的一个东西的话，为什么 costco 的 就比其他的好用那么多呢？对吧？不知道，这个是真的不知道， 然后根据，然后又跟叉的 j p c 聊了一下，那叉的 j p c 给的结论类似的就是说 a 阵它的核心，它不在于循环啊，也不在于那个技能啊，都不在，都不是关键，这些都不是关键。什么是关键呢？就是那个 世界模型啊，当然这个词用词可能比较大。那啥意思呢？简单来说就是比如我们用 a 键他，那你肯定有任务进来，对吧？那你的任务相关的各种信息，是不是又组成了一个任务的相关模型？ 然后呢，那你这个人啊，你的用户，那你的各种行为习惯啥的，是不是就能构建出来一个你的一个用户的模型？ 然后呢，你这个 agent 他 能在一个什么像环境下运行，对吧？他能调用哪些工具等等，而且这些东西他可能组成了一个环境模型，类似的这一大堆模型啊，合一块啊，你可以把它叫世界模型啊，但是这个词我觉得太大了。 总之来说呢，就是把这个东西构建出来之后呢，然后呢，你在每一步循环的时候利用这些信息，然后再去构建记日词，然后我也给打磨清啊，就是不需要特别复杂的循环，但是呢，上下文可能会比较多， 叉的 j b c 表示呢，这也是未来，一个也不应该不是未来，就是现在的一个发展方向吧？就是不是多次循环了啊，不追求多次循环，而是要追求尽可能少的循环，然后每一次循环呢，都尽可能去喂更多的双亚文啊。大概就这么一个思路。 但是根据我之前给自己定下来的原则呢，就是独立实践啊，独立思考，虽然他们都这么干的。嗯，到底怎么样，我还是自己先实践吧。 接下来呢，就先按照 cloud code 的 这种模式。我觉得先试一试吧，把它里面跟编程相关的其实对吧？全改了，全改了，然后去模仿它的玄幻组装逻辑， 然后再尝试一下吧，希望有好运。

今天给大家分享一下这个 cloud code 的 team 模式。 team 模式我觉得它是一个真的非常好用的一个方案，因为之前的都是 sabotaging， 它有一个特别大的问题，就是它每一次启动它上下文是已经重置了，但是你 team 模式的话，相当于你启动了多个这种子智能体，然后它一直待命， 这样的话它性能就会好很多。虽然它这个 cloud code 的 文档里面说的是什么情况下应该使用，什么情况下不应该使用，我个人感觉都可以使用， 只要不是你是一些特别小的项目，可能两百 k 的 上下文就直接可以足够你使用了的话，那么你就一定使用这个 t 模式，它效果好很多。它有两个特别好的点，第一个点就是你的主智能体，你在做任务的时候，你的上下文不那么容易去突破了， 之前可能我们两百 k 两百 k 的 上下文主智能体去做执行，就算他调用了子智能体去完成任务，他的上下文我自己用起来的话，估计就是五轮或者十轮，对于一个稍微大型一点的项目调试来讲，就是这样就直接又得压缩上下文了。你压缩上下文了之后，性能是急剧下降的，它效果是非常差的。 但是如果你把它分成了这种多个 teams 这种成员，那么它就会把很多任务它会自己去做拆分。因为像这种子智能体，它有个比较大的问题，就是它们对话和交互的时候，它上下文是会有信息损失的， 所以说它必须要把任务拆分成一个一个的小模块，只要你用这种 team 模式把这种比如说它模型，它的一些提示词写好的话，它会自己去把任务给你拆分成模块化的，但是这个可能它不会那么主动地去拆分模块化， 但是这个它是可以很主动地去拆封模块化，但是最好是用 opus 这个模型哈。如果说用其他的一些模型，我感觉效果都不太好，它其实跟自己主动去调这些子智能体有关系，可能 kimi 会稍微好一点，但是总体来讲我自己使用下来还是 opus 会比较好一点。 因为我这几天基本上我们自己搭的一个服务器是把这个 cloud code 放在了国外的一个云服务器上，然后去调到国内来的。我们是几个人去拼了这种二十 x 的 这种账号 来保障，当然大家如果有需要的话也可以联系我，但是必须要用量大一点，如果用量小的有太大必要去买一些 token， 还稍微好一点， 像我们我们自己基本上一个人就是得消耗十 x 级以上，然后这样的话会很划算，它不像 token 消耗，你会感到心痛，但是你如果用这个的话就完全不会心痛，你会想的是怎么样去能把它全部用完，有点跑题了。 我也是开源了这样的一个项目，它是一个 skills， 其实我是拿来自己用的，然后借鉴了这种 benning with fields， 还有这个 cloud code 的 黑客松的冠军，他分享的这个几个子智能体，然后还有最近非常火的一个滴滴，滴滴的一个 skills， 然后结合了他们的一些思想，创建了这样六个子的 team 团队，后端开发、前端开发研究员，还有这种端造端的测试，最后是这个审查，然后是清洁器，呃，其实就是一些重构的东西，其实都是借鉴的这个里面的，大家如果需要的话也可以直接拿这个去安装， 安装了之后其实就是里面有个 skills， 然后它读取，让 opus 去全量读取，但是它注意有一个点就必须要让它全量读取这个 skills， 不要让它去起一个这种探索的智能体去读，要不然它就会很有问题，它没有了解全的话，去创建的话就会创建的不太好。 然后把这个 skills 弄上去了之后，它自己会问你，你想要完成一个什么样的任务，然后需要哪些子智能体，然后这些子智能体的功能它也会跟你说，说了之后它会自己去创建。 然后最最重要的是我认为它比较好的点就是我需要它把这些所有的进度和 plan 和这种发现全部放在这种文档下面，而不是放在它自己的一个全局的文档里面， 这样的话我就能看到，而且它每一个这种角色它都有这样的文档，然后它这种文件持久化，比如说主文档 leader， 它有这样三个文档，这后端的它有三个文档， 然后研究的也有三个文档，但是最重要的是他每一个项目或者说每一个任务他都会再创建一个子文件夹，下面又有具体的文档，是这样的，所以说效果还是蛮不错的。我自己使用下来，虽然达不到完全自动化的去做开发， 但是确实非常不错。他这个 leader 他 会去主动的去分发给这下面具体的任务，然后基本上能完成一个小的功能的开发，由这个 leader 去分发，并且把测试这些全部跑完， 但是可能你人工还是需要测试的，不太可能能像全自动的，除非你就是很简单的像这种随便一个任务，它都是要突破这个两百 k 的 上下文的，所以说你把它这个 team 我 觉得最好的一个点就是它把这种两百 k 上下文的任务去分摊到了各个子智能体， 可能说两百 k 哎，本来 leader 是 可以完成的，但是它可以分给让这个前端后端这些乱七八糟的去每一个分个一百 k， 虽然总的托管是增加了，但是它是没有突破上下文，所以说它的性能还是很不错，但是不得不说哈，它的托管消耗是真的可能是之前的两倍及以上， 所以说大家如果用的话还是注意，如果不是自己实际的应用或者是之前的两倍及以上，所以说大家如果用的话还是注意，如果不是自己实际的应用，或者是之前的两倍及以上，所以说大家如果大家如果用的话，才有必要去做尝试。

用可乐的扣子写项目，聊着聊着就会蹦出来一句话，提示你上下文窗口快满了，一旦压到上下文， ai 就 开始抽风，出现上下文腐烂的问题。问题是在命令行里边，你压根看不到上下文用了多少，等提示的时候就晚了，尤其是你在这个绘画里面已经取得了一些项目进展的时候。 如果你有这个痛点，强烈建议安装可乐的哈的这个插件，执行三条命令就能用了。装上之后，在终端底部会出现一个实时的状态栏， 以进度条的形式显示当前窗口的上下文使用情况，还会显示 ai 正在调用什么工具，跑什么 a d 的。 当可乐的卡住不动的时候，一眼就知道它是在思考还是在调用工具，还有显示当前项目的 get 分 值，任务代办进度。 这种感觉就像给开车从没有用过仪表盘的人突然撞上了仪表盘。使用可乐的扣子，心里面就有数了，可以很清楚的看到可乐的在做什么，剩余的上下文有多少，哪些工具处于活动状态。当你管理多个变形的可乐的绘画的时候，会非常有用。点赞关注，每天获取一个新知识！

现在的模型基本上都是两百 k， 但是你在编程的时候到底用了多少？这个你有仔细去看过吗？今天我给大家分享一个怎么样去设置 cloud code 的 一个上下文查看窗口，这个不像 code x 它会显示这个上下文， cloud code 它是没有默认显示上下文的，只有到最后的百分之十的时候它才会显示。 第二个点就是给大家分享一下我今天踩的一个坑，因为我总感觉做一些稍微大型一点的项目的时候，他的上下文窗口特别的窄，因为我可能做一些稍微大型的项目的测试啊，或者说修改的时候，我想要去拿到足够的上下文，可能就是五轮对话或者十轮对话，他就要压缩上下文了。所以说我就详细的看了一下他的 contacts， 给我震惊到了， 可以看到我这是一个新的对话，他两百 k 的 上下文，我有效的使用空间只有百分之六十四点五不到， 而且是我优化过后的，我把 mcp 删到只剩下了一个 playwrite 的 mcp， 因为我要做这个端到端的测试，所以说留下了这个 mcp。 在 我没有进行优化的时候，比如说在它这个 memory fails， 它里面包含了很多这种嗯规则的文件夹，因为我之前安装了蛮多的黑客松他分享的 cloud code 配置的项目， 所以说我可能就安装了很多这种东西，大家一定安装的，一定要删掉，不要堆很多。我之前启动的时候， 新对话它的这个自由空间就只剩下了百分之四十多，相当于我只有九十多 k 是 有效的空间，其他的全被什么 m c p 记忆文件塞满了，并且它这个记忆文件还跟那个记忆文件还不一样，它其实就是你的一些命令行的一些东西，它会全量的加载。 我们来详细看一下，它的系统提示词包含了四 k， 然后系统的工具就包含了二十二 k， 然后它还要保留三十三 k 的 百分之百分之十六点五的不能侵犯的空间，因为它要做这种上下文压缩，所以说这一部分空间它是直接给你砍掉了的，所以说不管你做什么，它至少有五十多 k 的 上下文是你完全用不了的。 所以说这个点大家还是要知道一下，特别是你的 m c p， 你 的工具，你的这种规则记忆不要写太多，写太多会影响你的上下文，这都是我优化过后的，它有百分之六十四的上下文还可以用，这个是一个特别巨大的坑，特别是 m c p， 别堆一大堆 m c p 上去，你的 contacts 打开来一看， 你这个个 m c p 如果说上了两三个，肯定你这个 m c p 在 十 k 以上了。 ok， 我 们今天还是给大家分享一下这个看上下文的一个项目，但是它这个是到百分之八十二的时候，就基本上是到了它要压缩的上下文，它是按照两百 k 来计算的，不是看按照这个有效上下文来计算的。 所以说大家看在七十的时候，其实就要思考把现在的任务做一个归档和这个总结了。你可以直接告诉他，你的上下文不够了，我准备要压缩你上下文，你有没有什么需要记忆的或者收藏起来的东西，因为我是用的 team 模式，我会专门去给他创建很多，比如说这个是后端的，然后我会让他去把这些文档给记录下来， 然后这个这种一二一的测试的，这种是代码的主要 leader 成员的，然后我会让它记下来，所以说我到七十五 k 的 时候，我基本上就会让它做收尾了，因为你如果不收尾的话，你上下文压缩了之后，它很多信息就丢失了，下一次执行的任务它效果就非常的差。这个就是那个项目 cloud h， 它其实就很简单，首先是你的项目，然后它是什么模型，然后对应用量的上下文调用的工具调用了哪些也有，然后使用了哪些子智能体也有，但是它对这个 team 模式是支持的比较少的， 同时它这个用了哪些 team 它也没有显示，但是它可能后面就慢慢会更新，然后代办事项这种 task 和 to do list 它都会去写下来。 然后安装也是很简单，直接安装这三个，如果说有问题的就可以直接把这个文档发给他，让 cloud code 去给你做安装。但是它有一个比较好的一个点哈，就是它这个是热启动的，只要你安装好了之后，你所有的都不需要什么重启啊这些它直接就可以完全显示。 然后配置的时候，大家也可以把它这个功能全部配置上，因为它这个并不会增加这种托管的消耗，所以说它都是按照钩子这种脚本的方式来做的，做的这种总结，所以说不用担心，直接使用就可以了。 ok， 最后也可以说一下，或者打一个广告，我们几个朋友去做了这样的一个中转，可以大家一起去拼这种二十 x 的 账号，这样的话基本上就不会有被封的风险。如果说大家有用量用的比较多的，也可以点我主页沟通一下，但是如果只能用这种 二十美金的，这种一个月只能做二十美金，其实就完全没必要哈，你如果能用掉这种五 x 的 以上的，可以可以联系我。 其实就是我们几个朋友去搭了这样的一个类似于中转站吧，因为现在很多中转我们自己使用的时候发现反正他有点掺水，然后又不是 cloud code， 所以 说还是蛮大的问题的，而且很容易封号。如果你在国内用的话，你只有去搞个云服务器，在国外这样会稍微好一点，并且他这个 cloud code 是 真的有点痛苦，他还要 连做机制，就是你一个 ip 搞爆了的话，其实你上面的所有账号都废了，它基本上都会给你连连做全部封掉。呃，这也是现在给大家很大的诟病的，但是从实际使用下来还是 cloud code 的 效果会更好，像欧帕这些再多智能体啊，这种使用其实都是 cloud code 的， 会效果好很多， 这也是很痛苦的一个点。但是国内的一些小模型，它模型的性能还是不够的，特别是你在调用一些子智能体，或者说 skills 的 触发上面还是国外的 opus， 它的效果要好很。

ok， 好， 那么再往下啊，就是斜杠命令系统，那么回滚啊，它其实是一种代码管理的这样的工具，而斜杠命令系统啊，是让它内置的很多脚本的功能啊，这个可拉扣的这个斜杠命令系统实际上是非常强大的哈，当然怎么说呢， 这个这个也是属于命令行环境里面特有的一套功能体系，也是方便大家在命令行里面在进行操作的时候啊，很多的这个操作便捷性的这个考虑啊，所以有一个命令行的这个斜杠斜杠命令这样的系统， 但是如果假设你是一个外部页面的话啊，假设哈，我们假设如果你是个纯粹的外部页面的话，那么其实你完全可以把所有的斜杠的这个命令系统全部都给它改造成 你的外部页面上的很多按钮，对吧？啊，其实你就这么理解啊，就一个意思哈，你外部按钮上点一个，相当于是你斜杠命令运行的一个对不对？ 比如说这个 clear 清空历史对话，你也可以把它做成一个按钮啊，点一下历史对话就没了啊，然后呢，就跟你在命令行里面输入斜杠可列是一样的啊，这么来进行理解就可以了。 ok， 那 么在现在的 acl 里面跟我们提供了哪一些这个 斜杠命令呢？这里面总共是五十九个斜杠命令哈，非常非常多啊，当然这个大家不用死记硬背啊，其实核心的命令呢，之后我们看到你会经常使用的啊，然后我们这里呢，给大家提供了一个完整的命令的这个列表啊，可多了 啊，大家回头可以自己去看一下啊，领到课间之后，有需要的话，你可以把单独把它拎出来啊，做成一个表，然后有需要可以自己看一下，包括什么绘画管理啊，啊？是不是啊，什么 point 模式啊，什么各式各样的模式， 什么项目与上下文呐？啊，这主要是修改这个记忆的，对吧？哈，还有什么配置与状态呀？啊？什么拓展与 agent 呀，还有账户与平台，主要就是登录啊，看你扣费情况啊，类似这些健康命令啊，很多啊，总之这些命令就这么回事啊，你这个用多了也就习惯了，对不对？等等等等，很多命令。好，那这里面我们是一个非常重要的一个命令，是 init， 那 么 init 这个命令呢，我们需要知道的话，它就是按照某个脚本哎，给你一步到位来进行运行。 而 innit 这个命令，它呢，实际上是执行了一个内部的一个流程，就是让 cloud code 再次去看你当前整个项目的一个基本情况，然后形成 cloud code， 呃，形成 cloud 点 md 那 样的文档，换而言之说，它是一个全自动的生成或者修改 cloud 点 md 文档的这样的这个命令啊，这么理解就可以了。 那么啊，当然除此之外哈，输入这个 edit 之后，它还会创建点 cloud 那 个文件。之前不有同学说说啊，我们运行了 cloud 之后没有看，没有看到项目级的点 cloud 那 样的这个文件，对不对啊？这个时候你输入 edit 就 有了啊，是那么一回事， 那么为什么普通时候没有哈，是因为如果你是比较简单的这个项目的话，它其实完全不会生成这个点 cloud 那 样的文件啊，是因为你的绘画呢，都是存储在 这个项目主，呃，是存储在你当前用户主目录下的点 cloud 那 个文件夹里边啊，它并不是存储在你项目的这个主目录文件夹里边啊，所以呢，其实你普通的对话其实并不一定会创建点 cloud 这个文件， 但是如果你输入 init 这个命令之后，那么它就会创建啊，点 cloud 那 个文件，还会创建对应的这个 setting， 点 json 那 个文件啊，只不过这个时候呢，它只是创建那个壳子啊，都是空的啊，是这么回事， ok， 好， 所以这里面呢，我们可以考虑一下啊，输入一个啊，杠 init 这样的文件 啊，杠， any 这样的命令，那么这个命令哈，实际上对吧？啊，他会这么说啊，创建 cloud， 点 md， 哈，这样的这个文件， ok， 好， 开始来进行创建。 那么这个时候呢，我们发现，哎，我们现在已经有了一个 cloud 点 md， 对 不对？我们又输入了一个 any 之后呢，那么接下来他就会把原来的 cloud md 这个文件里面内容来进行一个替换哈，替换成他觉得 最能够呃，代表我们现在当前这个 agent 开发的这个基本原则的这样的一组，这个，呃，这样的一组文字，他会觉得你写的不行啊，我帮你写一遍，好，差不多这么个意思，哈哈哈， ok， 好， 你会发现啊，它果然啊，生成了一个，你看，这就生成了一个新的 cloud 点 m d 这样的文件，对不对啊？大家这个生成了之后，可以自己打开看一下哈， 就长成了这个样子，哎呀，更加规范，它能够非常详细的描述我们现在开发的一个基本要求啊，这个就是 init 啊，这样的一个命令的核心的这样的价值， 那么除此之外，我们说通用的啊，还有很多的一些斜杠命令哈，当然很多斜杠命令其实我们在开发的过程中会用到啊，那么除了开发之外，对于项目管理啊，其实还有很多其他的一些斜杠命令，比如说 context 啊， context 其实就是一个典型的啊，用于去查看我们现在还有多少额度的哈，这样的一个问题， ok， 我 们输入 context 之后，你会发现啊，现在，哎呀，还有这么多的一些这个额度啊，对不对啊？当然它每五个小时会刷新一次，那么我们当时输入输入输入这 context 的 时候呢，跟我们说你现在总共呢？ 呃，是这个当前这个绘画，首先哈，当前这个绘画里边儿也总共呢，是数占用了百分之十七的啊，这个 context 啊，上下文呢，现在总共占用了占用了三十四 k 的 上下文。 然后呢，这三十四 k 的 上下文分布在哪里？你看看咱们当前这个对话，总共也用了三十四 k 的 上下文了，你看看上下文总在哪里啊？跟我们说啊，有 system prompt 啊， system tools， memory files 啊， skills message 啊，还有等等啊，有这么多的这个 啊，这么多的这个，现在上下文的这样的占用啊，这里面能够看得非常清楚啊，叫 context， 当然你再往下翻啊，还有关于你现在啊，当前这五个小时内还剩多少额度的一个这个说明啊，当然我们说如果你是这个使用 api key 的 话，你还可以通过输入杠 cos 的 看一下你现在这轮对话总共你花了多少钱了？也是可以的 好，那么除了这两个命令之外，有一个非常非常重要的命令啊，是一定需要跟大家说的，叫做 compact。 那 么我们之前呃，有说过，好像现在的这样的 agent 都是无限上下文的这样的 agent， 那 么大家有没有想过这个无限上下文是怎么实现的呀？ 你对一个呃呃模型来说，它的上下文是有限的啊，对不对？比如说对于 cloud code 来说，它就是二百 k 好 上下文，它再多也不行了啊。呃呃，这 sorry， 对 于 cloud opus 四点六来说，它就是二百 k 的 上下文啊，再多了也不行了啊。 sanet 能有能有一兆啊？当然四点六它拓展模式下也能够有一兆，但它上上下文是有限的。 那么对于你 cloud 的 这个 cloud code 来说，它是如何能做到无限上下文这样的一个事情的呢？非常简单，就是靠 compact 啊，就是靠它的上下文压缩。 而对于 club 扣的来说，它的上下文压缩说实话比 open club 做的好多了啊。那个我们这个呃，从专业的角度上来说哈， club 扣的在很多方面其实都比 open club 要好很多啊，只不过 open club 是 开源的，这个实现啊，受众比较广，仅此而已。 比如说对于上下文压缩来说， open club 也会做，但是 open club 上下文压缩怎么是什么样情况呢？是到了某一个线之后自动触发来进行压缩，并且呢不能定制化来进行压缩， 而对于 color code 来说，它是能够来进行定制化的。这个压缩的什么意思？就比如说当我们输入 compact 的 时候呢？首先你不管现在上下文是多少，你都可以输入 compact 来进行压缩。其次呢，这个命令它不仅仅是一个命令哈，你可以在空格后面加上一段你想压缩的方向，就比如说我希望重点保留什么什么东西， 你也可以说，比如说什么什么东西不重要，这个时候呢，他就会调用 coco 的 内部的工具来完成上下文的压缩，他压缩的方法是通过一段描述的文本去代替掉你历史的啊，巴拉巴拉这一系列的这个来回的这样的回复啊，包括工具调用这样的信息等等等等来进行一个代替， ok， 那 么这样的压缩效果，其实哈， 根据我们实际的这个使用情况来说，效果还是非常好的。那比如说我们在命令行里面输入 compact 之后呢，那么他呢，实际上就会啊来进行压缩，他会自动保留非常重要这样的信息。然后呢去这个啊，不对你上下文的来进行一轮这个压缩啊，当然我们现在这个项目比较小，所以压缩效果不是非常明显， 比如说我们现在看到这个项目啊，这这个呢是呃，我的使用这个复盘 cc floor 这样的一个外部端的这样的项目来进行运行的时候，当时来进行一轮压缩啊，比如说这里面我们曾经哈是进行一轮压缩， 那么压缩完了之后，当时是开发完了某一个功能哈，所以我这主动触发的一个压缩啊，那么你主动触发压缩，怎么触发呢？非常简单，你这里点击压缩上下文，然后这里面可以有选择的给它输入一些压缩的一些，这个 如何压缩这样的描述啊？这个呢是可以的，那么除此之外，你也可以直接呢在斜杠命令这里，比如说输入斜杠啊康，呃，好的， compact 啊， compact， ok， 你 选择了之后呢，你就可以再输入空格，然后跟他说，比如说我希望， 我希哎啊，我希望重点保留项目架构信息， 然后你输入回车，他就可以来进压缩了啊，所以你会发现，对于现在的这个，呃呃，我们直接让他来进压缩试一试哈。对 于现在的这 qq 的 来说，他的压缩呢，是可以有选择性的，这个压缩有倾向性的压缩，并且压缩完了之后呢，呃，你还可以去查看，当然这个查看比较复杂哈，如果你借用我们前端项目的话，你查看起来会比较简单啊，但是如果要自己看的话，可能会比较复杂， 可以去看它现在压缩的一个成果和我们现在它的压缩之后呢，形成了一段什么样的这个文本，它是用一段文本去代替历史对话嘛，对吧？所以呢，你这里是可以看到的， 比如说我们上一轮的这个压缩，它呢就有一百七十六 k， 压缩到了四十九 k， 节省了百分之七十一的这个 talk。 然后你可以去看它现在的啊，这个历史压缩这个内容啊，它是用什么样的文本代替掉你原来的对话这样的信息啊？其实啊，它的压缩效果其实还是很好的哈，反正我这边看的是比 啊，是比这个 club 扣啊，是比这个 open club 压缩效果要好很多了啊。但是他这个压缩其实往往需要比较长的这个时间，因为他要去读 全部的上下文，然后呢要去开启一个比较复杂的任务才能够完成这个压缩。这个呢我们就是先让他这个压缩着啊，我们一会再来看他最后压缩结果。 那总之呢，任何项目他都是可以来进行上下文压缩的啊，是没有什么问题的。好，那么除了啊，这些命令之外呢，还有好多好多茫茫多其他的一些命令啊，这个大家可以回头自己去看 看一下啊，自己来进行一个这个使用啊，对不对？包括我们之前还用过比如说像 revine 的 这样的命令啊，它是来进行这个回溯的啊，我们之前还用过这个 doctor 这个命令啊， doctor 这个命令就跟 cloud doctor 是 一样的啊，来进行一个诊断的啊，等等等等。好，那这个呢是它的内置的啊，一个这个斜杠命令系统。