如何在skill中实现A2A协议？

不知道大家有没有跟我一样好奇， sku 它底层是怎么实现的啊？我们今天就一起来研究一下，研究对象呢，就是这 cloud code。 首先呢，我自己之前尝试过抓包，但是呢， cloud code 用的这个 http 协议呢，它是双向验证的，所以呢，我们很难用中间人去抓他的包，所以后来我想了想，索性呢，我把它的这个网关地址改一下，因为它不是可以给它配置成 http 的， 然后我也试了一下火山，它就支持 http， 所以呢，把它配成 http 就 好抓了，然后接下来就好办了哈，我们为了抓包，先把代理设上这个八八，八八呢，就是抓包工具的端口，然后把抓包工具起来好，然后呢，我们把 cloud 起来， 可以打开，有请求了，我们把它先关一下，然后 mod， 我 把模型切换一下。 你好，随便说一个，你好好，大家看有请求了，好，我把这个请求的 jason 请求体抓出来，消息，消息内容我们不细看了哈，然后系统提示词， 然后兔子，这是 function 的 模块，大家看啊，我们一个一个看啊， text text output 背式 logo， 这不看啥呢？ grape 推出计划模式， read edit 行键 no book edit web fight， 这个不知道干啥。 to do right web search， 应该是联网搜索 q shell， 这应该是杀死一个 shell， 传一个 shell id ask you a question skill， 大家看，这有一个 skill， 后边 enter plan 进入一个计划模式，相当于倒数第二个 function 提供的名字叫 skill。 然后呢，我们把它描述漏出来看一下， 它现在是在字幕串里，不好看，我们把它输出出来。好，我把它复制出来啊， 翻一下，这是 cloud code 提供的一个名叫 skill 的 function 给大模型调用，然后它的描述是这样的，大家看啊， 我们就不细看了，这里面有一些，比如说这个，当某个技能相关时，你必须立即调用此工具作为第一个操作。然后就是一些重要的一些说明吧，主要是这打开从这开始 可用 skill 就 可用的技能。这是一个这马克当格式， excel 的， pdf 的， ppt 的， 然后 m， c， p， build 的， 都是我本机现有的一些 skill。 相当于它在传给大模型的这个请求里边，它构建 skill 的 这个 function 的 描述的时候，它就会把 skill 文件夹里的那些 skill 的 头里边的 description 描述拿出来，然后拼到这个可用的 skills 里边， 这样的话，下边那些东西他还没有拼进来，等我们再调用某一个的时候，比如 ppt， 那 他会把 ppt 详细的思路再二次的再传给他。所以现在看来，说白了， skill 它底层也是一个 function calling， 只是呢，它这个 function 名叫 skill， 然后描述做了一些动态的拼接，像这样。最后哈，我想再感叹一下，大家看，就是我在页面上只是说了一个你好，两个两个字，但是他底层发了这么多东西， 这还不包含回复，这都是需要消耗 token 的， 所以 token 对 我们来说是真的越来越重要了。而且大家别忘了， 随着对话轮数的增加，它这些历史的聊天记录必须带着，因为大模型是无状态的嘛，所以呢，随着我们对话的回合不断增加，它这个 token 的 消耗真的是指数级增长，所以未来 token 对 我们来说真的是越来越重要了。

过年好啊，我是破旺，继续统一起手势，用户输入年夜饭吃啥？前面十六集呢，我们都讲了 ai 的 各种能力，最后组装成了 a 字， 但问题来了，有些的任务他实在是太复杂了，一个 a 证根本就干不完，干不好，比如年份的准备，那其实可能需要呢，菜单规划的 a 证，采购的时间管理的、营养把关的。那如果这四个 a 证呢，是不同的团队做的，那你怎么让他们进行相互配合呢？ 而 a to a 就是 agent 和 agent 之间的一个能够相互发现分工，协助安全通信的那个协议。我们看完整的过程， 用户输入年夜饭吃啥，如果只有一个 agent， 他 得干所有的事，很累，而且也不一定能干的好，不专业。而用了 a to a 的 一个做法，那四个 agent 就 可以进行分工，协助 用户找到总的协调 a 阵的用户说啊，今天饭吃啥？而总协调的 a 阵的呢，他通过 a to a 协议发现了还有其他的 a 阵，比如说菜单规划的，采购的、时间管理的和营养把关的， 那总协调呢，就会把整个的一个任务去进行一个分配。那先让菜单规划工作啊，他推荐了八道菜， 这个时候呢，总协调再让这个营养把关的 a 针去做一个相关的把关，那比如说招商冠名，那叫去掉清蒸，清蒸鱼打回给菜单规划，那菜单规划接收到了，这样一点说啊，那就换成红烧鲫鱼吧。 然后呢，哎，总协调的 a 针呢？他又去调用整采购的 a 针啊，那采购 a 针呢，他又会去进行一个比价啊。最终呢，他选择了一个相对合适的进行一个下单， 到了最后啊，时间管理的一等，那就是啊，这个下单一共呢是十八点啊，十八点到达，那么就是十七点半要开始做一些前置的准备，那十九点上桌，那并且呢还要发短信的一个提醒， 那这里面的关键点呢，就是 agent 只做自己擅长的事情，通过 a to 协议相互说话，我需要什么，你能提供什么，就像一个专业的团队在协助。那一句话总结， a to 呢，就是让多个 agent 能够相互配合，像团队一样 啊，分工协助干活。那整个这个系列呢，就是从年夜饭吃上这一个问题，我们一共讲了十七个 ai 的 概念， ai 怎么看？关于偷看和埋汰， ai 怎么想？大模型的本质和思维链， ai 怎么输出，这是 ai 怎么干活？通过啊，工具调用和 m c p， 那 ai 怎么记忆？那有 part 词组词，多流程化上下文工程和 rock 这样的一个技术， 那 ai 怎么进化呢？有 agent， 多模态，工作流编排， skill a to a， 那 这就是 ai 能够从看懂问题到解决问题的完整能力体系。我是 pro， 这个系列完结，我们下期见，拜拜。

在企业 ai 的 世界里，咱们正面临一个挺有意思的悖论，我们花了大钱开发的 ai 智能体，一个比一个厉害，但他们却像一座座孤岛，自己玩自己的，没法真正的协同工作。那今天咱们就来聊聊，怎么才能打破这些壁垒，建立一个真正能协助的 ai 生态系统。 你没听错，你手底下那个最强的 ai 智能体，很有可能就是个孤岛，他自己一个人干活可能效率惊人，但你想想，一旦他需要跟另一个 ai 合作，或者说要连一个新的数据库，麻烦就来了，每一次连接就意味着一次又贵又耗时的硬制开发。 说实话，这种模式不光是效率低，它从根上就限制了 ai 的 真正潜力，对吧？那到底要怎么打破这些壁垒，释放 ai 的 协助力量呢？嗯，答案呢，就藏在这两把钥匙里， 它们就是两个正在兴起的开放协议，一个叫 a to a， 另一个叫 m c p。 你 要知道，这可不仅仅是技术升级那么简单，这更像是为所有的 ai 智能体提供了一套通用的语言和行为准则。 好，咱们先来看第一个 a to a 协议。你可以这么想啊，如果每个 ai 智能体都来自不同的国家，说着不同的方言，那 a to a 就是 它们的万能翻译机。 a to a 全称就是智能体到智能体协议， 它的核心使命说白了就一件事，建立一个开放的标准，让任何两个 ai 智能体，不管是宅开发的，用的什么技术，都能够顺畅地沟通谈判，然后一起把活干完。那 a to a 到底是怎么做到这一点的呢？它有几个特别聪明的设计。 首先啊，每个智能体都有一张标准化的数字名片，上面清清楚楚地写着我是谁，我能干啥？这样一来， ai 之间就能互相认识了。 其次呢，它用的都是咱们现在互联网上最基础的技术，比如 h t d p 和 jason， 这就意味着它能很自然地融入我们现有的系统，不用推倒重来。最后一点，它还特别灵活，不光能聊文字，图片、文件也都没问题，而且还能实时告诉你那些需要很长时间才能完成的任务，现在进行到哪一步了。 好，智能体之间怎么聊天，咱们搞明白了，但还有另一个关键问题，一个 ai 自己怎么跟它要用的各种工具和数据来对话呢？这就要看我们的第二部分了，也就是 m c p 协议要解决的问题。 这么说吧，如果 a to a 是 翻译机，那 m c p 就 更像是一个万能充电头，或者说通用适配器。 m c p 全称是模型上下文协议。它的目标很明确，就是要终结 ai 工具集成的这场噩梦。你想啊，它创建了一个标准化的中间层，这样一来， ai 智能体就能用同一种方式去访问文件、系统、数据库、代码库，所有这些东西，再也不用为每个新工具都单独开发一套一次性的接口了。 m c p 是 怎么实现这个标准化的呢？主要靠三个核心概念。第一个是工具，就是 ai 能执行的具体动作，比如说去数据库里搜一下。第二个是资源，就是 ai 能读取的数据，比如说某个文件。 最后一个是提示，这就像是预设好的模板，能帮 ai 更高效地去使用这些工具，你看，它的核心思想就是把底层的复杂性全都藏起来，让 ai 只需要跟 m c p 这个标准的中间人打交道就行了。 好，那咱们现在来快速总结一下这两个协议的核心区别。你看 a 二 a， 它关心的是 ai 智能体和 ai 智能体之间的横向沟通，它就是那个万能翻译机。 而 m c p 呢，它关心的是一个 ai 智能体和它的工具之间的横向连接，它就是那个通用适配器，一个是管团队协助的，另一个是给单个队员赋能的。这么说是不是就清楚多了？ 听到这，你可能在想，那 a two a 和 m c p 它俩是竞争关系吗？我到底该选哪一个？嘿，这恰恰是整个故事里最精彩的部分。答案是，根本不用选，它俩不是对手，而是天生一对。当它们俩联手的时候，一个真正的完整的 ai 生态系统才算真正诞生了。 就像这句话说的，后来我们发现，我们根本不是在竞争，我们是在互补。没错，这两个协议就是从两个完全不同的维度一起解决了构建协助 ai 生态这个大难题。咱们来看一个零售业的真实藏讲，你就全明白了。 第一步，公司里有个库存 ai， 他 通过 m c p 协议连上了内部的数据库和文件系统去查库存，这是对内。第二步，哎呀，他发现有款产品快卖光了，这时候他就需要跟外面联系了。于是他切换到了 a to a 协议，用自己的数字名片在网上一找，就联系上了供应商的 ai。 最后一步，这两个 ai 通过 a to a 协议开始对话谈判，然后自动下了一个采购单，整个过程完全自动化，不需要人来插手。 你看这个例子啊，就把俩的协调作用展示的淋漓尽致。所以你只要记住这个关键点就行了。 m c p 负责连接 ai 的 内部世界，也就是公司自己的数据和工具。而 a to a 呢，负责连接 ai 的 外部世界，也就是其他的 ai 智能体，不管它们在地球的哪个角落。 好，了解了这些之后，这对于我们制定未来的 ai 战略到底意味着什么呢？咱们的核心战略启示其实可以浓缩成一个数字二，这意味着什么呢？未来的企业 ai 成功的关键绝对不在于你能不能找到那个无所不能的超级 ai， 真正的关键在于你能不能建立一个基于开放标准，大家都能互相协助的生态系统。而 a two a 和 m c p 这两个协议，恰恰就是这个生态系统的基石。把它们俩都用起来，这才是通往一个灵活强大的未来 ai 战略的正道。 所以，最后我想留一个问题给你来思考，你现在正在打造的 ai 生态系统，到底是在铺设一条通往写作的康章大道呢？还是在不知不觉中又建起了一座座新的信息孤岛？像 a to a 和 m c p 这样的开放标准，就是我们打破壁垒，走向真正写作智能的那个起点。

救命！别再教你的 ai 写代码了！ google 已经开始教他们谈恋爱了。想象一下，你刚用一个垂直 ai agent 画出了一张神作，现在还想让他顺便帮你配出图案。这种画工具的组合，以前真的挺难搞的， 现在的 ai agent 就 像个偏科生，你想让画图的帮写稿的，那你得亲自上手，像拉电线一样费劲地去联通它们。 只要一处对不上，任务就卡死了。但 google 发布的这个 a 二 a 协议，给每个 ai 都做了一张标准名片，叫 agent 卡儿。 这张名片展示了每个 ai 到底能干啥，有哪些超能力。从此， ai 之间不再是陌生人。 他们互相看一眼名片，就知道谁能画画，谁能翻译。我想做什么，直接派个任务过去，他们私下交流细节，干完活把结果直接返回给我。 有了这种 ai 界的普通话，所有的智能题都接轨了。这不仅是沟通，更是生产力的全自动化爆发。你半夜睡觉的时候，你的 ai 助理可能正在网上的社交圈 跟成千上万个 a 阵疯狂联网搞定任务。如果你的 ai 能自动找全世界的帮手，你最想让他去撩个什么样的搭档？我是阿康，陪你一起看懂 ai 爆发的前夜，别忘了点赞关注哦！

想用 web coding 开发上线生产环境的复杂应用，一定离不开两项技术， scale 和 m c p。 今天这期视频我们就分几个部分讲清楚 agent scale。 我 们首先从 agent scale 的 概念出发，给大家讲明白它到底是个什么东西。 然后我会用一个实在案例给大家演示一下它的基本用法和 reference script 的 高级使用方法 及它的核心逻辑，三层加载机制是如何节省 token 的。 最后，我会从核心能力、部署方式以及可扩展性这几个方面深度对比 m c p 协议和原生 skill， 帮你看清楚它们的各自适用场景。好了，话不多说，我们这就开始第一部分， agent skill 到底是个什么东西？ 用最通俗的话来讲， scale 其实就是一个大模型，可以随时翻阅的作业指导书。举个例子，比如你想要做一个电商智能客服，你可以在 scale 里面交代，遇到退货先询问退货原因，再检查凭证，最后再处理。 再比如你想要做会议纪要总结，你可以直接在 scale 里面规定必须要按照参会人员核心一体代办的格式来输出总结的内容，这样一来，你就不用每次都去复制这些要求了。 下面我就用会议纪要总结这个实际的场景，带大家看看它到底是怎么创建和使用的。这里我们使用科室来演示一下。 要想使用 a j t scale， 那 当然是要先创建一个了。这里直接告诉科室，让他给我们创建一个会议纪要总结的 style 文件，然后稍等一会好了，已经创建好了，我们会看到科室在根目录下创建了一个会议纪要总结的文件夹， 在这个文件夹里面创建了一个同样名字的 scale 主文件，还有填好了这个文件的主要内容，还有一个作为视例的文件，以及一个 reference 文件， 这个 reference 文件我后面会提到是怎样引用的，我们先来看看 scale 主文件，这个 scale 一 共分为两个部分， 头部这几行被这个短线包裹的叫做原数据，英文名叫 meta， 这一层就只写了 name 和 distribution 两个属性。 name 就是 a gentile scale 的 名称，这个名称要注意了，它和文件夹的名称是一致的。 name 下面的 distribution， 它代表这个 a gentile scale 的 描述， 主要是让大模型说明这个 a gentile scale 是 用来干什么的，我们看下下面这部分，这个就是具体的 a gentile scale 是 用来干什么的，我们看一下下面这部分，就是具体的 a gentile scale 的 说明了。这一部分就是在详细描述模型需要遵循的规则， 这个 scale 我 规定了它的提取规则，要提取讨论要点，代办事项，关键决策。好，现在我们的 agenda scale 就 做好了，这就是一个简单的说明文档，下面我们来测试一下， 我们在这里问科室一个问题，你有哪些 agenda scale， 可以 看出科室除了它自带的一些 scale， 它能够识别出来。我们创建了这样一个会议机要助手的 scale， 然后我们来看一下 ctrl 是 怎么使用这个 scale 的。 我们输入请求，布置一个会议录音文本，好，结果出来了，这完全符合我们在 scale 里面的规定，这个就是 agent scale 的 基础用法了， 哥瑟根据我们的指令意识到了这是归我们刚刚的那个 agent skill 管的，然后他就开始读取我们刚刚那个会议总结助手的 skill， 主要读取的也就是这份 skill md 文件了。现在你知道了如何创建和使用 agent skill， 那 么我们来看刚刚这个过程数据到底是怎么流转的。 首先整个过程中一共有三个角色，用户、科室以及科室背后使用的大模型。流程一开始的时候用户会输入请求，此时科室会把用户的请求连同所有的 scale 名称和描述一起发给大模型。 虽然说我们之前只演示了一个 scale， 但是你可以想象一下，哪怕你装了十几个 scale， 大 模型也只是在看一份只有名称和描述的轻量级目录。 在接到了用户请求和每一个 scale 的 原数据后，大模型会发现用户的请求可以使用会议记要总结这个 agent scale 来解决，他就会把这个信息告诉科室，科室接到大模型的响应之后会去会议记要总结这个目录，里面再去读取完整的 scale 详细论文， 这个时候读取的才是 scale 的 全部内容，而且要注意他只读取了会议记要总结这一个 agent scale 的 内容。 在拿到了会议就要总结的 skill 内容后，科室会把用户的请求和完整的 skill 内容再发给大模型，大模型根据 skill 的 要求来生成答案， 最后把答案发给科室，科室再将这个答案发回给用户，这样用户才看到了结果。这个过程就是 ai 的 skill 的 第一个核心机制，按需加载。 前面我们讲了，一开始 coser 会把所有的 i 键的 scale 的 名称和描述都给到模型，比如说如果一共有爆款文案 scale、 会议总结 scale、 数据分析 scale 等等，模型只会选中一个，最后只有选中的那个 scale 的 详细指令文件才会给到模型，这中间就能省下很多的 token。 接下来我们想一下，我们的会议纪要总结可能会越来越高级，我们希望它不仅仅是简单生成纪要，而是能够提供更有价值的补充说明。比如说当会议中谈到了报销的部分，那么他能直接在总结里面标注是否符合财务合规，当涉及到合同时，他能够提示法务风险。 这样大家在看会议总结的时候，就不需要再去翻阅公司的财务制度了，这就非常方便。但 skill 能做到这些事情的前提是它需要把相关的财务规定和法律条文都写入到这个 skill 文件里面，这些文件可能会非常长，都写进去的话，文件就会变得非常臃肿， 哪怕只是开个简单的早会，都需要再被迫加载一堆根本用不上的财务和法律废话，浪费很多的模型资源。 那能不能做到只有当会议内容真的聊到了财务报销内容，科室才会把财务规定加载给模型看呢？这里 agent scale 就 提供了 reference 的 解决方案，我们来看一下，那我们就把这个 reference 文件夹就命名一下，是公司 财务制度，我们在这个文件里面复制公司的财务制度。好，这样一个 reference 的 文件就建好了。这个财务制度里面包含公司具体的会计核算，以财务报告的标准，还有预算管理等规则。 然后我们让科室在原来的 skill 主文件里面新增一个财务提醒规则，里面写明清楚在提到钱、预算、采购这些费用的时候处发，出发的时候需要读取公司财务制度这个文件，根据文件内容明确报销流程，是否超标以及是否需要审批。 我们看一下 schedule 文件，里面有一块关于财务提醒的规则。好，我们现在拿一份有讨论到关于费用这一块的会议内容的文件，让科室帮我们测试一下。这个会议内容里面我们有提到一些预算啊，还有财务费用报销的问题啊， 我们来看看科室会不会触发这个公司财务制度的文件。好，我们会看到啊，科室识别了这个请求跟我们的会议总结助手相关，意识到了这个会议跟费用报销是相关的，根据 scale 的 主文件提示啊，它读取了这个公司财务制度的文件， 然后根据这个实际的会议内容达成了一个总结。可以看出，总结中不仅包含参会人员啊，一提就基础的这个会议内容还包含了财务提醒的规则啊，这完美符合我们的需求。这个就是 reference 的 核心逻辑了，在 agenda scale 的 体系里面，公司财务制度啊，就是一个典型的 reference， 请大家记住它的特性，它是由特定的条件触发的。 在刚才的例子里面，只有当科室读取完这个 scale 主文件的时候，判断出需要查询费用报销制度的时候，才会去加载这个文件，反过来说，如果这是一个跟财务没有关系的技术碰头会，那么就绝对不会占用任何一个 token。 好， 讲完了 reference 这个呢？接下来我们来讲一下如何让 agent scale 跑代码， 这才是真正的自动化。这个就利用到了 agenda scale 的 另一个大能力，也就是 script。 为了演示这个功能啊，我们这次就不搞复杂的服务器上传。我们来做一个最实用的功能，把会议总结自动保存为本地文件啊。 我们先在这个文件夹里面创建一个 python 脚本，这个脚本的功能非常简单，就是接受了一段文本，然后把它保存为一个带时间戳的 markdown 文件。来，我们创建一个这样的脚本 好了。我们发现科室在这个 scale 的 项目文件夹下面创建了一个 script 的 文件夹，里面就有我们的保存到当地文件的简单的拍摄脚本了。我们在这个 scale 的 主文件夹里面再增加一个保存规则。 好，这个保存规则说，如果用户提到了保存啊，存档或者生成文件这些的时候，再触发这个 script 的 文件。好了，配置完成了，我们来到 coco 这边测试一下，让它生成会议纪要，然后保存到本地，我们粘贴这个会议内容。 好啦，和之前一样，科室识别到了这个请求，是和我们刚刚的会议总结助手这个 skill 是 相关的，然后它输出了这个会议资料的内容，并且自动执行了这个 script 里面的脚本。好，执行成功，你会发现文件夹里面多了一个 macdunk 的 文件， 里面就是刚刚生成的会议总结，这里面大家要注意一下，我这次所使用的会议内容，跟财务费用这些其实没什么关系，所以科室也并没有读取这个公司财务制度的文件， 结果也没有财务提醒相关的内容。这正好印证了我前面所说的话， reference 是 按需加载的，如果用户没有提到和 reference 相关的内容，那科室是不会去读取它的，这样就达到了节省上下文 token 的 一个目的。 好让我们再回到代码执行层面，我们看一下，科室在执行这个脚本的时候，并没有去读取这个公司财务制度的文件， 也就是说， agent scale 里面的代码只会被执行，不会被提取。这就意味着，哪怕我们的脚本写了一万行复杂的业务逻辑，它消耗的模型上下文几乎是零。 所以我们会发现，虽然 reference 和 script 都属于 agent scale 的 高级功能，但是它们对于模型上下文的影响其实是不同的。 reference 是 读，它会把内容加载到上下文里面，所以是消耗 token 的， 但是 script 是 跑，它只会被执行，不， 不会占用模型的上下文。实践完两个高级功能，我们会发现， a t 的 scale 的 设计啊，其实是一个精密的渐进式批录结构。这个结构里面一共有三层，每一层的加载机制都不太一样。第一层是原数据层，这是一份 a t 的 scale 的 名称和描述列表， 它们是始终加载的，相当于大模型里面的目录。大模型每次回答都会看一下这一层的信息，然后决定用户的问题是否与某个 a t 的 scale 匹配。 第二层是指令层，对应 skill 文件里下面这部分，只有当大模型发现用户的问题与某一个 agent skill 相匹配的时候，它才会去加载这一层的内容。所以我们称这一层为指令层机制是按需加载。 第三层是资源层，这是最核心的一层，它包含 reference 和 script 两方面的内容。我们刚才例子里面的公司财务手册和保存文件到本地的 python 脚本就属于这一层。只有当模型发现用户问题与财务或者保存相关的时候，它才会去加载这一层的内容。 这就相当于是在按需加载的指令层基础上，又做了一层资源加载。需要强调的是， reference 和 script 的 加载方式其实不太一样， reference 是 被读取的， coser 会把对应文件的内容放到模型的上下文中，在回答时参考 script 是 被执行的。科特根本就不会去看代码的内容，他只关心代码的执行结果。到这里，很多朋友可能发现 a j 的 skill 跟 m c p 有 点像，本质上都是让模型去连接和操作外部世界。既然功能重叠，那我们到底应该用哪一个呢？ 关于这个问题， astropy 官方写过一篇相关的文章来解释，核心观点就一句话， m c p connects cloud to data lets teach cloud what to do with that data？ 这句话可以说是直接点明了 m c p 与 agent scale 的 区别。 m c p 用来连接数据 scale 教你怎么使用数据 scale 的 底层逻辑是用文档和规则定义 agent 的 工作流程，当你编写一个 scale 时，你本质上是在回答四个终极问题， 一、判定边界什么时候 ai 该触发这项超能力？第二，思考路径，他应该按什么步骤去拆解任务？第三，交付标准，最终的输出应该长什么样？第四，安全红线。哪些行为是绝对禁止的？ skill 的 适用场景呢？一个是脑力流程重复的任务，比如创意写作、深度研究或者知识整理。第二个是极简开发的工作，比如你想快速赋用某个能力，完全不想维护任何服务器和 api。 一 句话总结， skill 是 在让 ai 从随性发挥的聊天机器人变成循规蹈矩的业务专家。 mcp 的 本质就是给 agent 插上现实世界的手和脚，它存在的意义不是为了教 ai 怎么说话，而是为了解决那些 skill 触碰不到的硬核操作， 比如直接读取公司内部的数据库，调用企业级的内部 api 系统，真实环境的生产工具集成，就像丝滑连接、 slack、 github 等企业工具链。 为什么这些是 skill 做不到的呢？因为它涉及到了权限验证、服务端运行以及可靠的稳定接口。 skr 活在文件系统里面，而 mcp 活在网络协议和服务器里。 mcp 适用场景是非常硬核的企业级 agent， 还有需要处理真实业务数据以及多系统写作时，当你需要极低的上下文消耗和可靠性的连接方案的时候， 讲清楚这些呢？今天的视频就到这里结束了，我是阿阳，帮你节省时间是最大的美德。如果我的视频对你有帮助，欢迎点赞订阅，我们下次再见！

我为大家分享一个关于巧妙的通信协议设计的案例，这个案例主要解决了在实际项目中遇到的控制器输入输出接口数量不足的问题。我们的 wifi io 模块的客户最近提了一个比较特殊的需求， 一个现场对接需要用到二十路的数字量输入，而我们一个模块只有十二路 n p n 格式的数字量输出，包括八路固定 n p n 或者干接点，六路 n p n 或者 p n p， 可以 配置干接点，总共十四路数字量输入。 问题在于基于成本等原因的考虑， wifi io 模块并没有预留 r、 s 四、八、五等通信接口，更不巧的是输出输入接口并没接到单片机的 u a r t 口。 我经过简单的分析，提供了一个 i o 模块集连的实现方案。解决方案是不增加任何硬件， 而是通过软件来实现两个 i o 模块的集连。具体来说就是利用模块上已有的普通 i o 口，自己定义一套通信协议，让两个模块能够互相说话，从而共享他们的输入输出资源。 这张图就展示了我们的极联方案。为了通过输入输出端口实现模块之间的数据通信，我定义了一套通信协议为零，采用持续时间为 t 的 高低电瓶表示 为一，采用持续时间为二， t 的 高低电瓶表示。一个字节由八 b 次数据位组成，每一个数据位都翻转电瓶。一个数据帧包括两个字节帧头五十五 f f， 一个字节数据长度以及 n 个字节 payload， 一个字节的 crc 校验组成。帧与帧之间留五 t 的 帧间隔时间。通信处理使用 mcu 的 i o 口外部中断接收数据，同时使能 i o 口的上升下降延中断使能一个定时器进行计时。 当 io 口发生电瓶变化时，执行中断程序。在该程序中获取当前定时器的计时值，计算与上一次进入中断时的计时值差值。如果差值大于一点五 t， 则表示当前接收到的数据位为一，否则为零。 缓存当前接收的数据位，当收到一个 byte 数据之后送入到接收环形队列，让主程序进行数据帧的解析。 使用系统的 tick 时钟中断用于发送数据。在增加了该通信协议之后，整套代码只使能了 tick 时钟和外部中断。 其中 tick 时钟中断的发生周期为两百五十微秒。在该中断程序中只做一些简单的时间计时以及数据发送。对于主屏选择为七十二兆赫兹的 stm 三二 f 一 零三，处理器最坏情况下的运行耗时约为五微秒，外部中断的发生周期也为两百五十微秒， 最坏情况下的运行耗时也大概为五微秒。最坏情况下的中断负荷率为十，除以两百五十等于百分之四，处理器最坏情况下的负荷率为百分之三十一。整个硬件回路中影响数据波形及脉冲有以下几个因素， 一、用于输出的达令顿三极管的响应时间，从规格上看，其上升和下降时间在十微秒，对于最小脉宽为两百五十微秒的数据影响可以忽略不计。二、光藕的响应时间， 从规格数看，其典型值为四微秒，最大值为十八微秒。四、光藕的输入和输出寄生电容的充放电时间，输入电容最大为一百五十匹法，输入电阻为三点三欧姆， 时间长数为零点五纳秒，影响不大，但是从负载电阻和响应时间的曲线可以看到，负载电阻的阻值对上升下降时间的影响比较大。当 n p n 输入为低时，光藕导通，发光二极管第四十七也导通。 此时光藕的负载电阻约为 r 一 百零六，并上 mcu 的 内部上拉电阻约为三点零 k， 下降时间约为四十纳秒，而 npn 输入为高阻时，光藕截止，发光二极管第四十期也截止。 此时光藕的负载电阻为 mcu 的 内部上拉电阻，最大为五十 k 左右，此时的上升时间会超过一百纳秒。脉宽的为五纳秒的变化， 即超过卫衣的判断域值三百七十五纳秒，使得被误判为卫衣，造成误码，导致通信异常。为了解决这一问题，我把第四十期短接，这样光偶截止时的负载电阻变成三点零 k， omega 通信恢复了正常。 我们成功将系统的输入输出能力进行了扩展，同时我们也更新了设备内置的编程网页，让用户可以直观的看到所有扩展后的通道。上位机升级软件也做升级，修改 i o 模块的固件匹配的判断逻辑，即不判断输入输出的数量。 这个案例通过巧妙的通信协议设计，在没有增加成本的情况下，解决了一个实际的硬件扩展问题，它充分体现了软硬件结合的设计思路以及在限制条件下进行创新的重要性。