WeChat Bot 多平台 IM 助手
将微信、飞书、Telegram 和 WhatsApp 消息接入多种 AI 服务。
按维度查看评分与理由
项目通过联系人、群组和触发前缀白名单限制多数自动回复，并明确说明微信消息落入本地 JSONL、分析样本可能发送给所选 AI 服务，因此最小权限和数据流说明较强；但 Lark、Telegram 私聊默认可回复，工具还能读取聊天、联系人、收藏及朋友圈等广泛数据。登录扫码和平台授权提供初始同意，却没有逐次发送或分析确认。密钥放在 .env 中，但未见加密存储、日志脱敏、数据保留期限、删除流程或访问控制。依赖清单包含已被文档明确称为不活跃的 Wechaty 组件和非常旧的 Puppeteer，且没有审计、锁定策略或漏洞缓解证据，因此依赖安全计 0。外部发送行为和触发条件有说明，但自动回复本身没有事务性撤销；也未提供回滚机制。作者、贡献者及主要上游服务得到标注，但发布者身份未由给定材料验证，第三方组件归属也没有形成完整清单。
README 中的主要命令与 package.json 脚本大体对应，服务、CLI 和代理模式形成相对连贯的产品描述；扣分来自 LICENSE.md/README 声明 MIT、package.json 却声明 ISC，以及部分等价命令和服务命名存在歧义。项目依赖多个云 API、网络代理、外部 CLI、Webhook、微信非官方协议和不活跃的 Wechaty 生态，虽给出部分替代方式和排障提示，仍有明显可用性风险。FAQ 罗列常见故障检查项，但没有提供实现层面的结构化错误、错误码或恢复语义证据。
文档覆盖个人私聊、群聊、统计分析、本地模型、云模型以及微信、Lark、Telegram、WhatsApp 等明确场景，受众和用法充分。它清楚区分本地统计与会向 AI 发送样本的深度分析，也说明仅处理文本、各平台授权要求及协议风险。白名单、群聊提及、前缀和自动回复开关的触发规则具体，故相关两项给满分。环境方面提供 Node.js 版本、Docker、代理、中国大陆镜像及多平台配置，但未完整交代 wx-cli 的操作系统兼容性、资源要求、Webhook 部署安全和所有外部 CLI 的版本约束。
README 结构清晰，包含功能表、快速开始、逐平台配置、测试、定制点、警告、FAQ 和 Docker 示例；安装说明、示例及已知限制都较完整。命令名称总体稳定，但 ChatGPT 等服务大小写、多个入口别名及 302.AI 环境变量风格不统一。LICENSE.md 是完整 MIT 文本，但 package.json 的 ISC 声明造成实质冲突，因此未给满分。package.json 只有 1.0.2 版本，虽发布文件列表提到 RECORD.md，所给材料没有变更记录内容、发布策略或兼容性承诺。材料标识作者并欢迎 PR，但没有维护周期、安全报告渠道或明确支持责任。
文档给出可直接使用的命令、配置和典型工作流，输出具备实际可操作性；但几乎没有展示分析结果格式、回复质量、数据模式或下游消费约定。把多个 IM 渠道、本地微信数据、统计分析和多模型回复统一到一个 CLI，显示出较高的增量价值。项目同时提供本地模型、无 LLM 的统计模式和多种云服务选择，并提示付费、余额、协议及封号风险；不过没有量化令牌费用、基础设施成本、延迟、资源占用或运营负担。
不少声明可追溯到具体命令、环境变量、脚本或源码路径，package.json 也能交叉印证 CLI、依赖和测试入口；但未提供相关实现文件，无法静态核对消息过滤、存储和平台行为的实际实现。README、许可证和包元数据提供一定交叉来源，却存在 MIT 与 ISC 冲突。文档会使用“理论上”“社区反馈”等措辞区分部分推测，并明确标示风险；然而 GitHub Trending 第一名、稳定性及功能可用性等若干陈述没有所给文件中的独立佐证。
- 在使用云模型执行 /analyze 前，应假定近期聊天样本会离开本机；先取得参与者同意，并补充脱敏、最短保留期和删除机制。
- 微信默认协议及 Wechaty 依赖被文档明确描述为不活跃或可能导致警告、封号；不要把生产账号或关键业务依赖于该路径。
- Lark 和 Telegram 私聊默认回复；部署前应显式设置聊天与用户白名单，并保持群组自动回复关闭。
- package.json 声明 ISC，而 README 和 LICENSE.md 声明 MIT；分发或商用前必须澄清实际许可证。
- 对依赖执行独立安全审计并更新或隔离旧版 Puppeteer、Wechaty 及其 puppet 组件；所给材料没有漏洞缓解证据。
- 本地 JSONL 聊天记录缺少明确的加密、权限、轮换、保留和清理说明，不应默认视为安全存储。
这个 Agent 能做什么，适合哪些场景？
WeChat Bot 是一个基于 Wechaty 的自托管 IM 自动回复与聊天分析项目，并提供统一的 `wb` 命令行入口。它可从微信扫码会话、飞书事件流、Telegram Bot API 长轮询和 WhatsApp Cloud API Webhook 接收消息，再交给 Pi、ChatGPT、DeepSeek、Ollama、Claude、Kimi 等服务生成单轮回复。项目还通过 OpenCLI `wx-cli` 读取本地微信会话、联系人、群成员、收藏与朋友圈缓存，并可对群聊或好友执行本地统计及 AI 深度分析。消息可记录到 `.data/wechat/messages.jsonl`，而微信、飞书和 Telegram 的回复范围由白名单、群聊提及或前缀等规则限制。它适合愿意自行维护 Node.js 服务、平台凭据和公网 Webhook 的团队或个人，但微信 Web 协议存在明确的警告及封号风险。
端到端流程因平台而异：微信通过 Wechaty 扫码登录并接收文本消息；飞书通过 lark-cli event consume im.message.receive_v1 --as bot 消费事件；Telegram 使用官方 Bot API 长轮询；WhatsApp 则运行可供 Meta 访问的 Cloud API Webhook。wb agent --im <wechat|lark|telegram|whatsapp> --agent pi 可把消息交给 Pi，wb start --serve <service> 则调用 ChatGPT、DeepSeek、Ollama、Claude、Kimi、Dify、豆包、通义等已配置服务，并将结果发回原 IM。微信消息可追加写入本地 JSONL；wb wx sessions/history/contacts/members/favorites/sns-feed 等命令通过 wx-cli 查询本地缓存。wb analyze --room 和 wb analyze --friend 可输出纯本地统计，或将近期消息样本发送给所选服务进行深度分析。内置 /stats 和 /analyze 命令默认只对获准联系人或群聊开放。
- 需要在获准微信私聊或被点名的群聊中自动答复消息，同时避免机器人响应所有来信的个人用户。
- 希望用同一个 Pi 项目代理连接微信、飞书、Telegram 和 WhatsApp 的开发者。
- 需要从本地微信缓存统计群聊活跃度、查看群成员，或分析某位好友近期对话的用户。
- 希望在不调用云端模型的情况下，使用
--stats-only对本地 JSONL 消息执行统计的隐私敏感用户。 - 需要在飞书中搜索、读取和发送消息，并通过
im.message.receive_v1事件实现自动回复的团队。 - 希望在本机 Ollama与 OpenAI、Claude、DeepSeek、Kimi 等云端服务之间切换回复后端的自托管用户。
这个 Agent 有哪些优点和局限？
- 一个
wbCLI 覆盖微信、飞书、Telegram 和 WhatsApp，并针对各平台提供接收、发送或事件处理入口。 - 回复后端不限于单一厂商，可在 Pi、ChatGPT、DeepSeek、Ollama、Claude、Kimi、Dify 等服务间切换。
- 除自动回复外，还能通过
wx-cli访问本地微信会话、联系人、群成员、收藏和朋友圈缓存。 - 提供
--stats-only本地统计路径，无需配置 LLM，也不会为了统计而调用 AI 服务。 - 白名单、群聊提及和回复前缀为自动回复提供了明确的触发边界。
- 微信默认 Web 协议可能触发警告或封号；文档还指出 Wechaty 及 padlocal 相关维护状态不理想。
- 部署涉及 Node.js、
.env、各平台凭据以及若干外部 CLI；不同 IM 渠道的授权与配置方式并不统一。 - WhatsApp 接收消息要求 Meta 能访问的公网 HTTPS Webhook，纯本地封闭部署无法直接接收其事件。
- 非文本微信消息不会进入自动回复管线，WhatsApp 默认也只回复入站文本消息。
- 将
/analyze用于云端服务时会发送近期消息样本，处理私人对话前需要评估隐私边界与服务成本。
如何安装或部署这个 Agent？
要求 Node.js 18 或更高版本，建议使用 LTS。执行：
npm i
cp .env.example .env
npm link在 .env 中至少配置 BOT_NAME、ALIAS_WHITELIST、ROOM_WHITELIST、WECHAT_STORE_MESSAGES='true'、PI_BIN='pi' 和 PI_AGENT_ARGS='--print --no-session'。若系统没有全局 pi，可将 PI_BIN 留空，项目会通过 npx --yes @earendil-works/pi-coding-agent 启动。使用云端模型时还需提供对应凭据，例如 OPENAI_API_KEY、CLAUDE_API_KEY 或 DEEPSEEK_FREE_TOKEN；使用 Telegram 或 WhatsApp 时分别配置 Bot Token 或 Cloud API 凭据。首次微信运行命令为 wb agent --im wechat --agent pi，随后扫描终端二维码。也可构建并运行 Docker 镜像：docker build . -t wechat-bot，然后执行 docker run -d --rm --name wechat-bot -v $(pwd)/.env:/app/.env wechat-bot。
如何使用这个 Agent？
微信 Pi 模式运行 wb agent --im wechat --agent pi；传统模型模式可运行 wb start --serve ollama、wb start --serve ChatGPT 或 wb start --serve deepseek。私聊发送者必须出现在 ALIAS_WHITELIST，群聊必须位于 ROOM_WHITELIST 且消息需提及 BOT_NAME；还可设置 AUTO_REPLY_PREFIX。本地数据先执行 wb wx init，再使用 wb wx sessions、wb wx history、wb wx members 或 wb wx sns-search。分析示例为 wb analyze --room "群名" --stats-only 和 wb analyze --friend "好友别名" --serve ollama。飞书、Telegram 和 WhatsApp 分别以 wb agent --im lark --agent pi、wb agent --im telegram --agent pi、wb agent --im whatsapp --agent pi 启动；WhatsApp 还必须把公开 HTTPS 地址 https://your-public-domain.example/webhook/whatsapp 配置为 Meta Webhook。可通过 npm run test:analysis 与 node ./cli.js --help 检查本地分析模块和 CLI。
这个 Agent 与同类方案有什么区别？
Pi 模式把 Pi 作为统一项目代理，可通过四种 IM 渠道提供默认的单轮、非交互式回复；--serve 模式则直接选择 ChatGPT、DeepSeek、Ollama、Claude 等提供方。Ollama 更适合希望在本地处理内容的用户，而 OpenAI、Claude、Kimi 等云端服务需要 API 密钥、可用余额和网络连接。--stats-only 与这些生成式后端不同，只读取本地数据并生成统计结果。
常见问题
必须购买或配置大模型 API 吗？
wb wx ...、飞书操作命令或 --stats-only 时无需 LLM。云端自动回复和深度分析需要对应 API 密钥、余额与网络；Ollama 可作为本地服务。机器人启动后会回复所有消息吗？
ALIAS_WHITELIST 限制，群聊还要求 ROOM_WHITELIST 和对 BOT_NAME 的提及；其他平台也提供聊天、用户、前缀或群聊触发限制。使用微信账号是否安全？
聊天分析会把消息发送到外部服务吗？
/stats 和 --stats-only 只读取本地 JSONL。/analyze 或带 --serve 的深度分析会把近期消息样本发送给当前服务或代理；私人聊天宜优先使用本地模型或本地 Pi 配置。