Xux Note

AI Agent 的三件套：CLI、MCP 和 Skill 到底是什么

Wed, 10 Jun 2026 00:00:00 GMT

AI Agent 的三件套：CLI、MCP 和 Skill 到底是什么

最近科技圈有个热闹事：钉钉、飞书、企业微信，同一周全都开源了自己的 CLI。

你可能想问：CLI 是什么？跟之前老听到的 MCP 有什么关系？还有个叫 Skill 的又是什么？

别慌，今天用一个比喻把这三样东西讲明白。

先从一个场景说起

假设你是老板，刚招了一个超级能干的实习生（就是 AI Agent）。你想让他帮你在钉钉上干活：发消息、查日程、建表格、安排会议。

问题来了：实习生刚来，他不知道公司用什么工具，也不知道怎么操作。

你得解决三个问题：

给他一个能操作钉钉的工具
让他知道自己手边有这个工具
教他什么场景用什么功能

这三个问题，分别对应的就是 CLI、MCP 和 Skill。

CLI：给实习生一套工具

CLI（Command Line Interface），命令行工具。就是你在电脑终端里敲一行文字，电脑帮你干活。

比如查今天的日程：

lark-cli calendar +agenda

比如给同事发条消息：

wecom-cli im send --text "周五下午开会" --to zhangsan

没有界面，没有按钮，全靠打字。

你可能觉得这也太原始了吧？但这恰恰是 AI 最喜欢的方式。因为 AI 最擅长处理文字，输入是文字、输出也是文字，非常对口。你让 AI 去操作图形界面，它得先截屏，再用视觉模型找按钮在哪，再模拟鼠标去点——本来一行命令搞定的事，拆成四步，每步都可能出错。

所以，CLI 就是实习生手里的工具箱。 扳手、螺丝刀、锤子，都在里面。他需要的时候拿出来用，不需要的时候放着就行。

MCP：在实习生桌上摆一排按钮

MCP（Model Context Protocol），模型上下文协议。名字唬人，但原理不复杂。

MCP 的做法是：提前把所有工具的说明贴在实习生桌上。"你能发消息""你能查日程""你能建表格"……每个能力做成一个按钮，实习生随时能按。

好处很明显：实习生不用四处找工具，一抬头就知道自己能干什么，直接按就行。

但有个代价：桌子就那么大。

AI 的"桌子"叫上下文窗口，大小是有限的。每个 MCP 工具都要在桌上摆一张说明卡。你接三五个工具，桌上还很宽敞。但你要是把钉钉、飞书、企业微信、GitHub、Slack、Jira 全接上，每个软件十几个功能，上百张说明卡往桌上一摊——桌子就被占满了，实习生连写字的地方都没有了。

而且工具太多还有个问题：实习生面对一百个按钮，选错的概率也会变大。

CLI 不一样。 工具箱放在柜子里，桌上不摆东西。需要的时候打开柜子拿出来用，用完放回去。桌子始终是干净的。当然代价是每次用之前得先翻一下工具箱看看有什么（跑个 --help），比直接按按钮慢了一步。

所以两者的核心区别就是：

MCP = 工具常驻在桌上。 随取随用，但占桌面空间。工具少的时候很方便。
CLI = 工具放在柜子里。 按需取用，不占桌面。工具多的时候更合适。

实际上，两者并不矛盾。钉钉和飞书都同时提供了 MCP 和 CLI 两种接入方式。能访问终端的环境（比如 Claude Code）用 CLI 更灵活，不能访问终端的环境（比如一些桌面端 AI 工具）就用 MCP。

Skill：给实习生一本操作手册

前面两个解决了"有什么工具"和"怎么让 AI 知道工具在哪"的问题。但还有一个问题：AI 知道有工具，不代表它会用好。

你跟 AI 说"帮我把会议纪要里的待办整理出来"，AI 得知道：先用什么命令读会议纪要？提取出来的待办该用什么命令创建？创建的时候需要哪些参数？出错了怎么办？

这就是 Skill 的作用——一本写给 AI 看的操作手册。

Skill 不是工具，它自己不干活。它告诉 AI：你有哪些命令可以用、什么场景该用哪个、参数怎么填、出了错怎么补救。

没有 Skill，AI 也能用 CLI，靠 --help 自己摸索。但这就像让新来的实习生自己翻工具箱说明书——能用，但慢，而且容易犯错。

有了 Skill，相当于给实习生一本经验丰富的老员工写的操作指南："遇到查日程的需求，先用这个命令；如果对方没说时间范围，默认查本周；如果报权限错误，跑这个命令申请权限。"

实习生拿着这本手册，上手就快得多，犯错也少得多。

而且 Skill 的设计也很聪明——它跟 CLI 一样是按需加载的。AI 的上下文里只放一句话的简介："你有一本操作钉钉的手册"。只有 AI 判断需要操作钉钉了，才会去翻开手册的详细内容。不用的时候，不占桌面空间。

三者的关系，一张图说清

你说一句话："帮我查下周跟张三的会议"
│
▼
AI 判断要操作日历
│
▼
Skill 告诉 AI 该用什么命令、参数怎么填
│
▼
AI 通过 CLI 在终端执行命令
│
▼
结果返回给你

整个过程里：

CLI 是执行层——实际干活的工具
MCP 是发现层——让 AI 知道有哪些工具可用
Skill 是指导层——教 AI 怎么用好这些工具

三者各司其职，缺一不可。

那我作为普通用户需要关心这些吗？

大部分用户不需要。

你用钉钉 AI 助手的时候，不需要知道背后是 CLI 还是 MCP 在干活。就像你用微信发消息的时候，不需要知道底层用的是什么网络协议。

但如果你是开发者，或者你想让 AI 帮你干更复杂的活，了解这三件套就很有用了。

比如，你想让 AI 帮你操作一个它没见过的软件。你可以：

给它装一个 CLI 工具（比如 github-cli）
写一个 MCP Server，把 CLI 的能力包装成按钮
写一份 Skill 文档，告诉它什么场景用什么命令

做完这三步，AI 就能像一个熟练工一样帮你操作这个软件了。

一个有意思的趋势

今年 4 月，钉钉、飞书、企业微信同一周开源了自己的 CLI。这不是巧合。

这说明大厂们终于想明白了：AI Agent 要真正落地，不能只靠聊天框。得让 AI 能实际操作工具，能干活。

而 CLI + MCP + Skill 这个组合，就是目前最实用的方案。

CLI 解决了"怎么干"的问题，MCP 解决了"干哪些"的问题，Skill 解决了"怎么干好"的问题。

三个问题一起解决，AI 才能从"能聊天"变成"能干活"。

我怎么看

我对这个方向挺看好的。

过去一年，AI 的能力提升很快，但"能聊天"和"能干活"之间一直有个鸿沟。很多 AI 产品停留在"你问我答"的阶段，真正能帮用户完成复杂任务的不多。

CLI + MCP + Skill 这套方案，就是在填这个鸿沟。

当然，它也有局限。比如 MCP 的上下文占用问题，比如 CLI 的学习成本问题，比如 Skill 的编写和维护问题。但这些都是工程问题，不是方向问题。

方向是对的，剩下的就是时间和迭代。

我个人最期待的是：当这套方案成熟之后，AI 就不只是一个"聊天机器人"了，而是一个真正的"数字员工"。你给它一个任务，它能自己拆解、自己找工具、自己执行、自己处理异常。

到那时候，"AI Agent"这个词才真正名副其实。

参考来源：唐巧的博客《AI 干活的三件套：CLI、MCP 和 Skill 到底是什么？》

AI Agent 的"安卓时刻"：当苹果、Meta、微软同时下注

Tue, 09 Jun 2026 00:00:00 GMT

过去一周发生了一件挺魔幻的事：苹果、Meta、微软，三家完全不同的公司，在几乎同一个时间点，都宣布把 AI agent 塞进自己的商业平台里。

6 月 4 号，苹果批准了 Poke 成为 Messages for Business 平台上第一个 AI agent。同一天，纽约时报发了篇长文，讲小企业主怎么用 OpenClaw 管理"一整支 AI 员工大军"。往前一天，6 月 3 号，Meta 宣布 WhatsApp Business 的 AI agent 全球上线，微软发布了 Project Solara，一个专门给"跑 AI agent 的设备"用的操作平台。

再加上 5 月底 Robinhood 开放了 AI agent 交易接口……

这不是巧合。这是趋势到了拐点。

从"能用"到"在用"

过去两年我们聊 AI agent，大部分时候聊的是框架、协议、能力边界。LangChain、CrewAI、AutoGen、MCP、A2A……开发者社区热火朝天，但普通用户基本无感。agent 对他们来说就是 ChatGPT 里那个能联网搜索的功能，没什么特别的。

这次不一样。苹果不是在做一个 agent 框架，它是在让商家通过 iMessage 用 AI 回复客户。Meta 不是在搞什么前沿研究，它是在让全球几千万 WhatsApp 商家自动处理订单和售后。微软更激进——Project Solara 的思路是以后设备上跑的不是 app，而是 agent。

你品品这个区别：以前是"开发者用 agent 写代码"，现在是"消费者在 WhatsApp 里跟 agent 买东西"。

各家的打法完全不同

这三家做 agent 的方式完全不一样，能看出它们各自在想什么。

苹果的方式最"苹果"，严格审核，封闭生态。Poke 是第一个通过审核的 AI agent，意味着苹果把 agent 当 app 来管。你得过审才能上线，用户体验必须达标。这很像当年 App Store 刚出来时的逻辑：宁可少，不能烂。

Meta 走的是另一条路。WhatsApp Business 本身就有庞大的商家基础，Meta 的做法是把 agent 作为商家工具的一部分直接塞进去。你不需要懂技术，开通就能用。这个策略很像当年微信小程序——降低门槛，让不懂技术的人也能用上 AI。

微软的 Project Solara 最有意思，也最冒险。它不是在现有产品上加 agent 功能，而是想做一个全新的平台，让硬件设备直接跑 agent 而不是传统应用。GeekWire 的报道说，这是微软想在"后手机时代"抢占的制高点。想法很超前，但能不能成，得看开发者买不买账。

Robinhood 那边更激进

金融圈的动作也不小。Robinhood 在 5 月底开放了 AI agent 交易接口，允许 AI agent 直接帮用户做交易决策和信用卡消费。

这个事情争议很大。让 AI 帮你写代码，写错了大不了重来；让 AI 帮你花钱，花错了可不是闹着玩的。但 Robinhood 显然赌的是：如果 agent 能处理足够多的日常金融操作，用户粘性会大幅提高。

我自己对这个方向持保留态度。交易决策涉及的风险评估太复杂了，目前的 agent 连帮我选外卖都经常选不好，让它管我的钱？再等等吧。

小企业主才是真正的受益者

纽约时报那篇文章让我印象最深的不是技术，而是使用场景。文章里采访的几个小企业主，用 OpenClaw 管理多个 AI agent，分别负责客服、记账、社媒运营、供应链跟踪。一个人干了以前需要一个小团队干的活。

这才是 agent 真正的价值所在：不是帮大公司省钱，而是帮小公司活下去。一个开咖啡店的老板，以前要么自己学着做账、发帖、回消息，要么花钱请人。现在一个 agent 套件就能覆盖大部分日常运营。

当然，这里面也有隐忧。当你把这么多业务交给 AI 管理，出了问题谁负责？agent 给客户回复了错误的信息导致投诉，算谁的？这些问题目前没有答案。

这让我想到了安卓的早期

回头看智能手机的历史，iPhone 定义了什么是好手机，但真正让智能手机普及的是安卓——因为它让所有厂商都能做智能手机。

AI agent 现在可能正处在一个类似的节点。OpenAI、Anthropic 这些公司定义了 agent 的能力上限，但真正让 agent 走进每个人生活的，是苹果、Meta、微软这些平台方把 agent 做成了普通用户能直接用的东西。

MCP 协议让 agent 能调用各种工具，A2A 协议让 agent 之间能互相协作。基础设施在快速成熟。但最终决定 agent 能不能普及的，不是协议有多优雅，而是用户愿不愿意用。

从目前的信号看，大公司们显然赌的是"愿意"。

我拿不准的地方

但也不是没有隐忧。

第一，隐私。agent 要帮你处理业务，就得接触你的数据。商家的客户信息、交易记录、沟通内容，这些都在 agent 手里。苹果的封闭审核某种程度上是在解决这个问题，但 Meta 和微软那边呢？

第二，可靠性。agent 回复客户消息，99% 的时候没问题，但那 1% 的错误回复可能就是一条差评或者一次投诉。在客服场景里，"大部分时候对"可能不够。

第三，竞争格局。现在是各家各做各的，WhatsApp 的 agent 和 iMessage 的 agent 互不相通。如果 agent 真的成为主流交互方式，会不会又出现一轮"生态之争"？到时候用户是不是又得在多个平台之间切换？

这些问题现在都没有答案。但方向是清楚的。agent 不再是 demo 里的酷炫玩意儿，它正在变成基础设施。

接下来半年会很关键。如果 Poke 在苹果生态里跑通了，如果 Meta 的 WhatsApp agent 真的帮商家省了钱，如果 Project Solara 找到了第一批硬件合作伙伴——那 2026 年可能真的是 agent 的"安卓时刻"。

当然，也有可能这些尝试都半途而废。毕竟不是每个趋势都能兑现。但这么多大公司同时押注同一件事，上一次见到这种场面，好像还是 2007 年大家都在做智能手机的时候。

AI 写代码这件事，真的被"解决"了吗？

Mon, 08 Jun 2026 00:00:00 GMT

上周 VentureBeat 发了篇文章，标题很炸：《Agentic AI solved coding and exposed every other problem in SE》。大意是说，AI 编程代理已经解决了写代码这件事，但软件工程里其他的问题——需求理解、架构设计、调试、维护——反而被暴露得更明显了。

我第一反应是标题党。但仔细想想，好像又没完全说错。

现在的 coding agent 到底什么水平？

先说个背景。2026 年的编程工具市场已经卷得不行了。Claude Code、OpenAI Codex CLI、GitHub Copilot、Cursor、Windsurf……每家都在说自己能帮你写代码。有人搞出了用手机远程控制 Claude Code 和 Codex 的工具（叫 Circus Chief），还有人做了个 Dragoman，让你在 Claude Code 里切到别的模型跑。生态已经长到有点离谱了。

这些工具确实能干活。你给它一个清晰的需求，它能生成一个能跑的函数、一套 CRUD 接口、一组测试用例。速度快得离谱，以前要写半小时的 boilerplate，现在一句话搞定。

Eli Bendersky 最近写了篇博客，讲他用 AI agent 从零开始写一个 Go 项目（watgo）的经历。他的说法比较实在：agent 确实能加速编码，但你得一直盯着。有时候一个 changelist 相当于好几天的工作量，但他花了好几个小时让 agent 反复清理和重构。总体有提升，"只是没某些人吹的那么大"。

这话我挺认同的。

Vibe coding 的隐患

Cursor 的 CEO 四月份发了个警告，说 vibe coding（就是那种完全不看代码、纯靠 AI 生成的写法）会"建立摇摇欲坠的基础，最终一切崩塌"。

说这话的人是卖 AI 编程工具的，这本身就挺有意思。他显然看到了什么让他不安的东西。

我自己也碰到过。agent 生成的代码能编译、能过 lint、测试也能跑。但过两周你要改需求的时候，才发现它用了个奇怪的抽象方式，或者把本该分离的逻辑揉在了一起。代码"能跑"和"好改"之间差着十万八千里，agent 目前还跨不过去。

有句老话说得好——调试比写代码难两倍。当你让 AI 用它的方式写代码，而你压根没理解它为什么这么写的时候，这句话就变成了一个很现实的问题。你连调试的入口都找不到，因为你根本不知道代码是怎么运转的。

写代码从来都不是最难的部分

VentureBeat 那篇文章的核心洞察其实不是"AI 解决了编码"，而是"AI 解决了编码之后，我们终于能看清楚真正的难题在哪了"。

真正的难题是什么？

需求理解。用户说"我想要一个搜索功能"，这话听着简单，但你要搞清楚搜什么字段、要不要模糊匹配、结果怎么排序、分页还是无限滚动。这些 agent 搞不定，因为提需求的人自己往往也说不清楚。

架构决策。这个服务要不要拆微服务？数据库选 PostgreSQL 还是 MongoDB？缓存层怎么设计？没有标准答案，取决于团队规模、业务预期、运维能力。agent 可以列 pros and cons，但做不了这个判断。

长期维护。代码写完只是开始。上线之后有 bug 要修、有需求要加、有依赖要升级。一个 agent 写出来的"一次性"代码库，和一个经过人类工程师深思熟虑的代码库，三个月后的维护成本完全不是一个量级。

调试。这可能是 agent 最弱的地方。线上出了个偶发的并发问题，或者某个 edge case 导致数据不一致，你需要的不是更多的代码，而是理解系统是怎么运转的。agent 可以帮你加日志、写断言，但它替代不了那种"盯着日志想了半小时突然想通了"的过程。

那我们该怎么用这些工具？

说了这么多不是要唱衰 AI 编程工具。它们确实有用，我自己也在用。关键是怎么用。

Eli Bendersky 把项目分了两类，我觉得这个分法挺好：

低重要度的项目——原型、一次性脚本、hackathon 作品。这些可以 vibe code，反正不打算长期维护，快速出活就行。

你真正要维护的项目。这种情况下 agent 生成的每一行代码都值得过一遍。不用逐字审查，但你得理解它在做什么、为什么这么做。否则你就是在积累技术债，只是这个债现在还不用还。

我的做法是让 agent 处理那些我知道该怎么写但懒得写的部分——配置文件、测试用例、数据转换、文档。涉及到核心业务逻辑的时候，让它先写一版，然后自己过一遍，该改的改、该重写的重写。

效率确实比纯手写高，但远没有"一句话生成完整应用"那么夸张。现实就是这么无聊。

一个更大的观察

Anthropic 上个月花了三亿多美金收购了 Stainless，一个做 API SDK 生成的工具。连 AI 公司自己都觉得光有模型不够，开发者工具链的每个环节都得做好。

编程代理的战场已经不只是"谁的模型写代码更好"了。上下文管理、多模型路由、沙箱执行、安全审计、团队协作——每个环节都有创业公司在挤。GitHub 的 CPO 最近接受采访，说未来的开发者更多是在做"宏观委托"，把大块任务交给 agent，自己负责审查和整合。

这个方向我信。但"宏观委托"的前提是你得有能力做"微观审查"。你完全不懂代码的话，怎么判断 agent 给你的东西是对的？

所以结论可能有点反直觉：AI 越强大，基础功反而越重要。不是说你要手写每一行代码，而是说你得理解每一行代码。

写代码这件事，AI 解决了一半。剩下那一半，刚好是区分"会写代码的人"和"工程师"的那一半。

你好，这里是 Xux Note

Sun, 07 Jun 2026 00:00:00 GMT

你好，世界

这是我的第一篇博客。

说实话，搭建这个博客的过程比想象中折腾了不少——一开始我搭建了一个全栈的博客，调试很久准备部署上线但最后还是放弃了，因为我感觉它还是太笨重，所以我换了一个更为轻量的博客模板。但折腾完之后回头看，这本身就是一件挺有意思的事。很多事情都是这样，真正动手做了，才发现没有想象中那么难，也没有那么简单。

关于我

我是 XU。

如果要用一句话概括自己正在做的事，那就是博客签名写的那句——学会销售，学会建造，然后我会不可阻挡哈哈哈。

"建造"好理解：不止是写代码、搭系统、把想法变成能跑起来的东西。最主要的是一个价值的输出，我喜欢这种感觉，我能在在此过程获得极大的满足和被认同感。

"销售"可能听起来有点奇怪。但我越来越觉得，无论做出多好的东西，如果不会表达、不会让别人理解它的价值，那它就很难真正产生影响。这其中涉及到情商、沟通、多种因素，写博客，对我来说就是练习"销售"的一种方式——把想法讲清楚，把经验传递出去。

为什么写博客

其实理由很简单：

记录。 人的记忆是靠不住的。踩过的坑、学到的东西、某个瞬间的想法，如果不写下来，过几个月就忘得干干净净。与其依赖脑子，不如依赖文字。

思考。 写东西的过程会逼你把模糊的想法变成清晰的表达。很多时候，我以为自己想明白了，但写出来才发现逻辑上还有漏洞。写作是最好的思考工具。

分享。 如果我的某篇笔记恰好帮到了一个有同样困惑的人，那就值了。我在做有意义的事，放大并传播自己的价值。

这里会写什么

不会给自己定太严格的计划，但大概会围绕这些方向：

技术相关的内容——踩坑记录、工具推荐、项目复盘。生活相关的碎片——读过的书、想明白的事、一些随想。偶尔可能也会有一些不太正经的吐槽。

总之，这里是一个真实的人在认真生活和成长的记录。没有固定的更新频率，但有话想说的时候就会写。

最后

如果你偶然看到了这个博客，欢迎逛逛。

如果某篇文章对你有一点点帮助，那就更好了。

我们网上见。

如果你偶然看到了这个博客，欢迎逛逛。

如果某篇文章对你有一点点帮助，那就更好了。

我们网上见。

MCP 协议：AI Agent 互操作的未来

Sun, 07 Jun 2026 00:00:00 GMT

MCP 协议：AI Agent 互操作的未来

最近和几个做 AI Agent 的朋友聊天，发现大家不约而同地提到了一个词：MCP。这让我想起几年前 REST API 刚统一 Web 服务接口时的情景——似乎我们又站在了一个标准化的门槛上。

什么是 MCP？

Model Context Protocol（模型上下文协议）最初由 Anthropic 在 2024 年提出，目的是为大语言模型提供一种标准化的工具调用方式。简单来说，它就像是 AI Agent 世界的“USB 接口”：无论你用的是 Claude、GPT 还是开源模型，只要支持 MCP，就能以统一的方式调用外部工具。

这听起来可能有点技术化，但实际影响很大。想象一下：你写了一个天气查询工具，以前需要为每个模型适配不同的调用格式，现在只需要实现一次 MCP 接口，所有支持 MCP 的 Agent 都能直接使用。

从工具调用到 Agent 互操作

MCP 最初解决的是“模型调用工具”的问题，但它的野心不止于此。2025 年底开始，社区开始探索用 MCP 连接不同的 Agent，形成多 Agent 协作网络。

举个例子：一个研究 Agent 负责搜集资料，一个写作 Agent 负责整理成文，一个审核 Agent 负责质量把关。这三个 Agent 可能来自不同的团队，使用不同的模型，但通过 MCP 协议，它们可以像搭积木一样组合起来。

这种模式已经在一些开源框架中落地。比如 LangChain 的 Agent Protocol、AutoGen 的 GroupChat，都在尝试标准化 Agent 间的通信。但 MCP 的优势在于它更底层、更通用，不绑定特定框架。

现实中的挑战

当然，标准化从来都不容易。MCP 目前面临几个现实挑战：

性能开销：标准化意味着额外的序列化/反序列化成本，对于需要低延迟的场景（比如实时对话），这可能是个问题。
安全边界：当 Agent 可以互相调用时，权限控制变得复杂。一个恶意 Agent 可能通过合法接口获取敏感数据。
生态碎片化：虽然 MCP 是开放标准，但各大厂商都有自己的“方言”。OpenAI 的 function calling、Google 的 Gemini API，都在某种程度上与 MCP 竞争。

我的观察

我觉得 MCP 最有价值的地方，不是它解决了某个具体技术问题，而是它代表了一种思维方式：AI 能力应该像乐高积木一样可组合。

过去一年，我们看到太多“全家桶”式的 AI 产品——一个模型包办所有事情。但现实是，没有哪个模型能在所有任务上都做到最好。更合理的架构是：让擅长推理的模型做规划，让擅长代码的模型写程序，让擅长搜索的模型找信息，然后通过标准协议把它们串联起来。

MCP 正是在推动这种“专家协作”模式。虽然它现在还不完美，但方向是对的。

给开发者的建议

如果你正在做 AI Agent 相关的开发，我建议：

关注 MCP 规范的演进：虽然还在早期，但尽早了解标准的设计哲学，能帮你避免后期大规模重构。
设计时考虑可组合性：即使现在不用 MCP，也尽量把 Agent 的能力拆分成独立、可复用的模块。
参与社区讨论：MCP 的规范还在发展中，你的使用场景和反馈可能会影响最终标准。

结语

AI Agent 领域正在从“单打独斗”走向“团队协作”。MCP 协议就像是为这个新兴团队制定的沟通守则——它可能不完美，但没有它，协作成本会高得难以承受。

作为开发者，我们既要有耐心等待标准成熟，也要有远见提前布局。毕竟，在技术演进中，早期参与者往往能获得最大的红利。

你对 MCP 协议有什么看法？欢迎在评论区分享你的见解。