MaaAssistantArknights: an image-recognition assistant for Arknights daily tasks

What MAA automates in Arknights and who it is aimed at

MAA is a desktop assistant for Arknights that performs routine in-game work: sanity farming with drop recognition, base shift scheduling, recruitment, friend visits, credit collection, daily rewards, and Integrated Strategies runs that farm Originite Prime and levels. The README describes the project as "a one-click tool for the daily tasks of Arknights, supporting all clients." The intended user is someone who already plays Arknights and wants the repetitive parts done without manual tapping, plus developers who want to drive the automation from their own code.

The second audience matters more than the first for adoption decisions. The README lists C, Python, Golang, Dart, Java, Java HTTP, Rust, Rust HTTP, TypeScript and Woolang interfaces, each with an integration example in the repository, plus protocol documents for integration, callbacks, task flow and copilot. That is an unusually wide surface for a game assistant, and it means MAA can serve as an automation core inside another tool rather than only as a standalone app.

It is not a general-purpose macro recorder. Everything it does is built around Arknights-specific recognition and game data, and the repository ships resource files for that purpose.

How image recognition replaces game memory access

The mechanism is screen capture plus recognition, not injection into the game process. The README credits opencv for image recognition, PaddleOCR for text recognition, FastDeploy for deep learning deployment, onnxruntime as a machine learning accelerator, and Arknights-Tile-Pos for map tile recognition. A separate companion project, MaaFramework, is described as a new framework, and MaaAI handles deep learning work.

The data flow follows from that stack. The tool captures the device screen, matches templates and reads text through the recognition libraries, then decides the next action and sends touch events. For Android it uses Minitouch or MaaTouch as the touch event layer, both listed in the acknowledgements. Because the loop is visual, the same approach works across emulators and real devices without a game-specific hook, which is why the README can claim support for all clients.

The cost of that choice is fragility. Any UI change in Arknights can invalidate a template or a text region, and the fix is a resource update rather than a code change. The README notes that for functions already supported on the Chinese server, most overseas adaptation work "only requires screenshots plus simple JSON modifications," which confirms that the adaptation layer is data, not logic. That is a sensible design, but it also means correctness depends on someone capturing the right screenshots for each server.

Game data comes from external sources: Penguin Stats for stage data, the Arknights client assets repository, and Yostar game data for the international release. Several older data sources in the acknowledgements are struck through, which suggests the project has moved between upstreams over time.

Installing MAA and running a first automated task

The README does not put install commands in the repository root. It directs readers to the documentation first, then to the official site or the GitHub Releases page, and then to the newbie guide. There is no package manager command to copy, so the honest first step is reading the manual page for your platform.

The documentation entry points are split by language: docs.maa.plus/zh-cn/, /zh-tw/, /en-us/, /ja-jp/ and /ko-kr/. The newbie guide lives under the manual path, and the CLI guide is a separate page under the same manual section. Because the repository is C++ with a WPF front end, the distributed builds are the practical route for most users rather than a source build.

If you want to script MAA rather than click through a GUI, the CLI is the relevant surface. The README states it supports Linux, macOS and Windows and is intended for automation scripts or servers without a graphical interface. The exact flags are in the CLI guide, not in the README, so check that page before writing a wrapper:

# MAA ships a CLI for Linux, macOS and Windows.
# The flag set is documented at docs.maa.plus under manual/cli,
# not in the repository README, so read that page first.

For programmatic use, the Python interface has a sample at src/Python/sample.py and the module at src/Python/asst/asst.py. The C interface header is include/AsstCaller.h with an example in src/Cpp/main.cpp. Those files are the reference for how a caller initialises the assistant and registers callbacks; the callback message format is defined in the callback schema document rather than in code comments.

One practical note before you start: the most recent releases listed are beta builds (v6.17.0-beta.7 and earlier betas), so a user who wants a stable tag should look further down the Releases page rather than taking the top entry.

Overseas clients are supported but not comprehensively tested

The README is unusually direct about this. It states that most functions are now supported for the international (US), Japanese, Korean and Traditional Chinese servers, but that because overseas users are fewer and the project is short-handed, many functions have not been comprehensively tested, and users should try them at their own risk. That is the single most important limitation for anyone outside the Chinese server.

The adaptation path is documented: for functions already supported on the Chinese server, most overseas work needs screenshots and simple JSON edits. So the gap is not architectural, it is coverage. A function can exist in the resource files and still behave incorrectly on a given server because nobody verified it there.

The README also points users to Issues and Discussions for bugs or strong feature requests, and invites contributors to join through the overseas client adaptation guide. If your server's behaviour matters to you, the realistic options are to test it yourself and report what breaks, or to contribute the adaptation.

A second constraint is the licence and its extra terms. MAA is AGPL-3.0-only with an additional terms-of-service file in the repository root. The logo is explicitly excluded from the AGPL grant: the README states the two artists and all developers retain all rights, that the AGPL licence does not authorise logo use, and that commercial use of the logo is not permitted without authorisation. If you plan to redistribute MAA or build a service around it, read terms-of-service.md and LICENSE before assuming the AGPL terms are the whole picture. This is a description of what the repository says, not legal advice.

MaaFramework is the alternative if you are building, not playing

The README lists MaaFramework as a related project and calls it a new framework. The difference in approach is scope: MAA is an application for Arknights with an automation core inside it, while MaaFramework is presented as the framework layer itself. If your goal is to automate a different game or a non-game application with the same recognition-and-touch loop, adopting MAA means inheriting Arknights-specific resources and assumptions you would then have to strip out.

For pure Arknights play, the alternative is doing nothing and tapping through dailies yourself, which is not a serious comparison. The more useful comparison is between MAA's bundled GUI and its own CLI or API surface. The GUI is the default route in the documentation, and the CLI exists for headless servers and scripts. Choosing between them is a question of whether you want a desktop app or a component.

Within the repository, the interfaces differ in maturity in ways the README does not rank. C, Python, Golang and Java each have both an interface and a linked integration example. Dart, TypeScript and Woolang are listed without the same example links in the README text. That asymmetry is worth checking against the source tree before committing to a language.

Maintenance cadence, upgrade cost and what the licence asks of you

The repository is not archived, and the last push was on 2026-08-27. The three most recent releases are all beta builds from late August 2026, which indicates a fast release cadence around that date but also that the newest artifacts are pre-release. Anyone who pins to the latest release should be aware they may be pinning to a beta.

The upgrade cost is tied to the recognition approach. Because templates and text regions are data, a game update can require a resource update rather than a new binary, and the project ships resource files in the repository for exactly that reason. In practice this means keeping MAA itself current is the main defence against a broken recognition step, and running an old build against a new client is where failures concentrate.

On licensing, the AGPL-3.0-only choice plus the additional terms-of-service file means anyone offering MAA as a network service should read both documents rather than reasoning from the AGPL name alone. The README also states plainly that the software is open source and free for learning and exchange, and that if a vendor charges for boosting services using MAA, any resulting problems are unrelated to the software. That sentence is aimed at a real situation and is worth taking at face value.

Editorial conclusion

Adopt MAA if you want Arknights dailies handled without touching the game client, or if you need an automation core you can call from Python, Go or Java. Skip it if your client is a non-CN server and you expect fully tested behaviour, since the README states overseas functions have not been comprehensively tested, or if AGPL-3.0 terms do not fit how you intend to distribute anything built on top of it. Before installing, read docs.maa.plus and the newbie guide, confirm your client region is covered, and check whether the release you download is a beta build.

Frequently asked questions

Official sources

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