DeepSeek's Super-agent Design and Our Engineering Practice

Author: Cang He

Tags: Backend

Hello everyone, I'm Cang He.

Recently I read DeepSeek Harness team's "Super-agent Design Exploration: Toward More Autonomous Agent Systems" and was deeply impressed.

Over the past year, the individual capabilities of agents have grown significantly, but many are still stuck in single-session conversations. Switching conversations requires actively remembering context, and when many sessions run in parallel, human attention can't keep up.

The recently popular Personal Agent, in a personal assistant scenario, can continuously observe information flows and assist with tasks, and it has globally aware context. It's a good form of Super-agent.

The actual work of a Super-agent is executed by multiple Workers in parallel, each retaining its own context and connecting to real tool environments as needed. Follow-up messages for existing tasks can also be sent along subscription channels directly to the corresponding Worker, avoiding an extra round-trip through the Router.

A database underneath stores session state, and an external Watchdog monitors exceptions and execution progress.

These parts work together to let the system accept work at any time, keep executing, and recover from problems.

In summary, it's four words: continuous, efficient, proactive, and persistent.

So in real work, how do you organize a group of agents so tasks keep moving forward?

I've been exploring this too. I've tried many approaches. For example, when openclaw and hermes were hot, I tried building a complex multi-agent architecture myself.

But that system fundamentally didn't solve the problems of practice-driven and autonomous perception-decision making. At best it was a simple multi-agent architecture.

The essence is that it still required humans to filter information and make decisions; it wasn't event-driven or autonomously deciding. A simple example will make this clearer.

Suppose we have an agent that collects hot topics. It throws the daily hot topics to a team agent, and the team agent needs a human to confirm which topics to use for content selection. When the volume gets large enough, human attention becomes very limited, and sometimes the collection itself becomes meaningless.

But honestly, building a Super-agent on your own can seem complex, especially for those without a technical background. After researching, I found that there are already some mature solutions on GitHub.

You can try them yourself. Below I'll share some of my practice using LobeHub to build my own Super-agent, hoping to give you some inspiration.

If this article helps you, you can like and share it to let me know.

LobeHub is an early AI open-source project, previously called LobeChat. Many who first encountered GPT should have heard of or used it. I was among the earliest users. In 2025 it became LobeHub, an Agent platform.

After developing for a few years, it now has over 80k stars, with strong momentum.

Open source address: https://github.com/lobehub/lobehub

And I saw online that they've started using LobeHub to continuously develop and iterate on LobeHub itself.

LobeHub originally supported specifying a model per task, but only through the web interface. When agents create tasks via tools or the command line, that entry point was missing. That made it impossible to have one model plan and another execute a task.

After Supervisor Agent Nasa identified the problem, it created task T-1149 and assigned it to execution Agent Dario, which is based on Claude Code. The task description spelled out the current state, the missing entry point, and acceptance criteria. Dario took over and continued development.

In the end, Dario delivered PR #21852, adding the ability to specify a model for built-in task tools and the CLI. The delivery record included change descriptions, test results, and an acceptance report, and it also listed parts that needed further validation after deployment.

I also looked at the corresponding GitHub PR. It explicitly links to T-1149 and records the AI's participation in code implementation, testing, and validation. The PR has been merged.

PR: https://github.com/lobehub/lobehub/pull/21852

From identifying the problem, creating a task, assigning execution, to submitting code and providing acceptance evidence, this collaboration model is already used in their own development. More interestingly, the capability the Agent added this time happens to be the one that makes it easier for future Agents to work in a division of labor.

Recently I've also tried similar collaboration in my own work, such as updating my Codeguide website.

I first told the build assistant the division of labor and collaboration model I wanted, and it helped me set up a codexguide product development group.

The group has 1 Supervisor Agent and 6 execution Agents, with roles, rules, and processes configured.

In addition to LobeHub's Agents, I also integrated local Codex and Claude Code so the team can use tools from real projects.

For example, I asked it to audit the entire site content and give update priorities.

The supervisor first hands content review to the content editor: check the code repository and live pages against official documentation, and organize problem evidence, revision suggestions, and acceptance criteria. Subsequent implementation and review are then handed to other members according to their roles.

I went to the content editor first because this round needed to judge whether information is outdated, whether conclusions have sources, and which pages deserve priority updates. I configured the editor with a default read-only review role to first investigate these issues. When local validation or file modification is needed, I hand it to Codex or Claude Code, which have development environments, and arrange an independent Reviewer to re-check.

The basis for this division is each member's role, tools, and execution environment. When the supervisor assigns work, it also has to pass along the goal, input materials, the allowed modification scope, and acceptance requirements, so the next member can continue.

The content editor reviewed the codexguide repository and live content, organized the discovered problems, corresponding evidence, revision suggestions, and acceptance criteria into a report, and arranged the schedule for subsequent updates.

The report also includes verifiable sources, so wherever there really is a problem, I can confirm it item by item by following the evidence, without taking its word for it.

The embedded content "codexguide Site-Wide Review.mp4" was not published with the share.

The problems found in the review then went into actual fixes and PR delivery.

For specifics on how I delegate, you can look at the delegation record for fix #48. The supervisor had Codex modify the third-party API authentication documentation and submit a PR, then hand it to a Reviewer for re-check. The other two issues were handled by the supervisor itself. I didn't enable the group's Task recording this time, so the delegation process stays as cards in the group chat message flow.

Expanding the card reveals the target repository, baseline commit, affected files, problems identified by the content editor, links to official materials, and a scope of "can submit a PR but not merge or publish." The supervisor is handing Codex a work specification that can be executed independently.

This handoff requires two things to be explicit: what inputs the executor gets, and how far it can go this time. Review comments can serve as revision leads; for technical details like authentication, Codex also needs to look back at official documentation and the current repository to confirm the suggestion is valid.

Local environments also need to be connected. I looked at LobeHub's open-source implementation: with the CLI connection as an example, lh connect connects to the device gateway, and when an execution request arrives, it starts the corresponding Agent flow on the local machine. The request includes the Agent type, working directory, prompt, and topic identifier, so cloud-dispatched work lands on specific machines and directories.

Device connection implementation: https://github.com/lobehub/lobehub/blob/canary/apps/cli/src/commands/connect.ts

So when integrating Codex or Claude Code, you first make sure the local CLI works, then connect the device via the desktop client or CLI connector, and configure the execution members with their corresponding environments and working directories. Whether they can read/write files, run commands, and push code also depends on local file permissions, CLI execution limits, and Git and GitHub login/authorization status.

In my collaboration rules, an executor must first read the repository's AGENTS.md before starting, check git status, the current branch, and baseline commit. Existing uncommitted changes are to be preserved. When multiple people are writing code at the same time, use isolated worktrees; if isolation isn't possible, serialize the work. Permission to modify files, push, open PRs, merge, and release are also stated separately. These rules need to be followed by the executor, but actual access limits are still controlled by the local environment and server-side permissions.

For delivery, I require a summary of file changes, the actual commands run and their results, and links to commits and PRs. A Reviewer has to re-check the specific version; if new commits are added later, the affected parts need to be checked. Tests that haven't been run and pages that haven't been verified also need to be written down.

The team-provided Acceptance is another verification approach: break the requirements into check items, attach actual product screenshots, recordings, and logs, and summarize them into a report so people can accept item by item or request changes.

In my group rules this time, I first require a Reviewer to independently re-check the specific code version. When page behavior needs to be verified, screenshots and recordings can also be included as evidence.

Acceptance open source address: https://github.com/lobehub/acceptance

This round of review also showed me that the site's biggest problem is still content freshness.

When Codex's official site has news and I'm busy and don't sync it quickly, the site's information lags. Once the existing problems are fixed, someone still needs to keep following up on updates.

So I asked it to add automatic inspection, turning this review into a regularly executed task.

The supervisor analyzed the requirement, handed content comparison to the content editor, and gave the scheduled inspection to the Lobe assistant. From then on, checks are initiated at set times, reducing my manual follow-ups.

This inspection isn't just a matter of setting a timer. Task status, data sources, comparison targets, inspection scope, delivery content, and authorization scope are all configured item by item, giving subsequent execution clear basis and boundaries.

This daily inspection was created as an independent T-2 Task, scheduled to run every day at 9:00 AM Beijing time. The task page already has records from the first and second rounds, and the handoff comments from the supervisor, Lobe assistant, and content editor are also below.

From the content editor's own page, you can also find execution topics with "source: task." The Task carries the ongoing inspection, while each round of execution has its own topic record. After a topic is archived, subsequent inspections still need to continue as scheduled.

This also explains when I directly delegate to a member and when I create a Task: work that's already clear in the current group chat can be handed to the corresponding Agent via a delegation card; work like the daily inspection, which needs to run repeatedly and keep inspection progress across days, is better suited to an independent Task. If I later need to manage more dependencies and review rounds, I'll prioritize putting such work into tasks that can be tracked continuously.

Context handoff also has concrete landing points. This time the long report is saved in the content editor's Agent Documents, and the link is pasted into the task comment; code changes live in the repository and PR; subsequent inspections are asked to continue from the inspection progress, unresolved items, and report links in the comments. With this division, delivery can be organized like this:

Deliverable	Storage and handoff method
Review report	Agent Documents stores the full text, task comment holds the link, subsequent executors confirm the link is readable first
Revision suggestions	Group chat delegation card or task description spells out affected files, problem evidence, revision approach, and acceptance requirements
Code changes	Git branch, commit, PR store actual changes; delivery record includes links and command results
Review conclusion	Written back to the corresponding task or delivery record, noting the commit checked, issues found, and unverified items

A real problem came up here: the content editor couldn't open the expected parent document for inspection. The tool returned Document not found and Parent not found. It temporarily saved this round's report in its own Agent Documents, then wrote the link and blocking reason back into the task comment. The expected archive document's progress and index weren't updated.

The supervisor then asked that subsequent rounds first use task comments to hold inspection progress, deduplication clues, and unresolved items, and then try to establish a usable archive location. This can catch the work log, but whether another Agent can actually read the report still has to be verified by opening it. The file being saved, the link being passed along, and the next person being able to read it are three separate things to confirm.

Review configuration has similar details. In the record, the Lobe assistant tried to set an independent Verify, but after writing it, a subsequent query showed not configured, so it instead configured a task Review with autoRetry=true and maxIterations=2. These are configuration handoff records; the first round had no independent verdict sheet, so it can't be treated as a confirmed review pass.

For PRs being rejected, dependency changes, or execution failures, I've defined handling in my collaboration agreement: leave the failure reason and evidence in the original task, submit a new version after fixing, and re-review against the new commit. When upstream conclusions change, re-check affected downstream work. When permissions are missing or scope needs expanding, report the blocker first, then have the supervisor coordinate or come back to me for confirmation.

LobeHub also supports message-event-triggered work: it filters based on rules like channel scope and keywords, then the model combines the Agent's role to decide whether to intervene. For example, if someone in the group reports a defect and the conditions match, it can trigger downstream handling.

This also makes me think: "proactive" requires the conditions to be stated clearly. When to check, under what circumstances to intervene, how far it can go, and where it needs to come back and confirm with a person. Once these are configured, and you look at the evidence left by each round, you can gradually hand over continuous follow-up.

Besides tracking official updates, I also wanted to add some real use cases to the site, so I asked it to find noteworthy Codex usage on X.

After searching, it organized a batch of cases and gave a recommendation reason for each, so I can judge which are worth further research and organization.

It also looked at an issue I'd filed a long time ago and gave a detailed reply inside it.

What's useful to me in this step is that the judgment basis and follow-up suggestions are left under the original issue. When I later handle that issue, I can confirm progress by following the record, and related information is easier to find again.

Besides site maintenance and issue triage, I recently handed off topic research for short videos to Lobe as well.

I asked it to analyze Douyin videos related to AI tools, AI efficiency, and AI programming, see what practices those videos have worth borrowing, and combine the comments section to organize real user needs.

After receiving the task, Lobe split the research into two threads, created sub-assistants, and ran parallel searches on AI tools and efficiency content, and on AI programming content.

During execution, the right panel shows the current running tasks and their resource usage, and also lets me check the local machine's CPU, memory, and disk usage, so I know how the task is running and how loaded the computer is.

If you want to see concrete progress, open the sub-assistant to view its execution process and output.

After both threads finished, Lobe aggregated the results into an analysis report. It compared account scale and video metrics, and also analyzed each video's content depth, titles, and comment feedback.

On that basis, it further mapped out each video's content type, factors likely to drive spread, practices worth borrowing, and demand signals from the comments, then organized topic strategies, recommended video structures, and pitfalls to avoid, connecting the benchmark analysis to downstream content creation.

The embedded content "Douyin Video Analysis.mp4" was not published with the share.

Beyond this analysis report, it also organized the recommendations into a practical handbook, giving concrete moves from account cold-start and ready-to-use topic ideas to script writing, shooting different video types, and post-production review. That way the earlier benchmark analysis isn't just for my reference; it can be used directly to plan topics and shoots.

The whole task ran for about an hour, from the two-thread search and analysis to the report aggregation and practical handbook. What landed in my hands included both the analysis results and next-step content I could start acting on.

The entry point for assigning tasks can also be placed in the chat tool you normally use. For example, I integrated it with WeChat.

In WeChat, I asked it to find notable cases from the past week on X of using opus 5.5 for video production. After receiving the request, it allocated sub-agents and started searching. That way, when I think of a research question, I can hand it off right in WeChat.

After practicing this, what I feel most is that after one step is done, there's a chance the work continues moving forward.

Problems found in the site review flowed into actual fixes and PRs. Worrying about outdated content led to configuring inspection. The short-video research produced a handbook that can be used to plan topics and shoots.

No matter how strong a single Agent is, if it's confined to a single conversation, the work breaks at the conversation boundary. With supervisor delegation and task handoff, the output of one step becomes the input of the next, and the task has a chance to keep rolling on its own.

Looking back, my earlier self-built multi-agent architecture was stuck at the same place.

The hot-topic collection Agent threw results to the team, waiting for a person to confirm topics. When people got busy, the whole line stalled.

No event-driven behavior, no autonomous decision-making, and the human became the bottleneck.

Now with supervisor delegation and task handoff, I can put more attention on goals and results: which content deserves updating, which topics suit me, and whether delivery meets requirements.

Of course, these judgments still have to be made by me. Before a task starts, I spell out the goal, scope, and acceptance requirements. When results come back, I check against the evidence and give specific revision feedback.

In this system, the "proactive" part of the Super-agent matters especially.

When to check, under what circumstances to intervene, how far it can go, and what needs to come back for confirmation.

If the conditions aren't clear, proactivity becomes a nuisance; when they are clear, and each round leaves evidence, you can gradually hand over continuous follow-up.

To be honest, after using this for a while, my understanding of Agents has changed.

At first I thought using an Agent meant replacing myself.

Later I found that's not what it is at all.

Those repetitive, information-driven execution tasks can indeed be handed off. What remains is actually the part that needs me more: judging whether something is worth doing, whether the result meets the standard, and where to go next.

Super-agent gives my time back to me, letting me focus on the decisions that really matter.

LobeHub using Agents to develop LobeHub also confirms some things.

The capability the Agent added was exactly what makes it easier for future Agents to divide and execute work.

Getting your own process running, then letting the process help you run faster, is what "persistence" should look like.

I increasingly feel that the core skill of someone who uses Agents well isn't "knowing how to write prompts." It's understanding goal decomposition, acceptance standards, and driving iteration.

This is essentially project management.

Except the team you're managing is all AI.

Are you also building your own Agent workflow? Feel free to share your practice in the comments, or give a like to let me know this was helpful.