首页
学习
活动
专区
圈层
工具
发布
技术百科首页 >Cordis >Cordis 为什么选择零运行时反射依赖?

Cordis 为什么选择零运行时反射依赖?

词条归属:Cordis

Cordis 刻意不依赖 reflect-metadata 等运行时反射设施,而是基于 TypeScript 的声明合并与类型推导来实现依赖管理,这一选择出于工程与生态两方面的考量。

1. 极致轻量与零运行时冗余

不引入反射意味着框架没有额外的元数据收集与装饰器求值开销,核心代码得以压缩到约 2000 行,运行时除 Node 与 TypeScript 内置能力外没有任何第三方依赖。这使得 Cordis 可以同时在 Browser、Node、Bun 等环境下运行,不被任何特定运行时或绑定所限制。

2. 更贴合 TypeScript 语义

传统依赖注入框架(如 NestJS、InversifyJS)依赖装饰器与反射,侵入性强且与 TypeScript 的类型系统存在割裂。Cordis 改用声明式依赖声明加模块补充的方式,依赖关系通过 inject 字段与类型拓展表达,既能获得完整的类型推导,又不需要开发者编写繁重的装饰器样板代码。

3. 面向动态插件生态

反射型 IoC 容器通常在应用启动时一次性装配好对象图,之后基本不再变动,这对静态系统足够,却无法应对插件随时来、随时走的动态生态。Cordis 通过声明式依赖加反应式响应,让依赖关系在运行时可被追踪、可被撤销、可被重建,从根本上服务于"可卸"这一目标。

相关文章
为什么要选择VersionCatalog来做依赖管理?
很多人都介绍过Gradle 7.+提供新依赖管理工具VersionCatalog,我就不过多介绍这个了。我们最近也算是成功接入了VersionCatalog,过程也还是有点曲折的,总体来说我觉得确实比我们当前的ext,或者说是用buildSrc的形式进行依赖管理是个更成熟的方案吧。下面是几个介绍的文章,尤其可以看看三七哥哥的。
逮虾户
2023-02-02
1.1K0
Cordis:从开源 QQ 机器人内核到 DeepSeek Harness 平台底座
假设你写了一个聊天机器人,最初逻辑都在一个文件里。功能变多后你开始拆模块,但模块化只解决"代码怎么组织",解决不了另外四件事:
Lss233
2026-08-18
2.2K1
我扒了 DeepSeek Harness 的源码,发现 AI Agent 框架的终极形态长这样
系列:DeepSeek Harness 源码实战 | 进度 1/16 原文仓库:https://github.com/deepseek-ai/deepseek-harness
怕浪猫
2026-09-11
3060
拆解DeepSeek Harness(二):Cordis 元框架与可组合性
在 LLM Agent 系统中,模型只提供生成能力,真正决定系统能否稳定运行的,是围绕模型构建的执行框架:它需要管理 Prompt、工具、上下文、策略、评测与运行流程。Deepseek Harness 正是这样一层用于组织、执行和实验的“执行壳”。但当模型、工具与任务不断增多时,简单的拼接方式很快就会遇到复用难、扩展难、回放难的问题。因此,Harness 需要一种更高层的抽象,把各类能力统一定义为可注册、可组合、可运行的对象。这正是 Cordis 元框架要解决的问题。
用户11320522
2026-08-19
5050
从架构看 DeepSeek Harness rc.8:一个"一切皆插件"的 Agent 运行时
摘要:DeepSeek Harness(dsh)是 DeepSeek AI 开源的 Agent 运行时框架,其核心理念是"Everything is a Plugin"。本文不讨论模型能力,只从架构层面拆解它在 v0.1.0-rc.8 版本中的设计:以 Cordis 微内核为基础的插件体系,以及 Context / Service / inject 三者构成的依赖调度机制,最后落到 rc.8 在子代理、存储、终端三个方向上的实际改动。
Archive
2026-08-21
4640
点击加载更多
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
领券