JaydenAI的博客

Cordis插件针对服务的消费具有一个基本的原则：只有在显式注入的前提下才能消费目标服务。但是一旦完成了服务注入，Cordis就会认为当前插件没有依赖服务的参与就不能正常工作，所以它会将插件的生命周期和服务生命周期绑定在一起。对于插件来说，只有它所有注入的依赖服务全员上线，它才能上线；反之，如果在运行过程中有任何一个依赖服务下线，自己也改不了下线的命运，所以插件与服务之间就是这种硬性依赖的关系。但是很多时候插件需要保持始终处于激活的状态，消费的服务也不是必需的，就需要通过一些变通将针对服务的依赖变得软性一点

实现在`EventsService`的事件总线是Cordis的通信网络，也是DeepSeek Harness基于通信的基础设施。运行中的Cordis很多基础的功能要求涉及的模块相互协作，必然会使用到一些内部定义的事件。虽然被标识为内部事件，并不意味着它们不能为我们自定义的插件所用，所以我们有必要来了解它们

[DeepSeek Harness插件内核-04：事件总线完美解决各模块通信问题]中旨在对`EventsService`这个为Cordis提供事件总线的基础服务进行介绍，为了避免节外生枝，并没有涉及针对Fiber的介绍。但是Cordis的事件总线和Fiber具有不可分割的关系，我们通过这篇文章从另一个角度对Cordis的事件总线进行重新解读。

对于Cordis附加在Context的四大核心服务，我们已经介绍其中三个（[EventsService]、[ReflectService]、[RegistryService]，我们今天来补充最后一个，用来输出日志的LoggerService。日志的重要性无需多做介绍，如果你需要将DeepSeek Harness来构造正在在产线应用的Agent，相信你会编写很多日志相关的代码，所以我们有必要了解基于`LoggerService`的日志编程模式和背后的实现原理。

Cordis 中，**万物皆插件** ，但是插件的定义简单至极，用来调用插件执行和管理器周期的`Fiber`才是核心所在。在通过[DeepSeek Harness插件内核-10：Fiber是如何管理插件生命周期的]完成了针对插件和`Fiber`的深度介绍之后，我们介绍一下用来注册插件的`RegistryService`服务。

在[前文]中，我们介绍了通过调用`isolate`方法创建的子`Context`因与父`Context`共享同一个`Fiber`导致隔离能力丧失的问题。在文中为了演示这个问题，我刻意调用`inject`方法而不是`plugin`方法来为子`Context`注册插件，这是因为后者注册的插件根本无法执行。

在[DeepSeek Harness插件内核-10：Fiber是如何管理插件生命周期的]介绍Fiber的时候，我曾经提到过Cordis一个关于Context隔离的问题，我们今天就来着重聊聊，看看它是否是Deep Harness的Bug。如果它算一个BUG的话，我觉得这是一个大BuG。

本系列的[第8篇]和[第9篇])主要介绍了Cordis服务的本质以及服务是如何利用`ReflectService`以反射的形式被注册的，接下来我们来介绍DeepSeek Harness作为基本部署单元和生命周期管理单元的插件、和作为插件调度和生命周期管理器的Fiber。

[DeepSeek Harness插件内核-02:服务的注册与消费]中，我们简单体验了一下如何在Cordis中定义、注册和使用服务，在[DeepSeek Harness插件内核-08:利用RefectService以反射方式扩展Context]中介绍的ReflectService

虽然Context是Cordis架构体系最核心的类型，但是通过 Context全面解析 ([上篇] 和 [下篇]\)的介绍，我们知道Context仅仅定义了三个方法而已，它的很多方法都是`RefectService`以反射的方式赋予它的。`[symbols.invoke]` 是 C

在[上篇]中，我们刻意漏掉了如下所示的两个部分:一是在`extend`方法中用来包装当前`context`对象的`getTraceable`函数，还有就是`Context`构造函数中将自己包装成代理的`ReflectService.handler`。其实这两者最终的目的只有一个：让绑定到固定`Context`上的同一个服务实例在执行的过程在能过自动跟踪当前提供的`Context`。换句话说，当我们将两个插件注册在不同的`Context`上并对同一个服务发起调用时，后者可以感知到作为调用者的时那个插件。

这是本系列的第6篇文章，由于Context是整个Cordis的核心，所以前几篇文章都有在介绍它。在接下来两篇文章中，我们将从Context类型的定义对Cordis体系中这个最重要的对象展开介绍，几乎会涉及到Context的所有细节，争取把每一点都讲透。

Cordis利用动态创建子Context的方式构建具有树形层次化结构的Context Tree，进而为插件提供的独立的执行环境。貌似很完美地为插件解决了上下文隔离问题。但是还有一个问题得解决：由于Cordis总是将服务注册到根Context上，意味着以此为根的整棵Context Tree注册的插件使用的同名服务都是同一个实例，如何让服务执行的时候通过提取**与插件关联的上下文**信息，而不是使用**与自身绑定的上下文**。

Cordis 的事件总线是该轻量级 Node.js 插件化框架的核心通信枢纽，所有插件与服务之间的松耦合协作均由其驱动。在 Cordis 架构中，插件之间通常不直接相互调用，而是通过上下文（Context）中的事件总线服务进行跨模块通信。具体的事件总线服务具体为如下这个 `EventsService` 对象，Context的`events`属性返回的正是这个对象。

在 Cordis 中，管理插件与上下文生命周期的核心引擎并不是传统应用中的全局注册表，而是一个名为 Fiber 的状态机与执行单元。作为 Context 和 Plugin 生命周期的真正管理者。每一个被加载的插件实例，在 Cordis 运行时中都会被包裹在一个独立的 Fiber 作用域内。Fiber 充当了状态机的角色，负责监控插件的依赖是否满足，并精确追踪该插件在 Context 上创建的所有待释放资源，以便在卸载时执行资源清理和释放工作。

[DeepSeek Harness插件内核-01:DeepSeek Harness三种插件形式]中介绍了Cordis插件的三种定义方式，由于演示的插件功能简单，所以直接将所有的功能实现在作为插件的函数或者对象上。真正的插件开发中，我们都倾向于将业务功能定义成服务并注册到Context这个依赖注入容器上，任何依赖此功能的插件都可以从容器中提取并消费所需的服务，从而达到功能复用的目的。本篇文章将会

DeepSeek Harness（dsh）是由 DeepSeek AI 开发的开源 agent harness。它采用**一切皆插件的架构**，并由 Cordis 驱动，其设计参见论文 [A Programming Paradigm for Spatiotemporal Composability](https://github.com/cordiverse/paper)。Cordis 本质上是插件的的执行内核，Harness 则是基于 Cordis 的完整代理运行框架。理解 Cordis 就是理解 Har