摘要：

最近“DeepSeek Harness”开始在开发者圈里被频繁讨论。

真正值得技术人员关注的，不是它会不会成为“国产Claude Code”，而是一个更根本的问题。

为什么同一个模型，放进普通聊天框和放进Coding Agent里，会表现得像两个完全不同的产品？

答案就在Harness。

本文从工程视角拆解Model + Harness = Agent这条链路，并用Python实现任务状态机、工具注册表、代码沙箱、Patch Plan、测试闭环、上下文压缩、成本预算和审计日志等核心组件。

FACT-001｜先区分“视频热点”和“官方可核验信息”

视频中提到了DeepSeek Harness独立产品、8月1日内测招募、团队负责人和公众号注册等细节。

截至本文核验时，没有在DeepSeek公开官网、官方API文档或官方GitHub中找到这些产品细节的独立官宣页面。

目前可以从DeepSeek官方资料确认的是：DeepSeek V4已经显著强化Agentic Coding能力，并明确适配Claude Code、OpenCode、OpenClaw、GitHub Copilot CLI、Pi等Agent / Harness生态。

因此本文把“DeepSeek Harness”作为热点切入口，但技术结论只建立在官方已经公开的V4 Agent能力和Harness工程模式之上。

关键词：DeepSeek Harness、DeepSeek V4、Coding Agent、Agent Harness、Claude Code、OpenCode、Tool Calling、Sandbox、Context Engineering

1. 代码 Agent 的核心公式，不是“模型 + IDE”

很多人第一次理解Coding Agent，会把它看成“更聪明的代码补全”。

其实这已经完全低估了它。

代码补全的输入通常只是光标附近的上下文。

Coding Agent面对的却是一个长期任务。

它需要理解整个仓库。

需要定位相关文件。

需要修改代码。

需要运行测试。

需要读取错误。

还需要决定下一步是否继续。

更准确的公式

Agent = Model + Context + Tools + State + Policy + Feedback Loop

Harness负责的，正是Model之外的这些部分。

模型负责“思考”。

Harness负责让思考变成可以执行、可以验证、可以恢复的工程动作。

2. DeepSeek 官方已经释放出一个明确信号：V4 正在往 Agent 生态靠

DeepSeek V4官方发布资料把Agentic Coding单独列成重点能力。

官方还明确表示，V4已经与Claude Code、OpenClaw、OpenCode等主流Agent工具集成。

DeepSeek官方Agent集成文档目前还覆盖GitHub Copilot CLI、Pi、Deep Code、WorkBuddy、Crush、Kilo Code等工具。

这说明DeepSeek正在做的事情，已经不只是提供一个Chat API。

它在主动进入Agent执行层。

同一个DeepSeek V4模型，可以被多个不同Harness驱动。

DeepSeek V4
├── Claude Code Harness
├── OpenCode Harness
├── Copilot CLI Harness
├── Pi Harness
└── 自研 Harness

这也是为什么“模型能力强”并不自动等于“Coding Agent好用”。

3. Harness第一件事：必须把任务变成状态机

普通聊天可以一问一答。

代码任务不能。

“给项目增加JWT鉴权”可能持续几十分钟。

中间会经历搜索、阅读、规划、修改、测试、失败、回滚和继续。

因此Agent必须拥有显式状态。

from dataclasses import dataclass, field
from enum import Enum


class AgentPhase(str, Enum):
    PLANNING = "planning"
    SEARCHING = "searching"
    EDITING = "editing"
    TESTING = "testing"
    REVIEWING = "reviewing"
    DONE = "done"
    FAILED = "failed"


@dataclass
class AgentState:
    task_id: str
    goal: str
    phase: AgentPhase

    touched_files: list[str] = field(
        default_factory=list
    )

    failed_tests: list[str] = field(
        default_factory=list
    )

    iteration: int = 0
    max_iterations: int = 20

    token_cost: float = 0.0
    last_error: str | None = None

如果Agent没有显式状态，模型“记得自己做过什么”的能力就完全依赖上下文窗口。

一旦Context被压缩或者截断，Agent就可能重复读取文件、重复改代码、重复跑测试。

STATE-101｜STATE_ONLY_IN_PROMPT

任务状态只存在于自然语言上下文里，一旦上下文压缩或会话恢复，Agent会失去可靠执行历史。

4. 第二件事：Tool Registry必须可控，而不是“给模型一个Shell”

Coding Agent最大的能力来源不是模型参数。

而是工具。

读取文件。

搜索代码。

写补丁。

运行测试。

调用LSP。

执行Git命令。

如果所有能力都直接变成“执行任意Shell”，系统几乎没有治理能力。

from dataclasses import dataclass
from typing import Callable


@dataclass
class Tool:
    name: str
    description: str
    handler: Callable

    read_only: bool = True
    requires_approval: bool = False


class ToolRegistry:
    def __init__(self):
        self._tools = {}

    def register(self, tool: Tool):
        if tool.name in self._tools:
            raise ValueError(
                f"duplicate tool: {tool.name}"
            )

        self._tools[tool.name] = tool

    def get(self, name: str) -> Tool:
        if name not in self._tools:
            raise KeyError(
                f"unknown tool: {name}"
            )

        return self._tools[name]

真正的Harness应该知道哪个工具是只读的。

哪个工具会修改文件。

哪个操作需要人工确认。

TOOL-202｜SHELL_IS_THE_API

把任意Shell当作唯一工具接口，模型可以绕过权限边界，审计系统也无法准确理解每一次操作。

5. 第三件事：代码修改不能直接 write file，应该先产生 Patch

直接让模型覆盖文件，是最粗糙的Coding Agent实现。

真正可控的方式，是先生成Patch Plan。

Harness先检查。

再应用。

from dataclasses import dataclass


@dataclass
class FilePatch:
    path: str
    old_hash: str
    new_content: str


@dataclass
class PatchPlan:
    reason: str
    files: list[FilePatch]

    requires_test: bool = True
    rollback_ready: bool = True

old_hash很重要。

因为Agent读取文件以后，文件可能已经被人或者另一个Agent修改。

如果Hash不一致，就不应该盲目覆盖。

import hashlib


def sha256_text(text: str) -> str:
    return hashlib.sha256(
        text.encode("utf-8")
    ).hexdigest()


def verify_patch_base(
    current_content: str,
    expected_hash: str,
) -> bool:

    return (
        sha256_text(current_content)
        == expected_hash
    )

PATCH-301｜STALE_FILE_OVERWRITE

Agent基于旧文件生成修改，但应用Patch时没有检查版本，可能覆盖开发者刚刚提交的新代码。

6. 第四件事：真正的Coding Agent必须运行在Sandbox里

AI修改代码之后，必须执行。

但执行代码本身就是风险。

测试脚本可能删除文件。

依赖安装可能执行生命周期脚本。

项目代码可能读取环境变量。

因此Harness不应该直接在宿主机执行所有命令。

from dataclasses import dataclass


@dataclass
class SandboxPolicy:
    network: bool = False

    writable_paths: tuple[str, ...] = (
        "/workspace",
        "/tmp",
    )

    env_allowlist: tuple[str, ...] = ()

    max_cpu_seconds: int = 120
    max_memory_mb: int = 2048
    timeout_seconds: int = 180

真实实现可以使用Docker、gVisor、Firecracker或者独立CI Runner。

关键不是选哪个隔离技术。

关键是执行环境必须和开发者机器隔离。

SANDBOX-401｜RUN_ON_HOST

Agent生成的命令直接在开发机或生产环境执行，没有文件、网络、环境变量和资源隔离。

7. 第五件事：测试不是最后一步，而是Agent的反馈信号

普通代码生成的流程是生成代码然后结束。

Coding Agent的流程应该是生成Patch、执行测试、读取错误、定位原因、重新修改。

@dataclass
class TestResult:
    command: str
    exit_code: int

    stdout: str
    stderr: str

    duration_ms: int


def should_continue(
    state: AgentState,
    result: TestResult,
) -> bool:

    if result.exit_code == 0:
        return False

    if (
        state.iteration
        >= state.max_iterations
    ):
        return False

    return True

Plan → Read/Search → Patch → Test → Observe → Re-plan

这就是Agent Loop。

而Harness最大的价值，就是把这个Loop变得稳定。

8. 第六件事：Context Engineering才是代码Agent最容易被低估的能力

DeepSeek V4官方已经把1M上下文作为重要能力。

但1M上下文不意味着应该把整个仓库全部塞进模型。

上下文越大，检索噪声同样可能越大。

优秀Harness必须先决定什么值得进入Context。

@dataclass
class ContextItem:
    source: str
    content: str

    relevance: float
    freshness: float

    token_count: int


def context_score(
    item: ContextItem,
) -> float:

    return (
        0.70 * item.relevance
        + 0.30 * item.freshness
    )


def select_context(
    items: list[ContextItem],
    token_budget: int,
):
    ordered = sorted(
        items,
        key=context_score,
        reverse=True,
    )

    selected = []
    used = 0

    for item in ordered:
        if (
            used + item.token_count
            > token_budget
        ):
            continue

        selected.append(item)
        used += item.token_count

    return selected

CTX-501｜WHOLE_REPO_DUMP

为了利用长上下文把整个仓库直接塞给模型，导致噪声增加、成本上升，并削弱真正关键文件的注意力。

9. 第七件事：长任务必须做Context Compaction

Coding Agent运行20分钟后，上下文里会堆积大量工具调用、文件内容和测试日志。

全部保留会越来越贵。

全部删除又会失忆。

所以需要Checkpoint。

@dataclass
class AgentCheckpoint:
    goal: str

    current_plan: list[str]

    completed_steps: list[str]

    important_files: list[str]

    unresolved_errors: list[str]

    decisions: list[str]

    next_action: str

Checkpoint不是普通聊天摘要。

它保存的是任务继续执行所需的最小状态。

10. 第八件事：Harness必须有预算，Agent不能无限自我循环

Agent最危险的失败方式之一，不是报错。

而是不停重试。

@dataclass
class Budget:
    max_iterations: int = 20
    max_tool_calls: int = 100

    max_cost_usd: float = 2.0

    max_wall_time_seconds: int = 1800


def budget_exceeded(
    state: AgentState,
    tool_calls: int,
    elapsed_seconds: int,
    budget: Budget,
) -> bool:

    return any([
        state.iteration
        >= budget.max_iterations,

        tool_calls
        >= budget.max_tool_calls,

        state.token_cost
        >= budget.max_cost_usd,

        elapsed_seconds
        >= budget.max_wall_time_seconds,
    ])

BUDGET-601｜INFINITE_AGENT_LOOP

Agent没有最大迭代数、工具调用数、成本和墙钟时间限制，一次失败任务可能无限消耗资源。

11. 第九件事：同一个Harness里，Pro和Flash应该承担不同角色

DeepSeek V4官方目前同时提供Pro和Flash。

官方描述里，Flash在简单Agent任务上可以接近Pro，同时速度更快、成本更低。

这很适合Agent内部做分工。

def route_agent_model(
    task_type: str,
    complexity: int,
) -> str:

    if task_type in {
        "file_summary",
        "simple_search",
        "format_result",
    }:
        return "deepseek-v4-flash"

    if complexity <= 2:
        return "deepseek-v4-flash"

    return "deepseek-v4-pro"

主Agent可以使用Pro。

文件摘要、简单搜索判断和子Agent任务可以使用Flash。

一次用户任务内部，也可以产生多次不同模型调用。

12. 第十件事：每一步都要可审计，否则“自动改代码”很难进入企业

个人写Demo，可以只看最终结果。

企业场景不行。

必须知道Agent看了哪些文件、执行了哪些工具、为什么修改、哪些测试通过、谁批准了高风险操作。

from dataclasses import dataclass
from datetime import datetime


@dataclass
class AgentEvent:
    task_id: str
    timestamp: datetime

    phase: str
    action: str

    tool_name: str | None

    input_digest: str | None
    output_digest: str | None

    cost_usd: float

    approved_by: str | None = None

Agent的Session Log未来很可能和CI日志一样重要。

13. 把组件串起来，一个最小Harness长什么样

class CodingHarness:
    def __init__(
        self,
        model_client,
        tool_registry,
        sandbox,
        budget,
    ):
        self.model = model_client
        self.tools = tool_registry
        self.sandbox = sandbox
        self.budget = budget

    async def run(
        self,
        state: AgentState,
    ):
        while True:

            if budget_exceeded(
                state=state,
                tool_calls=0,
                elapsed_seconds=0,
                budget=self.budget,
            ):
                state.phase = AgentPhase.FAILED
                state.last_error = "budget exceeded"
                return state

            context = await build_context(
                state
            )

            decision = await self.model.plan(
                goal=state.goal,
                context=context,
            )

            if decision.type == "tool":
                tool = self.tools.get(
                    decision.tool_name
                )

                result = await execute_tool(
                    tool=tool,
                    args=decision.arguments,
                    sandbox=self.sandbox,
                )

                await append_observation(
                    state,
                    result,
                )

            elif decision.type == "finish":
                state.phase = AgentPhase.DONE
                return state

            else:
                raise RuntimeError(
                    "unknown decision"
                )

            state.iteration += 1

真正产品当然会复杂很多。

但骨架基本不会逃出Task State、Context、Model、Tool、Sandbox、Feedback这几层。

14. 为什么Agent产品最难复制的部分，很可能就是Harness

模型可以通过API调用。

Harness却需要长期积累。

STEP 1｜仓库理解策略

什么文件应该先看，什么目录应该忽略，如何使用LSP、Git历史和依赖图缩小Context。

STEP 2｜工具调用策略

不同任务开放哪些工具，哪些命令需要审批，什么情况下应该拒绝执行。

STEP 3｜修改策略

什么时候直接Patch，什么时候先重构Plan，如何避免旧版本覆盖和无关改动。

STEP 4｜验证策略

先跑哪组测试，失败以后读取哪些日志，什么时候需要扩大测试范围。

STEP 5｜恢复策略

Agent被中断、模型报错、上下文压缩以后，如何从Checkpoint继续。

STEP 6｜评测策略

如何判断一个任务是真的完成，而不是模型自己宣布完成。

这些规则加起来，才构成产品体验。

所以同一个DeepSeek V4放进两个不同Harness里，实际效果可以有巨大差异。

15. 多模型平台为什么也会越来越需要Harness层

如果平台只做聊天，多模型聚合主要解决“模型选择”。

当平台开始提供智能体以后，问题会迅速升级。

一个任务可能先用文本模型拆计划。

再调用图片模型生成资产。

再调用视频模型完成镜头。

最后用PPT能力整理结果。

对于聚合500+模型、同时包含智能体、无限画布、AI漫剧和AI PPT的多模型平台来说，本质上也会遇到同一个问题。

模型越多，越不能只做一个“模型下拉框”。

真正有价值的是统一的执行层。

Multi-Model Harness
├── Task Planner
├── Model Router
├── Tool Registry
├── Asset Registry
├── Workflow DAG
├── Context Manager
├── Retry Policy
├── Budget Manager
├── Quality Gate
└── Audit Log

从这个角度看，Harness并不只属于Coding Agent。

它是所有“AI真正开始干活”之后都会出现的一层。

16. 七个Coding Agent最容易踩的坑

STATE-101｜NO_PERSISTENT_STATE

任务执行状态只存在于上下文中，断线或压缩后无法可靠恢复。

TOOL-202｜UNRESTRICTED_SHELL

把任意Shell作为唯一工具接口，缺少权限、语义和审计边界。

PATCH-303｜WRITE_WITHOUT_VERSION_CHECK

修改文件前不校验版本，Agent可能覆盖开发者或其他Agent的新改动。

SANDBOX-404｜HOST_EXECUTION

直接在宿主机执行模型生成的命令，没有网络、文件系统和环境变量隔离。

CTX-505｜CONTEXT_DUMP

依赖超长上下文解决所有问题，把整个仓库塞给模型，导致噪声与成本同步上涨。

LOOP-606｜NO_BUDGET

没有迭代数、工具调用、Token成本和时间预算，失败任务可以无限循环。

DONE-707｜MODEL_SAYS_DONE

把模型输出“任务完成”当成真实完成，没有测试、Diff和业务验收。

17. 真正该怎么评测一个Coding Harness

只看模型Benchmark是不够的。

Harness应该有自己的工程指标。

指标	含义
Task Success Rate	真实任务最终通过测试和验收的比例
First-pass Success	第一次Patch就通过的比例
Median Iterations	完成任务需要多少Agent循环
Tool Failure Rate	工具调用失败、参数错误和权限拒绝比例
Context Efficiency	有效上下文Token占总输入Token的比例
Accepted Task Cost	完成一个可接受任务的真实总成本
Rollback Rate	最终需要撤销Agent改动的任务比例

如果一个Harness让模型多调用50%的Token，却把Task Success Rate提高20%，它可能依然非常划算。

反过来，Token很省但任务大量失败，也不是真正的低成本。

18. 最后：DeepSeek如果真的自研Harness，最值得看的不是UI

如果后续DeepSeek真的正式推出自研Harness产品，我最关注的不会是它长得像不像Claude Code。

也不会是它能不能一键生成几千行代码。

真正值得看的会是四件事。

第一，Context选择是不是足够准。

第二，工具和沙箱是不是足够稳定。

第三，测试失败后的恢复循环是不是足够聪明。

第四，Pro与Flash能不能在同一任务内部形成有效分工。

模型决定Agent能力上限。

Harness决定这个上限有多少能够真正变成工程产出。

代码Agent下一阶段真正的竞争，很可能不再只是Model War，而是Harness Engineering。

资料说明：

DeepSeek V4官方发布资料明确强调Agentic Coding能力，并表示V4已与Claude Code、OpenClaw、OpenCode等主流Agent工具集成。

DeepSeek官方Agent集成文档目前还提供Claude Code、OpenCode、GitHub Copilot CLI、Pi、Deep Code、WorkBuddy等工具的接入说明。

DeepSeek官方GitHub仓库awesome-deepseek-agent用于整理DeepSeek模型与多种Agent / Coding Assistant的集成方式。

视频中关于“DeepSeek Harness独立产品内测、具体团队与负责人”的信息，目前未在DeepSeek公开官网/API文档中找到可独立核验页面，因此本文没有把这些细节写成确定事实。

文中的Python代码、Harness架构、错误码与评测指标均为工程设计示例，不代表DeepSeek内部实现。