首页 文章 精选 留言 我的

精选列表

搜索[erp]，共3001篇文章
优秀的个人博客,低调大师

进销存 ERP 网页静默打印：出库单别再打到错的打印机上

做进销存的都懂：仓管点「打印出库单」，弹个 Chrome 打印框，再手选打印机——一天几十单还能忍，一到几百单，客服电话比出库还快。 产品提的需求通常就三句： - 不要弹窗 - 打到仓库那台激光机 / 针式机 - 格式跟现在单据差不多 前端第一反应经常是 `window.print`。框还在，默认机还是财务那台，纸白打。jsPDF 更冤，做出来是下载文件，仓管要的是纸。 ## 这类系统真正卡在哪 浏览器不让网页随便捅打印机，这是安全模型，不是你项目写挫了。办公网里想静默，行业做法就一种：每台出纸电脑挂本机打印服务，页面把内容推过去。 老项目里常见 Lodop / C-Lodop。能跑就别全拆。烦的是新上的 Vue3 模块还要继续塞全局脚本、工位一升级又「打印没反应」。 ## 我现在新模块怎么接 票种不多、单据本身就是页面 HTML 的，我会用 npm 包 `web-print-pdf`：本机装配套客户端，前端 async 调一下。装法和普通依赖一样： ```bash npm install web-print-pdf ``` 出库单示意（字段按你们单据改）： ```js import webPrintPdf from 'web-print-pdf' export async function printOutbound(html, printerName) { return webPrintPdf.printHtml( html, { paperFormat: 'A4', printBackground: true }, { printerName, copies: 1 }, { action: 'print' } // 联调先 preview ) } ``` **打印机名字一定写进门店/仓库配置。** 别信 Windows「默认打印机」，谁装过驱动谁知道有多玄学。名字用包里的 `utils.getPrinterList()` 抄，别手打猜。 后端报表已经生成 PDF 的，别再转一遍 HTML，走 `printPdfByUrl` 或 `printPdfByBase64` 更直接。客户端要能访问到那个地址，鉴权链现场很容易栽。 ## 和 Lodop 怎么共存 老出库单、老套打继续 Lodop。新做的调拨单、对账单走新方案。字典加个打印引擎字段就行。对老板好讲话：不是推翻现场，是新模块试点。 参数以 npm 上该包说明为准。百度开发者中心这篇不放外链，需要细节自己搜包名。
2026-09-27
优秀的个人博客,低调大师

本体驱动ERP｜情报周报：本体 / RAG / Agent 正在一起向"图"收敛

# 这周我刷了 arXiv 和几个厂商动态，攒了 10 条跟咱们号直接相关的情报。一条主线越来越清楚：**本体派主张正在从论文概念变成企业 AI 的底座**——RAG 在长出自体结构，Agent 在找确定性溯源，连 Google 都用轻量本体（OKF）给"显式知识"背书了。 下面按三个方向归类。 --- ## 一、RAG 正在"长出"图与层级：本体派进主流叙事 4 条信号指向同一件事：多路检索 + 图遍历 + 层级结构，正在成为企业 RAG 的默认答案；大厂也开始用轻量本体给显式知识背书。 【1】VDGR-RAG：向量 + 目录 + 图 + 反思，统一推理企业层级知识 arxiv.org/abs/2608.07994 新框架把向量检索、目录驱动推理、图遍历、迭代反思整合进一个管道，解决电信等复杂文档场景的企业知识问答——现有 RAG 普遍忽视多路检索整合，导致领域路由不准、层级结构用不上。 我的判断："多路检索 + 反思"正在成为企业 RAG 的标准答案，图遍历不再是配角，值得深读。 【2】AkasicDB：把向量、图、关系型收进同一个数据库引擎 arxiv.org/abs/2608.09214 演示型论文，统一向量-图-关系型的 Omni RAG 数据库，不用再拼三套系统。 我的判断：GraphRAG 团队普遍是"三件套缝合"，跨库 join 慢、维护贵。趋势对，但别急着迁移。对做本体的人：结构化知识终于有"原生"待的地方了。 【3】Neo4j 喊话：图智能让企业 AI 落地更可靠 siliconangle.com · Neo4j GraphTalk Neo4j GraphTalk：企业正收敛到"用知识层把 LLM 锚定在可信组织数据上"的架构。 我的判断：厂商口径听听就好，但"企业知识层"这个提法值得记——和咱们说的"本体驱动 RAG"是一回事。本体派主张正进入主流叙事。 【4】Google Cloud 发布 OKF：用 Markdown+YAML 的"活 wiki"替代向量库 digitaltoday.co.kr · Google OKF 核心企业知识以 Knowledge Bundle（YAML 元数据 + Markdown 文档目录）组织成知识网络，目录路径即概念位置，靠链接检索而非向量相似度；与 RAG 互补，由 AI router 按问题性质分流。 我的判断：大厂给"显式结构化知识"路线背书，本质是轻量本体实践——目录即类目、链接即关系、Git 即版本与审计。对做本体的人，OKF 是个低门槛的"本体封装"：不上 OWL/SHACL 也能让 Agent 用上结构化知识；但表达力上限也在这，复杂约束和推理还得回本体语言。 --- ## 二、Agent × 知识图谱：本体是进企业的硬门槛 3 条信号：Agent 要的不是更聪明的向量，是确定性推理 + 可审计溯源。图，是这件事的原生载体。 【5】Semantica：给 AI Agent 做知识图谱的"开源版 Palantir" github.com/semantica-agi/semantica 图谱原生的 Agent 上下文与溯源层：确定性推理 + W3C PROV-O 审计轨迹，核心层不依赖 LLM。做向量库做不到的事——回答"系统为什么这么决策、事实从哪来"。 我的判断：Agent×本体结合点最值得盯的项目之一。审计溯源是 Agent 进企业的硬门槛。已进试用清单，后面可出星球实战。（这期我最看好的一条。） 【6】Cognee：图谱派 Agent 记忆工具，GitHub 29.9K stars techsy.io · Agent 记忆工具盘点 2026 Agent 记忆工具盘点，重点提 Cognee——把数据建成知识图谱、在图上回答，Apache 2.0，29.9K stars。 我的判断：29.9K stars 说明"图谱当记忆"已从论文走向工程。做 Agent 记忆选型的值得列入对比清单。 【7】RippleMem：从孤立检索到联想回忆的 Agent 长期记忆 arxiv.org/abs/2608.13334 Agent 长期记忆的瓶颈不在存而在"取"——证据散落在多次交互中，一次性检索拿不全。RippleMem 把交互历史存成带线索的片段单元，组织成事件中心记忆图，查询时做联想式回忆而非单次检索。 我的判断：事件中心图 + 线索依赖联想，本质是把"经验的关系结构"用图显式建出来，和本体里的事件/参与者/时空线索建模是一路。它给"图为什么比扁平检索强"提供了具体机制而非口号，做 Agent 记忆系统的本周最值得深读。 --- ## 三、Agent 记忆的"结构化边界"之争：正方反方都在场 3 条信号：结构化记忆到底值不值？反方说先看检索器，正方说关系结构能保留成规则，治理派说记忆要能被采信。本期最值得做对照讨论的一组。 【8】ReFind（反方）：不做任何结构化，原始聊天记录也能匹敌 arxiv.org/abs/2608.12888 直接挑战"先建摘要/向量/树/知识图谱再检索"的主流路线：ReFind 不建任何语义结构，只做词法索引 + 迭代关键词搜索 + 四个聊天原生控制，在多项对话记忆任务上与结构化记忆打成平手。 我的判断：给"一切知识都要上图谱"的人泼的冷水。结论不是图谱没用，而是"别把检索质量全归功于结构，先看检索器够不够好"。对本体从业者是个必须正视的对照问题：结构化的收益要有实验支撑，否则 ROI 讲不清。 【9】GPM（治理派）：给记忆上"源绑定 + 双时态 + fail-closed" arxiv.org/abs/2608.12476 Agent 记忆不能只做 select-store-retrieve，还得回答"这条记录现在能不能支持我的输出"。GPM 提出可审计的双时态状态转换模型：源绑定准入、冲突隔离、撤回/删除后不得复活、fail-closed 释放，3600 例基准全对。 我的判断：把数据库的事务语义和本体里的"来源、时效、撤销"问题搬进 Agent 记忆。做记忆治理、审计合规场景（金融、医疗）的人可直接借鉴——比给记忆加个 schema 深一层，解决的是"记忆能不能被采信"。 【10】GraphRAG 落地威胁情报：图谱能否产出更耐用的检测规则 arxiv.org/abs/2608.13050 把安全报告喂给 Microsoft GraphRAG vs Naive RAG，看谁产出的检测计划更依赖 Pyramid of Pain 顶端的持久线索（TTP、工具、基础设施），而非几小时就失效的 IP/域名/哈希。 我的判断：难得的 GraphRAG 对照实验，场景选得好——威胁情报里"关系性线索"（攻击链、基础设施归属）恰恰是向量检索最弱的地方。做安全 KG 或 GraphRAG 选型的人值得读：它检验图谱能否把跨实体关系保留成可执行规则。 --- ## ■ 本周主线收一下 把 10 条收拢，结构化知识有**三级梯度**： **轻量层**：OKF 目录 / YAML（低门槛，Git 即版本） **图 层**：知识图谱 / Agent 记忆（关系显式，可溯源） **严谨本体层**：OWL / SHACL（复杂约束 + 推理，表达力上限） 不同场景选不同层，但**"关系显式化"是共同方向**。咱们做本体的人，这半年最大的变化是：**不用再解释"本体有什么用"了——大厂和论文在替我们解释。** **下期预告：**我挑 **Semantica** 拆一篇星球实战——它是"Agent 需要本体"最有力的工程证据：图谱原生 + PROV-O 审计 + 核心层不依赖 LLM。想看的回复 **语义**。 📡 关注「本体与AI」

2026-09-09
优秀的个人博客,低调大师

本体驱动ERP | Apache Ossie 进孵化器那天，我翻出了 2019 年的本体笔记

# 7月10号那条消息刷了我几个群：Snowflake 拉着 Databricks、dbt、Salesforce 等 50 多家公司，把 Open Semantic Interchange 送进了 Apache 孵化器，新名字叫 **Apache Ossie**。 我做的第一件事不是转发新闻。是从硬盘深处翻出 2019 年那份被甲方毙掉的本体方案，看了一遍。 五年前我跟客户说"你们需要一个正式的本体模型来统一业务语义"，对方问"本体是什么？能装到 Hadoop 里吗？"方案毙了。五年后的今天，同一拨人坐在一起定义 YAML 格式的语义标准，**而且他们管这叫"Ontology Representation Working Group"**。 世界真有意思。 ## ■ Ossie 是什么：不是一个工具，是一份协议 先把话说清楚，免得有人跟我当初一样先入为主。 Ossie 不是一个数据库，不是一个查询引擎，不是你装到生产环境跑的东西。它是一份厂商无关的 YAML/JSON 规范，用来描述"数据是什么意思"。你的 BI 工具读它，知道 MRR 怎么算；你的 AI Agent 读它，知道这个字段叫"客户"而不是"用户"；你的数据治理平台读它，能跟你的数仓对齐业务词汇。 SnowflakeDatabricksdbtAI AgentBI 工具Apache Ossie 语义交换协议数据仓库数据湖业务系统 Ossie 不是中间件，是中间语言——各类工具通过同一份协议"说同一种业务话" 如果你写过 Parquet 文件、用过 Iceberg 表格式、接过 Polaris 目录服务，这套逻辑你应该很熟。数据社区解决碎片化的套路一直没变：**不统一工具，统一交换格式**。Parquet 统一了文件格式，Iceberg 统一了表格式，Polaris 统一了目录，现在 Ossie 要统一"含义"本身。 **一句话总结：**Ossie 让"同一个指标，在 Snowflake、Databricks、dbt、BI 工具和 AI Agent 里是同一个数"，而且不需要你手写 N×M 个点对点映射。 ## ■ 他们的"本体表示工作组"，我认真读完了 Ossie 目前有五个工作组。最让我坐不住的，是第四个：**Ontology Representation Working Group**——本体表示工作组。 你没看错。一个由 Snowflake、Databricks、Salesforce 发起的工业标准，把"本体"写进了工作组名称。我摘一段他们的原话： "Ossie 目前解决了结构互操作性——任何工具都可以读写通用格式的语义模型——但尚未解决概念互操作性，即不同模型可能用不同名称或结构描述相同的业务概念。本体层将让组织能够独立于数据存储位置，定义规范的业务概念（客户、订单、产品等），并让物理语义模型映射回共享定义。" 翻译成人话：**Ossie 不只是"这个字段叫 revenue"，而是要定义"客户"这个概念本身是什么，不管你的 CRM 把它存成 customer、client 还是 account**。这事我太熟了——过去五年我一直在用 OWL 干这个。 更让我意外的是，他们的本体模型（在 `ontology/ontology.md` 里）设计得意外地完整。我拆解一下： |Ossie 本体组件|含义|OWL/RDF 对应| | --- | --- | --- | |EntityType|独立可引用的业务实体（人、公司、订单）|owl:Class| |ValueType|带语义的数据类型（身份证号、行号）|rdfs:Datatype| |extends|概念继承（Employee extends Person）|rdfs:subClassOf| |identify_by|用什么关系来唯一标识一个实体|类似 owl:hasKey（OWL 2）| |multiplicity|关系基数（OneToOne / ManyToOne）|owl:FunctionalProperty| |derived_by|派生规则（EXISTS、条件表达式）|类似 SWRL / SPARQL CONSTRUCT| |requires|约束表达式|类似 owl:Restriction| |verbalizes|自然语言表达（{Person} earns {Salary}）|类似 rdfs:label / 注释属性| 来看一个实际例子——Ossie 的 Person 概念： ``` ontology: - concept: Person type: EntityType identify_by: [nr] relationships: - name: nr roles: - concept: SocialSecurityNr verbalizes: ['{Person} is identified by {SocialSecurityNr}'] multiplicity: OneToOne - name: earns roles: - concept: Salary multiplicity: ManyToOne verbalizes: ["{Person} earns {Salary}"] - concept: Employee type: EntityType extends: [Person] derived_by: ["EXISTS ( Person.earns )"] ``` 如果你写过 OWL，这种"定义类、定义属性、定义约束"的套路太熟了。只不过 Ossie 用的是 YAML，不是 Turtle；用的是 ANSI SQL 表达式，不是 SWRL；用的是 `verbalizes` 做自然语言标注，不是 `rdfs:comment`。 ## ■ 体感：行业在从另一个方向爬山，跟我走的是一条路 这是我读完 Ossie 本体规范后最大的感受。 学术界 · OWL/RDF/描述逻辑1970s—现在工业界 · SQL/YAML/dbt/BI语义层2020s—现在← 山巅相遇 →描述逻辑指标口径OWL 2 DL语义层Apache Ossie · 2026 一个很有意思的现象：学术界从逻辑往下走，工业界从需求往上升，在山顶碰上了 2019 年我在项目里推 OWL 本体的时候，甲方最常问的问题是："这玩意儿能直接查数吗？"我说不能——本体是推理用的，不是查询引擎。于是方案毙了。但回头看，他们真正要的不是推理，是 **"同一个'活跃客户'不要被三个部门定义成三个口径"**。 Ossie 的聪明之处在于：**它没有试图解决"推理"问题，它只解决"对齐"问题**。它用 YAML 定义概念和关系，用 SQL 表达式做派生规则，用 `concept_mappings` 把物理表字段映射到业务概念——不碰推理机，不碰描述逻辑，不碰 Pellet、HermiT。整套设计哲学就是：**让 80% 的人能上手，不要求他们先学一学期知识工程**。 说句公道话。我至今觉得 OWL 的推理表达能力远超 Ossie——OWL 能做 disjointness、能做 cardinality 全约束、能跑 SWRL 规则链，这些 Ossie 全没有。但问题不在这里。问题是：**能让五十家竞品公司坐下来签字的，从来不是表达力最强的方案，而是刚好够用、人人能理解、迁移成本最低的方案。** ## ■ 对我们这些做本体的人，三点启示 翻完 Ossie 的 repo 和五个工作组的讨论记录，我整理出三点，每一点都跟我自己的项目直接相关。 **第一，本体工程的价值正在被行业重新发现——只是换了个叫法。**Ossie 管它叫"概念互操作性"、Palantir 管它叫"Ontology"、Goldman Sachs 的 Legend 管它叫"Data Model"——名字不同，干的是一件事：让机器知道"客户"不是一串 UUID，而是一个有属性、有关系、有约束的实体。如果你过去五年跟我一样被人问"本体有什么用"，接下来的两年你可能不用解释这个了。 **第二，不要把 RDF/OWL 当成唯一的输出格式。**我去年写的订单本体全是用 Turtle 写的，内部推理非常爽，但跟团队其他工具对接时——dbt 读不了 Turtle，Tableau 读不了 Turtle，AI Agent 也读不了 Turtle。Ossie 的出现说明一件事：**本体可以写成 YAML，而且 50 家公司都认**。我的建议是：把 OWL 留作推理的"源码"，把 Ossie YAML 当作分发的"编译产物"。这跟写 TypeScript 编译成 JavaScript 是一个逻辑。 我在自己项目里试了一下映射——把订单本体的核心六个类（Order、OrderLine、Product、Customer、Contract、Payment）转成 Ossie 格式，花了不到半小时。输出如下： ``` # 订单本体 → Ossie 映射示例 ontology: - concept: Order type: EntityType identify_by: [orderNr] relationships: - name: orderNr roles: [{concept: OrderId}] multiplicity: OneToOne verbalizes: ["{Order} is identified by {OrderId}"] - name: belongsTo roles: [{concept: Customer}] multiplicity: ManyToOne verbalizes: ["{Order} belongs to {Customer}"] - name: governedBy roles: [{concept: Contract}] multiplicity: ManyToOne verbalizes: ["{Order} is governed by {Contract}"] ``` **第三，赶紧关注这几个 Working Group 的讨论。**Ossie 的 Ontology Representation WG 目前正在讨论关系本体（Relational Ontology）和共享语义定义（Shared Semantic Definitions）。这条线的走向会直接影响未来两三年企业数据架构该怎么设计。Discussion #22 和 #101 是两个必读的讨论串，我把链接放在关键词回复里。 ## ■ 坦白说，Ossie 现在还嫩 得说实话。Ossie 目前版本号是 `0.2.0.dev0`，还在快速迭代。它有几个明显的短板： ``` HermiT、Pellet 推理机 ``` 换句话说：**Ossie 是"语义交换层"，不是"语义推理层"**。它解决的是"大家说同一种话"，不是"从已知推导未知"。如果需要做本体一致性验证、自动分类、规则推理——该用 Pellet 还是得用 Pellet。 但我觉得这才是最健康的分工。Ossie 管交换和对齐，OWL 管推理和验证。一个负责"大家都认"，一个负责"逻辑严密"。谁也别替代谁。 ## ■ 最后 五年前我拿着一份 OWL 本体方案在会议室里被人问"这个跟 BI 有什么关系"，五年后 BI 厂商自己发了份本体标准。行业没变方向，只是换了一拨人、换了个角度，走进了同一扇门。 如果你做本体工程做了几年，有时候觉得孤单——翻翻 Ossie 的 GitHub repo。50+ 家公司，用 YAML 写"概念-关系-约束"。可能没你写得严谨，但他们带的资金、工程师、用户，个个比你多。 **你的团队在用什么管业务语义？dbt metrics？自建本体？还是全靠代码注释？**
2026-09-09

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册