skills如何对外调用

今天皇叔做了一个 skills 啊，我觉得 nba 真的 肯定死了。来，我们先来看一看这个 skills 是 干嘛的，以及为什么皇叔觉得他完全替代了 nba。 我 们来看这个 ai 生成的他选定报告啊，他总共抓了一百一十八篇的文章，然后呢，从里面根据热度分析出了 top 十的热门文章内容。 那这些文章内容呢，其实就意味着说当下这篇文章的内容质量、热度，包括用户的认可度都是非常高的， 也就是给我们提供了一些选择题的参考建议。那在他的背后呢，其实是这个多维表格，他把一百一十八篇所有文章内容的标题链接和所有的数据都抓了下来， 然后他是通过订阅逻辑，把这三十七个黄书关注的公众号全部对应的内容抓取。 ok， 那 这个 skills 牛就牛呗，为什么你说它要替代 n 八呢？因为这个 skills 呢，其实它是完全模仿之前饼干哥哥做的，用 n 八加菲舒做一个 ai 公众号自动化小题的 a 卷工作流， 你看啊，完全一模一样，它是给了一个小题策略的分析报告，然后，对呢，它也是这么一个流程，以及说做了一个还挺复杂的 n 八 n 工作流。 那这个工作流呢？皇叔之前薅着饼干哥哥给我好好的讲了大半天，才把整个工作流打出来，那现在我用 skills 非常快的用一个小时就完全复刻出来了，你说夸不夸张？ 来，我们来仔细看一下这个 skills 它到底做了什么？它总共分为六个模块，订阅管理、自动采集、数据存储、数据分析啊，包括我自己家的 skills 潜力评估，以及最后的报告生成。 然后呢，你只要运行这个 sql 呢，它先会去读取整个定位列表，就是这张表，你总共关注的哪一些公众号？接着第二步呢，去便利这里面的每一个公众号，使用一个 api 来读取这公众号里面的所有的最新文章，它会做一个驱虫的处理。 第三步呢，会去处理每一篇新文章，会去拿它的正本，然后包括打标签或去对应的数据。 然后第四个呢，哎，把它批量的写入到飞书存进去啊。第五步呢，输出最后的采集报告， 那整个这个 skills 啊，包括它的工作流啊，其实非常有价值。为什么呢？因为皇书现在不断的要找什么样的 skills， 是 做出来之后大家觉得好用享用的，所以呢，我把它整个公众号的订阅的机制就非常快的加了一个。什么呢？ 加了一个转为 skills 的 可能性，对于每一个可能性进行推荐，星级哎，所以你都可以看到，我能够很快的就知道说什么样的好内容是别人需要的，以及说它可以转为 skills。 所以 大家可以期待啊，黄书后面会持续的产出更多优质的好的， 大家喜欢的 skills， 如果你希望黄书产出更多高质量的 skills 的 话，请你一定要点赞收藏，关注，我是爱产品黄书，我们下期见。

tiktok 上最近出现了一个非常火的项目， agent skills for contest engineering， 发布不到一周就斩获了二点三 k stars。 为什么它能瞬间引爆社区？今天我们深入来聊聊这个项目。你可能有过这样的经历，用 ai 编程时，明明给了足够的上下文，可 ai 要么答非所问，要么被永长的历史信息绕晕。最近 github 上的一个项目或许能解决这个痛点。 这个叫用于上下文工程的智能体技能的项目，发布不到一周就拿下了二点三 k 星。为什么他能这么火？我们从二零二五年末的技术背景说起， 这些年大厂白皮书里反复提到上下文工程，但对每天敲代码的开发者来说，那些理论太飘了。 我们需要的不是什么是上下文的论文，而是能直接用到 cloud code 里的工具。这个项目恰恰填补了这个空白，它把灰色的上下文管理策略打包成十个即插即用的智能体技能，借助 cloud 的 自动加载和触发机制， 让 ai 终于能像资深工程师一样自己管理内存。这就是一套上下文工程的最佳实践工具库。怎么理解它的核心逻辑？项目把上下文拆解成五个部分， 系统指令、工具定义、查找文档、消息、历史和工具输出。其中工具输出是最拖后腿的。研究显示，原始工具返回结果往往占了上下文百分之八十以上的体积，就像你电脑开了太多网页导致卡顿。 ai 的 上下文也有注意力，预算 一旦超支，性能就会下降。项目提出的渐进式路由策略就是解决这个问题的关键。初始状态下，智能体只读取所有技能的名称和简短描述，就像你手机桌面只显示常用 app 图标。 当你输入 prompt 后，智能体会自动进行语义匹配，找到相关能力，再加载详细内容。这跟操作系统的液交换机制很像，确保模型始终处理最相关的高信号信息。 你可能听说过 ai 的 迷失在中间现象，当信息放在上下文中间位置时，召回准确率比两端低百分之十到百分之四十。 除了这个，长对话里还会出现上下文中毒、干扰、混淆、冲突等问题。比如你先问 ai 怎么写 python 爬虫，再问怎么优化 java 性能。旧的爬虫信息可能干扰 ai 对 java 问题的回答。项目里提到的压缩优化技术能帮我们解决这些问题。 比如观察掩码技术，读取原文后提取核心结论，把原文从上下文里替换成引用 id， 这样上下文体积能骤降百分之九十。就像你把厚厚的参考手册换成一张锁影卡，需要时再去查详情。还有铆钉、叠带、摘药技术， 维护结构化的状态快，包括绘画意图、状态清单、决策记录和下一步行动向，让 ai 始终记得对话的核心目标。在多智能体协助场景里，上下文隔离很重要。比如一个项目分三个智能体， 写前端的，写后端的，做测试的。如果写前端的智能体看到后端的代码细节，可能反而会影响它的工作效率。 项目建议，每个子智能体只关心自己的任务，拥有专用工具，减少后选工具数量，实现故障阻断。 就像工厂里的流水线，每个工位只做自己的事，互不干扰。记忆系统也是上下文工程的重要部分。传统的向量检索有个时态盲区，它能找到相关的知识，但不知道这些知识的时间顺序。比如， ai 可能会把二零二三年的旧技术和二零二五年的新技术混在一起。 项目里提到的时态知识图谱就是给知识加上时间戳，让 ai 能区分旧方法和新进展。在工具设计方面，项目提出了一个反直觉的建议， 不要为每个细小功能写一个工具，而是把高度藕合的步骤合并。比如，你要做读取文件加分析代码加生成报告，与其写三个工具，不如合并成一个，这样能减少工具调用次数，提升效率。 项目还建立了完整的评估体系。智能体性能的百分之九十五变异由三个因素决定， token 使用量占百分之八十，工具调用次数占百分之十，模型本身选择占百分之五。这意味着优化上下文比换模型更能提升性能。 最后，项目给出了从 demo 到生产环境的五阶段流水线方法论。第一阶段，先用人肉方式跑通流程，再写代码。第二阶段，利用文件系统作为状态机，管理任务进度。这跟软件开发的最小可行产品思路类似，先验证流程可行，再投入开发。 通过这个项目，我们能看到，智能体开发已经进入了系统工程时代。以前我们可能只关注模型本身，现在发现，上下文工程才是构建确定性系统的关键。就像造房子，模型是地基，上下文工程就是框架， 没有好的框架，再好的地基也建不起高楼。这个项目的意义在于，它把抽象的上下文工程理论变成了开发者能直接用的工具，让更多人能用上高质量的智能体。说到这里，你可能会想， 以后 ai 会不会自己变得越来越会管理自己？我们会不会不再需要花太多时间调整 prompt？ 这些问题或许会在未来的技术发展中找到答案。好了，今天的内容就聊到这里了，如果你有什么想法，欢迎在评论区交流，我们下期再见。

hello， 大家好，今天我们来深度分析下 cloud skills 的 原理。你可能在各类 ai 工具里见过插件工具调用这类功能，但 cloud 的 skills 和它们不一样，它没有用代码直接外挂功能， 而是用了一种特别聪明的方式，在需要时给大模型临时装脑子。这到底是怎么回事？ 为什么说它是基于第一性原理的设计？今天我们就一步步拆开来看。首先得明确 cloud 的 skills 本质是什么。 传统的 ai 工具调用，比如你让 gpt 调用计算器，它是真的给外部计算器发了个请求，计算器算完结果再传回来，中间有个外部代码运行的环节。 但 cloud 的 skills 不 一样，它其实是一份 mockton 格式的专家手册，当你调用某个 skill， 比如处理 pdf 的 功能，系统不会去运行手册里的任何代码， 而是把这本手册里的所有指令、工作流甚至专业知识 完整的塞进 cloud 当前的对话。上下文理。就像你问一个普通人数学题，他不会，但你瞬间给他植入了一套高中数学的完整知识点和解析流程，他立刻就能像数学老师一样给你解析 skill。 不 直接做事， 他让 cloud 的 自己变专家去做事。接下来是架构层面，为什么叫圆工具与纯大模型推理？ 你想，如果把所有 skill 的 指令都预先塞进 cloud 的 提示词里，那上下文窗口早就爆了。因为每个 skill 的 手册可能有几千字，所以 cloud 的 设计很巧妙，它只有一个叫 scale 的 圆工具， 相当于一个技能目录 glot， 平时只能看到这个目录里所有 skill 的 名称和一句话简介，比如 pdf 处理，帮你分析提取 pdf 内容。 当你提需求时，比如帮我分析这个 pdf 里的核心观点， glot 完全靠自己的语言理解能力，从目录里匹配到最适合的技能， 没有任何硬编码的规则，也没有正则表达式分类器这类中间环节。整个决策过程就是大模型自身的前向传播运算。这种设计的好处是完全靠大模型的理解能力，不需要额外的工程逻辑，扩展性极强。 然后是最核心的机制，双重上下文注入。这里解决了两个矛盾，一是技能手册那么长，直接发给用户会刷屏，体验很差。二是手册必须让 closed 完整看到才能生效。 所以系统用了双通道消息显性通道给用户看。比如正在加载 pdf 处理技能，让你知道进度。隐性通道是给 cloud 的， 带着 excel 出标记，里面是 pdf 处理 skill 的 完整手册， 可能几千字的工作流和专业知识，这些内容会进入 cloud 的 短期记忆，但在你能看到的界面上完全隐藏。 除了文字注入 scale 还能动态改环境，比如临时给 clue 开权限，让它能调用 bash 里的 pdf 处理工具。或者某些 skill 能直接切换更适合的模型版本， 比如从 cloud 三 haikou 切到 opus， 这些都不需要你反复确认，系统会自动处理。那整个运作流程是什么样的？用一个场景来类比，你说帮我分析这份产品说明书的 pdf。 第一步，大模型，看到员工距离的 pdf 技能简介，判断这个需求匹配决定调用。 第二步，系统接入读取 pdf skill 的 完整 mockdown 文件。第三步，系统给你发一条显性消息，正在加载 pdf 处理技能，同时给大模型发一条隐藏的隐性消息。现在你是 pdf 处理专家， 你的工作流是，一、先调用工具把 pdf 转成文本。二、提取结构、目录章节。三、梳理核心观点。四、用简洁语言总结。 第四步，系统临时给大模型开权限，允许调用 pdf 处理工具。第五步，大模型带着这些新注入的记忆核心权限，开始调用工具处理 pdf， 然后给你输出结果。 整个过程就像动态加载领域，大脑，原本只会聊天的 cloud， 瞬间变成了 pdf 分 析专家。说到这里，你可能会问， 这和其他 ai 的 工具调用有什么本质区别？我们拿 gpt 的 tocolin 来对比， gpt 是 外接工具，大模型只是个调度员，告诉外部工具你去算这个，你去查那个，结果回来再整理。 而 cloud 的 skill 是 内化知识，大模型自己变成了专家，工具只是它可用的手脚。举个更形象的例子，假设你想让 ai 帮你修电脑， gbt 的 方式是，你说电脑开不了机。 gbt 先给你列几个可能的原因，然后告诉你，你去查电源有没有插好，你去拆开机箱，看看内存条松没松，它是在给你指步骤， 但自己不会动手，也没有真正的修电脑知识。而 closed 的 skill 方式是，你说电脑开不了机， 系统给他植入了完整的电脑维修知识库和操作流程，他瞬间变成电脑维修工程师，不仅能给你指步骤，还能告诉你内存调松的话，会出现什么报错，怎么检测电源是不是坏了。 他自己懂，维修工具只是辅助他操作的手段。这种设计的优势在哪？首先是扩展性强，因为每个 skill 都是独立的 macd 文件，要加新功能， 只需要写一本新的专家手册，不需要改大模型的代码或者重新训练，也不会影响其他功能。其次是一致性，所有的决策和处理都在大模型内部完成，不会出现调度逻辑和模型理解脱节的问题。 当然，它也有局限性，客观冷静。比如如果 scale 的 手册写得不好，大模型的处理效果也会差。而且因为要把手册塞进上下文， 所以 dango skill 大 小还是受限于上下文窗口的长度。那这种设计为什么能成立？核心是利用了大模型的上下文学习能力，就是你给大模型一段视力或者指令，它不用专门训练，就能立刻按照这个要求去做。 ecropic cloud 的 开发公司在二零二三年就公开过一篇关于上下文学习的论文，里面提到 cloud 三系列的上下文窗口最长可以到两百万 toc， 相当于一百五十万字的文本，这给 skill 的 设计提供了基础，足够大的窗口能装下完整的专家手册。 最后总结一下 closed 智能体技能的第一性原理就是基于大模型的上下文学习能力，用圆工具和双重上下文注入的方式，把静态的专家手册转化为大模型的动态零食 记忆，让大模型自己变专家去解决问题，而不是依赖外部代码运行。它没有创造新的程序执行方式，而是极其巧妙地利用了现有大模型的能力，实现了功能的无限扩展和按需加载。 说到这里，你可能会思考未来的 ai 工具会不会越来越多的用这种内化知识的方式，而不是外接工具。 毕竟外界工具总免不了沟通成本，而内化知识能让 ai 更像一个全才，但同时这种方式对大模型的上下文能力和理解能力要求更高，不是所有大模型都能做到。 这可能也是 ai 智能体发展的一个方向，从工具集合变成可动态升级的专家大脑。 好了，今天的内容就聊到这里，你觉得未来的 ai 会更倾向于外接工具还是内化知识？欢迎在评论区留下你的看法，我们下期再见。

hello， 大家好，欢迎收听我们的播客。然后今天我们要聊的呢，是这个 cloud skills 啊，我们会从这个 agent 和 mcp 现在面临的一些难题开始说起来，聊一聊这个 cloud skills 背后的一些核心的想法， 以及它到底解决了哪些实际的问题。最后呢，我们也会来看一看这个东西未来的发展前景怎么样，包括对于 开发者和平台方来讲有哪些机会。嗯，好，那我们就开始今天的内容吧。我们先来聊第一大块啊，就是这个 agent 和 m c p 现在面临的难题。好吧，就是想请你聊一聊，你觉得现在 用 m c p 来构建这个 agent 的 系统最大的挑战是什么？就是 m c p， 它确实是让模型能够去用很多外部的工具嘛，但是它有一个问题，就是它是把所有的工具的这个 skin 啊，都一股脑的塞到 这个模型的上下文里面，就光这一百个工具的定义可能就占了上万的 token， 那 这个模型它能处理的 token 是 有限的嘛？那你这个对话稍微长一点，或者说这个任务稍微复杂一点，它就直接爆了，就 o m 了，然后你这个整个系统就崩溃了。这确实听起来挺让人头疼的，更麻烦的是，这个 模型的这个推理的准确率也会受到影响，就是你这个工具调用的炼炉一旦长了之后，他的这个准确率就会像多米诺骨牌一样就塌下来了，然后再加上你这个维护各个 solo 之间的这个同步啊，也很复杂，又容易出错，成本又很高又很慢。 安全方面的话，你这个权限管理也很难做，就各种问题就会让你觉得非常的抓狂。就是说在实际应用当中，这个普通的这种 agent， 他 为什么 很难真正的成为一个各个领域的行家里手呢？因为他虽然很擅长就说这种通用的这种任务，但是一旦你下放到具体的业务场景里面，他就会因为缺少这种专业的知识和这种规范， 他就会表现的非常的不稳定。那你要去补全这些知识的话，你靠那种传统的方式去补全的话，就会让你的这个上下文变得臃肿，难以管理，然后各个不同的团队之间也没有办法去共享这些能力， 你每一次都要去重新造轮子，你也没有办法去统一的维护，统一的去升级。那就是说到底这个 cloud skills 它的最核心的设计思路是什么？就它是把这种专业的能力拆分成了一个个独立的技能包，那这个技能包里面它是用一种 标准化的这种文件夹和 markdown 的 结构来组织的啊，那这个就非常的方便管理和版本控制，然后大家也可以去共享，听下来确实很有条理。对，然后它的另外一个好处就是说它是一种 渐进式的加载，就是它只会在需要的时候才会把这个技能的具体的内容拉进来啊，同时它可以配合 m c p 和此 agent 一 起使用，所以它的这个灵活性和可维护性都非常的高啊，同时它也降低了这种构建这种复杂的 agent 系统的门槛。 对，那咱们来进入第二部分啊，就是今天要聊的是这个 cloud skills 到底是怎么解决这个实际当中的一些 ai 应用的问题，比如说它怎么能够让这个 ai 做事情的时候更省 token， 然后还能够提升效率？ 就是 cloud skills， 它是用了一种渐进式批录的方式啊，来管理这个上下文，就是它一开始的时候只会加载这个技能的一个大概的描述，那这个描述可能就占 很少的 token。 然后只有当你真的要用到这个技能的时候，他才会把这个具体的指令啊以及相关的一些资源再拉进来，所以他这种方式就会比你传统的那种把所有的东西都一股脑的塞到这个模型里面要省很多 token， 听起来就非常的高效，而且灵活。没错没错，是的，是的，是的。 然后他们官方做了一个测试，就是在这种比较复杂的多步骤的任务下面啊，他们用了 skills 之后，比用传统的 m c p 节省了差不多一半的 token， 那 同时呢，这个 ai 回复的速度也提升了百分之三十五，同时呢他第一次回答的准确率也提升了百分之四十， 那这就意味着你可以处理更多的请求，同时你也可以降低你的成本。嗯，你觉得就是这个 cloud skills 到底是怎么让这个 ai 能够做到输出稳定，然后又可以附用呢？ 就是它其实把这些东西都变成了一种可以保存，可以随时调出来的一种能力啊哈，就你可以把你公司的一些标准的流程或者说一些规范 全部都写进这个技能里面。嗯，那他每次在处理这种任务的时候，他就会自动按照这个模板来进行处理，那他就不会说出现那种一会格式对，一会格式错，或者说一会这个数据对，一会这个数据错这种情况。哦， 这样的话就可以保证每次的结果都是靠谱的。对，没错，而且就是这个技能他还可以跨平台使用啊，就是你可以在不同的项目里面或者不同的团队里面共享这个技能。 然后呢？呃，它的这个升级啊，和这个权限管理也都很方便，就可以大大降低这个维护的成本，也可以让大家都按照一个统一的标准来进行写作。嗯，那你觉得就是这个 cloud skills 和这个 m c p 它们俩之间是一个什么样的关系？ 我觉得就是 m c p 它更像是一个桥梁啊，就是它让 ai 可以 去连接外部的一些服务啊，然后去操作一些真实的资源。那这个 cloud skills 呢？它就更像是一本操作手册， 就他告诉你这个东西一步步应该怎么干啊？原来是分工这么明确啊。对，就是这两者其实配合起来特别好，就比如说你要自动生成一个报表，那可能 m c p 就 负责把这个数据从数据库里面拉出来， 然后这个 skills 呢，就负责按照你的这个公司的标准，把这个报表的格式全部都给你编排好，就一个是干活的，一个是管流程的，就他们俩配合起来，就会让这个 ai 的 这个应用啊变得又灵活又可控。 咱们来聊第三个部分，就是这个 cloud skills 未来的前景和机会。嗯啊，第一个问题，你觉得 cloud skills 会给整个 ai 的 发展带来什么样的变化？就我觉得这个 cloud skills， 它其实是把这个 ai 从一个 什么都懂一点的这种助手，变成了一个真正的可以解决各行各业的实际问题的这样的一个专家。 就它是一个非常重要的一个让 ai 往工程化、往实用化转型的这样的一个转折点，所以说它是一个推动 ai 落地的一个关键的动力。没错没错，对，因为它是一个呃 offropic， 它是一个开放了这个标准和参考实现的这样的一个东西，所以它是可以让 不同的平台、不同的开发者都能够来共享扩展这个 ai 的 能力。所以我觉得未来的话这个技能的生态会越来越丰富，然后这个 ai 也会变得越来越 专业，越来越灵活，就会成为一个 ai 领域的一个新的基础设施。对，那如果说咱们现在站在一个开发者的角度，你觉得这个 cloud skills 带来的最直接的机会是什么？我觉得最大的机会就是大家可以用一个统一的格式去封装 ai 的 能力，然后这个技能是可以一次开发到处运行的， 你就可以非常高效的去构建各种智能应用，而不用去重复的造轮子。对，那确实这个对于团队合作呀，或者说这个能力共享啊，确实是太方便了。没错没错，而且就是你有了这个规范之后，你就可以 不光是在自己的项目里面去重用这些技能，甚至你可以分享到社区，大家都可以用。然后你可以打造自己的技能市场，你可以去做针对不同的场景做一些深度的定制等等吧，就是真正的可以形成一个 ai 开发的一个新的生态。 那如果我们现在把视角再切到平台方，你觉得 cloud skills 会给平台方带来哪些新的机会？就这个技能它是一个开放的标准，所以平台方只要去兼容它，就可以让自己的这个产品 无缝的对接上整个这个 ai 的 生态。然后你也可以吸引到更多的开发者和用户加入到你的平台上面，你可以打造自己的技能商店，你可以去做一些技能的推荐， 你可以去做一些技能的自动的适配等等的一些新的玩法，你也可以去推动整个行业的创新和标准化，就可以在这个新的赛道上面去抢占一个比较有利的位置。 哎，今天咱们聊了这么多关于 cloud skills， 从它的设计理念到它的实际应用，以及它未来可能会带来的一些变化，感觉好像真的是这个东西有可能让 ai 真正的走向实用， 走向标准化。对，所以可能真的会彻底的改变这个游戏规则。行，那我们这期节目就到这里了，然后感谢大家的收听，咱们下期再见，拜拜。

大家好，我是小木头。在最近的一些分享和讨论中，许多朋友提到了关于 close skills 以及 m c p， 好 奇它们的区别是什么，那么它们之间的关系又是什么？ 本期视频呢，我们就来做一期相对比较详细的介绍，希望呢能够帮助大家理解它们分别是什么，以及如何配合使用。 在十月， cloud 发布了 agent skills， 当时呢，我也做了两期视频，分别介绍了什么是 agent skills 以及如何开发自己的 skills。 感兴趣的朋友可以在我的频道搜索 cloud skills， 回看这两期的视频。 随着这两个月的发展， cloud skills 越来越受到关注，有许多朋友呢，也开始拿它与 m c p 协议相对比，好奇它们之间的差异是什么，那它们之间又有没有什么关系？那今天呢，我们就来介绍一下。 在我个人理解 skills 与 mcp， 它是 ai 能力扩展的两种哲学来做一个简单的对比。 mcp 就 像给 cloud 装上了 usb 接口，让它能够连接外部世界。在过去的视频分享中，我们也介绍了许许多多关于 mcp 方面的内容， m c p 使得大模型能够连接到外部的数据服务，而 skills 就 像是 cloud 一 本操作手册，教他如何完成特定的任务。 举一个更加生动的类比，在五金店的场景中，如果你要修理坏掉的橱柜，店里有你需要的一切，比如木胶夹子、替换铰链等等，但知道买什么，怎么用是另一个问题。 因此 m c p 就 好比货架上的工具，而 skills 则是店员所提供的专业知识， 工具再多不会用也白搭，对吧？而专业知识再丰富，没有工具也干不了活， 看起来两者是缺一不可的。那什么是 mcp 呢？感兴趣的朋友可以在我的频道搜索 mcp， 从概念到开发实战有非常详细的介绍。 mcp 解决了一个核心问题，如何让 ai 与外部的系统对话。 在 m c p 出现之前，每接入一个新的工具或数据源，开发者都是要编写专门的适配代码的，这也被成为了 n 乘 m 问题。 n 个 ai 模型要对接 m 个工具需要多少种集成方式呢？ n 乘 m m c p 则提供了统一的翻译层。 我们来看看它的客户端服务端架构。 mcp 客户端通过约定的协议访问 mcp 服务器。服务器提供了一系列的工具服务，它能够访问外部系统，比如像数据库、 api 或文件系统。 mcp 提供了一系列的核心功能，其中约定了资源工具、提示词、模板等等。 或许大家最常用最熟悉的应该就是工具了。 mcp 工具提供给了 ai 应用或大模型，比如发送邮件、创建合并请求、执行、数据库查询等等的能力。下面呢，就定义了一个非常简单的 mcp 服务器， 通过 fast mcp sdk， 我 们可以很轻松地创建一个 mcp 服务器。在这个例子当中呢，创建了两个工具，第一个工具做数字相加，第二个工具呢，做个性化的问候。 这个服务器呢，运行在了 streamable h e p 协议之上，那这就是一个非常典型的简单的 mcp 服务器了。 那现在大家对 m c p 以及 m c p 服务器 m c p 工具有了一个相对比较具象的认识， m c p 在 发布的一年内已经成为了事实上的行业标准。 二零二五年三月， open ai 宣布采纳 m c p。 四月， google deepmind 也确认 gemini 支持 m c p。 五月， microsoft 也宣布 windows 十一会支持 m c p。 最近二零二五年十二月， angelopik 将 mcp 捐赠给了 linux 基金会下的 agenec ai foundation。 聊完了 mcp， 我 们来看看什么是 skills。 同样的感兴趣的朋友，请在我的频道搜索 close skills， 来了解什么是 skills 以及如何开发自己的 skills。 我们再一次简单地介绍一下， skills 是 ospec 在 十月推出的能力扩展机制，它要解决的问题是如何教会 clot 以特定的方式工作。与 mcp 的 连接外部系统不同， skills 专注的是传授知识和流程。我们来看看一个典型的 skills， 它的结构是什么？它的核心就是一个 markdown 文件， skill 到 md， 加上一些可选的辅助脚本。在许多的 skills 打包文件中，大家看到的或许就是一系列的 md 文档。那么在下面这个文件夹结构中，大家能看到 skill 到 md， 这是核心的指令文件。这其中可以有一些参考资料，比如 reference 底下的 patterns 到 md， 可以 提供视例，比如 examples 底下的 demo 到 s h， 还可以提供辅助的脚本，比如 scripts 目录下的 validate s h。 这就是一个 skills 的 文件架构。那大家应该有一个具象的认识了，一个典型的 skills， 我 们可以认为就是一个文件夹，这个文件夹当中包含了一系列的文件，其中的核心文件是 skill 的 md， 来了解一下它的工作原理。 skills 采用了渐进式路由或渐进式加载的策略 load。 首先扫描所有的 skill 的 原数据， 它并不会将所有 skill 一 次性全部加载，再根据用户的请求来判断需要使用哪个 skill 或与哪个 skill 相关，这时才加载相关 skill 的 完整内容。这种设计就避免了上下文窗口被大量无关内容占满。 我们来看一个代码审查技能的 skill 的 md 文件，在这个文件中， 以 mockdown 的 格式编写了代码审查时需要遵循的步骤。第一呢，安全性检查。第二呢，代码质量。第三，输出格式。 那这个 skills 存储在哪里呢？有两种方式，对于个人的 skills， 可以 存储在主目录下的 dot cloud slash skills。 如果是项目级别的 skills 或级别呢，就放在 dot cloud slash skills。 那 现在我们对 skills 和 m c p 做一番对比， 如果你在解释怎么做，那就是 skill。 如果你需要 cloud 访问某物，那是 m c p。 我 们用更通俗的话来讲就是 m c p 让 cloud 能够连接到工具，而 skills 教 cloud 如何使用工具。 m c p 服务器也可能包含工具使用的提示和常见任务的提示词，这些呢，应该保持通用。那么在职责边界的划分上该怎么做，如何避免冲突呢？这里有一些经验法则，对于 m c p 指令， 它应该约定如何正确使用服务器和工具。那么对于 skill 来讲呢？它应该约定如何在特定的流程中使用它们，比如先查哪些记录，如何交叉引用？如何格式化输出？ 关于 skills 以及 mcp， 一个常见的问题是， skill 是 否负责安装和配置 mcp 工具？答案是，不负责。 skill 只是引用工具名，它讲是 mcp 已经配置好。 我们以 notion 的 spectral implementation 这个 skill 为例，这个 skill 是 notion 提供的，它用来教 cloud 如何在 notion 当中做真正的工作。感兴趣的朋友呢，可以了解一下这个 skill 的 详情。 那我们回到介绍这里。在这个 skill 当中，它引用到了 notion search， notion fetch， notion crepe pages。 在这个 skill 的 驱动下， call 应用可能会用到其中的一些工具。那么这些工具呢，是需要咱们独立安装配置的。因此，从职责划分来看， skill 负责定义调用顺序和流程，规定输入的参数格式，规范输出格式， 并提供模板和最佳实践。而在 m c p 层面，负责服务器的安装。如果需要呢， a p， m e r 的 配置和认证的管理等等，还需要负责网络连接、权限设置， 服务器的运行和维护呢，也在 m c p 侧独立地完成。再做一次简单的类比。 skill 就 像一份菜谱，告诉你先放什么，后放什么，火候多大，但它不负责帮你买锅，装煤气灶。 而 mcp 呢，就像厨房设备，如果你需要，则自己购买安装调试。菜谱只是假设你已经有了这些设备。这种分离的好处在于， skills 能够保持清亮， 它只是一些 markdown 文档，便于进行分享和版本控制。而 mcp 呢，实现了高可附用性。一个 notion mcp 可以 被多个 skills 共同使用。 同时， mcp 的 升级并不会影响到 skill， 反之亦然。在介绍到 mcp， 介绍到 skills， 我 想大家对于他们的使用场景已经比较的清晰了。对于 mcp 使用场景在于，当我们需要访问数据库，需要调用外部 api， 需要操作文件系统， 或需要与第三方服务集成时，我们使用 mcp。 那 什么时候使用 skills？ 涉及到工具的多步骤的工作流，需要一致性的流程，或者想要捕获分享专业领域的专业知识，比如像研究方法论、代码审核标准，写作指南等等。 一个典型的应用场景是，即使团队的成员离职了，咱们也能够基于 skills 保留工作流，这就是制度的知识了，把只有老员工才知道的事变成可附用的指令。 接下来有一个官方的实战案例做分享，这是一个金融分析的案例，分析时，做公司分析时，需要从多个数据员拉取财务的指标，应用相同的估值方法，并按合规标准格式化输出。 这是重复的工作且易出错。我们会用到哪些组建呢？在 skill 层面，我们会尝试使用 comparable company analysis， 这是可比公司分析，咱们可以认为它是一种技能，一种方法。那 m c p 服务器会用到哪些呢？ 我想应该就是数据的查询，数据的计算等等。在这个案例中，典型的工作流程是 skill 来确定要查询哪些数据员，再通过 m c p 来连接拉取实施的财务数据。 基于拉取到的财务数据，基于 skill 完成任务的编排，他应该会应用到估值方法论，并且格式化输出。 在验证阶段，基于 skill 的 约定，根据合规要求进行校验。我们再来看一个在开发者应用场景中蛮典型的一个案例，在这里会引用到 context seven， 这个是 upstart 开发的一个 mcp 服务器，很好的解决了开发中的一个实际痛点。 大约模型的训练数据是会过时的。那编程库的文档呢？总是在不断更新的，那 contact seven 就 给到了 ai 接口或工具，能够实时地获取任意库的最新官方文档。 在这里，咱们列出了两个 m c p 工具，一个是 resolve library id， 一个是 get library docs， 分 别是将库名解析为 contact seven 的 id 以及获取指定库的最新文档。如果我们单独使用 m c p 呢？每次查文档，我们都需要手动地调用 resolve library id， 再记住这个 id， 再通过 id 调用 get library docs。 最后呢，自己整理输出的格式。 现在呢，我们可以创建一个配套的 skill。 在 这个 skill 的 原数据中，首先我们来指定可以使用的工具，这两个工具呢，也就是 contact seven 所提供的两个基本的工具了。 接下来在 square md 文档中约定查询的流程，当用户询问某个库子时候呢，首先使用 resolve library id 去解析到兼容的 id， 再用 id 呢获取文档，并将文档呢按照指定的格式呈现。 这个 skill 的 好处是，我们可以确保 cloud 在 涉及到开发工作时，总能够优先使用 contactseven mcp 工具来获取文档，从而使得文档的获取呢，尽可能的保证高质量。 日常使用 cursor 或 clock code 这类编程智能体进行开发的朋友呢，应该也会注意到，并不是每次对话中 dum 提及到某一个开发包时，它总是能够从 contact seven 来获取文档。有的时候呢，它会尝试使用搜索引擎或搜索工具， 那这就根据大家自己日常开发中的偏好或团队的开发模式来制定自己的 skill， 来看一个典型的工作流程吧。当用户提问 react hooks 怎么用， skill 会被激活。接下来呢，会使用 mcp 工具完成第一次的调用， 返回了 react 文档库对应的 id， 再根据 id 呢，去获得对应的文档 skill， 再去规范输出的格式。基于这个格式呢，得到结构化的文档内容展示。 好了，那这就是今天我们介绍的主要内容，我们来一句话的做一番总结。当解释怎么做时，使用 skill 需要访问某物，使用 mcp， 这也是刚才咱们介绍的 mcp 和 skills 代表了 ai 能力扩展的两种不同哲学。通过 mcp 来强调标准化和互操作性，使得 ai 呢能够与外部世界连接。而 skill 强调了内容的整理，知识的总结，将人类知识注入到 ai 的 管道， 告诉大模型，告诉 ai 应用究竟该怎么做。随着时间的推移，团队会积累出一系列相互关联的 skills 和 m c p 连接，使得 cloud 能够成为你们领域的专家。 好了，那今天的视频分享就到这里吧，如果大家对 cloud skills 以及 m c p 还有什么问题呢？欢迎在评论区讨论，那我们就下期视频分享，再见同学们，拜拜！

一天一个强大的工具第一百四十五期，今天要讲的是，这是 chrome 上超三百万人在用的网页翻译插件，支持超过一百种语言实时翻译，并且接入了 deepsea、 gemini 等主流大模型，翻译质量直接拉满。当我阅读一个英文网页时，点一下插件图标，整个网站秒变中文。最香的是双语对照模式，看外文资料的同时还能学单词华辞，翻译更是随点随意， 阅读效率直接翻倍。在线视频的翻译也不在话下，它能够实时形成双语字幕，比机翻流畅多了。贴心的是，它还能直接翻译 pdf、 doc 等多种格式的文档，例如我上传一个全英文文件，瞬间就能翻译成双语显示或纯英文的版本。 除此之外，它还有一个背包 doc 功能，把 pdf 拖进来，它会保留原文排版，自动识别表格和矢量图的文字，并进行精准翻译，不会出现乱码。关键是直接还原原文档的排版，改都不用改， 就和阅读中文文章一样顺畅。而且不止 chrome、 edge、 火狐这些主流浏览器能用，手机端也能无缝使用。这么全能的神器，有了它，翻译再也不是难题了。