MCP 不是后端：从 WorkBuddy 聊 Agent 的数据通道

前几天刷到腾讯 WorkBuddy 开放平台上线的消息，首批汇聚了超百家生态伙伴，声势相当不小。点开文档一看，它的核心形态其实不难概括：一套预置的专家流，加上一大排可以可视化接入的 MCP。朋友的第一反应和我最初的想法差不多——这不就是把 prompt 模板和工具调用重新包装了一遍吗，纯属重复造轮子。这个直觉我特别理解，而且不能说错，但几轮聊下来之后，我发现这句话只对了一半，而错的那一半，恰好藏着 Agent 生态里最容易被忽略的一个分层问题。

先说那个最值得商榷的印象：把 MCP 看成网页后端的替代品。后端真正要干的事，事务一致性、鉴权、状态持久化、业务逻辑编排、限流降级，这些 MCP 一概不管，也不该管。它解决的是另一个层面的问题，也就是大模型怎么用一套标准协议去够到外部数据和工具。说得再直白一点，它就是给现有系统“打洞”的，洞那边还是你原来的服务、原来的数据库、原来的业务逻辑，洞本身既不存数据也不跑逻辑。那些宣称用 MCP 搭起了完整系统的演示，拆开看后端往往还是传统那一套，而 MCP 只负责让 AI 能调到它。把协议层当成应用层来用，往里塞本不属于它的业务逻辑和鉴权方案，那才是真正造歪了的轮子，歪就歪在分不清边界。

而“给 Agent 提供数据”这件事，本身就分好几个不同的层。拿我自己维护的这个 Hugo 博客项目举例最直观：系统提示词里写着时区统一、禁止中文提交信息这类铁律，属于每次都生效的规则和事实；单独维护的记忆文件里攒着经验教训，属于按需去读的历史，本质上是一个极简的检索系统；而 Skill 喂的是程序性知识，教 Agent 这类事情该按什么流程办；至于 MCP 喂的则是实时能力和外部数据，解决上下文窗口之外的世界怎么够到的问题。这几样东西根本不在一个层面上，互相谈不上替代——Skill 教手艺而 MCP 发工具，规则立边界，记忆攒经验。各家产品的差异从来不在能不能提供数据，而在这些通道的工程化程度：粗糙的做法是全塞进系统提示，结果 token 占用爆炸还互相打架；讲究的做法是分层放置，让每一层各取所需。

但分层归分层，落到实际使用上确实有让人火大的地方。朋友吐槽说，很多数据人手动打开浏览器三秒钟就能看到，接个 MCP 反而要注册账号、申请 key、看配额，有的还要收费，感觉毫无意义。这个质疑相当成立，现在 MCP 生态里确实有一股歪风，把公开网页上摆着的数据包一层收费 API 的皮，包装成所谓的企业级能力。可再往深想一层，那些 key 和订阅买的并不是数据本身，而是稳定、结构化、不用跟反爬机制斗智斗勇的获取方式。人浏览网页靠的是直觉，扫一眼就知道哪里是重点，浏览器顺手就处理掉了跳转和 Cookie；可 Agent 要无人值守、批量、高频地干活，手动浏览这条路径就复制不过去了。所以真正无意义的从来不是 MCP 这个协议，而是那些把免费公开数据强行收费化的 Server。

那么怎么判断一个场景该不该上 MCP？我的标准很简单，看这个数据获取需不需要跨过一道门槛。不需要门槛的公开信息，直接抓取或者浏览器自动化就够了，别为它接付费服务；需要门槛的，比如私有数据、有鉴权的业务系统、海量批量查询，这些场景用 MCP 加 API 才是正路。另外还有一个比收费更隐蔽的坑：这几条通道之间目前没有统一的优先级仲裁，规则、记忆和 Skill，还有 MCP 返回的数据一旦打架，可 Agent 到底该听谁的，现在基本靠模型自觉，听错了就安静地干出离谱的事。在我看来，这可能是比造轮子更实际的工程问题，也是各家产品下一个真正拉开差距的地方。

回到 WorkBuddy 到底算不算重复造轮子这个问题。从纯技术的角度看，专家流就是 prompt 模板加工具编排加记忆管理，各家都在做同一件事，确实谈不上什么架构创新。但这个赛道的竞争从来不在轮子本身，而在分发和生态——腾讯赌的是把微信、企微、腾讯文档这些入口和数据打通，再让硬件厂商和开发者来适配自己的标准。就像当年很多人断言 Android 重复造了 iOS 的轮子，结果 Android 靠开放生态的跑马圈地活成了另一极。轮子圆不圆其实没那么重要，重要的是谁能先让最多的路跑起来。至于普通用户，倒不必急着站队，把每一层数据通道各自解决什么问题看明白，用的时候心里有杆秤，就已经领先大多数人了。