Hermes 0.21 vs DeepSeek Harness Hands-On Comparison: Two AI Agent Evolution Paths Deeply Analyzed

The AI Agent tool ecosystem recently saw two noteworthy updates: Hermes Agent upgraded to major version 0.21.0 (codename "Pantheon"), and DeepSeek Harness released version 0.1.1-rc.2. Based on a hands-on demo by a Bilibili creator, this article provides an in-depth analysis of the core changes in both versions and offers a critical engineering perspective on DeepSeek's "everything is a plugin" philosophy.

Hermes 0.21.0: Multi-Agent Collaboration Becomes the Core Upgrade Direction

Hermes 0.21.0 is a major version upgrade, codenamed "Pantheon" — implying "the gods are gathering." The naming alone reveals that this version's core focus is multi-Agent collaboration. The Bot Model feature, previously available as a beta plugin, is now directly integrated into the Desktop client and enabled by default, allowing multiple Agents to collaborate and invoke each other.

Multi-Agent Collaboration is a cutting-edge direction in the AI Agent space. The core idea is to have multiple AI agents with different specializations work together to accomplish complex tasks. Compared to a single Agent, multi-Agent systems can achieve task decomposition, role specialization, and information sharing — for example, an Agent responsible for information retrieval passes results to one focused on analytical reasoning, which then hands conclusions to an Agent tasked with report writing. This architecture draws on distributed systems and microservices design principles, but faces unique challenges in AI: communication protocols between Agents, task scheduling strategies, context-sharing mechanisms, and conflict resolution all require careful design. Notable frameworks in this space include AutoGen, CrewAI, and LangGraph. Hermes' decision to build this capability directly into the product signals an attempt to differentiate from these developer frameworks on usability.

That said, the creator admitted that multi-Agent collaboration isn't used much in actual office scenarios — they've only experimented with it. For most users, Hermes' core features are already sufficient. If you don't have a strong need for multi-Agent workflows, skipping this upgrade is perfectly fine since the core changes aren't substantial.

Another highlight of this upgrade is persistent memory for scheduled tasks. Previously, scheduled tasks were stateless with no memory. The new version allows scheduled tasks to load and update persistent memory just like other Agents, enabling users to attach specific memory information to scheduled tasks and making automated workflows smarter.

Persistent Memory is a critical capability for AI Agents to evolve from "stateless tools" to "memory-equipped assistants." Traditional LLM conversations are stateless — the model retains no information after a conversation ends. Persistent memory stores key information in external databases (such as vector databases, key-value stores, or graph databases), enabling Agents to maintain continuity across multiple sessions. This typically includes short-term working memory (current task context), long-term semantic memory (user preferences and historical knowledge), and episodic memory (specific snippets from past interactions). For scheduled tasks, persistent memory means tasks no longer execute in isolation — for instance, a daily email summary Agent can now reference previous execution results and user feedback for adaptive adjustments, rather than starting from scratch each time.

Additionally, MCP servers and directories have been consolidated into a unified page in Desktop. MCP (Model Context Protocol) is an open standard proposed by Anthropic in late 2024, designed to establish a unified communication protocol between AI models and external tools and data sources. Before MCP, each AI application needed to write custom integration code for every external service, resulting in massive duplication and a fragmented tool ecosystem. MCP adopts a client-server architecture and defines standardized message formats and interaction flows — similar to how the USB standard unified peripheral interfaces. With MCP, AI Agents can invoke file systems, databases, API services, and other external capabilities through a unified protocol. Hermes' integration of MCP into the Desktop unified page means users can manage all tool connections from a single interface, dramatically reducing configuration and debugging complexity.

Frontend Interface Feature Trimming Sparks Debate

Interestingly, the Hermes Studio Web interface was upgraded to version 0.7.15, but the frontend changes have proven controversial. The creator observed that the new frontend removed quite a few previously available features — modules like memory management and knowledge graphs are no longer visible in the interface.

"I feel like this version's frontend has been trimmed too aggressively. I have no idea where those features went," the creator said bluntly, noting that from a personal user experience perspective, the previous frontend might actually have been more usable. This kind of feature "hiding" or removal requires time for long-time users who relied on these visual management tools to adapt. Knowledge graphs, as a structured knowledge representation method, are typically used in AI Agents to store relationship networks between entities (e.g., "Zhang San - works at - Company A"), helping Agents perform associative reasoning and knowledge retrieval. If this management interface has been removed, users lose the ability to intuitively view and edit their Agent's knowledge structure, and must rely on APIs or command-line operations instead.

Furthermore, the base System Prompt has continued to grow, increasing from 16K in the previous version to 18.4K — an additional 2K of content, with an even richer capability list. The System Prompt serves as an AI Agent's "base instruction set," defining the Agent's role, capability boundaries, behavioral norms, and tool invocation methods. Growing from 16K to 18.4K means each conversation consumes approximately 2,400 additional tokens of context window space. Given that mainstream models currently offer context windows of 128K to 200K, this seems insignificant. However, in practice, the tokens consumed by the System Prompt compete with user input, conversation history, tool call results, and more for limited context space. More importantly, an overly long System Prompt may cause the model's attention to key instructions to become diluted (a phenomenon academics call the "Lost in the Middle" problem), as well as increased inference latency and API call costs. This is why the "bloat" trend in System Prompts deserves ongoing attention.

Three Interaction Interfaces and Desktop's Notable Evolution

Hermes 0.21.0 bundles Hermes CLI 0.21 and Studio 7.15, offering multiple interaction modalities:

• CLI Interface: The classic command-line terminal. Though limited by text terminal constraints, it's made quite intuitive through color coding and other treatments, and can automatically detect the current working directory as a portable environment. CLI (Command Line Interface) is the lightest interaction method, ideal for automation scripts and remote server environments.
• TUI Interface: Essentially a web page running inside the command line — a more advanced integration approach with better dynamic effects than pure CLI. TUI (Text-based User Interface) uses the terminal's character rendering capabilities to simulate graphical interfaces, with common implementations using libraries like ncurses and Textual. It provides richer visual feedback than plain text while maintaining terminal compatibility.
• Desktop Client: The part with the most significant changes and improvements in this upgrade.

The creator considers the Desktop client (with built-in Bolt) "much better than before," with an increasingly professional interface. Its settings are extremely comprehensive, covering workspace memory, context persistent memory, voice gateway, tool keys, and more. New features include Odyssey layout options, HUD mini-window mode, watermarks, and sidebars. For users who are into multi-Agent scenarios and enjoy deep customization, the Desktop client offers a better workspace and will likely gradually replace Hermes Studio as the primary official interface. The built-in Bolt framework is a desktop application shell built on cross-platform technologies like Electron or Tauri, capable of combining the flexibility of web technology stacks with native application-level system capabilities (such as file system access and system notifications). This reflects a broader industry trend of AI tools migrating from pure web interfaces to desktop clients.

GitHub Mirror Site Access Issues and Upgrade Solutions

The creator specifically warned that several GitHub mirror/acceleration sites have recently become difficult to access, possibly due to network blocking. Practical advice was offered: if you're not in a hurry, just wait. If you are, you can directly overwrite-install the new version — core configuration is stored in two directories, so simply extract the new version and copy those two directories over.

For advanced users who have manually installed third-party plugins like CodeGraphy and don't want to do an overwrite installation, the simplest approach is to overwrite the entire Hermes Agent directory, then follow the Studio upgrade steps. Detailed upgrade documentation is available on the cloud drive.

DeepSeek Harness: The Promise and Engineering Concerns of "Everything Is a Plugin"

DeepSeek also released DS Portable version (0.1.1-rc.2), with relatively few recent updates. It adheres to an "everything is a plugin" design philosophy — the official team provides a minimal core (Shell), delegating various capabilities to plugins and relying on the community to develop plugins for different scenarios.

This design philosophy is known as "Microkernel Architecture" in software architecture, with roots in operating system design. Classic microkernel operating systems (like Minix and QNX) keep only the most basic process scheduling and memory management in the kernel, with all other functionality (file systems, network protocol stacks, etc.) running as user-space services. In application software, tools like VS Code, Eclipse, and Obsidian all employ similar plugin architectures, opening APIs for community-driven extensions. DeepSeek Harness takes this philosophy to a more extreme degree — even basic AI capabilities like image recognition aren't built in.

Once running, you can see that without installing plugins, the core lacks even basic capabilities like image recognition. The intent behind this minimal kernel design is clear: build an open platform and let the ecosystem fill in functionality.

Hot-Plugging: A Smooth Experience Without Restarts

One genuine highlight of DeepSeek Harness is its hot-plugging capability. Unlike VS Code, which requires a restart for many plugin installations, Harness can enable or disable plugins on the fly without restarting, resulting in a noticeably smoother experience. It supports Path plugins as well as plugins written in other languages.

Hot-Plugging in the software domain refers to dynamically loading, unloading, or replacing functional modules while an application is running without restarting the entire system. This technology has mature implementations in OS kernel modules (like Linux's insmod/rmmod), Java's OSGi framework, and browser extensions. Implementation typically relies on dynamic library loading, inter-process communication, or sandboxed runtime isolation. It's worth noting that VS Code has actually been gradually improving this — newer versions allow some extensions to activate without restart, though extensions involving language servers or underlying runtimes still require one. DeepSeek Harness achieves more thorough hot-plugging support in this regard, which is indeed a meaningful improvement for the development experience.

Deep Challenges of Long-Term Plugin Maintenance and Version Compatibility

However, the creator offered quite pointed criticism of this philosophy, arguing that it lacks real-world engineering experience at the practical application level. The core issue is: hot-plugging isn't actually hard to solve — the truly difficult challenge is long-term plugin maintenance and version compatibility.

This problem has abundant precedent in software engineering history. The WordPress plugin ecosystem is a classic case: every major WordPress core upgrade causes large numbers of third-party plugins to break, and plugin developers' maintenance willingness and capability vary widely. Eclipse IDE's plugin system similarly lost ground to more modern tools due to version fragmentation. In the Python ecosystem, "Dependency Hell" is a developer's nightmare — different libraries with conflicting version requirements for the same dependency. While Docker containerization and virtual environments (like conda and venv) partially alleviate runtime isolation issues, they introduce additional resource overhead and complexity.

Specifically, two major risks exist:

1. Framework upgrades breaking plugins: When the main framework version upgrades and the runtime environment changes accordingly, plugins must be updated in lockstep. If a plugin team stops maintaining their work, users are stuck in the awkward position of "the new framework can't run old plugins, and new plugins don't meet their needs." This is known as "Breaking Changes" in software engineering. Mature plugin platforms typically mitigate this through Semantic Versioning and API Deprecation Policies, but even these measures can't fully prevent it.

2. Incompatible multi-version runtime environments: Suppose Plugin A is built on Node 21 and Plugin B on Node 23; or Plugin A requires Python 3.1, Plugin B requires Python 3.12, and Plugin C requires Python 2 — DeepSeek doesn't provide a multi-environment integration solution. How are users supposed to simultaneously accommodate these conflicting runtime dependencies? Industry solutions typically involve containerized isolation (running each plugin in an independent Docker container) or WebAssembly sandboxing (compiling plugins into Wasm modules that execute in a unified runtime), but both approaches introduce significant performance overhead and architectural complexity.

"Software built on this kind of plugin architecture is actually very hard to maintain. When the main framework version upgrades, all plugins have to upgrade with it, or they simply stop working," the creator said, arguing that this will leave users in a very frustrating situation down the road.

Practical Implementation Paths

Despite these concerns, the creator also offered two relatively sound implementation recommendations:

• Personal or internal business scenarios: Using DeepSeek Harness as the core, customize a small number of business plugins and maintain them long-term for use in internal business systems. This is a viable path. In this model, the upgrade cadence between plugins and framework is entirely self-controlled, eliminating the risk of third-party dependency breakage.
• Enterprise multi-vendor collaboration scenarios: If used as a core framework with different vendors maintaining different plugins, version agreements and environment specifications must be locked down completely. All affiliated vendors must upgrade in sync, otherwise it creates "endless problems — essentially digging your own grave." This is essentially similar to enterprise middleware governance — in the Kubernetes ecosystem, for instance, core version releases typically provide a compatibility window, but ultimately all components must maintain version synchronization.

Comparing Two AI Agent Approaches and Selection Recommendations

These two updates reveal two distinct evolution philosophies for AI Agent tools: Hermes follows an integrated functionality path, consolidating multi-Agent collaboration, persistent memory, and MCP into a unified desktop client with an increasingly professional interface; DeepSeek Harness bets on a minimal kernel + plugin ecosystem, embracing an open philosophy but facing significant engineering challenges.

This clash of approaches is hardly new in the tech industry — it's essentially a continuation of the classic open-source philosophical debate between "The Cathedral and the Bazaar." The integrated approach ("Cathedral" model) excels in experience consistency and quality control, but is limited in flexibility with iteration pace dependent on the core team. The plugin approach ("Bazaar" model) excels in ecosystem extensibility and community innovation potential, but faces risks of quality inconsistency and compatibility fragmentation. Historical experience suggests that the eventual winners tend to be products that strike a balance between both — with sufficiently powerful built-in capabilities to ensure an out-of-the-box experience, plus open extension mechanisms to satisfy advanced needs.

For general users, whether to upgrade to Hermes 0.21.0 depends on individual needs — if you don't have a strong need for multi-Agent workflows, waiting until GitHub mirror access is restored is perfectly fine. DeepSeek Harness is currently better suited for developer users who enjoy tinkering and can maintain plugins themselves. Whether its community can be activated and version compatibility issues properly resolved will determine its long-term trajectory. Both installation packages have been updated on Baidu Cloud Drive for interested users to download and try.