DeepSeek Harness 架构与实现深度解析

在大语言模型 Agent 的实际落地中，任务执行的可靠性、可追溯性与可扩展性，往往不取决于模型本身的推理能力，而取决于承载模型的运行框架。​

​

✍️

大语言模型的核心能力是接收输入并生成文本响应或工具调用意图，而上下文准备、工具调度、动作执行、状态持久化、异常处理等环节，均由模型外部的管控程序完成，这类程序被定义为 Harness（管控框架）。​

​

DeepSeek 在官方技术文档中提出了 Agent 的构成公式：​

​

Agent = Model + Harness​

​

​

​

​

👀

若将 Agent 视为数字员工，模型对应其决策与认知能力，Harness 则对应完整的生产办公体系，包括计算环境、工具集、存储系统、操作规范、权限体系、流程管控与审计日志。运行环境的配置差异，会直接决定 Agent 的能力边界：基础环境仅支持对话式问答；完备环境则可实现数据库访问、代码执行、任务分派与跨会话进度延续。​

​

DeepSeek Harness 正是针对 Agent 运行环境设计的开源框架，其核心设计思路是将 Agent 的所有运行能力拆解为可替换组件，并对 Agent 的感知信息与执行动作实现全链路可追溯。​

​

🎯

核心公式：Agent = Model + Harness​

模型负责认知决策与意图生成，Harness 负责上下文组装、工具调度、动作执行、状态持久化与异常处理，是 Agent 可靠落地的关键所在。​

​

​

一、Harness 的核心定位：模型与执行环境的解耦层​

对话交互形态容易形成“模型直接操作外部环境”的认知偏差。事实上，大语言模型并不具备直接访问浏览器、文件系统或终端的能力，其输出仅为结构化的工具调用意图，例如指定工具名称与对应参数的指令。​

​

👍

Harness 作为模型与执行环境之间的中间层，负责接收工具调用意图并完成全链路执行，标准流程包含：工具可用性校验、Agent 操作权限核验、参数格式合法性验证、底层系统调用执行、返回结果的标准化转换、结果注入下一轮模型上下文。​

​

复杂任务的执行过程，正是“模型生成意图—Harness 执行并返回结果—模型生成下一步意图”的循环迭代，单次任务可包含数十次该循环。​

​

​

完整的 Harness 体系覆盖模型适配、工具管理、会话管理、执行循环、安全管控、状态持久化等多个层级。​

模型厂商通常公开的参数量、推理精度与基准测试成绩仅代表模型自身能力，而 Agent 的实际落地效果，受 Harness 各层级实现质量的共同影响。​

Harness 的核心价值，是将模型的认知输出转化为可管控、可追溯、可持续的自动化行动。​

​

二、DeepSeek Harness：一体化的 Agent 运行与开发框架​

DeepSeek Harness 是 DeepSeek 开源的 Agent 管控框架，官方定位为集 Coding Agent 运行环境与 Agent 开发框架于一体的基础组件。该项目目前处于开发者预览阶段，官方明确提示后续版本可能引入不兼容变更。​

​

​

对于终端用户，DeepSeek Harness 可直接作为具备文件读写、信息检索、命令执行能力的可定制化 Agent 使用；对于开发者，其提供了一整套可扩展的 Agent 组装体系，支持通过插件化方式灵活配置 Agent 的能力边界与运行逻辑。​

​

三、DeepSeek Harness 的启动机制：插件化配置组装体系​

DeepSeek Harness 的核心设计原则为 Everything is a Plugin，即所有能力均以插件形式提供。​

​

👍

该设计并非仅指支持功能扩展，而是将模型适配器、工具注册表、会话日志、Agent 执行循环、存储系统、沙箱环境、调度器与交互界面等所有核心组件，全部抽象为插件实现。​

​

框架不存在不可扩展的“特权核心”，开发者可通过配置替换任意组件的实现，无需 Fork 主仓库修改底层代码。​

DeepSeek Harness 通过三层配置体系实现 Agent 的灵活组装，分别为 Profile、Bundle 与 Patch。​

Profile：Agent 的完整配置模板​

​

💙

Profile 定义了 Agent 的完整运行配置，决定了 Agent 实例的能力边界与运行模式。​

​

其包含模型选型、可用工具集、会话存储路径、交互界面类型、安全规则等全维度配置，相当于 Agent 的“工位配置清单”。​

DeepSeek Harness 内置 web 与 headless 等典型 Profile。web 模式启动时附带浏览器交互界面，适用于人工监控与交互式操作场景；headless 模式无图形界面，接收任务后自动执行、保存结果并退出，适用于脚本化调用与自动化流程。​

Bundle：可复用的功能插件组​

​

💙

Bundle 是一组关联插件的打包集合，用于实现特定领域的能力复用。​

​

其将一组配套的配置项与对应实现封装为独立功能包，避免重复配置多个插件。​

例如，研究场景 Bundle 可集成网页检索、文件处理、引用校验与研究提示词等插件；代码审查 Bundle 可集成代码读取、自动化测试与审查规则插件。创建新 Agent 时，可直接在配置中引用对应 Bundle，无需逐个配置底层插件。单个 Profile 支持叠加多个 Bundle，实现能力的模块化组合。​

Patch：配置的局部增量修改​

​

💙

Patch 用于实现配置的局部调整，解决全量复制 Profile 带来的维护成本高、难以跟进上游更新的问题。​

​

Patch 仅记录与基础配置的差异项，可实现模型替换、工具禁用、路径权限新增等局部修改，也支持插入新插件以扩展临时能力。​

​

👍

DeepSeek Harness 采用分层叠加的配置生效机制，优先级从低到高依次为：基础 Profile、Bundle 配置、用户级 Patch、命令行临时参数。上层配置与下层配置冲突时，以上层为准；未冲突的配置项则继承保留。该机制类似分层透明胶片的叠加效果，底层保留完整配置，上层仅覆盖差异部分。​

​

​

​

框架支持配置的热更新：用户修改配置文件后，系统自动计算受影响的插件集合，并通过 Cordis 完成插件的动态重组。该过程仅调整关联组件，无需重启整个 Agent 实例。​

完整的启动流程可概括为：​

​

代码块​

JavaScript

读取 Profile​

↓​

按顺序叠加 Bundles​

↓​

​

​

​

需要注意的是，配置文件的书写顺序不等于插件的实际加载顺序。插件会声明自身依赖的服务，Cordis 会等待所有依赖项就绪后再加载对应插件。若依赖的服务被卸载，关联插件会自动卸载以避免功能失效；服务恢复后，插件自动重新加载，实现组件的动态可用性管控。​

​

💡

三层配置体系（优先级从低到高）​

Profile（完整模板）→ Bundle（功能插件组）→ Patch（局部增量）→ 命令行临时参数。上层覆盖下层差异，未冲突项继承保留，支持热更新无需重启。​

​

​

四、Cordis 插件管理：面向时空可组合性的生命周期管控​

DeepSeek Harness 通过 Cordis 组件实现插件的全生命周期管理，其核心设计目标是实现 时空可组合性（Spatiotemporal Composability），包含空间与时间两个维度。​

​

​

空间可组合性：基于依赖的服务解耦​

空间可组合性指插件间的依赖关系由框架统一管理，插件仅声明自身所需的服务类型，不绑定具体的服务实现。例如网页研究插件仅需声明依赖模型服务、搜索服务与工具注册表，无需指定具体的模型厂商或搜索实现。​

该设计实现了能力与实现的解耦，服务的替换不会影响上层插件的运行，类似电器与供电网络的关系：电器仅要求标准电压输入，不关心电力的具体来源。​

时间可组合性：插件卸载的全量清理​

时间可组合性指插件卸载时，其运行过程中产生的所有变更都将被完整撤销，避免残留状态影响系统稳定性。插件运行过程中通常会产生多类副作用：注册工具定义、追加系统提示词片段、注册事件监听器、启动定时器与文件监听器、建立网络连接、挂载子插件等。​

​

👍

传统插件系统普遍存在卸载不彻底的问题：插件移除后，旧的事件监听器、状态数据仍保留在进程中，导致热更新后回调重复执行、旧提示词持续影响模型输出等异常。​

​

​

Cordis 通过 Fiber 生命周期容器 管理每个插件实例，插件的完整生命周期包含 PENDING、LOADING、ACTIVE、UNLOADING、DISPOSED 五个状态，同时支持 FAILED 异常状态分支。Fiber 是 Cordis 对插件实例的运行时抽象，负责追踪插件的依赖关系、运行状态与清理动作。​

​

插件通过 ctx.on() 注册事件、通过 ctx.tools.register() 注册工具时，所有注册信息都会记录在所属的 Fiber 下。插件卸载时，Cordis 自动移除所有注册项。对于插件自行创建的定时器、网络连接等资源，插件可通过 ctx.effect() 返回清理函数，Cordis 在卸载阶段自动调用该函数完成资源释放。​

​

此处的 Effect 指插件对外部环境产生的所有变更，包括工具注册、事件订阅、连接建立等。Cordis 要求插件的所有 Effect 都具备对应的撤销逻辑，确保插件卸载后系统恢复到加载前的状态，类似展会结束后展台、灯光、线路的完整拆除。​

​

插件的子插件会跟随父插件递归卸载，所有异步清理动作完成后，插件才会进入 DISPOSED 状态。该机制同时支持热模块替换：系统先卸载旧插件并清理所有副作用，再加载新版本插件，实现无重启的组件更新。​

​

🔄

时空可组合性（Spatiotemporal Composability）​

空间维度：插件仅声明所需服务类型，不绑定具体实现，服务替换不影响上层运行。​

时间维度：插件卸载时所有副作用完整撤销，Fiber 容器追踪依赖关系与清理动作，支持热模块替换。​

​

​

​

​

五、任务执行流程：基于 Turn 与 Step 的双层执行循环​

DeepSeek Harness 通过 Agent Loop 驱动任务的完整执行，核心包含 Turn 与 Step 两层执行粒度。​

•

Turn 对应 Agent 的一轮完整任务，从接收用户任务指令开始，到任务完成、终止或失败时结束。例如“读取销售数据并生成分析报告”即为一个 Turn。​

•

Step 对应单次模型请求及其触发的工具执行过程。模型首次读取目录是一个 Step；读取文件后再次调用模型判断下一步，是第二个 Step。单个 Turn 通常包含多个 Step 的迭代。​

​

​

以“读取 sales.csv 计算增长率并写入 report.md”为例，标准执行流程如下：​

​

代码块​

JavaScript

用户消息进入 Inbox​

​

执行流程中包含三类关键机制：​

统一输入收件箱（Inbox）​

用户指令、任务补充信息、插件注入的上下文均通过 Inbox 统一接收。部分消息会立即唤醒 Agent 执行，部分上下文会等待下一个 Step 再被读取。该设计支持任务执行过程中的动态指令追加，无需为不同类型的外部输入设计独立通道。​

​

​

前置检查节点（agent/pre-step）​

在调用模型之前，插件可对当前输入进行补充、重写或拦截，上下文压缩、运行时状态注入、策略校验等逻辑均可接入该节点。即使输入被拦截，系统仍会记录该任务的尝试记录，保证审计链路的完整性。​

可替换的执行循环​

Agent Loop 仅为默认实现，核心 Agent 包定义了公共接口，具体驱动逻辑由默认的 agent-loop 插件提供。其他插件依赖公共 Agent 接口，而非直接依赖默认循环实现。开发者可自行替换 Agent Loop 的实现，无需重构工具、会话与交互界面，是“Everything is a Plugin”设计原则在核心层的体现。​

两类事件的职责分离​

DeepSeek Harness 包含两类不同性质的事件：​

•

会话事件（Session Event）：如 turn/start、tool/call、tool/result 等，是对已发生事实的记录，会持久化到会话日志中，重启后可恢复。​

•

运行时事件（Cordis Event）：如 agent/pre-step、agent/request、tools/pre-execute 等，是运行过程中的扩展点，插件可在该节点观察、修改或拦截当前操作，本身不属于持久化记录。​

​

会话事件相当于行车记录仪，完整记录任务执行轨迹；运行时事件相当于交通管控节点，用于动态调整执行逻辑。部分运行时事件采用 Waterfall 调度机制，每个监听器通过 next() 传递控制权，不调用则可中止或替换后续结果，系统提示词组装、工具策略管控均采用该中间件架构。​

​

​

​

​

六、动态系统提示词：逐 Step 组装的上下文生成机制​

主流对话系统通常将系统提示词视为固定的长文本，DeepSeek Harness 则将其设计为动态组装系统。不同插件可贡献提示词片段，最终在每个 Step 开始前拼接为完整的系统提示词。​

​

​

插件可贡献的提示词内容包括：有序的指令片段、当前时间与工作目录等动态上下文、模型可见的工具定义（Tool Schema）、模板变量、Agent 的角色设定与行为规则。​

Tool Schema 是工具向模型提供的使用说明，包含工具名称、功能描述、参数列表与参数类型，是模型生成合法工具调用的依据。工具数量越多，单次模型请求需要读取的 Schema 内容越长，Token 消耗越高。DeepSeek Harness 支持按 Agent 配置限制模型可见的工具范围，被隐藏的工具不会占用提示词长度。​

​

👍

每个 Step 重新组装系统提示词的核心原因，是任务执行过程中运行环境处于动态变化中：模型切换、插件加载卸载、Agent 模式变更、权限策略调整、子 Agent 获取独立角色与工具范围等，都会改变提示词的组成。逐 Step 组装可保证每次模型请求都反映当前的最新环境。​

​

​

​

动态性带来了可复现性挑战：若提示词或工具集合发生变更，开发者难以还原历史请求的实际输入。为此，DeepSeek Harness 在会话中记录每次请求的请求头（request/header），保存模型提供商、模型名称、推理参数、最终系统提示词与工具 Schema 的快照。配置发生变更时，系统追加新的请求头记录，确保“模型当时接收到什么输入”可审计、可追溯。​

​

👍

该机制同时影响模型服务的 KV 缓存效率。若请求前缀未发生变化，Provider 可复用缓存减少重复计算；若插件加载、工具排序或角色设定发生变更，请求前缀改变，缓存可能从首个变化的 Token 开始失效。插件化架构提升了实验灵活性，同时也要求开发者关注其带来的延迟与调用成本。​

​

​

七、会话日志：基于事件溯源的唯一事实源​

DeepSeek Harness 的架构设计中存在一条强约束：模型可见的所有内容必须被记录。系统采用 仅追加式会话日志（Append-only Session Log） 作为唯一事实来源，记录内容包括：任务启动与结束事件、步骤启动与结束事件、用户消息与模型输出、工具调用与返回结果、控制消息与待办事项更新、每次请求的模型配置、系统提示词与工具 Schema 快照。​

该设计基于 事件溯源（Event Sourcing） 模式：系统不直接保存当前状态，而是保存所有导致状态变更的事件，当前状态可通过事件序列重新推导得到。类似银行账户不仅保存余额，还保存所有收支明细，审计人员可通过明细复算余额。​

​

👍

DeepSeek Harness 通过 deriveMessages() 从会话日志事件中推导模型下一次请求的历史上下文，无需额外维护独立的对话数组。​

​

单一日志流可同时支撑多个上层功能：​

•

任务恢复（Resume）：重新加载历史任务并继续执行；​

•

任务分支（Fork）：从历史节点创建新的任务分支；​

•

过程回放（Replay）：重放任务的完整执行过程；​

•

轨迹可视化（Trajectory）：在界面中展示任务执行路径；​

•

运行统计（Telemetry）：统计模型与工具的行为数据；​

•

持久化存储（Persistence）：将会话保存为 JSONL 或 SQLite 格式。​

该设计避免了多套历史数据各自维护导致的不一致问题，降低了数据冗余。​

​

​

​

​

48%

​

​

​

​

52%

​

​

​

针对上下文长度超限问题，DeepSeek Harness 通过 Compaction 插件实现上下文压缩。当上下文长度达到阈值时，插件生成历史摘要，并在面向模型的上下文表层（Surface）中替换早期的详细内容。原始的仅追加日志完整保留，不修改任何历史事件，实现了“原始事实完整留存、模型上下文动态优化”的分层设计。​

​

对于崩溃恢复场景，框架定义了明确的状态边界。若程序在工具调用过程中崩溃，持久化层会在恢复时补充状态标记：模型请求已发出但工具未启动时，标记为 TOOL_NOT_STARTED；工具调用已记录但无返回结果时，标记为 TOOL_OUTCOME_UNKNOWN，提醒模型避免重复执行可能产生副作用的操作。​

当前实现不支持从任务中间无缝续跑，恢复逻辑会先为未闭合的工具调用、步骤与任务补全结束记录，再从新的任务回合继续执行。​

​

📋

唯一事实源：仅追加式会话日志​

​

​

八、工具安全管线：多层校验的执行管控体系​

模型输出的工具调用不会直接作用于操作系统，DeepSeek Harness 设计了完整的工具执行管线，实现全链路的安全管控。模型发起工具调用后，系统先记录工具调用事件，再依次经过多层校验，最终执行并返回结果。​

​

​

标准工具执行管线如下：​

​

代码块​

JavaScript

​

管线包含三类核心安全设计：​

先记录后执行​

系统在执行工具调用前先写入调用日志，即使后续审批拒绝或工具执行失败，开发者仍可审计模型的操作意图，保证行为链路的完整性。​

故障关闭（Fail-closed）的审批机制​

工具审批结果包含单次放行（allowed-once）、拒绝（rejected）、取消（cancelled）与不可用（unavailable）四类，仅单次放行可放行当前操作。当审批组件缺失、报错或未返回合法结果时，系统默认判定为不可用并拒绝操作，即故障时优先保障安全。所有审批均为单次有效，仅对应当次具体请求，无永久授权。​

单向收紧的安全守卫​

工具管线中的 Monotonic Guard 仅可拒绝操作或保持沉默，无权推翻上游已做出的拒绝决定。该机制类似多道安检：后序安检可发现新问题并拦截，无权解除前序安检的禁止决定，确保安全策略只收紧不放宽。​

针对文件操作场景，框架还提供了更细粒度的检查点。文件工具在写入或编辑前会触发文件系统事件，策略插件可校验文件读取权限、路径白名单、沙箱模式限制等。安全策略直接集成在工具管线与文件能力接口中，不耦合于 Agent Loop，替换执行循环时仍可复用。​

​

💡

三重安全设计​

① 先记录后执行：操作意图必留痕，即使被拒绝也可审计。​

② 故障关闭（Fail-closed）：审批异常默认拒绝，所有审批单次有效，无永久授权。​

③ 单向收紧：后序守卫仅可新增拦截，无权解除前序禁止决定。​

​

​

九、能力接缝：实现与接口解耦的分层架构​

DeepSeek Harness 将可替换的抽象接口定义为 Capability Seam（能力接缝），实现上层工具与底层实现的解耦。一条能力接缝包含三类角色：​

服务定义（Service Definition）：定义统一的接口规范；​

服务提供者（Service Provider）：提供接口的具体实现；​

服务消费者（Consumer）：调用该能力的组件，通常为模型可见的工具。​

以文件能力为例：​

​

代码块​

JavaScript

模型看见 read / write / edit 工具​

│​

Consumer：tool-fs​

│​

Service Definition：ctx.fs​

│​

┌────────┼─────────┐​

│ │ │​

​

上层工具始终调用统一的接口，开发者替换底层服务提供者即可改变实际运行环境，无需修改工具名称与 Agent 执行逻辑。DeepSeek Harness 对模型、网页搜索、Shell、持久化、上下文压缩、子 Agent 等能力均采用该分层架构。​

​

👍

该架构在企业场景中具备显著价值：开发阶段可使用本地实现提升调试效率，部署阶段替换为权限受限的远程沙箱保障安全，Agent 的上层业务逻辑完全一致。​

​

分层架构也会带来一定的抽象成本，服务定义、提供者、消费者与策略插件需遵循统一的接口契约。对于仅需单一固定后端的小型项目，该分层架构可能增加不必要的复杂度。​

十、运行模式：同一内核的差异化能力组合​

DeepSeek Harness 提供 Standard、Code、Minimal、Creator 四种核心运行模式。四种模式并非独立的产品，而是基于同一内核，通过不同的插件组合与工具暴露方式，适配不同的使用目标。​

​

​

​

Standard Mode：完整工作台模式​

Standard Mode 提供完整的 Agent 能力，包括文件编辑、Shell 执行、信息检索、技能、计划管理、目标追踪、子 Agent 与工作流等。模型可直接看到所有工具的名称、说明与参数 Schema，按需调用对应工具，每次调用结果返回上下文后再决策下一步。​

该模式交互直观，适用于任务类型多样、需人工持续监控的编码 Agent 场景。​

Code Mode：工具编排模式​

Code Mode 不将所有工具作为独立调用暴露给模型，而是提供 run_code 统一入口，以及基于当前工具生成的 TypeScript 或 Python SDK 声明。模型可编写代码批量编排工具调用，例如并行读取多个文件、按依赖顺序执行操作等。​

中间工具结果保留在程序内部，仅模型主动返回或打印的内容会进入对话上下文，可减少批处理任务中“模型请求—工具调用—模型请求”的频繁往返，避免中间结果占用上下文长度。​

需要注意的是，Code Mode 并非在所有场景下都能节省 Token，生成的 SDK 声明本身也会占用请求长度。对于短任务、少工具的场景，普通工具调用模式可能更高效。此外，run_code 内部发起的子调用仍会经过完整的工具权限、沙箱与执行管线，并留存关联日志，安全机制不会缺失。​

​

​

Minimal Mode：评测基准模式​

Minimal Mode 仅为模型提供持久化 Shell 与文件编辑器能力，移除了技能、搜索、规划插件与复杂上下文辅助。该模式类似仅提供基础工具的考场，便于研究人员控制变量，纯粹评估模型自身的代码阅读、方案制定、测试执行与错误修复能力。​

DeepSeek 在自身的 Code Agent 评测中即采用该模式，其核心价值在于统一评测基准，而非优化日常使用体验。​

Creator Mode：框架开发模式​

Creator Mode 在 Standard Mode 能力基础上，增加了运行时检查、插件实验、配置编写指导等能力。开发者可通过 Agent 探查当前插件树结构，尝试新的组件组合，并生成对应的模式配置。​

该模式将 Harness 本身从 Agent 的幕后环境，转变为 Agent 可操作的开发对象，主要用于 Harness 自身的开发与实验。需要说明的是，相关动态工具集并未默认纳入所有发行版本，不能等同于“Agent 可无限制自我修改”。​

​

十一、子 Agent：可插拔的任务分派体系​

​

👍

复杂任务通常需要分工协作，主 Agent 可将资料检索、代码检查、测试执行等子任务分派给子 Agent 完成。​

​

DeepSeek Harness 未将子 Agent 实现为固定的内部线程，而是定义了统一的 ctx.subagents 接口，不同的服务提供者可启动不同形态的子 Agent，包括：当前进程内的新 Agent 实例、从父任务历史分支的 Fork Agent、通过 ACP 协议启动的外部 Agent、Codex 或 Claude Code 子进程、通过 SDK 启动的其他 Harness 实例。​

​

​

​

​

主 Agent 通过统一的工具集完成子任务委派、消息发送、状态查询与任务中断，底层是内部子任务还是外部产品，由服务提供者决定。​

​

🔔

对于 Fork 类型的子 Agent，仅继承父会话中已完整结束的任务回合，父 Agent 正在执行的工具调用不会被复制，避免因缺少对应结果与结束标记导致的不完整历史。​

​

Fork 机制仅传递对话历史，不继承操作权限。子 Agent 获得独立的权限作用域，不会自动继承父 Agent 的工具限制与操作授权。该设计体现了上下文继承与权限继承的分离原则：子 Agent 可了解父任务的执行背景，但不自动获得父级的操作权限。​

​

十二、典型应用场景​

截至当前，DeepSeek Harness 官方公开了可运行示例、内置工具集与实验性验证方案，以下为四类典型应用场景。​

场景一：动态工具构造​

DeepSeek Harness 最具辨识度的能力是支持 Agent 在运行过程中动态创建新工具。例如发布检查场景，团队需每次校验版本号更新、变更日志补充、测试通过状态、安装包体积异常四项内容，普通 Agent 需逐个调用工具重复执行。通过动态工具能力，Agent 可一次性创建 release_guard 工具，后续单次调用即可完成四项检查并返回统一报告。​

​

​

动态工具的创建遵循完整的插件生命周期：​

运行时检查：Agent 通过探查接口读取当前可用的服务、事件、内置能力、工具 Schema 等信息，确保接口调用准确。​

包定义：通过 cordis_define 接收模型生成的代码，校验参数与语法后生成不可变的包版本。该阶段仅定义不执行，不改变当前运行状态。​

动态工具包含三类标识：pluginId 为插件的唯一标识，packageId 为某一版本不可变的代码包，Run 为代码包的一次运行实例。版本更新时追加新版本，失败可回滚至旧版本。​

激活运行：通过 cordis_run 将指定包挂载到当前运行时，包含前端代码的包会触发用户审批，授权后正式生效。​

能力生效：插件注册的工具会触发工具 Schema 更新，下一个 Step 组装系统提示词时，新工具会出现在模型的可用工具列表中。​

​

👍

动态包不仅可注册工具，还可监听事件、提供服务、修改模型路由、向交互界面插入面板。单个包可同时包含主机侧（Host Half）与浏览器侧（Client Half）代码，两者通过私有 RPC 通信，实现后台能力与前端界面的同步扩展。​

​

若实验失败，cordis_stop 可停止当前运行实例但保留插件定义，cordis_undefine 则删除插件定义。所有由插件产生的工具、监听器与其他副作用均由 Cordis 生命周期统一清理。​

​

​

需要注意的是，临时插件仅存在于进程内存中，卸载或重启后消失，且可能影响同一进程内的其他会话。动态代码可访问完整的 Harness 服务，信任级别与 Shell 相当，属于高权限开发能力，需主动启用。​

​

场景二：多 Agent 流水线​

对于批量任务场景，例如百份源码文件审查且高风险结论需二次复核，可通过工作流（Workflow）工具实现多 Agent 流水线编排。模型编写 JavaScript 编排脚本，实现任务的批量分派、分级处理与结果汇总。​

​

🔔

工作流脚本支持的核心能力包括：agent() 启动子 Agent 并要求按指定格式返回结构化结果；pipeline() 实现对象的多级流式处理；parallel() 并行启动一组任务并统一等待；phase() 与 log() 标记阶段并上报进度；provider 与 model 为不同子任务指定不同的模型路线。​

​

工作流脚本本身无文件、网络、定时器等系统访问权限，仅负责任务调度，实际操作由子 Agent 执行，并发数与 Agent 总数受配置上限约束。​

​

​

结合不同的子 Agent 提供者，可组合出多角色协作场景：主 Agent 负责任务拆分，Codex 负责实现逻辑检查，Claude Code 负责架构评审，Fork Agent 负责对齐用户意图，最终由主 Agent 汇总结果。该架构支持灵活的角色组合，适配不同的业务需求。​

场景三：定时提醒与跨会话记忆​

通过 schedule 配置层（Overlay），Agent 可获得定时提醒能力，支持延后时长、指定时间、固定间隔三种定时方式。定时任务到期后，框架会在原会话空闲时插入跟进任务回合。提醒记录隶属于原会话，进程关闭或会话冷态时计时器暂停，重新打开会话后恢复并处理逾期提醒。​

​

👍

该能力仅针对当前会话生效，不支持系统级通知、邮件或短信推送，也不支持 Cron 表达式，适用于项目内的临时定时备忘。​

​

跨会话记忆能力通过 MCP 协议对接外部记忆系统实现。框架支持启动或连接第三方 MCP 服务器，发现并暴露对应工具，数据库初始化、模型选型与数据迁移由外部记忆系统负责。该能力可用于保存架构决策、项目术语、已核实事实等，供后续会话主动查询，是框架对外部能力的集成，而非内置的永久记忆功能。​

场景四：自动化集成​

Headless 模式支持命令行直接调用，接收任务后创建会话、执行、保存结果并退出，可集成到 CI 脚本、Git Hook 等自动化流程中，作为一次性任务执行器使用。​

对于 Python 服务集成，官方提供 JSON-RPC SDK，支持通过 Python 代码驱动无人值守的编码 Agent，捆绑运行时包含所有依赖插件，目标机器无需额外安装 Node.js。​

对于需要多会话管理、动态权限控制的场景，官方提供 ACP 协议实现，通过 JSON-RPC 标准输入输出与 Agent 进程通信，每个会话指定独立工作目录，权限审批交由客户端决定，无响应时默认拒绝。​

​

👍

三种集成方式的定位分别为：Headless 适用于单任务一次性执行；JSON-RPC SDK 适用于程序内 Agent 生命周期管理；ACP 适用于将 Agent 作为可被上层系统驱动的服务进程。​

​

此外，官方提供远程沙箱的 POC 实现，替换本地文件系统与子进程提供者，将所有操作转移至远程沙箱执行，上层工具接口保持不变，验证了能力接缝架构的实际价值。​

​

十三、技术创新与行业价值​

插件体系、MCP 协议、技能系统、钩子机制、子 Agent、权限管控、检查点与回放等能力在业界均已有相关实现。Claude Code 支持技能、Agent、钩子、MCP 与 LSP 的打包集成，LangGraph 提供了持久化与基于检查点的任务恢复能力。DeepSeek Harness 的核心价值在于其独特的组合方式与系统边界设计，主要贡献体现在三个方面。​

第一，将插件化边界延伸至 Agent 核心运行结构。开发者不仅可扩展工具能力，还可配置 Agent 的执行循环、历史存储机制、运行环境与交互界面，实现全栈的可定制化。​

第二，在同一系统中实现了可组合性与可追溯性的统一。Cordis 负责组件的加载、依赖管理与卸载清理，解决能力的动态组合问题；会话日志基于事件溯源保存完整运行事实，解决过程的可追溯与可恢复问题。两者通过 Agent Loop 衔接，形成完整的闭环。​

第三，将插件框架本身转变为 Agent 可操作的对象。动态代码执行并非新技术，但将运行时接口探查、不可变版本管理、审批流程、请求头变更记录、回滚机制与生命周期清理整合到同一条链路，形成了完整的动态能力体系。该能力仍属于高权限实验特性，但相比泛化的“AI 自编写插件”概念，具备更明确的实现路径与安全边界。​

DeepSeek Harness 是一套具备清晰设计主张的 Agent 管控架构，其能否成为行业标准，取决于 API 稳定性、插件生态质量、调试体验与生产环境负载能力等多维度的长期验证。​

​

结语​

DeepSeek Harness 将 Agent 体系拆解为模型与管控框架两个核心层级：模型负责认知决策与意图生成，管控框架负责上下文组装、工具审核执行、结果回传与全链路事件记录。​

从架构设计看，Cordis 插件管理与会话日志是框架的两条核心主线：前者负责组件的装载、依赖与撤销，实现能力的动态组合；后者负责运行历史的记录、推导与恢复，实现过程的可追溯。Agent Loop 将两者串联，每个 Step 都基于当前插件环境与历史事件生成下一次模型请求。​

从落地形态看，该框架支持动态工具扩展、多 Agent 流水线编排、自动化流程集成等多种应用模式，可适配从交互式开发到无人值守自动化的广泛场景。​

当前该框架仍处于快速迭代阶段，距离成熟的通用基础设施尚有发展空间。但其提出的设计理念为 Agent 技术的评测提供了新的视角：评估 Agent 能力时，不仅需要关注所使用的模型，还需要考察其可用工具集、运行的管控框架、以及失败场景下的过程可还原性。​

​

💡

两条核心主线​

Cordis 插件管理实现能力的动态组合，会话日志实现过程的可追溯，Agent Loop 将两者串联。评估 Agent 能力时，不能只看模型，还需考察工具集、管控框架与失败场景下的过程可还原性。​

​