为啥Agent里总触发不了skill

如果你的 android skill 安装了，但是发现并不好用，比如说总是不触发，大概率是 description 没有写对。今天分享六个呢， skill 创建的技巧，全部是从 ospec 官方仓库里面扒出来的实战经验。第一个 skill md， 要有黄金结构。很多人写 skill md 呢，就是一坨文字糊上去， cloud 其实根本看不懂。 正确的写法是分块， purpose， when to use process， decision， logic， output。 每一块呢，都用标题和列表写清楚。 cloud 呢，一看就知道该怎么执行。 第二点啊， description 的 写法是否正确，直接决定了处罚率，这是最容易踩的坑啊。你写帮助用户处理 excel， 这太模糊了， ai 不知道什么时候该调用你，你得写清楚两个关键信息，第一个呢，叫做能做什么？第二个呢，是什么场景来调用？比如正确的写法呢？是这样的 好，你看前半句，列出了四个具体能力，提取数据，执行透视表，生成图表。后半句呢，写明了处罚的场景，分析表格数据或者自动化工作流，具体化，以 才能被精准触发。而且第二个信息点更关键，因为很多人会写干什么，但是常常忘记写什么时候来触发这个 script。 第三啊，重复的活呢，封装成 scripts。 比如说你经常要抓取网页内容，每次呢，让 ai 现写代码又慢又不稳定，直接写一个脚本呢，扔进 scripts 文件夹，然后在 s q m d 里面呢，告诉 ai 调用脚本就行。注意啊， scripts 文件夹里面的内容再多都是不加载到上下文里面的，而只是执行，因此 intoken。 而且由于是代码逻辑呢，是前后一致的，完全是稳定的。第四个， reference 文件夹要按需加载， qmd 里面超过了多少字就要拆分呢？从时间来看呢，最多不要超过五千字啊，如果超过就 把详细文档呢放进 reference 文件夹里面，在 qmd 里面写上需要时读取某某文件，这样 ai 不 会一次性的塞满上下文，只会在用到它的时候呢才加载。第五个， 直接抄官方的优秀案例， ospeak 官方的 skills 仓库呢，有六万多的 star， 里面的 m c， p， builder， web app， testing， internal， commerce 这些呢，都是生产级的 结构，怎么组织，指令怎么写，资源怎么分配，全部呢，都是现成答案，抄完改成你的领域就行。第六个，打包分享出去， skill 则遵循开放的标准，一个 skill m d 呢，加上 scripts， reference， assets 三个文件夹，打包呢就能给别人用。你做的 skill 呢，越专业，附用的价值呢就越高，对你带来的影响力呢也就 越大。总结一下， description 决定了触不触发，触发率是多少， skill m t 的 结构呢，决定了执行的质量， scripts 和 reference 呢，决定了效率的上限。 ok， 这一期呢，讲到这儿，觉得不错的点个赞，后续呢，还会拆解更多的 skill 的 实战的玩法。

你辛辛苦苦写了一个 skill， 装上去之后 ai 压根就不用它，触发词说了，场景描述也写了，但就是没反应。 今天我就来拆解这个问题。九零百分号的 skill 从不触发，根源在 description 没写对本期是真。我会带你搞清楚三层批录模型 description 怎么写，才会触发工作流阶段结构是什么，以及五大反模式怎么识别和修复， 全是干货，建议一点五倍速看。先说今天要学的四件事，第一，搞懂三层渐近式，譬如模型，明白 l 一、 l 二、 l 三各放什么内容， token 不 浪费。 第二，学会写能触发的 description， 这是 skill 的 唯一入口，不会写等于白写。第三，掌握工作流阶段结构，记住四个要素，编号、入口条件、操作步骤、出口条件。第四，识别并修复五大反模式，让 skill 能通过质量审查上线。 这四件事搞定了，你的 skill 质量会有质的飞跃。三层渐进式批录模型是 skill 设计最核心的原则。 l e 式 description 始终在上下文里大约一百个词放触发关键词和使用场景。 l 二是 skill m d 正文 skill 激活的时候才加载，控制在五百行以内，放核心工作流和速查表。 l 三是 reference 目录下的文件， agent 按需读取，长度不限放详细规范和完整式例。 核心原则就一句话，每层内容只放一层，绝不跨层重复。很多人把工作流步骤写进 description， 这是最常见的错误， l e 根本就不是放这个的地方。 接下来说 description 怎么写，这是整个 skill 里最关键的部分。一个坏的例子是这样写的， description 等于帮助处理文档，这有什么问题？没有触发关键词， ai 不知道什么时候该用，它永远不会触发。 正确的写法是这样，从 pdf 提取文字和表格，填写表单，合并文档，当用户需要处理 pdf 文件或提到 pdf 表单文档提取时使用，看出区别了吗？ 功能描述加上触发场景，再加上具体关键词，格式上有几个硬要求，双引号，单行字符串不超过一千零二十四个字服用。第三人称不写工作流步骤。 工作流阶段结构，每个阶段必须有四个要素，第一是编号，让 ai 知道执行顺序不能乱。 第二是入口条件，就是开始这个阶段之前必须满足什么，防止跳跃执行。第三是操作步骤，编号的具体动作越精确越好，消除歧义。第四是出口条件，怎么判断这个阶段完成了？必须是可以用 yes 或 no 回答的标准。 举个例子，阶段二生成报告入口条件式阶段一的数据已提取到指定文件，步骤是读取数据渲染模板，保存文件。出口条件式报告文件存在且非空，这样写 ai 执行起来不会卡壳。 五大反模式遇到了就必须修，这是硬标准， a p e skill m d 超五百行。 修复方法是把详细内容迁移到 reference 次目录下。 a p 二， description 里写了工作流步骤， description 只放触发条件，步骤放正文。 a p 三，工作流阶段，没编号，没出口条件，每个阶段编号明确定意，完成。标准 a p 四，引用链， 就是从一个文件引用，另一个文件再引用。第三个修复方法是所有引用句 skill m d 只有一跳 a p 五指令不可验证，写高质量代码这种说法完全没用，改成通过 lint 测试，覆盖率不低于百分之七十。 这五条写完对照检查一条都不能放过。自由度设置很多人没想过这个问题，但它很重要，简单说就是操作越不可逆，指令就要越精确。低自由度适用于删除、迁移、部署这类不可逆操作， 写法式精确执行某个脚本，不做任何修改。中自由度适用于有推荐模式但允许变化的场景，比如报告生成，给一个模板说明哪些字段可以自定义。高自由度适用于探索性任务，比如分析代码结构。写文档 直接说分析结构，提出改进建议就行。同一个 skill 里可以混用不同自由度，关键是要匹配操作的风险等级。 可验证性原则是工作流质量的底线，所有出口条件和指令必须能用 yes 或 no 来回答，主观表述要全部消灭。我来举几个对比， 写高质量代码，改成通过 lint 测试，覆盖率不低于百分之七十，合理组织结构改成每个函数不超过五十行目录按模块划分足够详细。改成包含问题、解决方案、事例三个部分， 表现良好，改成 p 九九，响应时间不超过两百毫秒。记住一个判断标准，出口条件要能被程序或人直接验证是或否没有中间态。 说几点我自己的感悟，纯第一人称，聊聊学完这套最佳实践之后的变化。最大的收获是认知转变。 skill 本质上是给 ai 写的 sub， 不是 给人看的文档改变了这个认知，整个写法就变了，以前很多废话自然就删掉了。踩坑最多的地方是 description， 我 一直写的是功能说明结果 skill 从不触发。 后来加上了具体的触发关键词，命中率立刻就上来了。意外收获是三层模型，让我意识到 token 也是成本。 l 三、按需加载是对 ai 的 一种尊重。接下来我要把现有的 skill 全部对照这套标准重审一遍，发现反模式就修。 最后是发布前的质量检查清单，写完 skill 就 对照这个打勾。 l 一、 触发部分， description 有 具体触发关键词，不包含工作流步骤，双引号，单行格式不超过一千零二十四字母 l 二、正文部分 skill m d 不 超过五百行。工作流所有阶段有编号和出口条件，每个引用文件有使用上下文说明。 质量部分不存在五大反模式，所有指令可客观判断工作流。最后有验证步骤，有一项，不过就先别发。 skill 写得好， ai 用得妙。今天的内容就到这里，我们下期见。

如果说你想在克拉蔻的里面真正的去掌握 skill 的 话，你就不能够只从网上去下载别人的 skill 来使用。你需要去了解它们是如何工作的，为什么能够起作用，以及你应该如何去创建测试 优化自己的 skill。 在 这一期视频里面，我会向你完整的分享我平时自己使用 skill 的 一些心得，以及我是如何创建 skill 的。 左边的这一个是没有任何提示词的，直接使用 ai 默认生成的一个网站前端的 页面。右边呢，是我们加了一个设计 skill 之后的一个效果。但是你会不会以为 skill 仅仅只是增强了 colorado code 的 某一个特定功能，但其实不是。我们还可以使用 skill 来构建一个完整的工作流，让 skill 去调用 其他的一个 skill， 从而将我们的生产力提高。但是在学习如何自定义 skill 之前，我们需要了解 skill 到底是什么。不用担心，它的底层原理其实特别的简单， skill 只是告诉 cloud code 用特定的方式去做特定的事情的一个方法而已， 应该来说是一个文档而已，文档规则它就是这么简单。所以只要你能够在克罗德克的里面用提示时做到的事情，你都可以把它变成一个 skill。 它的灵活性是极其高的，几乎可以应用到任何的一个场景里面。 他的工作原理是这个样子，可以访问你列表中所有已经安装的是，他们并不是直接全部加载到你的上下文窗口中。他只是列出了所有你已经安装好的十六的名称，以及一个简短的描述，比如我自己安装的这一些十六， 一些是关于内容创作的，一些是关于视频制作的，还有一些是发布排版的，也有 以及一些关于开发的。每一个 skill 的 功能都不一样，但是它们可以串联成一个流水线。所以当你跟可乐扣子说我想设计一个网站的前端的时候，他就会去看你的 skill 列表里面有没有合适的 skill 能用上，然后他就会抓取对应的关键词， 当他抓取到对应的关键词，发现你的 skill 列表中有关于前端设计的这一个 skill， 他 他就会把这一个 skill 塞到上下文的窗口中，然后使用 skill 里面的内容来进行前端的设计。但是这里他虽然流程是这样，但是我们其实是下意识的做了 两个假设的。这里我们需要讲开第一个假设是我们假设他每一次都能够选对正确的 square， 我 们说过每一个 square 都有一段描述，这段描述可以帮助 colorado 的 做出正确的选择，但如果我想建一个网站来设计一下， 他是不是每次都能判断出哦？要建立网站，所以要用前端，所以要调用那个 skill。 如果说你不止安装了一个前端设计，你安装了很多关于设计的 u a 的 一些 skill 技能的话，你就会看到问题的所在， 我们需要做其他的事情来缓解这两个问题。首先在选对 skill 的 这个问题上，我们要尽量的去精简我们的一个 skill， 使 我们需要的是一把精确的手术刀，而不是说其他的乱七什乱七八糟的什么西瓜刀、菜刀之类的。除此之外，我们还要优化 skill 的 描述，这个可以用 skill creator 来做。后面我会进行演示如何去确保 skill 能被触发， 这是跟提示词的写法有关的。要让 code code 使用某一个特定的 skill， 我 们有三种方式，第一种是给一个模糊的自然语言提示词，然后希望它能够自己匹配上，比如说帮我建立一个个人网站， 这就只是在期望他自己去触发 skill。 第二种方式是明确的告诉他要用哪一个 skill， 比如说使用前端设计的 skill 来帮我做一个个人网站， 他就会听懂。第三种也是最靠谱的方式，用斜杠命令强制去调用，输入斜杠你的提示词名称，这个时候不管你后面说什么，他都会百分百的去调用那一个 skill 呢？一种方式是输入 plink， 打开你的插件市场，你可以搜索，也可以直接往下翻，比如说你想装 load 选的这一个插件，就点击它，然后你会看到三个选项，为你个人安装，为所有的协助者安装，或者仅在你当前仓库安装。 在上一条视频中，我们提到了上下文窗口的这一个问题。所以在添加 skill 的 时候，你得先想一想是不是我每一个项目都需要这一个 skill。 如果说 你只是在特定的项目里面使用特定的这一个 sku 的 时候，你就不需要全局去安装，你只需要把它装到项目级别就 ok 了。在我们安装完之后，你只你只需要重启你的 cc， 你 就可以打开使用这些 sku， 并且很多时候你可能会从别人的视频或者说公众号之类的看到别人分享的一些 skq， 你 想去安装，一般这种分享的 skq 都会附带对应的安装命令或者说 gethelp 页面，你想要安装也特别简单，比如以洞哥的这一个 skq 为例，直接把 他的这一个 gethelp 页面丢给你的可拉的扣的，然后给他说帮我安装一下这一个 skq， 他 就会帮你搞定。如果说你想自己去寻找 skq 的 话，你也可以打开一些 skq 的 聚合网站，然后去寻找你想要的 skq。 讲完安装，我们来聊一下 对于我们自身最有用的一个部分，就是创建属于你自己的自定义 skill。 skill creator 是 a 社官方出的一个 skill， 你 可以在插件市场找到它，也可以在格拉哈普的页面找到它。我们不仅可以用它来创建 新的 skill， 还可以修改和优化你自身现在已经有的 skill， 测量 skill 的 一个性能，或者说去跑一个精准的测试 功能非常多，这就是真正让你的 skill 如虎添翼的一个工具。使用方法也特别的简单啊，直接携带命令，然后 skill creator 就 可以了。然后你只需要描述你想创建什么类型的 skill， 你 甚至可以把这一步也交给克拉的扣的来想，可以看到我这里的视频流水线好像是少了一个标题，对吧？那我们就制作一个标题的这一个 skill creator， 先给 先调用出来，打开我们的一个计划模式，然后给他说你想要的这一个 skill 是 做什么的，比如说我现在我想要创建一个标题深层的 skill， ok， 就 这样，就是这么简单。在使用这一个 skill creator 创建的时候，他不管你是不是会开启计划模式，都会有对应的问题问你。但是我的建议是，你不管做什么，在你没有明确你的方向之前，都把计划模式开散，然后 不断的通过和他去对话，最终完全的去规划好你想要的东西，最后才让他进行创新。我这里就直接选通用标题，这里是可以多选的，然后如果说你有其他的想法，你也可以在这里直接给他沟通。我现在不太确定这一个标题是给我能不能适应多种平台， 所以说我需要你来帮我判断，我们可以继续下一步输入形式是什么？是竹子稿还是选题还是大干？直接选择选择竹子稿，方法论是什么呢？有现成的方法论这里你可以根据自己的需求来进行选择，我这里有动哥的一个知识库，所以我就直接选择 有现成方法论，然后 ai 就 会不断的在和你进行沟通的一个过程中 创建好一个计划，然后这个计划会进行去实施。 ok， 这里有一个集成方式，这里就是我们之前讲过的，通过一个 skill 去调用另外一个 skill， 就是 不断的进行套娃。但是在这里的话，我现在不希望他接入我的视频流水线， 因为我现在还没有进行过这一个 skill 的 测试以及后续的优化，所以我现在希望它独立的使用，但是我需要你保留一部分的接口，以便于后面我优化完成之后呢，把它集成到我的视频流水线里面， 在这个创建思路的过程中，就是我们不断的去和 ai 进行探讨，就是有任何问题就一定要及时的跟 ai 去说。这一点在上一期的视频中我提到过，就是你不知道什么是你不知道的，就是你不知道什么东西是对的，什么东西是错的，那么 你就应该让 ai 去帮你矫正你的道路是对的还是错的，虽然 ai 矫正的东西也不一定对，同时这一个矫正的道路是更多的是对于你自己的想法的一个补充，你不能够完全依赖 ai 给你产出的内容，因为 ai 因为 ai 的 上下文是会腐烂的，说着说着他就变成了一些特别奇怪的东西，当他做好设计计划的时候，你就可以看到他的一些描述的内容，以及他的一些目录结构之类的东西，他是如何去进行工作的，以及 他使用了哪一些方式。当你确定没有问题的时候，你就可以让他继续生成。当你觉得有问题的时候，有哪里不对，你就可以在 后面给他说有哪里不对，他会重新评估你说的话，然后重新给你生成新的计划，我这里只是示范，所以我就直接让他进行生成了。 其实在我自己创建 skill 的 这一个过程中，我都是经常这样，就是让它快速的出一个原型，然后快速的进行验证，然后再不断的去进行打磨和优化。当你从一开始就想把它打磨的很好的时候，其实是很浪费你的时间的，因为你没有通过实际的验证，你就 不知道你的东西做出来到底是对的还是错的。 ok， 当我们创建完成之后，他就会告诉你调用的命令或者说其他的一个东西，然后如果说你觉得他的名字不好，你也可以是进行修改的， 我这里就直接先进行一个测试。 ok， 当我们在发送一条消息，觉得这一条消息不对的时候，是可以按左上角的 esc 撤回的，然后这就是关闭了，然后连续按两下，你就可以回退到你上一条说的话的时候， 然后进行继续的一个补充，使用这一条竹子稿进行测试。 ok， 你 看到了创建一个 skill 就是 这么的简单，然然后续的效果是需要我们不断地去进行优化 和打磨的。但是如果说你在一个行业里面深耕的足够久，当你把这个行业的所有的方法论，制度库都共享给客户的时候，那么他能够给你产出的一个内容的效果是完全会超乎你的想象的。同时，如果说你有一些重复的工作，比如说选择题，精密分析，甚至哪怕只是 把你一个文件夹里面的所有发票都给你整理好，你就可以和他通过一步步的工作规划成一个工作流， 固化成一个 skill。 那 么在你日后工作的时候，你只需要打开这一个 skill， 它就能够去自动化的帮你去完成。 ok， 在 本期视频中，我们讲的是 skill 的 安装，使用以及创建你自己的一个 skill。 当然所有关于克拉的一切都是我自己去自学的，所以说有任何不对的地方也欢迎提出来指正。 ok， 这一期的视频就到此为止，我们就下一期再见。

如果你现在还在花大量时间研究 skill 点 md 该怎么排版，那你很可能已经在一个快过时的问题上越卷越深了。 google cloud tech 转的这篇文章，表面上是在讲五种 agent skill 设计模式， 但它最值得先听懂的一句话，其实不是任何一个模式名，而是格式。问题。已经差不多结束了，作者说的很直接，现在已经有三十多个 agent 工具在共用同一套 skill 点 md 规格，像 cloud code gemini c l i cursor 这些工具，外层长得越来越像， 也就是说，你再去纠结 v a m l 怎么写目录，怎么摆 references 和 assets， 怎么命名，这些事情已经不再是分水岭了。真正的分水岭变成什么是内容设计， 也就是同样一个 skill 点 md 外壳里面到底放什么逻辑，用什么资源，怎么让模型只在需要的时候加载对的内容？ 作者举了一个很典型的例子，一个将模型写 fast api 的 skill 和一个四步走的文档流水线 skill， 外面看都长得差不多，但里面的设计完全不是一回事，一个更像知识封装，一个更像流程控制， 问题根本不在格式，而在内容结构。接着文章先回顾了 google adk 的 skill toolset 三层结构，第一层是 list skills， 只给模型看到 skill 名字和 description。 第二层是 load skill， 模型需要的时候再把完整指令拿进来。第三层是 load skill resource， 只有真正要读参考文档模板或资源文件时，才去按需加载。这个设计背后的核心逻辑很重要，叫 progressive disclosure， 也就是渐进式批录， 先给少量信息，让模型自己决定什么时候再往下拿更多内容。作者甚至直接给了一个量化判断，每个 skill 在 启动时大概只多带来一百个抽肯左右的描述成本。真正重的部分，不应该一开始就全部塞进上下文，而是按需再读。 你看到这里就会明白， skill 设计的关键从来不是把所有规则一口气塞满，而是先把入口做清楚，让模型能找到它，再在需要时拿到更深的内容。所以文章一上来，就先抛出两个最常用也最容易上手的模式。第一个叫 tool wrapper， 它本质上是给某个库、某个框架、某个内部系统封一个即时专家包，比如 fast api、 terraform、 数据库查询规范、安全策略。 这些东西模型不是完全不会，但你希望它在处理这个领域问题时稳定遵守你团队的那条规则， 那你就把这些规范放进 references 里，让 skill 在 需要时加载。这个模式最值钱的地方是把专家经验从系统提示词里拆出来，变成按需调用的知识包。第二个叫 generator， 这个模式不是让模型变专家，而是让模型稳定产出固定结构的东西， 比如技术报告、 api 文档、 commit message， 或者你们团队自己的 agent scaffold。 它通常会同时用到 assets 和 references， assets 里放模板， references 里放风格规则， skill 自己负责把流程串起来，先加载规则，再加载模板，再补齐全的信息，最后按固定格式吐结果。你会发现它和 to rapper 的 差别很大，前者解决的是按什么规则做，后者解决的是按什么结构产出。 所以第一集真正要记住的结论只有一个，现在做 skill， 别再把精力放在格式上了。真正拉开差距的是你能不能先判断这个 skill 到底是在封装知识，还是在稳定产出。如果这一步都没想清楚，你后面写的再规范也大概率只是一个看起来很标准的空壳。 下一集我讲剩下三个更狠的模式，因为从第三个开始， google 讲的已经不是怎么给模型补知识了，而是怎么让模型按标准审查先问再做，甚至被强制卡在一个不能乱跳步的流程里。

hello， hello， 今天给大家讲一下龙虾的多 agent 联动的配置。首先要实现多个 agent 进行联动，每个 agent 必须有自己的独立的工作空间，独立工作空间的目录可以参考这里，这里 显示就是每一个工，每一个 agent 都有一个自己的独立工作空间。第二点，给每一个 agent 绑定一个机器人 bot， 我 们这里以电报或就是 telegram 电报来举例， 这个 channel 对 应的就是通讯软件， telegram 对 应的就是电报，你还可以换成自己的飞书，这里面的 account 对 应的其实就是电报或者飞书里的 bot， 它通过 token 去把电报里的 bot 传输到这个 count 上面，再通过这里的绑定把你的机器人和你的 agent 做绑定， 这个 agent id 对 应的就是你的机器人的 id， 就是 agent id， 这 account id 对 应的就是你的那个机器人。 ok， 我 们下面来讲第三点， a to a example a to a example a to a 就是 小龙虾自带的 agent 和 agent 之间的通信协议，这个是多 agent 之间能够互相伪拍任务的关键。 我们先看一下它的它在配置里配置文件里面的势力，在这里这个 agent to agent， 我们必须要把这个 agent to agent 激活，并且要允许你所有想你所有的 agent 之间要允许它们能够进行互相通讯。只有这里设成处以后， agent 它才可以通过去调用那个 c c c c 的 那个方法去把 任务或者说是消息发送到另一个 agent 身上。我们讲第三点。第四点， session level ping pong 这个的意思就是说你的主 agent， 比如说你的主 agent 要和要给你的子 a 证，要给你的研究 agent 发一条消息， 这这这个任务可能会比较复杂，主 agent 和你的那个研究 agent 深度研究 agent 可能会进行多次的交流，乒乓 limit 就是 限制了他的交流次数，防止造成死循环而导致任务一直无法结束。 我同样给大家看一下这个配置在哪里？这个配置在这里设置的是五次，也就是说我们只允许一个 agent 和另一个 agent 之间相互通信五次，超过五次以后就会强制，强制终止，防止无限的循环下去。第五点， 伪派的时候，我们为了保证伪派任务的稳定性和一致性，我们我我设计了一个伪派协议，伪派协议的具体长的位置在这里，这个就是 我设计的一个伪派协议。这个伪派协议里面我可以着重讲一下这个东西。绘画专用键，也就是 session， 小 龙虾，它的原理就是小龙虾，它是怎么实现我们在呃飞书或者电报上发发消息，大魔熊能够 agent 能够去回应呢？它是通过 你在电报或者说是飞书上面发一条消息，然后通过网关把这条消息发送到对应的 session 里面。这个 session 你 可以理解为就是绘画，虽然说你的多个 agent 都在一个群里面，但是每一个 session 它每个设置这个设置，但是绘画和绘画之间是隔开的，也就是说你在你在群里面，比如说艾特其中一个 agent， 说你好， 你好这个词并不会出现在所有 agent 的 绘画里面，它只会出现在你艾特的那个机器人的绘画里面，它从通过这样来实现了，消息不会串。我们接下来继续讲这个，我们如果想要设置就讲第六点， 我们如果想做一个多 agent 并行的框架，一般来说我们需要命令，需要委派一个 agent 为主 agent， 这个主 agent 我 推荐大家要用足够好的模型，因为主 agent 的 提示语会比较多， 如果没有一个比较好的模型，因为提示语比较多，它会造成混乱，无法做到一个很好的规划和委派任务。最后一点，每次 你一个伪拍任务完了以后，你去把这个绘画的 session 给删掉，防止多次伪拍下来之后你的 session 过多。 为什么会有这么一个机制？是因为我，我的设计师每一次伪拍任务都是一个新的 session， 我 可以给大家看一下。 我的设计是这样子的，我会通过时间戳来实现。每一次伪派都是一个单独的绘画，而不是说每，而不是说所有的伪派都放到一个绘画里面，所有伪派都放到一个绘画里面，就会造成绘画的上下文爆炸， 影响那个任任务的执行结果和稳定性。所以说我的设计是每次委派，每次主 a 政策，委派给其他专项 a 政策，都会创建一个专用的绘画件，专门来处来处理专门的这个任务，这样，但会这样，这样会造成一个绘画报绘画 c 室爆炸的问题，数量会爆炸。所以说一定要 在提示语中强调主 agent， 当你的当你的专项 agent， 比如说代码开发 agent、 深度研究 agent， 当他把他的任务完成以后，他会把结果回传到主 agent 这边，回传到主 agent 之后，主 agent 这边要负责去把 session 给删掉，这个整体的一个 do agent 进行绘画伪派的这么一个原理， 核心就是说通过 agent to agent 这个小龙虾自带的机制，这个协议机制来实现多 a 多 a 证之间的交流。我们单纯的让 在群里面让一个 agent 去艾特另一个 agent 是 没有用的，它是没有反应的。 agent 和 agent 和 agent 之间的交流必须得通过 agent to agent 的 这个协议来实现，或者说叫工具。我是为了让小龙虾内部的 agent to agent 的 这个协议来实现，或者说叫工具。我是为了让小龙虾内部的 agent to agent 的 实现的更稳定， 所以说我自己设计了一个伪派协议。我再补充一点，我们如果你做好了多 agent 的 之间的联动，通过 a to a 的 方式来实现了多 agent 的 联动，你会发现一个问题，就是说 主 agent 伪派给任务到研专项研究 agent， 你 在群里面是看不到这个结果的，它是直接通过 session 推送的方式有用，它会用到一个小龙虾内部的工具叫 session cent， 他会直接把伪派的消息发送给研究型 a 证，或者说我们另一个专项 a 证的的绘画里面去，他是没有发到群里面的，所以你看不到。 我们为了解决这个问题，我们需要在提示与我现在的做法是通过提示与强制要求专项 agent 在 接受到伪派以后，通过 message 的 工具， message 也是小龙虾里面内置的一个工具，通过 message 去显示的 往群里面推送一条消息来实现主 agent 伪派任务给专线 agent， 然后专线 agent 及时地把接收到任务的这个消息的通知发送到群里面，方便我们去追踪实时的状态。我这里给大家看一个其中一个，比如说现在这个是其中一个伪派的 session， 伪派的 session 它这条消息是主 agent 直接通过 session 的 方式 发给到这个专项 a 证的绘画里面的，它这个是不会显示在我们的群里面的，不会显示在飞飞书群里面或者电报群里面都不会显示的，因为对于 对于群里面显示出来的消息是通过 message 这个方法来传送的，因为它是相当于是个外部渠道，而绘画是 openclo 里面的内部渠道， 它用的 openclo， 绘画之间的通信用的是 system send， 而我们说的通讯软件那些都是外部渠道，是通过 message， 这是两个工具。所以说造成了这种现象，然后你就需要显示的要求 agent 去把你的接收到的委派消息，或者说你完成了这个任务，或者说任务遇到了堵塞，显示的通过 message 这个工具 传到你的群里面来实现我们可以直观的一个跟踪。但是我现在这个点我做的也不太好， agent 呢？经常会忘，虽然说我提示里面写的很清楚了， agent 呢？还是经常会忘，会忘记往群里去发这个消息。 ok， 这就是以上工程的全部内容。同时如果说大家不愿意 搞搞清楚原理什么的，最简单的方式就可以把这个提示语喂给 ai， ai 会自己去根据这个提示语，它会去创建一个多多 agent 可以 联动的架构。谢谢大家就就到这里。

你花两小时写了个 skill， cloud 从来不调用，好不容易调用了，执行起来又僵化，结果不达预期。本期我们继续精读 cloud code 核心开发者 toric 的 lessons from building cloud code how we use skills。 它总结了构建 skill 的 九个最佳实践来看如何让 agent 成功调用 skill， 以及如何达到更好的执行效果。这九条实践本质上是在解决三个递进的问题。 第一层问题， cloud 能不能找到你的 skill？ 找到之后能不能理解它该做什么？这是内容层，解决的是被看见和被理解。 第二层问题， skill 能不能在不同场景下附用？会不会因为写得太死而失去灵活性？这是结构层，解决的是可附用和不僵化。 第三层问题， skill 能不能记住上次做了什么？能不能直接给 cloud 可调用的代码，能不能在需要的时候开启护栏？这是高级技术层，解决的，是有状态和可组合。先看内容层，解决被看见和被理解。 第一条， description 字段是给模型看的。很多人把 description 写成功能说明，这是一个监控 pr 的 工具，但 cloud 启动绘画时会扫描所有 skill 的 description， 决定这个请求有没有对应 skill。 它需要的不是功能说明，而是触发条件。 那些在用户说 babysit watch c i make sure this lens 时，触发 description， 决定的是什么时候该用它。这是 skill 能不能被调用的第一道门槛。第二条，不要陈述显而易见的事情。 colin 已经知道大量通用知识，你写 skill 的 时候最大的浪费就是重复他已经知道的东西。 antropic 内部有个 friend and design skill， 一 开始工程师发现 cloud 生成的前端界面总是用 enter 字体和紫色渐变，看起来很 ai 味，但客户反馈说不喜欢这种风格， 于是他们写了个 skill。 这个 skill 不 教 cloud 怎么写 react， cloud 本来就会，他只告诉 cloud 一 件事，别再用 enter 和紫色渐变了。客户不喜欢 skill 的 价值在于补充 cloud 默认不知道的上下文偏好和坑通用知识他都会，你要告诉他的是你们团队的特殊情况。 第三条，构建 gorgeous 部分 andropic 发现，任何 skill 里信号最强的内容往往不是教程，而是 gorgeous。 因为教程 cloud 本来就知道很多，但坑只有你们团队真的踩过。 不要在循环里调用 api， 会慢一百倍。记得清理临时资源，我们生产环境，因为这个词盘满过。真正值钱的是告诉他哪里别踩。理想情况下，你应该随着时间不断更新 skill， 把新踩的坑也加进去。内容层三条讲完了，光有好内容还不够，还要有好结构。 第四条，使用文件系统和渐近式批录。很多人把 skill 写成一个巨大的 markdown 文件，所有内容都塞在里面，但 skill 是 文件夹，不是文件。 你可以放脚本模板，数据文件，主文件里只写核心逻辑，然后告诉 cloud 详细文档在 r e f e r e n c e s 点 m d， 需要的时候自己去读。 比如如果最终输出是 markdown 文件，可以在 assets 里放模板，让 cloud 直接复制使用，按需加载才能最大化利用上下文窗口。 第五条，仔细考虑设置流程。有些 skill 需要用户配置，比如站会要发布到哪个 slack 频道，这个信息每个团队都不一样。用 config 点 json 存储配置，首次运行时询问，后续直接使用。这让 skill 从无状态工具变成有状态助手。 用户只需要配置一次，之后每次调用都能直接用。第六条，避免过度约束 cloud。 skills 可以 被反复重用，所以写指令时要谨慎，不要过于具体。很多人会写，先运行 test， 再运行 lint， 最后运行 build， 但这样写太死了， cloud 没有灵活性。更好的写法是在部署前确保代码通过测试规范构建，并根据情况调整顺序 约束目标，而不是约束路径。给 cloud 它需要的信息，但也要给它适应不同情况的灵活性别把 skill 写成死板的脚本，前六条是基础，后三条是高级技术层，解决的是 skill 运行时的能力建设。 第七条，内存与数据存储 skill 每次运行都是全新的，不记得上次做了什么。 entropy 解决方案，让 skill 写日记，每次运行后追加一条记录，下次运行时读取日记，只报告新的变化。 skill 不 再是无状态的脚本，而是有记忆的助手。 第八条，存储脚本并生成代码。别让 cloud 每次都从头写样板代码，把稳定能力封成脚本和辅助函数，让它负责组合，而不是重造轮子。给 cloud 最好的工具不是更多文档，而是可调用的代码。 第九条，按需 hooks 有 些规则太严格，你不想一直开启，但特定场景下又需要 anthropoid。 有 个 careful skill 会阻止危险命令，比如 r m r f drop table。 当你调用 careful 时，它会注册一个 hook， 只在当前绘画有效，绘画结束后自动失效。九条最佳实践讲完了， 回到开头的问题，为什么你的 skill 不 被调用？为什么调用后效果差？不被调用大概率是因为你把 description 写成了招标，而不是触发时机。效果差大概率是因为你写了一堆 cloud 的 已经知道的东西，或者步骤写得太死。这背后是同一个问题，把 skill 当成 prompt 来写。 siri 的 核心观点是，好的 skill 不是 告诉 cloud 每一步做什么，而是给他组合的能力，让他在执行时自己决定怎么做。本期内容就到这里，这里是慢学 ai， 我 们下期再见。

ai 只是工具，搞钱才是最终目的，别再拿国内大模型当普通的聊天机器用了。今天直接揭秘高级 agent 的 核心底牌， skill！ 什么是 skill？ 它本质上就是一个 markdown 格式的文本文件，但它不是普通的提示词，它必须遵循严格的底层结构，分为配置区和指令区。重点来了，配置区的名称必须是全英文，为什么？因为这个文件必须放在你本地 agent 的 专属 skills 目录下。如果你用中文命名， 一旦路径包含中文，大模型在自动调用时极容易爆错崩溃。记不住路径逻辑的赶紧去补补基础。另外一个必须写好的叫 description 描述，它是告诉 ai 什么时候该触发这个技能。为什么要这么折腾？为了省钱和精准， 把几万字的标准 sop 全塞给大模型，不仅极其消耗 token， 还容易让它产生幻觉。 skill 能做到按需加载，没活的时候不占内存，触发任务了瞬间变身专家，怎么让大模型乖乖听话干活？ 国内开源社区早就有写好的 skill 生成器模板，你把它下载解压，直接丢进你本地 a 证的框架的指定目录里，启动你的终端或界面，直接输入指令，呼出这个生成器。专家，接下来就是大白话沟通，我想建一个帮我管理短视频矩阵的技能， 你需求描述的越细，它给你生成的 skill 文件就越精准。哪怕你完全不懂代码，也能靠它构建出逻辑极其严密、可扩展的自动化工具。这玩意用起来简直降维打击。 那这东西到底能干嘛？盘三个实战场景，第一个解决繁琐的脏活，比如你要拆解同行的爆款视频， 传统做法是自己听、自己抄，自己总结。现在你做一个爆款拆解 skill， 把工作流锁死。第一步，调动插件，把视频转文字。第二步，洗掉口语废话。第三步，提取黄金前三秒钩子。第四步，按固定格式存入你电脑的地盘， 以后你只要把视频链接往里一扔，它自己调兵遣将走完流程，爽感拉满。第二个场景项目统计，我手里目前有多个 ai 变现项目， 绝对不只是盯着某一两个赛道，为了全自动承接这些流量，我给每个赛道都定制了专属的生产线。 skill 不 用在各种国内大模型网页之间切来切去，一套底层逻辑全部跑通。 第三个，高级玩法，同步协助。在内容生产时，我们同时挂载三个 skill， 一 号负责爬取全网热搜找选择题，二号按我固定的爆款逻辑写脚本，三号负责审核违禁词。你只需要下达一个出师口令， agent 呢？就会像老板一样，自动按顺序指挥这三个 skill 干活。 这种模块化拆分，能极大降低国内大模型处理涨任务时的逻辑偏移。最后一句话讲透 skill 和最近很火的 m c p 的 区别。 skill 是 大脑 sop， 它是提示词，是指令，是工作流程。 m c p 是 手和脚，它是外部工具，是接口。 skill 负责调用 m c p 去执行动作，但 m c p 永远只能在 skill 划好的规矩里干活，懂了吗？干货都在这儿，马上行动起来，别再做技能内耗下课！

the skill 点 md pattern 如何编辑真正有效的 ai 代理技能？这篇文章由 beback pod 拷写，介绍了编辑 a 阵的 skill 的 最佳实践。如果你的技能没有触发，问题几乎从来不是指令本身，而是描述。这是大多数人经过一小时的挫折后才意识到的。 你编写了一个 skill 点 md， 放在正确的文件夹中，让代理使用它，结果什么也没发生。你重写了指令，仍然没有反应。 问题从来不是你在技能中写了什么，而是代理用来决定是否激活它的顶部两行内容。技能不是插件，也不是连接到 api 的 脚本。把它想象成为新团队成员。编辑入职指南， 你不用在每次对话中重新解释工作流程和偏好，而是将它们打包一次。当你的请求匹配时，代理会自动获取它们。唯一必须的文件是 skill 点 m d， 其他都是可选的。 skill 点 md 格式是 antropic 在 二零二五年十二月发布的开放标准，适用于 cloud code， open ai codex 和 open cloud。 在 编辑任何内容之前，你需要知道把它绑定哪里。每个平台从特定位置加载技能位置定义了范围。 cloud code 使用用户目录下的点 cloud 斜杠 skills 作为个人技能。点 cloud 斜杠 skills 作为项目级技能， open ai codex 使用类似的路径。 openclaw 使用用户目录下的点 openclaw 斜杠 skills 作为全局技能。当一个技能与另一个同名时，项目级技能会覆盖个人技能，这是大多数人跳过的部分。它解释了几乎所有的技能问题。技能使用渐进式批录三级加载系统， 第一级是原数据始终加载，每个技能约一百个 token， 代理只读取 yaml 前置内容中的名称和描述。第二级是指令触发时加载少于五千个 token， 代理读 skill 点 m d 的 完整内容。第三级是引用文件和脚本按需加载，实际上是无限的，这就是技能可扩展的原因，空闲时的透坑成本为零。最常见的错误是描述字段不是给人类看的，它是代理在决定是否激活你的技能时使用的触发条件。 糟糕的描述只说帮助处理文档。同样糟糕的是指描述了什么，以及何时使用，包含具体的触发短语。 有效的结构是既能做什么，加上何时使用它，以及具体的触发短语。让我们从简单到复杂构建四个技能。 readme writer 是 基础文件输出， get commit writer 展示多个触发短语， code reviewer 展示多文件结构， linear sprint planner 展示 mcp 集成 从 get 和 commit writer 开始。需要文件输出时使用 readme writer 模式。技能太长时像 code review 那 样拆分，需要外部工具协调时使用 linear spring planner 模式。技能一， readme writer 关键模式是收集上下文， 编辑保存到磁盘。第一步，收集项目上下文检查 package jill 或 pie project tom 查找 a n v 视力检查 s e a s e a 文件。第二步，使用标准结构编辑 readme 特性先决条件安装使用许可证。第三步，写入磁盘。 第四步，质量检查没有占位符文本命令准确。技能二， get commit message generator 关键模式是覆盖用户可能提出的不同方式的多个触发短语， 包含这些触发短语，编辑提交消息，帮我提交，总结，我的更改，我的提交应该说什么？起草提交。输出格式使用 conventional commis 规范类型，括号范围，冒号。简短描述类型包括 fit， fix， doc， refractor 等。技能三， code reviewer 展示多文件结构，关键模式是将内容拆分到多个文件中。 skill 点 md 保持约四十行，包含主流程。详细审查标准放在 reference 斜杠 criteria md 中，只有在实际审查时才加载。 输出结构包括摘药，堵塞问题，建议和积极评价。引用文件包括安全性、正确性、可读性、性能和测试的审查标准。技能四， linear sprint planner 展示 m c p 增强模式， 关键模式是技能加 m c p 服务器等于强大的自动化。在前置内容中声明 m c p server lina 流程包括从 lina 获取当前周期和代办事项，分析团队容量，优先处理代办事项，提交计划，供用户批准创建周期并分配问题。 一句话就能触发整个工作流程。 allow tools 自断限制技能，激活时代可以调用的工具，这对于止读技能很有用，防止代理意外写入或执行任何内容。例如日制分析器技能只允许 read grab club 工具。 激活此功能后，代理无法执行 shell 命令写入文件或进行外部调用。这是为观察技能添加安全保证的简单方法。当技能没有触发时的调试步骤，第一，检查你的描述，添加更多具体的触发短语。 第二，检查文件路径，确保 skill 点 md 在 正确的位置。第三，检查 yaml 语法前置内容必须从第一行的三个短化线开始。第四，重启绘画技能，在绘画开始时快照。 第五，使用显示调用测试，如果显示调用有效，但自动触发无效，说明描述需要改进。安全注意事项，技能可以捆绑可执行代码，这种力量使它们变得危险。 实用规则，永远不要安装要求你粘贴密钥的技能。安装前始终阅读 scripts 文件夹。对进行出站网络调用的技能持怀疑态度， 优先使用来自官方来源的技能，如 entropix， open ai 或你的团队。 clawhub 有 virus total 集成，可在安装前检查技能。关键要点总结，第一，描述等于触发条件，不是解释。第二，三级加载原数据质量引用。第三，从简单开始， 逐步增加复杂性。第四，将大型技能拆分为 skill 点 md 加 reference 文件夹。第五， skill 点 md 是 一个开放标准，可跨平台移植资源链接 agent skills 规范在 agent skills 点趟按抽象技能仓库在 github 点 com 斜杠按抽象斜杠 skills open ai 技能仓库在 github 点 com 斜杠 open ai 斜杠 skills 原文链接在 baggy podd 的 page 播课，感谢观看。

大家好，今天分享一个从零开始做 agent 的 思路。最近我要做一些和市场调研相关的工作，这里就大概分享一下我平时做 agent 的 搜索信息的思路。第一步，我会叫 cloud code， 帮我从各大 skill 网站搜索某个产品市场详细调研的 skill， 这时候我会让它收集的越多越好，并对每个 skill 做大概分类，介绍它的用途。 我提前提供了一些自己平时常用的 skill 聚合网站给他，这样就能避免他因为幻觉凭空捏造一些不存在的 skill 混进来。在收集了一圈信息后，他发给了我下面这个列表。因为我现在还处于市场数据非常初步的阶段，所以我继续给他指令来确认最终要用的几个 skill。 因为那么多 skill 肯定不可能全用 在海量 skill 面前，你把它全编排进一个 agent 也不太现实，毕竟我们的目的是让 agent 去解决某个具体问题，所以我向他输入了新指令。针对调研产品市场的初步需求，你最推荐哪些 skill 或组合？请在上述列表中按推荐度从高到低排序给我。 很快他就推荐了几个最优的 skill 组合，同时也给我推荐了一套工作流。这里我真正需要的是什么？因为只是做非常初步的市场调研，目前我不想配备花钱的 a p i 进去，也不想花时间费劲去配 a p i， 所以 我就直接告诉他，我希望你能把这些 skill 编排好，做成一个 agent， 这样我就能在新窗口里调用它，且全程不需要任何 a p i 配置。 搞定这个 agent 很 快就编辑完成了，接下来我们去测试，如果有些地方不够好，随时给出反馈让他修改就行。这就是今天的第一个核心内容。我们可以看到他跑出了一份 md 格式的报告，也就是用刚才构建的 agent 输出的结果。 但这还不太够，所以我就打开 gemini， 通过 deep research 功能抓取了深度市场数据，然后把数据复制贴回给 cloud code， 叫他把新数据结合起来重新分析。同时我还用到了 notebook lm， 我是同样输入了调研需求去梳理内容。大家可能知道有个 skill 能让 agent 直接和你的 notebook lm 对 话，相当于让 agent 自己进你的私有知识库捞数据。 所以我把 notebook lm 的 分享链接发给了 agent， 让他综合着三层信息，第一部分他自己抓的市场数据，第二部分 gemini 找的深度数据。第三部分 notebook lm 里的私域知识 综合分析后，最终输出一份可读性极高、数据真实并且免排版的 html 报告。最后我们打开看下效果， 有整体市场规模分析、细分市场机会矩阵、竞争格局拆解、同类竞品对比分析、差异化机会建议以及消费者洞察和关键词，资料非常详实。为什么我强烈建议大家在开始做 a 阵的时候，先去搜大佬们的现成 skill 组合跑一遍，因为别人写好的 skill 里封装了他们的思维流程和验证过的方法论， 直接拿高端 skill 来跑，大概率不会出错，这可以说是一个效率极高的方法。今天这期视频的实操思路就分享到这儿，这里是 chloe。

cloud 技能开发终于有了评测闭环， skill creator 二点零带来了评测功能 a、 b 精准测试，描述词优化和多智能体并行执行，让技能开发从碰运气变成真正的工程。 以前做技能这些问题你一定遇到过，写完就算完成，没有验证手段改了之后不知道变好还是变差，技能该不该触犯，难以把握。模型更新后，技能还管用吗？核心问题是缺少一套可验证、可量化、可迭代的评测体系。 功能一，评测功能让技能可验证只需一句话，使用 skill creator 对 技能名称运行评估，系统会自动生成测试，用力启动六个并行智能体执行测试输出量化评分和可式化对比报告通过率、失败象具体偏差不再是看起来还行。 功能二， a b 精准测试能发现过时技能同一输入分别在有技能和无技能情况下运行，然后盲审裁决。决策很简单，原声胜出就删除。技能略微领先就保留待测，大幅领先就继续使用 关键洞察模型在进步，你的技能可能在退化，每次大版本更新后必须跑。精准测试功能三，描述词优化让触发更精准 描述太宽泛泛会物触发太狭窄又不触发。使用命令优化描述词后，系统会压力测试大量提示词验证触发准确性，然后自动重写描述逻辑 and fropick。 官方测试结果，六个技能中有五个触发准确率明显提升。技巧，添加负触发器，明确不触发的场景。 快速安装只需两步，第一步，斜杠 putting marketplace at entropics 斜杠 skills 第二步，斜杠 putting install document skills at entropic agent skills 重启 cloud code 后即可使用，无需额外配置，安装后立即可用，无复杂依赖。 四个高级技巧让技能更专业。一、用脚本做关键叫验放 scripts 目录不解释，只执行。二、保持 skill m d 精简超过五千次，性能下降。三、设计可协助的技能，一个技能一个问题，多个技能组合接力。 四、添加负触发器，在描述中明确不触发的场景。技能开发不再是写完就用，而是覆盖测试、测量、优化的完整生命周期。技能成为可评测、可量化、可迭代、可信赖的软件制品。现在就开始使用这套全新的技能开发流程。

所以，如果你也在做智能体，我建议你今天开始换一个思路，不要再指定 the prompt， 而是先问自己这四件事，任务怎么拆？模式怎么选？上下文怎么给？结果谁来审？当你开始这么想的时候，你的 agent 才真正从 demo 走向系统。 这是昨天谷歌发布的一套 a 阵的架构设计方法，我觉得这个内容特别值得讲，因为现在很多人在做智能体，还停留在写提示词、接几个工具，拼一个工作流这个阶段。但谷歌这次其实讲的很明确，真正决定 a 阵的上线的不是提示词，而是架构。 这套内容里，他总结了五大 a 阵的技能设计模式。看完你就会明白，为什么有些智能体只能做 demo， 有 些却真的能落地， 为什么要开始从模块化思考。这一页其实是在讲一个很现实的问题，很多团队现在做 agent， 其实越做越乱，前面加一个提示词，后面挂一个工具，中间再塞点知识库，最后整个系统像毛绒球一样，谁都不敢动。所以谷歌这里提了一个非常关键的方向， 不要再把 a 证它当成一个大一桶黑盒，而是要拆成模块。比如输入要怎么处理，上下文怎么拿，输出怎么生成，结果怎么审核，每一块都应该有边界，只有这样，你这个智能体才能赋用，才能维护，也才能往企业场景里放。先拆开一个 a 证，它技能包 一个完整的 agent 技能其实不是一句提示词，而是一整套设计，里面通常包括什么呢？有角色定义，有模板、有参考资料、有规则说明， 说白了就是 agent， 不 只是你，是谁？请你帮我干什么这么简单。他背后应该有完整的技能包，这样他在执行任务的时候才知道自己该按什么标准做，遇到什么情况，怎么处理，输出又该长什么样。那以后做 agent 不要只写 prompt， 要开始写 skill。 第一个模式叫 to rapper， 你可以把它理解成把一个明确能力分装成工具，让 agent 去调用。比如查数据库，查知识库，发请求，调接口，执行动作，这些都很适合做成图。 这样 agent 本身不需要什么都懂，他只需要知道我什么时候该调用这个工具，传什么参数，拿回来什么结果。这个模式最大的好处就是两个字，稳定。因为你把能力边界定义清楚了， agent 就 不会老是自由发挥。 所以如果你要做企业里的智能体，像审批、查询报表、数据检测这种，我觉得 to rapper 基本是绕不开的。第二个模式叫 generator， 也就是生成器。这个模式适合干什么？适合做报告、邮件、方案、总结文案这种有固定结构的内容生成。 谷歌这里强调的重点不是让模型随便写，而是模板驱动生成，先把格式固定好，再让模型往里面填。比如一份周报，开头写本周正点，中间写进展，后面写风险和计划。那你就不要每次让模型自己想结构，而是直接给他模板，让他按这个框架输出， 这样做出来内容就会更稳，也更适合业务场景。所以这一页其实在告诉你，生成了 agent 想要好用，关键不是更能写，而是更会套模板。第三个模式叫 reviewer， 也就是审查者。这一页我觉得特别重要，因为很多人做智能体只关注怎么生成，但真正决定能不能用的，往往是谁来检查。让一个 agent 负责产出，另一个 agent 负责审核。审什么呢？ 审格式对不对？逻辑顺不顺？内容全不全？有没有明显风险？本质上，它是在模拟真实团队里的分工，一个人写，一个人审。 这个模式就特别适合高要求场景，比如合同、报告、方案、流程、文本、制度、文档。因为你只靠一个 a 站台一次生成很容易飘，但如果后面再挂一个 review 了， 整体质量就会文很多。第四个模式叫 in in 第四个模式叫 in warren。 这页稍微抽象一点，它特别关键，它想表达的是，不要一开始就把所有的上下文都塞给 agent， 而是让 agent 在 真正需要的时候再去拿对应的信息。 比如有些知识规则、历史记录，并不是整个流程每一步都需要，那你其实没必要从头带到尾， 应该是谁需要谁去取，什么时候需要，什么时候再加载。这样做的好处很明显，第一节省上下文，第二减少干扰，第三也更利于系统扩展。说白了，这一页讲的就是上下文不是越多越好，而是越精准越好。 第五个模式叫 poplan， 也就是流水线。这个模式就很好理解了，你把一个复杂任务拆成各个步骤，那第一步理解输入，第二步处理任务， 第三步检查结果，第四步整理输出。每一步只做一件事，前一步过了再走下一步，这就像工厂流水线一样。为什么这个模式重要？因为很多 a 站的失败，不是模型能力不够，而是他把所有事情一次性做完，结果中间出了问题也没人发现。 而 powerline 的 好处就是可控、可查、可回溯，非常适合企业里那些流程明确，结果却要求高的任务。到了这一页，谷歌其实在做一个汇总，意思很明确， 如果你是调工具做 agent， 不要上来就问哪个框架最强，你应该先问自己，我这个任务到底属于哪一种模式？这一页其实已经不是在讲单一模式了，而是在教你怎么选架构。 它像一个决策树一样，先问你几个问题，你需不需要结构化产出？你需不需要检查和反馈？你需不需要步骤编排？你需不需要调用工具？ 这一页是我觉得最有价值的一页。因为谷歌明确说明了，真正好用 a 阵。真正好用的 agent， 通常不是只用一种模式，而是多种模式组合。比如用 powerplay 把流程串起来，那比如说，如果，如果要查外部数据，那再通过 to rapper 去调用工具。 你看，这一下就从单个智能体升级为完整系统了。所以说，很多人老问智能体到底怎么做才专业？答案往往不是更会些 prom， 而是更会做模式组合。 adk 的 思路，渐进式批录， 这一页讲的是一个特别像工程实践的概念，叫鉴定式。譬如什么意思？就是不要一上来就把所有信息暴露给模型，而是随着任务推进，逐渐给他需要的那部分。比如一开始只给目标和基本上下文，后面需要再调用知识再补知识，需要审核规则再补规则，需要执行工具再补工具。

为啥你家的 skill 越多， agent 越不听话？核心问题就出在 prompt 上。 prompt 不是 随便写的话术，是指导 agent 用 skill 的 操作手，特定好规则， skill 才不会用错。你可以把 agent 当成厨师， skill 是 锅碗瓢盆这些工具， prompt 就是 菜谱， 没菜谱，厨师再全的工具也做不出指定的菜。就看这一行核心代码，它专门构建系统的规则喂给 agent。 新手想稳住 skill 执行就三步， 一，写清 skill 适用场景二，把规则写进 prompt 三，按顺序加载 skill 和 prompt 搞定。你是不是也遇到过 agent 乱掉 skill 的 情况？评论区说说是啥场景，我是卷毛，每天一分钟拆解 ai 原理，小白也能听懂。关注我，拆透 agent 不 踩坑。

哈喽，朋友们，我是阿水， a 正的 skill 最近真的太火了，但是很多朋友肯定想知道到底啥是个 skill， 凭什么这么火？那朋友们莫慌莫慌， 我呢已经为大家整理好了一套小白必读的 skill 大 全，今天的内容呢，我们将从简单到困难，一路升级打怪。首先呢，我们来看 skill 的 结构和它的原理， 然后呢，我们通过学习来定制自己的 skill。 这个 skill 呢，我们只需要简单的一句话，帮我根据这篇文章生成 ppt 分 析和内容规划，那它就会自动去执行和生成我想要的资料。 另外呢，我还会给大家推荐一些好用而且必用的 skill， 比如说帮你的文章配图，把杂乱的知识变成一个教学网页， 一句话处理表格等等等等等等。这期所有的资料我都已经整理成了文档，只需要一步一步跟着做，跟着看，就一定可以学会。那还在等什么呢？赶快点赞收藏关注呀！ ok， 那 我们就 let's go！ 那说了这么半天，到底什么是 agent skill 呢？直译过来呢，其实就是技能呗，比如可以把它看成一只小狗，这只小狗呢，它会记路线，听指令，使用工具，能听懂你的语气。那 agent 呢，也是同理，它要和你和平相处，也是要会这些东西的。 所以在 a 证的 skill 的 术语里面呢，它最最最核心的文件就是 skill 点 m d ai 的 工作手册，当然呢，还会有其他的文件，最后将这些文件集合在一起，打包成一个文件夹，这就是一个技能，一个 skill 了。 那有同学就要问了，阿水看着挺复杂的呀，这么做的好处是什么？本质上来说， skill 对 不懂代码和不懂怎么去创建软件的小白群体来说， 是大大降低了门槛的来，如果还是不懂，我们做一个超级简单的 skill 就 好了。这里呢，我用到的是谷歌的反重力工具 模型呢，因为可多扣的真的封号太严重了，我就用 jimna。 那 这个软件的下载方式呢？我已经放进了文档里面，可以说是非常的 perfect， 比如说我们打开反重力，在这里呢，选择模型 jimna pro 就 可以， ok， 我 们就可以开始创建了。那我们就先创建一个可以制作 ppt 的 skill 吧，可以根据我输入的文章链接或者文字帮我生成一个 ppt 内容规划。那按照反重力的创建规范呢？局 skill 必须在这个目录下面， 那我们先用最基础的方式手动创建这些文件夹，这个文件夹的名字呢，就是我们的 skill， 名字就叫做阿水 ppt 吧。这里的文件夹里面呢，必须有一个核心的文件，就是 skill 点 md， 文件 内容我已经创建好了，我们只需要把它粘贴过来就可以了。好了，这就是一个 skill 了啊啊， 有同学就会问了，这么多内容代表什么呀？别着急，我们一个一个来看。那这个文件里面呢，上面两条横线里面的内容，它叫做原信息，里边呢，有两个信息，一个是 skill 的 名字，一个是描述，就是它用来干嘛的，什么时候可以用它？ 那我这里呢，直接写的，用 ppt 的 时候可以用。下面这一大段信息呢，就叫做指令，其实这里就是告诉 skill 它应该怎么做。那这里呢，我就直接写到怎么用，输出的格式是什么？那这个时候呢，就有同学又要问了，你这和自己写提示词有什么区别呢？嗯， 其实呢，还是稍微有点区别的，比如我们之前在用 jimmy 里面去生成，每次都是需要去重复输入提示词， 那如果现在去用 ide 文件，那我们只需要去输入需求就可以了。当然上面这个案例呢，是最最最初级的创建方法，简单的 skill 完全可以这么实现。那在做这个的时候，我就在想，有没有创建 skill 的 skill 呢？ 果然不出我所料呀，可罗得克的官方出了一个创建 skill 的 skill， 它可以通过你的自然语言描述帮你创建一个 skill。 那 这个 skill 的 安装方法呢？大家可以去看我上期视频，巨简单。 当然这期的文档中呢，我也整理了安装方法。安装好了之后呢，我们只需要在这里用大白话描述帮我创建一个可以根据我提供的文章链接 pdf word 帮我生成 ppt 图片。这里呢，因为我们需要用到 nintendo 的 模型 api， 我 们就直接将 api 输入进去就好了。那通过我们这么一番描述，可以看到 ppt scale 就 创建好了，现在的 scale 就是 一个完整的 scale， 可以看到有说明文档，有脚本，还有输出文件夹。嗯，奇怪，我怎么感觉高级版创建起来怎么还比初级版创建起来更快更方便，更简单呢？对，主要是我们使用了创建 skill 的 skill 工具， 那我们来试试效果，出来的效果图呢，都是很不错的。那其实这个案例看下来呢，我们更多的是在用自然语言去写程序的一个功能，降低了代码的难度，而且拉近了普通人和创建软件的距离。所以只要你有明确的输入要求，或者有明确的方法 规范流程知识，创建 skill 工具呢，都会帮你创建出来一个定制的 skill 文档，里面呢，我整理了一些收集 skill 的 网站，里面有成千上万的 skill， 并且呢，我也给大家搜罗了一些普通人常用必备的 skill 工具，比如做 ppt 处理，文档表格处理，我们可以直接拖进文件夹就可以使用了。还有这个就是前端设计的 skill， 还有这个动画生成 skill， 可以 帮你做一些数学上难懂的演示动画。 当然大家也不用太焦虑怎么去把所有的东西都创建一个 skill， 我 们每个人呢，都不是必须成为技能开发者， 我们只需要把自己已经掌握的小技能或者已经沉淀出来的一些方法，重复性的事情交给让他去帮你做一些重复性的劳动力就可以了。那最后呢，资料链接我都放在了评论区， 大家快去手动创建试试吧。这个时候呢，大家就不要吝啬自己的点赞收藏关注技能了，我们下期再见，拜拜！

面试官问，你理解的 agent skill 是 什么？ a， 各位同学听到这个问题，先别急着回答说 cq 就是 给大模型调用的工具或者函数。如果你现在面试 ai a n t 相关的岗位，还只停留在方讯 call 令这个层面上，那在面试官眼里， 你的技术视野可能还留在两年前。 ai 大 模型学习资料可以在主页置顶群里。大家好，我是彭宇，咱们结合大屏幕上这套架构来拆解。大家看， 真正的 agent skill 已经演进成了一套标准化的工程范式。首先咱们瞅瞅最顶上这个紫色的模块，叫认知与路由层。如果你是一个公司的 ceo， 你 会把公司一百多个员工全部叫进办公室一起开会吗？肯定不会嘛，你会先找几个主管？ 在大模型里也是一个道理，如果你直接把几十个技能全塞给模型，它的注意力就涣散了，也就是常说的 lost in the middle。 所以 我们得先做意图识别与技能路由，通过一个 meta agent， 也就是原代理， 先理解用户到底要干嘛，然后从技能池里只挑选最匹配的那几个挂载上去。这里还有一个绝招叫自我反思机制，如果技能执行报错了，优秀的架构不会直接摆烂，而是会让模型捕捉报错。日制 反思一下是不是参数传错了，然后自动修正重试，这才叫真正的智能体。好，咱们顺着箭头往下看中间这个蓝色的区域， 这是物理封装层。大家看这个文件夹图标，现在的趋势是把 skill 做成一个可移植的能力包。你想啊，一个标准的技能文件夹里得装些什么？ 首先是 skill 点 md， 这是给模型看的说明书，定义了触发词和输入输出格式。接着是 reference 知识库，也就是这个技能专属的领域文档，方便模型随时查阅 sop。 最后才是 execute 执行脚本为什么要费劲做这种封装？因为这样它就解偶了呀。你写好一个财务分析技能， 不管挂在哪个模型下面，他都能插拔即用，这种工程思想才是面试官最想听到的。接着往下看，这层黄色的模块非常关键，也是大家容易忽略的执行与安全层。大家想过没有，如果 agent 被坏人诱导了，也就是发生了 prompt 注入， 他去执行了一个山库或者转账的脚本怎么办？所以我们的执行层必须要有容器化沙盒，所有的脚本都得关在刀口容器里跑， 严格限制他的网络和文件访问权限。而且对于像发邮件、改数据库这种有物理副作用的操作，一定要加一个人类再还审批，哪怕模型再聪明。最后按确认键的必须是人，这不仅是技术，更是生产环境的底线。讲完架构，咱们再看看落地时的三个深水区难题， 大家看下面这三个并列的筐。第一个坑是偷啃爆炸，技能挂多了，模型就容易间歇性失忆。咱们的方案叫动态览加载系统出场的时候只给模型看一眼技能名称和简介，等真正匹配到意图了，再实时把那个详细的点 md 说明书拉进工作记忆区。第二个坑 是多工具串联时的参数错位，比如 a 工具突出的数据， b 工具接不住，这时候咱们得用分层调度设一个专门的 planner 负责拆解任务， 再加上严格的赛马教验，一旦出错立刻驱动模型，基于日制自我纠正。第三个坑是环境依赖冲突，不同的技能可能需要不同的拍摄环境，所以我们要搞运行式隔离，给高复杂的技能配独立的运行容器，互不干扰。最后咱们来复盘一下，如果要在面试里拿满分， 你得从三个维度去总结，第一是定义高度强调它是一个标准化的知识与能力封装包。第二是工程落地， 聊聊你怎么用懒加载和分层代理去处理复杂的 token 管理。第三是安全底线，也就是沙盒隔离和人类在还把这三点讲透了，面试官一定会觉得，嘿，这哥们是真的在写代码搞落地，不是在纸上谈兵。好，关于 agent skill 的 架构，我们就先拆解到这里。

很多人做 skill 还停留在给模型补资料这一步，但 google 这篇文章真正狠的地方是，他已经开始教你怎么让 skill 反过来管模型了。 上一篇我们讲了前两个最容易理解的模式，一个是 tool rapper， 把某个领域知识打包成即时专家。 一个是 generator， 用模板和风格规则稳定产出结构化结果。但从第三个模式开始，事情就变了， google 其实在把 skill 从知识补丁往行为控制器推进。第三个模式叫 reviewer， 它的核心不是写，而是审。 作者把它定义得非常清楚，把检查什么和怎么检查拆开，检查标准放在 references 里的 checklists 里， 审查流程写在指令里。这样一来，同样一个 skill 结构，你换一份 checklist， 它的审查目标就完全变了。今天可以审 python 代码，明天可以审安全问题，后天甚至可以审文案。是不是符合品牌风格， 这个思路非常重要，因为它说明 skill 不是 靠模型自己凭感觉点评，而是让模型按外部标准来做判断。文章里甚至举了例子，一个带三处刻意 bug 的 函数 reviewer 模式，能把命名问题、可变默认参数和 bare accept 全抓出来，而且还能按严重程度分级。这背后的重点不是模型聪明，而是 checklist 的 真正接管了行为。第四个模式叫 inversion， 翻过来理解就是先问再做。这其实是在专门打模型最常见的一种失败方式，明明信息不够，他却急着开始设计，开始输出，开始拍脑袋补设定。所以这个模式会强制模型按阶段提问。 比如先问问题是什么，用户是谁，规模多大？然后再问部署环境、技术站预算合规要求，最后等这些都答完了，才允许他进入产出阶段。 作者甚至直接在指令里加了很重的一句，在所有阶段完成之前，不要开始构建或设计。 你会发现，这已经不是在教模型知识了，而是在压他的行为边界，防止他跳步骤。对于需求梳理、故障排查、配置向导这类任务，这种模式特别值钱，因为它能显著减少模型自己脑补一堆前提的问题。第五个模式叫 pie plan， 这也是最重的一种， 它不是简单的补知识，也不是简单的先问问题，而是定义一条必须按顺序走的工作流，每一步没过，下一步不能开始。作者给的例子是，文档生成流水线，先解析代码，列出公开 a p i， 问用户，这是不是你要文档化的全部内容，然后再生成 docstring， 并且要用户确认， 确认通过后才进入文档拼装，最后再按质量 check list， 回头做一次完整检查。这里最关键的不是步骤多，而是 gate， 也就是关卡。比如用户没确认就不能进入下一步，某一步失败就不能继续往后跑。 google 明确在强调，很多 agent 一 旦没有这种 get， 就 会一路冲到底，最后给你一个看似完整，但中间跳过了验证的结果。到这里，这三个模式其实已经把 skill 的 边界往前推得很明显了。 reviewer 在 做标准化评估， inversion 在 做输入控制， pieplan 在 做流程控制。 换句话说， skill 不 再只是让模型知道什么，而是开始规定它应该按什么顺序问，按什么标准查，按什么观察走 这种变化很关键，因为它说明 skill 正在从提示工程的附件变成 agent 行为工程的一部分。文章后面还专门说了一点，五个模式不是互斥的，而是可以组合一个 pipeline， 里面可以欠 reviewer 一个 generator， 前面可以先走 inversion 采集需求。 也就是说，真正成熟的 skill 很 可能不是单一模式，而是多个结构组合在一起，最终把一个模糊任务拆成可控的行为列。 所以第二集最该记住的不是这三个英文名字，而是一个更大的判断。 google 这篇文章真正想推进的，已经不是让 skill 变多，而是让 skill 开始管理模型的行动方式。 谁能做到这一点，谁的 agent 才会从会回答变成会按规矩干活。下一集我讲最后一层，也是最容易被忽略的一层。 google 其实不只是在讲五种写法，它背后真正想推动的是一个跨工具、可附用、能流通的 skill 生态。如果你觉得模式讲到这里已经差不多了，那最后一集最值得看，因为真正大的变化可能根本不在这五个模式本身，而在它们会把整个 agent 生态推到哪里。

如果你正在用 open call， 你 现在最该安装的 skill 可能不是让它更强的 skill， 而是一个先帮你保命的 skill。 为什么呢？因为现在 open call 最大的安全风险之一已经不是模型本身了，而是 skills。 你 可以把 skills 理解成 agent 的 up， 装对了，能力暴涨。装错了你的文件，你的浏览器，你的登录状态，甚至你的记忆文件，都可能被一起带走。这不是危言耸听，官方已经公开下架过一期恶意 skill， 甚至有账号一次性传了三百一十四个 skill， 官方后来一查，全是刻意的，一个干净的都没有。这些 skill 最常见的套路是什么？ 表面看着特别正常，什么加密分析、金融追踪、自动更新、桌面控制的名字都很像正经工具。但装上以后，它会让你的 agent 去陌生地址下载东西，然后直接在你电脑上执行。听着是不是很耳熟？ 这跟很多年前电网中毒的逻辑本质上没区别。我建议所有用 opencloud 的 朋友先装一个 skill， 叫 skill vetcher。 这东西不是帮你提效的，它是帮你在装任何 skill 之前 先审一遍。说白了，它就像 agent 时代的杀毒软件，它会先看来源谁写的，有没有人用过？是不是官方站在看代码？有没有偷偷联网？有没有读取 s s h a w s 浏览器？ ok， 最后再看权限，一个天气 skill 凭什么读你的服务器？密要很多。 skill 不是 一眼看上去就恶意，真正危险的是它，用它可能是正当的， 但权限大得离谱。这就是为什么下载量大不等于安全， star 多也不等于无害，页面做的像官方更不等于它真是官方的。以后所有从网上装的新 skill， 我 建议你都先做一件事，先审查 再安装。别让 a 阵时代的你还是十几年前下一步的下一步的装软件心态，那个时代最多是电脑卡一点，现在不一样， 现在你的 agent 能读文件，能联网，能操作你的电脑能力越大，你可能付出的代价也越大。 agent 可以 大胆用，但 still 不 能随便装。我是 max， 带你探索 ai 世界。