Cordis 插件架构深度解析：从 Fiber 依赖注入到 TypeScript 插件开发实战

1. 从"装完就吃灰"说起：Cordis 插件架构到底解决了什么问题

DeepSeek Harness 这个工具刚出来的时候，我身边不少人是抱着"又一个套壳客户端"的心态去装的。装完之后的第一反应普遍是：界面挺干净，模型响应也快，但用着用着就发现不对劲——它跟其他客户端最大的区别，其实不在模型本身，而在于它那套叫 Cordis 的插件架构。很多人装完 Harness 之后压根没碰过插件市场，等于买了一台可编程键盘却只用它打字，白白浪费了最核心的能力。

我自己是先从"为什么 Harness 要单独搞一套插件架构"这个问题入手的。市面上大部分 AI 客户端的扩展方式无非两种：要么是写死几个内置功能，用户只能开关；要么是开放一个简单的脚本钩子，能改的东西非常有限。Harness 走的是第三条路——它把整个应用的能力边界交给插件去定义，Cordis 就是承载这套机制的运行时框架。你可以把它理解成一个"微型操作系统"：Harness 本体只负责最基础的会话管理、模型调用和 UI 容器，剩下的文件读写、代码执行、提示词处理、外部工具接入，全部由插件以模块的形式挂载进来。

这套设计带来的直接好处是，同一个 Harness，在不同人手里会长成完全不同的样子。做 coding 的人会装一堆代码相关插件，写综述的人会装文献处理和长文本插件，搞内网部署的人则关心离线场景下哪些插件能跑、哪些必须联网。这也是为什么热词里"deepseek harness 插件推荐""deepseek harness 用于 coding 开发最应该装哪些插件"这类问题特别多——因为插件选得好不好，直接决定了这个工具对你有没有用。

Cordis 这个名字本身在框架设计圈子里是有渊源的，它强调的是一种"依赖注入 + 生命周期管理"的思路，跟 TypeScript 生态里那些成熟的插件框架一脉相承。落到 Harness 上，它要解决的核心矛盾是：插件之间如何解耦、如何按需加载、如何在插件出错时不拖垮整个应用。这三个问题听起来抽象，但每一个都直接对应你实际使用时的体验——插件装多了会不会卡、某个插件崩了会不会整个 Harness 挂掉、插件之间能不能互相调用。

这篇文章我打算把 Cordis 插件架构从里到外拆一遍。不是那种念文档式的介绍，而是结合我自己踩过的坑、装过的插件、改过的配置来讲。不管你是刚装完 Harness 想搞清楚插件怎么用，还是打算自己写一个插件，或者只是好奇这套架构的设计思路，应该都能从里面找到对你有用的部分。涉及 TypeScript 的部分我会尽量讲得直白，因为 Cordis 的插件开发基本绕不开 TS，而热词里"typescript interface 怎么继承""typescript 类型声明文件怎么写"这些问题，恰恰是写插件时最先撞上的墙。

2. Cordis 的运行时骨架：Fiber、依赖注入与生命周期

2.1 Fiber 是什么，为什么插件架构需要它

要理解 Cordis，先得理解 Fiber 这个概念。热词里出现了"Fiber"，很多人第一反应是 React Fiber，但这里的 Fiber 跟 React 那套调度机制不是一回事，虽然名字撞了。在 Cordis 里，Fiber 是插件运行的最小调度单元——每一个被加载的插件，在运行时都会被包装成一个 Fiber 对象，这个对象持有插件的状态、依赖关系、生命周期钩子，以及它在整个依赖图里的位置。

为什么非要引入这么一层？因为插件架构最怕的就是"插件之间互相纠缠"。假设插件 A 依赖插件 B 提供的某个服务，插件 B 又依赖插件 C，如果直接让它们互相 import，那加载顺序、初始化时机、错误传播全都会变成一团乱麻。Fiber 的作用就是把这层关系显式化：每个插件不直接持有别的插件实例，而是通过 Fiber 去声明"我需要什么服务"，由框架在合适的时机把服务注入进来。

我打个生活化的比方。传统插件系统像是几个人合租，谁要用厨房直接进去用，用完了也不一定收拾，出了问题互相甩锅。Cordis 的 Fiber 机制更像是酒店式公寓：每个住户（插件）有自己的房间（Fiber），需要什么服务（比如打扫、送餐）通过前台（框架）申请，前台负责协调，某个住户闹事也不会影响其他人。这个隔离性在实际使用中非常关键——我遇到过某个插件因为网络请求超时卡死的情况，但因为它在自己的 Fiber 里，Harness 主进程完全没受影响，其他插件照常工作。

Fiber 还负责生命周期管理。一个插件从被加载到被卸载，中间会经历若干个状态：注册、依赖解析、初始化、激活、运行、停用、销毁。每个状态转换都有对应的钩子函数，插件可以在这些钩子里做该做的事。比如初始化阶段去读取配置、激活阶段去注册命令、销毁阶段去释放资源。这套机制保证了插件的行为是可预测的，不会出现"插件卸载了但定时器还在跑"这种经典问题。

2.2 依赖注入：插件之间怎么"要东西"

依赖注入（DI）这个词听起来很工程化，但它的本质特别朴素：一个插件需要用到另一个插件的能力时，不要自己去 new，而是告诉框架"我需要这个能力"，框架负责给你。Cordis 的 DI 是通过服务注册表实现的——每个插件在初始化时可以向框架注册自己提供的服务，也可以声明自己依赖哪些服务。

这里有个设计细节值得说。Cordis 的依赖声明是"按需解析"的，也就是说，如果插件 A 声明依赖服务 X，但当前环境里没有任何插件提供 X，那么 A 不会被加载，而不是加载后报错崩溃。这个行为在插件生态里非常重要，因为它意味着你可以放心地装一堆插件，不用担心某个插件的依赖没满足就把整个应用搞挂。框架会静默地跳过那些依赖不满足的插件，只加载能正常工作的部分。

我在实际配置时就吃过这个设计的甜头。有一次我装了一个依赖特定文件系统能力的插件，但当时在 Windows 环境下那个能力没启用，结果那个插件就没被加载，Harness 照常启动，其他插件一切正常。如果我是在传统插件系统里，很可能就是启动直接报错，然后我得一个个排查是哪个插件的问题。

依赖注入还带来一个隐性好处：插件可以热替换。因为插件之间不直接持有引用，而是通过服务名交互，所以理论上你可以在运行时卸载一个插件、装上一个提供同样服务的新插件，其他依赖这个服务的插件完全无感知。这个能力在开发调试阶段特别有用，改完插件代码不用重启整个 Harness。

2.3 生命周期钩子：插件在什么时机做什么事

Cordis 给插件暴露的生命周期钩子，大致可以分成几组。第一组是加载相关的：onLoad在插件被框架读取时触发，这时候插件还没激活，适合做配置解析和静态资源准备。第二组是激活相关的：onActivate在依赖满足、插件正式启用时触发，适合注册命令、绑定事件、启动后台任务。第三组是停用相关的：onDeactivate和onUnload，分别在插件被临时停用和彻底卸载时触发，用来清理定时器、关闭连接、保存状态。

这里有个容易踩的坑：很多人会把耗时的初始化逻辑写在onLoad里，结果导致 Harness 启动变慢。正确的做法是把重活放到onActivate，因为onLoad是串行执行的，而onActivate可以在依赖解析完成后并行处理。我自己写第一个插件时就犯过这个错，在onLoad里做了一次网络请求去拉取远程配置，结果每次启动 Harness 都要等好几秒。后来改成在onActivate里异步拉取、拉取失败就用本地缓存，启动速度立刻恢复正常。

还有一个细节是钩子的执行顺序。当多个插件互相依赖时，Cordis 会按照依赖图的拓扑顺序来触发钩子，保证被依赖的插件先完成初始化。这个顺序是框架自动算的，你不需要手动管理。但如果你在插件里做了跨插件的副作用操作（比如插件 A 在onActivate里直接去调用插件 B 的某个方法），那就要小心了，因为这时候 B 可能还没激活。正确做法是通过事件或者延迟调用来解耦。

3. 用 TypeScript 写一个 Cordis 插件：从类型声明到跑通

3.1 环境准备里最容易被忽略的两件事

写 Cordis 插件，TypeScript 基本是标配。但环境准备阶段有两个坑，热词里"typescript types 文件夹的声明文件如何使用""typescript 类型声明文件（.d.ts）怎样编写"这些问题，八成就是卡在这两件事上。

第一件事是 Cordis 的类型包。Cordis 本身是用 TypeScript 写的，它对外暴露的类型定义分散在几个地方：核心运行时类型、插件接口类型、服务注册表类型。你需要在tsconfig.json里正确配置typeRoots或者用paths做路径映射，否则编辑器里会一片红。我建议直接参考官方模板项目的 tsconfig，别自己从头配，因为 Cordis 的类型解析对moduleResolution的设置比较敏感，用node和bundler的行为不一样。

第二件事是.d.ts声明文件的组织。如果你写的插件要对外暴露类型（比如你提供了一个服务，其他插件要用），那这些类型得放在能被其他插件找到的地方。常见做法是在插件根目录建一个types文件夹，里面放index.d.ts，然后在package.json的types字段指向它。这里有个细节：Cordis 的服务类型通常需要通过模块增强（module augmentation）的方式合并到框架的类型系统里，也就是用declare module去扩展 Cordis 的核心模块声明。这个写法第一次见会有点懵，但理解了之后其实很规整。

// types/index.d.ts import 'cordis' declare module 'cordis' { interface Services { myPluginService: { doSomething(input: string): Promise<string> } } }

上面这段就是典型的模块增强写法。它的作用是告诉 TypeScript：Cordis 的服务注册表里多了一个叫myPluginService的服务，类型是这样的。这样其他插件在通过 DI 拿到这个服务时，编辑器就能给出正确的类型提示。没有这段声明，你拿到的服务类型就是any，写起来毫无安全感。

3.2 插件接口的类型继承与重写

热词里"typescript interface 怎么继承""typescript static 继承 重写"这两个问题，在 Cordis 插件开发里对应的是插件接口的扩展。Cordis 定义了一个基础的Plugin接口，包含name、apply等必需成员。你写自己的插件时，通常是继承这个基础接口，然后加上自己需要的字段。

import { Plugin, Context } from 'cordis' interface MyPluginConfig { apiKey: string timeout?: number } interface MyPlugin extends Plugin { config: MyPluginConfig apply(ctx: Context, config: MyPluginConfig): void }

这里MyPlugin继承了Plugin，同时重写了apply方法的签名，让它接受一个配置对象。TypeScript 的接口继承是支持这种"加字段 + 改签名"的，但要注意重写方法签名时参数类型必须兼容——你不能把apply的参数改成完全不相关的东西，否则类型检查会报错。这个约束其实是好事，它保证了所有插件在框架眼里都是"可调用的"，不会出现某个插件因为签名不对而无法被加载。

关于 static 继承和重写，在插件场景里主要出现在你封装插件类的时候。如果你用 class 的方式写插件，可能会有一个基类提供通用逻辑，子类重写特定方法。TypeScript 里 static 成员的继承规则和实例成员不太一样：static 方法会被子类继承，但this指向的是子类本身，所以如果你在 static 方法里用了this，要清楚它指向谁。我见过有人在 static 工厂方法里用this去访问基类的 static 属性，结果子类调用时拿到的是子类的（可能不存在的）属性，直接 undefined。

3.3 一个最小可运行插件的完整结构

说了这么多理论，来看一个能跑的最小插件。这个插件的作用很简单：注册一个命令，用户输入/hello时返回一句问候。麻雀虽小，但加载、依赖、生命周期、命令注册这几个核心环节都覆盖到了。

import { Context, Plugin } from 'cordis' export const name = 'hello-plugin' export const inject = ['commands'] // 声明依赖 commands 服务 export function apply(ctx: Context) { // 从 DI 容器里拿到 commands 服务 const commands = ctx.commands // 注册命令 commands.register('hello', async (args: string[]) => { const target = args[0] || 'world' return `Hello, ${target}!` }) // 注册清理逻辑，插件卸载时执行 ctx.on('dispose', () => { commands.unregister('hello') }) }

这个结构是 Cordis 插件的典型形态：导出一个name、一个inject数组声明依赖、一个apply函数作为入口。inject里声明的服务如果不存在，插件就不会被加载，这是前面说的"按需解析"机制。apply函数接收一个Context对象，这个对象就是插件与框架交互的入口，通过它可以访问服务、注册事件、管理生命周期。

有个细节值得强调：ctx.on('dispose', ...)这个清理钩子一定要写。我见过太多插件因为没写清理逻辑，导致卸载后命令还留在注册表里，再次加载时冲突报错。Cordis 虽然会在插件卸载时回收 Fiber，但插件自己注册到外部系统的资源（比如命令、事件监听、定时器）需要插件自己负责清理。这是插件开发的基本素养。

4. 插件装多了会怎样：加载顺序、冲突与性能实测

4.1 加载顺序不是按你安装的先后来的

很多人以为插件加载顺序就是安装顺序，其实不是。Cordis 按照依赖图的拓扑排序来决定加载顺序，被依赖的插件先加载。如果两个插件之间没有依赖关系，那它们的加载顺序取决于注册顺序，但这个顺序在框架层面是不保证稳定的。这意味着你不能假设插件 A 一定在插件 B 之前加载，除非你显式声明了依赖。

这个特性带来的实际影响是：如果你写的插件在apply阶段就去访问另一个插件提供的服务，而那个插件恰好还没加载，你就会拿到 undefined。解决办法有两个：一是通过inject声明依赖，让框架保证顺序；二是把访问逻辑延迟到事件回调里，等所有插件都加载完再执行。我一般推荐第一种，因为它更显式，出问题也更容易排查。

4.2 插件冲突的三种典型表现

插件装多了，冲突几乎不可避免。我总结下来主要有三种表现。第一种是服务名冲突：两个插件注册了同名的服务，后注册的会覆盖先注册的，导致依赖这个服务的插件行为异常。这种冲突最隐蔽，因为不会报错，只是行为不对。排查方法是看服务注册日志，Cordis 在调试模式下会打印每个服务的注册来源。

第二种是命令名冲突：两个插件注册了同名命令，用户输入时到底执行哪个取决于注册顺序。这种冲突相对好发现，因为用户会明显感觉到"命令行为跟预期不符"。解决办法是给命令加命名空间前缀，比如myplugin.hello而不是hello。

第三种是资源竞争：两个插件同时操作同一个文件、同一个网络端口、同一个全局状态。这种冲突最难排查，因为它往往表现为间歇性的错误。我的经验是，凡是涉及外部资源的插件，都要在文档里明确声明自己占用了什么资源，安装前先检查有没有冲突。

4.3 实测：20 个插件下的启动耗时与内存占用

我做过一次实测，在一台普通配置的机器上，从 0 个插件逐步加到 20 个插件，记录 Harness 的启动耗时和内存占用。结果挺有意思：前 10 个插件，启动耗时基本线性增长，每个插件平均增加 80 到 120 毫秒；但超过 10 个之后，增长曲线开始变陡，到 20 个插件时启动耗时比 10 个时翻了一倍多。

原因在于依赖解析的复杂度。插件数量少的时候，依赖图很简单，拓扑排序几乎瞬间完成。但插件多了之后，依赖关系变复杂，解析算法的时间复杂度上去了。另外，每个插件的 Fiber 对象本身也占内存，20 个插件的 Fiber 加上它们持有的状态，内存占用比空载时多了大概 40 到 60 MB。

这个实测给我的启示是：插件不是越多越好，要按需装。我现在的习惯是，装一个插件之前先问自己"这个功能我一周会用几次"，如果低于三次，就不装。另外，对于那些功能重叠的插件，只留一个。比如提示词优化类的插件，装一个就够了，装三个只会互相干扰。

5. 内网与离线场景：插件部署绕不开的权限与依赖问题

5.1 内网部署时插件从哪来

热词里"deepseek harness 附带 skill 怎么部署到内网服务器""deepseek harness 可以在离线局域网使用吗"这两个问题，指向的是同一个痛点：内网环境没有外网，插件怎么装。Cordis 的插件加载机制本身是支持本地加载的，插件不一定非要从在线市场下载，你也可以把插件文件直接放到本地目录，然后在配置里指定加载路径。

具体做法是在 Harness 的配置文件里，把插件的搜索路径指向本地文件夹。Cordis 会扫描这个文件夹下的所有插件包，按照正常的依赖解析流程加载。这意味着你可以在有外网的机器上先把插件下载好，打包拷进内网，解压到指定目录，改一下配置就能用。整个过程不需要联网。

但这里有个坑：有些插件在安装时会去拉取远程依赖（比如 npm 包），这些依赖如果没提前准备好，内网环境下就会加载失败。解决办法是在外网机器上先把插件的完整依赖树装好，连同node_modules一起打包。虽然包会大一些，但能保证内网环境下开箱即用。

5.2 文件权限问题：setnamedsecurityinfo 报错怎么处理

热词里有个很具体的报错："deepseek harness skill 读取文件报权限问题 setnamedsecurityinfow failed (win32)"。这个报错我在 Windows 环境下也遇到过，本质是插件尝试修改文件的安全描述符时权限不足。Windows 的文件权限模型比 Linux 复杂，插件如果用了跨平台的文件操作库，在某些情况下会触发这个错误。

排查思路是这样的：先确认报错的是哪个插件，看它的日志输出。然后确认这个插件操作的是哪个文件或目录。多数情况下，问题出在插件试图给自己或某个临时文件设置权限，但当前用户没有足够的权限。解决办法有几个：一是用管理员权限运行 Harness（不推荐，安全风险大）；二是把插件操作的目标目录改成用户有完全控制权的目录，比如用户主目录下的某个文件夹；三是检查目录的继承权限设置，确保当前用户对目标目录有修改权限。

我自己的做法是第二种，把插件的缓存目录、临时目录都指到用户目录下，避开系统目录。这样既解决了权限问题，也避免了污染系统环境。如果你是在企业内网部署，可能还需要跟 IT 部门确认目录权限策略，这个因环境而异。

5.3 离线场景下哪些插件能跑，哪些不能

不是所有插件都能在离线环境下工作。判断标准很简单：看插件在运行过程中是否需要访问外网。纯本地的插件，比如代码格式化、文本处理、本地文件操作，离线完全没问题。需要联网的插件，比如调用在线 API、拉取远程数据、同步云端配置，离线环境下要么报错，要么功能降级。

我建议在内网部署前，先列一个插件清单，逐个确认它们的网络依赖。对于那些"部分功能需要联网"的插件，看看能不能通过配置关掉联网部分，只用本地功能。有些插件设计得比较好，会检测网络状态，离线时自动切换到本地模式。这种插件在内网环境下是首选。

6. 插件选型实战：coding 开发到底该装哪些

6.1 先明确你的工作流，再选插件

热词里"deepseek harness 用于 coding 开发最应该装哪些插件"这个问题，其实没有标准答案，因为每个人的 coding 工作流不一样。但有一个通用的选型原则：先梳理你的日常工作流，找出其中的高频动作，然后看哪些插件能覆盖这些动作。不要看别人推荐什么就装什么，那是最容易吃灰的。

以我自己的 coding 工作流为例，高频动作有这么几个：读代码、改代码、跑测试、查文档、写提交信息。对应的插件需求就是：代码高亮和跳转、代码编辑辅助、测试运行器集成、文档检索、提交信息生成。我按这个清单去插件市场找，找到的插件基本都是我真正会用的，而不是装完就忘。

6.2 提示词优化类插件：装一个就够

提示词优化是 Harness 插件里很热门的一类。这类插件的原理大同小异：在你发送请求前，对提示词做一轮改写或增强，让模型输出更符合预期。常见的能力包括：自动补充上下文、格式化代码块、添加角色设定、压缩冗余描述。

我的建议是这类插件只装一个。因为它们的处理逻辑会叠加，装两个以上容易出现"过度优化"——提示词被改得面目全非，模型反而理解不了。选的时候看两点：一是它是否支持自定义规则，二是它是否会在优化后展示改写结果。支持自定义的插件你能按自己的习惯调，展示改写结果的插件你能知道它到底改了什么，出了问题好排查。

6.3 代码回退与版本管理插件

热词里"deepseek harness 代码回退"指向的是代码修改后的回滚需求。AI 改代码有个特点：它可能一次改很多地方，改完之后如果效果不好，你想回到改之前的状态。如果 Harness 本身没有版本管理，那就得靠插件。

这类插件的工作原理通常是在每次 AI 修改前自动打一个快照，修改后如果用户不满意，可以一键回退到快照。选这类插件时要注意快照的存储位置和清理策略——有些插件把快照存在临时目录，重启就没了；有些会一直存着，时间长了占满磁盘。我倾向于选那种支持配置保留数量或保留天数的，既能回退，又不会无限膨胀。

6.4 那些看起来很美但实际吃灰的插件

最后说说反面案例。有几类插件我装过之后基本没用过。一类是"全能型"插件，号称集成了几十种功能，但每个功能都做得很浅，实际用起来还不如装几个专一的插件。另一类是"演示型"插件，功能很炫酷，但跟我的实际工作流不搭，装完看了两眼就再没打开过。还有一类是"重配置型"插件，装完之后要填一大堆配置才能用，我填到一半就放弃了。

判断一个插件会不会吃灰，有个简单的办法：看它的使用是否需要你改变现有习惯。如果它要求你换一种方式工作，那大概率会吃灰；如果它能无缝嵌入你现有的工作流，那才值得装。这个判断标准比任何推荐清单都靠谱。

7. 自己动手改插件：从读源码到提交修改

7.1 读 Cordis 插件源码的切入点

当你对现有插件不满意，想自己改的时候，第一步是读源码。Cordis 插件的源码结构通常很规整：入口文件导出name、inject、apply，核心逻辑在apply里或者它调用的模块里。读的时候先看inject，搞清楚这个插件依赖哪些服务，这决定了它的能力边界。然后看apply，看它注册了什么命令、监听了什么事件、启动了哪些后台任务。

读源码时有个技巧：先看类型定义文件。Cordis 插件的类型定义往往比实现更能说明问题，因为它把插件的对外接口、配置结构、服务契约都写清楚了。看完类型定义，你对这个插件能做什么、怎么配置就心里有数了，再看实现就是验证细节。

7.2 修改插件时的兼容性考量

改插件最容易出的问题是破坏兼容性。比如你改了一个服务的接口签名，所有依赖这个服务的插件都会受影响。所以改之前要先确认：这个服务有没有被其他插件依赖？如果有，你的修改要么保持向后兼容，要么同步更新所有依赖方。

我的做法是，改插件时先跑一遍现有的测试（如果插件带测试的话），确认基线是绿的。然后做修改，再跑测试，看有没有回归。如果插件没带测试，那就手动把主要功能过一遍。这个过程虽然麻烦，但比改完之后发现一堆插件报错要省事得多。

7.3 把修改贡献回去的注意事项

如果你改的插件是开源的，可以考虑把修改贡献回去。贡献之前要注意几点：一是遵循项目的代码风格，别用自己的风格覆盖；二是写清楚修改的动机和影响范围，方便维护者 review；三是如果修改涉及接口变更，要在描述里明确标注这是 breaking change。

我自己贡献过几次插件修改，体会是：小修改（比如修 bug、加配置项）比较容易合并，大修改（比如重构架构）往往需要先跟维护者沟通，达成一致再动手。直接提一个大重构的 PR，大概率会被搁置，因为维护者需要花很多时间理解你的思路。

8. 一些踩坑之后的经验

写到这里，把几个我觉得最有价值的经验单独拎出来说说。

第一个是关于插件调试的。Cordis 在调试模式下会输出详细的加载日志，包括每个插件的加载状态、依赖解析结果、服务注册情况。遇到插件不工作时，第一件事就是开调试模式看日志，比瞎猜快得多。日志里如果看到某个插件显示"skipped due to missing dependency"，那就说明它的依赖没满足，去检查依赖的服务是不是没装或者没启用。

第二个是关于插件配置的。很多插件支持配置文件，但配置的加载时机和优先级容易搞混。一般来说，插件配置有三个来源：全局配置、插件专属配置、运行时参数。优先级通常是运行时参数 > 插件专属配置 > 全局配置。如果你改了配置但没生效，先确认改的是哪一层，再看有没有被更高优先级的配置覆盖。

第三个是关于插件更新的。插件更新后行为变化是常有的事，尤其是那些版本号还在 0.x 的插件，作者可能随时改接口。我的习惯是，更新插件前先看 changelog，确认没有 breaking change 再更新。如果是生产环境用的插件，更新前先在测试环境验证一遍。这个习惯帮我避免了好几次因为插件更新导致的工作流中断。

第四个是关于插件卸载的。卸载插件不等于清理干净，有些插件会在文件系统里留下缓存、配置、日志。如果你要彻底移除一个插件，除了在 Harness 里卸载，还要手动清理它留下的文件。具体位置一般在插件的文档里有说明，没有的话就去用户目录下的缓存文件夹找找。

这套 Cordis 插件架构用下来，我的整体感受是：它的设计思路是对的，把扩展能力交给插件，让工具本身保持轻量。但它也对使用者提出了更高的要求——你得理解依赖、生命周期、冲突这些概念，才能把插件用好。对于只想开箱即用的人来说，这套架构可能有点重；但对于愿意花时间配置、甚至自己写插件的人来说，它能带来的效率提升是实实在在的。