【AI Agent】DeepSeek Harness（dsh）源码与架构深度分析

宁教主

732人浏览 · 2026-08-30 00:13:45

宁教主 · 2026-08-30 00:13:45 发布

DeepSeek Harness（dsh）源码与架构深度分析

Repository: https://github.com/deepseek-ai/deepseek-harness
Analysis date: 2026-08-30
Scope: public GitHub master, README, AGENTS.md, docs/architecture.md, docs/capability-seams.md, SAFETY.md, development.md, Agent Notes, public Discussions, and DeepSeek official Harness page.

00. Executive Summary

一句话结论

DeepSeek Harness 不是“一个带插件的 Coding Agent”，而是在尝试把 Agent Harness 本身做成一个可组合的 Microkernel / Plugin Runtime。

官方 architecture.md 明确说明：Cordis 是 dsh 的基础框架；插件贡献 services、typed events 和 reversible effects；model adapter、tool registry、session log、agent loop 本身也都是 plugin，因此可以通过配置替换。

官方甚至明确写出：不存在需要 patch 的 privileged core，而是通过 mounting plugin 扩展系统。

核心模型：

Everything is a Plugin
        ↓
Cordis Runtime
        ↓
Service + Event + Effect
        ↓
Capability Seam
        ↓
Profile / Bundle / Patch
        ↓
Agent Runtime

这与 Codex 的关键区别是：

Codex
= Agent Runtime with strong internal boundaries

DeepSeek Harness
= Plugin Runtime in which Agent Runtime itself is composable

因此：Codex 更像“把 Agent Runtime 做深”，DeepSeek Harness 更像“把 Agent Runtime 做成可重组基础设施”。

当前状态

GitHub 当前页面显示约 14,226 commits、203k Stars、23.4k Forks；项目为 MIT License，但官方明确仍处于 Developer Preview，并明确警告会发生 compatibility-breaking changes。官方 SAFETY.md 更直接指出：项目尚未经过安全审计，不能视为 secure / production-ready。

所以必须区分：

Architecture maturity ≠ Product security maturity.

综合评分

Dimension	Score	Judgment
Architecture innovation	9.8/10	Microkernel + plugin + event + capability seam
Agent runtime	9.5/10	Agent loop itself is composable
Extensibility	10/10	Everything-is-plugin is genuinely deep
Engineering discipline	9.5/10	Strong contracts, tests, invariants
Session architecture	9.5/10	Event sourcing + projection
Interoperability	9.3/10	ACP / hooks / subagents / providers
Security design	8.0/10	Many boundaries, but experimental
Security maturity	5.0/10	Explicitly not audited
API stability	4.5/10	Developer preview / breaking changes
Learning value	10/10	Excellent research target
Production readiness	5.5/10	Not yet according to its own safety statement

01. Project Positioning

1.1 Official positioning

DeepSeek Harness (dsh) is an open-source agent harness developed by DeepSeek AI. Its core slogan is:

Everything is a Plugin.

The official Harness page also uses the conceptual model:

Agent = Model + Harness

where the Harness supplies the environment, tools and persistence needed for an agent to work in the real world.

1.2 What it really is

A more precise engineering definition is:

Plugin-oriented Agent Runtime / Agent Harness Microkernel / Composable Agent Platform

It is not merely a Coding Agent, Agent Framework, MCP host, workflow engine, or IDE. Those are capabilities composed inside the runtime.

1.3 Why “Harness” matters

Traditional agent:

LLM → Prompt → Tools

Harness:

LLM
 + Context
 + Tools
 + Memory
 + Session
 + Sandbox
 + Policy
 + Loop
 + Persistence
 + UI
 + Observability

The architectural bet is that the model is only one component of an agent; the Harness defines the environment in which model decisions become durable real-world actions.

02. Repository Structure

Current monorepo structure includes:

deepseek-harness/
├── .agents/
├── .claude/
├── .github/
├── apps/
├── docs/
├── native/
├── packages/
├── patches/
├── python/
├── scripts/
├── snapshots/
├── vendor/
├── website/
├── AGENTS.md
├── BENCHMARK.md
├── CLAUDE.md
├── README.md
├── SAFETY.md
├── package.json
└── pnpm-lock.yaml

packages/ is organized by capability rather than by traditional layered application modules:

core/          session, system-prompt, tools, agent, agent-loop
api/           remote BFF / RPC gateway
typert/        type graph / runtime registry
llm/           LLM capability
shell/         bash capability
subprocess/    process capability
terminal/      persistent PTY
fs/            filesystem capability
lsp/           language server
skill/         skills
web/           web capability
compaction/    compaction
context/       request context
subagent/      subagents
bundle/        profile patch layers
workflow/      workflow engine
plan/          plan mode
preset/        per-session composition
guard/         loop hygiene / timeout
self-modification/
hooks/         Claude Code / Codex bridges
session/       persistence / projection / telemetry
settings/
credentials/
acp/
interaction/
sdk/
experimental/

This taxonomy already looks closer to an Agent OS than a conventional CLI application.

03. Architecture

3.1 Microkernel model

Cordis provides:

Context
Plugin
Service
Event
Effect
Scope

A plugin can:

load
 ↓
register services
 ↓
register listeners
 ↓
create effects
 ↓
runtime
 ↓
unload
 ↓
unwind effects

Thus a plugin is a runtime participant, not merely an optional npm package.

3.2 Capability Seam

The canonical seam is:

Service Definition
        +
Service Provider
        +
Consumer

Examples include:

ctx.llm
ctx.tools
ctx.sessions
ctx.sessionPersistence
ctx.sessionQuery
ctx.sessionProjections
ctx.sandbox
ctx.sandboxPolicy
ctx.approval
ctx.fs
ctx.shell
ctx.terminals
ctx.compaction
ctx.skills
ctx.agents
ctx.subagents
ctx.storage
ctx.credentials
ctx.settings
ctx.sessionTelemetry

This is effectively an Agent Capability ABI.

04. Agent Architecture

Agent is modeled separately from the loop:

Agent
 ├── identity
 ├── model
 ├── system prompt
 ├── tools
 ├── skills
 ├── session
 ├── agent-loop
 ├── subagents
 └── context

The key design is:

Agent
  ↓
ctx.agentLoop
  ↓
Plugin implementation
  ↓
Typed events

Therefore a different loop can be mounted without rewriting the Agent object.

This enables concepts such as standard loop, replay loop, Ralph-style loop, experimental loop, or custom domain loops.

05. Event Architecture

One of the strongest parts of dsh is the event-driven loop.

Important extension points include:

agent/pre-step
agent/request
agent/request-error

tools/pre-execute
tools/execute
tools/post-execute

llm/stream

system-prompt/assemble

agent/turn-stopping

session/flush

Three dispatch semantics are explicitly documented:

Waterfall

A → B → C → next()

Listeners can transform, wrap, short-circuit or recover. A waterfall listener that does not call next() short-circuits the chain.

Serial

Used for ordered checkpoints such as agent/turn-stopping.

Parallel

Used where all listeners should get an independent opportunity, such as durability-oriented session/flush.

The consequence is important:

The Agent Loop is becoming an Event Kernel rather than a hard-coded while-loop.

06. Tool Architecture

ctx.tools is a capability seam for a guarded execution pipeline.

Consumers include:

tool-bash
tool-fs
tool-web
tool-skill
tool-subagent
tool-terminal
tool-todo
tool-cordis

Conceptually:

LLM
 ↓
Tool Registry
 ↓
Guard
 ↓
Approval / Policy
 ↓
Sandbox
 ↓
Execution
 ↓
Event
 ↓
Session Log

Timeout policy is also a separate plugin. This is a strong indication that execution policy is being modeled as a first-class capability rather than scattered conditionals.

07. Sandbox & Security

The security surface is decomposed into:

ctx.sandbox
ctx.sandboxPolicy
ctx.approval
ctx.permissionPresets
ctx.fs
ctx.shell
ctx.subprocess
ctx.codeRuntime

There are local sandbox and E2B-related providers, so the architecture permits different execution backends.

However, the official safety document is explicit:

DeepSeek Harness is experimental developer-preview software;
it has not undergone a security audit;
it can execute model-generated code and commands;
it can load third-party plugins;
it can access network, processes, credentials and files made available to it;
sandboxing, approval and permissions reduce risk but do not guarantee isolation;
it should not be the sole security control for untrusted workloads.

Therefore:

Security Architecture = Advanced
Security Maturity = Experimental

Do not confuse the two.

08. Permission Architecture

Permission is distributed across:

Approval
Permission Presets
Sandbox Policy
Authorization
Credentials

ctx.approval is consumed by ACP, bash tooling and the tool pipeline, making approval a runtime capability rather than a UI button.

This is a much stronger design than:

ask_user = true

09. Context Architecture

Context is not merely a prompt string.

Important seams/components include:

ctx.systemPrompt
ctx.context
ctx.skills
ctx.session
ctx.compaction
ctx.tokenMeter
ctx.toolResultPruner

System Prompt

ctx.systemPrompt is a registry. Plugins can contribute prompt sections through the assembly lifecycle.

Skills

ctx.skills
    ↓
skill-filesystem / skill-badge
    ↓
tool-skill

This turns skills into a runtime capability rather than a directory of markdown files.

Compaction

Compaction is itself a seam:

ctx.compaction

with provider(s) such as compaction-basic, plus token metering and tool-result pruning.

This is an important architecture decision: context management is treated as replaceable runtime infrastructure.

10. Session Architecture

Session is one of the strongest subsystems.

ctx.sessions
ctx.sessionPersistence
ctx.sessionQuery
ctx.sessionProjections
ctx.sessionProjectionCache
ctx.sessionTelemetry

The session is effectively a durable event stream rather than a simple messages[] array.

Persistence

Providers include:

session-persistence-jsonl
session-persistence-sqlite

Both persist the same SessionEvent vocabulary. This is excellent separation of canonical protocol from backend.

Projection

The architecture uses:

Event Log
   ↓
Projection
   ↓
Projection Cache
   ↓
API / UI

This resembles Event Sourcing + CQRS.

Session format

Current AGENTS.md explicitly states that the session format has no compatibility promise during the pre-release phase. It also requires current builds to recognize session event types when reading them.

This creates a very important conclusion:

Session Event Schema is effectively a core protocol of the entire plugin ecosystem.

11. Data Architecture

There are two distinct persistence concepts:

Session persistence

Conversation / execution events

Generic storage

Plugin domain state

The architecture keeps them separate:

Session Persistence
 ├── JSONL
 └── SQLite

Generic Storage
 ├── JSON
 └── SQLite

This is superior to making one database the universal source of truth.

12. LLM Architecture

The LLM is a capability seam:

ctx.llm

Providers currently include concepts such as:

llm-deepseek
llm-pi-ai
llm-replay

Consumers include the agent loop and compaction.

The key design is:

Agent Loop
    ↓
LLM Service
    ↓
Provider

rather than hard-coding a provider into the loop.

llm-replay is especially valuable for deterministic Agent testing and regression replay.

13. Subagent Architecture

Subagents are a capability seam:

ctx.subagents

Providers include concepts such as:

subagent-spawn-in-process
subagent-fork-in-process
subagent-dsh-sdk
subagent-acp
subagent-codex
subagent-claude-code

This is an unusually strong interoperability decision.

The architecture can be viewed as:

Supervisor
   │
 ┌─┼────────────┐
 ▼ ▼            ▼
A  B            C
│  │            │
Codex Claude  DeepSeek

A subagent is not just another prompt. It is a provider of an Agent runtime.

14. ACP / MCP / Hooks

The runtime includes bridges for:

ACP
Claude Code hooks
Codex hooks
MCP-related integration

This means external agents can be integrated into the dsh runtime rather than forced to become native packages.

That creates a broader architecture:

Agent Runtime
    │
 ┌──┼─────┐
 ▼  ▼     ▼
ACP Hooks MCP

15. Code Runtime / PTC

A particularly interesting direction is programmatic tool composition / Code Mode.

Traditional tool loop:

LLM → tool → result → LLM → tool → result → LLM

Programmatic composition:

LLM
 ↓
generate program
 ↓
Code Runtime
 ↓
tool A / B / C / D
 ↓
structured result

Potential advantages:

fewer model round trips;
complex loops and branching become executable code;
aggregation can happen outside the model.

Risks:

generated-code security;
permission propagation;
provenance;
debugging complexity.

The important point is that code execution is itself a capability seam, not a special-case hack.

16. Workflow Architecture

There is a workflow capability:

ctx.workflowEngine
workflow
workflow-worker-thread

This enables a stronger pattern:

Agent decides
      ↓
Deterministic workflow
      ↓
Execution
      ↓
Agent observes result

This is better than asking the LLM to control every deterministic step.

17. Plan / Goal / Todo

Plan, goals and todo are modeled as runtime domains.

In particular, plan mode is logged state rather than merely text in the prompt.

That means:

Plan
 ↓
Domain State
 ↓
Session Event
 ↓
Projection
 ↓
UI

This is a much more reliable architecture for long-running agents.

18. Web Architecture

Web is another capability seam:

ctx.web

Provider examples include:

web-search-deepseek
web-search-exa
web-search-perplexity
web-fetch-http

Consumer:

tool-web

Therefore web search is provider-swappable instead of being baked into the agent loop.

19. Frontend Architecture

The project ships a Web UI. Official startup is:

npx @deepseek-ai/dsh web

The default local address is http://127.0.0.1:3080.

The important architecture is:

Web Client
   ↓
API / Remote
   ↓
Cordis Services
   ↓
Agent Runtime

The frontend is a consumer of runtime state rather than the owner of Agent logic.

The development system also deliberately separates Host and Client TypeScript aggregates because Cordis Context declaration merging would otherwise collide in one TypeScript program. This is a sophisticated but non-trivial type-system consequence of the plugin architecture.

20. API Architecture

Important infrastructure:

api
Typert
api-gateway
sdk

Typert creates a type-aware remote surface:

Type Graph
 ↓
Remote Descriptor
 ↓
Runtime Registry
 ↓
RPC

The architecture therefore supports:

Plugin Service
      ↓
Remote API

The Python SDK also uses the normal dsh launcher and profile architecture instead of bypassing the runtime with a separate application model.

21. Profile / Bundle / Patch

This is one of the most important dsh concepts.

Profiles include:

web
headless
sdk
sdk-minimal
acp

A bundle is a distribution format for Cordis configuration rows and code. A patch can replace a row or insert new rows.

The effective composition is roughly:

Bundle 1
 ↓
Bundle 2
 ↓
Bundle 3
 ↓
Profile Patch
 ↓
Home Patch
 ↓
CLI --patch

Therefore:

Deployment shape itself is composition.

This is more powerful than ordinary dependency injection because the composition can be inspected, patched and reconfigured at runtime/profile level.

22. Self-Modification

The repository includes concepts such as:

self-modification
inspector
cordisInspect
dynamicCordisRunner
tool-cordis

The intended model is roughly:

Agent
 ↓
Inspect Runtime
 ↓
Inspect Plugins
 ↓
Mount / Unmount capability
 ↓
Change runtime composition

This is much more ambitious than a normal tool system.

It is also one of the highest-risk areas because the attack surface becomes:

Tool Abuse
+
Runtime Mutation

Any production implementation would need signed plugins, trust tiers, immutable system plugins, policy-gated mutation and strong rollback semantics.

23. Observability

Important capabilities include:

session-telemetry
session-telemetry-otel
token-meter
session-query
session-projection

A particularly strong invariant in AGENTS.md is:

Model-visible ⟺ logged

Anything that reaches a model request should be reconstructable from the session log; adding new model-visible input requires a corresponding session event.

This is a very strong principle for Agent reproducibility.

24. Testing Architecture

The repository has explicit commands for:

pnpm run test
pnpm run test:coverage
pnpm run test:e2e
pnpm run test:expected
pnpm run test:snapshot
pnpm run test:snapshot:record
pnpm run typecheck
pnpm run lint
pnpm run duplication
pnpm run build
pnpm run hygiene

The documented CI coverage gate is test:coverage, with a per-file coverage requirement for package source.

Snapshot replay

Recorded Session
       ↓
Replay
       ↓
Shipped Profile
       ↓
Expected Output

This is one of the most appropriate testing patterns for a stateful Agent Runtime.

LLM replay

A replay provider enables deterministic behavior without requiring a live model for every regression test.

25. Development Engineering

The project uses a large TypeScript monorepo with:

pnpm workspaces
ESM
TypeScript
Vitest
Typecheck
tsdown
VitePress
Lefthook

Important engineering conventions include:

every contribution goes through explicit effects/events;
registry registration returns disposers;
typed events use declaration merging;
discriminated unions use assertNever where appropriate;
plugin behavior should use documented extension points rather than editing the agent loop;
capability seams should be complete Definition / Provider / Consumer triplets;
deployment-varying choices should be configuration fields rather than hardcoded constants.

This is a strong engineering discipline for a plugin system.

26. Engineering Strengths

26.1 True Plugin Architecture

The word “plugin” is not marketing. Core execution primitives are plugins.

26.2 Capability Seam

Definition + Provider + Consumer gives a clean substitution boundary.

26.3 Event Kernel

Agent lifecycle is extensible without turning the core loop into a giant conditional tree.

26.4 Composition

Profile / Bundle / Patch makes runtime composition explicit.

26.5 Session Event Sourcing

Events + projections + cache provide durability and efficient reads.

26.6 Interoperability

Codex / Claude Code / ACP / DeepSeek / Pi AI / MCP can participate in the broader runtime.

27. Engineering Weaknesses

27.1 Everything-Plugin Complexity

The greatest strength is also the greatest weakness.

Extensibility ↑
      ↓
Dependencies ↑
      ↓
Composition complexity ↑
      ↓
Debugging difficulty ↑

A community discussion explicitly raised the “plugin paradox”: the architecture is attractive to developers but can impose configuration and composition complexity on end users.

27.2 Event Schema Coupling

Because model-visible state is tied to session events, the session event vocabulary becomes an ecosystem-level protocol.

A recent community discussion raised a concrete concern: third-party plugins that persist their own event types may make histories unreadable by official builds if there is no sanctioned extension path. This is an important architectural risk, not merely a documentation issue.

27.3 Security Maturity

Officially unaudited. This is a hard limitation for production claims.

27.4 API Churn

Developer preview + explicit breaking-change policy means downstream consumers must expect migration work.

28. Security Weakness — Deep Dive

The system has many security mechanisms:

Approval
Permission
Sandbox
Credential
Network
Plugin Trust

But the threat model is unusually broad because the agent can potentially:

execute code
modify files
spawn processes
load plugins
access credentials
access network
modify runtime composition

Therefore a production architecture should add:

Signed Plugins
Trusted Plugin Registry
Immutable Core Policies
Capability Attestation
Ephemeral Credentials
Network Egress Policy
Sandbox Escape Detection
Audit Trail
Rollback

29. Performance Architecture

The main performance ideas are architectural rather than benchmark numbers:

Programmatic Tool Composition

Reduce LLM round trips.

Projection Cache

Avoid replaying entire session logs on every query.

Replay

Avoid live model calls for regression tests.

Profiles

Allow minimal/headless/web/sdk compositions rather than one giant runtime.

No current public evidence justifies inventing a universal latency or cost benchmark.

30. RAG Architecture

DeepSeek Harness is not RAG-first.

Its retrieval model is closer to:

Skills
+
Web
+
Filesystem
+
Session Query
+
Tool Discovery
+
MCP

If a RAG capability is added, the architecture suggests:

ctx.retrieval

with providers such as:

Milvus
PostgreSQL/pgvector
Elasticsearch
Local

and consumers such as:

tool-search
context-builder
system-prompt

The key is to add RAG as a capability, not modify the agent loop.

31. Memory Architecture

Current persistent cognition is primarily represented through:

Session
Persistence
Projection
Skills
Context
State

rather than a classic vector-memory subsystem.

A future long-term memory should naturally be:

ctx.memory

with separate provider/consumer contracts.

32. Multi-Agent Architecture

The runtime already exposes a subagent seam and experimental Agent Teams concepts.

The powerful idea is:

Agent
=
Runtime participant

rather than:

Agent
=
Prompt + LLM

This enables heterogeneous subagents:

Supervisor
 ├── DeepSeek
 ├── Codex
 ├── Claude Code
 └── ACP Agent

while keeping the host-level policy, session and observability model centralized.

33. DeepSeek Harness vs Codex

Dimension	Codex	DeepSeek Harness
Core idea	Agent Runtime	Plugin Runtime
Agent Loop	Core subsystem	Plugin/capability
Tool Registry	Runtime subsystem	Capability seam
LLM	Provider boundary	Plugin/service
Session	Runtime subsystem	Plugin/service
Sandbox	Deep runtime subsystem	Capability seam
Event system	Strong	Fundamental
Plugin	Extension	Architecture primitive
Profile	Limited composition	Core composition model
Bundle	Not central	Core distribution primitive
Self-modification	Limited	Explicit experimental direction
Subagent	Runtime feature	Provider seam
UI	Host/client	Composition layer
Storage	Runtime abstraction	Capability seam
Stability	Higher	Developer preview
Security maturity	Higher	Experimental
Extensibility	9/10	10/10

Fundamental difference

Codex:

Agent Runtime
┌─────────────────────────────┐
│ Session                     │
│ Context                     │
│ Tool                        │
│ Policy                      │
│ Sandbox                     │
│ Agent Loop                  │
└─────────────────────────────┘

DeepSeek Harness:

Cordis
┌─────────────────────────────┐
│ Plugin                      │
│ Plugin                      │
│ Plugin                      │
│ Agent Loop Plugin           │
│ Session Plugin              │
│ Tool Plugin                 │
│ Model Plugin                │
│ Sandbox Plugin              │
└─────────────────────────────┘

Codex = Runtime.

DSH = Runtime Builder / Composable Runtime.

34. What Is Actually Innovative?

Innovation 1 — Everything is a Plugin

Not optional features; runtime primitives themselves are plugins.

Innovation 2 — Capability Seam

Definition / Provider / Consumer creates a reusable capability ABI.

Innovation 3 — Event Kernel

The Agent Loop is an event protocol rather than an immutable algorithm.

Innovation 4 — Composition as Deployment

Profile / Bundle / Patch make deployment a first-class composition operation.

Innovation 5 — Self-Modifying Runtime

Runtime inspection and plugin mutation are being treated as agent capabilities.

35. What Is Not New?

These individual technologies are not novel by themselves:

LLM API;
tool calling;
MCP;
web search;
shell;
sandbox;
JSONL;
SQLite;
Web UI;
subagents;
OpenTelemetry.

The innovation is their composition under one plugin runtime.

36. 二次开发建议

不推荐

Fork dsh
 ↓
直接改 packages/core
 ↓
增加大量 if/else
 ↓
形成自己的 distribution

This destroys the core architectural advantage.

37. KEEP

Strongly retain the following ideas:

Capability Seam
Cordis Context
Event-driven Agent Loop
Profile / Bundle / Patch
Session Event Log
Projection
Provider / Consumer separation
Replay testing
Agent interoperability
Runtime inspection

38. REFACTOR

Plugin SDK

Create a stable external SDK instead of exposing every internal runtime concept.

Event Schema Governance

Add:

Event namespace
Event version
Extension registry
Unknown-event policy
Migration
Compatibility policy

Permission Model

Unify:

Approval
Sandbox
Permission
Credential
Network
Plugin trust

Lifecycle Contracts

Formalize:

Plugin lifecycle
Agent lifecycle
Session lifecycle
Turn lifecycle
Scope lifecycle

39. REPLACE for Enterprise

Local Storage
 ↓
PostgreSQL + Object Storage

Local Credentials
 ↓
Vault / KMS

Local Identity
 ↓
OIDC / SSO

Untrusted Plugin
 ↓
Signed / Verified Plugin

40. ADD for Enterprise

A production enterprise harness should add:

Multi-tenancy
RBAC
ABAC
Audit
Policy Engine
Secrets Management
Quota
Cost Control
Agent Evaluation
Plugin Trust Registry
Signed Plugins
Sandbox Attestation
Artifact Store
Governed MCP
Network Egress Control

41. Recommended Enterprise Architecture

                 Enterprise Gateway
                         │
              ┌──────────▼──────────┐
              │ Identity / Policy   │
              └──────────┬──────────┘
                         │
                  Agent Runtime
                         │
      ┌──────────────────┼──────────────────┐
      ▼                  ▼                  ▼
   Agent A            Agent B            Agent C
      │                  │                  │
      └──────────────────┼──────────────────┘
                         ▼
                  Capability Bus
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
      LLM              Tools             Memory
       │                 │                 │
       ▼                 ▼                 ▼
   Providers          MCP/API        Persistent Store
                         │
                         ▼
                    Policy Engine
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
           Sandbox    Approval    Network

42. Plugin Contract Recommendation

A clean external contract could be:

interface Plugin {
  id: string;
  version: string;

  provides(): ServiceDefinition[];
  consumes(): ServiceDependency[];
  events(): EventDefinition[];
  config(): ConfigSchema;

  mount(ctx: PluginContext): Disposable;
  health(): HealthStatus;
}

43. Capability Contract Recommendation

interface Capability<TRequest, TResponse> {
  name: string;
  version: string;

  resolve(request: TRequest): Promise<ResolvedCapability>;

  execute(
    request: TRequest,
    context: ExecutionContext
  ): Promise<TResponse>;
}

The capability should not know about UI.

44. Event Contract Recommendation

interface AgentEventMap {
  "agent/pre-step": PreStepEvent;
  "agent/request": AgentRequestEvent;
  "agent/request-error": RequestErrorEvent;

  "tools/pre-execute": ToolPreExecuteEvent;
  "tools/execute": ToolExecuteEvent;
  "tools/post-execute": ToolPostExecuteEvent;

  "llm/stream": LlmStreamEvent;
  "system-prompt/assemble": PromptAssemblyEvent;
  "agent/turn-stopping": TurnStoppingEvent;
  "session/flush": SessionFlushEvent;
}

45. Definition of Done

A production-grade Plugin Harness should require:

[ ] Plugin contract frozen
[ ] Capability seam defined
[ ] Provider contract defined
[ ] Consumer contract defined
[ ] Event schema defined
[ ] Event versioning defined
[ ] Plugin lifecycle tested
[ ] Unload tested
[ ] Session persistence tested
[ ] Replay tested
[ ] Sandbox tested
[ ] Approval tested
[ ] Credential boundary tested
[ ] MCP tested
[ ] Subagent tested
[ ] API contract tested
[ ] Snapshot tested
[ ] Security tested
[ ] Performance baseline
[ ] Upgrade migration tested

46. CTO Decision Matrix

Question	Verdict
Architecture Innovation	⭐⭐⭐⭐⭐
Agent Runtime	⭐⭐⭐⭐⭐
Plugin Architecture	⭐⭐⭐⭐⭐+
Extensibility	⭐⭐⭐⭐⭐+
Event Architecture	⭐⭐⭐⭐⭐
Session Architecture	⭐⭐⭐⭐⭐
Testing Architecture	⭐⭐⭐⭐⭐
Interoperability	⭐⭐⭐⭐⭐
Security Design	⭐⭐⭐⭐☆
Security Maturity	⭐⭐☆☆☆
API Stability	⭐⭐☆☆☆
Developer Experience	⭐⭐⭐☆☆
Enterprise Readiness	⭐⭐☆☆☆
Research Value	⭐⭐⭐⭐⭐+
Learning Value	⭐⭐⭐⭐⭐+

47. Final Verdict

DeepSeek Harness 到底是什么？

不是：

“DeepSeek 版 Claude Code。”

也不是：

“带插件的 Coding Agent。”

更准确：

一个正在尝试把 Agent Runtime 本身做成可组合 Microkernel 的开源 Harness。

它真正强在哪里？

Cordis
 ↓
Plugin
 ↓
Capability Seam
 ↓
Event Kernel
 ↓
Profile
 ↓
Bundle
 ↓
Patch
 ↓
Agent Runtime

最大技术价值

Everything is a Plugin
Capability Seam
Event-driven Agent Runtime
Session Event Sourcing
Agent Interoperability
Self-modifying Runtime

最大风险

Everything Plugin
        ↓
Dependency Graph Explosion
        ↓
Configuration Complexity
        ↓
Protocol Coupling
        ↓
Event Schema Governance
        ↓
Security Boundary Complexity

48. 是否值得学习？

★★★★★ 强烈值得。

最值得研究：

Cordis
Capability Seam
Event Kernel
Profile
Bundle
Patch
Session Event
Projection
Plugin lifecycle
Subagent provider

49. 是否值得 Fork？

★★★☆☆ 当前不建议直接 Fork 作为长期产品基础。

原因：

Developer Preview
+
Breaking Changes
+
No Security Audit
+
Extremely High Composition Complexity

但它非常值得作为架构参考和实验底座。

50. 最终判断

如果 Codex 代表：

“如何把 Agent 做成成熟 Runtime”

那么 DeepSeek Harness 代表：

“如何把 Agent Runtime 本身做成可组合基础设施。”

最终可以把两者放在同一张图里：

                  Modern Agent Engineering
                           │
              ┌────────────┴────────────┐
              │                         │
            Codex                     DSH
              │                         │
              ▼                         ▼
       Deep Agent Runtime       Runtime Microkernel
              │                         │
              │                 ┌───────┼────────┐
              │                 ▼       ▼        ▼
              │               Loop    Tools     LLM
              │                 │       │        │
              └─────────────────┼───────┼────────┘
                                ▼
                         Agent Harness

最值得复制的不是 dsh 的 package 数量，而是它的设计原则：能力必须有稳定 seam；行为必须通过 event 扩展；实现必须由 provider 提供；组合必须由 profile 控制；状态必须可记录、可回放、可投影。

而最应该警惕的是：

“Everything is a Plugin” 如果没有强治理，最终可能从“可组合”滑向“不可理解”。

因此，一个真正成熟的下一代 Agent Harness 应该取 DeepSeek Harness 的：

Capability Seam
+
Event Kernel
+
Plugin Runtime
+
Composition
+
Event-sourced Session
+
Replay

再补上：

Stable ABI
+
Plugin Trust
+
Event Versioning
+
Security Attestation
+
Enterprise Governance
+
Evaluation

这才是从 Developer Preview Harness 走向 Production Agent Infrastructure 的完整路线。

Evidence / Source Notes

Official repository: https://github.com/deepseek-ai/deepseek-harness
Official architecture: docs/architecture.md
Official capability graph: docs/capability-seams.md
Official engineering rules: AGENTS.md
Official safety statement: SAFETY.md
Official development guide: docs/development.md
Agent Note: microkernel event taxonomy
Public discussions on plugin complexity and session-event compatibility
DeepSeek official Harness page

All dynamic GitHub metrics are treated as the current page snapshot rather than timeless facts. Security maturity and production readiness are explicitly constrained by the project’s own SAFETY.md statement.