AI + MCP 如何落地 CRM：从自然语言到受控业务工具调用
AI 不应绕过业务系统直接操作数据。本文解析蝉鸣 CRM 如何通过 MCP 将模型推理、工具调用与企业权限连接起来。
“给 CRM 增加一个聊天框”并不等于完成智能化。如果模型只能生成文本，它无法判断客户的真实状态，也无法参与跟进、商机和服务流程；如果让模型直接访问数据库，又会破坏租户、权限和业务规则。
蝉鸣 CRM 4.1.0 采用另一条路线：AI 服务负责模型、会话和工具编排，CRM 服务继续负责客户数据、领域规则与权限，二者通过 MCP（Model Context Protocol）连接。
设计原则
模型负责理解自然语言，MCP 负责描述和调用工具，CRM 领域服务继续守住租户、权限与业务规则。
AI 模块不是某一家模型的包装层
services/mesh-ai 分为公共 API 与业务实现：
services/mesh-ai
├── mesh-ai-api # MCP 工具定义、调用对象和远程服务契约
└── mesh-ai-biz # 模型、会话、MCP Server、工具、Access Key当前模型枚举覆盖 OpenAI、Azure OpenAI、Ollama、DeepSeek、通义千问、文心一言、豆包和腾讯混元。AiModelFactory 根据模型标识选择实现，统一提供聊天、图像、Embedding、语音合成和语音转写等模型能力。业务代码不需要绑定单一厂商。
从用户问题到 CRM 工具
页面会话的核心链路如下：
- 用户通过网关和平台认证进入 AI 会话；
AiChatServiceImpl读取会话选择的模型和参数；McpServerToolService将启用的业务工具装配到 ChatClient；- 模型根据工具名称、描述和参数结构选择 Tool；
AiMcpToolDispatcher按mcpModule查找业务 Provider；- Feign 契约
RemoteMcpToolProviderService将调用转发给 CRM； - CRM 校验参数、身份、租户和数据权限后执行业务逻辑；
- 工具结果返回模型，模型再生成面向用户的答案。
公共契约只保留两类调用：
public interface RemoteMcpToolProviderService {
Result<String> invoke(McpToolInvokeRO dto);
Result<String> invokeFromSession(McpToolInvokeRO dto);
}invokeFromSession 复用页面当前登录身份；invoke 服务于 Access Key 的内部签名链路。业务服务只依赖公共 API，不需要了解模型如何创建，也不会依赖 AI Biz 的内部实现。
CRM 工具如何被发现和执行
CRM 侧通过 CrmMcpToolFactory 发现并注册工具方法，CrmMcpToolProviderController 实现统一远程契约，CrmMcpToolProviderService 完成校验和业务转发。当前工具方向覆盖客户、跟进和商机等查询与处理场景。
这不是概念效果图，而是当前系统的 MCP 服务管理页面。管理员可以查看服务归属、请求方式、服务地址、超时配置和启用状态，使“模型能调用哪些工具”成为可配置、可核查的系统能力。截图未包含 Access Key 或会话中的客户数据。
新增一个工具时，需要同时处理五件事：明确工具名称与描述、定义输入参数、绑定业务模块、执行权限校验、验证模型调用闭环。工具描述决定模型能否选对能力，业务校验决定它即使选对工具，也只能在授权范围内工作。
外部 MCP Client 如何接入
AI 服务以 Streamable HTTP 暴露 MCP Server，默认端点为 /mcp。外部客户端使用平台生成的 MCP Access Key 接入。验证器会恢复账号、用户和租户身份，并检查密钥有效性、绑定状态和频率限制。
创建凭证后，系统只展示一次完整密钥，并根据当前 MCP 服务地址自动生成第三方工具 JSON、Windows PowerShell、macOS/Linux 和 Node.js 配置。用户不需要手工拼接 Streamable HTTP 地址与认证头，可以直接选择目标环境复制完整配置。公开文档中的截图已遮挡访问密钥、服务地址与 Authorization 值。
凭证列表用于管理密钥名称、有效期、创建时间、到期时间、最后使用时间和当前状态。管理员可以按使用对象分别创建凭证，发现泄露、人员变化或客户端停用时立即吊销；过期和已吊销凭证不能再恢复业务身份。界面同时显示传输协议、只读限制和频率上限，使接入能力与安全边界可以在一个页面核查。
完整密钥只在创建时展示，数据库保存摘要，日志中不得记录密钥明文。这让外部 AI 客户端可以使用业务工具，同时仍然进入平台身份体系。
安全不是附加项
工具被模型选中不代表操作可以直接执行。所有调用仍需经过身份恢复、参数校验、数据权限与业务规则，敏感写操作还应增加用户确认。
销售行业案例：AI 分析商机但不越权
假设销售负责人提出：“列出我负责团队中 30 天未跟进、预计金额较高的商机，并给出本周行动建议。”
模型首先理解筛选条件，然后选择商机查询与跟进查询工具。CRM 按当前租户、组织与数据权限返回结果；模型对结构化结果归纳，生成优先级和行动建议。负责人看到的是自己有权访问的数据，模型也不能通过修改提示词获得其他团队客户。
如果下一步需要写入跟进记录，系统还应要求用户确认，并继续执行 CRM 校验。AI 可以降低操作成本，但不应成为绕过审批和权限的捷径。
从“能聊天”到“能协作”
AI + MCP 的价值，不是让 CRM 多一个新入口，而是建立可治理的业务协作方式：模型负责自然语言推理，工具契约定义可用能力，领域服务守住规则和数据，平台身份体系提供安全边界。
蝉鸣 CRM 已经将这条链路落到独立模块、接口和调度代码中。
一次业务问题如何穿过完整调用链
销售负责人提出“查询长期未跟进的高价值客户”后，ChatClient 组合模型配置、会话和当前身份。模型不读取数据库，只从已注册工具的名称、描述与参数中选择能力。McpServerToolService 管理工具暴露，Dispatcher 定位 Provider，RemoteMcpToolProviderService 通过 Feign 统一契约把请求交还 CRM。
CRM 侧的 Customer360McpTool、CustomerVisitMcpTool、CustomerPriorityMcpTool、BusinessMcpTool 和 ContractMcpTool 不是通用 SQL，而是边界明确的领域工具。它们复用客户归属、租户、组织和数据权限。结果返回后模型负责归纳；若用户要求创建记录，则调用写工具并再次校验权限与业务状态。
参数不完整时应补充询问，工具不可用时明确返回能力状态，越权时以业务错误结束，不能靠改提示词重试。日志需要关联会话、模型、工具、用户、租户与结果，才能审计回答使用了哪些事实。
工具治理比模型选择更重要
高质量工具只完成一件可解释任务，参数区分必填、枚举和时间范围，返回最小必要字段。写操作应具备幂等标识、确认语义和审计结果。Access Key 支持外部 MCP Client 接入，但仍需绑定允许使用的工具与访问范围，它不是超级权限。
mesh-ai 可以适配不同模型、Agent 和向量存储；模型会变化，客户、商机和合同契约不能变化。稳定的 MCP 工具与 Feign 接口把模型选择和领域实现隔离，让升级 AI 时不必重写 CRM。
边界
检索、归纳、拜访提纲适合 AI；批量删除、无确认合同变更和跨租户查询不应直接开放。更多访问判定见多租户与数据权限。