开场：MCP 是 AI 时代最重要的基础设施之一

主播娜塔开场点题，称 MCP 0728 解决了 MCP 长久以来一个非常痛苦的问题——stateful。随后解释 MCP 是 AI 与外部世界交互的第一代入口，最初只有本地 stdin/stdout 接口，甚至无法联网，除 web search 外几乎是唯一通道。

用比喻拆解 model、harness、skills 与 MCP 的分工

主播用一套比喻说明各层职责：model 是脑子，负责意图识别与决策；harness 是手，负责执行动作；skills 是技能，告诉手该怎么做；MCP 则是冰箱，负责与真实世界做存取交互。这一框架为后文对比 MCP 与 skills 打下基础。

MCP 一代的核心痛点：有状态服务

MCP 一代最核心的问题是它是有状态服务，远程连接需要一条 session 一直维护状态并与具体 IP 服务器绑定。这导致扩缩容和 load balance 极难处理，新版本上线时老机器上的连接必须继续维持，否则用户聊着聊着就不能用了，得新开 session。用 Redis 做 session 共享可以解耦，但终究麻烦。

skills 加 CLI 的绕行路线与生态繁荣

skills 用另一种办法解决问题：每个产品提供 CLI 服务，通过命令行调用与外部世界交互，从而绕过 MCP。主播表示自己非常推崇 CLI，因为它直观、语义化。目前多数应用产品更重视 skills，skills 市场已经多到难以想象，连各种品牌都有自己的 skills 市场。

skills 的第一个软肋：语义表达弱于自然语言

主播指出 skills 的第一个问题：CLI 通过 Linux/Unix 那套规范用单词拼接参数，比如 sintalk fetch 一个 URL。相对于自然语言，CLI 的语义化程度略逊一筹，因为单词凑一块并不能成为句子，而 MCP 里的一个 method 表达会更好。

skills 的第二个软肋：必须依赖一台机器运行

CLI 运行在哪里？不可能在对话里直接执行，它依赖一个线上运行环境，可能是 sandbox 或很小的 VM。这意味着每次调用 skills 都要开一台机器，本地或远程都行，但成本不低——AI 基础设施里内存、CPU、GPU 价格都居高不下，对服务商是实打实的负担。

skills 的第三个软肋：CLI 黑盒与语义失守

CLI 程序是黑盒且在用户本地执行，运行不受信 skills 时可能去调用 password 之类的东西，npm 供应链攻击蔓延到 skills 只是早晚问题。此外 CLI 的语义依赖开发者自觉，如果有人把 get 做成 post，在 RESTful 实现里这种情况非常多。而 MCP 的每个 method 都有读或写的分类，AI Agent 可以做简单分类。

MCP 0728：把状态环节完全干掉

MCP 没有严格意义上的二代，只有以日期命名的 0728 版本。它把中间验证和保持的环节完全干掉，改成类似 HTTP 的无状态接口，不再需要维持 session ID，每次请求带上 header 和处理模式即可。于是服务扩缩容变得非常简单，load balance 终于有了用武之地，还带来便于审计和相对安全两个好处。

实例演示：shorttime 的 MCP server 与工具分类

主播用 shorttime 演示一个 0728 版本的 MCP server。屏幕上只读工具可以直接设为 always allow，写操作则被单独分类——rollback 服务里有三十二个写和 delete 操作，可以针对性地禁止或允许。主播认为用 Claude 很容易实现一个还不错的 MCP server。

调用结果与结论：MCP 与 skills 的取舍

调用后 MCP 加载了 shorttime 的工具并调用了其中众多方法，屏幕上出现最近从 codex 使用、以 USD 计价的数据，显示多数工作在用 Claude Code 完成。这些数据由 MCP 获取，再结合 Claude 做分析和渲染。主播总结 MCP 0728 实践简单、安全性更好、语义化更高，并建议有自己产品的团队去实现一个 MCP server。