摘要：

最近“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应该有自己的工程指标。

如果一个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内部实现。