DeepSeek Harness Hub
← 返回列表

nomicore-ai/nomicore

DeepSeek Harnessspec-screened在 GitHub 查看 ↗
需源码安装

为 Agent 而生的数据库。

暂不能直接安装(需源码编译或环境不满足):缺少 main/exports/bin 入口声明;仓库 package.json 标记 private,未发布到 npm,需从源码安装。 · 最近上游提交 2026/9/16 · 已提供中文文档

一个面向AI代理的自描述、受治理的数据核心——模式、权限、验证和语义上下文随数据一同传递。

综合分
32
GitHub 分
32
用户评分
★ Stars
3
周下载量
安装插件(需先安装 dsh CLI 引擎:npm install -g @deepseek-ai/dsh)
dsh plugin --profile web add nomicore-ai/nomicore
缺少 main/exports/bin 入口声明;仓库 package.json 标记 private,未发布到 npm,需从源码安装,改用 GitHub 源安装
数据截至 2026/9/18(元数据每日更新 · 实装验证按队列轮转,单条结论的验证时间见上方)
安装兼容性检查需源码安装

以下结论由程序自动检查 npm 包、engines 声明与入口文件得出,未做人工实机验证——能装不等于用着没问题。

npm 包nomicore(未发布到 npm,仅可源码安装)
Node 引擎要求 >=20 · 基线 Node 22.19 满足
dsh CLI 依赖未声明 dsh 版本约束
入口文件缺少入口声明

缺少 main/exports/bin 入口声明;仓库 package.json 标记 private,未发布到 npm,需从源码安装

验证方式:npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/18 21:08:51

用户评分
还没有人投票,来当第一个
订阅周报,不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动

README

Nomicore

英文 |

CI

为 Agent 而生的数据库。

面向 Agent 的数据库

示例:当 revenue: 120 不够用时

假设一个 Agent 从传统数据库收到这样的结果:

{
"month": "2025-01",
"revenue": 120
}

这个值看起来很简单,但 Agent 无法在不提出更多问题的情况下安全地使用它:

- revenue 是以美元、千美元还是其他货币计量的?
- 它是已确认收入、已开票收入,还是已收现金?
- 它是否包含税费、退款和公司间交易?
- 这条记录是由哪个 schema 版本生成的?
- 该定义在本月与历史记录之间是否发生了变化?

使用 Nomicore,结果中同时包含数据以及解释数据所需的信息:

{
ok: true,
value: {
month: '2025-01',
revenue: 120
},
schema: # readData []

{
month: Pattern // Reporting month in YYYY-MM format
revenue: Range // Recognized revenue in USD thousands, excluding tax and refunds; accounting policy 2025-v2
}
,
truncated: false
}

Pattern 表示该值必须匹配指定的格式。Range 表示该值必须是处于该范围内的数字。注释解释了每个字段的含义以及应如何解释它。

现在,Agent 知道 120 表示在会计政策 2025-v2 下已确认的 120,000 美元收入。如果一条较早的记录使用不同的结构或定义,该记录可以保留自己的 schema 和语义,而不会被静默地按最新规则解释。

当这个结果被发送给另一个 Agent 时,它的 schema 和语义会随之一起传递。接收方 Agent 无需访问单独的数据字典或未记录的组织背景,就能正确地解释该值。

为什么选择 Nomicore

为什么传统数据库在 Agent 时代力不从心

传统数据库主要是为人类编写的应用程序而设计的。应用程序可以预先编码数据结构、业务规则和错误处理,但 Agent 处理的是动态任务,必须在读取、修改、共享和监控数据的同时理解数据及其边界。传统数据库在每一步都留下了重要的缺口:

1. 数据到达时没有完整的说明。 数据库查询通常只把数据交给 Agent,而不提供其 schema。即使单独获取了 schema,它也很少包含每个字段的业务语义。Agent 可能知道某个值是数值,却不知道它的单位、范围、计算方法或适用版本,从而不得不猜测或到别处查找文档。
2. 写入缺乏可强制执行的约束。 当约束仅存在于应用代码或人为约定中时,修改数据库的 Agent 无法可靠地判断其写入是否有效。拼写错误的字段、错误的类型或违反的业务规则可能在没有任何明确警告的情况下进入数据库,并进一步传播。
3. 对错误更改没有低成本的撤销手段。 传统数据库要么缺乏单个语义更改级别的回滚,要么需要事务、备份或整库恢复。回滚粒度粗、操作复杂且成本高昂,因此一次误编辑可能影响大量无关数据。
4. 数据无法单独安全共享。 当一个 Agent 将查询结果发送给另一个 Agent 时,通常只发送值——而不发送模式和业务语义。接收方使用自己的假设来解释数据。随着参与者和版本数量的增长,结果很快变得不一致且令人困惑。
5. 模式演进拖慢迭代。 一旦模式发生变化,通常必须迁移所有历史数据,以便新旧记录能够继续使用相同的应用逻辑。数据集越大、越旧,成本和风险就越高,使得模式演进变得谨慎而缓慢。
6. Agent 无法自然地感知数据变化。 当数据发生变化时,Agent 通常不会收到通知。为避免基于过时信息采取行动,它必须在每次使用前重新读取数据。反复将大型数据集加载到提示中既缓慢又消耗大量上下文。

自我解释的数据

Nomicore 将每一条数据与其模式和语义绑定在一起。当 Agent 检索数据时,它同时获得理解其结构和解释其含义所需的信息。因此,数据是自描述、自解释的,而不是依赖于隐藏在别处的上下文。

每一条数据都携带自己的模式和语义定义。不同的形状和定义可以共存,而无需首先强制每个生产者和消费者对齐到一个全局版本,或一次性迁移所有历史数据。

这也使 Nomicore 天然适合 Agent 协作。当一个 Agent 将数据发送给另一个 Agent 时,相关的模式和语义随之一起传递。接收方 Agent 可以从数据本身确定如何读取数据,从而大幅减少歧义和误解。

能力

- 使用熟悉的语法定义数据:用类似 TypeScript 的语法描述数据结构,并直接在那些定义旁边编写字段含义、业务规则和解释指南,使人类和 Agent 都能读懂。
- 在数据库内核中强制执行 Schema 约束:每次写入都会根据其 Schema 进行验证。无效数据在存储边界被拒绝,防止结构和业务约束随时间漂移。
- 实时响应数据变更:数据一经更新,Agent 即可收到变更信号并立即响应,无需定期轮询或反复读取整个数据集。
- 以多种方式访问和搜索数据:按路径读取精确的字段、对象或集合;限定读取的深度和宽度,只获取大型结构的一部分;或对数组和键控集合使用窗口读取,按索引、键或字段排序,以选取最新条目、稳定范围或 Top-K 结果。每次读取还会返回适用的数据规范和业务语义。
- 原生支持参与者之间的协作:多个参与者可以通过细粒度、可合并的变更持续修改同一份数据。这既支持 Agent 与 Agent 之间的协作,也支持 Agent 与人类在共享的单一事实来源上进行协作。
- 可嵌入任何位置并横向扩展:将 Nomicore 作为模块嵌入任何应用程序,或将其作为独立服务运行。随着需求增长,可将其部署为 Hub/Peer 复制集群,在各节点间拥有完整副本。
- 原生支持 DeepSeek Harness:Nomicore 可以直接为 DeepSeek Harness 提供持久化、感知 Schema 与语义的数据访问,以及跨 Session 和 Agent 协作的共享数据基础。

了解更多

- 安装、集成、部署与开发
- 权威领域术语
- 架构决策
- 实例复制通信协议

上游仓库有新提交时邮件通知你(每天最多一封,无更新不打扰),随时一键退订。

💬 加入 DPharness 群聊

插件用法、部署报错、新插件第一时间同步——群里问,比一个人翻文档快。

点击加入 QQ 群
DPharness 群聊二维码,手机 QQ 扫码进群
扫码进群