Liang Sheng's Open-Source Super Agent Architecture: Keeping AI Online Long-Term to Work Proactively

From "Waiting for Instructions" to "Proactively Identifying Problems": A Key Turning Point in the Agent Paradigm

According to a Bilibili creator's share, developer Liangsheng (Liang Sheng) recently open-sourced a super agent architecture called DeepSick Operating Prototype. Its core idea isn't complicated, yet it hits the most awkward pain point of current AI agents: most agents are essentially "slaves to conversation" — you ask, it answers; once the window closes, the task ends. This architecture attempts to turn AI from a passive responder into an Agent that stays online long-term, proactively identifies problems, and executes tasks.

The significance of this shift: the Agent is no longer constrained by the lifecycle of a single conversation window. The agent of the past was like a temp worker who needs to be briefed on the background every time they come on shift; a long-term online agent is more like a permanent employee who continuously perceives the environment, accumulates context, and proactively advances work within the bounds of its rules. According to the creator, this is exactly what makes the architecture "really good" — it may not be an algorithmic breakthrough, but rather a recombination of engineering mechanisms.

Two-Layer Decoupling: Router Handles the Global, Worker Handles Concurrency

The DeepSick Harness team rebuilt from the ground up, splitting two fundamentally different things — "maintaining global continuity" and "high-concurrency work" — into two layers:

• Router layer: responsible for global scheduling and user interaction, holding overall state and task dispatch;
• Worker layer: each maintains independent context and processes specific tasks in parallel.

This split resolves a common architectural contradiction: if all context is crammed into a single session, concurrency becomes impossible; if fully parallel, global consistency is easily lost. After layering, the Router ensures "who I am and where the overall progress stands," while Workers ensure "how to quickly finish this specific thing," and the two don't interfere with each other. According to the creator, this is the most noteworthy part of the architecture's engineering design.

Event-Driven: Tasks No Longer Start Only from Instructions

The task-driving mechanism has also changed. The Agent no longer relies solely on user instructions to start tasks, but listens to external events from GitHub, group chats, CI, and so on. When there's nothing worth handling, it stays quietly idle, consuming no resources and disturbing no one; once an event triggers, it enters a working state.

This design lets the Agent truly embed itself in the workflow — code commits, pipeline statuses, and team discussions can all become its input sources, rather than waiting for someone to remember to ask it.

Event-Driven Architecture is a pattern that organizes system behavior around the generation, detection, and response of "events." In the traditional request-response model, the system runs only when called; in an event-driven system, the system continuously listens to external signal sources (such as Webhooks, message queues, file changes, CI status callbacks), and triggers the corresponding processing logic once preset conditions are matched. For an Agent, this means it can take GitHub push events, @mentions in group chats, pipeline failure notifications, etc. as "inputs," with the events themselves — rather than human questions — driving task initiation. Event-driven design is usually paired with publish-subscribe mechanisms along with deduplication and rate-limiting strategies; otherwise, event storms can easily cause duplicate processing or resource waste, which is the engineering reason why later sections emphasize "filtering simple events with code."

In the Agent context, "context" refers to all the information visible to the model when completing a task, including conversation history, tool call results, environment state, and so on. Constrained by the model's context window length, cramming all information into a single session is both expensive and prone to mutual interference. The Worker layer "each maintaining independent context" means: each concurrent task has its own isolated context space, loading only information relevant to that task, which can be reclaimed or summarized and archived after the task ends; the Router layer, meanwhile, holds a lightweight global state (such as which tasks are currently running, their individual progress, and priorities). This division of "light global state + heavy local context" is a common pattern in distributed systems; it allows concurrent scaling without linearly increasing the single-point context burden, while ensuring global consistency is maintained by a single scheduler.

Cost Control: Filter Simple Events with Code, Only Hand Complex Events to the Model

The biggest hidden concern of proactive Agents is runaway inference costs. The architecture's response is tiered processing: proactively advance when rules allow, filter simple events directly with code, and only hand complex events to the model for judgment.

The value of this mechanism is putting model compute where it matters most. A large number of routine events can be handled with deterministic logic — there's no need to invoke a large model every time; only scenarios that truly require understanding and judgment incur inference costs. The creator explicitly mentions that this is to "reduce unnecessary inference overhead."

The inference overhead of large models is mainly reflected in the number of tokens consumed per call and the call frequency. Because proactive Agents continuously listen to events, their call frequency may be far higher than that of conversational Agents, making costs easy to spiral out of control. "Filtering with code" means applying a layer of screening with deterministic rules (such as event type whitelists, keyword matching, changed file paths, status code checks) before entering the model, directly handling or discarding events that clearly need no processing or can be handled programmatically. Such deterministic logic costs nearly nothing and produces predictable results, while model calls are suited to scenarios requiring semantic understanding and fuzzy judgment. The industry often calls this approach "model tiering" or "routing-based cost reduction"; combined with techniques like large-small model collaboration and cache-hit reuse, it can concentrate the inference budget on high-value events while maintaining proactivity.

Not an Algorithmic Innovation, but a Recombination of Engineering Mechanisms

To be objective, the creator himself points out: these designs do not count as entirely new algorithmic innovations. Router/Worker layering, event-driven design, and tiered filtering are all engineering patterns familiar to the industry when viewed individually.

The real value lies in recombining them into the Agent runtime, thereby freeing the Agent from the lifecycle constraints of a single conversation window. Such work is often less eye-catching than breakthroughs in model capabilities, but it is crucial to whether Agents can move from demos to production environments. Open-sourcing this architecture also provides a reference implementation sample for developers focused on Agent engineering.

For teams building Agent applications, what's worth noting about this prototype isn't any single-point technology, but how it uses layering and event-driven design to simultaneously achieve the two goals of "long-term online" and "high concurrency."

One-line Summary

An open-source Agent architecture uses layering and event-driven design to keep AI online long-term and working proactively.

Paragraph Summary

The article introduces the DeepSick Operating Prototype super agent architecture open-sourced by developer Liangsheng. Its core is transforming AI from a "slave to conversation" into a resident Agent that stays online long-term and can proactively identify problems and execute tasks. The architecture achieves two-layer decoupling in engineering: the Router layer handles global scheduling and user interaction, while the Worker layer each maintains independent context and processes tasks in parallel, balancing global consistency with high concurrency. Task initiation no longer relies solely on user instructions but listens to external events such as GitHub, group chats, and CI, staying silently idle when there are no events. For cost control, it uses tiered processing: simple events are filtered with code, and only complex events are handed to the model for judgment. The article notes that this is not an algorithmic innovation; its value lies in recombining familiar engineering patterns into the Agent runtime, breaking free from the lifecycle constraints of a single conversation window.