JaydenAI的博客

[DeepSeek Harness深度拆解-18:DSH配置服务设计详解]对以抽象类SettingsProvider为核心的配置系统的设计进行了系统介绍，并在此基础上提供了[基于内存字典作为数据源的实现]。DSH默认使用的配置系统是通过`FileSettingsProvider`实现的（对应的包为`@deepseek-ai/dsh-settings-file`）,本篇文章将系统介绍背后的设计和实现原理。

围绕着SettingsProvider对DSH的配置系统的设计进行了系统的梳理，这是我们对配置系统进行定制的基础。在这篇文章中，我么将通过继承这个抽象的SettingsProvider，提供一个简单的将内存字典作为数据源的配置系统。

[DeepSeek Harness深度拆解-17:如何使用DSH的配置服务]从编程的角度介绍了如何在自定义的插件中使用DSH提供的配置服务，接下我们将通过这篇以及后续的几篇文章详细介绍配置服务的完整设计和实现原理。配置服务最核心的部分实现在`SettingsProvider`这个抽象类中，学习它帮助我们深刻理解DSH原生提供的基于yaml和json文件的实现。如果希望提供其他数据源的配置，就必需对这个抽象类具有深刻的理解。

`@deepseek-ai/dsh-settings`包提供`settings`服务是DSH中用于管理运行时配置的底层核心服务，专门负责系统参数的命名空间注册、分层解析、热更新持久化以及变更检测。`@deepseek-ai/dsh-settings-file`进一步提供了基于文件的配置系统，本篇文章将通过几个简单的实例来提供DSH基于配置的编程体验。

[DeepSeek Harness深度拆解-15:体验系统提示词的构建]从编程的角度利用提供的一系列实例演示如何使用`SystemPrompt`这个基础服务，这篇文章将会完整介绍该服务针对相关注册方法的处理和最终对系统提示词的组装流程。

DSH利用插件`SystemPrompt`将自己注册为服务（服务名为`systemPrompt`）来以类似于Builder模式来渲染系统提示词，我们可以将此服务作为Builder，通过提供相应配置，注册构成最终系统提示词的相关元素（`PromptSection`和`PromptContext`），并同时提供描述有序工具的Schema。本篇以实例演示的方式来介绍如何利用`SystemPrompt`来生成我们希望的系统提示词。

在[DeepSeek Harness深度拆解-12：揭秘工具完整的执行流程]我们谈到，在整个工具执行的预检阶段会利用waterfall的形式触发tools/pre-execute来收集是否允许执行目标工具的决策。事件流最终返回一个`PreToolDecision`对象，其kind字段除了返回allow和deny这两个分别表示允许和拒绝执行的选项外，还可以返回ask选项引入人工审理的流程。接下来我们提供一个简单的例子引入基于人机交互的审批流程到指定的工具执行上面。

[DeepSeek Harness深度拆解-12:揭秘工具完整的执行流程]完整介绍了作为工具运行时的ToolRuntime针对工具注册和执行的执行流程，我们了解了一系列钩子事件。充分利用这些钩子事件可以按照我们的需求干预指定工具的执行流程，本篇文章采用实例演示的方式介绍这些事件触发的时机、注册的方式以及应用的场景。

到目前为止，我们都是站在开发者的角度来探讨工具如何定义和注册，接下来我们将站在`ToolRuntime`的视角，聊聊它如何处理我们提供的工具注册，并在Agent Loop中以怎样的形式执行由LLM生成的工具调用。

本文深入解析了ToolDefinition、ToolRestriction与ToolGuard在DeepSeek Harness中的核心作用。通过defineTool函数，开发者可基于类型安全的Schema定义工具参数与输出，实现工具的注册与执行控制。ToolDefinition扩展自ToolSchema，包含执行逻辑、输出校验、结果渲染及并发安全性判断等能力；ToolRunContext提供执行上下文支持，如中止信号与上下文延展；ToolOutputDefinition则负责输出验证与内容呈现。整体设计保

工具对于Agent的作用不言而喻。虽然不同的Agent框架针对工具都不同的定义和注册方式，但是工具的大部分描述信息是为LLM提供的，因为最终决定调用哪个工具决定于LLM针对推理任务的理解和当前可用工具的描述，所以DSH针对工具的定义也不会有什么太特别的地方。如果硬要说特别的化，那就是源于DSH建立在Cordis之上，需要以插件的形式调用相应的服务来注册工具。这篇文章我们将通过一系列的实例来体现工具定义和注册的编程模式。

[DeepSeek Harness深度拆解-08]通过实例演示的方式体现了`@deepseek-ai/dsh-scope`提供的基于Scope的隔离机制。通过提供的`createScope`函数，我们可用构建一个逻辑层面的Scope树，并将节点动态绑定到Context树的某个节点上，再利用`scopeTarget`函数提供的对象作为触发事件的主体，该对象会利用提供的过滤函数让基于某个Scope发出的事件只能在限定的Scope内传播。结合使用`ScopedLayers`，我们可用实现基于Scope的可继承注册

DSH建立在Cordis之上，而Cordis应用的核心就是具有层级结构的Context树。我们可以调用`isolate`方法基于指定的Context创建一个子Context，后者利用`symbols.isolate`字典提供服务名称和实例标识的映射，进而实现基于服务注册的隔离。但是这种隔离机制对于DSH来说是远远不够的，除了这种基于Context树结构的物理隔离，我们还需要一种逻辑隔离，即在逻辑上构建一个同样具有层级结构的Scope树如，并动态地将每个Scope节点映射到对应的Context。

[DeepSeek Harness深度拆解-06:体验DSH针对LLM的动态路由]我们通过在自定义的插件中利用注册的`LlmRuntime`服务调用LLM，并通过修改作为`GenerateOptions`的方式实现针对LLM的切换，这就是DSH被称为动态LLM路由的特性，接下来我们就来介绍一下这一重要特性是如何实现的。实际上整个LLM路由就实现在`LlmRuntime`这个类型中，虽然该类型定

DSH本质是一个Agent开发框架，**Agent = LLM + Harness**，所以作为Agent大脑的LLM永远是最重要的部件。DeepSeek Harness针对LLM的设计体现在它针对LLM的动态路由上：我们可以配置针对不同厂商的不同模型，并给去提供的输入动态选择对应的LLM发起调用。接下来我们就来体现一下这个特性。

在Cordis系统中，DSH通过分层补丁文件构建插件树，其结构与运行时Context一致。EntryTree与Entry类共同表示插件树，每个Entry对应一个插件或组，通过update方法实现热重载：基于配置差异动态初始化、更新或销毁插件，支持force强制刷新与!!js表达式求值，确保配置变更实时生效。

通过前面两篇文章针对Profile的介绍，我们知道了所谓的Profile本质上就是构建了一组用来提供插件的配置，但是最终应用到Cordis上的插件不限于此，它还有其他的来源。这篇文章就来不起最后这张拼图。

[DeepSeek Harness深度拆解-02:Profile究竟是什么？]对DSH的Profile进行详细介绍，我们知道表面上看Profile是为DSH程序提供了针对不同运行形态和交互方式，但本质上它就是提供一组插件的配置而已。为了对Profile具有更加深刻的认识，我们决定创建一个全新的Profile，并利用它来提供我们自定义的插件。

[DeepSeek Harness深度拆解-01:DSH是如何跑起来的？]介绍了三种启动DSH的模式。由于`plugin`模式会将指定的参数转发 `pnpm` 包管理器，所以我们一般用这种执行模式来安装或卸载提供插件的包。额外两种执行模式(`profile` 和 `dump-config`)都与Profile有关，那么Profile究竟是什么呢？

[DeepSeek Harness插件内核]系列文章花了较多的篇幅介绍DeepSeek Harness（一下简称DSH）最核心的部分，作为支撑框架和核心引擎的Cordis，这个系列开始我们将正式探讨DSH。DSH发布已经有一段时间了，相信你已经看了很多介绍DSH的内容，我争取提供一些不同的东西。对于DSH来说，**一切都是插件**，但这句话只有在你对Cordis具有充分理解之后才可能有深刻的体现，而Cord