# 随笔 — Patrick Colm Audley *工作笔记、立场文章与短篇随笔。转载自各平台，使其不随任何单一平台消逝。* 作者： [Patrick Colm Audley](https://patrickaudley.com/) · 许可证： Creative Commons BY-NC-SA CAv2.5 · 规范主页： 每篇文章亦以独立 Markdown 格式提供，路径为 `/posts/{slug}.md` 。 --- ## PurRDF 1.0：一个 RDF 引擎，一套行为，贯通各语言 **日期：** 2026-09-02 · **转载自：** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7501321819077898240/) · **标签：** `rdf`, `rdf-1.2`, `sparql`, `shacl`, `shex`, `semantic-web`, `knowledge-graphs`, `linked-data`, `Rust`, `python`, `webassembly`, `开源` > PurRDF 1.0 发布：一套 RDF 1.2 工具包，以 Rust 编写一次，并逐字节移植到 Python、WebAssembly/JavaScript 与 C。带排序的全文检索、空间谓词与向量相似度，均在同一数据集上由 SPARQL 于进程内直接应答——而这三件事，过去往往迫使 RDF 项目在三元组存储旁另设一个 PostgreSQL。 **PurRDF 1.0.0 已发布。**这是一套 RDF 1.2 工具包：以从零编写的 Rust 核心实现一次，再原样移植到 Python、WebAssembly/JavaScript 与 C。 它所针对的问题，是 RDF 工具在两个维度上的割裂。跨语言方面，每个生态都有自己的解析器，各带其缺陷与各自实现的规范子集；于是一张图从 Rust 服务流向 Python 管线、再流向浏览器，其含义已在无声中被改动三次。跨时间方面，RDF 1.2——三元组项、具体化节点、基础方向字面量——是该标准的当前修订版，而既有库几乎无一支持。 因此，引擎只实现一次。每个已发布的 crate 都可编译到 `wasm32-unknown-unknown` ；整个工作区亦刻意不设任何 Cargo feature flag：承载数据者，不应有可选行为。 在实践中我认为最有用的，是它从架构中*移除*了什么。通常迫使人们在三元组存储旁常驻一个 PostgreSQL 实例的三件事——带排序的全文检索、空间谓词与向量相似度——都在 PurRDF 内部作答：同一进程、同一数据集、同一条 SPARQL 查询，无需第二个数据库，也无需同步作业。全文排序采用精确定点 BM25，该 crate 内不含任何浮点运算。GeoSPARQL 1.1 将几何读作精确有理数，并在精确的 DE-9IM 上判定每一种拓扑关系，不依赖 GEOS 与 PROJ。最近邻检索是精确检索，而非近似。三者皆为确定性的：在服务器上与在浏览器标签页中，返回相同的行、相同的顺序——这是 Postgres 技术栈跨机器时并不给出的保证。 此外还包括：九种语法的原生 codec、RDFC-1.0 规范化、支持完整 Update 的 SPARQL 1.1/1.2 及受管控执行（宁可返回经认证的部分结果，也不给出错误答案）、SHACL Core 以及 SHACL-SPARQL 与 SHACL-AF、ShEx 2.1、自 RDFS、OWL 2 RL 直至 OWL 2 直接语义 tableau 的蕴涵机制——每次闭包都附带推理报告，使不完整的答案绝不会被当作完整答案交付——以及 GTS 单文件图传输。 两点实话。其一，1.0.0 并非功能版本：它就是 0.13.0 的代码树，经由 Trusted Publishing 在全部 21 个 crate 上重新发布。改变的是承诺本身。自 1.0.0 起，破坏性变更递增主版本号，次版本号只做增量添加，修订号只修缺陷。其二，C ABI 独立编号并仍处于 0.x；工作区的 1.0.0 对其不作任何承诺。GTS 覆盖 Rust、命令行工具、Python 与 C，但 WebAssembly 包并不暴露它。 每个引擎都由其官方测试套件把关，并已冻结在仓库内：shexTest 校验用例 1,105 / 1,105、W3C SHACL 129 / 129、SPARQL 求值用例 862 项通过、语法往返 264 / 264，以及冻结的跨语言 GTS 向量。 若想不装任何东西就试用 RDF 1.2，可用浏览器 playground；若想按图索骥，则有配套手册。代码仓库已开放：[PurRDF](https://github.com/Blackcat-Informatics/purrdf)。 欢迎在 [X](https://x.com/paudley/status/2095558962779459703) 与 [r/semanticweb](https://www.reddit.com/r/semanticweb/comments/1w6dpk3/purrdf_100_a_fromscratch_rdf_12_sparql_shacl_shex/) 参与讨论。 *独立版： · 规范锚点： * --- ## Logit Loom：把 token 边界变成可编程界面 **日期：** 2026-07-23 · **转载自：** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7486090856559677452/) · **标签：** `Rust`, `AI 工程`, `开源`, `llama.cpp`, `token 生成`, `模型引导`, `可复现推理`, `神经符号 AI` > Logit Loom 将 token 边界变成可编程的 Rust 界面：组合有序 logit 变换、观测精确 token 字节、在明确定义的边界停止、为 llama.cpp 会话创建检查点，并保留记录已执行机制的可序列化回执。 LLM 每次生成一个 token，但我们通常以轮次为单位消费它们——这样就错过了大部分乐趣！**Logit Loom** 将 token 边界变成可编程界面。你可以摆弄 token 流、调整 logits、准确观察哪些 token 被接纳，并直接进入生成循环内部。 我已将一套 Rust 工具包开源，用于围绕 `llama.cpp` 构建精确、可检查的生成管线：组合有序 logit 变换、观测精确 token 字节、在明确定义的边界停止、为会话创建检查点，并保留记录执行内容的可序列化回执。 它可作为自定义采样与引导、受约束生成、智能体运行时、可复现推理实验，以及神经符号系统机制层的基础。它不会替你编写那些有趣的部分，但会消除编写它们时的繁琐工作。 做自己的弗兰肯斯坦博士，探索智能体伙伴们初生的心智！ 代码仓库已开放：[Logit Loom](https://github.com/paudley/logit-loom)。 *独立版： · 规范锚点： * --- ## GMEOW：面向推理的数字存在超级词汇 **日期：** 2026-06-04 · **转载自：** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:share:7468346496736772097/) · **标签：** `ontology-engineering`, `semantic-web`, `owl`, `rdf`, `linked-data`, `knowledge-graphs`, `知识表示`, `ontology-alignment`, `local-first`, `AI 智能体` > 一个新的本体项目：GMEOW——面向 Web 的全局元数据与实体本体，一套以推理为中心、符合 OWL 2 DL、以 gUFO 为基的超级词汇，用于刻画个人或组织的数字存在。它铸造规范术语并向 FOAF、REL、DOAP、GEDCOM、PROV-O、ORG、schema.org、vCard 与 Wikidata 对齐，将来源、置信度、时间有效性与共指视为一等关切。 我启动了一个新的本体项目：**GMEOW**——Global Metadata and Entity Ontology for the Web（面向 Web 的全局元数据与实体本体）。 设计目标是一套以推理为中心、符合 OWL 2 DL、以 gUFO 为基的超级词汇，用于刻画个人或组织的数字存在。 它源于一个实际问题：一旦着手在真实的个人或组织记忆之上构建本地优先的代理，便会迅速撞上词汇碎片化。 联系人、电子邮件、文档、项目、笔记、法律协议、家谱、著作、账户、日历与社交存在，各自都有成熟却彼此孤立的世界描述方式。FOAF、REL、DOAP、GEDCOM、PROV-O、ORG、schema.org、vCard、Wikidata 等都承载着有用的结构——但没有一个能给出完整的形状。 GMEOW 的思路是铸造规范术语并向外对齐。因此它不去改写源数据，而是建立一个连贯的上层，使各表层词汇能映射到同一模型。该本体以 gUFO 为基，依 OWL 2 DL 约束校验，并围绕一个理念构建：来源、置信度、时间有效性与共指都是一等的建模关切。 项目按切片推进。首个切片是实体与联系人。每个切片都新增规范术语、SSSOM 对齐表、夹具与覆盖率报告，使进展可对照真实数据衡量，而非一厢情愿。 工具链本身也是要义所在：校验、推理、映射、Wikidata 核对、元数据、内容协商、文档、构建产物与发布支持都须干净运行。本体也应有持续集成的纪律。 我尤其欢迎来自以下领域者的反馈：OWL/RDF、上层本体、本体对齐、语义网发布、个人数据存储、来源模型、本地优先 AI 与代理记忆。 你在何处见过个人或组织知识图谱因词汇层过于单薄而崩坏？ 代码仓库已开放：[gmeow-ontology](https://github.com/Blackcat-Informatics/gmeow-ontology)。 *独立版： · 规范锚点： * --- ## Gmeow：邮箱即代理记忆，当存于本地 **日期：** 2026-05-24 · **转载自：** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7464480186072285184/) · **标签：** `开源`, `AI 智能体`, `gmail`, `mcp`, `local-first`, `semantic-search`, `knowledge-graphs`, `archives` > 有用的个人代理反复遭遇同一难题：其所需上下文早已存在，却并不在演示所偏爱的整洁处。它在邮件之中。gmeow 以 loopback REST、MCP、PostgreSQL、语义搜索、附件 sidecar、对象存储与本地知识图谱，使此邮箱基底可在本地为代理所用。 有用的个人代理反复遭遇同一难题：其所需上下文早已存在，却并不在演示所偏爱的整洁处。 它在邮件之中。 亦不止于消息本身。它在标签里，在半被遗忘的附件里，在旧项目线程、发票、航班变更、账户通知、旁路决策、引介、一次性承诺，以及诸多“你还记得那时……”的碎片里。这些碎片使邮箱更近于机构记忆，而非寻常通信。对工作中的代理而言，Gmail 不是收件箱。它乃一层基底。 `gmeow` 是我使这层基底可在本地发挥用处的一次尝试，同时不把它变成又一个云端导入管线。 设计在该平淡之处刻意平淡：向 Gmail 认证，水合邮箱，在本地缓存有用结构，暴露 loopback API，并给代理一个可查询的 MCP endpoint，而不把整个账户的钥匙交出去。其内里维护一份 PostgreSQL 目录，涵盖标签、线程、头部、MIME 结构、类别、图三元组、作业、同步状态与 embedding 分块；以 BLAKE3 内容寻址对象存储保存载荷；为附件构建 sidecar；并在其上叠加词法搜索、语义搜索与图遍历。 重要边界在此：`gmeow` 并非托管式邮件智能服务。 它面向受信任的单用户本地系统。默认绑定至 `127.0.0.1` 。它并不佯称自己是一款面向互联网的应用，再事后钉上一层半成品认证。若将其暴露给不受信网络，便已越出威胁模型。此约束并非不便；此即其要义。 我最关心的是面向代理的表面。一个本地编码或研究代理，应能提出如下问题： “找出我们敲定迁移计划的那个线程。” “给我看这个供应商发来、提到续约的附件。” “哪些人物、项目与主题同这封消息相连？” “概述此类别中最近未读的消息。” “记录相关元数据后将其归档。” 这与构建邮件客户端迥然不同。邮件客户端是给坐在玻璃前的人使用的界面。`gmeow` 则是为伴随人类工作的代理铺设之管道：搜索、读取、标签、联系人、类别、附件元数据、归档状态、语义查找，以及经由 REST 与 MCP 的图探索。 图这一部分，始见其趣。邮件中满是潜在结构：人物、组织、项目、文档、义务、反复出现的运维模式。部分结构明示于头部与标签。另一些则须待文本被抽取、类别被判定、分块被嵌入、关系渐次积累之后方显。我不想要一个仅在邮箱里做关键词搜索的代理。我想让它构建一张可用的本地地图。 此中亦有档案之念。我素来不喜这样的系统：一份工作记录唯一完整副本，竟活在他人产品边界之后。`gmeow` 始终顾及原始 RFC822 路径，在缓存归档对象之上暴露只读 IMAP 服务，并将附件视作一等本地对象，而非 API 响应末端悬挂的晦暗 blob。若邮箱乃长期记忆之一部，便应能有体面地保存之。 这是我预计会在整个 Google 表面复用的模式之首。Gmail 是显然的起点，因为邮件富含上下文；但同一种 local-first 形态也应适用于 Drive、Calendar，以及代理不断需要推理的其他服务。每项服务各有小型 daemon、本地缓存、对象模型、MCP 工具，以及刻意狭窄的信任边界。 当前状态：早期、立场鲜明，且已足够有用，可以开始自用试炼。Python、PostgreSQL、近似 FastAPI 的边界、用于 embedding 分块的 pgvector、本地对象存储、可选的 SOPS-backed secrets、服务账户委派或用户 OAuth，以及面向不需要 JSON 形式礼仪的 MCP 客户端，默认提供紧凑 TOON 响应。 若你正在构建需要对真实邮件而非玩具语料进行推理的本地代理，不妨试之。仓库已开放，粗糙边缘亦在其中：[gmeow](https://github.com/paudley/gmeow)。 *独立版： · 规范锚点： * --- ## 代理式编程需要锚定物理现实的人类签署 **日期：** 2026-05-21 · **转载自：** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7463256842350022656/) · **标签：** `AI 治理`, `软件安全`, `AI 编程`, `应用安全`, `零信任`, `DevSecOps` > 随着 AI 编程代理从被动自动补全工具转向可执行整条功能分支的自主贡献者，我们正冲向一个巨大的安全盲点：如何证明真实的人类确实在上线前审阅并验证了代理生成的代码？ 随着 AI 编程代理从被动自动补全工具转向可执行整条功能分支的自主贡献者，我们正冲向一个巨大的安全盲点：如何证明真实的人类确实在上线前审阅并验证了代理生成的代码？这并不是一个*新*问题，但现在无疑变得更加*紧迫*。 在我的工作中，我们重点构建面向 AI 代理的策略即代码护栏：使用 Common Expression Language 策略、Git hooks、沙箱以及 Model Context Protocol 服务器，确保自主代理即使在人不在环路中时，也不能交付违反团队标准的代码。 但即使最稳健的自动化关卡也只完成了一半。纵深防御的最终层仍需要真实的人眼审阅关键代码。在完全代理化的工作流中，传统 SSH 或 GPG 提交签名已经不够，而且常常已被自动化。若代理进程或本地环境被攻破，或被复杂的提示注入转移，这些存储的凭据可能被误导。人也可能只是偷懒。 我们需要一种以密码学方式绑定物理现实的零信任开发者确认模型： **生物识别验证：**快速、低摩擦的验证，例如 Face ID 或 Touch ID，证明一个活着且获授权的开发者正在屏幕前。 **时间验证：**确保人类批准精确发生在提交窗口内，从而消除重放攻击。 **地理物理验证：**确认开发者的物理位置符合预期遥测与可信边界。 当自主代理提出关键架构变更时，最终关卡不应只是 CI 流水线里的绿色勾号。它需要一个不可伪造的人类断言。 我目前正在为代理开发流程 设计这一防御层，也想向网络中的各位打开讨论：你的工程团队如何划分自动化策略执行与强制人类签署之间的边界？随着代理处理越来越大的代码库片段，我们如何防止审阅疲劳把人类验证变成自动盖章？ 欢迎讨论。我正在积极把这个验证框架从设计模式推进到真实的平台集成。如果你正在构建生物识别快速身份产品，或运营企业软件供应链安全平台，并希望探索与此验证框架 的试点集成，[请联系我](#contact)。 *独立版： · 规范锚点： * --- ## 标准 Graph Neural Networks 须借曲率语义流形方可致远 **日期：** 2026-04-22 · **转载自：** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7458177770238681088/) · **标签：** `拓扑数据分析`, `图神经网络`, `流形学习`, `知识表示` > 标准 GNN 于映射复杂文本归因时受结构性之制约；平坦欧几里得空间中之线性聚合必致语义漂移。欧德理愿与 TDA、几何深度学习及谱图理论之研究者相交。 标准 Graph Neural Networks 于映射复杂文本归因时受结构性之制约：平坦欧几里得空间中之线性聚合必致语义漂移。欲忠实映射高维知识，须过渡至曲率语义流形，使几何本身承载关系结构。 欧德理逾三十年间构建科学分析管线——基因组学、卫星影像、跨洲高可用金融系统——其一贯之主线乃：表征必须于数学上忠于其底层几何，否则数据一旦离开开发集，可解释性即刻丧失。 吾近期开源一框架，借流形学习与谱分析，于高阶语义向量空间中发现涌现之知识图谱关系。初步证明、简要预览及 Python 代码库见于 [paudley/nonlinear-semantic-graphs](https://github.com/paudley/nonlinear-semantic-graphs) ；驱动此设计之工作论文载于[发表著作](#emergent-knowledge-graphs)。 欧德理愿与专攻 **Topological Data Analysis**、**Geometric Deep Learning** 及 **Knowledge Representation** 之研究者与应用科学家相交——尤其从事测地线聚合或谱图理论之同仁——以推动此等思想落地于稳健之企业级部署。敬请于 [LinkedIn 原帖评论](https://www.linkedin.com/feed/update/urn:li:activity:7458177770238681088/) ，或[直接联络](#contact)。 *独立版： · 规范锚点： * ---