这期围绕 MCP 讲了两个机会。一个偏体力：企业里几十个现成的 API 服务要包成 MCP，工作量不小，员工也不愿意干，这是很实在的外包生意。另一个更大：MCP 现在只有开发者能用，谁把申请 key、配权限这些包掉，谁就做出了 MCP 的应用商店。
Meta 这边不太顺。负责 FAIR 的那位 2017 年就加入的负责人辞职了——PyTorch 这类东西就是在他任内做出来的。随着 Llama 的势头转弱，内部大概是越来越觉得不对劲。
另一边，Shopify CEO 的内部备忘录传得很广：要求所有员工都开始用 AI，并且把「AI 使用率」当作一条基线预期——所有事情都尽量先用 AI 试着做。
这是这期最核心的判断。现在能用 MCP 的基本只有开发者——你得加 key、申请开发者权限，才能真正跑起来。
要让普通用户用上，必须有一层把这些全包掉的产品。可以把它叫做 MCP 的应用商店：比现有的东西再往外包一层。
谁来包？很像以前那种托管 key、聚合各平台 key 的角色——你在我这里用一个 key，我帮你对接所有平台。这个位置是个很大的机会。
至于入口形态，要么是 Spotlight 那种唤起式，要么是一直浮在桌面上的小控件——但后端一定是常驻的。
单个服务包成 MCP 很简单，几行就拿到了。但一家企业动辄几十个服务，原来的 API 都在，要全部再包一层 MCP，工作量并不小。
企业多半不愿意让自己的员工去干这种活。所以至少在几个月到半年内，「帮企业把内部服务和常见服务包成 MCP」是个很实在的外包机会。
选客户端时要看清楚：MCP 这个协议本身有好几类能力，各家客户端支持程度不一样。
resource——能不能取文件；tools——大家最熟的那类，模型能拿它干什么；还有 prompt。
prompt 也是 MCP 的一种输出能力，但很容易被忽略——大家看到 MCP 只想到 tools。官方有做过各客户端的支持度测试，选型时值得先查一遍。