最近在做 v-im-server-pro 时，我补了一套自己觉得很实用的能力：Skill + MCP。
它不是那种"接个大模型聊聊天"的玩法，而是让 AI 真正能接入业务系统，调用项目里的消息能力，完成"找人、找群、发消息、发文件、发会议邀请"这一整套动作。
这篇文章主要分享一下，这套能力在 V-IM 项目里是怎么设计的、解决了什么问题，以及为什么我觉得这种方式，比单纯写提示词靠谱得多。
一、为什么 IM 项目特别适合做 MCP
很多业务系统接 AI，第一反应通常是：
- 做个问答助手
- 做个知识库
- 给后台加个智能客服入口
这些当然都可以做，但对于 IM 项目来说，更自然的一条路其实是：
把聊天系统本身的能力开放给 AI 调用。
因为聊天系统最核心的能力，本来就是"把消息发给正确的人或群"。
举几个很典型的场景：
- 给张三发一句提醒
- 通知研发群晚上发版
- 给系统消息发一段公告
- 发一张活动海报到某个群
- 创建一个会议并把邀请卡片发出去
这些需求，用户天然就会用自然语言表达。
如果 AI 能理解这句话，再直接调用系统能力完成动作，它的价值会比单纯"生成一段文案"高很多。
所以我在 v-im-server-pro 里做的这件事，本质上就是：
把 V-IM 的消息能力标准化成 MCP 工具，再用 Skill 约束 AI 的调用方式。
二、项目里是怎么落地的
当前项目结构里，和这件事最相关的是 v-im-server-mcp 模块。
这个模块的作用很明确：
把 V-IM 的聊天发送能力，包装成标准 MCP Server，对外暴露给支持 MCP 的客户端或者 Agent 使用。
从配置上看，它的默认地址是：
http://localhost:8080/vim/mcp
服务名是：
v-im-mcp-server
同时它不是一个随便暴露出来的"裸接口"，而是带有比较清晰的业务约束，例如：
- 消息发送默认需要 mcp.message.send
- 文件上传默认需要 mcp.file.upload
- 有每分钟调用限流
- 有消息长度限制
- 有文件名长度限制
- 有目标解析候选数量限制
这一点我很看重，因为它意味着：
AI 不是直接绕过业务规则去操作系统，而是在现有权限和安全边界之内工作。
三、这套 MCP 提供了哪些能力
目前 V-IM 这层 MCP 已经覆盖了比较完整的消息操作链路：
- resolve_chat_target
- send_text_message
- send_image_message
- send_file_message
- upload_file
- create_upload_session
- send_mail_notification
- create_meeting_and_send_invite
- invite_users_to_meeting
这几个工具组合起来，基本就能覆盖日常消息发送的大部分场景。
1. resolve_chat_target
这个工具很关键。
因为真实用户不会说：
请把这条消息发给 chatId=123456
用户更可能说：
给张三发一句话
通知研发群一下
给系统消息发一段祝福
所以第一步通常不是发消息，而是解析目标。
这个工具会根据名称去解析单聊用户或群聊目标，支持：
- friend / group
- 昵称或群名
- 精确匹配
- 候选限制
- 登录名、手机号后缀、部门等辅助过滤
也就是说，AI 可以先把"自然语言对象"转换成"系统里的真实目标"。
2. send_text_message
发送文本消息。
这是最基础、最常用的工具。
一般流程就是：
- 先解析目标
- 拿到 chatId
- 发送正文
3. send_image_message / send_file_message
发送图片和文件消息。
这里也体现出业务系统和 AI 调用之间的一个现实问题：
AI 拿到的不一定是系统可直接发送的资源。
比如图片可能只是一个远程链接，或者文件只是本地内容。
所以需要先通过上传能力转成系统可访问 URL，再继续发送。
4. 会议和邮件能力
这部分不是传统意义上的聊天消息，但它们和"沟通协作"高度相关，所以也一起放进了 MCP：
- 创建会议并发邀请
- 给会议追加邀请人
- 发邮件通知
这会让 AI 的能力从"发一条消息"，进一步延伸到"发起协作动作"。
四、为什么还要配一个 Skill
如果只有 MCP，其实还不够。
因为 MCP 只解决了一件事：
工具可以被调用
但另一个问题是：
AI 知不知道什么时候该调用哪个工具，顺序是什么，失败时怎么处理
这就是 Skill 的作用。
在这个项目里，我补了一个技能：
skills/v-im-send-message
它的本质不是代码，而是一套给 Agent 用的"执行策略"。
简单说，它是在教另一个 AI：
- 用户说"给张三发消息"时，先不要乱猜 chatId
- 私聊和群聊要先判断
- 如果只给了名字，先走 resolve_chat_target
- 如果要发图片或文件，先确认有没有可访问 URL
- 如果解析结果不唯一，不要盲发
- 成功后应该把哪些关键结果回报给用户
所以我一直觉得：
MCP 是能力层，Skill 是行为层。
两者结合起来，AI 才不是"能看到工具"，而是"知道怎么稳妥地使用工具"。
五、这个 Skill 具体做了什么
当前这个 v-im-send-message 技能目录里，主要有三类文件。
1. SKILL.md
这是技能主说明。
这里面定义了：
- 这个技能在什么场景下触发
- 适合处理哪些消息操作
- 标准发送流程是什么
- 什么时候必须先解析
- 什么时候不能直接发送
- 输出结果时要同步哪些信息
它最核心的一条原则就是：
优先解析目标，不要自己猜 chatId
这句话听起来简单，但对稳定性影响很大。
因为很多发送错误，不是接口调用错了，而是目标识别错了。
2. agents/openai.yaml
这个文件是技能的元信息配置。
它声明了技能的显示名称、简介、默认提示，以及依赖的 MCP 服务。
也就是说，在支持技能系统的环境里，AI 能明确知道这个技能依赖的是哪个 MCP 服务。
3. references/调用参考.md
这是调用参考文档。
我把常用工具、关键参数、推荐调用顺序、返回结果解释都放进去了。
这样主技能文档不会太长，细节又可以按需查阅。
这种拆法我觉得很适合工程化场景：
- 主文件负责策略
- 参考文件负责细节
- Agent 按需加载，减少上下文噪音
六、我为什么觉得这种方式比"写一段提示词"靠谱
很多人做 AI 接口时，会习惯这么干：
- 给模型一些接口说明
- 写一大段提示词
- 希望模型自己理解调用顺序和参数规则
这种方式在 Demo 阶段没问题，但一到业务场景，经常会出这些问题：
- 该先解析目标的时候直接发了
- 群聊和私聊判断错了
- 资源 URL 不可访问
- 候选目标不唯一时盲发
- 成功结果没有提炼给用户，直接贴一坨 JSON
这些问题本质上不是模型不聪明，而是没有工程化约束。
而 Skill + MCP 这套组合，解决的就是这个问题：
- MCP 负责把能力标准化
- Skill 负责把调用路径标准化
- 权限、限流、审计在业务边界内兜底
这样 AI 的行为就会从"依赖灵感"变成"依赖流程"。
这件事在业务系统里非常重要。
七、这套设计在 IM 场景里有什么实际价值
如果从产品角度看，我觉得它至少带来三类价值。
1. 让自然语言直接映射为业务动作
用户说一句：
通知研发群今晚发版
AI 不再只是帮你润色这句话，而是可以真的：
- 找到研发群
- 组织消息内容
- 调用发送工具
- 返回发送结果
这一步非常关键，因为它把 AI 从"建议者"变成了"执行者"。
2. 降低系统能力对人工操作的依赖
原本很多动作，需要运营、客服、管理员手工点来点去完成。
现在这些动作，如果权限允许，就可以由 Agent 直接完成。
对于 IM、协作、通知类系统来说，这个方向会越来越有价值。
3. 给后续智能体协作留出接口
一旦 MCP 能力建起来，后面其实就不只是"发消息"了。
你还可以继续扩展：
- 发审批提醒
- 发会议通知
- 发邮件
- 发文件
- 做跨插件协同动作
也就是说，MCP 不是一个孤立功能，它更像是 AI 接入整个业务系统的标准入口。
八、这次实践里，我最在意的几个点
1. 不要硬编码目标
发消息类操作里，最危险的不是"发失败"，而是"发错人"。
所以目标解析必须是第一层能力，而不是调用方自己拼。
2. Skill 要写给 AI，不是写给人看
技能文档不是产品说明书，也不是 README。
它的目标只有一个：让另一个 Agent 稳定执行。
所以要写清楚：
- 什么时候触发
- 用什么顺序
- 什么情况下停止
- 返回结果怎么解释
3. MCP 不应该脱离业务权限体系
如果 AI 可以直接越过权限发消息，那这套系统就很危险。
所以我很认同当前项目里把 scope、限流、路径、上传约束都配置化的做法。
九、我对 Skill + MCP 在业务项目里的判断
如果只是做一个"能聊天"的 AI，我觉得没必要折腾这么多。
但如果你想让 AI 真正进入业务流程，变成可执行的助手，那 Skill + MCP 是一条很值得走的路。
尤其是在 IM 这种天然以"沟通动作"为核心的系统里，它比传统问答式接入更贴近真实价值。
因为最后真正重要的不是：
AI 会不会回答
而是：
AI 能不能把正确的消息，用正确的方式，发给正确的人
这才是业务系统真正关心的结果。
十、后面还可以怎么扩展
基于现在这套能力，我觉得后面还可以继续往下做：
- 把更多插件能力 MCP 化
- 做更完整的消息模板和发送策略
- 补更细的审计日志和回执能力
- 为不同角色做不同的技能集合
- 让 Agent 不只发消息，还能串起会议、邮件、文件、通知全流程
如果这条路继续走下去，最终得到的不会只是"一个会聊天的 AI"，而是：
一个真正能操作业务系统的智能执行层。
结语
这次在 v-im-server-pro 里做 Skill + MCP，我最大的感受是：
AI 接入业务系统，关键不是模型多强，而是接口有没有标准化、流程有没有被固化、边界有没有被收住。
MCP 提供能力，Skill 提供策略。
当两者真正结合起来，AI 才会从"看起来懂业务"，变成"真的能做业务"。
如果你也在做 IM、协作、通知类系统，我很建议试试这个方向。它比单纯接一个聊天框，更接近业务落地。