抖音解析盒子session怎么获取

几周前，我发现自己在使用代理时做了一件自认为非常聪明的事情，但我觉得这件事太简单了，不值得专门做成一个技能。 对于那些不了解的人来说，我一直在思考技能相关的事情。我一直在思考如何将我的直觉和编程实践打包成可附用的技能，这也导致我的技能仓库在录制时已经有将近十万个星标了。 我开始思考的这个技能是一个交接技能。理论上，这个技能会把当前绘画的上下文窗口压缩成一个 markdown 文件，然后可以交接给另一个绘画。 所以几周前，我把这个技能发布了。它在 skills 目录下的 productivity 文件夹里，具体在 handoff 这个位置。这是一个非常非常简单的技能，它的作用是编辑一份交接文档，总结当前的对话内容，以便新的代理能够继续工作， 将其保存到用户操作系统的临时目录，而不是当前的工作区。我把它放进了我的技能文件夹里，作为一个实验，看看我会用它多少， 结果发现我用的非常多。在本视频中，我将为你深入讲解这个技能，包括我为什么设计它，它的意义是什么，它与一些工具包，比如 compact 内置工具的对比， 以及你如何最大化利用它，让你的 greening 环节发挥最大的效果。首先，让我解释一下为什么我要开发这个技能，以及它与您可能听说过的压缩有何不同。 当我们处于这样的绘画中，比如一次编程绘画时，随着我们与智能体的交流，它调用工具编辑文件，这个上下文窗口就会不断被填充，内容会越来越多， 越来越多的 tokens 会填满这个上下文窗口。现在，在我使用的 cloud code 框架中，它的上下文窗口非常大， 对吧？你可以获得多达一百万个 token 的 上下文窗口。但实际上，在这些上下文窗口中存在一个智能区和一个低效区。在上下文窗口的前期，你会发现智能体的表现要好得多，因为那里的注意力关系没有那么紧张， 因为要计算的 token 更少，这些 token 之间的注意力关系也更少，所以智能体的注意力不会那么分散。换句话说，当里面的内容更少时，它能够更好地集中注意力。 这意味着，随着你的对话不断进行，你从智能体那里得到的回复会变得越来越笨，一直到比如说达到八十万个 token。 当然，我个人从没到过那个程度。因为大约在十二万个 token 的 时候，我就已经感觉自己进入了低效区。所以这也就意味着，尽管 astropics 宣传这些模型有很大的上下文窗口， 但实际上，如果你想让他们真正聪明地完成任务，你只有大约十二万个 token 可以 用。这就要求你必须非常高效地分配资源，并且时刻关注你的上下文窗口。那么问题来了，当你开始接近这个低效区时，你该怎么办？ 你要如何让你的对话恢复正常？你要如何在保持智能的同时让对话在低效区之外继续下去？答案就是 compact。 compact 的 作用是，它会把像这样的大型对话进行总结，这样你就可以从接近低效区直接回到高效区。 有时候还会有一个自动压缩缓冲区，这取决于你使用的是哪种工具，以及你是否开启了这个功能。这意味着，当你快要用进上下文窗口，比如已经深处低效区时，自动压缩缓冲区就会启动，并在一个新绘画中自动总结你的对话内容。 这个总结通常看起来像是被引用的文件列表，也就是仅仅列出已经被引用的文件。你在对话中说过的话通常也会被包含进去，对话的整体语气也会被体现出来。 然后这些内容会作为一个小斋，要被放在新绘画的开头。随着你在新绘画中不断积累上下文，你也会持续引用旧绘画的内容。这意味着随着你不断的压缩和再压缩，最终你会得到类似沉基层一样的内容。这些都是来自之前对话的不同层次。 这种方式可能有点低效，但如果你需要在同一个问题上反复深入，这其实也是一种不错的方法。 实际上，这对于调试来说非常有用，因为你可以把之前尝试过的所有选项都压缩起来，然后继续尝试不同的方法。遇到障碍后再压缩一次，本质上就是保存你的状态。所以这是一种进行长时间绘画的方法，但实际上它只算做一个绘画。因此， 我发现 compact 在 创建这种长时间的单一绘画时，确实是一个非常非常有用的工具。但我开始注意到，我希望用 compact 做更多的事情， 我希望能够将内容压缩到另一个绘画中。比如说，假设我正在进行一个绘画，在这个绘画中，我发现了一个小的重构机会，这完全超出了当前绘画的范围和主题，但我知道最终还是需要处理它。 那么我有哪些选择呢？我可以延长当前的绘画，但那样的话，我的上下文就会变得有些稀释。一半在做这件事，一半在做另一件事。这样我肯定会进入那种愚蠢区，所以我很可能无法完成我最初的目标。 我可以进行压缩，但那样我就会覆盖掉当前绘画中所有已经取得的进展。我真正想做的是说，好吧，我想在一个单独的绘画里完成这件事，并且让我当前的绘画保持纯净。换句话说，这才是我想要的。 我本质上是想把与这个额外的 bug 修复相关的上下文，或者说相关的那一部分内容交给另一个绘画处理，然后这两个绘画就可以各自独立运行。 所以有一段时间，我的做法是说好把我当前绘画里的内容拿出来。我想修复这个特定的 bug， 帮我写一个 handoff mad 文档， 这样我就可以把它交给另一个代理来处理。发现这事频率太高，我便决定为此开发个技能。常在烤肉时用 handoff， 比如这次边烧烤边规划 sandcastle 的 未来功能，它是我的一个软件工厂项目。 你可以看到，我在这里其实是在回答一些问题。我现在只进行到这个烧烤绘画的第二个问题，所以这次绘画并不长。我在这里说，我觉得将来我们可能会想把迭代和完成信号迁移到一个单独的 api 上，实际上不如把这个任务交给另一个代理来处理。 你可以看到，当我在定义交接的时候，我会说明我为什么要交接，以及这个文档里应该包含哪些内容。 这样做有两个作用，首先它实际上让我当前的烧烤绘画更加聚焦，所以它的意思是在这个限制下， 第二个问题就可以省略了。所以实际上它对我当前的烧烤绘画很有帮助，因为我可以说这个不在本次讨论范围内，我们会在别的地方再处理。然后它会在这里创建一个 markdown 文件，记录下次会议的重点。 比如提交一个 github issue， 并最终设计将迭代拆分和完成信号分离到一个独立的 api 之后，我只需要把这个内容传递给另一个代理，让他来创建这个 issue。 很 简单， 我还强烈推荐的另一个模式是在烧烤绘画中交接到原型开发。当你在进行烧烤环节时，也就是代理通过 grill me 或 grill with dogs 这些技能向你提问时，你通常会发现需要回答两类问题， 一类是已知的未知，也就是代理可以直接问你的问题。另一类则是你必须通过代码或者原型才能真正看明白的内容。 这在处理 ui 原型或者一些你还不确定如何应对的复杂逻辑时尤其如此。所以 在这个烧烤环节中，我们已经到了第十三个问题。其实代理也给出了一个最终的解决方案。然后你可以看到我说把这里难处理的部分交给原型，比如窗口通信， t l draw s d k 的 集成，这正是我当时正在开发的内容， 他创建了交接点，然后我就在那个分支上实现了原型。所以在原型开发环节，这最终变成了一个非常庞大的绘画，总共有一十六万九千个 token， 远远超过了烧烤环节所能容纳的内容。 我做的是我创建了这个 ui 的 原型，以及我想要看到的那种交互方式。然后我说好的，现在把这个交还给最初发起这个项目的规定环节， 把原型中获得的所有经验教训，任何没有直接体现在原型里或者不那么明显的内容，都整理成一份交接文档，这样我就可以把它传递回给规划者。其实我在这里用的是一个非常常见的模式，就是你有一个出使环节，在那里你做一些工作，然后把它交接给另一个环节， 那个环节再创建一份交接文档，然后再把它传回给最初的环节。这几乎就像你自己动手做了一个子代理一样，你可以为某个特定任务，利用上下文窗口把你从这个任务中学到的内容进行压缩，然后再传递回负极。 然后我就能够完成烧烤环节，并且在里面用原型创建一些合适的 p r d 和任务。所以这实际上是一个非常丰富的模式，可以真正从 afk 代理中获得你需要的东西，并且利用原型，这真的非常非常酷。 还值得一提的是，这里用一个像 markdown 文档这样的东西，而不是依赖于原生代理的方式。酷的地方在于，你可以让第一轮绘画是 cloud code， 但你也可以把这个文档传递给另一个代理。 你可以把它传给 codex， 或者传给 copilot c i， 或者你正在用的任何工具。所以，如果你想做任何类型的对抗性审查，或者让不同的编码代理之间进行任何形式的互动，这都是一个非常非常简单的方式。 我们也应该把这个技能的最后部分读一遍，这样你就能理解每一步背后的推理。这里的理论是，在文档中包含一个建议技能的部分。建议代理应该调用哪些技能？我加上这一点是因为有时候他会 我我用技能来定义那一轮绘画的风格。所以有一个建议技能的部分，就意味着你可以直接把交接文档粘贴到新的绘画里。它会调用所需的技能，比如文档深挖、诊断或原型设计等等，然后你就可以直接开始了。 所以你不需要去考虑下一轮绘画需要用到哪些技能，这真的很方便。还有一条是不要重复已经在其他资料中记录的内容。我经常发现这些交接文档会变得非常庞大，而且只是重复了已经存在于其他 markdown 文件或者像 github issue 这样的资源里的内容。 所以基本上就是说只需要用指向这些内容的链接，而不是把文档里的所有内容都重复一遍。我也非常坚信，你应该把这些交接文件保存到用户操作系统的临时目录中。换句话说，这些交接文件是一次性的， 它们不是那种需要长期保留在你的代码库里，最终变成过时文档的东西。还有一条是要去除任何敏感信息， a p i。 密钥密码或个人身份信息。 p i i i。 这非常重要，你肯定不希望信息散落在 markdown 文件或其他地方。 最后，如果用户传递了参数下一次绘画，将其作为下一次绘画的重点描述，并据此定制文档。 我认为这对于交接来说是非常关键的，因为要写出一份像样的文档，代理需要知道下一个代理绘画将要关注什么内容。 每次我使用交接功能时，我都会描述交接的目的和原因。因为我实在想不出在没有这些信息的情况下，怎么能写出一份好的交接文档。 当然，语音输入让这一切变得非常简单，因为我只需要快速说出来，然后就可以继续了。就是这样，这就是交接。这是我工具箱里一项非常重要的技能。感谢你的观看，我们很快再见。