Deep Dive into DeepSeek Harness: Old Patterns, New Ecosystem

DeepSeek Harness uses proven software patterns but differentiates through server-side Agent positioning.
DeepSeek Harness, while built on familiar software engineering patterns like dependency injection and lifecycle management, distinguishes itself through strategic positioning as a server-side Agent framework rather than a personal TUI tool. Its TypeScript-based plugin system enables deployment on application servers for unattended automation, setting it apart from Claude Code and Pi/Codewell which target human interaction.
Recently, DeepSeek AI open-sourced an Agent framework called DeepSeek Harness (preview version), which quickly amassed nearly 100,000 GitHub Stars and attracted widespread attention in China's tech community. Even investment media outlets like Wallstreet CN reported on it immediately.
This article is based on the in-depth breakdown from B-station creator "Xiao Ma Ge's" (小马哥) Tech Weekly Episode 87, analyzing DeepSeek Harness's design essence, its similarities and differences with competitors, and where its true differentiation lies—all from a software engineering perspective.

Harness at Its Core: Yet Another Agent Toolkit
First, let's clarify a concept. "Harness" originally refers to a saddle or reins—a mechanism for "reining in a wild horse"—used here to control AI's uncontrollable behavior. But as Xiao Ma Ge emphasizes, no software can truly constrain a large model's hallucinations. A more accurate positioning for Harness would be an "Agent engine" or "standardized toolkit."
When you place DeepSeek Harness in the broader landscape of current Agent products, you'll find that it is fundamentally no different from Codex, Claude Code, Pi (now renamed Codewell), and similar products. They all revolve around the large model's Function Call / Tool Call mechanism, extending capabilities through various means.
Function Call is a core capability introduced by OpenAI in June 2023, which was widely adopted by the industry and evolved into Tool Call. The principle works as follows: developers pre-declare a set of callable function signatures to the model (including function names, parameter descriptions, and return types). During inference, the model determines when to call external tools and generates structured JSON call requests, which the host program executes and feeds results back to the model for continued reasoning. This mechanism is the foundation of all current Agent frameworks—it evolved large models from "only generating text" to "being able to operate on the external world." MCP (Model Context Protocol) is an open protocol proposed by Anthropic that attempts to standardize Tool Call discovery and invocation; A2A (Agent-to-Agent) is Google's inter-Agent communication protocol. Regardless of protocol names, the underlying logic remains: model decision → structured call → execution feedback → model continues reasoning.
Whether it's Codex's skills, MCP, A2A, or Harness's plugins, they are all fundamentally extension mechanisms. Xiao Ma Ge's assessment is straightforward: the differences between these tools mainly lie in "how extension mechanisms are organized," not in underlying principles.
Core Component Architecture
By having Harness introduce itself (its documentation is excellent source material), we can outline the framework's core capabilities:
- Dependency Injection (DI): Similar to Spring's Inversion of Control
- Dependency Lookup: Similar to Java JNDI's context.lookup mechanism
- Tool injection and registration
- Event dispatching: Event Sourcing observer model
- Lifecycle management
These are almost entirely classic patterns from software engineering. Dependency Injection and Inversion of Control are design patterns formally named by Martin Fowler in 2004, with the core idea of transferring object creation control from objects themselves to external containers. In the context of Agent frameworks, this means tools, plugins, and event handlers can all be uniformly managed and orchestrated by a container like Spring Beans, achieving loose coupling and flexible assembly between components.
Design Through Code: Echoes of Spring and Pi Everywhere

Borrowing Spring's Dependency Injection Philosophy
DeepSeek Harness's plugin registration mechanism is essentially a Function Call. Through inject functionality, tool components are injected into the context. This mirrors Spring's Dependency Injection (DI) and Inversion of Control (IoC) philosophy.
Since Rod Johnson created Spring Framework in 2003, it has become the de facto standard for Java enterprise development, with its IoC container at the framework's core. DI brings three key benefits: loose coupling (components don't directly depend on concrete implementations), testability (easy to substitute mock objects), and configurability (changing behavior through configuration rather than code). Harness transplants this philosophy to the Agent domain, meaning each functional module of an Agent can be flexibly replaced and combined.
Interestingly, Spring's DI is mostly completed at runtime, while Harness leans toward compile-time organizational orchestration. It even adopts XML-configuration-like approaches to declare component IDs and metadata—highly similar to Spring's standalone context XML configuration. It's worth noting that Spring author Rod Johnson has recently been committing extensive TypeScript code on GitHub, which might corroborate the shared design philosophy.
Additionally, Harness's "dependency lookup" mechanism resembles Java's JNDI (Java Naming and Directory Interface), allowing applications to look up objects and resources by name. The typical usage is context.lookup("jdbc/myDataSource")—applications don't need to know the specific implementation details of resources; they can obtain them through standardized names. In Agent frameworks, this pattern allows plugins to dynamically discover and obtain other registered tools or services at runtime, accommodating both declarative orchestration and runtime dynamic binding paradigms.
High Similarity with Pi/Codewell
Xiao Ma Ge points out that DeepSeek Harness draws considerable inspiration from Pi (Codewell)—both are built on TypeScript at their core. Writing a Pi extension and writing a Harness plugin share virtually the same logic in terms of location conventions, import patterns, event mechanisms, and lifecycle:
- Plugins have a unified signature (context + apply)
- Events use
onexpressions (similar to JS's onClick) - Loading through conventional directories (extension directory), similar to Java's ServiceLoader
Java's ServiceLoader is a JDK built-in Service Provider Interface (SPI) mechanism that declares implementation classes through configuration files named with the interface's fully qualified name placed under META-INF/services/, automatically scanning and loading at runtime. JDBC driver auto-discovery is a classic SPI application. This "convention over configuration" philosophy has had far-reaching influence. Harness loading plugins through a conventional extension directory is essentially the same approach implemented in TypeScript.
The differences are only in minor configuration and loading details—none escape the overarching Function Call / Tool Call framework.
Lifecycle and State Machine (Fiber)
Harness's Fiber is the plugin's entity state machine, managing states like Pending, Loading, Active, Failed, Dispose, and Unload. This design was already mature in Java's OSGi (bundle mechanism)—with install, start, active, resolve states mapping one-to-one.
OSGi (Open Services Gateway initiative) is a dynamic modular system specification for the Java platform, first proposed in 1999, with Eclipse IDE's plugin system being its most famous implementation. OSGi bundles have a strict lifecycle state machine: INSTALLED → RESOLVED → STARTING → ACTIVE → STOPPING → UNINSTALLED. Each bundle declares its exported and imported packages, with the container managing classloading isolation and version conflict resolution. This mechanism solved Java's long-standing "JAR Hell" problem. While OSGi's design is arguably even more rigorous than Harness in terms of specification, its adoption has remained lukewarm due to complexity—which perhaps explains why Harness opted for a lighter implementation.
Effect is used for callback destruction and resource cleanup, handling post-tool-use cleanup actions.
Harness's True Differentiation: Server-Side Agents

This is the article's most critical insight. DeepSeek Harness doesn't include a TUI (Terminal UI), drawing complaints from users that it's "not as user-friendly as Claude Code." But Xiao Ma Ge argues this precisely reveals its strategic positioning.
TUI Is for Humans; Harness Is for Machines
Claude Code, Pi, and similar TUI programs are fundamentally human-computer interaction tools. You wouldn't deploy them on a Linux production server—because there's no one on a server to type commands or answer interactive questions like "who are you."
TUI (Terminal User Interface) is an interaction paradigm between pure command-line and graphical interfaces, using libraries like ncurses to draw windows, buttons, and other UI elements in the terminal. TUI buffer limitations stem from the historical design of terminal emulators: early hardware terminals like VT100 had limited display memory, and while modern terminals have expanded, scrollback buffers typically still have upper limits. More critically, TUI is a synchronous blocking model designed for human interaction—it assumes someone is sitting in front of a screen waiting for output and typing input. Server-side programs need asynchronous, unattended, highly concurrent communication patterns (like HTTP APIs, gRPC, message queues). TUI is inherently unsuitable for efficient machine-to-machine collaboration.
DeepSeek Harness, however, has the capability to be deployed on application servers. Its plugins are primarily written in TypeScript and can be deployed like Tomcat to run an Agent application, enabling machine-to-machine interaction (via communication protocols or in-process/inter-process calls).
Apache Tomcat's core design provides a runtime container where developers deploy packaged applications, with the container managing lifecycle, thread pools, connection handling, and other infrastructure. Harness's server-side positioning is highly analogous: it acts as the runtime container for Agent applications. Plugins written by developers are equivalent to deployed application units, while Harness manages Agent lifecycle, tool call orchestration, event dispatching, and context management. This "container + application" layered architecture is the gold standard for enterprise software, suggesting Harness's ambition extends beyond development tools to becoming the application server of the Agent era.
The Imagination Space for Server-Side Scenarios
For example: you could deploy Harness on your rented server, combine it with its built-in job/cron timer tools, and implement unattended automation tasks like "automatically summarize emails and generate a weekly report every Friday at 8 PM." This has escaped the realm of 'personal assistant' and moved toward server-side applications.
Xiao Ma Ge predicts that after seeing DeepSeek claim the "server version" position, foreign vendors will likely follow with similar products. Meanwhile, domestic products like Doubao (ByteDance) also show trends toward enterprise editions and connector (plugin) directions.
TypeScript Ecosystem: Advantages and Limitations
Harness's choice of TypeScript as its plugin language brings two major benefits:
- Massive developer base: TS/JS developers are numerous, especially given its #1 position in frontend development
- Seamless UI component integration: Like the community's Apollo (Walker) plugin, which makes observability highly intuitive—text input renders directly to UI without needing to embed a browser like competitors
Observability is a core concept in the cloud-native domain, consisting of three pillars: Logs, Metrics, and Traces. In the Agent domain, observability faces new challenges: the large model's reasoning process is a "black box," tool call chains may be non-deterministic, and Token consumption and latency require fine-grained monitoring. The Apollo plugin bringing observability to the UI rendering layer means developers can visually see every decision the Agent makes, the input/output of every tool call, and the entire reasoning chain. This transparency is critical for debugging, optimizing, and production monitoring of Agent applications.
However, Xiao Ma Ge also candidly notes its limitations: the barrier to writing extensions is relatively high, requiring programming knowledge. Compared to standardized solutions like skills where "any scripting language can write them," Harness plugins demand higher development capabilities.
He also makes a bold prediction: Java will regain importance in enterprise integration scenarios. Currently, Agent development is dominated by TypeScript and Python, but for enterprise-grade legacy system integration, Java's engineering capabilities (application context management, DI, Event Sourcing, configuration, metaprogramming) remain powerful. A language's core value beyond performance lies in maintainability—which is why financial trading systems still have components written in Perl, while no one actually writes business logic in assembly.
Advice for Developers: Don't Panic, See the Essence
Facing the dilemma of choosing between Pi, Claude Code, and Harness, Xiao Ma Ge offers a clear-headed judgment: the tool itself isn't what matters most; model quality is the core.
Once a tool is packaged locally, its functionality is fixed—its prompt optimization and context compression strategies are tied to the version. The three things truly worth focusing on are:
- Stay humble: Creative applications (skills) from all industries shouldn't be underestimated
- Learn to organize prompts in English: English is more precise, consumes fewer Tokens, and offers more accurate professional expressions
- Understand the technical essence: Whether LangChain, Spring AI, or Harness, they're all fundamentally "context construction helpers for large model requests"—guiding models toward desired outputs through tool mounting, MCP, structured output, loop engineering, Human-in-the-loop, and other means
The second point deserves elaboration: understanding the Tokenization mechanism of large models is key. Taking the BPE (Byte Pair Encoding) tokenizer used by GPT series as an example, English words are typically encoded as 1-2 Tokens (e.g., "function" = 1 Token), while Chinese characters usually consume 2-3 Tokens due to UTF-8 encoding characteristics. This means expressing the same semantics in Chinese prompts may consume 1.5-2x more Tokens, directly impacting API costs and effective utilization of context windows. Additionally, English typically comprises over 60% of mainstream large models' pre-training corpora, and virtually all core computer science terminology originates from English. Using English prompts avoids semantic loss from translation.
Conclusion
DeepSeek Harness is not a "world-saving" innovation in its technical implementation—its plugin mechanism, DI, event system, and lifecycle management are all mature strategies refined over years of software engineering. But its two real advantages cannot be ignored:
First, its strategic positioning toward server-side Agents, breaking out of the red ocean of personal assistants. Second, DeepSeek's brand's massive popularity and the capital strength behind it, enabling rapid assembly of China's enormous engineer community for open-source co-development.
As Xiao Ma Ge says: when your software vision is broad enough, seeing the essence of problems becomes effortless, and all those dazzling Agent frameworks remain well within your grasp.
Related articles

Spring AI Alibaba Graph in Practice: Building a Full-Process HR Recruitment Agent
Build an enterprise-grade HR recruitment Agent with Spring AI Alibaba Graph, covering Workflow orchestration, human-in-the-loop, and state rollback.

OpenCode + TIA Portal MCP in Practice: AI Automatically Parses PLC Project Architecture
Learn how to use OpenCode with Siemens TIA Portal MCP server so AI can automatically analyze PLC project architecture, hardware config, and cross-references.

Can AI Be Conscious? A Deep Dive from Scientific Theories to Philosophical Puzzles
Can AI be conscious? This article examines the question through major scientific frameworks like IIT and GWT, exploring the possibilities, verification challenges, and ethical implications.