mcp和cli的区别

c l i、 m c p skill 有 什么区别？其实用一句话就能记住， c l i 是 入口， m c p 是 接口， skill 是 手册。先说 c l i， 也就是命令行界面，它解决的问题是你怎么去使用一个工具。比如你打开终端，输入一行行命令，这些都属于 c l i， 它本质上是一个操作入口。也就是说， c l i 不是 能力本身， 而是你和程序交互的方式。你可以把它理解成一个窗口，只不过这个窗口不是图形按钮，而是命令行。接着说 m c p， 你 可以把它理解成它是让 ai 接上外部世界的一套标准接口。比如 如 ai 要读本地文件、访问数据库，调用搜索浏览器，或者使用别的工具，它总得有一套同一的方式去连接。 m c p 干的就是这件事，它不是界面，也不是某一个具体的工具，而是一种接线标准。最后说 scale， 它是指一套被封装好的经验流程和说明。你可以把它理解成 ai 处理某类任务时的操作手册。比如让 ai 去分析 pdf， 生成报表，写代码，做汇报，它不只是靠模型临场发挥，而是可以加载对应的 skill， 按照预示好的步骤去完成。所以 skill 强调的不是连接，也不是入口， 而是怎么做这件事情更加专业，更加稳定。这样一对比，三者的区别就清楚了， c y a 是 交互层， m c p 是 连接层， c y a 面向的是系统和工具， skill 面向的是任务执行的方式。再用一个更加生活化的类比来帮助你理解，假设你在操作一台很强的智能工作台， c y i 就 像是前台操作面板，你可以通过它发布 指令。 m c p 就 像后面的插线板和标准接口，负责把各种设备接进来。 skill 就 像专家写好的 m c p 和操作手册，告诉系统遇到某类任务，按照什么步骤去做就可以了。这回你记住了吗？欢迎评论区告诉我。

朋友们晚上好，今天这个视频呢，只有一件事情，就是从零到一的教会你们使用 cloud code。 那 很多人听到 code 这个单词啊，就会想到写代码， coding 编程，对吧？ web coding， 但实际上以 cloud code 为代表，这种 ai coding agent， 它并不是只能写代码，而是一个万能的工具，并且就在昨天飞书刚刚看完了，他们的 coi 就是 command line interface， 也就是我们说的命令行接口。那么这意味着你可以使用 ai agent 帮你做表格，回消息， 发通知，定会议和安排日程。那么它代表的什么呢？它代表的其实是一种新质的生产力，你可以不用它写任何的代码，但是你要学会使用它。就像在远古时代，一个人是转不去火，而另外一个人直接拿着打火机就把火点起来了。 那么 cloud code 除了编程，它还能帮你做什么呢？首先它可以帮你做数据分析，管理文件，其次可以帮你爬取你的这个每日信息流，每日资讯，还可以帮你修图升图，生成播客，剪辑视频， 甚至你也可以根据你自己的工作方式来搭建属于自己的 skills。 那 么这个视频我将全面的讲解，不需要你有任何的预备知识，从基础到高阶，循序渐进，包括安装和设置，那么基础操作和这个最佳实践，以及 hooks agents， skills， plugins mcp 我都会教给你。那么同时像一些不常见的非常好的命令，比如说 simplify insights， a loop 我 也会教给你。以及我还会分享一下我的经验，比如说如何避免在长时间开发中的莫名其妙的 bug， 以及如何优化 token 节省成本。最后我还会告诉你如何设计你自己的 skill， 点 m d 来让自己的工作效率最大化。 那话不多说，我们直接开始。那首先呢，我们先来安装 cloud code， 那 么这里我们直接进入它的官网，然后我们下滑，我们可以看到这里有好几行命令，那我们只用根据你的电脑，比如说你是 micro s， 或者你是 windows， 选择相应的命令就安装就好了。 那这里呢？如果，如果说大家是 windows 的 话，我推荐大家使用这个 power show， 而不是 cmd。 因为这个 cloud code 的 它的底层是 unix 风格的命令，所以说使用 power show 的 话会更好。那比如说这里我是 micro s， 我 们只复制条命令，然后我们打开我们的终端， 然后我们粘贴上命令，然后再回车就好了。那么它就会帮我们自动地装好 cloud code。 由于这里我已经装好了，所以我就不再演示了。 ok， 那 刚才既然我们已经安装好了 cloud code， 那 现在我们该怎么使用呢？那很简单，我们只用打开我们的终端，然后输入 cloud 就 好了。 我们敲击回车，那这里它会选择说你是否愿意选择当前这个呃，文件夹做你的 workspace， 那 我们点击 trust this folder 就 好了。 ok， 进来之后我们就来到了这个界面。 ok， 那 现在趁着 cloud 在 安装，那现在我们需要安装另外一个非常重要的工具，叫做 c c switch。 我 们知道。呃，我们在国内想要使用官方的服务，比如说 opus， sonnet 或者是 hikube 是 非常麻烦的。那所以说我们就需要使用我们国产的模型，比如说 mini max， 呃， g o m， deepseek， 或者说百炼等等等等。 呃，还有像 kimi 这样的模型，那我们该如何使用呢？那很简单，我们使用这个工具就可以方便的帮我们配置，那么这个工具呢？叫做 cc switch， 那 么它的作用呢？就是允许我们配置多个模型，并且可以快速的切换。那么安装方式也很简单，我们只用往下滑。 好，这里有个快速开始，然后如果说你是 macos 用户，你直接复制这行命令，然后打开终端，像刚才我们安装一样，把这行命令复制过去，然后回车，它就会自动安装了。那如果说你是 windows 用户，那就比较麻烦了，我们需要点击 release， ok， 那 这样我们来到它的 release 界面，那我们一直往下滑， 那么我们可以看到它的一个 contributors， 然后它有个 assets， 那 我们点开这个 show all， 然后我们找到这个 cc switch v， 三点十二点三， windows 点 msi， 注意一定要是 windows 点 msi， 然后我们下载这个就好了。 ok， 那 既然我们已经安装好了 cc switch， 那 这一步我们要做的就是配置我们的模型，那么在这里呢，我选择的是我们的 mini max。 二点七，那配置方式也很简单，我们点击一下这边这个加号， 然后我们可以这里可以选择你使用的是模型，比如说你是智普，就选择这个，那么你，你是 deepsea， 选这个，对吧？你是 kimi， 就 选择这个，那我们这里是 mini max， 那 我们只能选择 mini max。 这，我们往下滑，那这里它已经帮我们填写好了这个 base url， 那 我们需要做的指示填写，我们好我们的这 api key 就 好了，那 api key 怎么获取？ 那很简单，我们打开这个，呃， mini max 官网，呃，这里有个订购套餐的界面，好吧，那在这里呢，我建议大家就选择这个四十九元的这个套餐就好了，呃，目前我用下来是非常的够用。购买了套餐之后，我们点击我们的这个账户管理，我们选择 tokenplay， 在 这里我们把这个 api key 复制一下，然后我们粘贴在这里就好了， 这我们点击添加就 ok 了，就配置完成了， ok， 那 现在既然我们已经把 cloud code 安装好了，然后我们把 api 也配置好了，那现在我们就直接开始使用，那使用方式也非常简单，我们打开终端，输入启动命令，我们回车之后就进到第一个选项，那这里我们选择 yes， ok， 我 们就来到我们的工作页面，那可以看到刚才我们已经配置好了 api， 所以 说它这里显示的是 mini max 二点七，然后这里是 api use， ok， 那 么首先呢我们来讲讲 cloud code 的 三种模式，那么第一种模式呢叫做 default mode， 也是现在这种模式就就是这里什么都没显示。那么第二种呢叫做 plan mode， 那 就是规划模式。那么第三种呢叫 bypass permission mode， 那 这就是，呃完全执行，也就是相当于 full access 这种模式。那么首先我们来说第一种，第一种模式的话，那它的呃这个特点就非常简单，就说，嗯，它执行就是 cloud code 执行任何一个操作，比如说它读写文件，编辑文件，都需要你明确确认之后它才会执行，那比如说现在 我们让他在桌面上创建一个文件，看看是什么效果，那这里呢？我推荐大家一个工具叫做闪电缩，那他就是一个语音输入法，但是他这个语音输入法是会使用这个拉玛，也就是我们的大模型去整理的语音输入，并且他是可以学习的，所以说他这个识别准确率是非常的高，那么包括我看到抖音，他们也做出了自己的这个 豆包输入法吧，那么我看我身边有朋友体验也非常不错，那大家可以去试一下，总之一切是免费的。那云输入法的话很简单，我们只用给他说我们的想法，呃，帮我在桌面上建立一个文件夹吧，然后里面给我放一个文件叫做 test 点， md， ok， 我 们回车看一下他会怎么执行， ok， 那 首先他会问我们文件夹是什么名字，对吧？叫做 test 就 好了， 这里呢它就会让你选择是否执行这个命令，那我们可以看到 make d r， 就是 就是新建一个文件夹嘛，然后在这个位置，好吧， 那我们选择 yes 就 好了，因为现在我们是 default mode 嘛，就是它每个插座都会问你是否要执行，我们选择 yes， ok， 他 说已经成功创建了，刚才我们已经讲解并演示了 default mode， 那 么它就是每执行和命令，好吧，都需要我们手中确认一次，那我们想刚才只是一个非常简单的任务，对吧？我们创建一个文件夹，所以说执行一次，选择一次，点击一次就好了。那如果说现在我们在执行一个非常复杂的任务，那我们每次就要点嘛， 那我们还怎么玩手机，对不对？那怎么摸鱼对不对？非常的麻烦，所以说我们就要使用这个危险模式，那危险模式该怎么进入呢？危险模式的话，我们需要呃用一个单独的命令进入，刚才我们是输入 c l a u d cloud 这个命令来进入的，对不对？那现在如果说我们想要使用这个危险模式，也是这种 full access 全自动的模式，那我们就需要在后面加上参数，加上这个 dangerously skip permission 就 许可嘛，对吧？就是无许可模式嘛。 ok， 我 们点击回车 啊，一样的，我们选择 yes， 相信这个。呃 folder 做我们的 workspace， 那 ok， 看到这里就有了这个 bypass permission 啊，就说现在它执行和命令不需要我们的这个批准了，好吧，它会直接自动执行。那同样的，我们说帮我在桌面上建立一个文件夹，然后名字叫做 test 二吧，然后里面给我放一个这个 md 文档，名字随便取就好。 ok， 我 们看看它会怎么做， 你看它这里直接执行了这个 bash 命令，好吧， macd 直接创立了这个 test 二的这么一个 folder， 然后在下面呃，创立了一个 untitled 的 点 md 文档。 ok， 他 现在直接给你说我们完成了这个任务就非常方便。所以说，呃，我更推荐大家使用这个 dangerously keep permissions 这个命令来起到我们 cloud 吧。那我们继续讲讲规划模式，就是这个 play mode， 那 play mode 它其实有两种的，呃，这个应用场景嘛，那么第一种就是当我们在做产品的时候，做项目的时候，在初期，呃，我们想知道这个 ai 会怎么执行，对不对？是不是按照我想的方式执行？ 那么我们可以用这个 plan mode， 让他规划书写一个 plan 出来，我们看一下，没问题。 ok， 那 就会按照这个 plan 去执行。那第二种应用场景呢？就是针对一些比较宽广的任务，就是广度比较大的任务吧，就比如说现在我让他把我桌面上面所有的这个文件全部给我迁移到我的这个硬盘里面去，那他会操作很多文件，对吧？可能呃几百个，那这时候我们就用这个 plan mode 就 比较好。 那还有一种场景就怎么说？就比如说现在我们我需要让他去 re-use 我 们的代码，就去审查我们的代码吧，对吧？那这时候让他用这个 client 就是 一条条干，先干嘛，后干嘛，那这个场景是比较好的，那这里我们来体验一下这个 client， 我 们还是用 shift 加 tab 切换一下。 那我想想我们列个什么计划，那很简单吧，现在我要整理我的桌面文件夹，现在请你帮我列个计划，我看看该怎么整理。 ok， 我 们回车看看他会怎么做。那么我们要注意啊，就是 plan mode， 他的权限是只读权限，就是他只会进行读操作，不会进行写操作，只有你看过没有问题之后，那么他才会进行写操作。 ok， 我 们可以看到很快他就给了我们一个 plan， 那 同时他给了我们三个选项，第一个选项就是 yes and bypass permission， 这是什么意思？就说无条件执行，不要来问我了。那么第二个是什么意思？第二个就说 yes， manually approve it， 就是 执行这个计划，但是需要我手动来批准每项这个编辑，那么第三个选项就说你可以告诉他，你觉得这个计划有什么不好的，你直接给他说， 他就会按照你的这个要求去更改这个计划，然后再让你看一遍。那比如说你再帮我把垃圾箱清理一下吧，把这个计划加入进去，然后让我看一下。 ok， 我 们可以看到他刚才又在我的要求上增加了一部清空垃圾箱的这么一个任务，那你觉得没问题，那我们就选择 yes 这个 bypass permissions， 它就会自动执行的。 ok， 那 现在我们来讲讲 cloud code 的 一些命令，那首先第一个命令就叫 enit 命令，那么现在我已经打开了一个项目，这个 voice input 是 我让 codex 做的一个语音输入法的项目， 那一定题命令很简单，就是初设化嘛。那么他这个命令呢？首先会把我们整个这个项目的代码看一遍，看完之后他会根据他理解生成一份 cloud 点 md 文档，那这个 cloud md 文档有什么作用呢？就是，嗯，每次绘画的时候，他都会首先加载这个 cloud md 文档，那里面就是一些最高的原则，相对于类似于机器人不能违背的三条法则那种感觉。 ok， 我 们这里可以看到他成功创建了一个 cloud md， 然后这是他给出的一份资料，那即使想要写好一份好的 cloud md 文档，也是需要花很多功夫的，那我们就不在这里多说了，但是 唯一一个原则，大家需要记住的就是不要让你的 cloud md 写得又臭又长。如果说 cloud md 写得非常长的话，那每次上下文稿加载它就会一个是会消耗我们大量的 tool， 另外一个就是会让这个 嗯 a 键是变得非常笨。那一种解决方式就是我们把那种长的文件拆分出来，我们新开一个这个 md 文档去存放，那比如说我们可以开一个 get 点 md， 对 吧？然后我们把这个 get md 的 这个路径，我们记录到这个 cloud md 中，然后并且我们想指示说如果你需要这部分的知识，那么请去查找这个文件，这就是，嗯， cloud 客户团队非常喜欢的这个叫渐行式批录。 ok， 那 我们什么时候可以使用这个 init 命令呢？那我的答案是你任何时候都要使用这个 init 命令。比如说你从 github 上面下载了一个新的项目，你使用这个 init 命令，那就可以让这个 agent 快 速的了解整个项目，然后生成一份 cloud 的 md 文件， 然后 cloud 点 m d 文件是相当重要的一个文件，它相对于这个 ajax 的 一个最高指示，所以说你可以在里面写一些你自己喜欢的，你觉得非常重要的一些原则，比如说开发规范，比如说千万不能执行 r m 杠 r f 等等等等。那 cloud 点 m d 呢？一般会随着你项目的迭代，开发过程迭代呃来完善。 ok， 那 大家肯定听说过 marty agent 或者说 agent team， 那 其实想要创建一个多 agent 的 这么一个团队也非常简单，那像 cloud code， 它就支持我们创建这个 agent， 并且可以用这个自然语言创建，那我们只用执行 agent 命令，可以看出来，我们点击确认，那它就会说第一个选项 create new agent 就是 创建一个新的 agent， 那 么这就是 user agent， 就 代表说我们已经创建好的 agent， 可以 看到我这里创建了一个 codex review agent， 还有一个这个 marty agent coordinator。 ok， 那 现在我们来创建一个 agent 来看一看。那首先很简单，我们直接回车选择这个 create new agent 就 好。 ok， 它这里就会让我们选择这个 agent 的 location 在 哪里，就说选择你这个项目级别，就是它这个权限级别嘛，那我们就选择这个 project 就是 这个项目级别就好了。 然后它现在又给了两种方式，第一种方式就是 generate with cloud， 就是 说让你跟 cloud 一 起创建这个 agent。 第二种方式呢，就是你自己去写它的这个配置文件，那我们肯定选择第一种，对吧？因为毕竟它后面都说了这个 recommended， 那现在他就说让你去描述一下你这个 agent 要做什么，你看他这里说的 describe what this agent should do？ 吧啦吧啦吧啦一大堆，对吧？那我们很简单，现在我要创建一个这个 technique co founder， 这么一个 agent 就是 一个技术合伙人的 agent 吧？那我把我准备好的这个 prompt 发进去， ok， 那 现在我们点击回车就拿创建这么一个 agent， 然后他现在就在 显示，他说 generating agent from description， 就 说现在根据我们这个描述在创建这么一个 agent。 那 当然本次教程提到的所有提示词会放在我这个文档里面，那具体怎么获取文档请看我的这个主页，好吧， 在我的公众号里面获取。 ok， 那 现在出现了这个界面，这个界面就是说让你去选择你新建的这个 agent 允许他使用哪些工具，那他根据我们的这个描述，现在给他全部工具权限，那当然你也看到这里写了是 enter to talk selection， 那 就是 talk 切换状态嘛，那很简单，如果你想 不让他使用这么多工具，对吧？那你就小键盘嘛，上下左右。然后你假如说不让他使用全部工具，你再按一下这个 enter， 那 你看全部都没有选中了，现在是零个工具这里显示的。 那如果说你要全部工具选上，那就返回去，然后再按下 enter， 现在是 auto selected， 然后确认没问题，我们就 continue 就 好了。 那这里他就说让你去选择你新的这个 app 的是用什么模型，那比如说你是用 sonet 或者 oppas 或者是海库，要不然的话，你就说它是继承它的这个负类的模型。那很简单，因为我们用的是 mini max 二十七嘛，那我们其实不用选，我们直接选择这个 inherit 就 好了。 然后这里就说让你选择这个 agent 的 颜色，比如说你选择红色、蓝色、绿色、黄色，对吧？选择选择一个你喜欢的颜色就好，那我们选择一个黄色吧，然后他这里就说这个 agent 这个 memory 它在哪个范围，那我们选择这个当前项目级别就好。 然后现在它就会让你再再次确认，然后你可以浏览一下这个，你的这个 description， 你 这个 memory， 你 的这个 system prompt 等等等等。 ok， 确认没问题，我们选择 enter 就 创建好了，你看它这里显示的 creative agent technical founder。 ok， 那 我们想要调用我们创建的 agent 也很简单，直接使用这个自然语言去交互就好了。 那这里我们就说帮我调用我新建立的这个 technic founder， 这个 agent， 我 要做一个项目， 那我们看看他会怎么做？ ok， 可以 看到他成功唤醒了这个 agent， 你 看他正在初步化，花费了二十六点六 k 这个 tokens， 然后现在他说 technical founder 这个 agent 已经启动了，现在你可以说你要做什么项目了，那我们就开始巴拉巴拉巴拉说我们的一堆项目，对吧？他就可以帮我们完成。 那我们什么时候该新建立一个 agent 呢？那很简单，就是当你发现你会重复地做同一类任务的时候，并且这类任务需要很长的一段 prompt， 需要你定很多的规范。那这时候你应该专门创立一个自己的 agent， 比如说你可以专门建立一个产品经理的 agent， 一个后端开发的 agent， 一个前端开发的 agent， 一个专门做这个测试的 agent， 甚至呢你也可以专门建立一个 codex agent， 那 这个 agent 其实就只用干一件事情，就是在你的终端去执行这个 codex 命令，相当于唤醒了 codex， 那 这样就可以实现 cloud code 的 写代码 codex 进行 review， 并且不需要你人工去传递他们的 prompt， 传递上下文，直接让他们两个对接就好了。 一个单独的 agent 还有一个非常好的点，就是它可以帮助我们节约我们的上下文。那假如说现在我们要去执行一个非常长的文件的写操作，或者说一大堆这种抓取的操作，那我们可以单独开一个 java agent， 让这个 a 键去执行的操作。我们并不关心他到底获取了什么样的数据对不对？我们只关心他到底完没完成任务，那 x a 键就帮我把中间上下文给省略了嘛？最后他完成任务返回一个 ok， 那 我们就知道任务完成了，那 a 键这个命令就讲这里了，那同样有很多玩法需要大家自己去探索， 那现在我们来继续讲讲 m c p skills， 以及最近新出的 plugins， 还有我们的 hooks。 那 首先我们来讲 m c p 跟 skill 吧，因为很多人会把这两个词搞混，那其实很简单， m c p 中文翻译过来叫做模型上下文协议，那么 skills 呢？翻译过来叫做技能能力，对吧？它们之间的差别 有一个就是 m c p 是 告诉你能不能做，就是你有没有这个能力做，而 skill 是 告诉你你如果有了这个能力，你应该怎么做。那我举个例子，现在假如说我是一个残疾人，我没有这个腿，但是我想去骑自行车，是不是我就不能骑？那假如现在给我一个骑车的 m c p， 相当于就能帮助我长出这个双腿，那我有了腿是不是就可以去骑车了？ 但现实就是很多人尽管他四肢健全，他还是不会骑这个电瓶车，对吧？不会骑这个，呃，这个自行车，摩托车的。那我们再给他一个 skill， 就是 给他一个骑车指南，就是教他怎么骑这个自行车的，对不对？那这样二者一结合，是不是我们就会骑车了？大家应该可以很好的理解。 然后我们再举个例子，那假如说现在我们在进行一场开卷考试，开卷考试我们肯定要带复习资料对不对？肯定要带书对不对？那么 m c p 就是 说你带了这个书，带了这个资料，那如果说没有这个 m c p 就 相当于没有带书，那么 skill 是 什么呢？ skill 就是 说你脑袋里面组织你怎么看这个书，怎么看这个材料，对吧？ 比如说有些人会很快的找到这个答案在哪里，有些人要找很久才能找到，所以说 skill 是 教你怎么看书的，那么 m c p 是 你本身带不带这个书，带不带这个资料？那现在我们想看我们 cloud 的 安装哪些 m c p 很 简单，我们直接在这个命令行里面输入这个 slash m c p 指令就好了， 就可以看到现在我这里只安装了三个这个 skill， 一个抖音的，一个 pencil 的 playwrite。 那 现在你想看你安装哪些 skill 也非常简单，我们输入这个 slash skills， 就会看到你安装了这 skill。 当然这里的误区就是 skills 并不是越多越好，而是越精越好，就是 你如果是个小白的话，你可能会安装很多 skill， 对 吧？摸索一些你比较常用的 skill。 然后那我给你的建议就是你在这个使用过程中，你要不断去精简这些 skill。 因为 skill 过多会造成一个什么现象？就是模型有太多的工具调用了，导致他根本不知道什么时候该调用什么工具。这句话怎么理解呢？就有点相对于类似于选择恐惧症了， 就是一个人有太多的选择，就导致他一下子迷茫了，不知道自己的路该怎么走，那如果说他就一个选择，那就逮着往死里干就完事了。 那什么是 hooks 呢？嗯， hooks 用中文翻译过来叫做钩子，这个可能比较难理解，其实他本质上就是一段脚本银行代码，然后呢，在特定的事情发生的时候，他就会自动触发执行。 那么 hooks 呢？大家按照它的执行顺序，可以把它简单地理解成两大类，第一类叫做在工具调用前执行的 hooks， 第二类叫做在工具调用后执行的 hooks。 那 我们看一下， 那现在我们想象这样一个场景，我们知道 cloud 它是可以操作我们电脑所有的文件，对不对？但是你不想你的某些私密的信息，一些密钥文件，或说你不想让 ai 知道的文件被它读熟了，那怎么办？ 那你就可以制定一个 hook。 这个 hook 怎么定义呢？就说每当这个 ai 进行读操作之前，或者说之后执行这个 hook， 这 hook 就 会检查你当前要读取哪一行文件，读取什么东西。如果说发现你读取这个路径和你这个私密文件的路径重复了，那就直接拦截， 懂了吧？这就是 hooks。 那 再比如说，现在我们在我写一个项目，那么项目写好之后，我们会把它推送到 github， 进行这个代码托管。那么我想的是每一次只要我执行了这个 review 操作之后，就自动地给我推推送到 github， 那 么也可以定一个 hooks。 那 么这个 hooks 呢？就是这个 post tool use hooks。 简单就说，当它监测到我们执行的这个 review， 那么它就会自动触发这个 hook， 把代码推上 gitlab。 那 hook 是 怎么创建的？也非常简单，我们只用告诉 a e i 说帮我创建一个 hook， 然后它这里就显示了你想配成哪一种 hook 啊，然后你再把你的需求给他说，他就会根据要求帮你配进一个 hook， 很 简单。 那同样的我们该如何创建 skill 呢？那么 skill 其实不建议大家在一开始就创建好，除非你很明确自己的这个流程是什么样的，场景什么样的。我更建议大家在使用这个 cloud 的 过程中来创建，因为你在使用的过程中才会发现哪些工作流是可以重复的，对吧？会大量重复执行， 那这时候你就可以建立一个你自己的 skill， 那 比如说我自己就建立了一个记录素材的 skill， 每当我给他发一个抖音链接，或者说小红书的链接，或者说呃， youtube， bilibili 等等视频网站链接，那么他就会执行一个动作，他会把这个链接的这个字幕也是在这个脚本这个竹子稿，然后保存到我本地我指定的位置，非常的方便。 那什么是 plugin 呢？这是最近新出的一个东西啊，那么 plugin 本质上就是说它把你的 hooks， 把你的 skills， 把你的 m、 c， p 全部打包封装在一起，那这样你在进行团队开发的时候，大家都可以附用这个主键，就非常的方便，非常的好，所以这就是 plugins 紧急抄波一条啊。刚才 codex 官方出了一个 plugin， 叫做 codex plugin c c， 就是 允许我们在可拉钩中直接调用 codex， 那 么安装非常简单。首先我们执行这行命令， 那么再执行这个命令，然后我们再重载一下 plug in， 这我们再准备这个 set up， 那 它就会自动调用你这个桌面上面的这个 codex 的 配置，然后写入，那就准备就绪了。来继续讲讲几个非常好用但是很不常见的这个命令，我基本上没有看到任何人讲过。那么第一个命令就是这个 simplify， 我 们把它敲出来， 那就是这个命令。这个命令命名是什么意思呢？那么叫 simplify， 它的中文翻译就是简单简化，对吧？那么 simplify 它其实就是一个代码的一个呃，检查命令，一个进行 code review 的 一个命令。就说当你完成一段代码的修改之后， 你运行这个命令，它会自动地对你所有的变更进行全面的审查。那么它的工作流程就是它会同时派出三个 sub agent， 那 么第一个 agent 它会检查这个代码有没有重复造轮子， 那么另外一个 agent 它会看这个代码或者命名这个格式不规范。那么还有一个 agent， 那 么它会直接查这个性能影 换，那就比如说重复计算，内存泄露等等问题。最后呢，他们会把发现的问题直接修复掉。当你的代码写完了，你直接运行这个命令，让这工具帮你检查一遍，进行这个 code review。 大家要注意就是我们想运行这个命令，我们必须把这个代码上传到 github， 进行这个代码托管。那 github 什么呢？ github 是 全球一个最大的开源的一个，呃，代码托管的一个社区，那你如果没安装 github 的 也非常简单，你直接给你 ai 说帮我把代码上传到 github， 它就会协助你完成。好吧，那现在我们运行一下这个 sql 发命令，看一下是个什么效果。 ok， 我 们可以成功看到他已经把这个命令运行完了。由于我这个代码仓库刚才只是更改了这个 readme 文件，然后做一个演示，所以说他这里给出这个发现是你的代码非常干净，好吧，没有任何需要更改的。 那我们可以看一下他这个命令的运行过程，首先他执行的是 git diff， 他 看一下你当前这个代码和你之前提交在 gitlab 上面的代码，那有什么差距，对吧？那他这里说这个 only change is readme dmd， 那就说我们只修改了我们这个 readme 文档，那他还会走他接下来的流程，那接下来的流程就是他开了三个稍不一点的，那么第一个可以看到他进行了这个代码的附用的这个检查，第二个进行了代码质量的检查，那么第三个进行了这个效率的检查，那发现全部做完成之后，那给出了结果，然后给出了发现， 那这就是这个命令。 ok， 那 现在我们来讲第二个命令，第二个命令叫 rewind， 也非常简单，我们把敲出来看看，那这个命令它作用是什么呢？这个命令它作用就是时光倒流，就是当你把这个项目做歪了，或者说你想换个方向的时候，那么它可以回归到之前这个 checkpoint， 就是 回归到这个检查点，然后同时它会恢复这个代码和上下文。非常简单， 因为刚才我只执行了两个命令嘛。首先第一个命令我执行了 clear， 第二个执行了 simplify， 对 吧？所以说这里就只能选择两个，那我们选择一下这个 clear， 那 进来之后呢？我们可以看到这个命令给了我们三个选项，第一个选项就是 restore conversation， 那 我们看到它的解释是这个 conversation will be fork， 就是 说当前这个对话那会保持不变，但是我会在 clear 这个 checkpoint， 就是 在 clear 这个检查点这个地方，我们先看一个分支， 然后继续我们的对话，好吧，那我们看第二个选项是什么？第二个选项是 summarize from here， 就 说我们会把从 clear 这个检查点到现在这个检查点之间的所有对话进行一个压缩，进行一个总结，生成一份答案，然后再继续。那这个 nevermind 就是 我们直接取消的意思，那我们直接选择 restore confirmation， 你看那他就新开了一个对话，这个命令就到这里结束了。那接下来我们讲讲 in size 这个命令，这个命令非常简单，顾名思义就是洞察，那么他会根据你的 sql 的 对话，就是你所有的 session 来生成一份这个报告，那么他会统计你使用 sql 的 模式，比如说你会在哪些项目区域花的时间多，在哪里容易卡住，那么帮助你了解自己的一个写作习惯。那么使用方法也很简单， 我们直接输入这个 in size 命令就好了。那我们使用方法也很简单，我们直接看到这个报告非常详细， 那最后这个命令叫做 loop， loop 也很简单，顾名思义就是循环的意思嘛，那它就相当于一个定时任务，但是一个定时任务是在三天之内的，那我们怎么使用呢？比如说现在你想每一个小时帮我查一下当前的时间，那你可就可以这么执行，我们先选择 slash， 然后输入 loop 命令，然后你看它这里说了 interval 就是 间隔的意思，那我们选择 one hour， 就是 e h， 然后干嘛帮我查询一下当前的时间，那回车我们看看它会干嘛？ ok， 那 我们可以看到它成功帮我们设立了这个定时任务，并且查询了当前的时间。 ok， 那 这个 loop 还有个非常好用的地方，就是它可以和 skill 一 起赋用，因为我们知道 skill 本质上就是一段 prompt， 对 吧？所以说我们可以这么使用，那比如说现在我想让他每隔一个小时帮我查询一下当前这个 ai 新闻，那我们该怎么执行？就是 loop， 然后执行一下哪个 skill， 执行下 ai news 这个 skill， 我 们看看它会怎么做。然后我们可以看到它成功执行了我的这个 skill， 并且把内容保存到了这个位置，然后它也创建了 cron。 ok， 那 现在我们来讲讲如何解决在长对话中莫名其妙出现的 bug。 那 我们知道如果说我们一个对话进程很长，那它肯定会压缩我们上下文，就是那个 auto compact， 那 压缩上下文的时候，那如果说最开始前几轮还会好，它只会压缩一些内容，一些文档，不会压缩一些关键信息。但是我们发现随着对话的进行那么多轮压缩之后，它第一点就是它的关键角色信息会丢失，早期价格约束将会被遗忘，那就会导致我们多人写作的时候 bug 越来越多了，好吧，所以说一些莫名其妙的 bug 出现， 那我们该怎么解决呢？那我们就是要让这个 cloud code 不要遗忘那些关键的决策，对吧？那比如说我们就可以在 cloud md 里面加入加入这个方案，或者说我们让他写一份这个 handoff 文件，那 handoff 文件怎么写？首先第一步我们要说清楚当前的进展是什么？我们的目标是什么？已验证的有效方案是什么？那么已验证的无效方案是什么？写清楚之后， 再打开下一个对话，让他进行交接，这样就会没有问题了。 ok， 那 现在我们来继续讲讲一个被很多人忽视的就是工具调用所产生的这个上小文的噪声。那我们知道，假设调用工具，比如说你测试代码，它会给你输出一长串的配索键，或说你查找文件的时候也会给你输出一长串的那种信息，那这东西是 cloud 是 根本不需要的，他只需要知道你完成了没有， 对吧？是 ok 还是不 ok？ 所以 说我推荐大家安装这个 skill 就是 一个 r t k， 那 么他就会帮我们把这个信息压缩，只用返回给 cloud 的 最关键的信息就好了。 ok， 朋友们，那么看完了这期视频，我相信你对 cloud code 的 掌握已经超过了国内百分之九十九的 ai 玩家。但是说实话，工具只是工具， ai 时代最重要的并不是你会多少个命令，而是你的想法，你的 idea， 你 到底有没有真正想要做的事情。那么 ai 就 像一盏阿拉丁神灯，你提什么愿望， 它就会帮你实现什么愿望。所以说做一个有趣的人， dream bigger。 那 么下期视频还想提什么？你们决定评论区打出来，我们下次再见，拜拜。

面试官问你一句， c l i 和 m c p 有 什么区别？你怎么看？你要是只会说一个是命令行，一个是协议，那我可以直接告诉你，你没想到本质。那正确答案就是一句话， c l i 和 m c p 本质上是两种不同的 agent 工具调用方式，一个是直接执行，一个是协议中转。 你可以先快速定义 c l i， 本质是通过命令行直接调用系统能力。 m c p 本质是给 ai 提供一套工具说明书加调用规范的协议。然后呢，你一定要给对比结构。 第一，工具认知方式， m c p 模型需要先读说明书理解工具能力， c l i 直接通过命令调用，不需要复杂的描述。 第二，调用路径， m c p 是 模型到 m c p server 到 api， c l i 是 模型到命令行到 api， 少了一层中转。第三，成本与效率， m c p 是 上下文，长投肯消耗大， c l i 轻量调用成本低。你也可以举一个简单的例子，比如让 agent 把会议记录写入 lotion， m c p 呢，就会先读工具说明，再选工具，再填参数，再调用。 c l i 呢，是直接执行命令，调用 api。 然后你一定要深一层。这句话很关键，就是 m c p 解决的是让模型知道怎么用工具， c l i 解决的是让模型直接用工具。面试官如果追问趋势，你可以这么答， 早期模型能力弱呢，需要 m c p 这种说明书体系，那现在模型更强了，理解能力更好了，推理能力也更强了，不再需要那么重的中间层， 所以 c l i 这种更轻量的方式开始占优势了。那其实 m c p 并没有消失在企业的场景里面呢？权限控制工具统一接入安全治理 m c p 仍然是更适合做中间建层。那最后一句话， agent 工具调用的未来不是单选择题，而是轻量执行 c l i 加企业治理 m c p 的 组合。 最后呢，我也是把二零二六年呢关于进阶大模型的最新路线给整理好了，大厂资深的算法工程师亲自准备的内部必读文档，包含了模型原理，产品落地思维框架全都有。如果你最近想要转行或者是面试，应该对你有帮助，需要的安排。

大家好，让我来向你介绍一下 playrite c l i 是 什么。它是 playrite 家族中的一款新工具。在本视频中，我们将讨论 playrite c l i 是 什么，并将它与 m c p 进行对比，展示一些演示，讲解令牌效率和一些功能。 希望你能更清楚地了解未来应该使用哪一个。让我先从演示开始。这次 playrite c l i 功能的一个演示，我现在在一个空文件夹 demo c l i 里开始操作。 接下来我要全局安装 playrite c l i， 这意味着它将在所有位置都可用。我做的第一件事是初设化我的工作区。我输入 playrite c l i install， 这会创建一个名为 playrite 的 空文件夹。就是这样，我们用这个方法来区分你词盘上的不同工作区。 每个工作区都会有自己要使用的一套浏览器。关于这一点，我们稍后会详细介绍，但我还想在这个工作区里安装一些技能。我输入 install skills， 他 会在我的工作区安装一堆 cloud 技能。当我启动 cloud 并给他分配一个任务， 我要让它打开 playwrite dev。 这是一个网页，搜索 locators 这个词，并检查每种语言的文档是否都可用。这里所说的语言是指它支持 javascript， python， java 和 dapplet。 我 还让它为每种语言的文档都截一张屏。 那么让我们看看它是怎么做的。我们现在看到的是一个十六倍速的延时画面，展示了刚才发生的过程。刚才发生的事情其实就是 cloud 在 用 c l i 工具和浏览器进行对话，让我们看看结果出来了没有。 我们来看一下上下文，这样可以看到我们已经消耗了多少 tokens， 但我们不会在这里停留太久。接下来我们将用 mcp 版本来完成同样的任务。让我开始吧。 cloud 这里 我看到 mcp 服务器已经安装， play red mcp 也已经安装，这个文件夹里没有安装任何技能，所以我接下来要做的就是给他分配完全相同的任务。 同样，第十六倍速快进任务完成了，我们也来打开这里的上下文统计，看看我们消耗了多少 tokens。 好 的，所以我们在这里看到的是我们总共用了十一万四千个 tokens， 对 于这个操作来说，这个消耗是相当高的。我们来和 cli 的 结果对比一下， c r i 只用了二万六千八百个 tokens， 所以 我们在演示中看到 m c p 消耗了更多的上下文。但这是为什么呢？让我们深入探究一下，这就是 m c p 所做的事情。所以我们来看看这两个雕用。首先，它尝试导航到一个页面， 而 playrite dev 是 一个 docker source 页面，这个页面相当大，内容很多，有很多 dom 控件，脚本等等。 尽管 playwrite msp 在 指传递可访问性快照给 llm 方面非常高效，但他仍然回复了全部内容。这些内容都进入了上下文窗口， 我们可以看到这个结果已经超过了最大临牌数。最后他截取了一张屏幕截图，但当 mcp 截屏时，是 llm 要求他这么做的，所以我们把所有这些字节都回复给了 llm 本身。同样，图片的 token 也进入了上下文。 而在这种情况下，这并不是我们的目标，我们想要的只是截取一张屏幕截图并保存在此盘上。让我们来对比一下 c r i 的 做法。 c r i 说我想去一个位置，然后他甚至没有补获快照，也没有从此盘读取由这次调用生成的快照文件，而是直接截取了屏幕并保存了这个文件。结果，他保存了上下文，这些 tokens 都没有进入上下文。因为 l m 实际上并不需要他们， 所以 c i 的 做法是，他会把所有输出的数据都保存到文件中，然后你的编码代理会决定是否需要将这些数据发送给 l l m。 我 们来谈谈功能。我们已经看到了 m c p 是 如何工作的，但你会发现 m c p 只用了几十个命令。这并不是因为 我们并不是没有这些命令。我们确实有这些命令。事实上，所有 c l i 的 功能在 m c p 中也都可以使用，只是我们默认没有起用它们，因为它们会消耗上下文。另一方面，在 c l i 上我们没有这种限制，所以我们可以开放所有这些命令，甚至更多。好了，我们已经看过了 token 的 使用情况，也讨论了功能。 那看起来这似乎是显而易见的选择，应该使用 c l i， 对 吧？好吧，让我们稍微聊聊这个问题。 c l i 是 一款新工具，当它作为编码代理的一部分使用时，它的优势就会体现出来。 而编码代理可以是你的云端代码 github compile， 或者任何能够编辑文件访问你的工作区的代理。在这种场景下，我们可以非常高效。 你可以捕捉这些快照，并将它们保存到词盘上。将这些截图保存到词盘上，然后让编码代理决定是要完整读取它们，还是要将全部内容发送给 l l m。 这样一来就能实现偷看的高效利用。所以， c l i 需要配合编码代理才能高效运行。除此之外，它是基于技能的， 你可以将关于 playwrite 和你的场景的知识添加到这些技能中，因此它可以与其他基于技能的工具互操作。它默认也是无头模式，因为我们假设你会在编码代理中运行许多后台代理。另一方面， mcp 可以 与任何通用代理合作， 它是一个严格的标准工具，知道该期待什么，如何调用这些 mcp 工具以及结果会是什么。但在这种情况下，一切都掌握在 lm 手中， 因此所有的回复很可能都会返回到 l o m， 并且有可能会使其上下文超载。你在 m c p 中仍然可以拥有多个浏览器，这没有问题。而且 m c p 的 效率实际上是可以配置的。你可以允许或禁止这些工具，并根据需要进行选择。 在这方面，他稍微需要更多手动操作。此外，从历史上看， m c p 默认是被添加的。所以总结一下，如果你在使用编码代理，如果你的任务是编码测试，你再用 close gitop compile， 你 可能更想用 c r i。 另一方面， 如果你正在创建一个能够执行特定任务的代理循环，用于你的场景， m c p 依然是首选，大致就是这些内容。祝你测试顺利。

c r i 为什么一夜爆发？这个视频给你一次讲清楚。

我用飞速四幺 i， 一 行命令就可以导入几百条数据到多维表格，还能在飞书里直接用它画逻辑图，效果非常棒。用 open 四幺 i， 我 可以自动抓取网站数据，比现在的 m c p 方案还有爬虫方案都方便很多。 不止是这些，每天用的 action 工具、写代码、跑任务、操作各种软件，它们的执行入口几乎都落在命令行上，或者至少借用了 gli 的 这套执行方式。命令行在一九七零年就已经存在，为什么到了二零二六年，最前沿的公司都在用它？是什么原因导致了它在 action 的 时代又重新被选中了呢？ 为了回答这个问题，我从头学习了它的整个逻辑，它是怎么来的？为什么是现在这个结构？我花了一周的时间把整个脉络都给整理清楚了。如果把这个问题压缩成一句话，其实就三件事情， c r i 在 软件世界里到底在哪一层？ 为什么在 it 的 时代重新又变得重要，以及现在它正在被重新设计成什么样。 c r i 最早要解决的不是界面体验，而是让人把命令准确的交给机器。 很多人一提到 c l i， 脑子里先出来的是黑窗口、程序员专业工具，于是很容易把它理解成一种不够友好但很高效的界面。但回到他最早出现的场景，你就会发现，他一开始面对的就不是体验优化的问题， 而是一个更基础的问题，人怎么把命令准确的交给机器？ c l i 的 全身是 command line interface， 中文意思就是命令行界面。我接下来这一段不单单是为了补一段计算机时，更是为了回答一个问题， 为什么 h 的 时代没有重新发明一个新接口，而是又撞上了 c i？ 如果把过去和现在并排看，会更容易看清这个事情。 我们的执行者变了，题材变了，但中间的这层要求是没有变的，动作要能够明确的交出去，结果要能立刻拿回来，多个动作要能连续的接起来。 更早的人机交互、打孔、卡纸、带开关、面板，这些东西是能够把信息送进机器的，但反馈不会立刻回来， 更谈不上持续来回交互。直到终端和打字机的出现，人和机器才形成了第一次输入一句立刻就能看到结果的实时回路。正是在这个节点上，问题才真正升级成现在可以实时交互了。人到底该怎么把动作清楚的交给机器呢？ ai 就是 在这个问题下形成的， 最自然的办法就是把要做的动作压成一行命令，命令词是什么以及对象。这个公式听起来很简单，但他把一个关键结构固定了下来， c l i 它是一个命令文本，不是命令本身，它负责把动作交给程序，再由程序去调用底层的能力。这就让 c l i 很 早就备了我们之前提到的三个重要的能力， 把动作交出去，把反馈拿回来，把多个动作接起来。后来， g u i 又出现了。对于普通人来说，按钮、窗口、图标、菜单都比 g 命令轻松的多。人更擅长视觉识别，不擅长回忆，精确的制服串， 很多状态如果能看见，也就比文字想象的要容易。所以在这个层面上， g u i 真正解决的是降低操作门槛，把状态直接展示出来，让很多非技术用户也可以用计算机。 它替代的是 c i 的 前台位置，而不是它的结构优势。 c i 更像先想清楚再输入， g u i 更像先看见再操作。前者不一定友好，但他在动作、表达、结果、返回步骤、串联这三件事上一直更强。 这也就是为什么到了 g u i 时代， c u i 并没有消失。像 get 这样的工具，到了今天仍然主要运行在命行上。普通用户把计算机前台交给了 g u i， 专业世界一直把连续动作和组合动作交给了 c i。 如果要用三个证据把这段历史收入，可以记住三个词，第一个是 r n， 说明 c i 最基础的结构就是命令参数对象，从一九七零年代到现在，一直都没有变过。 unix 说明了 c i 为什么能活这么久。不是没有人想替代它，而是因为 unix 给了它一道生存哲学文本，进文本出每个命令只做一件事，命令之间能够接点起来。 d t 证明了 g u i 到来了以后， c i 也没有死，它在专业世界里面一直承担连续动作和组合动作。 这段历史说明的不是 c l i 很 古老，而是它一开始就是执行层。为什么到了 action 时代，又轮到了 c l i 呢？理解了 c l i 最早是怎么诞生的，我们再回看今天的软件世界，会发现两个方向正在往同一个地方收敛。 一方面是模型测 ansible， 把 agent 的 执行入口落到了 c l i， 做出了 cloud code。 随后 open ai 的 cortex c l i gemini gemini c l i 也在往这个方向推进。另一侧是软件测平台能力开始被重新包装成命令入口。飞书有飞书， c l i， 网页和平台能力被 open c l i 这类项目重新翻译成命令， 最后都落在 c l i 上面。不是巧合，而是因为软件世界多了一个新的执行者 agent。 过去的软件结构都是只能通过 c l i 或者 g o i 操作软件，现在变成人提出目标 agent 拆任务执行修正。 agent 不是 聊天机器人，他是一个真正能够把动作做出去，把结果拿回来的执行者。一旦执行者从人扩展成了人家 agent， 最先被摆上桌面的就不是聊天能力，而是执行层怎么组织。因为 agent 一 开始真正工作，就会碰到四个问题， 命令怎么送进软件执行结果怎么拿回来？出错了以后怎么继续修正？多个动作怎么串成一条链？我们可以看到， c i 正好是那个最成熟的答案，不是因为它最新，而是因为它在这件事情上一直积累最深。听到这里，很多人会混淆 api 和 c i 的 概念，两者的站位不同。 api 它是一个应用程序的接口，是软件原始能力的一种包装。比如非书把读写表格、发信息、管理文档这些能力开放成 api， 供其他程序调用。 c i 往往是 api 上面的一层包装，它把健全参数、拼装分页、错误处理这些复杂细节分装掉，最后对外暴露成一条命令。 但 c u i 又不总是 api 的 包装，像 i m l s c p 这类命令，背后直接连的就是本地操作系统，不是远程的 api。 所以 更准确的说法是， c u i 是 站在能力层上面，把能力包装成一条条可执行的命令。 这个能力层可以是远程 api， 也可以是本地程序。理解了 api 是 什么，我们就要问一个问题，为什么 agent 的 执行层会先收敛到这里？我们先聊为什么 agent 的 执行层是落在 c u i 而不是 g u i 和 api 上？原因有三个， g u i 对 人很友好，对 agent 却很别扭，人看按钮一眼就知道该点哪里，但但 agent 要操作 agent， 通常得先截图识别界面定位元素，再模拟点击，视觉成本非常高。裸 api 只是另一种极端，能力最强但很散，健全参数、拼装、分页、重试 以及等等的措施都得自己全部处理掉。 agent 和裸 api 直接打交道，等于每次都给他还定的零件，但 ceo 正好刚处在中间。他比 g u i 稳定，因为接口是文本，不是界面。 哈比罗 api 省事，因为脏活，已经被命令行分装好了。第二个是大模型，天生会 c l i， 大 模型的训练与料理充满了命令行指令。我们看到 github 上有很多安装说明，构建脚本到处都是 c l i 模型，模型不需要从零学习怎么用命令行，它对这种范式天然熟悉， 往往比在一堆互不相干的工具里做复杂选择更稳。命令调用是在一个相对统一的文本格式里做组合，而韩式调用常常是在一堆结构各异的接口里切换。第三个是 ci 的 unix 哲学，刚好符合 agent 的 工作方式，很早就把 ci 的 底层逻辑定了下来。 每个程序只做一件事，程序之间能够互相协作，用文本流做通用接口，这三件事刚好就是 agent 最需要的三件事。 文本是模型的母语输入，也可以是文本命令，也可以是文本结果错误信息，或者 jason 输入输出通道稳定正常结果。它有一种标准输出错误，也有标准的错误输出成功或失败，也有退出码，表示每个命令只做一件事，但多个命令可以接起来，形成一条工作流， 不管是新命令还是老命令，结果都是一样的。工具动作对象，像之前的命令里的话，这里还会有一个参数的类型， 我们通过管道就可以实现功能组合。比如说像这个就是阅读能力，它能读取文件里面的所有内容。这个斜杠之后，我的这个 grab， 它就是过滤内容。 c， 它就是进行统计， 最后它能够把三件事情通过一个管道接成一条线，输出一个最终的结果。这就是 a 型的最擅长的连续动作。拉数据，填数据，出表格，一步接一步， 他不只能执行，还能够根据结果直，还能够根据结果继续修正。拉数据，发现格式不对，就先转格式，再继续填数据，发现字断缺了，就先补字断，再填上。看一步修一步的循环，正好和 c l i 的 及时反馈机制要合在一起， 所以这一节的解路人可以落在这里，执行成一档组合， c i 仍然是最成熟的汇合点。这时候我们再把 m c p 放进来，它和 c i 有 什么关系呢？ c i 和 m c p 都站在 i g 的 能力和底层能力的之间，但处理同一件事情的方式很不同，用同一个任务来看最清楚。 比如从非数据表格里拉出来一批记录，两者在三件事上有明显的区别，怎么发现能力怎么调用？能力怎么回来？ c r i 路径下， agent 必须先知道有什么命令，它才能够生成这种制服串，自动执行这个命令，然后把结果返回给 agent， agent 读文本决定执行下一步。但如果 agent 不知道有 luck c r i 这个命令，这条路就会行不通，它连命令都不会生成出来。但 m c p 路径它有一个优势在于它会主动告诉 agent 我 有什么样的能力。 cp 的 server， 他 会主动把自己的能力清单推送给 agent。 第二个是调用组合，比如我们制定那个任务是读日制，找出错误行，统计一共有多少条，我们这里就有三个任务了， 对吧？ c i 模式下，他只要写一个命令就好了。 m c p 模式下，他每调用一次都是执行一个工具，也就是要等三次，就非常的浪费时间。第三个维度是数据类型， c i 的 通道是文本流，文本进，文本出，这是 unix 五十年前就定下的规矩， 与日制代码配置文件这些文本内容。这套模式非常高效，但如果要去处理一张图片、音频数据库查询的文本的管道就成了瓶颈。 m c p。 的 结构化调用，它就没有这个限制，能够传二阶式数据带类型的返回值就非常方便。第第四个维度是安全性， c i 里面都是制服串，爱情的，拼出来的参数是对是错，只有执行了才知道，万一拼错了，数据命令执行失败，可能导致电脑里面的文件都没了， 但 m c p。 在 调用前就会拦住这些问题。每个工具都有具体的类型定义，协议层会在执行前叫验，填错了就当场报错，不会把错误命令带到执行环节。这里还额外提一句，参与验证只能减少错误调用，不代表 m c p 就 安全了，真正的安全还是要靠权限控制、纱窗隔离、服务砖的一些策略来进行。 这个维度看下来， m c p 和 cl i 的 差别可以归成一句话， cl i 看起来更省事，不用写很多的条件。 agent 可以 直接上手，但它有大量的演示前提，比如说我们当前是在哪个文件夹下面，环境变量是什么吗？安装了什么样的工具，这些都会影响到命令的执行结果，但 agent 都不知道。 m c p 虽然看起来笨重，但它有工具描述、定义、参数类型，注注上下文。正因为这些都写出来了，执行前提是显性的输入是可逾期的，出了问题也更容易定位。所以总结来说， c i 省的是显示说明，增加的是隐私的不确定性，而 m c p 是 恰恰相反。 而 c 幺 i 和 m c p 其实正在互相靠近，两者都在弥补对方的短板。 c 幺 i 这边开始变得更加结构化，像 open c 幺 i， 它也提供了机器可以读取的命令清单，包括 skills， 可以 给 agent 去说明他有什么样的命令，让 c 幺 i 不 再指示你得先知道有什么。 而 m c p 这边也变得更加可以。组合收比特的 go 的 形式，让 agent 不 再一次只能调用一个工具， 而是直接写一段脚本，把多个 m c p 工具串联起来，一次搞定原本需要多次调用的练习操作，两者都在往中间走，但并不意味着它们会合并成一个东西。 管道组合和结构化调用仍然是两种不同的架构。拿 cloud 来说，它的内置能力全在走 c i i 路线，外部的服务全在走 m c p。 日常使用当中，大约有百分之七十的工作由 c i i。 完成，百分之三十由 m c p 完成。 底层继续调 c l i， 外层继续调用 m c p。 那 这里我们可以看一下未来 c l i 不是 原封不动的回来了，他正在被重新设计。 c l i。 重新重要以后，事情并没有结束。他遇到了我们刚刚想的两个问题。 第一个， it 的 不知道当前环境里有哪些 c l i 可以 用。 c l i 原本是给人设计的程序员知道有 git、 docker 或者 im 能干什么，所以他们学过用过。但如果装了一些新开发的 c l i， 他 并不知道命令具体怎么用。 第二个是很多平台，它没有 api， 也没有 c l i。 大 量的能力被锁定在网页里，我们只能够点着用，不能够调用。对 agent 来说，这些能力就像隔着玻璃，看得见摸不着。围绕着这两个问题， c l i。 正朝着两个方向演化。第一个方向，把已有的 c l i 更好地暴露给 agent。 这是这是我在叉上看到一篇很好的文，技术文章 c l i is all agent。 他的方向不再是发明一对新接口，而是围绕已有的 c l i。 做两件事情，给 agent 一个统一的入口，不让，不让他在满世界找命令，把执行结果整理成 agent 可以 看得懂及其角色的样子。 这样以来， c r i 就 不再只是你知道命令才能用的专家工具，而是变成一个可以配合 action 的 持续循环工作的工作台。如果大家感兴趣，可以去看一下这个原文。而之前挺火的 open c r i 则是抓住了第二个问题， 他处理的不是已有的 c i 怎么被发现，而是原来没有 c i 的 平台怎么重新变成 c i。 以前我们想从某个平台拿数据，往往得自己打开网页找命令点按钮导出。 open c i 做的就是把这些点着完成的动作重新打包成命令。原本所在网页里面的能力能够被重新的命令式调用。 更关键的是，它不止提供了命令，还提供了机器可以读写的发现方式。像这几个命令，都是让 agent 能够去发现它有什么样的工具的。这意味着它在解决第二个问题的同时，也顺带解决了第一个问题。命令不再是给人看的，也开始给 agent 看的。 当然，我相信 open c i i 它也不是终局，它先解决的是把平台能力翻译成命令，而不是把所有底层动作拆分的很细，让 agent 任意拼装， 但它也说明了方向。 c i i 的 边界正在扩张，它不再只代表本地电脑的能力，也开始代表网页、平台和远程服务。把两条线和之前一直存在的传统 c i i。 合在一起看，今天的 c i i 至少长成了三个样子，工具型、平台型、 agent 的 型。 工具型的 c i i。 一 直都在继续承担专业世界里面的连续执行。平台型 c i i 把分散在网页里和平台的能力重新包装成命令，这是软件的型 c i。 表面输入可能是自然语言，但底层调用的仍然是 c i， 这是模型测手点的结果。三种形态看起来很不一样，但它们站的位置其实相同，都在执行层。下次看到一个 ai 相关产品，我们可以多问一句，它的能力暴露到哪一层？是在 g u i 还是 api， 还是 c r i？ 还是它已经走到更远了，组装成了一个 skill ci 还有一个没有展开的能力，它能够极大地增强 agent 的 skills 体系。下篇文章我打算做几件事情。第一个是 ci 它怎么从零做出来，以及它怎么跟 skills 配合，让 agent 的 边界能够再往外推一层。

不知道大家有没有想过，为什么到二零二六年的今天， cli 这个概念似乎又变得如此火热了？ 那其实先介绍下什么是 cli 吧，其实 cli 就是 一个命令行，就比如说我这是一个 macbook， 那 我的命令行呢？就是长这个样子，我可以通过手敲一些命令，去实现一些我所需要的功能， 它包括像文本输入啊，结构化输出等等，那它的地位呢？其实就相当于 ai 界的一个母语。那前段时间可能有两个这个开源的项目比较火啊，一个叫， 一个叫 c l i anson， 一个叫 open c l i， 那 分别对应的这个 github 的 样子就是这就是这里。那 c l i anson 呢？它其实就相当于把开源的软件可以变成这个命令行可以控制的这种方式的工具。 那 open c l i 呢？其实就是想能够将桌面的应用以及网站转换为 c l i， 就是 可以让我们的 ai 更好的去操控这些网站，这就是它们两者的一个区别。 那 c i 那 么火，那像去年，去年可能大家都使用 m c p 去控制我的这个工具，那现在呢？大家可以发现 ai 可以 直接通过命令行 ci 去控制我们的这个。 嗯，工具，比如说前段时间飞速不就开源了自己的这个 c l i， 那 我其实总结了以下几点呢？比如说像 c l i 的 优势，它比如它比较消耗，投投坑比较少，那对人类也比较友好。那像 m c p 呢？它可能说 更加标准，那对于多用户或者权限控制比较强，那 对于我个人而言，我其实觉得 c l i 才是未来的一个趋势，你像 ai 天生不太适合去控制这种可式化的这种界面，就是 g u i 嘛，那 c l i 可能更适合 ai 一 点，所以说为什么管它叫 ai 界的这个母语？

最近技术圈有个很火的说法， m c p。 已死， c l i。 当利听起来很像王朝更替啊。其实本质上只有一个问题， ai 智能体调用外部工具，到底该走标准协议，还是直接走命令行？如果你只是做本地开发，或者做个人 ai 助手， b l i 往往更务实。原因很简单，大模型在训练数据里 见过大量的命令行势力对 c l i。 的 模式非常熟悉，生成命令成功率很高，执行完就退出，不需要长驻服务， 轻量直接成本低。但这并不意味着 m c p。 过时了，一旦进入企业场景，多人协助，全线隔离 操作，审计可追溯日制，这时候标准化协议的价值就会放大。 c l i 解决的是能不能跑，而 m c p 解决的是怎么管控。其实呢，这场争论背后是工程师和架构师视角的差异。工程师关心的是效率、 灵活、快速落地，而架构师关心的是边界安全、治理成本。两边都没错，只是所处的成绩不同。所以与习真谁替代了谁？不如承认一件事，单兵作战用 c l i 组织协作用 m c p。 技术选型从来不是战队问题，而是场景问题。

嘿，大家好，今天我们来聊个特别有意思的事，你知道吗？有项技术，那可是跟计算机差不多同岁的老古董了，但最近呢，它居然又火起来了，简直就是迎来了第二春。 你看看，就在最近这几周，发生了个怪事，像谷歌、 stripe 这些国际大厂，还有咱们国内的飞书钉钉，你猜怎么着？它们像是商量好了一样，全都推出了同一种东西， 这就很奇怪了，对吧？到底是什么产品能让这些巨头们这么心照不宣呢？答案来了，就是命令行工具。没错，就是那个黑乎乎的窗口敲代码的那个东西，我们通常叫它 c l i， 是 不是有点反之学你想想，这些公司个个都是技术浪潮的弄潮儿，结果呢，他们竟然齐刷刷地掉头去拥抱一个看起来特别复古的技术，这太有意思了。 所以，这就引出了我们今天真正想搞明白的问题，为什么？为什么这些大公司要集体给一项诞生于上世纪七十年代的技术投下重注？ 到底是什么让这个几十年前的老家伙在今天在 ai 时代突然变得这么关键，这么不可或缺了呢？好，要想解开这个谜团，我们得先明白一个最根本的区别，就是咱们人类和 ai 跟电脑打交道的方式，那真是天差地别。 你想啊，咱们觉得好用的东西，对 ai 来说，可能，嗯，完全是另一回事。来，我们看个超直观的例子，就说剪视频吧，要把一个视频的前五秒给剪掉。 咱们人类会这么做，肯定是打开剪辑软件，用鼠标把视频拖进去，找到那个时间点，咔嚓一剪，然后再点导出，你看点点拖拖好几个步骤。 但 ai 呢？它就完全不一样了，你看右边，就这么一行命令， ffmp 什么的，啪一敲，回车搞定，干净利落、精准，没有任何废话， 所以这背后的关键点就呼之欲出了。命令行界面，也就是 coi， 它简直就是 ai 的 母语啊！ 你想想这些大模型是怎么训练出来的？他们可是吃了海量的代码和文字长大的，所以他们天生就能看懂，也最习惯用这种基于命令的语言来沟通。这种语言结构清晰，指令明确，而且最重要的是特别容易自动化。 好！既然 c o i 对 ai 这么友好，那问题就来了，现在市面上成千上万的软件，可都是咱们人类用的图形界面啦！怎么办？怎么才能让 ai 也能用上这些工具呢？ 别急，最近就出现了几个项目，简直就像是给软件世界施展魔法的魔藏，它们就是来解决这个问题的。 没错，就是这两个项目，它们是这股潮流的领头羊，一个叫 clean anything， 另一个叫 open c l i。 你 听听这名字多霸气！ 它们的目标啊，说出来你可能不信，就是要让世界上任何一个软件，不管它是新的还是旧的，都能被 ai agent 调用和操作。 咱们先来看看这个 curly anything 是 怎么变魔术的，它的工作方式说实话非常惊人， 你啥都不用干，就把一个软件的原代码扔给他，然后好戏就开始了，他自己会去分析代码，自己规划需要哪些命令，自己生成一个全新的命令行工具，甚至连测试和说明文档都给你写好了， 最后一个为 ai 量身定做的命令行版本就这么诞生了，整个过程从头到尾都是 ai 自己在搞定。 咱们来举个实在的例子，就说 java 吧，大家可能都用过，画流程图什么的，全靠鼠标拖拖拽拽，这东西对咱们来说挺方便，但对 ai 来说简直就是噩梦。 你想让一个 ai agent 在 屏幕上精准地拖动一个小方框，再画一根线连到另一个框上，那可太难了。 但是经过克雷安尼清这么一改造，你猜发生了什么？现在 ai 只需要一行命令，就能让 jio 乖乖地画出一个完整的流程图。这个转变简直是天翻地覆，他直接把那些复杂的、需要手眼协调的视觉操作变成了一行简单的文字命令。 另外一个工具 open club 呢，也同样厉害，它专门对付网站和桌面应用，有了它， ai 就 能像个真人一样，用几行命令就能去招聘网站上帮你找工作，或者去 hack news 上看看今天有什么热点新闻，是不是很酷。 其实啊，大家这么追捧 c r a， 不 仅仅是因为它好用，这背后其实是一场关于 ai 未来的路线之争。争论的焦点就是 ai agent 到底应该怎么去使用外部的各种工具。 以前的主流方法叫 m c p， 你 可以把 m c p 想象成 ai， 出门前你得把它可能用到的所有工具连同说明书，一股脑全塞进它的大包包里。而 c r a 呢，它提供了一个完全不一样的思路， 我们从这个时间线上就能看出来整个行业风向变得有多快。你看今年年初那个火到不行的开源项目 open interpreter， 人家一上来就说了我们不支持 m c p。 然后没过多久，三月份 ai 搜索领域的明星公司 perplexity 也官宣了，我们放弃 m c p， 全面拥抱 c i。 这一下子开发者社区就炸锅了，甚至有人直接喊出了 m c p 已死， c i 永生这样的口号。 那为什么大家突然就嫌弃 m c p 了呢？这张对比图说得很清楚。首先， m c p 太费钱了，也就是偷看沉稳太高，因为它得把所有工具的说明书都提前读一遍，你说这得多为什么？第二，它就像个黑箱，一旦出了问题，你都不知道去哪儿查。 最后一点， m c p 里的工具都是各玩各的，没法像乐高积木一样自由组合起来干一件大事儿。 咱们再具体看看这个 token 成本，这一点真的太关键了。有家叫 scale ai 的 公司，用 gehub 的 官方工具做了个测试，结果发现要完成同样一件任务，用 cli 的 消耗大概只有 mcp 的 十五趴。 你想想看，这是什么概念？这可不是省了一点半点，这是数量级的差距啊，省下来的可都是真金白银，而且还能让 ai 的 反应速度更快。 而且 c i i。 还有一个独门绝技，一个 m c p 完全没有的超能力。这个东西叫管道，英文是 pipes。 这个概念真的非常非常强大，它就像一条流水线，你可以把好几个命令串联起来，第一个命令处理完的结果直接就丢给第二个命令，接着处理，这样一步步下去，最后用一行命令就能完成一个复杂的工作流， 你看这个例子就特别能说明问题，就这么一行，命令他干了四件事。第一步，先把 github 上所有的遗属都列出来， 然后通过那个竖线，也就是管道符把结果送给下一步，筛选出所有带 bug 标签的，接着再把筛选结果送去排序，最后把排好序的结果直接存成一个 csv 文件，你看，一气呵成，多么优雅。 当然了，说了这么多，也不是说 c l i 就 完美无缺， m c p 就 一无是处。技术的发展嘛，从来都不是简单的谁干掉谁。我们现在看到的更像是一场进化，双方都在取长补短，互相融合，一起塑造 ai 工具的未来。 所以啊，现在这两条路线的界限其实已经开始模糊了，你看，大家都在互相学习。一边呢，像 cloud 这种顶尖的大模型，开始给 m c p 加上工具搜索的功能，这不就是学了 c i 那 种随用随取，降低成本的思路吗？ 另一边呢，社区里也有大神在开发像 m c p compiler 这样的工具，作用刚好反过来能把 m c p 的 工具转换成 c i 的 格式来用。 所以说， c i 的 这次回归，绝不仅仅是一次简单的文艺复兴，它的背后代表的是我们和 ai 写作方式的一次根本性的变化。 最后，我想留给大家一个问题，一个可以好好畅想一下的问题。如果未来任何软件，不管它有多复杂，我们都能用一行文字来指挥它，那我们又能创造出怎样不可思议的东西呢？

我是木木，去年 m c p 是 agent 的 智能体调用外部工具的明星，但今年， co i 将成为 agent 的 调用方式的核心焦点。 co i 就是 命令行界面。不同于 g u i 图形用户界面， co i 要求用户像说话一样，在终端中输入特定的命令来执行任务。它是 g u i 的 前身，更适合开发者使用的跟机器交互的方式。 c o i 的 再次风红，因为在 agent 的 时代，软件不仅是要让用户使用，更是要让 agent 能更自然地理解。和调用 c o i 相比， m c p 能让 agent 任务执行得更准，头肯消化得更低。 最近，企业微信 c o i 开源已上架到 geekup 社区，其 v c i 覆盖通讯录、代办会议、消息、日程、文档、智能表格等核心业务领域，提供七大品类和十二个 skills， 支持住五六 a 型的调用，比如 cloud code codebox、 workbody、 q cloud 等。安装也很简单，前提是使用 node js npm 的 环境，在启维管理后台创建智能机器人，并获取长连接方式下的 botid 和 secret， 然后在终端中输入安装 cio 的 命令，以及安装 cio skill 的 命令。安装成功后配置启维机器人凭证，也就是出厂命令输入机器人的 botid 和 secret， 这样就安装完成了。我们用 help 命令可以查看启维 cio 所有的调用能力。 品类调用可参考这两个命令方式，每个品类作为独立子命令使用。不传方法名时，列出该品类下所有可用工具，传方法名时调用指定工具。我也测试下在终端中调用企微 c o i 的 执行情况。在 agent 的 skill 中，我最常用的是文档能力，我给了它两个指令，创建一份名叫 c o i 解释文档，然后编辑文档，填入内容。 他果然在企微文档中给我创建了这份文档，并将内容引入其中。这样我的 agent 在 搜集产品信息后，能自动调用这个 c o i 并保存整理内容。在企微的龙虾 agent 中，经常要创建日程预定会议记录。代办 起微， c o i 也执行了很多 bug， 这即将任务精准地完成了，并且给指定的用户和群聊发送了消息，这也都是办公 a 技能中必备的技能。此次开源，起微优先面向十人及以下企业开放。在 a 键的时代，软件正从给人使用的功能进一步变成可被 ai 调用的能力， 起微也将变成更适合 a 键的任务执行的入口。在办公和效率场景， ai 将更自然地串起分散的操作，并以极高的效能工作。记得点赞关注哦！

m c p 到底死了没有？别急着下结论，今天我用实打实的数据来为你彻底拆解 c i l i 和 m c p 的 终极对决。从 scale kit 的 精准测试，到 open call 的 安全彩案，再到企业级架构的选型，这不是什么宗教战争，而是一场有数据支撑的技术分析。 欢迎来到路上学 ai， 我 们的频道专注深度解读 ai 工程实践。不黑不吹，所有观点背后都有数据和案例来支撑。如果你觉得有收获的话，请帮忙点赞、关注，还有转发，我们一起进步。 首先来看 token 效率站，这是 scalekit 在 二零二六年二月发布的精准测试结果。注意了，这个测试条件完全一样， 同样是连接 github， 同样是 cloud sony， 四、同样的任务，那结果如何？使用 mcp 需要四万四千多个 token， 而使用 c i i 仅仅需要一千三百六十五个 token。 大家注意，这可是整整三十二倍的差异。为什么差这么多？原因其实很简单， 因为 github 的 mcp 服务器一共暴露了九十三个工具，而按照 mcp 的 设计，每次调用的时候的完整定义都会被注入到模型的上下文里面。 也就是说，即使你只用到其中一两个工具，模型也得在脑子里装着其他九十一个工具的定义。反观 c l i 就 完全不一样了。 c l i 的 g h。 命令模型在训练的时候就已经学会了，不需要任何额外的 steamer 开销，所以说结果就是整整三十五倍的成本差异。 再来看可能性， c i l i 的 成功率是百分之百，而 m c p 只有百分之七十二，因为有百分之二十八的请求在网络超时了，那这意味着什么？算一笔账， 如果每个月跑一万次操作的话， c i l i 的 成本大概是三块两毛钱，而 m c p 要五十五块钱，而且还不只是钱的问题，每一个被用来加载工具 schema 的 token 都是从模型的推利空间里扣掉的，也就是说， schema 占得越多，留给模型真正思考的空间就越少。 接下来我们来看第二个角度，那就是为什么 a i。 天生就会用 c i l i。 这不是巧合，背后有三个根本原因。首先是训练数据的优势。你想想看 l l m 的 训练数据里面充满了什么？ stack overflow 上的 bash 脚本， github 上的 shell 命令，还有各种 main pages 文档， 加起来是数十亿行的真实终端交互。所以说当你问 cloud 怎么用 git 的 时候，他早就知道了，完全不需要任何引导。其次是自文档化的能力， c i i 工具本身就是可以自我解释的，比如说你只要运行 g h issue， 加上 help 这个参数， 一秒钟模型就学会了这个命令的用法，不需要 steamer， 也不需要类型定义，更不需要额外的 token。 第三是 unix 的 可组合性 小工具，加上管道，加上标准输入输出，这就是 unix 的 核心哲学。而这个哲学和 agent 的 思维方式完全一致， agent 的 工作逻辑也是先获取信息，再处理数据，最后采取行动，这不就是管道的逻辑吗？没错，这就是 unix 的 力量。 那反过来看， m c p 就 不同了， m c p 是 运行时才出现的全新 steam 模型，在训练数据中从来没有见过这些工具的定义，所以说每次调用的时候，模型都得先理解这个陌生的抽象层，然后才能去执行任务，这就是额外的认知负担。 不过这里有一个关键的转折，那就是 m c p 为什么不能死？答案就藏在一个核心问题里，那就是你的 agent 到底代表谁在行动？ 我们来看两个完全不同的场景，第一个场景， agent 代表的是你自己，比如说你在用 cloud code 写代码， agent 帮你运行命令， 在这种情况下， c i i 就 完全够用了，效率最优，成本最低。 agent 继承的是你的 token， 就 算出了问题，后果也只涉及你一个人。但第二个场景就完全不一样了，如果 agent 代表的是你的客户在行动呢？ 举个例子，想像一个项目管理平台，用户 a 说帮我从 github 创建一个 giga ticket， 然后发消息到 slack， 与此同时，用户 b 在 另一个组织也在用这个平台。那么问题来了，怎么确保 a 的 数据不会跑到 b 的 系统里去？怎么确保只能访问自己有权限的那些 github 仓库和 giga 项目？ 还有怎么确保每一个 agent 的 行动都可以被审计追溯到具体的用户？这就需要三层身份隔离了。第一层 agent 身份，也就是哪个 agent 在 行动，用来做限流和防止滥用。 第二层用户身份，也就是哪个用户授权了这个操作，这是通过 oops go 来控制权限的。第三层租户身份，也就是这个用户属于哪个组织，这决定了数据隔离和信任边界。那如果用 c i l i 来实现会怎么样？ g h off login 给你的是一个 token， 一个 token 对 应一个用户，那要支持多个用户怎么办？还要支持多个组织怎么办？那你就得在应用层自己管理 token 交换，还有 token 刷新以及权限检查。说白了，你就是在手工重建 oof， 而这恰恰就是 mcp 的 设计目标， mcp 内置了 oof 二点一的支持，每个用户都能通过 grant scope 来限制， agent 能做什么，而且每个组织的数据都是隔离的。 接下来我们还要看 c i l i 的 另一面，那就是安全隐患。二零二五年的 openclaw 事件就是一个血淋淋的教训。先说背景， openclaw 是 一个很流行的 agent 框架，允许 agent 执行任意的 shell 命令，结果出了大事。 首先，一万多个暴露的实力凭证和 api 密钥全部泄露到了互联网上。其次，百分之十二的社区开发的 skills 被发现是恶意的，会偷偷把数据外赚。更严重的是，七十七万个 agent 因为一个漏洞可以被远程劫持。 为什么会出这么大的问题？根本原因就是两个词， m b n credentials 加上 arbitrary execution。 也就是说，用户的 a w s 密钥和 github token 就 躺在本地环境里，而 agent 可以 运行任意的 shell 命令， 没有协议边界，也没有权限检查，这就是架构级别的隐患。那 m c p 的 设计是怎么解决这个问题的？ 首先是显示的工具边界， agent 只能调用你事先声明过的工具，不能随便 curl 任意 url， 也不能随便访问文件。其次是结构化的审计追踪，每一个工具调用都会被完整记录下来，包括谁发起的什么时间，以及返回了什么结果， 这些信息都是可以被查询和审计的。第三是基于用户的 oos 隔离，不是 agent 拿着你的 token 到处跑，而是 agent 代表特定的用户，用特定的权限来操作。 所以说这就是为什么 mcp 更贵，因为它的设计从一开始就是为了安全。这里划重点，便宜的背后代价就是风险。那么说了这么多，终极答案到底是什么？其实不是说西安娜好还是 mcp 好， 而是应该用混合架构。具体来说有三种方案，第一种 c i i 加上 skills， 这是开发者工具的最优方案，效率最高，成本最低，有整整三十五倍的优势，适合的场景就是你自己，就是最终用户，出了问题也只影响你自己。 第二种是 m c p direct 直联模式，当你的 agent 需要代表客户来行动的时候，就需要这个了，因为你需要 oof 授权，需要租户隔离，还需要审计追踪， 成本确实是 c i l 的 四到三十二倍，但换来的是治理能力，这个方案适合中等规模的 b two buss 产品。 第三种是 m c p gateway 网关模式，这是企业级的终极方案，具体来说就是在 agent 和 m c p 服务器之间加一个 gateway 网关层，它做三件事， 首先是 schema 过滤，不是把所有九十三个工具定义都注入进去，而是只注入当前任务需要的两三个，光这一步就能减少百分之九十的 token 开销。其次是连接值， gateway 维护持久连接，帮你吸收那些超时失败 可信，从百分之七十二直接提升到百分之九十九。第三是集中认证 gateway 统一处理， oops token 的 刷新，全线检查以及审计日制。所以说最终结论是什么？这不是 c i i 更好或者 m c p 更好的问题，而是谁在用你的 agent。 如果是你自己在用，那就选 c i l i。 如果是你的客户在用，那就需要 m c p。 如果是企业级多租户场景，那就上 getaway。 选择对的工具，匹配你的架构，这才是正确答案。总结一下今天的核心观点， 从效率角度看， c i l i 赢了整整三十五倍的成本优势。从架构角度看， m c p 不 可替代，因为多用户隔离离不开它。 从实践角度看，混合方案才是最优解，要根据具体场景来选择。所以说， m c p 没有死，它只是被用错了地方，而 c l i 也不是银弹，它只在特定场景下才是最优的。 路上学 ai， 我 们下期再见！如果你觉得这期有帮助的话，请帮忙点赞、关注，还有转发！

给 ai 使用的 c l i 和 m c p 到底有什么区别？其实 c l i 是 命令店界面，像 git clone and install。 你 得记住，命令按步骤来精确，但学习成本高。而 m c p 是 模型商业型工艺，用大白话项目在 type stack ai 理解后，直接帮你做完所有步骤。最大的核心区别在于， c l i 是 由人给机器下达精确的指令，而 m c p 是 人描述意图，由 ai 自主执行。在实际工作中复杂的自动化本地调用使用 c l i 快 速开发与外界交互使用 m c p。