chatgpt-wechat: an LLM assistant that reaches WeChat through WeCom

The ban problem chatgpt-wechat is built around

Personal WeChat accounts that automate replies get restricted. The README states the project's purpose directly: it is a ChatGPT personal assistant that can be used safely in WeChat by relaying through WeCom (企业微信), with no ban risk. That single design decision explains most of the rest of the repository. The bot is not a WeChat client at all. It is a WeCom application, and WeCom is the channel that carries messages to and from WeChat users. The audience is therefore narrow and specific: someone who already has a WeCom organisation, wants an LLM assistant reachable from ordinary WeChat conversations, and is willing to run the service. The README also notes a customer-service mode, so the same code can serve inbound support messages rather than only a personal assistant.

How the pieces fit: Go service, Redis, optional Milvus

The repository is a Go service with a Docker Compose deployment. The README's architecture diagram is at doc/system.png, and the install steps live in doc/install.md. From the FAQ and the Redis password instructions, the shape is visible: a web service container (the FAQ references `docker logs -f chat_web_1`) reads its configuration from `chat/service/chat/api/etc/chat-api.yaml`, and a Redis container is configured through `chat/build/redis/redis.conf`. Redis holds session state, which is why the README describes multiple conversations that can be switched without losing content, and an adaptive context length that avoids manual clearing. The v1.0.0 notes say the database moved to PostgreSQL to support vector queries, which is a change from the stable line rather than a description of v0.6.6. Milvus appears as the private vector knowledge base, and the plugin mechanism covers shell, search and wikipedia, with the README inviting users to write their own. Nothing in the material describes the internal Go package layout, so treat the diagram as the authoritative picture rather than any inference about code structure.

Getting it running with Docker Compose

The install document is doc/install.md and the README points at it rather than inlining the commands. What the FAQ does give is enough to describe the operating loop. Configuration lives in `chat/service/chat/api/etc/chat-api.yaml`. After editing it, the README offers two options: `docker-compose restart web` to restart just the web service, or `docker-compose build && docker-compose up -d` to rebuild and restart everything. Redis credentials are split across two files: set `RedisCache: Pass: "xxxxxx"` in the YAML and `requirepass "xxxxx"` in `chat/build/redis/redis.conf`, then run `docker-compose down && docker-compose up -d`. The install flow also includes a step the FAQ calls out by name, section 5, configuring a trusted corporate IP (配置企业可信IP). Skipping it is the documented cause of a bot that sends messages to the model but never receives a reply. The other named parameters are CorpID, agentSecret and agentID; the README ties access_token errors such as Code 41001 to those three values being wrong.

Failure modes the README admits to

The most useful part of the documentation is the FAQ, because it lists what goes wrong. Three cases stand out. First, silent non-delivery: messages reach the model but no reply arrives. The README's diagnostic path is `docker logs -f chat_web_1`, searching for `应用消息-发送失败 err:` for application messages and `客服消息-发送失败 err:` for customer-service messages. That is a concrete debugging procedure rather than a reassurance. Second, network reachability: on a server inside mainland China the README reports `connect: connection refused`, and offers two fixes, either a local proxy client listening on 0.0.0.0 in socket mode with authentication disabled, or moving the server to Hong Kong or overseas, with the note that mainland access will not work long term. Third, Redis state: after an upgrade, Redis may fail to start or be unreachable, and the README attributes this to leftover files from an older Redis version, instructing users to stop with `docker-compose down`, delete the contents of `chat/build/redis/data/`, and bring the stack back up. A fourth limitation is structural rather than operational: v1.0.0 is described as still in development, and the README explicitly says to use v0.6.6 for the stable version. The upgrade notes list PostgreSQL, Gemini-pro, a web bot, the newer WeCom customer-service protocol and custom API domains as v1.0.0 features, so anyone reading those notes and deploying the stable tag will not get them.

Where a Dify workflow is the better fit

The README lists dify among the topics and says the project supports dify workflows, but it does not document that integration in the material available here. The honest comparison is at the level of responsibility. chatgpt-wechat owns the channel: it holds the WeCom credentials, terminates the callbacks, keeps session state in Redis, and decides how context is trimmed. Dify owns the orchestration: prompt graphs, retrieval steps and model routing live in its own editor and are versioned there. If your main problem is designing a multi-step pipeline with human review points, a visual editor will be faster than editing a Go service. If your main problem is that the assistant has to live inside WeChat conversations that ordinary users already have, the channel work is the hard part, and that is what this repository does. The two are not mutually exclusive, but the README does not spell out how the handoff is configured, so treat dify support as a claim to verify in the code before you plan around it.

Maintenance cost and the Apache-2.0 terms

This is a self-hosted stack with several moving parts that you upgrade yourself: the Go service, Redis, and optionally Milvus and PostgreSQL. The Redis upgrade note in the FAQ is a small but real example of the cost, since a version bump can require deleting local data directory contents before the service will start. Configuration is file-based, and the README's answer to a changed config is a restart command, which means there is no hot reload described. The project is licensed Apache-2.0, a permissive licence that allows commercial use and modification provided the licence and notices are preserved; this is a description of the licence text, not legal advice, and you should read the LICENSE file and your organisation's own policy before shipping it. The README also states the project is free and open source with no paid tier, and warns that anyone asking for payment is a scammer. That claim is about the upstream repository; it says nothing about the model providers you will pay for tokens through.

Editorial conclusion

Adopt it if you already run WeCom, can supply a public HTTPS endpoint and the CorpID, agentSecret and agentID values, and are willing to operate Redis plus a reverse proxy yourself. Do not adopt it if you want a hosted bot, cannot run a service outside mainland China or behind a working http/socks5 proxy, or need the unfinished v1.0.0 feature set in production. Verify first that your server's outbound calls to the LLM endpoint succeed, that the trusted IP list in WeCom is configured, and that you are comfortable with the v0.6.6 stable tag while v1.0.0 remains in development.

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. whyiyhw/chatgpt-wechat on GitHub