MCP 是新的‘建好了自然就会有人来’

四月份，一位客户让我们找出他们的 MCP 服务器为什么没有起色。我们大约花了 90 秒就明白了。三个月里只有 61 次工具调用，其中 58 次来自他们自己的工程师在测试；发布本身也进行得很顺利，问题不在这里。目录收录、一篇公告帖子、评论区里来自再也没回来的人的一些祝贺。在开始构建之前，没有人明确问过目标用户应该是谁。我翻了一遍 Slack 历史记录确认了一下，确实从来没人问过。快速声明一下，因为这类观点需要有出处：我从事软件开发已有 8 年，MCP 相关工作现在占客户付给我们费用的相当一部分。所以我在批评自己的饭碗。在最初那波热潮中，我也构建了一个自己的服务器，但它没给我带来任何收益，因为它没有解决任何真正让人卡住的问题。我大概花了一年才承认这一点。我反复看到的一种混淆是：服务器能让你的产品被智能体触达，而团队把“可触达”当成了“被需要”。集成是真正的工程，有明确的完成标准，所以大家都倾向于做它……你可以把它做完。但“是否真的有人在尝试让智能体执行你的任务并失败了”是一个让人不舒服得多的问题，合并多少 pull request 也回答不了它。与此同时，目录中已经堆满了数千个服务器，其中很大一部分显然已被弃用。当我们问新客户为什么想要一个时，在花哨演示文稿之下的诚实回答通常都是某种“我们的竞争对手也有”。我经历过 2022 年，那时候每个消费品牌都推出钱包登录和 NFT 空投，可能只有十来个人用过，这件事有同样的味道。资金正流向网关、注册表和认证层，而不是服务器本身。平心而论，这些都不是协议的错。它把自己的本职工作做得很好。问题在于可发现性。人类需要在数千个服务器中找到一个属于你的，这是软件一直以来的分发难题。然后智能体还得在需要时刻选中你的工具，任何见过一个连接了 40 个工具的模型却总是依赖同样 3 个“最爱”的人，都知道会是什么结果。这两件事都不是协议能替你解决的。在 MCP 出现之前它们就是工作任务，现在仍然是。我们现在在构建任何东西之前都会做的测试是：找到 5 个真实用户，他们已经尝试让智能体做这个任务但失败了。说“听起来有用”的人不算数，你要的是那些亲自试过并卡住的人。然后从第一天起就对每次调用进行埋点，并提前商定触发关闭的指标数字。我们四月的那位客户正在围绕一个工作流重新构建，而这个工作流是两个真实客户一直反复要求的，早期使用量已经比旧服务器高出一个数量级。“建好了自然就会有人来”是一句电影台词，而且即使在电影里，男主角也差点因此丢了农场。