DeepSeek Harness 完整解析：从“Everything is a Plugin”到可恢复、可审计的 Agent Runtime
当 Agent 具备代码修改、Shell 执行、子 Agent 调度和长时间运行能力后，工程问题便不再只是“模型能否调用工具”，而是：系统能否解释它看到了什么、执行了什么、为何被允许执行、异常后如何恢复，以及什么证据足以证明任务已经完成。
摘要
传统 Agent 系统通常围绕“模型—工具—结果”的循环构建。然而，当任务持续时间从几分钟延长到数小时，当执行范围从单次 API 调用扩展到代码修改、后台进程、多 Agent 协作和外部系统操作时，仅有 Agent Loop 已不足以保证系统可靠运行。
DeepSeek Harness，简称 dsh，试图提供一套更完整的 Agent 运行基础设施。它通过 Cordis 实现插件化组合，以只追加的 Session Event Log 保存执行事实，通过 Context Projection 管理模型可见信息，并将工具暴露、执行策略、授权确认和进程沙箱拆分为不同层次。此外，Goal、Ralph、Workflow 与 Jobs 等机制分别处理同会话续跑、Fresh Agent 接力、多 Agent 编排和后台任务生命周期。
本文将从架构定位、插件系统、执行循环、上下文与持久状态、工具体系、长程任务、权限边界和完成验证八个方面，系统分析 DeepSeek Harness 的设计价值与现阶段局限。
截至 2026 年 8 月 19 日，DeepSeek Harness 仍处于 Developer Preview 阶段。官方明确提示其核心插件与 API 仍在快速演进，并可能出现破坏兼容性的变更。
一、Agent Harness 解决的不是“模型调用”，而是“受控执行”
最基础的 Agent Loop 可以表示为：
用户任务
↓
模型推理
↓
工具调用
↓
工具结果
↓
模型继续决策该结构能够让模型连续行动，但并不能回答以下工程问题：
- 任务在什么条件下才算完成？
- 模型声明完成时，测试是否真正执行？
- 上下文过长后，早期约束是否仍然有效？
- 进程崩溃后，系统如何恢复任务状态？
- 当前 Agent 应该看到哪些工具？
- 模型请求执行高风险操作时，运行时是否允许？
- 一个失败的外部操作能否安全重试？
- 长任务的 Token、费用和实际运行时间如何限制？
- 执行过程出现偏差后，能否重建当时的模型输入？
因此，完整的 Agent 系统不应被简化为：
Agent = LLM + Tools更准确的表达是：
Agent System
=
Model
+
Execution Runtime
+
Persistent State
+
Capability Control
+
Permission Boundary
+
Verification模型负责理解任务、制定策略和选择行动；Harness 则负责管理模型运行的生命周期、状态、能力和边界。
从这一角度看，DeepSeek Harness 的定位并不是单纯的 Coding Agent，而更接近一个可组合的 Agent Runtime 与控制平面。
二、整体定位：为什么 DeepSeek Harness 更像 Runtime
DeepSeek 官方将 Harness 描述为模型与真实工作环境之间的基础设施：模型提供智能，Harness 使 Agent 能够理解环境、使用工具并持续工作。当前系统覆盖模型、工具、Skills、Session、Sandbox、Storage、Loop、Scheduling 与 UI 等能力。
其整体结构可以概括为：
用户 / 上层应用
│
▼
┌─────────────────────┐
│ DeepSeek Harness │
│ Runtime / Control │
└─────────────────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
执行与编排 能力与权限 状态与上下文
Agent Loop Tool Registry Session Log
Goal / Ralph Skills Persistence
Workflow / Jobs Approval Compaction
Subagent Sandbox Projection
│ │ │
└─────────────────────┼─────────────────────┘
▼
LLM这里最重要的架构变化是：
LLM 不再是系统唯一的中心，而是运行时中的一个决策组件。
模型可以替换，工具可以替换，持久化实现可以替换，沙箱后端可以替换，甚至 Agent Loop 本身也可以被其他插件实现取代。
官方当前提供四类运行模式：
| 模式 | 主要能力 | 典型用途 |
|---|---|---|
| Standard | 文件编辑、Shell、搜索、Skills、Plan、Goal、Subagent、Workflow | 完整 Coding Agent |
| Code | 通过模型生成的 TypeScript 程序组合多步工具调用 | 减少模型与工具之间的往返 |
| Minimal | 持久化 Shell 与文件编辑器 | 模型与 Harness 基准测试 |
| Creator | Standard 能力加运行时检查和插件实验 | 开发自定义 Harness 与 Preset |
其中，Code Mode 的核心价值是将确定性的工具编排交给程序，而不是让模型在每一步操作后重新推理。
三、Everything is a Plugin：以 Cordis 构建插件化内核
DeepSeek Harness 最核心的设计原则是：
Everything is a Plugin。
它基于 Cordis 构建。插件可以向共享 Context 注册 Service、Typed Event 和可逆 Effect，并通过依赖关系完成组合。包括模型适配器、工具注册表、Session Log 和 Agent Loop 在内的主要组件，均以插件形式存在。官方架构文档强调，系统不存在一个必须通过修改源码扩展的“特权核心”；插件卸载时，其注册产生的 Effect 也可以随之撤销。
可以将其抽象为三个角色：
Service Definition
│
▼
Service Provider
│
▼
Consumer例如，一个 Sandbox 能力可以定义统一接口，再由不同 Provider 提供具体实现：
Sandbox Service
│
├── Linux bwrap / Landlock Provider
├── macOS Seatbelt Provider
├── Windows Restricted Token Provider
└── 其他远程执行或容器实现上层消费者只依赖能力契约，而不依赖某个固定执行后端。
这种架构带来两项直接收益。
第一，框架能力可以通过配置组合，而不必持续修改一个庞大的 Agent 类。
第二，具体实现可以被替换，而上层 Agent、工具或 UI 不需要同步重构。
从软件架构角度看，DeepSeek Harness 更接近微内核式设计：
较薄的核心执行协议
+
可替换的能力接口
+
插件化 Provider
+
统一事件与生命周期它的优势是扩展性和可组合性；代价则是更高的概念复杂度和插件治理成本。
四、Agent Loop：管理的是执行生命周期，而不仅是循环
DeepSeek Harness 将执行过程拆分为 Turn 与 Step。
- 一个 Step 对应一次模型请求，以及该请求产生的工具调用；
- 一个 Turn 可以包含多个 Step；
- 工具结果返回后，如果模型仍需继续推理，同一 Turn 可以进入下一 Step。
核心流程可以简化为：
turn/start
│
├── 领取当前输入
├── 组装 System Prompt
├── 组装 Tool Schema
├── 从 Session Log 派生历史
│
▼
step/start
│
├── 请求模型
├── 接收流式输出
├── 写入 assistant/message
├── 分发工具调用
├── 写入 tool/result
│
▼
step/end
│
├── 是否继续下一 Step？
│
▼
turn/end官方核心文档说明，默认 Loop 会从 Session Log 派生历史，通过 System Prompt 与 Tool Registry 组装请求，并将每一个模型可见的事实继续追加到日志中。
值得注意的是，DeepSeek Harness 并未把压缩、Goal、Ralph、Workflow 和后台任务全部固化到一个巨型 Loop 中。
其设计更接近：
Thin Agent Loop
+
Lifecycle Events
+
Optional Plugins这种方式能够避免 Loop 不断膨胀，也使不同部署可以根据任务类型选择不同的执行机制。
五、Session Event Sourcing：系统真正的状态基础
DeepSeek Harness 中最具工程价值的设计之一，是以 Event Sourcing 方式组织 Session。
一个 Session 不是简单的聊天记录，而是一条由类型化 SessionEvent 组成的只追加日志。事件可以包括：
turn/start
turn/end
step/start
step/end
user/message
assistant/chunk
assistant/message
tool/call
tool/result
request/header
request/context
approval/*
goal/*
compaction/*官方 Session 文档明确指出：
- Session 是只追加的类型化事件日志；
- 它是 Agent 完整交互历史的唯一真源；
- LLM 消息历史从日志派生，不单独保存；
- Replay 本质上是基于同一批事件重新投影。
其数据关系可以表示为：
Session Event Log
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Model Context Web UI Telemetry
│
├── Resume
├── Replay
├── Fork
├── Search
└── Audit这意味着聊天记录不再是系统全部状态，模型上下文也不再承担数据库职责。
5.1 Model-visible means logged
DeepSeek Harness 还定义了一条重要约束：
Model-visible means logged。
凡是真正进入模型请求的信息，都必须能够从日志中重建。
Session 中的 request/header 会记录模型调用配置、渲染后的 System Prompt 和组装完成的 Tool Schema；模型历史则从 Session Surface 派生。这样，模型的某一次决策就不再是无法复现的黑盒输入。
当第 40 次模型请求出现异常时，系统可以尝试回答：
模型当时使用了哪个 Provider 和 Model？
System Prompt 是什么？
当时暴露了哪些工具？
哪些历史已经被压缩？
工具之前返回了什么结果？对于 Agent 调试而言，这相当于为模型调用建立了可重建的执行轨迹。
5.2 Context 与 State 的分离
DeepSeek Harness 明确区分：
Context：当前模型能够看到什么
State：系统历史上实际发生过什么假设完整事件历史为：
E1 E2 E3 ... E1000当前模型上下文可能只包含：
Summary(E1-E900)
E901
E902
...
E1000原始事件仍然保存在 Session Log 中；模型看到的只是由 Context Policy 生成的当前投影。
因此，更准确的关系是：
Persistent Event Log
↓
Context Projection
↓
Model-visible Surface这一分离是实现上下文压缩、会话恢复、轨迹回放和独立审计的基础。
六、上下文压缩：重写模型可见 Surface，而不是删除历史
DeepSeek Harness 将 Compaction 设计成独立能力，而不是 Agent Loop 中不可替换的固定逻辑。
压缩过程会选择一段当前可见历史，生成摘要，再通过 Surface Replacement 将原有区间替换为摘要节点。压缩的生命周期、选中范围、被遮蔽事件、Token 估算和模型调用信息仍然记录在 Session Log 中。
其效果可以表示为：
持久日志：
原始消息
工具结果
压缩开始事件
压缩摘要事件
压缩结束事件
摘要对应的 Surface Replacement
模型当前看到：
摘要
最近消息
最近工具结果这种设计的优势在于：
- 模型输入能够被压缩；
- 原始执行事实不会被物理删除；
- 后续仍可进行回放与审计；
- 压缩行为本身也能被追踪。
但需要注意，摘要模型可能遗漏关键约束。因此，长期规则不应只存在于普通对话历史中。
例如：
禁止操作生产环境
禁止提交密钥
公共 API 不允许改变
必须兼容指定运行时版本这些规则更适合进入固定 System Prompt、Policy、仓库级规则文件或其他每轮都会重新注入的外部状态。
七、工具系统：能力、可见性和执行权限是三个不同问题
模型无法直接感知宿主环境。对模型而言，Tool Schema 定义了它可选择的行动空间。
DeepSeek Harness 在工具系统中做了几项关键拆分。
7.1 模型可见 Schema 与运行时实现分离
一个注册工具不仅包含名称、描述和参数，还包含执行函数、输出契约、超时、并发属性和 UI 展示逻辑。
但这些字段并不会全部发送给模型。
工具注册表只通过显式白名单构建模型可见的 ToolSchema[]。执行函数、超时、并发安全属性、结果展示逻辑等运行时字段不会泄漏到模型请求中。
可以表示为：
ToolDefinition
│
├── Model-facing Schema
│ ├── name
│ ├── description
│ └── parameters
│
└── Runtime-only Contract
├── execute
├── output validation
├── timeout
├── concurrency policy
└── UI presentation7.2 Tool Restriction
系统注册了一个工具，不代表所有 Agent 都应该看到它。
DeepSeek Harness 支持在不同 Scope 上设置 allow 与 deny，从继承工具中筛选当前 Agent 可见能力。
因此，需要区分：
Capability
≠
Visibility
≠
Authorization即：
- 系统是否拥有某项能力；
- 当前 Agent 是否能看到该能力；
- 当前调用是否最终被允许执行。
这三者不应被合并为一个开关。
7.3 Guarded Execution Pipeline
工具执行经过一条可扩展流水线：
tools/pre-execute
↓
Monotonic Guards
↓
tools/execute
↓
tools/post-execute
↓
finalizeContent
↓
tools/resultpre-execute 可以返回：
allow
deny
askMonotonic Guard 则只能继续拒绝调用，不能把此前已经拒绝的操作重新变成允许。这样可以避免插件执行顺序导致安全决策被后续组件覆盖。
这是一个较为成熟的“失败关闭”设计。
八、Code Mode：让模型生成编排程序，而不是逐步调用工具
Standard Tool Calling 通常需要模型在每次工具调用后重新参与：
LLM
↓
搜索
↓
LLM
↓
读取文件
↓
LLM
↓
修改文件
↓
LLM
↓
运行测试Code Mode 则允许模型生成一段 TypeScript 程序，在程序中组合多步工具调用：
LLM
↓
TypeScript orchestration program
↓
搜索 → 过滤 → 读取 → 修改 → 验证
↓
返回结果这可以减少模型与 Harness 之间的往返，并把确定性的流程控制交给程序。官方将其定位为：在 Standard 能力基础上，通过 Code Mode SDK 让模型在一个 TypeScript 程序中组合多步操作。
但 Code Mode 同时提高了风险密度。
普通工具调用可能只产生一个副作用，而一段编排程序可能在一次模型响应中发起大量操作。因此，以下机制会变得更加重要：
- 单次调用预算；
- 子调用数量上限；
- 取消信号传播；
- 工具权限；
- 沙箱；
- 审计；
- 幂等与补偿机制。
尤其是涉及支付、部署、消息发送或数据库变更的工具时，Harness 仍不能替代业务系统自身的事务语义。
retry ≠ repeat如果调用结果因网络异常未知，简单重试可能产生重复副作用。因此生产工具仍应支持 Idempotency Key、Transaction ID、去重和补偿操作。
九、Goal、Ralph、Workflow 与 Jobs：四类不同的长程执行机制
DeepSeek Harness 没有试图用一个统一 Loop 解决全部长任务问题，而是提供了不同层次的编排原语。
9.1 Goal：同一 Session 内持续推进
Goal 面向同会话目标。
它将目标状态持久化到 Session Event Log，并提供以下阶段：
active
paused
blocked
completeGoal 还记录修订版本、已开始轮次和最大轮次限制。其核心特征是保留当前 Session 和已有上下文。
适合场景：
- 任务依赖连续对话；
- 当前推理过程具有较强上下文相关性；
- 不希望每轮重新交接背景。
主要风险：
- 上下文持续增长；
- 早期错误假设可能被长期保留；
- 历史噪声会影响后续决策。
9.2 Ralph：Fresh Agent 顺序接力
Ralph 采用不同策略。
每一轮都会启动新的子 Agent，新 Agent 不继承父会话或上一轮子 Agent 的完整对话历史，而是接收：
- 不可变目标；
- 当前轮次与轮次上限；
- 共享工作区是权威状态的规则；
- 上一轮结构化 Handoff。
官方明确将共享工作区视为长期记忆，父会话和先前子 Agent 的对话不会被用作新一轮上下文种子。
可以表示为：
Immutable Objective
│
▼
Fresh Agent 1
│
Structured Handoff
▼
Fresh Agent 2
│
Structured Handoff
▼
Fresh Agent 3Ralph 可视为一种周期性上下文重置机制。
它主动舍弃临时推理、失败尝试和过时假设，只保留已经写入工作区的事实和结构化交接信息。
其代价也很明确：
没有被写入工作区或 Handoff 的信息，将不会自然传递给下一轮。
9.3 Workflow：模型生成多 Agent 编排脚本
Workflow 允许 Agent 运行由模型生成的编排脚本，并由脚本启动多个 Subagent。当前官方 Provider 基于 Node.js Worker Thread，每个 Workflow Run 使用独立 Worker，并在其中运行脚本上下文。
Workflow 适合处理：
- 多阶段任务；
- 并行调研；
- 多 Agent 分工；
- Pipeline 式执行；
- 动态任务编排。
需要强调的是，Worker Thread 主要解决执行生命周期、终止和隔离事件循环问题。从安全边界角度看，它仍应与文件系统 Sandbox、网络限制和权限策略分开理解。
9.4 Jobs：后台任务生命周期
Jobs 子系统负责管理后台工作的身份、所有权和生命周期。
当前状态包括：
running
stopping
completed
killed
failedProducer 管理具体执行资源，Job Runtime 负责身份、访问、取消、等待和状态投影。
这表明 DeepSeek Harness 已经超出普通 Agent Loop 的范围，开始具备真正运行时的特征：
- 前台模型回合；
- 后台进程；
- 子 Agent；
- 多 Agent Workflow；
- 取消；
- 资源回收；
- 所有权控制；
- 状态查询。
十、权限体系：Prompt 约束与运行时权限必须分离
在 System Prompt 中写：
不要删除生产数据库。只能形成模型行为指导，不能构成可靠的安全边界。
真正的权限控制应该发生在模型之外：
模型请求危险操作
↓
Tool Policy / Approval / Sandbox / IAM
↓
允许或拒绝DeepSeek Harness 将工具策略、Approval 和 Sandbox 拆分为不同机制。
10.1 Sandbox
当前 SandboxMode 包括：
read-only
workspace-write
danger-full-access本地 Provider 根据平台使用 Linux bwrap/Landlock、macOS Seatbelt 和 Windows ACL/受限令牌等技术。
但官方文档特别指出：
当前 SandboxMode 只描述文件系统影响，网络访问与进程可见性不在该抽象的保证范围内。
因此：
workspace-write并不等价于：
Agent 已被完整隔离它无法自动解决：
- 网络数据外泄；
- 已登录 CLI 的权限滥用；
- 云凭证访问；
- 外部 API 高风险调用；
- 多租户隔离；
- Secret 泄漏。
此外，Sandbox 会明确报告 full 或 partial enforcement。要求强隔离的调用方不应把 partial 视为完整保证；如果需要受限执行但后端不可用，系统也不允许静默退化为不受限执行。
10.2 Approval
Approval 当前支持：
ask
never其中：
ask：将请求交给交互式 Answerer；never：不向任何人询问，所有需要授权的操作直接拒绝。
never 并不表示自动批准，而是适用于 CI 或无人值守环境的确定性拒绝策略。缺少有效 Answerer 时，系统同样采用失败关闭。授权请求和结果会进入 Session 审计事件。
10.3 生产环境所需的安全纵深
对于企业级 Agent，完整权限体系通常还需要：
Tool Restriction
+
Filesystem Sandbox
+
Network Egress Gateway
+
Short-lived Credential Broker
+
API Capability Allowlist
+
Human Approval
+
Secret Redaction
+
Audit Log尤其需要防范“不可信内容影响高权限执行决策”的问题。
当 Agent 同时具备网页读取、文件访问和 Shell 执行能力时，外部页面、Issue、文档或日志都可能成为 Prompt Injection 的载体。
因此，生产安全模型应区分：
Trusted Instructions
Untrusted Content
Sensitive Data
Privileged Tools十一、完成验证：Stop、Done 与 Verified 必须分离
Agent 系统最常见的错误之一，是把模型停止执行视为任务完成。
实际上，任务结束至少包含三个不同层次：
Stop ≠ Done ≠ VerifiedStop
Agent Loop 已经停止。
可能原因包括：
- 模型没有继续调用工具；
- 达到轮次限制；
- 用户取消；
- 请求失败；
- 上下文溢出；
- 资源预算耗尽。
Done
执行 Agent 声称目标已经完成。
例如：
功能已经实现，相关问题已经修复。这只是执行者声明。
Verified
独立机制根据验收条件和可检查证据确认结果成立。
例如，一个修复登录流程的任务，验收证据可能包括：
回归测试通过
全量测试通过
Lint 通过
应用成功启动
浏览器登录流程成功
Session 正确创建
公共 API 未发生非预期变化理想的闭环应当是：
Agent 声称完成
│
▼
收集执行证据
│
├── Test
├── Build
├── Lint
├── Runtime Probe
├── Browser Interaction
└── Screenshot / Trace
│
▼
Independent Verifier
│
▼
Verified / Continue / Blocked11.1 DeepSeek Harness 当前的验证边界
Ralph Report 中包含：
continue
complete
blocked以及 summary、evidence、next steps 和 blocker 等字段。
但官方文档明确说明，complete 和 blocked 是 Worker Report，并不是独立认证；当前没有独立 Evaluator 或 Verifier 判断目标是否实际完成。
这意味着：
Worker：测试已经通过。不能自动等价于：
Verifier：我独立执行了测试，并确认结果通过。因此，DeepSeek Harness 当前的执行与恢复基础设施，明显走在 Completion Assurance 之前。
这也是其现阶段最重要的架构缺口之一。
十二、资源预算：轮次上限不等于成本控制
Goal 与 Ralph 都提供轮次限制，但轮次数量不能完整代表实际资源消耗。
一次 Round 可能只包含一次小模型请求，也可能包含：
- 多次大型模型调用；
- 多个子 Agent；
- 大量工具操作；
- 长时间构建任务；
- 高额 Token 成本。
Ralph 当前明确将 Token、费用与实际运行时间预算列为延后工作，聚合工作量主要依赖 Round 数量限制。
生产级长任务通常还需要：
maxRounds
maxModelCalls
maxInputTokens
maxOutputTokens
maxToolCalls
maxSubagents
maxWallClockTime
maxProcessTime
maxNetworkRequests
maxDollarCost如果缺少这些硬预算，无人值守任务仍可能在合法轮次范围内产生不可接受的成本。
十三、架构成熟度与实证成熟度需要分开评价
DeepSeek Harness 的架构具有较强完整性：
- Cordis 插件系统；
- Event-sourced Session；
- Context Projection；
- Guarded Tool Pipeline；
- Goal 与 Ralph；
- Workflow 与 Jobs；
- Sandbox 与 Approval；
- Crash Recovery。
但架构完整并不自动意味着任务成功率已经得到充分证明。
当前仓库中的 BENCHMARK.md 主要说明如何使用 Python SDK 运行 Minimal Variant，并未在该文件中提供完整的对比结果、成功率分布或长期可靠性数据。
因此，不能直接从：
架构设计先进推导出：
任务执行一定更可靠评估 Agent Harness 还需要观察：
- 多次运行成功率；
- 最差运行表现；
- 失败类型分布；
- 崩溃恢复成功率；
- Token 与费用；
- 长尾错误；
- 版本升级后的回归情况；
- 高风险副作用发生率。
对于生产 Agent，平均成功率往往不如 Tail Risk 重要。
十四、DeepSeek Harness 的八层能力模型
综合当前设计，可以将 DeepSeek Harness 拆分为八个工程层次：
| 层级 | 核心问题 | 对应能力 |
| Execution | Agent 如何执行 | Loop、Turn、Step |
| Orchestration | 多轮与多 Agent 如何协作 | Goal、Ralph、Workflow、Subagent、Jobs |
| Capability | Agent 能够调用什么 | Tools、Skills、Code Mode |
| Context | 当前模型看到什么 | System Prompt、Context Injection、Compaction |
| State | 系统历史发生了什么 | Session Event Log、Persistence |
| Permission | Agent 实际允许做什么 | Tool Restriction、Guard、Approval、Sandbox |
| Verification | 如何证明任务完成 | Test、Build、Verifier、Review |
| Operations | 如何调试与运营 | Replay、Fork、Search、Trajectory、Telemetry |
从这一模型看，DeepSeek Harness 当前表现最突出的部分是：
- 插件化和可替换能力；
- 事件溯源状态模型；
- Context 与 Persistent State 分离；
- 工具执行流水线；
- 长程任务与多 Agent 编排；
- 崩溃恢复和轨迹重建。
相对薄弱的部分包括：
- 独立完成认证；
- Token、费用和实际耗时预算；
- 网络与凭证安全；
- 外部副作用的通用事务语义；
- 公开且系统化的可靠性评测；
- Developer Preview 阶段的 API 稳定性。
十五、生产化采用建议
DeepSeek Harness 比较适合以下场景：
- 构建自定义 Coding Agent；
- 搭建企业内部 Agent 平台；
- 研究长程 Agent 与上下文压缩；
- 设计多 Agent Workflow；
- 需要会话恢复、回放与审计的系统；
- 需要替换模型、工具、存储或沙箱实现的项目。
对于简单的一次性工具调用、短对话或低风险自动化任务，完整 Harness 可能带来不必要的架构复杂度。
如果基于 DeepSeek Harness 构建生产系统，建议额外补充以下组件：
DeepSeek Harness
│
├── Acceptance Criteria Engine
├── Deterministic Verifier
├── Hard Cost / Time Budget
├── Network Egress Gateway
├── Short-lived Credential Broker
├── Secret Redaction
└── Idempotent Transaction Layer其中优先级最高的是：
1. 验收标准引擎
在执行前将目标转化为结构化验收条件。
2. 确定性验证器
优先使用测试、构建、静态分析、文件状态和运行探针，而不是只使用另一个模型进行判断。
3. 强制资源预算
同时限制轮次、Token、费用、实际时间、工具调用和子 Agent 数量。
4. 网络与凭证隔离
文件系统 Sandbox 之外，还需限制网络出口和凭证作用域。
5. 外部操作幂等机制
所有高风险工具都应具备可重试、可查询和可补偿的事务契约。
十六、总结
DeepSeek Harness 的核心价值，不是为大模型增加更多工具，而是尝试把 Agent 从一个基于对话的工具调用程序，提升为一个具备明确运行时结构的系统。
它所推动的架构变化可以概括为：
Prompt + LLM + Tools升级为：
Model
+
Execution Runtime
+
Persistent State
+
Capability Control
+
Permission Boundary
+
Orchestration
+
Observability
+
Verification其最值得关注的设计包括：
- Everything is a Plugin；
- Cordis 插件化组合；
- Session Event Sourcing；
- Model-visible means logged；
- Context 与 State 分离；
- Tool Schema 与运行时实现分离；
- Goal 与 Ralph 两类长任务策略；
- Workflow 与 Jobs 编排能力；
- Sandbox、Approval 与 Tool Guard 分层；
- 崩溃后的中断轮次恢复。
与此同时，DeepSeek Harness 仍处于快速演进阶段。独立完成验证、聚合资源预算、网络和凭证安全，以及公开的长期可靠性评测，仍是其进一步生产化需要解决的问题。
因此，对 DeepSeek Harness 更准确的评价是：
它是一个具有较高架构价值的 Agent Runtime 项目。其插件系统、事件溯源、上下文投影、工具策略和长程任务机制，为构建可恢复、可审计的 Agent 提供了扎实基础；但“Agent 能持续运行”与“系统能证明任务正确完成”之间，仍存在必须由验证、安全和预算机制补齐的工程距离。
设计 Agent Harness 的目标，并不是假设模型将永远正确，而是确保：
即使模型会遗忘、误判或失败，系统仍然能够限制其行动、保存执行事实、恢复任务状态，并通过可检查证据完成最终验收。
欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。
更多推荐
7
0- 0
已为社区贡献2条内容
所有评论(0)