一、为什么 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_targetsend_text_messagesend_image_messagesend_file_messageupload_filecreate_upload_sessionsend_mail_notificationcreate_meeting_and_send_inviteinvite_users_to_meeting这几个工具组合起来基本就能覆盖日常消息发送的大部分场景。1. resolve_chat_target这个工具很关键。因为真实用户不会说请把这条消息发给 chatId123456用户更可能说给张三发一句话通知研发群一下给系统消息发一段祝福所以第一步通常不是发消息而是解析目标。这个工具会根据名称去解析单聊用户或群聊目标支持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”而是一个真正能操作业务系统的智能执行层。
在 IM 项目里落地 Skill + MCP：我给 V-IM RPO 做了一套可被 AI 直接调用的消息能力
发布时间：2026/5/20 10:07:33
一、为什么 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_targetsend_text_messagesend_image_messagesend_file_messageupload_filecreate_upload_sessionsend_mail_notificationcreate_meeting_and_send_inviteinvite_users_to_meeting这几个工具组合起来基本就能覆盖日常消息发送的大部分场景。1. resolve_chat_target这个工具很关键。因为真实用户不会说请把这条消息发给 chatId123456用户更可能说给张三发一句话通知研发群一下给系统消息发一段祝福所以第一步通常不是发消息而是解析目标。这个工具会根据名称去解析单聊用户或群聊目标支持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”而是一个真正能操作业务系统的智能执行层。
