别让 Agent 在脑子里做 Join：跨源数据分析的正确姿势

别让 Agent 在脑子里做 Join：跨源数据分析的正确姿势

给 Agent 接上 Stripe、PostHog、HubSpot 三个 MCP Server，然后问它："产品用量和收入有什么关系？"它会先调一个服务，再调下一个，再调第三个，然后试图在自己的上下文窗口里把三份结果对齐。有时候答案是对的——"有时候"，这就是问题所在。

MCP 拼结果，正是出错的地方

MCP Server 是把 Agent 接上工具的快路：文档齐全，Agent 通常也知道怎么调。但拿来做数据分析，它有三大硬伤：

只能拿到厂商暴露的东西。 MCP Server 没暴露某张表、某个字段，Agent 就无从问起。你的问题边界被厂商的设计决定了。

Join 发生在上下文窗口里。 Agent 必须把多个来源的结果同时装进记忆再合并——而这恰恰是模型最会"编造"的地方。让 LLM 在脑子里模拟一个内存数据库做跨源 Join，出错率极高，而且错了你也看不出来，因为过程不可审计。

权限非黑即白。 一个 MCP 连接要么对所有人暴露，要么要求每个用户单独认证，中间没有行级安全（Row-Level Security）这回事。

正确的做法：一个横跨多源的数据模型

思路转换：不让 Agent 去各个源头取数再自己拼，而是先把 Stripe、PostHog、HubSpot、GitHub、广告平台、Google Sheets、CSV 这些来源接进一个统一的数据模型（Data Plane），需要的话还能挂上 BigQuery、ClickHouse 这类数仓。

表进了一个模型之后，Agent 的工作方式变了：写真正的 SQL 去做跨源 Join。这带来两个根本性改善：

• 多月、多年的分析成为可能——上下文窗口装不下的数据量，SQL 毫无压力
• 答案可验证——你可以打开那条查询语句，亲眼看 Join 是怎么做的

一句话：Join 属于 SQL，因为事后你能读它。

数据主权回到你手里

用 MCP Server，哪些数据"存在"由厂商决定；用统一数据模型，由你决定。把问题需要的表加进模型，像对待数仓表一样给每张表写注解和描述。

这件事比听起来重要得多：Agent 在一小组描述良好的表上工作效果最好，而最适合你问题的表集合，几乎从来不是厂商为所有用户选好的那一套。只暴露你的问题需要的表，并把每一张都描述清楚。

一套权限规则贯通所有来源

因为这些来源都活在同一个数据模型里，行级安全规则可以一视同仁地生效：一条针对国家或租户列的全局规则，过滤 Stripe 行的方式和过滤数仓行完全一样。一个权限模型覆盖所有来源，而不是每个连接各讲一套信任故事。

MCP 依然有价值——在另一件事上

这不是要否定 MCP。读一页 Notion 文档补充上下文、在 Linear 里建一张工单、把分析结果存到团队协作的地方——这些是动作而不是分析，正是 MCP 的主场。

我的划分规则很简单：凡是要 count、sum、join 的，走数据模型；凡是"去做一件事"的，走 MCP。

从哪里开始

挑一个需要两个工具才能回答的问题——比如"按产品用量分层看收入"（需要 Stripe + PostHog）。把两个源接进统一数据模型，只加这个问题需要的表，写好描述。然后提问，读 Agent 写出来的 SQL。

如果你能看懂那个 Join，任何需要信任这个答案的人也能看懂。

让 Agent 决定问什么，让数据库做算术。