DeepSeek's "self-evolution" blueprint has been unveiled.

DeepSeek's latest paper in collaboration with Peking University unveils the Harness version of the Black Whale.

Its full title is A Programming Paradigm for Spatiotemporal Composability, whose previously mentioned Chinese translation refers to a programming paradigm designed to handle spatiotemporal composability.

It sounds a bit convoluted, you only need to remember one single sentence —

The entire paper centers on Cordis, the core of the Black Whale, a "Lego base board" that can be plugged and unplugged freely.

At its core, everything is a plugin, everything can be recombined.

This also explains why the "Black Whale" has such an extremely high openness, and the official team strongly encourages all users to build plugins and make custom modifications to Harness.

This paper is full of valuable information, and it is also the masterwork that the DeepSeek Harness team has spent a long time polishing, which finally delivered an outstanding achievement in the form of the full-featured Black Whale.

It is worth noting that this is the seventh paper published by DeepSeek this year, and also the Nth collaboration with Peking University.

The paper totals more than 80 pages. I went through the full content from start to finish, and sorted out several key takeaways —

1. Cordis provides a set of general dynamic composition semantics. Components managed by Context can be dynamically loaded and unloaded, and their managed side effects will be automatically recycled.

2. Its mathematical foundation comes from two classic concepts in type theory: effect and coeffect.

3. It is not just a lab prototype. This design has been running on the Koishi chatbot framework for four years, with more than 4000 community plugins verified in production environments.

All of these designs serve the same ambitious goal —

Self-evolution.

Time and Space: Two Core Barriers for Harness Self-Evolution

There is a counterintuitive reality in the software world: for most systems that support plugin systems, you need to restart the entire host process after uninstalling a single plugin.

This means that you may only remove one plugin, but all other already loaded plugins will also be forced to restart along with it.

Yes, the so-called "plug-in" in most cases cannot actually be unplugged once it is installed.

VSCode is a typical example of this issue.

The paper points out that as of June 9, 2026, among the top 100 most popular extensions on VSCode Marketplace, 87 of them contain executable code that cannot be individually uninstalled at runtime once activated. The entire extension host must be restarted after the extension is disabled or deleted.

This is not a problem unique to VSCode. The paper notes that almost all plugin architectures have this type of defect, with only differences in severity.

This problem is already troublesome enough in common plugin systems, but it is still acceptable if the only cost is a system restart.

However, in the context of Agent systems, this becomes an entirely different problem.

A typical Agent runtime is usually packed with a large number of components: tool sets, execution environments, permission controls, sandboxes, session states, memory systems... It is already an extremely complex engineering system by itself.

Now it is further combined with the "self-evolution AI" which is highly dynamic, and the system may accidentally modify itself to malfunction without proper design.

This is exactly the perspective DeepSeek's paper takes to address self-evolution:

In the future, Agents may generate a tool by themselves according to the task, install the tool into the runtime, and replace it by themselves once they find there is a flaw.

If every time you modify a line of code you have to restart the entire process, all the previously accumulated context and cache may be corrupted.

This concept is called temporal composability.

If the dependencies between modules are patched by each module itself, checking for dependency A today and guessing the status of dependency B tomorrow... circular dependencies will easily be introduced, and errors will occur when you try to reload the modules.

This concept is called spatial composability.

These two difficulties are exactly the two problems that Cordis aims to solve.

DeepSeek's Solution

First we need to introduce two mathematical concepts, which are the two core theoretical pillars of this paper —

Effect and Coeffect.

Simply put, effects describe "the influence of the program on the world"; coeffects describe "the constraints of the world on the program". The two are dual concepts: effect systems enrich the type system, while coeffect systems enrich the context system.

But there is a problem: in the context of self-evolution AI, the framework is dynamically loaded.

Classic effect/coeffect concepts are originally tools for static type systems.

In order to overcome both the temporal and spatial barriers, the team adapted and upgraded these two concepts specifically for Agent runtime, introducing "revertible effects" and "reactive coeffects".

Revertible effects target the temporal dimension.

The core definition can be summarized in one sentence: every modification to the context must be paired with an explicit inverse function, so that the side effect can be reverted.

When loading a plugin, every state modification will record the corresponding inverse function, which is stacked in order to form a "revert chain".

When uninstalling a plugin, this chain is executed in reverse order, so that the system state can be precisely restored to the state before the plugin was loaded.

It can be understood as a stack of plates: the last plate you put on the top is the first one you take away.

In this way, the temporal order will not be messed up.

Reactive coeffects are responsible for the spatial dimension.

In Cordis, components can declare which dependencies they need, so that dependencies can be properly resolved.

For example, a chat plugin can declare that it needs a message adapter and a database. It will only enter the ACTIVE state when both dependencies are satisfied. If one dependency is missing, it will stay in the INACTIVE state, and will not start prematurely or throw null reference errors after running.

When a dependency provider appears, the dependent will be automatically activated. When the provider is removed, the dependent will stop first, wait for it to revert all its own effects, then the provider can finish the uninstall process.

When the dependency provider is uninstalled, the dependent is automatically deactivated; when the dependency comes back online, the dependent automatically recovers. This topological orchestration does not need to be manually written by developers, it is automatically derived from the dependency declarations.

The combination of these two mechanisms forms the core of Cordis.

The intuitive meaning of "spatiotemporal composability" in the paper title is exactly reflected in this mechanism.

Koishi

So, have all the designs mentioned above been verified in real practice?

Yes.

And the scale of practice is quite large.

The paper uses a chatbot framework called Koishi for experimental verification.

Koishi is built based on Cordis, and has accumulated more than 4000 community plugins over four years, covering instant messaging adapters, database drivers, management consoles and various user-facing features.

According to GitHub, Koishi is a cross-platform, extensible, high-performance chatbot framework.

Its name and icon design come from the character Komeiji Koishi in the Touhou Project series.

Komeiji Koishi is a character who makes unconscious actions. The name not only symbolizes the theme of the chatbot, but also embodies the passion the developer put into the project.

This is indeed a very interesting README content.

So what exactly is Cordis?

The author of Koishi states that the name Cordis comes from the Latin word for "heart", and everything in Koishi starts from Cordis.

As a meta-framework, Cordis is not coupled to any specific domain or scenario.

The capability it provides — a plugin system — is nothing surprising for most frameworks, but behind this system is a goal that most frameworks have not achieved: reversibility.

The author also left this sentence:

I hope it can become the core of future software, at least of all the software I develop.

Four years later, DeepSeek's new paper has provided formal verification for this design.

First is the verification of the temporal dimension.

In Koishi, administrators can disable a plugin from the console, the influence of the plugin on the system will be reverted in place, and other plugins will continue to work.

During development, after a plugin is modified and saved, the modified plugin will be reapplied, while caches and connections remain unchanged.

Next is the verification of the spatial dimension.

In the Koishi ecosystem, IM adapters provide message platform access, database drivers provide persistent storage, and feature plugins declare these as dependencies and access them directly.

During actual operation, when switching the storage backend or reconnecting the adapter, only plugins whose dependencies have actually changed will be reactivated, while plugins with unchanged dependencies remain completely unaffected.

It is worth noting that these plugins are usually independently developed by different authors, and the only coordination mechanism between them is the reactive coeffect mechanism emphasized by Cordis.

This proves that a set of dynamic composition rules can indeed work properly in an open plugin ecosystem with contributions from different developers.

However, the paper does not package this case as a perfect demo.

The team acknowledges that currently there is only verification data from the single Koishi ecosystem and the single TypeScript language, lacking controlled comparisons with alternative architectures...

But the most important value of the paper is that it points out a new direction: a set of Agent Harness infrastructure designed for self-evolution.

The DeepSeek Harness released now is exactly the upgraded version of Koishi Cordis.

Introduction to the Paper Authors

Finally, let's introduce the authors of the paper as usual.

There are three authors in total, from both Peking University and DeepSeek.

The first author is Yifan Shi, from Peking University, and he is also a member of DeepSeek.

After further research, we found that his name already appeared in the DeepSeek V3 Technical Report.

The verification project Koishi in this new paper is also developed by him.

It is obvious that he has a strong preference for the "shi" syllable: his real name is Yifan Shi, the project name is Koishi, and his GitHub username is Shigma.

(doge)

Back to the topic.

Koishi is a repository created four years ago, and now it has 5.7K stars. It can be said that this is the origin of everything.

Because the concept of Cordis was first proposed within Koishi.

In 2023, Shigma wrote a design article for the official Koishi documentation titled Reversible Plugin System, which is almost the predecessor of this new paper.

Wei Zhang, also from Peking University, is an associate professor at the Software Institute of the School of Computer Science, Peking University.

According to the college's official website, Wei Zhang's research areas mainly cover software engineering and programming languages.