context window设置

我的小龙虾脑梗了，今天跟我的小龙虾聊得正嗨，突然他给我回复了一条错误消息， order contest window exit。 中文含义就是模型上下文窗口超过了最大值。 我下意识的发了一句帮我修复这个错误，结果他依然返回同样的报错。我想了一下，这种情况是没办法让小龙虾自己修复的。 其实原理很简单， open cloud 的 所有行动靠的都是底层大模型的推理，现在大模型已经卡住，连你的指令都读不进去，怎么可能修复？这就好比一个人晕倒了，你不能指望他自己给自己做心肺复苏，这时候必须人工介入，给小龙虾做开颅手术。 第一，登录服务器输入 open cloud t u i 进入它的终端模式。第二，输入命令杠 compact， 一 键压缩上下文，看上下文瞬间从两百 k 压缩到了二十二 k， 瘦身百分之九十。再问他一个问题，小龙虾立马复活了。你在用小龙虾时有遇到过哪些坑？评论区聊聊。

三分钟讲清什么是大模型的上下文。 context window， 它是什么，怎么算，超了会怎样，以及你该怎么避开这个坑。 为什么你跟 ai 聊着聊着，它突然就忘了前面说的话？不是它笨，是你超了它的记忆上限。 context window 中文叫做上下文窗口。 context window 就是 ai 一 次能看多少内容的容量上限。 你可以把它想象成一张工作台，台面越大，能同时摆的材料越多。台面太小，新东西一放上去，旧的就得扔掉。 ai 处理你的问题时，会把你这次输入的内容、之前的聊天记录、上传的文档全都放到这张工作台上。如果内容总量超过了窗口大小， ai 就 会自动丢掉最早的部分 窗口大小。用 token 来计量，一个中文字大约等于一点五负二个 token。 截至二零二六年二月， gpt 五点二的窗口是四百 k tokens， 约三十万字 cloud opus。 四点六是二百 k tokens gemini 三点一 pro 支持一百万 tokens。 听起来很大，其实不然。 一份五万字的技术文档，加上你的提问和 ai 的 回复，很快就会占满一百二十八 k 的 窗口。 超了窗口会怎样？ ai 会自动截断最早的内容，你会发现他突然忘了你最开始说的需求。有些模型会启动压缩机制，把早期对话总结成摘要，但可能丢失关键细节。 你该怎么避开这个坑？第一，别把所有材料一股脑扔给 ai。 第二，长对话要定期重启，如果 ai 开始答非所问，直接开新对话。 第三，重要约束要反复强调。举个真实场景，你再用 ai 帮你改简历。你先上传了一份三千字的简历，然后开始逐条修改。聊了二十轮后，你让他按照最开始的风格再写一段， 结果 ai 给你写了个完全不同的版本。为什么？因为简历原文加上二十轮对话，早就超过了窗口上限， ai 只能看到最近几轮的修改记录，已经看不到原文了。记住这一点， context window 不是 ai 的 长期记忆，而是短期工作台。它决定了 ai 一 次能处理多少内容，但不代表它能记住你之前所有的对话。 所以下次 ai 突然失忆时，先检查一下是不是你超了它的窗口上限。

呃，我现在演示一下那个怎么去。嗯，配那个 open call， 就是 如果用那个自定义的那个 open ai 的 那个端点的话，就这是一个空白的命令。行，然后我这个就是这个讯基已经安了， 就是你没安的话，其实步骤差不多，只不过我安装了的话，我用这个命令，然后我重新选择一下，如果你没有安装的话，你直接拿脚就是那个官方的脚本直接运行就可以， 就是弹出的画面差不就是一样的。然后我点继续，然后继续， 然后继续到这个模型提供商的时候，你选倒数第二个，就是这个用自定义的那个模型提供商，然后选择让他给你一个视例，然后你把它删了就行。 就是我这边是给了你一个，我应该是给了你一个端点，给他复制到这 一敲回车，然后他让你输入那个 api k， 然后把 api k 粘到这儿，然后继续， 然后他问你，呃，要这个兼容吗？啊，对对，就这个兼容的，这个这个组合的这个就选是就可以了，然后你输入一个模型 id， 你 比如说你用 gpt 五点二的话， 啊，这不要数错啊， gpt 五点二中间有一个杠，然后回车，他验证， 啊，这是验证成功了啊，这个回车就可以啊，这个别名回车，然后这这这我已经配过了，其实不用管我挑过 啊，这个也挑过，继续就可以，让我重启， ok， 他 让我，嗯，这个继续就行，打开那个 u i， 嗯，可以了， 它已经连接了， ok， 这就已经成功了， ok， 这是没有问题的。然后就是有一点要注意啊， 我先敲回车，就是如果它不行的话，就是配完不行的话你注意一下，你检查一下这个文件，就它的主配置文件， 就这个文件，然后点回车这边的话是 下面的是幺六三八四这个。

右键新店菜单老是自动增加了许多无用选项，想删除却又无从下手。别着急，这个小工具帮你搞定。这个软件是一个纯粹的右键菜单管理程序，免安装，直接打开。以桌面的新店菜单为例，最初是这样的， 调整完后是这样的，软件中的新建菜单对应此处设置，把其他的都关掉，然后把三大件的名称进行简短的自定义，再去桌面右键新建看看吧，大功告成，收藏下来你一定用得上！

一会我们在聊天的时候啊，你好的时候他是不会回复的，为什么呢？因为在 providers 提供器里边，我们没有给他去配置， 就是在这没有配置，那么如果我们的套餐里面有很多一个低级模型，又等着你用，或者我们用不常用的模型怎么办？就是我们这样啊，大家注意看提供器 providers， 把这啊大家看，直接从这到这都给他去，从这到这都给他删掉， 然后打开笔记啊， 我们把这个大家注意看啊，你把你的模型的名字放在这， 然后其他的在这照抄就行了。这个是窗口的大小，这个是 max 头肯，虽然我选择了最小的一零二四，但是呢实际上他至少他不会这么小的。我们先看一下刚才这里面他的默认是多少，他是大概 是一百三十一 k 啊，就是他是这样的，一百三十多 k 除以一零二四。这个呢，我们给他尽量小一点，把这个拿过来， 把这个删掉啊，把这个一拿过来。这块大家要注意一下这里是否是推理， 那我们就给他这么写下， 那这个地方就是你的模型是推理还是不推理，就这写处或者 false， 其他的就照抄就可以了。然后我说一下窗口大小跟 max token 的 意思，什么意思？ context 上下文窗口。上下文窗口是什么意思呢？指的是模型一次对话能记住最大的 token 数量，简单说模型一次能看到文字的历史内容，加上当前的输入， 那超出这个窗口它会怎么样呢？就会挤出去一部分，那么就会造成失忆。而这个 max 头款就是你每次最大输入的，这个我们是可以自己设置，从而呢让你的头款进行一个结缘，然后这个 id 呢是什么？就是你在这里面你选择模型的时候， 它是什么，你就可以给它写上。比如说咱们这个是赠送的四点五二，你就把后面这个给它拿过来，你看就放到 id 这上面。为什么咱们没有这个 z a i 杠？是因为 怎么外层有个 z a i o。 那 么如果同学们用的是我这个质谱跟我一样，直接照抄我这这个就可以了，那我是把多余的给它删掉了，只留一个四点五。为了让大家看着方便，这是提供器 proender 所主要的 pr i primary 这个单词， agent 默认的代理默认的模型，主要模型，这是主模型，后面是 forback， 是 备用模型。这个咱们要自己写啊。 如果咱们不是自己编辑这个文件，咱们在这选的话，你选完之后它就会变成一个 glm， 他这个是没办法去选咱们自定义的这种地段模型的。那么有同学发现设置完模型怎么都用不了， 那可以用这种方式去手动去修改模型，这个名字也是在这去选，你在这复制，带着前面斜杠左边的跟右边的完整的放到这， 那么这个文件设置完之后一保存就好了。但如果咱们在那保存完之后，在这，又比如说我现在又去保存一个，我再 continue， 那 它就会覆盖。比如我们现在再双击它， 我们再搜 friend， 大家看，只要你在命令行里面去设置了它的主模型，这儿就会改成不是。咱们要的就是咱们必须在这儿改完之后，不要在这里面再继续去，再 再去命令行再改一次，那么大家如果在命令行里面又去设置这个文件之后，我们还要去手动修改 open collog， 这次文件给它改成我们自己要用的模型， 那智普赠送给我们的套餐里面，他是没有五的，所以我们这不但不会消耗最低版本的这个四点五二，同时还会聊天报错，大家可以举一反三啊。看一下我们的 配置文件里面，它的主模型里面的版本是否是我们自己购买套餐里面所带的版本，如果不是就自己手动改一下这个 api k， api k 不 光是在命令行上设置在这里面， 大家注意看是在这个文件里面，它是能设直接去修改这个的。

别再浪费 cloud 上下文了，这个工具直接干掉百分之九十八荣誉数据。在 cloud code 中，每次调用 m c p 工具，都会将原始数据转储到二百 kb 的 上下文窗口中。 playwrite 快 照占用五十六 kb， 二十个 decryption 问题占用五十九 kb， 一个访问日制占用四十五 kb。 三十分钟后，百分之四十的上下文数据就会丢失。分享一个 github 项目，让你的 cloud code 和 m c p 服务器之间的输出又减少了百分之九十八。

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

上下文窗口 ai 的 记忆力？让我们看看 ai 是 如何记住对话的。 步骤一，什么是上下文窗口？上下文窗口就像 ai 的 短期记忆，它只能记住最近的对话内容。 步骤二，为什么有限制？因为处理更多内容需要更多计算资源和时间，所以必须设定上限。步骤三，不同模型的窗口大小不同的 ai 模型有不同的记忆容量，从几千到上百万个 tock。 步骤四，超出窗口会怎样？当对话太长时， ai 会忘记最早的内容，就像滑动窗口一样。 步骤五，如何有效利用上下文窗口？合理利用上下文窗口，可以让 ai 更好地理解你的需求。 核心要点，记住，上下文窗口是 ai 的 工作记忆，合理使用才能发挥最大效果。

去年十一月， ansorepic 发布了一系列新的测试版功能，只在解决我们在构建 ai 智能体时遇到的一些实际问题。 工具定义在你发送第一条消息之前就已经占用了大量的上下文。当智能体连续执行多个工具调用时，这些工具调用的中间结果会进一步膨胀上下文。 而且随着你在系统中增加工具的数量，智能体在为任务选择合适工具时会变得非常吃力。因此，这些测试版功能帮助解决了这些问题。而且随着两周前 sony 四点六的发布，这些功能已经在云 api 上全面开放。 在他们的原始帖子中，他们展示了这些功能如何帮助实现了八十五百分之的 token 使用量减少。 这也导致一些网友宣称 entropic 已经终结了工具调用，或者至少是传统的工具调用方式。虽然这种说法有些夸张而且确实不准确，但这两个功能编程是工具调用和工具搜索工具 确实是非常巧妙的解决方案，在集成到任何 ai 智能体中时都能发挥极高的效用。而且关键在于这些功能并不是云 api 独有的，也并非最初就是 entropic 的 创意。 这些是智能体构建的核心模式，适用于任何框架或模型。我会解释这两种高级工具调用如何运作，并演示如何集成到你的定制智能体中。 这正是我在这里所做的事情。我已经把它集成进了我的系统，这个系统是我用 python 和 react 定制开发的应用，这是我在本频道过去四期视频中逐步搭建出来的。 我还用全新的困三点五，拥有二百七十亿参数的模型来测试这些高级工具调用方法。所以与其直接跳进理论部分，不如我们在应用里演示一下。 而最简单的切入点大概就是先演示一下工具搜索工具。所以即使只是打个招呼，我们也能收到一个简短的回复。但在底部，你可以看到我们正在追踪本次绘画的上下文窗口。 我们已经用了一万三千个 token， 为了弄清楚发生了什么，如果我们切换到 langfuse， 如果我们看一下这个生成追踪，你会发现已经有六十个不同的工具被加载到上下文中了。 虽然听起来很多，但实际上只有两个 mcp， 就是 playrite mcp 和 github mcp， 再加上一些我在前几期节目中开发的工具。 所以工具搜索工具的关键点在于你不会一开始就加载所有内容。你会延迟加载让代理去搜索他，所以他会多出一个额外的步骤。现在我会把这些 m c p 服务器标记为延迟加载，然后让我重启一下服务器。 如果我再次问同样的问题，比如我们打开一个新的聊天窗口，输入 hello， 然后得到一个回复，你可以看到我们现在只用了六千三百个 tokens。 如果我们看一下这个追踪，你会发现现在只有十二个工具被加载到上下文中。第十二个就是这个工具搜索工具。 这个工具允许代理在工具注册表中搜索，通过名称或关键词来发现并加载工具。为了演示工具搜索的实际效果，我们让他获取这个项目的最新提交。这是一个私有项目，所以他需要使用 m c p。 你 可以看到他现在正在触发工具搜索。他找到了一个工具， 就是 list commits 工具，然后他用仓库的信息触发了这个工具。好了，我们得到了提交 id 以及提交内容的信息。 如果我们查看这次工具搜索的响应，你会发现 listcommits 是 一个延迟加载的 mcp 工具，它会把这个工具的完整模式加载到上下文中。 现在这个工具已经被加载到接下来对话的上下文中了。所以如果我再问任何后续问题，就不需要再去搜索这个工具了。比如说给我最后一个提交，我就可以直接使用 listcommits 工具。 如果我们切换到 langfuse， 在 我发送的第一条消息中，你可以看到只有十二个可用工具。然后在它触发工具注册表搜索后， 在下一次调用中，我们有了十三个工具，包括 list commits， 并且它能够对此作出响应。而在我后续的问题中，我们同样有十三个可用工具。 简而言之，这就是工具搜索实际的工作方式。虽然这已经非常有用，但我认为以编程方式调用工具更加令人印象深刻。如果我们开启一个新的聊天，现在我们在 opodder 上使用的是 cloud hikou， 我 一会会切换到 queen 三点五。但我想先给大家展示一下云端模型和开源模型在这里是如何工作的。为此，我们将使用 anthropic 在 其文章中发布的官方示意。 这里他给出了一个预算合规检查的例子。然后问题是哪些团队成员超出了他们第三季度的差旅预算？ 这里有三个可用工具，分别是获取团队成员，获取支出和按级别获取预算。他在这里展示了传统的方法，也就是需要大量的工具调用和许多中间响应，这会导致上下文窗口被迅速填满， 所以我已经写好了云端代码来生成这个场景的虚拟数据。首先我们来看一下传统的做法，我已经关闭了沙河，现在我来提问哪些团队成员超出了他们第三季度的差旅预算。 正如我之前提到的，我们现在用的是嗨酷模型，所以他正在执行工具搜索，获取报销数据，获取团队成员。现在他正按照这种传统方式操作，需要为每一位成员逐一获取报销信息， 让我们看看会得到什么答案。所以第三季度差旅预算分析显示，有三个人超出了他们的差旅预算，这是他给出的结果。 根据测试数据，这个答案是正确的，但实际上应该有四个人，所以他似乎漏掉了一个。 marcus johnson 超出了预算一千七百， 所以这种传统方法实际上消耗了大量的工具调用。实际上有五十六次工具调用。正如你在这里看到的， 它处理了七万六千个 tokens， 但实际上并没有给出一个准确或者说全面的答案。这正是程序化工具调用能够解决的问题，因为所有这些其实都可以通过脚本自动完成。 因为一旦你知道了团队成员和预算水平，你就可以用一个负循环来获取每个用户的开销，并计算实际的超支情况。 那么现在让我们起用沙盒，并尝试用程序化工具调用来实现。好的沙盒已经开启，让我们重启后端，打开一个新的聊天窗口。好的哪些团队成员超出了他们第三季度的差旅预算？现在正在进行工具搜索。他找到了所需的三个工具。 现在他进入了编程模式，并创建了一个即将被执行的脚本。他抛出了一个错误。这其实并不奇怪，因为他并不知道这些工具的输出结构。所以本质上，如果没有所有信息，他就无法一次性完成。 现在他正在不断迭代自己的代码，实际上是在尝试得到一个结果。你可以看到他不断抛出错误，并且正在逐步解决。 与 anthropomorphic 的 论文相比，这可能是更贴近现实的程序化工具调用方式。因为我相信在 anthropomorphic 的 论文中，它是一次性完成的，而实际上并不会这样。经过多次迭代后，我们得到了一个准确的答案， 所以二千二百， sarah， chen， marcus， alex， emily。 所以 我们得到了所有正确的答案。 这很好，但这才是程序化工具调用的现实。它的方法相当迭代，就像 cloud code 或 open code 一 样。出于兴趣，我们再运行一次，看看能不能得到正确的答案。它会不会走一条不同的路径。我们假设是的， 很有趣。这一次它实际上是在预算层面获取团队成员的信息，所以它实际上是先获取所需的数据，然后再生成代码。所以这次它可能一次性就能完成。 但实际上他并没有做到，他仍然在自我迭代。不过我们确实得到了正确的答案，所以结果是对的，每一次都是如此，只是到达结果的路径不同。所以我们来看看这两条追踪记录。在我刚才运行的那一次中，总共进行了六轮调用， 总共调用了十二次工具，总提示词数为五万八千。现在如果我继续这个对话，目前只用了一万三千，但这是在与大语言模型进行了六轮来回交互的情况下。而之前那一次是在十一轮中用了十一万六千个 prof tokens， 都是为了得到正确的答案， 所以我确实没有看到 anthrax 所报告的八十五百分之的 token 节省。但这其实非常依赖具体的用力。 比如说这里我是在和二十个团队成员一起工作的，如果你有两千个团队成员，那情况就完全不同了，因为大圆模型需要运行两千次单独的调用，这根本行不通， 所以在那种情况下，就需要程序化的工具调用。或者你就需要一个真正的端点，让实际的数据处理在服务器端完成，而你只是获取信息并将其展示给用户。所以这其实切中了这个话题的核心。 也就是说，你的大圆模型到底应该像这样临时进行数据处理，还是应该仅仅从一个预先创建的脚本中传递信息？ 比如说这个脚本可以放在一个技能文件夹里，因为这是我们在上一个视频中搭建的一个完整的技能部分。你可以有一个 python 文件，一旦创建测试并验证后，它就能真正完成这项工作，或者你也可以把它放在工具调用的 m c p 端，这样它就只是简单地传递接收到的信息。 那么我们把 cloud haiku 换成 queen 三点五二十七亿参数，来看看它的实际表现如何。我现在是在网络上运行这个模型，这里用的是欧拉玛，我有一个十万个上下文窗口长度，这里用的是 rtx 五零九零，显卡有三十二 gb 的 显存。 那么我们保存一下，重启服务器，然后问同样的问题，哪些团队成员超出了他们第三季度的差旅预算？现在加载需要一点时间，因为他需要把模型加载到内存中。好了，他已经触发了工具搜索，然后直接开始生成代码。 他实际上在工具调用之间没有输出文本，但你可以看到他正在生成代码本身，而且他正在经历和嗨酷一样的迭代过程，他正在从错误中学习， 并且在不断完善。看看，这就是我们的答案。让我看看二二百十五十七，还有三百，看起来很准确，我觉得这比嗨酷用的 tokens 更少，这很酷，我们来深入看看追踪记录吧。 是的，这次用了四万五千个 tokens 就 得到了准确的回应，这真的很棒，只用了四次工具调用，这已经相当不错了。这是我们 ai builder 系列的第五个视频。在这个系列中，我们正在用云端代码构建一个功能完善的 ai 系统。 本模块的 prd 可以 在我们的公共 github 仓库中获取完整的课程和代码库则在我们的社区中提供 相关链接在下方描述中。那么好吧，这一切到底是如何运作的呢？因为你可以看到我们正在这里的沙箱中触发代码执行，但这实际上意味着什么呢？所以这是一个完全本地化的系统。 我之前用的是嗨酷配合 open router， 但现在用的是 queen 三点五，这里内置了一些文档和 r a g 功能，使用的是 queen 三的嵌入模型。所以你看到的这个代码执行其实是在 docker 中触发了一个沙箱。你可以看到 现在所有这些容器都已经启动了。这里有一些孤立的容器是因为我一直在重启后端。但总体来说，代码执行都是在这里的一个隔离沙箱中进行的。 而这个架构安全性的一个关键部分就是工具桥的概念。所以从头到尾，当用户提出问题时，他会先到 fast api， 然后到 python， 接着再转发到 ai 模型。无论是远程还是本地的， 我们会收到一个工具调用，也就是你需要去执行这段 python 代码，这时后端就会启动一个沙箱容器。 我在上一个视频里已经介绍过这个的设置过程，但本质上我们用的是这个 github 仓库，也就是 llm sandbox。 这是一个非常清亮即可移植的沙箱环境，你可以配合 docker 这样的工具使用。或者如果你不用 docker， 也可以用 portman。 但本质上，这大大简化了启动这些环境的复杂性。 它们支持多种语言，还有许多不同的高级功能。你可以预先启动容器，而不是按需启动。 你也可以使用自定义镜像。这个项目里有很多很棒的功能，所以我会在描述区留下相关链接。我在上一个视频里已经非常详细的讲解过了，所以基本上我们就触发了那个容器的创建， 然后我们会把代码和一个绘画 id 一 起传递进去。所以现在在这个容器里，我们有一个 python 运行器，它会执行那段代码。在我们之前的例子中，有很多不同的工具需要被触发，比如获取预算水平、获取部门、获取团队成员， 而所有这些都可以存在于比如说一个外部系统中，但我们并不希望让沙乡访问外部服务。 相反，我们创建了一个安全的工具桥梁连接回 python 应用程序，然后每当工具或函数在 python 脚本中被触发时，都必须通过这个桥梁。正如你之前看到的，单个脚本中可能会有五十次不同的 api 调用或工具调用， 所以对于每一次工具调用都需要通过这个桥梁，它会使用绘画 id 来进行身份验证， 然后 python 应用程序会将该调用路由到外部系统获取响应后再将其发送回沙乡。因此，除了访问这个 python 应用程序中的 fast api 之外，沙乡没有任何互联网访问权限。从安全角度来看，你可以对这个 fast api 进行严格限制， 这些限制是基于工具本身的精确模式，所以所有这些工具片段、工具定义都是在创建时作为存根发送到沙箱中的。因此，多个工具调用会在 python 代码中，比如说在一个 for 循环内进行， 而且这样做速度非常快，因为此时你完全忽略了 l l m 没有任何中间代码堵塞上下纹。在这里， l l m 完全不参与这个过程，直到 l l m 完成脚本并生成响应。你在之前的演示中已经看到了， 然后这个响应看起来大致是这样的，这就是我们的脚本结果，然后这个结果会被反馈给 l l m。 l l m 接着可以决定下一步该做什么。 如果它已经获得了所有需要的信息，就可以生成综合响应并返回给用户。或者正如你在演示中看到的，它需要对代码本身进行迭代。在很多情况下，它会生成更多的代码，并再次触发沙盒环境。 这就是端到端的流程。我在这里提到了 gviser， 因为 docker 容器并不是你能拥有的最安全的隔离沙盒，因为它们与整个系统共享内核。 所以为了真正保障像 ram， sandbox 这样的安全性，我建议你搭配 gviser 一 起使用。 cloudflair 曾经做过一些有趣的研究，探讨了 ram 在 生成 python 代码或 type script 以及触发工具和 mcp 方面的有效性。他们发现，当工具以 type script api 的 形式呈现，而不是标准的 mcp 时，智能体能够处理更复杂的工具。 我认为这是有道理的，因为他们在训练时接触了大量原生的 python 和 javascript， 所以 在 cloudflared code mode 版本中，也就是我们所做的类似，他们会把 mcp 的 schema 转换成 type script， 因此 l l m 只是生成 type script 代码来触发 m c p。 这和我们正在做的事情非常相似。所以我刚才提到，工具存根被发送到沙盒中。因此，我们在智能体层面定义的 m c p 和工具会被转换成 python 存根 自动生成的 python 函数。这样，当 ai 为沙盒生成代码时，它实际上只是触发 python 函数， 而且因为这是原声 python， 所以 它在这方面会非常擅长。而且重要的是，沙盒永远不会接触到 api 凭证，它永远不会接触到任何机密信息或类似的内容。 我之前提到过需要高效的工具设计，因为在早期，有太多的 mcp 服务器完全塞满了你的上下文窗口，让你根本无法完成任何实际工作。 即使在 anspec 自己的文章中，他们试图解决的挑战也是关于臃肿的 mcp。 在 这里，他们提到 github 的 mcp 有 三十五个工具和两万六千个 tokens。 但即使是在这篇文章发布之后， github 也发布了他们 mcp 的 新版，现在这个数字大约是四千个 tokens。 所以 在 mcp 和工具调用端其实可以做很多工作来确保不会无谓的给你的上下文窗口增加负担。 最后， entropy 在 他们的高级工具调用工具包中还加入了另一个功能，就是关于工具使用视力的这个概念。因为虽然 jason schema 非常擅长定义结构，但它无法表达使用模式。 他们举了一个例子，比如说截止日期，它的数据类型是自复串。日期格式有很多种传递方式， 那么他们到底希望用哪种日期格式呢？除非你真的引导他，否则大圆模型是不会知道的。所以，通过工具使用势力，你可以为每个字段提供一个势力，以便让大圆模型朝着正确的方向前进。比如在这里，日期格式就是年月 日。在他们的测试中，他们发现这能将复杂参数处理的准确率从七十二百分之提升到九十百分之，这很合理，因为本质上这就是多轮提示。你只是给了一个你想要的视力，这绝对会引导模型朝着正确的方向。 实际上，我不确定你是否需要把这个设置成系统中完全独立的功能。我认为，使用技能这个概念意味着你可以在加载技能时提供视力，这样就可以触发你想要实现的任务的执行顺序。 你会发现 cloud 也有点类似，里面有很多功能是重叠的。 antropic 之所以没有取消工具调用，是因为他们认为你应该有策略力对这些功能进行分层。 所以，如果你的上下文因为工具定义工具搜索而变得臃肿，如果你有大量中间结果污染了上下文，那就走沙河路线。或者，如果 ai 总是把错误的值传递给参数，那么使用工具势利就是有意义的。非常感谢你的观看，我们下期再见。

一夜突讲清楚 ai 硬核技术，很多朋友在问， openclock 三点七版本大更新搞出的这个 context engine 到底是个啥？是不是官方又出了个新的记忆功能？ 错，官方这次直接把桌子给掀了。大家看上面的结论， context engine 不是 一个新功能，而是官方把记忆处理这件事从底层固定代码变成了一套可替换的插件接口，为什么这么干？ 看左边，以前 open class 的 记忆逻辑是写死在底层的，对话一多就直接粗暴截断， ai 动不动就是 e， 你 要是不爽想改对不起只能去改底层原码，非常折腾。所以到了三点七版本，看中间， 官方开放了七个生命周期接口，把记忆处理彻底解偶了。如果你什么都不配，它会默认给一个兜底方案，跟你以前用的一模一样。但如果你觉得官方的方案太差劲，看右边，你现在只需要在配置文件里敲一行代码，不用改任何原码， 就能直接给大模型换上过目不忘的记忆外挂，还不懂看下面这个通俗类比，这就跟 openclaw 现在指定接口规矩， 至于你是用官方的默认实现，还是用社区里最火的 lsl 无损记忆插件，完全由你自己决定。 所以总结成一句话， context engine 的 价值不是官方又给你加了一个记忆功能，而是把记忆怎么做这件事彻底开放给了生态，不满意官方方案直接拔掉换一个， 这就是顶级架构的魅力。把这张图存下来，下期一页图，我们讲讲三月十三日版本是怎么把浏览器接管给补齐的。点个关注不迷路。

每天一个 ai 新词汇，今天要学习的是 context window 上下文窗口。通俗讲就是 ai 能持续承接你需求的有效记忆时长，本质是它能同时调取用来回应你的所有历史对话信息的时间与容量边界。 这就像你找了位专属生活助理，他的有效记忆时长只有固定的三天，你周一跟他明确的不吃香菜，饮品要无糖，周末要提前备菜这些固定偏好。周四在找他安排采购时，一旦超出了三天的记忆窗口，这些前提要求就会被完全清空。他只会按你当下说的新指令形容 窗口大小直接对应这个记忆有效期的长短。大窗口能记住你近半个月的所有需求与偏好，不用你反复重复。前提，小窗口只能记住你最近一小时的对话，稍隔一段时间多聊几句，之前的关键信息就会丢失，出现答非所问的情况。

openclaw 三点八，能让你的龙虾消耗更少的 token， 更省钱，想要速度更快，然后回答也会更精准，那这个原理是什么呢？首先使用 openclaw 比较久的用户都知道，你跟他聊天聊的比较多了，他就会失忆。 其实这是因为你跟他聊，你们的记忆呢，上下文呢，就会不断堆叠，堆叠堆叠，直到啪失忆了，因为他的这个上下文是有一定的量，当达到一定量的时候呢，他就会把某些一部分的记忆 给压缩，换成一些 summary 的 总结，这个俗称 compact。 那 这样呢，就会导致，哎龙虾聊着聊着就失忆了。 所以我们开发了曼九点 ai 这样一个记忆管理的插件，你可以理解为把你的记忆去上传到云端，然后通过 f t s 技术，在你和它聊天的时候，只召回跟你正在聊，正在做的工作，直接相关的一些事情。 那这个云端的空间是无限大的啊，当然云端的存储就跟网盘一样，如果你的这个虾不小心搞死了，对吧？重装一下，只要把密码重新一输， 所有的记忆都会回来。我觉得这个是 open cloud 这个非常基础的，也是非常必备的一个记忆的一个工具了。那回到刚才我们说的这个 context engine， 怎么帮助到我们更省 token， 然后更精准，更快呢？那其实 在有 context engine 之前呢？呃，市场上也有非常多的这个 memory 的 插件，整个这个 memory 体系有点像网盘一样。呃，你的 context 内部是一个黑盒的，它到底什么东西该留，什么东西该存，什么时候？ compact 其实你是完全不知道的，那在很外围的地方去存取一 一些这个记忆上的东西，那 context engine 呢？其实提供了更细力度的一些，呃，整个生命周期的一些接口，比如它提供了像这个 bootstrap， assemble， 呃， compact after turn 等等。那通过这些 hooks 可以 让你 啊，这个让你这个记忆的插件呢？像这个手术师一样，可以把整个 context 更细力度的，整个生命周期什么时候该存，什么时候该取，什么东西要一直留到最后，那让你参与整个生命周期，这样你就有机会把整个 context 做得更加的精准，更小。那其实大家都知道，因为 context 它相当于你跟这个 ai 对 话的时候的这个上下文的容量，那如果没有这样的一个小手术的去处理，它会带一大堆的废话，那把这些废话去掉之后，不但更快更省钱， 而且呢，它自然这个给这个大模型，呃一个更精准的输入，那自然响应也会更加的完美。那 context engine 是 今天刚发布的，同一天我们就实现了对 context engine 的 支持，呃，也实现了这个更细力度的 context engine。 那 除此之外呢，曼姆九点 ai 还可以实现多加的共享 实时的哦。比如说我们在做一些大的工程的时候，我们会编排，我们会有一个 orcas， orcas 就是 一个编排者，然后他有哪些项目经理一样，然后管理更多其他的龙虾， 比如谁负责写 prd 啊，谁负责开发啊，谁负责做设计，谁负责上线测试等等。那这个时候呢，麦姆九点 ai 呢？只要共享同样一个 space id， 就 可以实时共享这些啊龙虾的一些记忆，那这些是更高级的玩法，我可以在后面的视频里面给大家去分享， 请大家多多关注我，了解更多 open cloud 相关的一些知识。那曼九点 ai 也希望大家多多支持。现在还是免费的，无限的一个存储，走过路过不要错过，我们下一期再见。