Lynxe: a Java implementation of Manus built around Func-Agent determinism

Why a Java port of Manus exists at all

The README's own framing is that Lynxe is a Java implementation of Manus, currently used in applications inside Alibaba Group, and that the original name was JManus. That provenance explains both the design and the audience. A Java codebase inside a large enterprise carries constraints a Python-first agent framework does not: the deployment target is a JVM, the team is Spring-trained, and the work to be automated is exploratory but repetitive rather than open-ended.

The stated use case is narrow on purpose. The README names finding data from massive datasets and converting it into a single database row, and analysing logs and issuing alerts. Both are tasks where the shape of the answer is uncertain at the start while the steps repeat every time. That is a different requirement from an agent that improvises, and it is the requirement that drives the Func-Agent design.

The project is Apache-2.0 licensed, sits under the Spring AI Alibaba organisation, requires Java 17 or newer, and lists Spring Boot 3.x as its base. The repository tree shows a Maven project with `pom.xml`, a `ui-vue3/` frontend, `src/`, `deploy/`, `knowledge/`, `tools/`, and separate `design.md` and `design1.md` files. The last push was on 2026-06-28.

Func-Agent mode and what determinism buys you

Func-Agent is the mode the README leads with, and the description is worth reading precisely: it lets you control every execution detail, which the project says gives high execution determinism for complex repetitive processes. The practical implication is that the agent produces an explicit plan and then executes it, rather than deciding what to do next after every tool call.

The v4.10.11 release notes name a plan execution snapshot feature, described as letting you stop the agent at a specific step and modify the agent logic repeatedly to speed up debugging. That is a small feature description with a large implication for anyone doing agent development. When an agent run takes minutes and costs tokens, freezing it at step four, changing the plan and replaying from there is the difference between a workable loop and an unusable one. A public repository of use cases lives at Lynxe-public/Lynxe-public-prompts, with a query-plan example linked as the Func-Agent reference.

The project also supports the Model Context Protocol for external tools, and exposes HTTP service invocation so it can be integrated into existing projects. The README points to `README-dev-en.md` for the developer quick start rather than documenting the HTTP surface itself, so anyone embedding it needs that second document.

Running the fat JAR and reaching the web UI

Method 1 in the README is a single JAR, which is the fastest way to see what the thing does. The release publishes it as `lynxe.jar`, and a local Maven package produces the same executable under `target/lynxe-exec-fat-jar.jar`.

wget https://github.com/spring-ai-alibaba/Lynxe/releases/latest/download/lynxe.jar

java -jar lynxe.jar

Java 17 or newer is required and no classpath work is needed. The application then serves a web UI on port 18080, and the first thing it shows is a guided setup page: pick English or Chinese, then paste a DashScope API key. That key comes from the Alibaba Cloud console, and the README mentions a free quota of one million input and one million output tokens, valid 90 days, for new users.

If you prefer to embed it, the release also publishes a thin JAR, without the executable repackage, for use as a library, documented separately in `docs/LYNXE-AS-LIBRARY.md`. The v4.10.11 release notes add that this embedded mode exists so Lynxe can be pulled into another Java project through Maven and save a separate application server, which distinguishes it from products that can only be run as a service.

Docker, MySQL, and a version tag that lags the releases

Method 2 is the container path, and the README recommends it for production. The image is on GitHub Container Registry under the Spring AI Alibaba organisation.

docker pull ghcr.io/spring-ai-alibaba/lynxe:v4.7.0

docker run -d --name lynxe -p 18080:18080 -v $(pwd)/lynxe-data:/app/data ghcr.io/spring-ai-alibaba/lynxe:v4.7.0

Note the version in that tag. The documented Docker tag is v4.7.0, while the newest GitHub release tag is V4.10.12, published on 2026-06-10. The Docker snippet and the release line do not sit on the same version number, so the tag you copy from the README is not the newest release by name. That is not necessarily a defect, since an image tag may track a separate line, but it is worth verifying before you pin a version in infrastructure.

There is a second inconsistency worth pairing with it. Every README snippet serves the app on 18080, while the v4.10.11 release notes mention a change to a more standard `localhost:8080/lynxe` path. The port and the path in the release note do not match what the quick start shows, so a reverse proxy rule or a bookmarked URL written against one version may not behave as expected in the next. Persistence is handled by mounting `/app/data`, and a MySQL backend is selected with `SPRING_PROFILES_ACTIVE=mysql` alongside `SPRING_DATASOURCE_URL`, `SPRING_DATASOURCE_USERNAME` and `SPRING_DATASOURCE_PASSWORD`.

A Makefile that delegates to one fragment per concern

The repository is a mixed-language project and the tree makes that clear. There is a Java backend under `src/`, a Vue 3 frontend under `ui-vue3/`, a `deploy/` directory, a `knowledge/` directory, and a `tools/` directory that holds the make fragments. Two `tsconfig` files sit at the root and belong to the frontend.

The top-level `Makefile` does not build anything itself. It delegates to a set of included makefiles, one per concern: common settings, Java, linting, tools, Docker and the UI.

-f tools/make/common.mk \
-f tools/make/java.mk \
-f tools/make/linter.mk \
-f tools/make/tools.mk \
-f tools/make/docker.mk \
-f tools/make/ui.mk \

Those fragments are handed to a nested make invoked with `--warn-undefined-variables`, and the file wraps them behind a single `_run` target so whatever target you type is forwarded. The practical consequence is that the Docker image, the Java build, the linting and the UI build are separate makefiles, so a contributor working on the frontend does not follow the same path as one working on the agent. The file carries the standard Apache 2.0 header, matching the declared licence.

The presence of `design.md` and `design1.md` at the root suggests design history is tracked in the repository, and `RELEASE-NOTES-zh.md` holds the Chinese release notes, which is where the v4.10.11 UI path change is recorded.

Where Lynxe is a poor fit

The first limit is the model dependency. The documented quick start assumes a DashScope API key, or an alternative provider. A team with a hard requirement to route model traffic through an existing gateway will find that path less documented than the happy path, and the README does not enumerate which alternatives are supported.

The second is scope. The project describes itself as high-determinism, code-free prompt programming, and its examples are data extraction and log analysis. If the task at hand is open-ended software engineering, a general coding agent fits better, and Lynxe's determinism orientation works against you there rather than for you.

The third is release hygiene. Tags include V4.10.12, v4.10.11 and v4.10.9 with inconsistent capitalisation, the newest release body is a one-line note about fixing a small bug, and the Docker tag lags the release numbers. None of that suggests abandonment: the last push was on 2026-06-28 and releases continued through June 2026. Still, a four-part version number attached to a project whose newest release note is a bugfix is not something to pin in production without reading the release history first.

Editorial conclusion

Lynxe earns its place in a Java shop that has agent-shaped work to automate and does not want a Python service in the middle of an existing Spring architecture. The Func-Agent mode is the substantive part: plans that can be snapshotted, replayed and edited at a step are what separates it from a chat box with tools attached, and README-dev-en.md is where that gets explained. It is the wrong choice if you need a general-purpose coding agent, or if DashScope access is not an option, since the documented quick start begins with an Alibaba Cloud API key. Before you commit, check the two places the version story disagrees, because the Docker tag and the release tags are not on the same line and the UI path changed underneath them. The quickest evaluation is to run the fat JAR on port 18080, point it at a small real task, and see whether plan snapshots hold up under your own failure cases.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. spring-ai-alibaba/Lynxe on GitHub