UnicomAI/wanwu: China Unicom's multi-tenant agent platform, reviewed from the repo

What problem UnicomAI/wanwu solves, and for whom

The README frames the project around the Forward Deployed Engineer: the person who has to take an AI capability and land it inside a customer's existing systems. That framing explains most of the design choices. Instead of a single agent library, Wanwu ships five capability areas in one repository: a RAG and knowledge base agent, an ontology agent for structured data, a low-code workflow agent, a GUI agent for systems without APIs, and a general agent with skill development. The intended user is an enterprise platform team or an integrator who needs all of those in one deployable unit, with multi-tenancy and permission control already present rather than bolted on.

The README lists three deployment paths: an out-of-the-box visual platform, a RESTful API for embedding into OA, CRM or ERP systems, and a Skill plus UniClaw client for high-privilege local operations. That third path matters because the GUI agent needs to click through applications that expose no API, which is a real constraint in legacy enterprise environments. If your problem is 'we have documents, structured data, and a legacy UI, and we need one platform to handle all three', this is the scope Wanwu is aiming at. If your problem is 'I want a Python library to call an LLM', this is far more machinery than you need.

How the Go services fit together in the repository

The repository layout shows a Go monorepo with separate service binaries. The cmd directory contains entry points such as bff-service, iam-service, model-service and mcp-service, and the Makefile builds each of them for amd64 and arm64 with CGO_ENABLED=0. That means the backend is a set of independent processes behind a BFF, not a single monolith. The iam-service handles identity and access, which is consistent with the multi-tenant claim. The model-service manages model providers, and the go.mod lists eino-ext components for DeepSeek and OpenAI, so model integration is provider-based rather than hardcoded.

The docker-compose.yaml file defines the middleware layer: MySQL, Redis, MinIO and Kafka, each with healthchecks. The MySQL service mounts configs/middleware/mysql/initdb.d and a separate mysql-setup container runs init.sql once the database is healthy. Alternative compose files exist for TiDB and OceanBase, and WANWU_DB_NAME selects between mysql, tidb and oceanbase. Kafka appears in the dependency list through IBM/sarama and the dnwe/otelsarama wrapper, so event streaming is part of the architecture. The rag directory and the Dockerfile.rag suggest the RAG pipeline is packaged separately from the main backend, and the presence of MinerU and OCR references in the README points to document parsing being a distinct stage. This is a distributed system with at least four stateful middleware components, which is the single most important operational fact about it.

Installing UnicomAI/wanwu with Docker Compose

The repository provides a Makefile and a .env.example, and the compose file reads variables from the environment. The first step is to create your .env from the example and set the external address and port. The example uses localhost and 8081.

cp .env.example .env
# edit .env: WANWU_EXTERNAL_IP, WANWU_EXTERNAL_PORT, WANWU_VERSION

The .env.example sets WANWU_VERSION to v0.6.4, which matches the most recent release listed on the repository. It also defines WANWU_DB_NAME with the comment 'db: mysql | tidb | oceanbase', so you choose your database backend before starting. Default credentials for MySQL, Redis, MinIO and Kafka are all present in the example as Wanwu123456, which you should change before exposing anything.

docker compose -f docker-compose.yaml up -d

Because docker-compose.yaml includes docker-compose.ontology.yaml, the ontology service starts alongside the core stack. The MySQL container has a healthcheck with 99 retries and a 10-second start period, and mysql-setup waits for that health condition before running init.sql. Expect the first startup to take a while. The README points to a Bilibili video for a visual walkthrough, but the repository itself does not document a rollback procedure or a migration path between versions.

For building the Go services directly rather than using images, the Makefile targets follow a pattern. The build-bff-amd64 target compiles cmd/bff-service with the version and git metadata injected through ldflags.

make build-bff-amd64
make build-iam-amd64

Each target writes to ./bin/amd64/. The go.mod requires Go 1.24.13, and the README badge states Go >= 1.24.0.

Where UnicomAI/wanwu will fight you

The operational surface is the first limitation. Running MySQL, Redis, MinIO and Kafka is not optional if you use the provided compose file, and each is a component you now have to back up, monitor and upgrade. The repository offers TiDB and OceanBase alternatives, which tells you the authors expect database choice to matter, but it also means three compose variants to keep in sync with schema changes. The init.sql in configs/middleware/mysql/initdb.d runs only on first initialization, so schema migrations across releases are a question the README does not answer.

The second limitation is documentation depth in the repository itself. The README is long on capability claims and short on failure modes. It states that the platform supports 12 file formats and URL crawling, that GraphRAG is built in, and that there is an 'industry-leading F1 score', but it does not link to a benchmark methodology or a dataset. Treat those claims as marketing until you reproduce them on your own documents. The README also does not document rollback, backup, or how to move from v0.6.1 to v0.6.4 safely.

The third limitation is scope. If you only need RAG over a document set, this platform brings a workflow engine, an ontology layer, a GUI agent sandbox and a multi-tenant IAM system you will not use. That is weight you pay for in deployment complexity and upgrade risk. The GUI agent also requires a separate client download from a Baidu Pan link, which is not a standard distribution channel and may be blocked in some corporate networks.

UnicomAI/wanwu compared with Dify

The README itself names Dify, stating that Wanwu supports API import of knowledge bases created in Dify for retrieval in agents, chat and workflows. That is a useful comparison point because the two projects overlap in the low-code agent and workflow space, but the difference in approach is visible in the repository. Wanwu is written in Go with a service-oriented backend, and its compose file expects Kafka alongside the usual database and object storage. Dify is a Python application with a more compact deployment story. If you want the smallest possible self-hosted footprint for RAG and chat, Dify is the lighter path, and Wanwu's own compatibility feature means you can keep using Dify knowledge bases from inside Wanwu.

The difference that favors Wanwu is the breadth of the FDE toolchain. Dify does not ship a GUI agent that operates applications without APIs, and it does not ship an ontology agent for structured business data. Wanwu also builds on eino, the CloudWeGo Go LLM framework, and exposes MCP through both ThinkInAIXYZ/go-mcp and mark3labs/mcp-go in its dependency list. If your delivery requires one platform that covers documents, structured data, legacy UIs and agent skills under a single IAM system, the integration cost of stitching together Dify plus separate tools may exceed the cost of running Wanwu's heavier stack. The trade is footprint and operational simplicity against breadth of built-in capability.

Licence, maintenance and upgrade cost

The repository is Apache-2.0, and the README badge confirms it. Apache-2.0 permits commercial use and modification, and it includes a patent grant, which matters for enterprises that need that assurance. The repository also contains a NOTICE file. Apache-2.0 requires that you preserve NOTICE contents when redistributing, so if you fork or ship Wanwu inside a product, read that file rather than assuming the whole tree is uniformly licensed. The README describes the licence as developer-friendly, which is consistent with Apache-2.0, but the NOTICE file is the place to check for bundled components under different terms. This is not legal advice; your counsel should review the NOTICE before redistribution.

On maintenance, the last push was on 2026-09-04, and the most recent release v0.6.4 was tagged the same day. Before that, v0.6.2 was on 2026-07-24 and v0.6.1 on 2026-07-17. That is a fast cadence: three releases in roughly seven weeks. Fast cadence cuts both ways. You get fixes quickly, but you also carry upgrade work. The repository does not document a migration procedure between these versions, and the MySQL init script only runs at first initialization, so upgrading an existing deployment is the thing to test on a staging copy before touching production. Pin WANWU_VERSION in your .env rather than tracking latest, and read the release notes for each version you cross.

Editorial conclusion

Adopt UnicomAI/wanwu if you are an enterprise or FDE team that needs a self-hosted, multi-tenant agent platform with RAG, workflow orchestration and MCP support, and you are willing to run MySQL, Redis, MinIO and Kafka yourself. Do not adopt it if you want a managed service, a single-container install, or if you cannot commit to tracking the rapid release cadence. Before deploying, verify the exact image tags in .env.image.amd64 or .env.image.arm64, confirm the database variant you need (mysql, tidb or oceanbase), and check the license and NOTICE files for any bundled component whose terms differ from Apache-2.0.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. UnicomAI/wanwu on GitHub