Jumping-Agent: Building an Agent by Playing a Hopping Game
Build your own AI agent through gameplay.
At a glance
- What is it?
- Jumping-Agent-platform replaces the node-and-arrow workflow editor with a Three.js hopping game, then hands the result to a ReAct agent that writes the code. It is a solo project with seven flow templates and an admitted stability problem.
- Who is it for?
- Adopt it if you want to see what spatial, game-driven agent composition looks like and you can tolerate a project whose own README says the workflow templates number seven and the build flow is not yet stable. Do not adopt it if you need a supported product, an upgrade path, or a workflow editor you can hand to a team next week.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 77 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: workflow editors assume you already think in graphs
Most agent builders ask you to draw. You place a node, drag a connector, name the edge, and repeat until the canvas resembles a circuit diagram. That representation is fine for someone who already models systems as directed graphs, and hostile to everyone else. The README states the goal plainly: turn flat workflow construction into spatial, gamified construction so that beginners can start easily. The carrier is the Chinese mobile game 跳一跳, where you press and hold to charge a jump and release to land on the next platform. Each platform is a step. The agent's progression becomes something you watch happen rather than something you read off arrows. The intended audience is explicit in the README: zero-background users, on mobile, with tablets as the first target. That is a narrower audience than the topic list (agent, agentic-workflow, ai-agent, platform, workflow) might suggest. This is not a tool for an engineer who wants a YAML file and a diff. It is a tool for someone who has never built an agent and needs the first one to feel like something other than configuration.
Two runtimes, one repository: Three.js in front, Python behind
The architecture splits along a clear line. Frontend/ holds the Three.js hopping interface, with game logic, flow templates and the build client under js/game/, and 3D models and icons under res/. Everything else is Python or Node. The orchestrator at backend/orchestrator.py is the hub. It accepts build and chat requests from the front end, loads agent_builder dynamically, generates an agent workspace, and calls back_agent over local HTTP. agent_builder/ supplies the skeletons: flow_template/ for sequential, routing and parallel patterns, agent_template/ for agent classes, project_template/ for scaffolding, and config_creator/ for configuration. back_agent/ is a ReAct agent that reads the skeleton code, combines it with the requirements typed into the front end, and completes or rewrites the agent. The output lands in backend/workspace/ as generated Agent/*.py files plus a project_runtime.py. The README's Mermaid diagram shows the front end reaching the orchestrator, the orchestrator reaching both builders and the workspace, and the workspace producing runnable agent files. The interesting design choice is that the game is not a visualization layered on top of a config file. It is the input mechanism. The jump sequence is the specification.
WeChat is a first-class channel, not an afterthought
The README devotes a full section to WeChat, and the repository layout backs it up: apps/weixin-main/ contains an iLink connector with src/bridge/ for talking to the orchestrator. The flow is described in five steps. Build the agent in the hopping front end. Switch to the WeChat tab. Start a QR login and scan it. Send a message from WeChat. The connector forwards that message to the orchestration service, which runs the corresponding agent workspace and sends the reply back to WeChat. The bridge listens on port 8787 by default, and the README states that starting the backend on port 8001 also starts the bridge automatically. The front end polls login status. This is a meaningful integration choice for the stated audience: a beginner who builds an agent on a tablet has no obvious place to run it, and a WeChat conversation is a place they already are. It also adds a second runtime to keep alive. If the bridge dies, the agent still exists and the workspace still runs, but the user's only interface to it is gone.
Getting it running takes three terminals and an API key
Prerequisites are Git, Python 3.11 or newer, Node.js 18 or newer, and npm. Clone the repository, then run npm install inside Frontend/, and npm install inside apps/weixin-main/ for the connector. The README recommends a virtual environment before installing Python dependencies, and gives the activation commands for Windows and for macOS or Linux. The Python packages are installed with an explicit list: fastapi, uvicorn[standard], pydantic, openai. Configuration is a single key. back_agent/config/model_config.toml reads the OPENAI_API_KEY environment variable by default. You can export it in your shell, or run python backend/set_agent_api_key.py, which prompts for the key and writes it to back_agent/.env and to the .env of any already-generated workspace. Then three terminals, all from the repository root: cd back_agent and python -m uvicorn api:app --host 0.0.0.0 --port 8000; cd backend and python -m uvicorn orchestrator:app --host 0.0.0.0 --port 8001; cd Frontend and npm run server -- --host 0.0.0.0 --port 6301 --allowed-hosts all. The interface opens at http://localhost:6301. For iPad access, the README says to find the machine's LAN IPv4 address with ipconfig or ifconfig and browse to http://192.168.x.x:6301 from a device on the same network. Note the port map: 6301 front end, 8000 back_agent, 8001 orchestrator, 8787 WeChat bridge. Four services, no supervisor.
Seven flow templates and an admitted stability problem
The acknowledgment section is unusually candid, and it is the most useful part of the README for anyone deciding. The author states the project is developed alone, that the current version has shortcomings, and names two: the agent workflow offers only seven templates, and the platform arrangement plus final build flow are not yet stable. Take that at face value. Seven templates means sequential, routing, parallel and a few others, and anything outside that set has no path through the builder. The instability claim covers the part of the system that matters most, the step where a jump sequence becomes generated code. A second limitation is structural: back_agent is a ReAct agent that writes and rewrites code, and its output is Python files placed in a workspace directory. Anyone who has watched a code-generating agent work knows the failure mode. It produces something plausible that does not run. The README does not describe a validation or test step between generation and execution. There is also no release history, so there is no version to pin and no changelog to read before upgrading. The CLI section confirms the gap: agent-jump setup, agent-jump config set OPENAI_API_KEY and agent-jump dev are described as a recommendation for the future, and the README says to use the manual Quick Start until the CLI exists.
The alternative: a canvas editor or a framework you write by hand
The obvious comparison is a node-based workflow editor of the n8n or Dify kind, where you drag blocks onto a canvas and connect them. The difference is not cosmetic. A canvas editor still asks you to hold the whole graph in your head while you build it, and its output is a stored graph definition that the platform executes. Jumping-Agent inverts that: the interaction is sequential and embodied, one platform at a time, and the output is not a graph definition but generated Python source in a workspace you own. That makes the result portable in a way a hosted canvas is not, and it makes the build step far less predictable. The second alternative is writing the agent directly against a framework such as LangGraph or the OpenAI Agents SDK. That path assumes you can read the code you are producing, which is exactly the assumption this project is designed to remove. Neither alternative is worse. They serve different people. If you can already write the agent, Jumping-Agent adds a game between you and the file. If you cannot, a canvas editor still shows you connectors you may not understand, while a hopping game shows you a sequence you already do.
Licence, maintenance and what a fork actually costs
The repository is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant, which matters if you plan to build on the generated workspaces. It also requires that you keep the licence and notice files and state significant changes. This is not legal advice; read the licence text and the NOTICE requirements yourself before shipping anything derived from it. The maintenance picture is simpler and less comfortable. There are no releases, so there is nothing to upgrade between. The last push is dated 2026-06-30, and the author describes the project as a personal effort with ongoing iteration. Practically, that means upgrades arrive as commits on main, and your cost is the work of re-reading the diff and re-testing your build flow after each one. Because the platform generates code into backend/workspace/, a change to agent_template/ or flow_template/ can alter the output of every future build without touching anything you wrote. Pin a commit if you depend on it. The dependency surface is small, which helps: fastapi, uvicorn, pydantic and openai on the Python side, plus whatever Frontend/package.json and apps/weixin-main/package.json pull in. The WeChat connector is the piece most likely to break independently of this project, since it depends on an external messaging platform's login and polling behaviour.
Editorial conclusion
Adopt it if you want to see what spatial, game-driven agent composition looks like and you can tolerate a project whose own README says the workflow templates number seven and the build flow is not yet stable. Do not adopt it if you need a supported product, an upgrade path, or a workflow editor you can hand to a team next week. Before anything else, check whether back_agent/config/model_config.toml still reads OPENAI_API_KEY, whether the Weixin bridge on port 8787 actually starts when orchestrator.py boots, and whether the generated workspace under backend/workspace/ survives a second build. The repository has no releases, no CLI (agent-jump is a plan, not code), and the author states it is a personal effort.
Community notes