←News detail

Sina TechUpdated Nov 3 10:10

DeepSeek Proposes Super-agent Concept: Managing Sessions with a Two-Layer Router and Worker Architecture

AI summary

DeepSeek published an article introducing the Super-agent concept, arguing that Sessions should be hidden from the front end and replaced with a two-layer Router plus Worker architecture that dispatches tasks uniformly, so the front end always faces only one Agent. The article says the design also includes Fast Path and Slow Path dual filtering of external messages, asynchronous task execution, and placing thinking and state in the cloud while a local Daemon handles execution, and that an experimental prototype has already been open-sourced on GitHub. Sina Tech also noted that cross-Session memory management, permission boundaries, and security remain unresolved issues.

Why read this

AI score 60

The article breaks DeepSeek's Super-agent concept into three layers—architecture, triggering, and execution—to make the engineering challenges of personal agents easier to understand.

Topics

Tags

Body · AI translation

Add crowdsourcing promotion copy Add crowdsourcing promotion copy end Add App-exclusive traffic routing

A couple of days ago, DeepSeek published an article introducing an idea called Super-agent.

Whether it's Super or not, we don't know, but the substance inside was really dry—the engineering design was explained in such fine detail that it left everyone a bit foggy.

But actually this isn't complicated. Just look at it together with the recently popular Muse and Grok Bot, and you'll find that DeepSeek is actually directly putting the Personal Agent matter on the table.

They proposed that to build a usable Personal Agent, it must at least satisfy 4 characteristics: continuous, efficient, proactive, and persistent.

None of these is easy.

Not to mention anything else, just the current usage where everyone opens a pile of conversations for one task is not efficient at all.

In professional terms, people call these conversations Sessions. A Session is an independent small environment that stores your chat history with the AI, tools, environment configuration, and a bunch of other things.

And basically all current Agents use this Session model, and they don't interoperate with each other.

Usually you first open a dialog box to look up information; then open another for brainstorming to sort out ideas; then open another to write a proposal; finally open another to formally start writing code and building the project, and behind that there's actually another one for verification and checking...

At first glance this design seems quite intuitive. Each Session is independent, and results on the code side are convenient to feed back to the proposal side for iteration, and vice versa. It's not easy to mix things up when working.

But don't forget, when it comes to attention, humans are quite weak. If the project architecture is clear, we can still manage, but if it's a big job involving multiple people, then even hooking up two brain-computer interfaces on the outside probably wouldn't be enough.

According to DeepSeek's estimate, when interacting with AI, humans can follow 3 to 5 Sessions at the same time at best; any more and they simply can't hold on.

Under this Session-centric architecture, humans are no longer humans—they're purely context movers.

The key is you also can't stuff all tasks into one Session. Doing so, not to mention context explosion, the tasks themselves would have to queue up slowly one by one, and with too many details, the model easily becomes mentally split...

So what to do?

DeepSeek stepped in. Human attention is weak, but AI's isn't. This Session thing, plainly speaking, shouldn't be something humans worry about.

They simply hid Sessions from the front end and built a two-layer Router + Worker architecture.

Simply put, they added a Router routing layer on top of these working Agents, acting as a big steward that uniformly assigns work.

When you submit a request on your side, the Router receives it and, depending on the situation, assigns it to a suitable Worker. Submit another, and it assigns again.

Although a bunch of Workers are running in the background, on the front end you always face only one Agent, with none of the cumbersome feeling of splitting Sessions.

It sounds a bit like an Agent cluster, but it's actually completely different.

An Agent cluster splits one thing among different sub-Agents that work together and disband on the spot when done.

Super-agent, by contrast, forms a small team. It isn't born for a certain task, but continuously advances a bunch of messy things according to your needs. Even if some job is done, the team won't completely disband.

Besides the architecture, current Agents are also criticized for being "passive."

Because no matter what model they use, at heart they're still responsive oversized ChatBots. You poke them and they take a step; if you don't speak, they play dead.

But ideally, we'd still hope Agents can be more proactive.

After all, in real work environments, it's impossible to write everything into formal written reports. Many requirements and feedback are actually hidden in everyone's group chat records.

If an Agent could extract real task requirements from this idle chatter, that would be truly amazing.

So DeepSeek designed it this way: not just group chats, but emails, calendars, GitHub issue comments, and so on can all be connected.

They collectively call these external messages Triggers—that is, the trigger—which can trigger certain events.

Then the question comes: a group chat can easily have hundreds or thousands of messages a day. How do you identify which are Triggers and which are nonsense?

Ah, this relies on Super-agent's dual filtering mechanism.

After connecting to IM, messages must pass through two layers of filtering before being sent to the Agent: one is Fast Path, the other is Slow Path.

Fast Path must be fast, so it uses hard-coded programs. For example, whether the message source is on a whitelist, whether it's from a chit-chat group or a business group—just run through it once and a large number can be filtered out.

By the time it reaches the Slow Path, only the filtered candidate messages remain; at that point they are handed to the large model to judge whether they have value and whether they can be distilled into requirements.

This is already quite token-efficient, but to further improve cost-effectiveness, DeepSeek also designed a subscription mechanism.

For example, if a Worker has already taken on a GitHub PR requirement, subsequent comments and feedback under that PR can be pushed directly to it, without having to go back through the Router for reassignment every time—dedicated handling for dedicated matters, as it were.

And to guard against the information volume being too large, DeepSeek borrowed from computer cache management ideas and used Inline & Spill.

Anything likely to be used in the near term is Inlined directly into the context; historical information that is not useful for the time being is hung outside, Spilled out, with only a directory index left, to be looked up when needed.

This is classic chained recall—equivalent to giving the Agent a records room; no matter how much stuff there is, once the directory is compressed it can all fit.

Of course, if there is one part of the whole system that is the smoothest, it may be its task design.

Overall, it is all about putting humans first.

To match the filtering mechanism above, they used a rather aggressive idea of "speculative execution."

No matter where the human discussion has gotten to, as soon as my Agent gets the message, it first tries in the background; if it works, it tells you, and if not, nothing happens, so that you don't belatedly make me start over and waste waiting time.

Look at that perceptiveness—a thoughtful secretary doesn't even need the boss to open his mouth, right?

And this background task execution is also done with care.

In the traditional ReAct Loop approach, tasks are executed synchronously; if an Agent calls a tool, it will be stuck there until the tool returns the execution result, and only then can it hear the user's next message.

But in the Super-agent vision, this was changed to asynchronous execution, completely decoupling foreground chat from background execution; you can let it run code while arranging other work, without standing around waiting in line.

Agent things are useful because they can directly modify things locally, but that also means once you shut down your computer, they clock off immediately.

This obviously does not fit the Super-agent vision; at the very least, like those Personal Agents, it has to be on standby for us 24 hours a day.

So how to do that? Ah, friends who have tinkered with Agents may have already thought of it: cloudification.

According to DeepSeek's thinking, the Agent system can be divided into three parts: the brain responsible for thinking, the state that preserves context, and the execution environment that mounts various dependencies and tools.

Of these three, the first two can actually be put in the cloud. As for the last environment, although it cannot be moved up there, DeepSeek designed a lightweight little thing called "Daemon," which stays local and is dedicated to doing this one thing: execution.

That way, it can be moved to the cloud and be on standby 24 hours a day.

Of course, considering compatibility issues across all kinds of devices, they also deliberately left a watchdog—yes, it is called Watchdog—patrolling back and forth in the background.

It is responsible for checking whether Workers are doing their jobs properly, or whether any process is stuck somewhere, to prevent falling into an infinite loop.

With all this in place, this Super-agent is indeed super enough.

Of course, just drawing a big pie is not DeepSeek's style. To prove this thing is feasible, they conveniently open-sourced an experimental prototype on GitHub.

After reading through it, you can feel that this thing was not thought up on a whim; many things they had already tried internally, and are even already using.

Whatever works is all written out, and there are also some thornier ones, like cross-Session memory management, permission boundaries, and security. On these they themselves are actually not sure, and can only be said to give everyone an idea to explore slowly.

But no matter what, after unpacking it layer by layer like this, everyone should be able to see why Personal Agent is appealing and how it is appealing.

It is not like training models, where brute force does the job; underneath, it still has to be matched with all kinds of precise engineering methods.

What DeepSeek did this time is put the thinking on the table.

These problems are certainly not only encountered by them; a look at the official community shows that not only big companies, but many individual developers have actually made similar attempts.

Combined with the technological equalization of AI, to put it plainly, this useful Agent may not necessarily be built by big companies first.

Who knows, one day the community may tinker out a true Super-agent, letting the big fat fish in our hands live as a real big fat fish.

No longer parasitic in a dialog box with a million-token context, but with its own memory, work, and rhythm, accompanying you through a complete life...article_adlist[

Responsible editor: Ruofeng

Article content report]article_adlist Statement: This is an exclusive article from Sina.com; unauthorized reproduction is prohibited. tech_web_article_v2015_block_bottom Non-targeted 300*250 button 17/09 wenjing begin

Non-targeted 300*250 button end

Source

Sina Tech