Claude Skill

YanHaidao/wecom

WeCom 是一个企业微信 AI 机器人与 OpenClaw 插件,将大语言模型集成到企业微信中,实现智能助手、自动化流程和自建 AI 应用。

概览

Stars267
Forks42
语言TypeScript
最后更新2026-05-14
最近同步2026-06-20
前往 GitHub

仓库信息

拥有者YanHaidao
仓库wecom
完整名称YanHaidao/wecom
Repo ID1,150,477,726

安装这个 Skill

git clone https://github.com/YanHaidao/wecom.git

Registry 信息

类型mcp_server
质量分75/100
验证状态readme_parsed
最近验证2026-06-18
平台
MCPOpenClaw
能力
pdfimage
识别文件
README.mdpackage.json
配置键
YOUR_BOT_IDYOUR_BOT_SECRETYOUR_CORP_IDYOUR_AGENT_SECRETAGENT_TOKENAGENT_AES_KEYURLPRIMARY_AGENT_SECRETPRIMARY_CALLBACK_TOKENPRIMARY_ENCODING_AES_KEYPACKAGE_JSON

项目简介

WeCom 是一个企业微信 AI 机器人和 OpenClaw 微信插件,将大语言模型(LLM)集成到企业微信中。它支持智能助手、自动化流程响应以及自建 AI 应用,作为智能体网关实现无缝沟通与任务自动化。

英文描述

企业微信 AI 机器人、OpenClaw 微信插件、WeCom 大模型接入、企微 AI 助手、企业微信流式响应、微信智能体网关、企微自建应用 AI、OpenClaw 企微插件、微信机器人插件

要点

  • 企业微信 AI 机器人集成
  • 支持 OpenClaw 微信插件
  • 大语言模型(LLM)接入企业微信
  • 企业微信自动化流程响应
  • 自建 AI 应用网关
  • 微信生态智能体网关

使用场景

  • 为企业微信客服部署 AI 助手
  • 在企业微信群中自动化流程响应
  • 在企业微信内构建自定义 AI 应用
  • 集成基于大模型的聊天机器人用于内部沟通
  • 创建基于微信业务流程的智能体网关

README 摘要

# OpenClaw 企业微信(WeCom)Channel 插件 <p align="center"> <img src="https://img.shields.io/badge/Original%20Project-YanHaidao-orange?style=for-the-badge&logo=github" alt="Original Project" /> <img src="https://img.shields.io/badge/License-ISC-blue?style=for-the-badge" alt="License" /> </p> > [!WARNING] > **原创声明**:本项目涉及的“多账号隔离与矩阵路由架构”、“Bot+Agent双模融合架构”、“长任务超时接力逻辑”及“全自动媒体流转接”等核心设计均为作者 **YanHaidao** 独立思考与实践的原创成果。 > 欢迎技术交流与合规引用,但严禁任何不经授权的“功能像素级抄袭”或删除原作者署名的代码搬运行为。 <p align="center"> <strong>🚀 企业级多模式 AI 助手接入方案(统一运行时架构)</strong> </p> --- ## 💡 核心价值:为什么团队会真正选择这个插件? 企业真正需要的,不是“把一个模型接进企业微信”,而是让企业微信变成一个**能长期工作的 AI 协作入口**。 大多数团队最终只关心五件事: - 能不能先低门槛接起来,而不是先做一轮重部署 - 多人同时使用时,会不会串上下文、串身份、串会话 - 长任务会不会因为长连接窗口太短而白跑 - 能不能既有实时对话体验,又能做正式推送和稳定投递 - AI 能不能真正进入文档、日程、会议、待办、通讯录这些协作层,而不只是停留在聊天框 常见方案通常会很快碰到边界: - **只用 Bot WS**:接得快、聊得顺,但会受到单连接、心跳保活、会话边界和组织级广播能力的限制 - **只用 Agent**:能力强、治理清晰,但部署门槛更高,对话体验不如 Bot WS 丝滑 - **只选单一路径**:团队最后往往被迫在“体验”和“能力”之间二选一 本插件的价值,就在于把这些原本互相冲突的目标,尽量同时成立。 ### 您真正会得到什么? 1. **多人共用一个入口,但上下文不会串** - **问题本质**:企业里真正难的不是“接入一个机器人”,而是让几十上百个人同时使用时,仍然保持每个人的上下文隔离。 - **插件做法**:按 `(底层账号 + 部门/群组/人员)` 动态切分运行上下文和 Agent 实例。 - **用户收益**:同一个企业微信入口可以承接多人并发使用,而不会出现“张三的问题让李四接上回答”的串流灾难。 2. **长任务不白跑,回复不轻易丢** - **问题本质**:企业微信长连接的响应窗口很短,而推理模型的思考时间往往很长。 - **插件做法**:先保活,再流式推进;必要时走备用投递路径,把最终结果交付出去。 - **用户收益**:更敢把复杂任务、长文本分析、报告生成交给 AI,而不是每次都担心“算完了却发不回来”。 3. **实时对话体验和正式投递能力,不用二选一** - **问题本质**:实时聊天和组织级推送,往往不是同一条技术路径最擅长的事。 - **插件做法**:会话内实时交互、流式回复、异步追发优先走 `Bot WS`;组织级广播、冷启动触达、正式通知由 `Agent` 兜底。 - **用户收益**:日常使用时体验像聊天助手,正式落地时又有企业应用该有的稳定性和控制力。 4. **AI 不只会聊天,还能进入企业微信协作层** - **问题本质**:如果 AI 只能回消息,信息最终还是散落在聊天流里,业务并没有真正被推进。 - **插件做法**:把企业微信原生协作能力按两条能力平面接入 OpenClaw。 - **用户收益**:AI 不仅能回答问题,还能真正参与文档、日程、会议、待办和通讯录相关工作。 5. **小团队能低门槛上手,大团队也能正式上线** - **问题本质**:小团队怕折腾,大团队怕失控。 - **插

话题

暂无话题

探索更多

数据来自 GitHub,同步时间:2026-06-20