DeepSeek Ships Harness, an Open-Source Agent Framework That Runs on Your Machine
Agent tooling is shifting from cloud-hosted chat to local, file-system-aware execution. DeepSeek Harness puts a transparent, auditable agent directly into a developer's project directory, with a permission model that makes it viable for real work rather than just demos.
DeepSeek Harness is an MIT-licensed agent framework that moves AI coding out of the chat box and onto the developer's own machine. It provides a graphical cockpit where an agent can read project files, execute shell commands, and modify code, with every action gated by an approval system. The architecture is built on a plugin model using the Cordis framework, making capabilities like file I/O, web search, and tool execution pluggable and configurable.
A session inside dsh supports advanced primitives including sub-agents for parallel task execution, background tasks for long-running jobs, a plan mode that requires human sign-off before code changes, and a goal system that keeps the agent on track. The tool call tree and a raw trace view expose every model thought and command run, giving developers full auditability.
The tool runs via a single `npx` command and supports over twenty model providers out of the box, plus any OpenAI-compatible endpoint for local models or internal gateways. A headless CLI profile lets the same agent run in CI pipelines or scripts, making the jump from interactive use to automation straightforward.
Harness treats the agent as an operator on a real filesystem, not a chatbot, which changes the failure mode from hallucinated answers to real file damage—hence the mandatory approval gates.
The plugin architecture based on Cordis means the agent's capabilities are not a monolithic product decision but a configurable assembly, lowering the barrier for community extensions.
Offering a headless mode alongside the GUI suggests DeepSeek sees agent automation as a first-class CI primitive, not just an interactive developer tool.
The combination of plan mode, goals, and sub-agents creates a project-management layer on top of raw tool calling, pushing the agent toward multi-step, reviewable workflows rather than one-shot prompts.
The discussion centers on what DeepSeek Harness actually is and how it differs from existing tools like Codex, Qoder, and Hermes. A key distinction emerges: Harness abstracts the agent's internal components (model, loop, scheduler, UI) into pluggable modules, treating agent architecture itself as a searchable design space rather than a fixed system. Practical concerns surface around missing file-@ functionality, multimodal support, and whether adding more tools genuinely increases capability or just inflates context. The tutorial's speed and depth draw praise, while some remain unconvinced the framework offers anything beyond a new scaffold.
Codex has already combined a relatively mature Agent loop, runtime, sandbox, tool execution, and security policy into an opinionated agent system, then allows us to extend it through skills, MCP, AGENTS.md, and subagents. DeepSeek Harness abstracts one layer further down, even making the model, loop, session, storage, sandbox, scheduler, and UI all pluggable. So Codex is more about optimizing 'how an Agent should work reliably,' while DeepSeek Harness is more about exploring 'what the way an Agent works itself should be.' I think the biggest opportunity for DeepSeek's route is that once models are strong enough in the future, many orchestration policies that today require manual hard-coding can gradually be handed over to the model to learn and explore; but the biggest risk is precisely here — once the search space expands, without a strong eval and feedback system, flexibility might not translate into final performance.
DeepSeek will model Harness optimization as an outer-loop search problem. First, parameterize loop, memory, tools, subagent topology, context strategy, scheduler, etc., into a search space; then run candidate Harnesses on a large number of real tasks, fully recording trajectories; then use success, cost, latency, robustness, etc., to form a multi-objective reward. The Meta Agent performs credit assignment based on failed trajectories, determining whether the problem is model capability, or context, tool policy, memory, scheduler, or verifier, then produces the next generation of Harness through mutation, recombination, or generating new plugins. Going further, it won't seek a single globally optimal Harness, but will train a meta-controller that dynamically selects or even generates a Harness based on the task. So what truly needs to be learned is no longer just: 'How to do this task?' but: 'Faced with this type of task, what kind of Agent itself is most suited to solve it?' I believe if DeepSeek Harness's composability ultimately has strategic value, the core should be reflected right here.
DeepSeek will model Harness optimization as an outer-loop search problem. First, parameterize loop, memory, tools, subagent topology, context strategy, scheduler, etc., into a search space; then run candidate Harnesses on a large number of real tasks, fully recording trajectories; then use success, cost, latency, robustness, etc., to form a multi-objective reward. The Meta Agent performs credit assignment based on failed trajectories, determining whether the problem is model capability, or context, tool policy, memory, scheduler, or verifier, then produces the next generation of Harness through mutation, recombination, or generating new plugins. Going further, it won't seek a single globally optimal Harness, but will train a meta-controller that dynamically selects or even generates a Harness based on the task. So what truly needs to be learned is no longer just: 'How to do this task?' but: 'Faced with this type of task, what kind of Agent itself is most suited to solve it?' I believe if DeepSeek Harness's composability ultimately has strategic value, the core should be reflected right here.
Seeing the article say 'the more tools, the more things the Agent can do,' here's a note on DeepSeek Harness's applicable boundary: when MCP tools reach dozens or hundreds, functionality does increase, but the Tool Schema the model carries in each round also grows longer. When we built MCP Lens, we adopted search → return a small number of exact schemas → explicit call; small directories don't need this layer. It's suggested the tutorial later test four things together: model-facing schema bytes, candidate recall, extra search steps, and same-task completion rate, to judge whether 'more plugins' is adding capability or adding burden. Disclaimer: I am the maintainer of labmimors/dsh-mcp-lens.