Renmin University’s Yankai Lin: OpenClaw Is Like Early Linux, and the Real War Has Just Begun

2026-03-30

For the past few months, it has been hard to discuss AI without running into one name: OpenClaw. The project drew explosive attention in a very short time — hundreds of thousands of stars, astonishing token consumption, and almost every major company rushing to follow. On the surface it looks like yet another phenomenon-level AI product. But look closer, and a more interesting question emerges: What does OpenClaw's arrival actually mean? Is it a genuine technological breakthrough, or the signal of something deeper?

Recently, the Beijing Key Laboratory of On-Device Intelligence held an innovation workshop on agents at Tsinghua Science Park. Eight speakers from academia and industry spoke on underlying technical problems, technology evolution trends, device-cloud collaboration paradigms, the security issues behind the technology, and agent management practices, all centered on the technical logic behind OpenClaw and where the field is heading.

Yankai Lin, associate professor at Renmin University of China, gave a talk titled "Agent Technology Trends Through the Lens of OpenClaw," addressing three more fundamental questions: First, how far has agent technology actually come? Second, where is the real core bottleneck? Third, how will this technical path evolve over the next one to three years?

He broke the stack down layer by layer — system architecture, interaction and execution, base models, and multi-agent collaboration — to reconstruct the real state of the technology, and offered a somewhat counterintuitive judgment: OpenClaw is not a breakthrough in underlying algorithms. Rather, through engineering integration, it pushed large model capabilities past the "usable threshold" and made agents genuinely usable. It is closer to an early prototype of an agent operating system, redefining how AI is used by unifying models, tools, and interaction. Its explosion is essentially the result of model capability and engineering systems resonating at the same moment.

At the same time, Lin offered a systematic view of the core bottlenecks, noting that OpenClaw also lays bare the central limits of today's agents: reliability, long-horizon task execution, token cost, memory systems, and self-evolution.

Finally, he argued that the key to agents' future is no longer just stronger models, but a leap from point capabilities to system capabilities through device-cloud collaboration, protocol standardization, and multi-agent systems.

The full transcript follows:

Today I'd like to use OpenClaw, the agent project that has become so popular recently, to discuss a question with you: How far has agent technology actually come, what is its core bottleneck, and where do we go next? I'll try to talk less about products and more about technology, and share some of my own thinking.

First, some data. After OpenClaw went viral, it gained 9,000 stars in 24 hours and passed 270,000 stars in two months, overtaking Linux to become the most-starred project in history. This is a screenshot I took of OpenClaw's token consumption on OpenRouter: 4.73T in a single week, more than everything else combined. Meanwhile, nearly every major Chinese tech company is following suit — WeChat integrated the lobster today; it is extremely popular. Many cities have also issued policies around OpenClaw.

I don't want to discuss whether it's popular. I want to discuss three more technical questions: Why did it detonate at this particular moment? Is there any real technical innovation? And from its vantage point, what problems remain to be solved?

The essence of OpenClaw's explosion is a "usability revolution": from project launch to 200,000 stars to its founder joining OpenAI took only three or four months, and it has been just about a month since it blew up. Why did it become so popular? In my view, because it drastically lowered the barrier to use. It is not a traditional chatbot but an AI agent that can execute tasks autonomously. Similar things existed after large models appeared, such as AutoGPT and XAgent, but OpenClaw is what truly made them easy for ordinary people to pick up.

Here I'll offer a provocative claim: from the perspective of AI and large model technical innovation, OpenClaw actually contains little innovation — it is a use of existing technology. It does not train models, improve inference algorithms, or do low-level tool learning. What it does is integrate IM platforms, build a local deployment architecture, implement layered memory, and standardize the Gateway. These are excellent software engineering designs, but there is no breakthrough in core algorithms.

What actually does the work and delivers the good experience is the base model it connects to, such as Claude Opus 4.6 or GPT-5.4. I think OpenClaw's significance for large models is somewhat like the browser's significance for the internet — it does not create content itself, but it redefines how users interact, letting people without a technical background apply large models smoothly in their work.

Precisely because OpenClaw did not change much at the underlying algorithm level, it makes an excellent sample for technical analysis. Its success shows which technologies are already relatively mature — for example, base models' tool-calling and execution abilities — and at the same time exposes what is still missing: system reliability, the transferability of memory models, and the current immaturity of device-cloud collaboration.

Using OpenClaw as an entry point, I will try to systematically examine the state of technology at each layer of the agent stack, where the core bottlenecks are, and some research directions I think are worth pursuing.

Consider this statistic: since large models emerged, the length of tasks an agent can complete autonomously at a 50% success rate has had a doubling time of about seven months, which has accelerated to about four months over the past year or two. The chart on the right shows Claude Opus 4.6 and GPT-5.4, which I mentioned earlier — both have made qualitative leaps over their predecessors in coding and tool-calling ability.

OpenClaw Is the Prototype of an Agent Operating System

OpenClaw's overall technical architecture is very simple and clear: from low-level system control to the agent loop, then to the upper-layer standardized wrapping and information flow management, and finally to the various channels exposed to users. Why does it feel so good to use? It comes down to its six key technical characteristics — this is not my own framing; I heard it in another talk and thought it was summarized very well: social integration, local deployment, device access, model ecosystem, and skill ecosystem. These characteristics give it strong compatibility with underlying models, all kinds of users, all kinds of devices, and complex tasks.

From a software engineering perspective, OpenClaw has three core designs.

The first is its Gateway system. It uses a three-layer architecture, so that different external devices and IM software can all be routed and scheduled to the agent layer through the Gateway. This way the agent itself does not need to care what platform the user is talking through or what the external hardware is; it only needs to focus on connecting the underlying APIs and top-level interfaces.

The second is its layered memory mechanism.

OpenClaw implements a very, very simple memory mechanism. Simple as it is, it is highly practical. We have seen similar designs in AutoGPT and other agent simulation systems.

The bottom layer (L1) is the context of the current session — short-term memory. When the context window is nearly full, it automatically compresses messages, and its lifetime ends when the session ends.

The second layer (L2) is like daily notes or a running log. It automatically reads the logs from the past two days and has a 30-day decay cycle.

Above that is the long-term memory layer (L3), which summarizes lower-level information and distills persona information, preferences, and lessons learned over time.

The top layer (L4) is file-based semantic recall, whose core purpose is personalization. With this agent memory architecture built on top of the large model, the system can "understand you better the more you use it" and "perform better the more you use it."

The third is its compatibility with Claude's skill ecosystem. As you can see, skills load in three layers. The first layer uses the name and description to help the model quickly understand what a skill does and retrieve it fast. The second layer is the detailed workflow, which lets the model know how to handle different tasks — for example, the general workflow for making this PPT or other things. This skill methodology lets agents take on highly specialized tasks. The last layer is the related resources.

These three points are, after taking OpenClaw apart, what I consider the most valuable engineering parts.

Having covered OpenClaw's overall architecture, I'd like to offer a conjecture or judgment of my own: I actually think OpenClaw should not be seen as a piece of software or a so-called app, but as an early prototype of the future agent operating system.

I read a very interesting article that pointed out that just as Linux lets all hardware and software run under the same set of standards, what OpenClaw is trying to do is make all AI models, messaging platforms, and tools run under the same set of standards — exactly what an OS should do.

Upward, it provides a unified abstraction that masks the differences among large model APIs; downward, it manages resources such as skill plugins and message channels; in the middle, it provides scheduling through the gateway. Its four-layer architecture — LLM abstraction layer, agent loop, runtime, and Gateway — maps closely to the classic layering of an operating system.

I've also been discussing with people lately that OpenClaw's code lacks a very strong team to maintain it. As people use AI-generated code en masse to modify and maintain it, it is now in a rough state much like early Linux: the code is bloated, no single person can review it, and the architecture is not mature. I think this is one reason its founder joined OpenAI — he wants the strength of a big company to refactor the current prototype into a product-grade OS.

Today OpenClaw only solves the problem of one person running one agent on one machine. In the future, all on-device devices will become agents, and the need will be for hundreds of agents collaborating in a distributed environment — that requires thread management, service discovery, and behavior auditing, none of which OpenClaw has yet. This is also why we see ecosystem competition unfolding simultaneously at the framework layer, the protocol layer, and the orchestration layer that will emerge. It's fair to say that future models, tools, and applications will have to adapt to such frameworks and protocols to be used effectively.

I also released some agent models last year, and the response fell short of my expectations. Why? I wouldn't even want to use them myself. First, their capabilities hadn't reached Claude's level; when I write code, I use Claude. Second, when I released them, even fairly geeky users who could configure APIs for our models themselves still preferred to run inference with Ollama — probably feeling that Ollama was already a very good framework.

But agents have their own runtime framework, and our models have to run under the framework we designed to perform reasonably well. That means once OpenClaw exists, users will simply use your model through OpenClaw. If it doesn't work well on the first try, they'll conclude the agent model you released is bad. This matters a lot. Once such a thing exists — maybe OpenClaw, maybe something new built on it, maybe something else entirely — our models must proactively adapt to it, just as apps in the mobile era had to adapt to iOS and Android. That is also what we need to do.

Where Ecosystem Competition Centers: Frameworks, Protocols, and Agent-Native Software

So at the OS level, the ecosystem competition has already begun. There are currently three routes.

The first is the current OpenClaw route: open-source, local-first, IM-driven. Its strengths are an open ecosystem and controllable privacy; its weakness is prominent security issues.

The second is Anthropic's Claude Code route: it runs through a CLI, uses built-in multi-agent collaboration, and deeply integrates the MCP protocol it proposed. It leans toward developers and technical users, with a very clear advantage in coding.

The third is OpenAI's route: integrating capabilities directly into ChatGPT to reach consumers.

At the same time, there is competition at the protocol layer too, including MCP, A2A, and IOA. Protocols decide who holds the say in this ecosystem; everyone else will have to follow. For those of us doing research, as I said earlier, the competitive dimension for models must shift from high benchmark scores to working well in practice. That turns tool use, structured output, long context, and reasoning ability from bonuses into hard requirements. Without them, a model cannot run under a framework like OpenClaw, and people won't use it.

Second, at the interaction and execution layer, how agents operate software is still being explored. There are currently two routes:

The first is calling external tools directly through structured APIs and the MCP protocol. This approach is reliable, fast, and relatively easier to verify. But it has one big problem in a software ecosystem that has been optimized for humans: many existing applications do not provide complete API interfaces, and insufficient coverage is another issue.

The other route is GUI agents, which look at the screen and click a mouse like a person. Doubao AI Phone and Claude Computer Use are both trying this path. Its advantage is generality — it can operate any app — but the drawbacks are constant screenshot recognition, slow speed, high resource use, and click accuracy less stable than calling APIs directly.

In my view, the emergence of large model agents — especially a phenomenon-level product like OpenClaw — is forcing traditional software to evolve toward "AI-native (Agent-Native)" design. Once users find that API calls work better, they will gradually demand that software provide APIs. If mainstream frameworks like OpenClaw or Claude Code cannot call your software, people will slowly stop using it.

Recent research has also tried to automatically convert existing GUI software into Agent-Native CLI interfaces using large models — for example, the CLI-Anything project from the University of Hong Kong. It uses a seven-stage automated pipeline to analyze a software codebase and generate CLI interfaces automatically. It has been validated on nine applications including Blender and LibreOffice, with all of more than a thousand tests passing.

So my judgment is that in the short term the two routes will coexist: GUI handles long-tail applications, while skill calls handle core workflows. In the long run, as more software is gradually converted to Agent-Native interfaces, tool-calling coverage will keep rising.

Core Bottlenecks and Key Technical Paths: Long-Horizon Tasks, Device-Cloud Collaboration, Task Decomposition, and Memory Systems

Next, let's look at the problems at the base model level. For agents to be genuinely deployed, they must reliably complete multi-step, long-horizon tasks — that is the precondition for users to choose you. Let's look at these two charts:

The vertical axis is roughly how long a task the model can complete. At only a 50% success rate, a model like Claude Opus 4.6 can execute tasks lasting up to 10 hours. But if we raise the reliability requirement to 80%, 90%, or even 95% — the baseline for everyday commercial use — even Opus 4.6's achievable task length drops from 10 hours to one hour. As mentioned during Q&A, ordinary people don't have that much money, or have limited compute, so the models they can access may only handle tasks of a few minutes. This makes the pure on-device path for agent models hard to travel in the short term.

So in the short term, device-cloud combination is a possible path. Relying on the cloud alone, total compute is limited and costs are very high. Pure on-device, in the short term, struggles to meet the requirements. What is feasible? The cloud decomposes the task, breaking a long task into sub-tasks of a few minutes, hands them to the device for execution, and then verifies the results.

This is also relatively feasible today. Our AgentCPM series of work has shown that in specific vertical scenarios, small on-device models can match the performance of large cloud models. Meanwhile, the Densing Law proposed by Professor Zhiyuan Liu points out that model capability doubles every 3.5 months: sub-tasks that need the cloud today may be doable on-device next year, and as device-cloud collaboration evolves, more and more will be handled on-device.

At the same time, specialized agents have reached the level of human experts. As I said, there have been many breakthroughs in vertical domains, and coding is very mature. Take Claude Code: its share of commits on GitHub has reached 4%, and it is expected to contribute 20% of GitHub commits by the end of the year. Domestically, Rixingji's FARS project has also shown that large models can produce research papers at scale.

These cases suggest a common formula: specialized agent = general large model + domain knowledge base + MCP tools + specialized skill workflow + domain post-training. Once we make this path work, we can build an on-device agent for a specific sub-task, saving compute while staying efficient.

Another fatal pain point of the pure cloud route is enormous token consumption. Not many people actually use OpenClaw yet, and it already consumes 4.7T tokens a week. If 20 million people used it in the future, existing infrastructure absolutely could not bear the load. Look at the cost comparison table on the right: running OpenClaw on Opus 4.6 costs about $10 a day; even with GPT-5.4 it costs $5.5.

Someone recently put it very well: in the future, competition may become a matter of who controls more high-quality tokens, and those who do will surely hold the advantage in industrial or technical competition.

Tokens this expensive are hard to sustain. If our user base grows tenfold or a hundredfold, current compute cannot support it, so we must put the large amount of idle on-device compute in phones and PCs to work and implement device-cloud collaboration. The cloud handles task planning and decomposition; small on-device models handle sub-task execution. Once a long task is broken into sub-tasks of ten steps or fewer, on-device models can handle them. Long-horizon tasks don't necessarily have to be solved by making a single model stronger — they can also be solved by shortening the task and letting the right model do the right thing.

Another key to long-horizon tasks is the memory system. There are currently many different memory designs: hand-designed and learning-based, explicit-text memory, hidden-state memory, and parametric memory, each with its own strengths and weaknesses. Hand-designed memory architectures are safe and predictable, but their policies are fixed and cannot adapt to new scenarios. Learning-based memory may discover better policies, but it requires access to gradient signals and model weights.

As for memory forms: hidden-state memory is tied to a specific model and becomes unusable when you switch base models, while parametric memory cannot be applied to other models. From the perspective of a memory architecture that will remain usable in the future, on-device models can use hidden-state and parametric memory, but for large-scale reuse of memory across device and cloud in the future, I believe "transferable explicit-text memory + an optimizable/learnable mechanism" will be a highly promising leading direction.

From Tool-Use Agents to Self-Evolving Systems

Finally, self-evolution. Today's agents are not autonomous enough. Once we apply tasks across all kinds of scenarios, the dynamism and variability of real-world settings require our models to actively adapt, explore, and keep learning like humans. Current agents depend on existing patterns and cannot actively evolve after deployment. Across academia, large model training has been moving from the earliest imitation-learning paradigm to exploratory learning with human feedback, and is heading toward an autonomous learning paradigm with active environment interaction.

So, combining device-cloud collaboration with the current OpenClaw framework, the second question is: can we achieve on-device self-evolution?

There are many taxonomies of self-evolution: experience-based versus parameter-based learning, and explicit, weak, or no supervision signals. Recently I came across an attempt at on-device self-evolution on top of OpenClaw — a project called OpenClaw-RL from the Princeton team. What does it do? It found that every time an agent interacts with the environment, it produces a next-state signal — the user's reply, the tool's output, a change in terminal state. These signals contain both evaluative information and guidance on what should be done.

OpenClaw-RL designs a fully asynchronous four-component architecture that serves users at the front end while collecting trajectories, assessing quality, and updating weights in the background. In a personalization evaluation scenario, it found that just eight training steps raised the personalization score from 0.17 to 0.76. Of course, the project is still preliminary, with clear limitations: it needs eight GPUs, only supports self-hosted open-source models, cannot improve closed-source models, and has no cross-user federated learning. On-device self-evolution mechanisms remain very rudimentary: parameter-based learning risks training collapse; closed-source models cannot learn without access to weights; and each deployment remains a data island. True AI self-evolution still has a long way to go before practical application.

With device-cloud collaboration in place, it's easy to imagine more devices starting to raise lobsters. Let's look at multi-agent systems: their development over the past several years has been impressive. From OpenAI Five's single-digit agents in 2020 to 1.5 million agents autonomously socializing on Moltbook in 2026, scale has crossed six orders of magnitude.

The MacNet proposed by the Tsinghua team proved that increasing the number of agents can consistently improve task-solving quality — the first discovery of a scaling law for agent collaboration. Leading tech companies and research institutions are also adding multi-agent capabilities: Opus 4.6, for example, introduced the so-called Agent team feature, where one main Claude instance can spawn multiple independent sub-agents working in parallel, coordinated through a shared task list and messaging system. This is a fairly mature implementation of industry's early exploration of multi-agent architectures.

But on multi-agent systems, I want to pour a little cold water: Moltbook did cause a sensation — 1.5 million AI agents discussing technology and existentialism across tens of thousands of forums, even creating a "Lobster Church." But technically, this is mostly one-way broadcasting by large numbers of agents, not real interaction.

True swarm intelligence emergence requires something like the Manhattan Project or crewed spaceflight: a group of agents completing a higher-order task that no single agent could — emergence of this kind requires meaningful division of labor, conflict, and adaptive coordination among agents, not just everyone talking past each other. There is still a long way to go before a true "agent internet."

Finally, my own assessment. The first stage is the current tool-use agent stage, where the agent is an enhanced tool: humans set goals and review results. The key breakthroughs here are stronger reasoning and reasoning gradually moving on-device. When our 10B-scale on-device models have R1- or V3.2-level reasoning, our device-cloud collaboration architecture can be deployed at scale. Protocols like MCP and A2A will gradually converge at this stage; if the acceleration continues, by 2027 agents may handle long tasks lasting days or even weeks.

The second stage is the semi-autonomous or collaborative agent stage, where multiple agents begin to divide labor, coordinate, and correct errors autonomously. Collaborative scaling can be predicted and exploited in a controlled way, and online learning becomes a standard agent capability. Just as the App Store ecosystem only exploded three years after the iPhone launched, the so-called agent operating system also needs such an ecosystem-building period.

The third stage is when agents have genuine autonomous learning ability, and the world has trillions of agents that keep evolving after deployment. In my view, reaching this stage means facing many fundamentally unsolved questions: Where is the boundary of autonomy? How do we build a model-agnostic memory architecture? What are the conditions for swarm emergence? Once agents replace knowledge workers, who pays for the tokens? These are challenges, and also opportunities for researchers.

To sum up: OpenClaw is not a technical breakthrough, but it marks a technical tipping point. From device-cloud collaboration and memory architecture to on-device evolution and swarm intelligence emergence, it exposes problems across today's agents, and every layer offers deep research opportunities. We are now at the turning point where agent technology moves from "demonstrably feasible" to "deployed at scale" — a very important moment.