MCP 实战：我们如何让 AI 直接操作一个真实的 VR 全景 SaaS 平台

最近我们在芊云全景上线了一套 MCP 服务。这次做的事情不是再给 SaaS 后台增加一个 AI 聊天框而是尝试解决一个更实际的问题能不能让 AI 不只是告诉用户“应该怎么操作”而是真正调用业务系统完成操作目前第一版已经接入了作品、场景、素材、背景音乐、语音讲解、热点等 VR 全景业务能力。用户可以直接使用自然语言描述需求例如查询一下我最近创建的全景作品。看看这个作品有哪些场景。给这个作品找一首适合展厅的背景音乐。给大厅场景生成一段语音讲解。在入口场景添加一个跳转到展厅的热点。AI 根据任务选择对应的 MCP 工具调用芊云全景真实业务接口然后把执行结果返回给用户。从产品交互角度看这意味着 AI 开始从回答问题逐渐变成理解任务 → 选择工具 → 执行业务 → 返回结果 → 继续处理。本文主要分享这次实践背后的思路。一、为什么我们没有继续做一个 AI 聊天框现在很多 SaaS 产品接入 AI 的第一反应是在页面右下角增加一个聊天窗口。用户可以问怎么修改作品名称AI 回答请打开作品管理然后点击编辑……从知识问答的角度这当然有价值。但实际使用一段时间以后会发现一个明显的问题AI 最终还是把工作重新交给了用户。用户仍然需要找到正确页面找到对应作品进入编辑器找到具体配置填写参数保存再检查结果。也就是说AI 优化了“怎么做”的学习成本却没有真正降低“执行”的成本。而 VR 全景平台本身又是一个典型的复杂 SaaS。一个完整作品可能包含作品基础信息数十个全景场景图片、视频、音频素材场景热点场景跳转关系背景音乐语音讲解导览逻辑插件发布和传播配置随着平台功能越来越多传统做法只能不断增加菜单、按钮、弹窗、配置页面。所以我们开始思考另一条路线软件继续负责提供可靠的业务能力AI 负责理解用户真正想完成什么。这也是这次接入 MCP 的核心原因。二、MCP 到底解决了什么MCP全称Model Context Protocol如果不讨论协议细节可以把它简单理解为让 AI 以标准方式发现和调用外部工具。传统大模型擅长的是用户 ↓ 自然语言 ↓ 大模型 ↓ 生成文字加入工具以后流程变成用户 ↓ 自然语言 ↓ AI / Agent ↓ 理解任务 ↓ 选择工具 ↓ 调用真实业务 ↓ 获得结果 ↓ 继续推理 / 执行因此MCP 真正有价值的地方并不是“又多了一个协议”。而是它让 AI 和真实软件能力之间有了一层相对标准化的连接方式。对于 SaaS 产品而言这个变化尤其重要。三、芊云全景的 MCP 架构我们目前的整体思路大致可以抽象成┌────────────────────────────┐ │ 支持 MCP 的 AI 客户端 │ │ │ │ Chat / Agent / AI Workflow │ └─────────────┬──────────────┘ │ │ MCP ▼ ┌────────────────────────────┐ │ 芊云全景 MCP 入口 │ │ │ │ 鉴权 / 限流 / Schema / 路由 │ └─────────────┬──────────────┘ │ ┌───────┼────────┐ │ │ │ ▼ ▼ ▼ 作品工具 场景工具 素材工具 │ │ │ ├───────┼────────┤ ▼ ▼ ▼ 音乐工具 语音工具 热点工具 │ ▼ 芊云全景真实业务服务这里有一个设计原则非常重要MCP 不应该绕过原业务系统重新实现一套业务逻辑。MCP 更适合作为 AI 与业务系统之间的适配层。真正的权限判断数据隔离业务校验数据修改状态管理仍然应该由原有业务服务负责。否则 MCP 很容易逐渐发展成第二套后端。四、我们没有把所有 API 直接暴露给 AI这是做 MCP 时一个很容易踩的坑。假设后台有 200 个 API。最简单粗暴的方式是把 200 个接口全部包装成工具。理论上可行。实际上 AI 的工具选择质量很容易迅速下降。工具越多名称越接近参数越相似上下文越大选择错误概率越高后续维护成本也越高。所以我们的第一版采用了分层能力设计。大致按照业务域划分作品 ├── 查询作品 ├── 读取详情 ├── 创建作品 ├── 修改信息 └── 作品评分 场景 ├── 查询场景 ├── 场景详情 ├── 修改场景 └── 删除场景 素材 ├── 查询 ├── 上传 ├── 修改 ├── 删除 └── 下载 背景音乐 ├── 音乐搜索 ├── 标签 ├── 智能匹配 └── 配置作品音乐 语音讲解 ├── 主播查询 ├── 文字转语音 ├── 任务查询 └── 添加作品讲解 热点 ├── 查询热点 ├── 文本热点 └── 场景跳转热点用户并不需要知道这些工具叫什么。比如用户只需要说帮我找一下最近发布的那个展厅作品。AI 再去决定应该调用哪个工具。五、Schema 对 AI 工具调用非常重要真正把 MCP 接到业务以后一个很现实的问题是AI 会填错参数。例如ID 类型错误枚举错误必填字段缺失字段名称猜错不应该传的字段也传了同一个业务概念存在多个 ID所以我们给不同工具分别定义了比较明确的 Schema。理想情况下一个工具不仅应该告诉 AI“这个工具是修改作品的。”还应该明确告诉它每个参数是什么意思哪些字段必填数据类型是什么枚举有哪些哪些字段不能同时出现一个正确调用应该长什么样。当调用失败以后也尽量返回可以让 AI 自己修正的结构化错误。这样才有机会形成第一次调用 ↓ 参数错误 ↓ 读取错误信息 ↓ 自动修正参数 ↓ 第二次调用成功而不是每次失败都重新把问题丢给用户。六、一个真实使用过程是什么样的比如用户告诉 AI帮我看看最近的几个全景作品。AI 首先调用作品查询工具。返回作品 A 作品 B 作品 C ...用户继续看一下作品 B 有哪些场景。AI 再调用场景工具。拿到大厅 展厅 会议室 走廊 ...然后用户说给大厅找一首轻松一点的背景音乐。AI 可以继续调用音乐搜索或者智能匹配工具。返回几首候选音乐。用户确认后再执行设置背景音乐。整个过程中用户并不需要先理解背景音乐在哪个页面配置也不需要记住作品 ID、音乐 ID、对应接口参数分别是什么AI 负责把自然语言需求转换成业务系统可以执行的调用。七、真正值得关注的是“连续任务”如果 MCP 只能完成查询一条数据。其实价值还比较有限。Agent 更有意思的地方在于一个用户目标往往会对应多个工具调用。比如用户说帮我检查一下这个全景作品还有哪些地方需要优化。未来 AI 可以按照类似流程处理读取作品 ↓ 查询全部场景 ↓ 检查作品信息 ↓ 读取热点 ↓ 检查背景音乐 ↓ 检查语音讲解 ↓ 读取作品评分 ↓ 汇总问题 ↓ 给出优化建议 ↓ 用户确认 ↓ 继续执行修改这时候用户描述的是一个业务目标。而不是某个按钮操作。我认为这才是 Agent 对 SaaS 软件最有价值的地方。八、读操作容易写操作才是真正的难点让 AI 查询作品并不危险。让 AI修改作品删除场景上传素材添加热点发布内容性质就完全不同了。所以做生产环境 MCP 时不能把重点只放在“AI 能不能调通接口”还需要考虑1. 身份认证AI 当前到底代表哪个用户2. 数据权限这个用户是否真的有权限操作目标作品3. 参数校验AI 生成的参数是否合法4. 限流如果 Agent 出现循环调用怎么办5. 高风险操作删除、发布、批量修改是否应该额外确认6. 操作复查写操作完成后是否应该重新查询验证结果我们目前的 MCP 服务入口会经过开发者 Key ↓ 身份识别 ↓ 请求限流 ↓ Schema 校验 ↓ 业务权限 ↓ 真实业务服务也就是说AI 获得的是工具使用能力不是绕开系统权限的超级管理员权限。这是两件完全不同的事情。九、为什么我们还做了一个9kvrnpm 包MCP 解决的是AI 如何调用芊云全景能力。但对于开发者而言还存在另外一个问题如何真正开发和扩展 VR 全景应用所以我们同时维护了官方 npm 包npx 9kvr目前9kvr同时承担两类职责CLI SDKCLI负责插件开发生命周期登录 ↓ 初始化插件 ↓ 本地开发 ↓ 构建 ↓ 发布 ↓ 上线例如npx 9kvr login --key开发者Key初始化插件npx 9kvr plugin 插件ID发布npx 9kvr pub上线指定历史版本npx 9kvr online --history-idID十、SDK 解决的是 VR 宿主能力除了 CLI9kvr还提供插件 SDK。开发者不需要直接依赖底层全景播放器内部对象。目前已经覆盖插件生命周期插件上下文场景读取和切换视角控制热点添加、更新、删除热点点击事件宿主事件插件配置渲染状态调试能力例如import { definePlugin, useScene, useDebug } from 9kvr export default definePlugin({ setup() { const scene useScene() const debug useDebug() scene.onSceneChange((packet) { debug.log(scene changed, packet) }) return { mount(el) { el.innerHTML 当前场景${scene.getCurrentSceneId()} } } } })开发者可以继续操作场景await scene.switchScene(scene-id)或者调整视角await scene.setView({ hlookat: 90, vlookat: 0, fov: 80, duration: 800 })也就是说现在正在逐渐形成这样一套关系芊云全景 │ ┌──────────┴──────────┐ │ │ MCP 9kvr │ CLI SDK │ │ AI Agent 开发者 │ │ └──────────┬──────────┘ │ VR 全景能力十一、下一步让 AI 不只使用平台还能帮助开发平台能力这是我们认为更有意思的一件事情。第一阶段AI 帮用户使用芊云。比如管理作品、场景和素材。再往后AI 帮开发者开发芊云插件。例如开发者说帮我做一个场景导航插件。AI 可以查询芊云插件开发规范读取 SDK 能力创建插件工程编写代码调试构建发布测试版本。于是自然语言 ↓ AI ↓ MCP 获取平台上下文 ↓ 9kvr 创建开发工程 ↓ SDK 开发 ↓ 构建 / 发布这也是我们持续建设 MCP、CLI、SDK 和插件体系的原因。它们并不是几个完全独立的功能。最终目标其实是一致的让 AI 真正进入 VR 全景内容生产和开发工作流。十二、MCP 不会让传统后台立刻消失这里也需要说一个比较现实的判断。Agent 并不会马上替代全部 GUI。比如精细调整一个热点的位置观察复杂的全景空间关系大量素材的视觉筛选精确的 UI 配置很多工作依然更适合图形界面。所以更可能出现的形态是AI Agent 负责 理解目标 批量操作 自动检查 查找能力 串联流程 GUI 负责 精确编辑 视觉操作 结果确认 复杂配置两者并不是竞争关系。而是AI 正在成为软件新的操作入口。十三、我们对 AI SaaS 的一个判断过去的软件使用方式是用户学习软件 ↓ 理解菜单 ↓ 理解按钮 ↓ 理解参数 ↓ 完成任务未来可能逐渐变成用户描述目标 ↓ AI 理解意图 ↓ AI 调用工具 ↓ 软件执行 ↓ 用户验收结果这里真正发生变化的不只是有没有 AI。而是软件的人机交互模型正在发生变化。对于复杂 SaaS 来说尤其如此。功能越多、业务流程越长Agent 能够提供的价值反而越明显。最后芊云小助手 MCP 第一版目前已经正式上线。现阶段已经接入作品管理场景管理素材管理背景音乐语音讲解热点管理芊云知识查询部分开发者能力这仍然只是第一阶段。我们接下来会继续尝试让 AI 从“知道怎么做”逐渐变成“真正帮助用户做完”。对于我们来说MCP 最值得关注的也不是协议本身。而是它背后的变化AI 正在开始真正进入软件。相关地址芊云小助手 MCPhttps://9kvr.cn/html/qianyun_mcp_assistant.html芊云小助手工作台https://9kvr.cn/tour/workbench/robot9kvr 官方 npm 包https://www.npmjs.com/package/9kvr芊云全景https://9kvr.cn/