CowAgent 2.2.0: a two-line Dockerfile, nine messaging SDKs, and two version numbers

The Dockerfile is two lines that pull a moving tag under the project's former name

The Dockerfile in this repository does not build the project. It is FROM ghcr.io/zhayujie/chatgpt-on-wechat:latest followed by ENTRYPOINT ["/entrypoint.sh"], so it inherits a prebuilt image published under the previous name of the project and tracked only as a floating latest tag. That tag is the problem. Nothing in this repository pins a digest or a version, so the image your Docker host pulls can change without a single commit here, and if that upstream image is retired your container fails to start with no change of your own. The described origin also shows up in the repository description, which still carries the parenthetical formerly chatgpt-on-wechat. Meanwhile the documented Docker path does not use the docker/ directory in this tree at all, it fetches a compose file from a CDN. So a Docker deployment has three moving parts: the CDN compose file, the CDN run script, and the latest base image.

requirements.txt installs every channel's SDK whether you use that channel or not

The lightweight claim in the repository description has a specific price, and it is in requirements.txt. The channel libraries are all unconditional: wechatpy for WeChat, lark-oapi for Feishu, dingtalk_stream for DingTalk, websocket-client and pycryptodome for WeCom bot websocket mode, python-telegram-bot, slack_bolt, and discord.py. If your only channel is the Web console, you still install eight messaging SDKs. The consequence is not just download size. A single unbuildable or unresolvable wheel in that set fails the whole install, and on a locked down machine or an air gapped host this is where the one-line installer stops working. There is a requirements-optional.txt in the tree alongside the required list, but the quick start path does not say which side you land on, so a reader has to inspect the repository to find out. The rest of the file follows the same pattern of deliberate substitutions, and the comments explain why.

pyproject says version 1.0.0, the release feed says 2.2.0, and both are current

Two version numbers live in this project and they do not match. The published releases are 2.2.0 on 2026-09-30, 2.1.9 on 2026-09-14, and 2.1.8 on 2026-09-11, and the repository was pushed on 2026-09-29. But pyproject.toml declares version = "1.0.0" with description = "CowAgent - AI Agent on WeChat and more". So anything that reads the installed package metadata sees 1.0.0 while `cow update` pulls code that reports itself as 2.2.0. If you log versions, pin containers, or file a bug with a version string, decide in advance which number you trust. The Python floor has the same flavor of drift: requires-python is ">=3.7", yet ruff targets py39 and requirements.txt branches on 3.10 and 3.13. Also note that packages.find includes only cli*, so a pip install gives you the CLI package and its console script `cow = "cli.cli:main"`, not the whole application.

aiohttp and web.py are chosen by Python version markers, not by version alone

The clearest statement of which Python versions actually work is in the marker comments. For aiohttp the file carries two lines, aiohttp>=3.8.6,<3.10 for python_version below 3.13 and aiohttp>=3.10 for 3.13 and above, with the reason spelled out: aiohttp below 3.10 has no prebuilt wheels for Python 3.13+, so pip would compile from source and need MSVC on Windows. For web.py the split is the other way, because web.py 0.62 is the last release supporting Python below 3.10 and it imports the stdlib cgi module removed in 3.13, while 0.76 dropped cgi but requires 3.10 and up, so it is asked for only where it can be installed. Practical consequence: 3.10 through 3.12 is the comfortable range, and on Windows you stay below 3.13 unless you have a compiler. Two other pins explain themselves in comments too, regex instead of stdlib re because regex.search() supports a real per call timeout for the search_files tool, and markdown-it-py for structure aware chunking of memory and knowledge markdown files.

The one-line installer pipes an unsigned remote script straight into a shell

Three install routes are offered and none of them pins anything. On Linux and macOS it is a process substitution around curl:

bash <(curl -fsSL https://cdn.link-ai.tech/code/cow/run.sh)

On Windows PowerShell it is the same idea:

irm https://cdn.link-ai.tech/code/cow/run.ps1 | iex

And for Docker you download a compose file from the same CDN before bringing it up:

curl -O https://cdn.link-ai.tech/code/cow/docker-compose.yml

docker compose up -d

There is no version argument, no checksum, and no signature in any of them, so you execute whatever sits at that URL at the moment you run it, from a project CDN rather than from a tagged release asset. That matters more here than for a typical library, because what you are installing will set up a terminal tool, browser automation, a scheduler, and a file I/O agent. If you want to read before you run, the tree holds run.sh, a docker/ directory, and a scripts/ directory, and the manual install guide is at docs.cowagent.ai/guide/manual-install. After startup the console is on localhost:9899.

Exposing the console needs two config keys and a firewall rule, in that order

The default is safe and the instructions for leaving it are easy to half follow. Out of the box the Web console is at http://localhost:9899, reachable from the machine it runs on. The documented way to make it reachable from elsewhere is to set web_host to 0.0.0.0 in config.json, set web_password to protect it, and then open port 9899 in the firewall or the security group. The order matters and the failure mode is quiet: if you change web_host first, the console is listening on every interface with whatever password state exists, and there is a window where an unauthenticated admin console is on the network. config-template.json sits at the top of the tree, and a browser tool, a terminal tool, a scheduler, and file I/O all sit behind that same login, so treat web_password as the only barrier between the public internet and a shell. The CLI covers the operational side with `cow start`, `cow stop`, `cow restart`, `cow status`, `cow logs`, `cow update`, `cow skill install <name>`, and `cow install-browser`.

Self-Evolution rewrites skills and chases unfinished tasks between conversations

Most of the feature table describes things you ask for. One row does not. Evolution is described as Self-Evolution reviewing conversations automatically to improve skills, following up on unfinished tasks, and consolidating memory and knowledge, growing through everyday use. Memory sits in a three tier architecture, context to daily to core, with automatic Deep Dream distillation and hybrid keyword plus vector retrieval, and Knowledge auto curates structured material into a Markdown wiki and builds an evolving knowledge graph. Consequence for a reader: this is the component that acts without a prompt, and it acts on the same agent that holds file I/O, terminal, browser, and scheduler tools. Skills can also be created through natural language conversation, and installed from the Skill Hub, GitHub, or ClawHub. That means your skill files and your memory tiers can change between sessions rather than during them, so you need a review path for what changed and some way to see a diff before a modified skill runs. The docs excerpt describes no dry run or approval step for evolution.

The model table is narrower than the multi-model claim, and the console is the config surface

Two things are worth separating. First, per capability routing: chat, vision, image generation, ASR or TTS, and embeddings can each be routed to a different vendor, which is a genuinely different design from one model for everything. Second, what the table actually shows. In the rows that are fully visible, DeepSeek with deepseek-flash (V4.1) and pro, and Claude with claude-opus-5-5 and fable-5.1, both have Chat and Vision ticked while the Image Gen, ASR, TTS and Embedding columns are empty, and the OpenAI row is cut off part way through a model name. So before you design around image generation or speech, check the table row for your own provider rather than assuming symmetry. The second point is where configuration happens: providers are set in the Web console with no manual file editing, and swapping is a one click action. The tradeoff is that your provider credentials live in the console's config rather than in a file you can diff and review, and CLI-only or headless deployments have to go through the same surface.

Editorial conclusion

CowAgent suits a reader who wants one Python process that speaks several IM platforms at once, who is willing to read a requirements file before installing, and who treats the skill and memory directories as generated artifacts to review. It does not suit a reader who needs a reproducible or auditable install, who runs on Python 3.7 because that is the declared floor while the tooling assumes 3.9, or who needs a minimal dependency set, since every channel SDK arrives whether or not you use that channel. Before you install, check five things: whether the CDN install scripts are acceptable to you, since they are unpinned and unsigned; what the Dockerfile's :latest base image actually resolved to; which of the two version numbers, pyproject's 1.0.0 or the released 2.2.0, your tooling should trust; whether your Python version lands in a supported requirements.txt marker branch; and how you will review changes that Self-Evolution makes to skills and memory between conversations.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes