Jiuwen Symbiosis: Physical Agents Enter an Automated Research Lab

Jiuwen Symbiosis: Physical Intelligent Agents Enter Automated Research Labs

How can the experimental procedures listed on the screen be accurately turned into a series of actual operations? This question directly targets the core barrier to AI research implementation: AI can generate feasible experimental plans, but it is difficult for it to autonomously complete the entire offline hands‑on process.

The Huawei openJiuwen team, together with the Computing Power Platform Public Service Squadron, used an electrocatalysis scenario as an example to bridge the interaction between large models and underlying physical devices, successfully dispatching the designed experimental plan to physical equipment for execution. One of the key foundations ensuring that the large model can operate physical devices is the Jiuwen Symbiosis physical intelligent agent under openJiuwen.

This implementation case also opens a window for us, further illustrating the general technical capabilities of Jiuwen Symbiosis for automated research laboratories.

1. Wet Experiments

Why This Is a Bottleneck in AI Research Implementation

Take a typical experimental instruction as an example: “Prepare three sets of solutions according to Plan B, stir at 60 °C for two hours, then perform spectral characterization.”

In the digital realm, this description appears clear and complete. But when applied to a real lab bench, it must be broken down into multiple physical actions: fetching containers, opening caps, weighing, pipetting, mixing materials, controlling a heating plate… Each step requires the corresponding equipment or embodied robot to execute.

The real challenge lies in: when AI is placed in the physically real world formed by the coupling of samples, containers, instruments, and environment, it must determine whether an operation is feasible and whether execution conditions are met — for example, whether the bottle cap is open before pipetting, or whether the heating station is idle; it must remain stable in scenarios involving heterogeneous device clusters, multiple concurrent workflows, and sudden anomalous disturbances; and it must ensure that all actions have clear constraint boundaries, with every state change of samples and equipment traceable.

The larger the automated laboratory, the longer the experimental chain, and the more concurrent tasks, the more pronounced the consequences: an unrecognized deviation in an object’s state or a single operation that violates constraints can propagate through the workflow, causing downstream experiment failures and even safety hazards. When a wet experiment goes wrong, there is no “undo” key as in the digital world.

II. Disassembling Jiuwen Symbiosis

How It Completes Wet Experiments

To address the aforementioned wet‑lab challenges, Jiuwen Symbiosis centers on an “Perceive — Plan — Execute — Feedback” Agent Loop, enabling dynamic orchestration of experimental tasks based on environmental perception: before acting, it confirms the on‑site status; it dynamically schedules devices and allocates actions according to equipment capabilities and conditions; after execution, it validates effectiveness with observation results and drives the next decision cycle, repeating until the task is completed.

Perception: Building a Structured State of the Experimental Site

The perception stage is responsible for answering “What does the site look like?”. It aggregates two types of information:

• Environment Status: Which containers and samples are on the workbench, where they are located, and what spatial relationships exist among them. The system uses an open‑vocabulary visual recognition approach, allowing targets to be located simply by textual description; the recognition results, combined with depth information, are uniformly transformed into the coordinate system of the corresponding device. Whether the camera is mounted on the robot arm’s end or fixed on the side of the workbench, the output is a position that can be used directly for operation.

• Device Status: What capabilities each device has, its current pose, whether it is idle, and whether its end effector holds an object. Device capabilities are declared explicitly — can it move, can it grasp, can it suction, does it have vision — and during planning actions are assigned only to devices that truly possess the required capabilities.

In an automated laboratory, robotic arms, mobile robots, and various workstations come from different manufacturers, with vastly different hardware structures and communication interfaces. The adapter layer smooths out these heterogeneous differences, providing the planning layer above with a unified abstraction of capabilities and states. Experimental workflows only need to consider “who can perform this step,” without worrying about the specific underlying device.

Planning: Dynamic Orchestration Based on On‑Site State

The planning stage is responsible for answering “what to do next and who should do it.” The planner takes the experiment goal described in natural language as input, combines the structured on‑site state output from the perception stage and the capabilities declared by each device, and decomposes the task into a sequence of subtasks with clear precedence dependencies. It then matches each subtask with devices that possess the required capability and are currently available: dispensing is assigned to the liquid‑handling workstation, transfer to the robotic arm, and cross‑station transport to the mobile robot. Data dependencies between steps are also explicitly described — the sample location obtained in the previous perception step is used directly as a parameter for the subsequent grasp action, rather than a hard‑coded coordinate. The generated execution plan undergoes a global validation before dispatch, confirming that the prerequisites for each step are satisfied by preceding steps, thereby preventing constraint‑violating operations from entering the execution phase.

Compared with fixed scripts, the value of dynamic orchestration lies in: the experimental workflow is no longer tied to a specific equipment layout or a particular experimental protocol. The same experimental goal can generate different execution plans under different site conditions; adding a new type of experiment does not require rewriting control programs; when the lab adds or replaces equipment, it only needs to declare its own capabilities to be incorporated into the orchestration.

Execution: Dynamic action scheduling across devices

The execution stage is responsible for turning the plan into physical actions of the equipment. The planning results are broken down into device-specific action commands, which are sequentially scheduled to different execution units such as liquid handling workstations, robotic arms, and mobile robots.

Each “handover” between devices is based on the on‑site state: whether the previous device’s action was truly completed, and whether the next device is idle and can reach the target position. To ensure safety, actions involving motion and grasping are not issued in parallel to the same device, preventing multiple commands from driving the same hardware simultaneously; all actions must also pass a safety fence boundary check before reaching the hardware (see Part 4 for details).

Feedback: use observation to validate and drive the next decision cycle

The feedback stage answers “Did we really accomplish that step just now?”. After each step finishes, its result is written to the execution memory, and the on‑site state is updated accordingly.

Before proceeding to the next step, the system checks the latest real‑world state to verify whether this step can be carried out. If reality deviates from the plan — for example, the target container is not where expected, the heating station is occupied, or the previous step did not achieve the desired result — a replanning is triggered, with a limit on the number of attempts to avoid endless loops.

Thus, the execution result becomes the new starting point for perception, completing one closed loop and moving on to the next.

III. Enable Physical Agents to Remember and Retrieve Clearly:

Execution Memory and Replayable Trajectories

Physical agents must operate stably for extended periods in a real laboratory, needing to “remember” the present — what the environment looks like after each step — and to “retrieve clearly” the past — how each experiment was carried out step by step.

Execution Memory: Maintaining Real‑Time State Awareness

In long‑running experiments, merely knowing “what to do next” is far from enough. Where is the target sample now? When was this location confirmed? Has the equipment moved since then?

Jiuwen Symbiosis’s execution memory automatically maintains this information: perceived target locations and device states are recorded; successfully executed actions have their outcomes automatically persisted for subsequent steps to inherit; if an action changes the reference relationship of a location—e.g., the robot chassis shifts—the previously recorded position is automatically invalidated, and the system knows it must re‑confirm rather than operate on stale coordinates. The entire process requires no hand‑written caching logic from developers.

Execution memory also follows two principles: on‑site observations take precedence over inferences drawn from execution records; any unconfirmed state is treated as “unknown,” not assumed “true.” If a bottle cap’s status has neither been observed nor proven by an execution record, the system will not assume it is open. For wet experiments, this is the key to preventing a “single unidentified object state bias” from causing cascading failures.

Replayable execution trace: from a single failure to a class of failures

Every action call, every on‑site observation, and every exception event is structurally recorded, with key frames saved as needed. After the task ends, this trace can be replayed as a complete visual report.

When a sample’s test result is abnormal, researchers can trace back along the trajectory: which step it was at, which device processed it, what the on‑site conditions were, and whether it experienced failures or retries. The system also supports offline analysis of large volumes of historical trajectories, automatically clustering failure cases, summarizing common causes, and generating improvement suggestions for manual review — not just handling individual failures, but continuously improving from categories of failures.

IV. Safety Baseline

Every action has boundaries

Dynamic orchestration makes the system more flexible, but in a wet lab, flexibility must be predicated on safety.

Jiuwen Symbiosis sets up a series of safety guardrails before any motion reaches the hardware. They are not a “post‑check” added at the end of the process, but are attached to key events during execution: a guardrail triggers before each motion‑type tool call, and a recovery guardrail triggers when a tool execution fails. On the test bench, this means commands that exceed the limits are rejected outright and never sent to the hardware. Even if a particular boundary has not been configured, the guardrail still performs type and value validity checks on the command itself, intercepting non‑numeric, infinite, or other abnormal parameters.

Safety is not only about “blocking” erroneous actions, but also about being able to “contain” the situation after a failure. If a motion or grasp action fails, the recovery mechanism strives to bring the device back to a known safe pose: if the end‑effector is not holding anything at that moment, it releases the end‑effector; if it is confirmed to be gripping a sample, it maintains the grip and performs a loaded retreat, never simply dropping the sample because of a single motion failure. If the repositioning itself fails again, the system does not repeatedly retry the same action; instead, it reports the issue accurately. Thus, the device returns to a known state as much as possible, providing a clear starting point for the next step—whether that is a retry, re‑planning, or handing over to a human operator.

Conclusion

From “Writing a Plan” to “Completing an Experiment”

Returning to the opening question: how do the experimental steps listed on the screen become physical operations on the lab bench?

The answer offered by Jiuwen Symbiosis is not a single, all‑encompassing model, but a system of agents for the physical world: using a closed loop of “perception → planning → execution → feedback” to see the scene clearly and dynamically orchestrate it, allowing device collaboration to adapt to the environment; using execution memory and replayable trajectories to record every step and trace every run; and using safety guardrails to enforce the boundaries of each action.

You are welcome to join the Jiuwen Symbiosis open‑source community:

Code repository:

• AtomGit:https://atomgit.com/openJiuwen/jiuwensymbiosis

GitHub:https://github.com/openJiuwen-ai/jiuwensymbiosis

Community:

• openJiuwen @ AtomGit: https://atomgit.com/openJiuwen

• Official website:https://www.openjiuwen.com/

© THE END

For reprints, contact this public account for permission

Submit articles or request coverage: liyazhou@jiqizhixin.com