DeepSeek Harness核心引擎Cordis深度解析：从插件架构到时空可组合性编程范式

DEEPSEEKHARNESS技术深度解析Cordis核心引擎深度解析从插件架构到时空可组合性编程范式EverythingisaPlugin的技术底座技术白皮书·2026目录CONTENTS共6章·40页01背景与起源Agent框架三代演进·Cordis的出身与定位02核心机制五大概念：插件·上下文·注入·事件·可逆副作用03在DSH中的实践启动流程·Profile分层·工具流水线·自指设计04开发能力与生态槽位服务·三种角色·插件开发生态05论文与理论时空可组合性编程范式·effect与coeffect06生态与未来Koishi实战平台·自进化Agent展望Cordis:AMeta-FrameworkofSpatiotemporalComposability01背景与起源从QQ机器人内核到Agent运行时的心脏CHAPTERONEAgent框架的三代演进第一代大而全：以ClaudeCode为代表，厂商提供完整Agent，扩展是附属品，核心不可替换。第二代小而美：以Pi为代表，极薄通用内核，用户自行拼装Agent，但内核仍不可替换。第三代一切皆插件：以DSH为代表，连内核本身都可替换，组合成为有理论支撑的学科。三代产品回答同一个问题："一个编程Agent应该如何组织？"从不可替换的完整产品，到可拼装的薄内核，再到一切皆可替换的插件化架构，Agent的灵活性和可组合性不断提升。01/背景与起源DeepSeekHarness：一切皆插件DeepSeekHarness（DSH）是DeepSeek于2026年8月开源的Agent运行时框架，以MIT协议开放源代码。其架构宣言只有一句话：Everythingisaplugin。全部可替换的核心组件模型适配器工具注册表会话日志Agent主循环沙箱执行存储后端不存在"为了改核心必须fork"的特权层。扩展DSH的方式是在旁边挂载一个插件，注册行为在插件卸载时自动回滚。核心洞察：Agent=Model+Harness。模型是Agent的灵魂，Harness让Agent理解环境、使用工具、在真实场景中持续工作。而Cordis就是Harness背后管理插件挂载、卸载和依赖的内核。01/背景与起源Cordis是什么：从QQ机器人到Agent地基Cordis是一个元框架（meta-framework），它规定"副作用如何组合、依赖如何解析"，但不预设任何业务领域。QQ机器人可以用它，Agent运行时也可以用它。发展时间线2020.01Koishi发布首个正式版，Cordis作为其插件体系内核诞生2022.04cordis包独立登上npm，核心层被抽出来成为通用框架2024.11Cordis4.0预发布，引入基于fiber的生命周期体系2026.08DeepSeekHarness开源，Cordis成为Agent运行时地基名字的由来Cordis是拉丁语"心"（cor）的所有格，意为"心脏"。它是Koishi的心脏，如今也成了DeepSeekHarness的心脏。Cordis不是机器人框架（Koishi才是），也不是传统DI容器。传统DI回答"谁创建谁"，Cordis回答更困难的问题："谁在什么时候活着"。它把"卸载"和"协作"这两件事，从插件作者的自觉上升为框架级保证。01/背景与起源作者Shigma与一人撑起的技术栈Cordis的作者是Shigma（群友们亲切称呼为"梦梦"），在第三方QQ机器人圈子里是相当出名的存在。GitHub账号下有130多个公开仓库，npm上几个包的主页打开，maintainer都是同一个人。一人撑起的技术栈包名一句话描述koishi跨平台聊天机器人框架cordis插件化应用框架，本文的主角@satorijs/core跨平台聊天协议适配层schemastery类型驱动的schema校验器minato类型驱动的数据库框架cosmokit通用工具集配套论文《AProgrammingParadigmforSpatiotemporalComposability》以预印本发布，署名单位是北京大学与DeepSeek-AI，第一作者YifanShi，合著者WeiZhang、TianyiCui。论文把Cordis的机制形式化，给出了定义、定理与证明。这是一套一个人撑起来的技术栈：Cordis是骨架（生命周期与依赖），Schemastery管配置校验，Minato管数据存取，Satorijs管平台协议，Koishi是集大成者。整篇文章讲到的每一个概念——fiber、effect、Schema、Service——都出自他一人之手。02核心机制五个概念，七个小节，由浅入深拆开CordisCHAPTERTWO五个核心概念总览Cordis的全部语义可以浓缩为五个概念，由浅入深逐一拆开：1插件（Plugin）功能的最小单元，三种形态：函数、对象、类2上下文（Context）一切操作的入口，既是依赖容器也是事件总线3注入（Inject）响应式依赖，服务随时出现、消失、更换身份4.事件（Event）五种分发模式，类型安全5.可逆副作用（Effect）加载执行，卸载自动回滚这五个概念加上把它们串起来的Schema，构成了Cordis的全部语义。其中effect（可逆副作用）和inject（响应式依赖）是Cordis区别于传统DI容器的两个核心机制。第一个插件：完全不需要框架启动代码//hello.tsimporttype{Context}from'@deepseek-ai/cordis'exportconstname='hello'exportfunctionapply(ctx:Context){console.log('hellofrommyfirstplugin')}运行DSH自带的小启动器，输出hellofrommyfirstplugin。注意分工：插件只描述贡献，应用长什么样由配置决定。这就是"配置即组合"。插件的三种形态1.函数形态最常见，exportfunctionapply(ctx:Context){}。接收上下文，在其中注册服务、监听事件、挂载子插件。2.对象形态exportconstobjectPlugin={name:'obj',apply(ctx){}}。适合需要携带元数据的插件，name字段用于标识。3.类形态exportclassMyServiceextendsService{}。需对外提供服务时使用，构造函数接收ctx和服务名。上下文Context：一切操作的入口在Cordis里，你几乎只会跟一个东西打交道：ctx。它是上下文，也是服务容器，承载了插件能做的所有事情。ctx.on('event',payload=>{})//监听事件（卸载时自动移除）ctx.effect(()=>{...})//注册副作用（卸载时自动回滚）ctx.plugin(SomePlugin)//挂载子插件（随父插件卸载）ctx.get('someService')//读取服务（没有则undefined）vide('someValue',42)//提供服务ctx.plugin(child)不是简单的"注册"，而是派生出一个子上下文。插件因此不是平铺的，而是一棵树。插件树的卸载语义子上下文能看到父上下文的一切（继承），但卸载是按层级的：父插件卸载，所有子插件递归卸载；子插件卸载，不影响兄弟和父级。fiber：插件的生命周期状态机Cordis4为每个已加载的插件实例维护一个fiber（纤维），状态机如下：PENDING等待依赖就绪LOADINGapply执行中ACTIVE运行中UNLOADING清理中DISPOSED已拆除FAILED：apply抛异常/配置校验失败插件可能因配置修改、热重载、显式dispose()或依赖服务消失而被卸载。无论哪种原因，清理都是自动的。在DSH里，cordis_inspect巡检的就是每个fiber的状态；一个插件"加载了却没反应"，多半是蹲在PENDING。一个fiber就是一个已加载插件实例的生命周期与树：无论因何卸载（改配置/热重载/显式dispose/依赖服务消失），清理都是自动的。fiber携带自己的生命周期状态、累加器与"已承诺视图"（committedview），记录各依赖当时解析到哪个提供方。effect：可逆的副作用这是Cordis的第一个核心机制，也是它与传统DI容器的区别所在。ctx.effect(()=>{constconn=createConnection()return()=>conn.close()//disposer：如何清理})effect的主体在加载时执行，返回的disposer在卸载时执行。你永远不需要自己调用清理函数，不管插件因为什么原因被卸载，Cordis都会替你把定时器、监听器、连接全部回滚。内置API本身就是effectctx.on()的监听器随插件卸载、ctx.plugin()的子插件递归卸载、服务注册随提供方消失。论文的实现章节有一个关键结论：Cordis中所有对上下文的变更，最终都归结为ctx.effect这一个原语。插件作者的铁律凡是自己创建、Cordis不管的资源，都包进ctx.effect()。因为副作用可逆，插件就可以被安全地卸载与重装，由此获得热重载（HMR）、故障自动恢复、测试隔离。服务与注入：响应式的依赖这是Cordis的第二个核心机制。把一项能力挂到ctx上，让别的插件按名字取用，这就是Service。exportconstinject=['greeter']//声明依赖exportfunctionapply(ctx:Context){console.log(ctx.greeter.greet('world'))}inject的语义：插件保持PENDING，直到所列服务全部就绪。配置文件顺序无关紧要，启动顺序由依赖关系决定。与传统DI的本质区别传统DI假设"一旦绑定，服务就一直在"；Cordis的假设是"服务可以随时出现，也可以随时消失"。提供方被卸载时，所有依赖它的插件自动卸载（effect回滚）；新提供方就绪后，自动重载。两个配套机制ctx.isolate(key,realm)隔离：让一个作用域内某项服务解析到独立实例，两组各自用各自的实现，互不干扰。ercept(key,meta)拦截：给依赖访问附加元数据，外层上下文可以约束组件如何使用某个依赖，而不修改组件本身。事件系统：五种分发模式与waterfall服务适合"直接打电话"，但很多时候插件只想"喊一嗓子"或者"拦一下"，不关心谁在听。Cordis的事件系统是类型化的。模式语义emit同步广播；不等待、不收集返回值parallel所有监听器并发执行并等待serial按序执行；第一个非空返回值胜出，停止后续bailserial的同步版本waterfall环绕中间件（around-middleware），DSH用得最多waterfall决策链本质是把Koa、Express的中间件搬进事件系统：每个监听器收到参数和一个next()continuation。不调用next()=否决、短路；调用next()=放行。多个互不相识的插件，就这样组成一条决策链。在DSH里：工具执行管道tools/pre-execute→tools/execute→tools/post-execute就是一条waterfall链；approval/request、agent/request也是。DSH明文纪律：只负责观察和记录的waterfall监听器必须调用next()，否则会无声地吞掉下游所有默认行为。Schema与声明式组合：配置即程序cordis.yml里的每一项（entry）都可以带元数据，插件用schema声明配置结构，Cordis在调用apply前校验。exportconstConfig=Schema.object({greeting:Schema.string().default('Hello'),targets:Schema.array(String).default(['world']),})配置非法则加载失败并给出精确错误，插件绝不会在配置不完整时半启动。配置即程序修改配置=局部热替换，无需重启。在DSH里，cordis.patch.yml与--patch覆盖层，就是这套声明式组合在生产环境的使用方式。连"应用由哪些插件组成、各是什么配置"本身，都是可叠加、可覆盖、可审计的声明。entry的关键元数据id稳定身份，精准增量更新group插件打包成单元整体装卸disabled保留条目不挂载，改回自动加载03在DSH中的实践二十行启动·Profile分层·工具流水线·自指设计CHAPTERTHREE启动：约二十行代码搭起整个应用import{Context}from'@deepseek-ai/cordis'importLoaderfrom'@deepseek-ai/cordis-plugin-loader'asyncfunctionboot(binName,configPath,patches,prepare,baseUrl){constctx=newContext()//创建根上下文ctx.baseUrl='/'//相对路径基准vide('dshHomePath',dshHomePath)//引导值awaitctx.plugin(Loader)//挂载Loaderawaitprepare?.(ctx)//准备钩子awaitmountRootInclude(ctx,configPath,patches,baseUrl)awaitctx.get('loader')?.await()//等整棵树稳定awaitassertEntriesActivated(ctx,binName)//审计returnctx}根Context只做了三件小事：1.创建上下文、设置基准路径2.挂载Loader插件3.等整棵插件树稳定其余一切，来自配置树。DSH自带的小启动器（创建根Context、挂载Loader、读取cordis.yml），输出插件中的日志。插件只描述贡献，应用长什么样由配置决定。Profile与Bundle：应用被拆成可叠加的层DSH引入了Profile概念：$DSH_HOME/profiles/<名字>/下的一个目录，包含manifest和用户自己的cordis.patch.yml。配置树的组装顺序（后写覆盖先写，按id寻址）①空根（cordis.yml={}，什么都没有，等着被插）②bundle1：@deepseek-ai/dsh-base（一次insert几十个核心插件）③bundle2：@deepseek-ai/dsh-web-app（Web界面相关插件）④profile的cordis.patch.yml（你的覆盖层）⑤$DSH_HOME/cordis.patch.yml（机器级覆盖层）⑥--patch覆盖层（命令行，临时生效）Bundle是什么Bundle（组合包）就是一个npm包，其package.json声明"dsh":{"bundle":{"patch":"./cordis.patch.yml"}}。核心组合包@deepseek-ai/dsh-base的patch就是把几十个插件一次insert进空根。部署方想改默认行为，无需改任何源码，在自己的patch层按id覆盖一行即可。工具流水线：Agent的每一项能力Agent的能力边界是ctx.tools服务，注册一个工具，本质就是一个Cordis插件。exportconstname='greet-tool'exportconstinject=['tools']//等待注册表就绪exportfunctionapply(ctx:Context){ctx.tools.register(defineTool({name:'greet',description:'Greetthenamedperson.',parameters:{name:{type:'string',required:true}},asyncexecute(args){return`Hello,${}!`},}))}inject:['tools']等待注册表就绪；ctx.tools.register(...)注册即effect，插件卸载时工具自动注销；tools/result事件让任何插件都能观察每次工具调用。工具执行的waterfall链每次工具调用都经过一条waterfall决策链：tools/pre-execute→权限检查tools/execute→实际执行tools/post-execute→限流/审计任何插件都可以在链上插入自己的逻辑。本文写作过程中用到的bash、read、grep、subagent等工具，全部挂在ctx.tools上。DSH内置的工具类插件包括：tool-bash、tool-fs、tool-fs-search、tool-web、tool-subagent、tool-workflow、tool-goal、tool-jobs、tool-skill、tool-ralph、tool-lsp、tool-cordis（自指工具集）等。自指设计：Agent检查并改装自己的运行时DSH最值得注意的包是@deepseek-ai/dsh-tool-cordis，官方称之为"自指的Cordis工具集"（self-referentialCordistoolset）。它给Agent提供五个工具cordis.inspect对当前进程只读巡检：哪些服务在运行、各fiber状态、注册了哪些工具cordis.define现场定义一个小插件包（可带"宿主半+浏览器半"），只记录不执行cordis.run把宿主半放入node:vm沙箱执行，把浏览器半推送到每个打开的网页cordis.stop卸载动态包cordis.undefine卸载动态包自进化Agent的雏形Agent可以检查自己运行的框架、现场编写并运行动态插件、用完再卸载，全程不动cordis.yml、不装npm包、不重启进程。自省+现场改装，这两点叠加就是"可进化Agent"的雏形。论文的结论部分恰好把"自进化Agent运行时"列为这套理论未来的验证方向。04开发能力与生态槽位服务·三种角色·开发入口·插件生态CHAPTERFOUR三种角色：Definition/Provider/ConsumerDSH对"可替换能力"有一套固定模式，以shell为例，分为三种角色：ServiceDefinition定义服务契约（只声明服务名与类型，几乎不变）。如dsh-shell定义shell服务的接口。ServiceProvider可独立替换的提供方（提供方/工具）。如dsh-bash-local把能力暴露成Agent可调用的工具。可替换：bash-sandbox/pwsh-local/E2B。Consumer消费方（工具/插件）。通过inject声明依赖，使用ctx.shell执行命令。与Provider互不依赖，只依赖Definition。关键设计：Definition只声明服务与类型，几乎不变；Provider可以独立替换，换一个提供方（比如换成沙箱执行），通过cordis.yml改一行配置，Definition和所有Consumer保持不变，依赖方自动重载。Consumer与Provider互不依赖。这套模式就是"一切皆插件"在能力层面的落地：每一项能力都是一个seam（接缝），接缝两侧可以独立演进。替换提供方的方式在cordis.yml里改一行：Definition和所有Consumer保持不变，依赖方自动重载。不需要改任何源码，不需要重启进程。这就是声明式组合的威力。开发入口：三种方式把插件装进去1patch覆盖层（最快）写一个YAML，dshweb--patch./my-plugins.yml启动时插入条目。适合快速测试和临时插件。2profile的cordis.patch.yml常驻生效的用户层。放在$DSH_HOME/profiles/名字/下，每次启动该profile时自动加载。适合个人常用插件。3bundle包（可复用的组合包）把一组插件打包成npm包，声明dsh.bundle.patch，成为可复用的"组合包"。适合发布和分享给他人使用。插件代码本身依然是Cordis那套函数、对象、类三种形态，inject声明依赖，ctx.effect管理资源，Schema校验配置，ctx.tools.register(...)注册工具。无论用哪种方式装进去，插件代码的写法都是一样的。区别只在于"怎么被发现和加载"。槽位总览：扩展点全部是服务DSH的扩展点不是一个"API列表"，而是一张Cordis服务注册表：任何插件都可以注册新服务，也可以替换已有服务的提供方。类别槽位用途现有提供方执行shellBash执行bash-local、sandbox执行codeRuntime代码执行code-runtime-worker模型llmLLM适配器llm-deepseek、pi-ai智能agentsAgent注册表agent-loop智能subagents子Agent提供方ACP、Codex、Claude数据sessions会话日志持久化jsonl、sqlite环境fs文件系统提供方fs-local、sandbox、e2b环境webWeb访问fetch-http、exa、perplexity治理approval审批权限策略sandbox、ox-policy编排goals/jobs长期目标后台任务dsh-goal、worker-thread前端slotsUI槽位客户端插件dsh-client-ui-*系列这正是响应式依赖的直接应用常用槽位按类别整理：执行（shell、codeRuntime、subprocess、lsp）、模型（llm）、智能（agents、agentLoop、subagents）、数据（sessions、storage）、环境（fs、web、credentials）、治理（tools、approval）、编排（goals、jobs、workflowEngine）、自指（dynamicCordisRunner）、前端（slots、clientModules）。每一项能力都是一个seam（接缝），接缝两侧可以独立演进。05论文与理论从"好用的框架"到"被证明的范式"CHAPTERFIVE论文概述：时空可组合性编程范式《AProgrammingParadigmforSpatiotemporalComposability》作者：YifanShi（北京大学/DeepSeek-AI）、WeiZhang（北京大学）、TianyiCui（DeepSeek-AI）88页预印本，cordiverse/paper仓库开源论文不是"给Cordis写说明书"，而是把Cordis的核心机制形式化，证明它们构成一种新的编程范式。论文里没有一句"我们的框架很优秀"，有的是定义、定理与证明。贯穿始终的主张动态组合（运行时装卸组件）缺乏形式基础；Cordis用两个运行时机制把它补上了，并证明了由此得到的性质。两个正交维度：时间维度（temporalcomposability）：组件被移除时，它对共享环境做的修改必须被完整、安全地逆转。空间维度（spatialcomposability）：组件必须能声明、发现、解析相互依赖。动态场景下依赖会出现、消失、更换身份。为什么这个问题被长期回避操作系统和容器编排提供了一个粗粒度替代：进程粒度的时间可组合性（进程死了状态全清）+服务粒度的空间可组合性（依赖交给编排器）。但代价沉重：每次重启丢弃全部进程内状态（缓存、连接、半成品计算），重建要花几秒到几分钟；跨地址空间的依赖无法用函数调用表达，只能走网络。插件生态：内置与社区内置插件（dsh-*包）按角色分四类工具类tool-bash、tool-fs、tool-fs-search、tool-web、tool-subagent、tool-workflow、tool-goal、tool-jobs、tool-skill、tool-ralph、tool-lsp、tool-cordis提供方类模型适配器（DeepSeek、pi-ai、replay）、shell提供方（本地、沙箱、PowerShell）、fs提供方、web搜索源、持久化后端系统类上下文压缩（compaction-basic）、token计量、消息反馈、权限预设、计划模式、长期目标、审批管道前端类dsh-client-ui-*数十个包，设置页、模型选择、插件管理、任务面板、子Agent面板、目标面板、主题社区插件生态（awesome-dsh-plugin，截至2026年8月收录174个）改界面：dsh-visualize（模型把交互式HTML卡片直接画进会话流）、dsh-TUI（像素鲸鱼顶栏的全屏终端UI）、dsh-deep-whale（Web皮肤）改记忆：dsh-memento（有界、分层、带审批、可审计的跨会话记忆）、dsh-mneme（SQLite+可编辑Markdown镜像）改能力：dsh-computer-use（控制macOS）、dsh-data-agent（帮AI连数据库写SQL）、dsh-docker（带护栏的容器控制）改协作：dsh-agent-teams（多智能体团队）、dsh-crosstalk（跨会话互发消息）、dsh-chat-import（导入ClaudeCode、ChatGPT聊天记录）自进化方向的社区插件dsh-evolve：让Agent在会话内给自己热挂载、卸载持久化插件dsh-continual-evolve：从会话轨迹沉淀可审计、可回滚的harness状态dsh-find-plugin：让Agent在会话内直接搜索并安装插件dsh-plugin-manager：提供dshpm多源插件管理理论支柱：effect与coeffect论文的两个支柱是编程语言理论里的两个经典概念，Cordis把它们从编译期静态分析工具提升为运行时机制。effect（效应）描述"计算对环境做了什么"：写文件、分配内存、发消息。源自Moggi的monad理论，Haskell的IO、代数效应与处理器都属于这条线。coeffect（余效应）描述"计算对环境要求什么"：需要读哪些配置、依赖哪些服务。源自Petricek等人2013年的工作，是effect的对偶。关键观察：这两个概念传统上都是编译期静态分析工具，类型系统在编译时检查"这段代码可能产生什么副作用、需要什么上下文"，约束是词法作用域内固定的。Cordis的论文把它们提升为运行时机制，让它们能在组件随时到达和离开的动态场景下工作。这是论文区别于既有工作的出发点。两层机制协同coeffect操作是effect，而effect可逆：set(k,v)的类型恰好是effect函数，注册一个依赖本身就是可逆effect，撤销提供方时依赖自动消失。这就是两层机制协同的地方。这就是inject的数学形式：inject:['greeter']就是声明d={greeter}，fiber保持PENDING直到σ⊨d。可逆副作用：把"撤销"做成结构保证时间维度的诉求是：卸载组件=恢复共享环境。论文把effect建模为：一个effect函数作用于当前上下文Γ，返回新上下文和一个逆函数（undo函数）。三个关键性质（论文6.3节）精确恢复如果每个逆都在它自己应用时的状态上执行，恢复是精确的（Theorem7,16）：按LIFO撤销时，每个逆面对的正是它当初执行时的上下文，因此一切状态都被还原。独立性论文定义两个effect独立，当它们的所有变换互相可交换、且互不干扰对方产出的逆。对独立的一族effect，可以按任意顺序撤销（Corollary21）。这正是"从交错运行的多个组件中单独撤掉一个"的理论基础。观察等价（非字面相等）恢复的语义不是"回到过去"，而是"任何观察者都看不出区别"——这是让可逆性在真实系统里成立的关键让步，也让独立性变得可达：两个操作留下的值只要≈等价，就算可交换。效应上下文的形式化定义定义效应上下文∂Γ=(γ,φ)：γ是当前状态，φ是累加器，到目前为止所有effect的逆的复合。track：执行effect时，把新状态写入γ，把它的逆复合进φ。recover：卸载时，把φ作用到当前状态，φ(γ)就回到初始状态。逆按相反顺序累积（twistedcomposition）：先执行的effect后撤销，天然LIFO。06生态与未来Koishi实战平台·通用生态·自进化Agent展望CHAPTERSIXKoishi：第一个实战平台论文的案例研究就是Koishi，并给出数据：四年间积累了4000+社区插件。从npmregistry核实了当前数字。生态规模（2026年8月实测）155@koishijs官方scope包3951koishi-plugin-*前缀包5800GitHubStar（koishijs/koishi）npm下载量：koishi近一年约34万次下载，cordis近一年约51万次（周均约1万）。官方FAQ称有数千位活跃搭建者，其中许多人的单个机器人就覆盖数万活跃用户。论文还指出了一个设计上的验证：Koishi的Web控制台是第二个独立的Cordis应用（浏览器里运行着另一棵插件树）；适配器、数据库驱动与功能插件之间形成了真实的依赖拓扑，切换存储后端或重连适配器时，只有依赖真正变化的那部分插件会被重新激活。这验证了"跨独立作者协作"的场景：插件与其依赖通常由不同作者编写，双方只通过服务契约（coeffect）协调。一个版本事实Koishi目前仍使用Cordis3.x（@koishijs/core依赖cordis:^3.18.1），而论文与DSH使用的是4.x。核心组合模型两代共享，但4.x重构了effect、coeffect语义与Loader。一个在Koishi圈写过几年插件的开发者视角：这套生态里的插件很少直接互相调用，大家靠服务契约（inject）和事件协作。写插件的人通常只关心自己声明了什么依赖、注册了什么效果，谁先启动、谁依赖谁、谁负责清理，是Cordis的事，不是作者的事。@cordisjs：独立的通用生态Koishi之外，Cordis还维持着一个独立的官方生态，@cordisjsscope下现有101个包，覆盖了一个通用应用框架所需的全部组件。通用应用框架的全部组件核心机制loader、plugin-loader、plugin-include、plugin-hmr、plugin-group、plugin-config、schema、timer、logger服务端plugin-server（含-acl、-proxy、-static、-temp、-webui）、plugin-http数据plugin-database及sqlite、mysql、postgres、mongo、memory驱动业务基础设施mail、sms（多家供应商）、sso（十几家登录方式）、webui控制台、market插件市场、manager（插件依赖关系图）、insight、cli、client、components、create-cordis（脚手架）这些包的存在说明：Cordis不是"为Koishi定制的内核"，而是一个真正通用的应用框架。Koishi与DSH只是它的两个实例，一个在IM领域，一个在Agent领域。生态背后的几件事：小且可审计（核心几千行TypeScript，DSH整体vendor进仓库并做了约18处本地修改）、实战验证（Cordis在Koishi生态经历了上千插件的并发运行考验）、TypeScript-first（声明合并让扩展点全链路类型安全，DSH甚至从这些声明自动生成供模型阅读的API目录，类型系统本身变成了Agent的操作手册）。Rust社区的跟进社区已经出现了cordis-rs：一个runtime-agnostic的Rust移植版，基于Cordis4.0.1实现，核心结构与TypeScript版一一对应（context、fiber、events、logger等模块）。这说明Cordis的编程范式已经超越了语言边界，开始在其他生态中落地。参考资料与延伸阅读论文与官方文档1.YifanShi,WeiZhang,TianyiCui.AProgrammingParadigmforSpatiotemporalComposability.arXivpreprint,2025.2.Cordis官方文档：3.CordisGitHub仓库：/cordiverse/cordis4.论文仓库：/cordiverse/paper5.DeepSeekHarness官方仓库：/deepseek-ai/DeepSeek-Harness6.DSH官方文档：/harness7.Koishi官方文档：https://koishi.chat8.KoishiGitHub仓库：/koishijs/koishi9.@cordisjsnpmscope：/org/cordisjs10.awesome-dsh-plugin社区插件列表：/awesome-dsh/awesome-dsh-plugin相关理论与背景1.EugenioMoggi.Notionsofcomputationandmonads.InformationandComputation,1991.（effect理论基础）2.TomasPetricek,DominicOrchard,AlanMycroft.Coeffects:Unifiedstaticanalysisofcontext-dependence.ICALP,2013.（coeffect理论基础）3.AndrejBauer,MatijaPretnar.Programmingwithalgebraiceffectsandhandlers.JournalofLogicalandAlgebraicMethodsinProgramming,2015.4.OSGiAlliance.OSGiServicePlatformCoreSpecification.（动态模块系统先驱）5.ReactHooks官方文档：https://react.dev/reference/react（effect/cleanup机制对比）6.ZIO官方文档：https://zio.dev（monadiceffect对比）7.Effekt语言：（代数效应