做 AI 要赚钱一定是服务 B 端用户。B 端 AI 要落地，一定绕不开 MCP。
Hermes Agent 替代小龙虾成为当前最火爆的 Agent项目，Claude Code 也在快速迭代，大家都想做 B 端 AI 交付赚钱。
接几个 Skills，写点 Prompt，看起来就能用了，但是核心问题根本没解决：数据。
Excel、PDF 这种数据好解决，Excel 用代码生成统计分析，PDF 通过 OCR 提取文本，图片可以 Embedding。可以看看我之前的文章：10 分钟做的 Excel 数据报告，拿下 160 万的订单
但企业真正的数据在哪里？
在 Elasticsearch、Oracle、MySQL 数据库里。财务、用户、业务数据，这些才是企业的核心。
工具再好，Skills 再多，接不了企业数据库，就是空谈。
我们试了一圈，最后发现：B 端 AI 落地，绕不开 MCP。
一、知识库方案，只适合小企业
大家第一反应是做知识库（RAG）。
但这条路在真正有数据的企业面前，根本走不通。
企业不会把数据给你。涉及数据安全、合规性（GDPR、行业监管）、跨境传输限制。
知识库方案的本质是「把数据搬出来」，需要企业把数据导出、上传。
但企业凭什么信任你？
这不是技术问题，是信任问题。
知识库更新延迟是小时甚至天级别。企业要的是实时数据：当前库存、实时订单、最新财务数据。知识库做不到。
动态业务逻辑也无法编码。复杂的业务规则、计算逻辑，知识库只能存静态文档。
知识库只能回答「已知问题」。企业的数据需求是动态的：临时性的数据分析、复杂的多表关联查询，知识库做不到。
知识库方案适合文档类数据、小企业。但真正有数据的企业，数据在 Oracle/ES/MySQL 里，不会给你，也不需要你搬。
二、AI 生成复杂查询，成功率只有 20-40%
那能不能让 AI 直接生成查询语句？
我们试过。简单查询可以，复杂查询不行。
我们让 AI 生成 ES 查询语句。简单查询（单层 match）成功率 85-95%，但嵌套字段查询（nested fields）成功率只有 20-40%。
为什么失败？
ES 的 nested 查询语法复杂：多层括号、嵌套路径、bool 逻辑组合。AI 很难精准匹配这种嵌套结构。
更要命的是成功率的指数级下降。
单个查询成功率 90%，看起来很高。但一次生成 10 个查询，成功率就变成 10%。如果是嵌套查询，成功率更低。
C 端产品，70-80% 成功率可以接受，容错率 20-30%。用户可以重试，可以容忍错误。
B 端产品，必须 99 % 以上，容错率小于 1%。
财务报表、业务决策，错一次就是事故。
实际案例：某金融企业报表系统。AI 生成查询，准确率 85%，需要人工审核，处理时间 5-10 分钟。固定工作流，准确率 100%，无需审核，处理时间小于 1 秒。
AI 生成查询，适合探索性场景，但不适合企业生产环境。
企业要的是稳定性，不是「差不多」。
三、MCP：本地部署 + 标准化接口 + 成本降低 70%
知识库走不通，AI 生成不稳定，那怎么办？
答案是 MCP。
MCP 本地部署，数据不离开企业网络。不需要把数据上传到第三方，不需要担心数据泄露。
GDPR、行业监管、跨境传输限制，企业完全可控。
解决信任问题。企业不需要信任你的服务器，只需要信任你的代码（可审计）。
MCP 是标准化协议，不需要定制开发 API，不需要维护复杂的 API 网关。
成本对比：
- API 方案：初期 $8k-23k + 年度 $27k-85k
- MCP 方案：初期 $5k-13k + 年度 $6k-12k
年度运维成本降低 70-85%。
MCP + 固定工作流，不是让 AI 动态生成查询，而是预定义查询模板 + 参数化。查询已验证，100% 正确。
完整的审计日志：谁查了什么数据、什么时候查的、查询结果是什么。企业合规要求都能满足。
MCP 能同时解决数据主权、成本、稳定性的问题。
四、B 端 AI 落地的正确路径
B 端 AI 落地，不是选模型的问题，是数据接入的问题。
Hermes、Claude Code、OpenClaw 这些工具很好，但解决不了数据问题。
知识库方案只适合小企业，真正有数据的企业，必须用 MCP。
如果你在做 B 端 AI 落地，先别急着选Agent、选模型、写工作流、调 Prompt。
先想清楚：
你的数据在哪里？（Excel/PDF，还是 Oracle/ES？）
企业愿不愿意把数据给你？（信任问题）
你的方案稳定性够不够？（容错率 <1%） 想清楚这些，你就知道为什么 MCP 绕不开了。