跪拜 Guibai
← Back to the summary

DeepSeek's Cordis Protocol Turns Agent Development into a Lego Set

Not Just Another Agent Framework

On August 13, 2026, DeepSeek did something it had never done before—it open-sourced not a model, but the infrastructure surrounding models. Harness, an agent orchestration layer that turns DeepThink-powered models into production-grade autonomous workers, was released under the MIT license.

Alongside it came a paper and a meta-framework called Cordis. Together, the three convey a clear message: DeepSeek believes the future of Agents lies not just in smarter models, but in better ways to apply them.

The significance of this depends on how you look at it. If you see DSH as "yet another Agent framework"—one more option alongside LangChain, CrewAI, and AutoGPT—then its meaning is simply "one more choice." But if you see what Cordis does, you'll realize it's not competing in the same arena as these frameworks at all.

It's redefining the arena.

The Two Old Paths for Current AI Products

Before DSH, if you wanted to build an AI product, you basically had only two paths:

Path A: Build the Scaffolding from Scratch

Choose your own model, design the agent loop, write the tool registry, handle session state, implement error recovery, manage the context window... you have to tackle every link in the chain yourself. The upside is complete freedom; the downside is reinventing the wheel—every team has to solve engineering problems like plugin loading, dependency management, and lifecycle, which are unrelated to business logic.

It's like building your own hammer, saw, and nails before you can build a house. By the time you've gathered all your tools, your competitor's product has already been live for three months.

Path B: Be a "Second-Class Citizen" Inside an All-in-One Framework

Use LangChain, CrewAI, or AutoGPT—quick to start, lots of integrations. But your code is always an "extension" of the framework, never a peer component. The framework's core—agent loop, state management, tool scheduling—is privileged code; you can only extend it, not replace it.

Want to change core behavior? Fork the source code, modify it, and maintain your own diff. Every time the framework upgrades, you have to rebase your patches. It's like renting a fully furnished apartment; want to knock down a wall? You can't—you're a tenant, not the owner.

image.png

The two old paths for current AI products—free but repetitive, fast but restricted.

Even more awkwardly, these two paths don't interoperate. The tool integrations you write in LangChain can't be directly used by CrewAI. Every framework is building its own walled ecosystem; your code is the framework's asset, not yours.

The Third Path: Protocol-First, Replaceable Implementations

Cordis offers a third path.

It doesn't give you a framework; it gives you a set of protocols: how services register, how dependencies are declared, how side effects are disposed, how events communicate, how components are loaded and unloaded. All participants—including the framework's own core—adhere to the same set of protocols, with no privileges.

This is the key difference. LangChain's agent loop is the framework's core code; want to change the scheduling logic? Fork it. Cordis's agent loop is an ordinary plugin; want to change the scheduling logic? Write a new plugin, register a service with the same name, and the old one is automatically replaced. No need to fork anyone.

image.png

Cordis's Lego model—the baseplate is the protocol, the bricks are plugins, any piece is replaceable.

Let's use an analogy. Traditional frameworks are like a complete car—the engine, gearbox, and chassis are all welded together; if you want to change the engine, you have to dismantle half the car. Cordis is like a box of Lego—the baseplate and interfaces are standardized; what you build on top is entirely up to you. You can pull out the "engine" and swap in another one without affecting the other parts.

Where's the core difference?

LangChain gives you a framework—you work within the boundaries of that framework. Cordis gives you a set of protocols—you use these protocols to define your own framework. The former is "renovate my house"; the latter is "here's a plot of land, build your own."

Future Scenarios: Same Baseplate, Different Products

If Cordis truly works out, what will the future look like? Not everyone using the same DSH, but different people using the same set of protocols to assemble completely different things.

Scenario 1: Customer Service Agent

A SaaS company needs a customer service Agent. They use DSH as the base, attach their own ticketing system plugin (connecting to the Zendesk API), a knowledge base plugin (RAG over company documents), and a multilingual translation plugin (connecting to the DeepSeek API). The customer service Agent automatically receives tickets, looks up documents, replies to users, and escalates complex issues to a human.

Six months later, they want to add a "sentiment detection" capability—write a new plugin that listens for the agent/pre-step event, analyzes the sentiment of the user's message, and raises the priority if anger is detected. Just plug it in; no need to change any existing code.

Scenario 2: Code Review Agent

An open-source team needs a code review Agent. Again, use DSH as the base, but attach completely different plugins: a Git plugin (to pull PR diffs), a CI plugin (to run tests and see results), a static analysis plugin (SonarQube integration). The Agent receives a PR → pulls the diff → runs analysis → generates a review report → comments on GitHub.

The team uses a self-developed model? No problem, swap the model adapter plugin. Using Claude? Swap the plugin. Want to change the agent loop itself from ReAct to Plan-and-Execute? Swap another plugin. Each time, only one brick is changed; the rest stays put.

Scenario 3: Security Operations Agent

A security team needs an operations Agent. Attach a log analysis plugin, an alerting plugin, and an automatic response plugin (isolate host, ban IP). The Agent monitors 24/7, automatically responds to detected anomalies, and notifies on-call staff for serious incidents.

The key point is—this security operations Agent shares the same set of plugin protocols as the customer service Agent mentioned earlier. They register services, declare dependencies, and dispose of side effects in the same way. Yet the resulting forms are completely different: one is a customer service system, the other is a security platform.

Scenario 4: Not Even an Agent

Someone might take only Cordis's kernel and build a hot-swappable backend service that has nothing to do with Agents—like a microservice gateway that dynamically loads and unloads routing modules at runtime. Cordis's reversible effects, dependency injection, and lifecycle management are equally applicable to such scenarios.

This shows that Cordis's protocol layer is not bound to the Agent domain. It solves the general problem of "how to safely compose, decompose, and replace components." Agent is just its most dazzling application scenario right now.

image.png

Four teams using the same set of Cordis protocols, assembling four completely different products.

Plugin Marketplace: From "Reinventing the Wheel" to "Assembling Bricks"

If the protocol is unified, the next step is naturally a plugin marketplace.

This isn't wishful thinking. Cordis's first large-scale validation case, Koishi—a chatbot framework based on Cordis—accumulated over 4,000 community plugins over four years. IM adapters, database drivers, admin consoles, various user features—all are community-contributed plugins. Different authors developed them independently, and the only coordination between them was Cordis's protocol.

Imagine what DSH's plugin marketplace would look like:

This shifts from "every team reinvents their own wheel" to "everyone shares the same box of bricks." You don't need to write a Salesforce integration from scratch—find one in the marketplace, install it, and use it. Can't find one? Write one yourself, and publish it along the way for others to use.

image.png

Plugin Marketplace—from "reinventing the wheel" to "assembling bricks."

More importantly, the composability of plugins. A's customer service plugin + B's translation plugin + C's knowledge base plugin = a complete customer service product. This isn't theoretical—Koishi has already proven that 4,000+ plugins can operate collaboratively under the same set of protocols.

Contrast this with the current situation: the tools you write in LangChain can't be used by CrewAI; AutoGPT's plugins can't be installed in LangChain. Every framework is building a walled garden. Cordis's protocol is open, MIT-licensed—if it becomes a de facto standard, the walls come down.

Self-Evolving Agent: Not Sci-Fi, an Engineering Problem

The DSH paper mentions a concept called "self-evolving agent harness"—an Agent that can continuously serve requests while having its own components generated and replaced by AI.

Sounds like sci-fi? But the engineering problem behind it has already been solved by Cordis.

Traditional systems can't achieve "self-evolution" because swapping components means restarting the process, losing state, and interrupting service. Cordis's reversible effects turn component replacement into a safe operation:

  1. Unload the old component → the framework automatically rolls back all its registered side effects (event listeners, services, sub-plugins) in LIFO order.
  2. Load the new component → the framework automatically resolves dependencies and registers new side effects.
  3. The entire process is transparent to other components—they only see that "the service has changed," without needing to know who is making the swap.

What does this mean? A customer service Agent can automatically adjust its own capability set based on operational experience:

Each adjustment is a "self-evolution"—pull out one brick, insert a new one, the system doesn't interrupt, and state isn't lost. This isn't magic; it's the engineering result of Cordis's reversible effects + reactive dependency management + hot module replacement trifecta.

image.png

The evolution flow of a self-evolving Agent—detect → unload → load → run, all without interruption.

Of course, the paper honestly acknowledges its limitations: currently, there is only validation data from the single Koishi ecosystem and the single TypeScript language, lacking controlled comparisons with alternative architectures. Its use as a runtime framework for self-evolving Agents "remains a direction for next-step validation, not a landed product capability."

But the direction has been pointed out. From "what an Agent can do" to "what an Agent can become"—this is a qualitative change.

Final Words

Back to the original question: What is the real significance of DSH being open-sourced?

It's not just one more Agent framework. It's that DeepSeek has turned "how to build an Agent runtime" itself into an open proposition, and then handed the pen to the community.

In the past, if you wanted to build an AI product, you either built the scaffolding from scratch—free but reinventing the wheel; or you used an all-in-one framework—fast but a "second-class citizen." Cordis offers a third path: you get a box of standardized bricks—services, events, side effects, lifecycles are all ready-made protocols—and you only need to decide what to build.

Some build a castle—a customer service Agent, attaching a ticketing system and a knowledge base. Some build a spaceship—a code review Agent, attaching Git and CI. Some build a walking robot dog—a security operations Agent, attaching log analysis and automatic response. And some just take the baseplate and build something completely unrelated to Agents.

They share the same set of plugin protocols, yet can grow into completely different forms.

It's like Lego—the baseplate and interfaces are unified, but what you build on top is entirely up to you.

That's what DSH and Cordis provide: this baseplate.

I'm full of anticipation for this.

References: