问题背景
当前系统中，业务分析师日常工作的一个高频场景是跨数据源核对数据。典型情况：数仓拉出的周环比增速与 BI 看板显示的数字存在偏差，两个系统本身并未报错，但业务口径存在细微差异。当需要在管理层面前解释这类偏差时，分析师只能手动打开多个标签页，靠肉眼和经验判断差异原因。
只要公司有两个以上系统能查同一件事，这类数据对不上的问题就会反复出现。分析师需要在数仓、看板、合作方对账单之间反复切换，把数字抄到草稿纸上逐项比对，全凭经验判断这是正常时延还是实际错误。目前系统缺少自动化的交叉核对能力。
基于上述现状，本文梳理当前系统在接入 AI 智能体后的架构演进过程，分析各阶段暴露的问题，并提出对应的优化方案。
现状与问题分析
阶段一：单 MCP 聊天机器人
初期方案在语义层前套了一层 MCP 服务，挂载智能体，让用户用自然语言提问，替代手写 SQL 或在看板中逐层筛选。演示阶段效果不错，但上线后暴露三个问题：
- 单数据源盲区。语义层的数据若未及时刷新（比如收入数据卡在两天前），AI 仍会以笃定的语气返回过期数据，用户无法判断数据时效。
- 权限失控。底层服务账号权限直接透传给 AI，同一个查询接口既能查营收，也能导出包含客户邮箱的全量数据。调用链路无法区分请求来源和权限范围。
- AI 无法表达不确定性。无论是返回准确数据还是过期数据，AI 给出的语气没有区别。遇到数据缺失或异常时，AI 倾向于硬猜而不是主动说明。
第三个问题揭示了一个更本质的判断：这不是聊天机器人体验问题，而是数据治理问题披了对话交互的外衣。
阶段二：多数据源接入
为解决单点盲区，系统接入了原始数仓、BI 缓存指标层和产品埋点内部 API 等多个数据源。分析师日常查询的系统，AI 都能直接调用。
但数据泄露风险随之成倍增加。此前的权限管理依赖 BI 系统的网页界面（行级权限、文件夹可见性等），这些前端层面的权限控制无法延伸到底层的工具调用。实际工单反馈：用户查询简单账户信息时，AI 顺带返回了无关的敏感字段。原因在于直连数仓的 MCP 没有做字段级输出控制。
接入数据管道本身不难，难的是数据治理。数据开始在各管道间流通后，权限漏洞才会集中暴露。
阶段三：权限治理完成后，口径差异仍无法解决
在 RBAC 权限钉入 MCP 工具边界、PII 脱敏做在数据进入大模型上下文之前之后，权限问题基本解决。但向数仓 MCP 和 BI MCP 询问同一个指标（如"上周收入"），两边数字仍然不一致。
根因不是系统故障，而是业务口径差异：一个口径包含退款调整，另一个不包含；两边的数据同步频率也不同，早上拉出的报表可能比实时库落后半天，而两个 MCP 都不知道对方的时效。
资深分析师靠长期业务经验能判断各场景下该看哪个数，AI 缺乏这种直觉，只会随机选一个然后给出笃定的回答。
AI 实现方式分析
权限控制：必须在 MCP 工具层实现
BI 网页前端的权限拦截无法跟随底层工具调用传递。每个 MCP 服务必须作为独立的安全边界，每次工具调用显式携带当前用户的角色和权限范围，核验通过后才能访问底层数据。
PII 脱敏同样需要前置到 MCP 输出路径：数据进入大模型上下文之前，必须经过实体识别并打码。依赖 Prompt 约束大模型不输出敏感字段不可靠，正确做法是从源头切断敏感字段的可见性。
口径裁决：语义本体层
解决指标口径打架的唯一方案是建立语义和本体层，并作为独立 MCP 部署。这不是 Wiki 上的口径说明文档，而是硬性协议：任何 MCP 对外返回数据前，必须将字段定义提交本体层校验。当两个数据源对同一指标定义冲突时，平台层面必须预先裁定哪个数据源为权威口径，不允许大模型自行调和。
交叉对账：多源并发查询与容差比对
权限和口径问题解决后，系统可以实现自动化的跨源对账。智能体并发调用数仓 MCP、BI MCP 和外部参考源，统一按本体定义解析字段，执行自动对账（Reconciliation）。
对账逻辑不是让大模型选一个"更合理"的数，而是在人为设定的容差区间内做客观比对。核心收入指标容差设窄，采样推算指标容差可放宽。超出阈值的偏差直接标明，不隐瞒也不替用户做判断。容差阈值由业务方协商确定，不由 AI 决定。
外部数据源：独立置信度评级
外网检索 MCP 用于补充内部库无法覆盖的内容（竞品定价、行业趋势、外部基准）。但外网搜索到的估算数据如果与内部财报数据以同样语气混合输出，极易在汇报材料中被当作既成事实传播。
外部数据必须携带独立的置信度评级，在回答中明确标注为"外部估算"，与内部对账数据隔离存储。外部数据对决策有参考价值，但必须明确标识其来源和可信度边界。
改进方案
Skill 机制：将排查套路工程化
收入对账、流失率测算、定价异常审查等场景，排查流程高度重复：选择 MCP 调用范围、分配 RBAC 角色、配置对账规则、标注外部数据。每次靠临时拼凑 Prompt 来完成这些操作，效率低且容易出错。
这类重复流程应固化为带版本号的可复用 Skill。Skill 不是提示词模板，而是打包好的工程规范，包含四个部分：
- MCP 调用范围：限定可调用的服务器和接口。
- 语义口径契约：每个字段必须对照的标准定义。
- RBAC 权限策略：严格继承调用者角色，禁止越权。
- 对账校验规则：针对业务场景设定的容差阈值与对齐逻辑。
当前进展与后续方向
Skill 仓库目前只沉淀了少量排查模板，跨任务的长时记忆版本化尚未完成。语义本体层在遇到未覆盖的业务问题时仍需扩展。但系统的核心架构已经确立：
- 每个 MCP 工具在边界上守住权限和隐私。
- 语义本体层作为指标口径的裁决层。
- 自动化对账替代人工肉眼比对。
- 常见排查流程固化为工程化 Skill，避免重复配置。
数据差异问题不会消失，但系统可以在几秒内完成跨源交叉比对，将差异原因和各数据源的口径差异完整呈现，不再需要分析师手动开多个标签页逐项核查。