LobeHub: A Multi-Agent Platform That Plans, Codes, Tests, and Reviews Its Own Work

Title: LobeHub is truly popular, practically the best implementation of Super-Agent.

After the previous post "Stayed up all night, finally understood the Super-Agent architecture" received high recognition, many friends also left messages asking: for DeepSeek Harness's Super-Agent mechanism, is there an implementation I can try?

To be honest, I'm also interested in this question. After all, Router/Worker, event-driven, context management, computation/environment separation — each concept is easy to understand on its own, but stringing them together is quite difficult.

So over the past couple of days, I studied a few open-source projects and found that LobeHub fits well.

This is an open-source project with over 80,000 GitHub Stars, previously called LobeChat.

When DeepSeek released important versions like V3 and R1, they often used LobeHub for demos.

Now LobeHub has grown into a multi-agent collaboration platform. A supervisor Agent can arrange tasks, with execution tools like Codex and Claude Code connected below, and manage long-running work through Task, Goal, and Workspace.

What's even more interesting is that the LobeHub team is already using LobeHub to develop LobeHub.

Their supervisor Agent dispatches tasks in team chat groups, specialized Agents handle development, testing, and PR submission, and finally humans review and accept the work.

So I thought, since they're already using it this way, can I set up a similar setup myself?

This time, I took a real development task for testing: let LobeHub build a web-based 3D game called "180 Seconds Before Power Outage."

The requirements were clear: players need to retrieve energy cores from different areas of the space station within the time limit and then return to the escape pod.

I had the supervisor Agent handle planning, Codex handle development, and another Agent handle game acceptance.

Next, let's see how these Agents collaborate and what problems we eventually run into.

Let's first review the characteristics of the Super-Agent architecture:

• Router/Worker two-tier architecture: A persistent Router communicates with users and distributes tasks to Workers, while Workers execute specific tasks.

• Event-driven with two-level filtering: Actively discover tasks and execute them based on Trigger; route based on Fast Path and Slow Path.

• Channel-oriented output: Supports full-duplex communication, asynchronous ReAct.

• Computation/state/environment separation: Storage-compute separation, computation and state separated, computation and environment separated.

• Context boundaries: Define the boundaries between context sharing and isolation.

You can check the actual execution flow of LobeHub below with these points in mind.

Understanding Super-Agent Through LobeHub

Next, let's verify how LobeHub works with a specific task.

I set up a web-based 3D game "180 Seconds Before Power Outage," where the player must move energy cores scattered across three areas of the space station back to the central escape pod within 180 seconds, then enter the pod to win.

My main LobeHub Agent is called June, and we can trace its pipeline.

Router and Worker

After receiving the task, it breaks it down, creates a development Agent, and then arranges an acceptance party.

Our June runs on Opus 5.5.

Then June arranged the development and acceptance sides: the developer is a Codex software engineer, and the acceptance side is a game acceptance engineer.

June then split the task into several steps.

We can see the assigned tasks in the Codex engineer's Tasks.

From June's task layout, we can see its requirements research and assignment situation.

Each subagent has its own task execution boundaries and status descriptions.

During goal and other long tasks, all context and comments are stored in the same Task.

During specific task execution, you can see the content and results of each round.

After execution, the main Agent June interacts with the user and reports results.

Here I want to share something interesting.

For example, the LobeHub team itself develops LobeHub in a similar way.

They deployed a supervisor Agent called Nasa in Discord, responsible for managing tasks, coordinating different execution Agents, and tracking deliverables.

For example, there was a task T-1149. Nasa assigned it to a Coding Agent named Dario. Dario then completed development, testing, and submitted PR #21852 to GitHub.

This also explains why LobeHub integrates Agent, Task, Goal, Workspace, and the execution environments of external Coding Agents.

Because they already use these capabilities to organize real software development work in their own R&D team.

This is what I find interesting about LobeHub: it has long been continuously developed and iterated by its own Agents.

Event-driven

The DSH team proposed the Trigger mechanism — proactively discover tasks and execute them based on Trigger, and route via Fast Path and Slow Path.

Let's demonstrate how this is implemented in LobeHub.

In Agent settings, you can configure IM bots.

For example, we directly configured a Feishu bot. Of course, you can configure other IM terminals too — Discord, WeChat, and Slack all work.

For example, I created a group with three bots: June, Codex development engineer, and game acceptance engineer. If you ask about project optimization, June will summarize and report.

Even the Codex Agent can proactively discover and execute tasks. For example, it discovered a Codex startup configuration warning issue.

The image above shows the Agent discovering the problem itself. But most of the time, Triggers come from outside.

Open the Agent's IM bot and you can see the Agent's Wake policy, which is more like writing duty rules for an employee:

The Wake policy actually consists of two parts.

The first layer is rules. It only wakes in a few cases: when someone @mentions it, privately messages it, replies to it, or when a message hits a watch keyword.

The second layer is model judgment. When "Speak up on its own" is on, it reads messages not directly addressed to it, and decides whether to interject based on the Duties defined (channel scope and pace).

All these wakes are eventually archived as wake records.

So it corresponds one-to-one with the two-level filtering from the DSH post: @mentions, keywords, follow-ups are Fast Path — rules filter out noise first; then it's handed to the model, which combines duties and context to decide whether to intervene — that's Slow Path. The difference is that LobeHub has made both layers a configurable, reviewable, and correctable product.

Device Access

In device management, we can see LobeHub has connected both local and cloud environments.

In LobeHub, the execution environment is selected per Agent granularity, with six levels: No device, Auto (auto-select when multiple devices are online), Local device (runs as a local process), Local sandbox (restricted working directory, offline), Cloud sandbox (runs in cloud, no need for your own machine), and finally through a device gateway.

Then under Settings -> Devices, you can see the host hardware info, Agent status, and Topic (task) status.

We can see that, using the cloud Agent calling local device mode as an example, it can be divided into three parts:

• Computation: The cloud Agent Loop calls models, plans tasks, and decides next steps;

• State: Conversations, Task progress, and execution records are stored on the platform for continued follow-up;

• Environment: Code, files, and toolchain stay on the Mac mini; a local daemon receives tool calls, executes them, and returns results.

Put together: Cloud Agent → Device Gateway → Local Daemon → Return execution result to Agent.

Context Boundaries

The DSH team's article listed context boundaries as an open question.

LobeHub's approach is this: they use Linear-style Task management for Agent collaboration. Taking the Workspace demo above, in the same space, task context, execution progress, and all comments live in the same Task — information is naturally shared, traceable, and easy to manage.

This is the CAO mechanism they went live with in May, now stable for six months. Multiple tasks can run in parallel, large amounts of work are done autonomously by Agents, humans only step in at critical nodes, and the team shares all information within the same Task.

CAO stands for Chief Agent Operator, usually translated in Chinese circles as "首席 Agent 运营官" (Chief Agent Operations Officer). Don't laugh :)

I understand it solves the management problem: when one person has a dozen Agents in hand, what they need isn't a chat box, but org structure and dashboards.

From the actual test above, we can see three designs:

• Space: humans, Agents, and tasks are in the same Workspace, information is naturally shared, no need to forward back and forth;

• Linear-style Task: a task isn't a one-time conversation but a card, with context, progress, and comments attached to it, traceable;

• Human's position: only steps in at critical nodes, i.e., bounce back or approve.

These three exactly fill the open questions of the DSH team.

The Task detail above is proof: status changes, each round of goal loop, comments from the development Agent, and deliverable documents in Artifacts are all on the same page.

LobeHub uses Workspace and Task to provide a task-level context management solution already running in a product. It allows multiple Agents to share necessary information around the same task, while preserving execution records and delivery evidence.

But an Agent finishing doesn't mean acceptance passed.

Normally we'd manually accept.

After this round, I feel this statement needs half a correction: the acceptance process can be handed to an Agent; humans only keep the final "bounce back or approve".

The LobeHub team also just released an open-source project called Acceptance, a tool based on Agent Loop, an end-to-end acceptance testing Loop for Agents, so that AI can produce acceptance evidence before delivery.

When accepting, they directly integrated Acceptance.

After integration, deliverables and acceptance records are evaluated simultaneously. Here's the actual game running.

Then look at the acceptance itself. For example, the game acceptance engineer follows Acceptance to accept, and finally leaves it to human judgment:

There's a counterintuitive point here: acceptance failure doesn't mean delivery failure.

After failure, it goes back to development for rework. Round 6 submitted the two media items:

After judgment, you can see C1 and C2 have passed acceptance.

You can see that every step has auditable records: round number, the reason, what was delivered, and what was judged.

Only then did Acceptance pass.

Summary

After this tinkering, what I find most interesting about LobeHub is that it begins to treat multi-agent collaboration as a system that can run and be managed continuously, rather than a one-off task orchestration.

Previously, when building Multi-agent setups myself, I mostly solved how to split a task among several Agents. As soon as tasks got complex, new problems appeared: progress, status, how to handle exceptions, how to hand off, and how to accept.

But this round of testing also showed me that being able to dispatch tasks and being able to stably deliver results are separated by quite a gap.

That's exactly why tools like Acceptance exist: when an Agent says it's done, you ultimately have to test it with real run results, screenshots, screen recordings, logs, and test records.

What's even more interesting is that the LobeHub team itself does this. They've already moved their R&D workflow into LobeHub, letting Agents participate in developing LobeHub, and then using task records and acceptance mechanisms to iterate round after round.

So to say that Super-agent is mature at this stage, I think it's far from that. But at least, we can now observe and even personally test the entire process on real projects, rather than imagining it against architecture diagrams.

I think this LobeHub test provides a smooth, ready-to-use product reference for Super-Agent.

If you're a developer, you can definitely try it with your own code repository and see what changes when a group of Agents work together in your workflow.