DeepSeek Harness and the Codis Architecture Explained: Agent Development Enters the Plugin Era

20,000 Stars in One Hour — What Makes Harness So Special?

The Harness project released by DeepSeek on August 13th can only be described as "terrifyingly popular." Within just over an hour of launch, it surpassed 20,000 Stars, setting a new velocity record on GitHub. By day five, the Star count had already surged past 140,000. Officially, DeepSeek positioned it as merely a "Developer Preview," but the community clearly couldn't hold back — many were already treating it like a public beta.

GitHub Star count is one of the core metrics the open-source community uses to gauge project popularity. Previous velocity record holders included DeepSeek-R1 (which broke 100,000 Stars in its first week) and Meta's Llama model series. For a project to gain 20,000 Stars in one hour means more than 5 developers were clicking the Star button every second — a rate of spread typically only seen when major AI labs release milestone projects. The Developer Preview stage means APIs and interface specifications haven't been frozen yet, and breaking changes could happen at any time. But the community's early flood of adoption also signals that developer demand for Agent infrastructure has reached a fever pitch.

The project is fully open source, but what truly deserves a deep dive isn't that jaw-dropping Star count — it's the Codis architecture under the hood. This architecture may be fundamentally reshaping how Agent development works at its core.

The Origins of Codis: Design DNA That Grew Out of a Chatbot Framework

Codis originally served as the foundation for CodeC, a domestic chatbot framework. To understand why it looks the way it does today, you need to go back a few years to the era of QQ group bots and Discord bots.

Back then, group bot requirements were incredibly fragmented: group management, song requests, gacha pulls, mini-game API integrations… Add a daily check-in feature today, hook up a weather query tomorrow, then decide the day after that some feature is too noisy and needs to be turned off. It was precisely this highly dynamic, constantly shifting environment that forced out a core capability — every feature is a building block that can be pulled out at any time, and when it's removed, the side effects it left behind can be cleanly undone.

Codis's service injection and dependency rollback mechanisms grew out of this very soil. Service Injection is a runtime dynamic extension of the Dependency Injection pattern. Traditional dependency injection completes binding at compile time or startup, while service injection allows services to be dynamically registered, replaced, and deregistered while the system is running. Dependency Rollback takes this a step further: when a plugin is unloaded, the services it registered, the events it listened to, and the state it modified all need to be cleanly undone, leaving no residual side effects. Technically, this is similar to database transaction rollback, but applied to plugin lifecycle management. The key to achieving this capability lies in precisely tracking and recording each plugin's side effects — which services it registered, which events it subscribed to, which shared states it modified — so that all operations can be reversed upon unloading.

This design was originally conceived to handle the fragmented needs of chatbots, but the fundamental problem it solves happens to overlap heavily with today's Agent development challenges.

Everything Is a Plugin: The Core Philosophy of Harness

Harness takes this philosophy to its logical extreme, advocating that "everything is a plugin": the kernel is only responsible for three things — loading, unloading, and managing dependencies. Models, tools, sandboxes, storage, scheduling, and UI are all plugins. This design philosophy is entirely in line with Codis's heritage.

The "Tuition" Agent Developers Have Been Paying Over and Over

Over the past two years, teams building Agents have been reinventing the wheel almost universally. How to store conversations, how to manage context, how to register tools, how to schedule subtasks, how to recover from crashes, how to replay state — every team has had to write all of this from scratch. The result is usually: everyone's solutions look roughly the same, and none of them work particularly well.

To be specific, Agent development frameworks have experienced explosive growth over the past two years. LangChain, AutoGen, CrewAI, MetaGPT, and other frameworks each defined their own way of abstracting Agents, but their solutions to underlying engineering problems overlap heavily. Session state management typically relies on Redis or SQLite, context window management requires implementing truncation and summarization strategies from scratch, tool registration requires manually writing JSON Schema, and subtask scheduling is often a hardcoded directed acyclic graph (DAG). Even thornier is crash recovery: if an Agent that has been running for hours fails midway, most frameworks can only restart from the beginning because intermediate state was never persisted. This repetitive labor consumes enormous engineering resources without producing any differentiated competitive advantage.

Everyone seemed to accept that these were the unavoidable "tuition fees" of the Agent era. But the Codis approach offers a more fundamental insight: most of these problems are actually the same problem — namely, how to build a long-running software system that dynamically combines capabilities and gracefully handles side effects.

From this perspective, whether it's a chatbot or a coding Agent is actually beside the point. The underlying engineering challenges are the same, which is precisely why an architecture born from chatbots can be used to power coding Agents.

Event Sourcing Design: Append-Only Session Logs

Harness also makes a critical design choice: session logs are append-only, never overwritten. System prompts, chains of thought, tool calls, and sub-Agent dispatches that the model sees are all written into a single event stream. Recovery, branching, retrieval, and replay all use this same stream.

Event Sourcing is an architectural pattern originating from Domain-Driven Design (DDD), first systematically articulated by Martin Fowler and others. Its core idea is: instead of storing an entity's current state, store the entire sequence of events that caused state changes. The current state can be reconstructed by replaying the event sequence. This pattern is already widely used in financial trading systems and audit systems. In the Agent scenario, event sourcing is particularly valuable: every tool call, every round of chain-of-thought reasoning, and every subtask dispatch is an event. When an Agent fails or needs debugging, developers can precisely trace back to any point in time and see the complete context at that moment. More importantly, event streams naturally support "branching" operations — creating a new execution branch from a historical node to try different strategies without affecting the original execution path. This shares a striking resemblance to Git's branching model.

This event sourcing design makes Agent state management clean and traceable — you can return to any node and branch off at any moment, or replay the entire execution process. This is one of the toughest nuts to crack in complex Agent systems.

Configuration-Layer Swappability: A New Paradigm for Vertical Domain Agent Development

The most imaginative aspect of Harness is this: developers can swap capabilities at the configuration layer without modifying source code.

For example, simply by swapping the file system provider, the bash terminal and language services automatically migrate to a remote sandbox. The sub-Agent provider uses the same interface — behind it could be a newly created sub-agent, or the entire task could be handed off to another product entirely.

The essence of this configuration-layer swappability is the extreme application of the Inversion of Control (IoC) principle in the Agent domain. In traditional software engineering, the Spring framework used IoC containers to enable declarative assembly of components in Java applications, dramatically reducing the complexity of enterprise application development. Harness brings a similar concept to Agent development: file systems, terminals, language services, and other capabilities are all abstracted as "Provider" interfaces. Developers only need to declare which provider implementation to use in a configuration file, and the framework automatically handles dependency assembly and wiring. For example, when switching the file system provider from local to a remote sandbox, all components that depend on the file system — the bash terminal needs to execute commands remotely, the language service needs to analyze code remotely — automatically follow the migration. Developers don't need to modify any business logic code.

What does this mean? Teams building medical, legal, or specialized industrial software Agents no longer need to build the skeleton from scratch. What they need to do is replace a few domain-specific plugins on a tree that's already up and running. This dramatically lowers the barrier to entry for vertical domain Agent development.

Key Differences Between Harness and Claude Code / Codex

Of course, the project is still in its Developer Preview stage, which means compatibility is still evolving, some third-party tools are hard to get running on the first try, and token consumption isn't exactly low.

Compared to Anthropic's Claude Code and OpenAI's Codex, the biggest difference with Harness is: it's fully open source, and its plugins are swappable. This isn't a closed product you can only use as-is — it's an engineering foundation that can be disassembled, recombined, and extended.

Specifically, Anthropic's Claude Code adopts an end-to-end optimization strategy where model capabilities and tool invocation are deeply coupled. Users get a highly polished programming assistant experience, but cannot replace the underlying model or customize the toolchain. OpenAI's Codex leans more toward API-as-a-service, executing code tasks through cloud sandboxes, but its execution environment and scheduling logic are a black box to users. What both have in common is: you can use them, but you can't disassemble and recombine them. Harness's open-source plugin-based approach means developers can replace DeepSeek's model with other open-source models (such as Qwen or Llama), switch the sandbox from Docker to WebAssembly, or switch storage from a local file system to cloud object storage — this flexibility is especially critical for enterprise scenarios requiring private deployment or data compliance.

The Real Revolution: From Laying Foundations to Snapping Together Building Blocks

Looking at the big picture, the real revolution Harness may trigger isn't about becoming the "strongest Agent" — it's about transforming Agent development from "laying the foundation over and over again" into "an engineering ecosystem where components can be assembled and swapped."

If this path proves viable, then future competition among vertical domain Agents won't be about who writes the most elegant underlying skeleton, but about whose domain plugins are better and more specialized. The skeleton becomes shared public infrastructure, and value migrates toward domain knowledge and the plugin ecosystem.

Looking at historical patterns in the software industry, when the infrastructure layer becomes standardized, value tends to migrate to the ecosystem layer. WordPress's plugin ecosystem, VS Code's extension marketplace, and Kubernetes's Helm Chart repositories all followed this evolutionary path. If Harness's plugin architecture becomes the de facto standard, we could see the emergence of an Agent plugin marketplace: medical teams publishing HIPAA-compliant medical record analysis plugins, legal teams publishing case law retrieval and contract review plugins, industrial teams publishing PLC control and sensor data parsing plugins. The competitive focus would shift from "who can build a working Agent" to "whose domain plugins are more accurate and reliable." The profound impact of this paradigm shift is that it could enable a vast number of vertical domain experts — even those without deep AI engineering skills — to participate in building the Agent ecosystem.

This is perhaps the deeper significance worth paying attention to — Harness is attempting to push Agent development from fragmented, repetitive solo efforts into a new engineering phase that is standardized, modular, and collaborative.