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 获得的是工具使用能力，不是绕开系统权限的超级管理员权限。
这是两件完全不同的事情。
九、为什么我们还做了一个 9kvr npm 包？
MCP 解决的是：
AI 如何调用芊云全景能力。
但对于开发者而言，还存在另外一个问题：
如何真正开发和扩展 VR 全景应用？
所以我们同时维护了官方 npm 包：
npx 9kvr
目前 9kvr 同时承担两类职责：
CLI
+
SDK
CLI
负责插件开发生命周期：
登录
↓
初始化插件
↓
本地开发
↓
构建
↓
发布
↓
上线
例如：
npx 9kvr login --key=<开发者Key>
初始化插件：
npx 9kvr plugin <插件ID>
发布：
npx 9kvr pub
上线指定历史版本：
npx 9kvr online --history-id=<ID>
十、SDK 解决的是 VR 宿主能力
除了 CLI，9kvr 还提供插件 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 正在开始真正进入软件。
相关地址
芊云小助手 MCP：
https://9kvr.cn/html/qianyun_mcp_assistant.html
芊云小助手工作台：
https://9kvr.cn/tour/workbench/robot
9kvr 官方 npm 包：
https://www.npmjs.com/package/9kvr
芊云全景：
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
7
0- 0
已为社区贡献1条内容
所有评论(0)