openJiuwen agent-core: a Python SDK for ReAct and workflow agents

What openJiuwen agent-core is for

openJiuwen agent-core is the Python SDK layer of the openJiuwen framework. The README describes it as a development toolkit that wraps interfaces for agent creation, workflow orchestration, LLM invocation and tool calling, plus a runtime that supports asynchronous IO, streaming, agent state saving and interruption recovery. The intended reader is a Python developer building an LLM application who does not want to assemble the loop, the graph and the prompt tooling from separate libraries.

The package name on PyPI is openjiuwen, not openJiuwen, and the project metadata describes it as a "feature-rich AI agent SDK for developing, running, tuning, and improving your AI agents". The classifier in pyproject.toml is Development Status :: 4 - Beta, which is the honest label here: the API surface is large and the version number is 0.1.x.

ReActAgent versus WorkflowAgent: two execution models in one SDK

The README splits the agent layer into two pre-built types. ReActAgent follows the ReAct loop of thinking, action and observation, iterating until the task completes; the README positions it for scenarios that need multi-round reasoning and self-correction. WorkflowAgent executes a predefined process step by step and can switch between workflows inside one session, which the README frames as the answer to users who change task scenarios mid-conversation.

The trade-off is visible in that split. A ReAct agent decides its own next step, so behaviour varies run to run. A workflow agent is deterministic in structure but only as good as the graph you drew. Choosing between them is the first design decision this SDK forces on you, and the README does not offer guidance on mixing the two in one application.

The asynchronous parallel graph executor and how state is kept

Under the agents sits an execution engine. According to the README, the asynchronous parallel graph executor supports component concurrent execution, asynchronous IO, structured context management, batch and streaming value transfer between components, dynamic jumping, and state interruption and recovery. Components can be dynamically configured and run as multiple instances.

The storage story is the part worth reading twice. The README states that the SDK can connect to external storage systems to externalize agent context data, which is what makes elastic scaling in distributed scenarios possible. That is a claim about architecture, not a guarantee about any particular backend; the README does not name which storage systems are supported, and the dependency list includes sqlalchemy[asyncio], sqlmodel and pymilvus, which suggests SQL and vector stores are both in scope. Treat the externalization path as something to verify against your own storage before you plan a distributed deployment.

Installing openjiuwen and running a first workflow

The README gives one install command and states the supported operating systems as Windows, Linux and macOS. Python must be 3.11 or higher but lower than 3.14, and the README recommends 3.11.4. The pyproject classifiers list 3.11, 3.12 and 3.13, so a 3.14 interpreter will not satisfy the requirement.

pip install -U openjiuwen

After install, the README's example builds a WorkflowAgent that calls a workflow to produce a piece of text. The imports come from openjiuwen.core.workflow, openjiuwen.core.foundation.llm, openjiuwen.core.runner.runner, openjiuwen.core.single_agent.legacy and openjiuwen.core.application.workflow_agent. The example sets API_BASE and a second environment variable whose name is cut off in the README before the code finishes, so you will need to fill in your own LLM credentials.

import os
from openjiuwen.core.workflow import Start, End, LLMComponent, LLMCompConfig
from openjiuwen.core.foundation.llm import ModelRequestConfig, ModelClientConfig
from openjiuwen.core.runner.runner import Runner
from openjiuwen.core.application.workflow_agent import WorkflowAgent

os.environ.setdefault("API_BASE", "your_api_base")

The README shows the expected output as a single line beginning with "WorkflowAgent output result >>>". Because the example is truncated, the fastest path to a working program is the examples/ directory in the repository, which contains directories such as examples/react_agent/, examples/multi_agent/, examples/mcp/ and examples/session/. The README does not document how those examples are launched.

Prompt generation and optimization, and where the documentation stops

Beyond orchestration, the SDK ships debugging and optimization tools. The README lists prompt auto-optimization, prompt generation and full-link observability, and describes generating a suitable prompt from a stated requirement, then iterating it against a dataset from a real scenario. That is a different job from running an agent, and it is the part that most directly competes with standalone prompt-engineering tools.

The limitation is documentation depth. The README is an introduction, not a reference: the quick-start example is truncated mid-block, there is no section on configuration keys, and no page on what the observability output looks like or where it goes. The repository has docs/ and examples/ directories, and the README points contributors at issues and documentation improvements, which tells you the project expects the community to fill gaps. If you need a documented API reference before you commit, this is not yet that project.

Dependency pinning, licence and the cost of upgrading

pyproject.toml pins agentdescent==0.4.6 exactly rather than with a floor, and the comment explains why: openjiuwen.rsi.artifact_rsi.program_opt vendors a PUCT port out of agentdescent's examples, importing internals such as FlatPuct, Candidate.prior, AggregatorConfig and Ledger, none of which promise stability across releases. That is a deliberate choice and a real constraint. If your environment already depends on a different agentdescent version, you have a conflict to resolve.

pymilvus is bounded as >=2.6.2,<2.6.10 because 2.6.10 changed an interface, and fastmcp is bounded below 4.0. The Python range is >=3.11,<3.14. The licence is Apache-2.0, which permits commercial use and modification with the usual notice and patent terms; the LICENSE file and Open_Source_Software_Notice.txt are both in the repository, and if you redistribute the package you should read the notice file rather than assume the licence covers every bundled component. This is not legal advice.

Upgrade cost is the open question. The last push was on 2026-08-20, and releases v0.1.15, v0.1.16 and v0.1.17 landed between 2026-06-22 and 2026-08-20. That cadence is fast for a 0.1.x line, and the README does not document a deprecation policy or a migration guide between versions.

Alternatives and when openJiuwen is the wrong tool

The nearest comparison is a general-purpose agent framework such as LangGraph or a provider SDK such as the OpenAI Agents SDK, where you assemble the loop and bring your own graph and prompt tooling. openJiuwen's difference is that the graph executor, the ReAct agent, the workflow agent and the prompt optimizer are one package with one dependency set. You trade control over individual pieces for not having to integrate them.

It is the wrong tool in three cases. If you are not on Python, nothing here applies: the SDK is Python-only. If your application is a single LLM call with a tool or two, the graph executor and workflow switching are overhead you will not use. And if you need a documented, stable interface with a published upgrade path, the 0.1.x versioning and the truncated README are working against you. The repository's Makefile shows the project's own quality tooling (ruff, pylint, mypy, codespell), which suggests internal standards, but that is not the same as a public compatibility promise.

Editorial conclusion

Adopt openJiuwen agent-core if you want a Python SDK that already contains both a ReAct loop and a workflow graph, and you are willing to read examples/ rather than the README to learn the API. Avoid it if you need documented upgrade paths, a stable interface across minor releases, or a non-Python runtime. Before writing production code, check that your Python is between 3.11 and 3.13, that pymilvus resolves below 2.6.10, and that the pinned agentdescent==0.4.6 is acceptable in your dependency tree.

Frequently asked questions

Official sources

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