2026-11-10 · GitHub AI 日报

统计窗口2026-11-09 10:30 ~ 2026-11-10 10:30（北京时间），对应 GitHub `committer-date >= 2026-11-09T02:00:00Z` 之后的默认分支提交。本期共收录 **104** 个条目，其中精选 5 条，四类分布为 ① 29 / ② 20 / ③ 31 / ④ 24。

覆盖方向AI Coding / 编程智能体与技能生态 · 医学 / 临床研究 AI 与 Agent 技能库 · 健康管理 / 营养与食品 AI · 模型底座与 Agent 基础设施

去重说明已与 10-16 至 11-09 二十一期推送记录逐条比对（用 `grep -ho "https://github.com/[^/]*/[^/]*"` 抽出**累计 1256 个历史仓库全集**再逐一比对，且比对时统一转小写以免大小写变体漏网），本期 104 个条目**全部为首次出现，零重复**；5 条精选亦均为首次入榜。本轮检索共采集 **4237** 个 `search/repositories` 唯一候选（38 条单词查询 + 40 条健康/医学专项查询配合 `pushed:>2026-11-08` 日期限定），其中 150 个与历史重复、另有大批明显 SEO 灌水项，剔除后得 3311 个非历史候选，再**逐仓用 core 端点 `GET /repos/{o}/{r}/commits?since=&per_page=1` 核实默认分支提交**（多线程并发，读取 `Link` 头 `rel="last"` 页码作为精确提交数），**最终保留 3258 个在窗口内有真实提交的仓库**，人工挑选与信息密度筛选后定稿 104 个。**凡 `pushed_at` 显示更新但逐仓核实后落在窗口之外的仓库一律剔除，不凭 `pushed_at` 收录**；窗口内只有无实质意义的提交的条目亦已剔除——本期据此剔除了 4 个仓库（`reyamira/models` 窗口内 15 次提交全部是 `chore: update benchmark data` 的自动写入、`belkins/ai-dive-deep` 12 次是 `radar: auto-update` 的时间戳刷新、`nicedreamzapp/nicedreamzapp` 28 次是 `Profile:` 图片固定、`jamesgreenmsa/renal-aware-rfs-ai` 7 次是文件重命名与上传）。上一期已出现的 `garrytan/gbrain`、`vercel-labs/agent-browser`、`ruvnet/RuView`、`milind-soni/OpenMausBot` 等本期因核实到窗口内无新提交而未重复收录。

核验口径所有"今天有动作"条目均以 GitHub 提交记录核实，**精确提交数一律以 core 端点 `Link` 头 `rel="last"` 的页码为准**（`per_page=1` 时页码即总条数）。**星标与许可证取自 GitHub API 实时快照**（截至 2026-11-10 10:30 北京时间）。**许可证以 core 端点 `GET /repos/{o}/{r}/license` 读取的 LICENSE 文件实文为准，API 的 `spdx_id` 只作线索**——本期实测 `verifywise-ai/verifywise` 的 API 报 `NOASSERTION`，实文是 **VerifyWise Community & Evaluation License (VCEL) 1.0（已从 Business Source License 1.1 换掉）**；`kody-hq/kody` 实文是 **Functional Source License 1.1（FSL-1.1-ALv2）**；`margince/margince` 与 `bike4mind/bike4mind` 实文是 **Business Source License 1.1（源码可见，非开源）**；`saltylvn/dialed-kitchen` 实文是 **"All rights reserved" 的专有授权**；`marcnester/glycofy-api` 实文是**专有源代码声明**。另有 20 个条目经 core 端点逐一确认**仓库根目录没有 LICENSE 文件**，表中标注为"未声明"——**"未声明"不等于无授权条款，但选型阶段必须回查**。本期 104 个条目中 MIT 与 Apache-2.0 合计 63 个（61%），AGPL-3.0 6 个、GPL-3.0 3 个只能读不能抄，PolyForm 2 个（研究与非商用）、LGPL-3.0 1 个、BUSL-1.1 2 个与 FSL-1.1-ALv2 1 个属于"源码可见但非开源"，20 个未声明。

一、今日精选 5 条

1. meta/astryx：Meta 把内部用了八年的设计系统开了源，150+ 组件全部"开放内部结构"——它要解决的不是好看，而是让 agent 改 UI 时能读懂、能下手

地址：https://github.com/meta/astryx ｜ ★20,293 ｜ MIT ｜ TypeScript + React 19 + StyleX

事件内容

窗口内 152 次提交（11-09 至 11-10 持续进行，11-10 02:28Z 仍在提交），是本期提交量最高的项目之一，主线是 v0.7.11 版本（11-07 发布）的持续打磨。README 的定位一句话说清："An open source design system that's fully customizable and built for how we build now: by people and the agents working alongside them." —— 注意后半句：这是在讲"人和 agent 并肩工作"的时代，设计系统要同时对两者可用。

⭐⭐ 它的核心主张是"开放内部结构"，而这正是与大多数设计系统的分野：README 明确写 "Open internals. Components are built to be composed at any level, not locked behind a closed top-level API." —— 组件可以在任意层级被组合，而不是被锁在一个封闭的顶层 API 后面。 这个判断对 agent 极其关键：一个 agent 要改一个 UI，它必须能顺着组件树往下摸到具体那一层，而不是拿到一个只暴露 variant="primary" 这种黑盒开关的封装。
⭐ 底座是 React 19 + StyleX，组件全部走"预构建 CSS + 类型化 React 组件"这条路：README 说 "You import pre-built CSS and use typed React components — no build plugin, no styling library to adopt" —— 不需要装构建插件，也不需要为了用它而改造现有样式体系，这对已经有一套样式的项目几乎零接入成本。
⭐ 规模与来源都写得很具体：在 Meta 内部成长了八年，是公司内部最大、使用最广的设计系统，支撑 13000+ 个应用；开源版提供 150+ 个无障碍组件、品牌级主题（brand-level theming）、暗色模式、可直接发布的模板，以及一个 CLI。
⭐⭐ 窗口内的提交能看出它把"agent 与人共用"落到了哪些具体细节上：docs(ChatLayout): a reply gets one right edge with contentWidth="100%"; Markdown keeps its 680px measure —— 给 agent 写的一条排版规则：回复只有一个右边缘，Markdown 正文保持 680px 的阅读行宽。fix(DropdownMenu): a finger's hold-slide-lift no longer flashes the focus outline on the menu button —— 手指长按滑动抬起时不再闪现焦点框。test(interaction-harness): a late hand-off reads the caught start 与 test(Lightbox): a coast landing frozen late fails by name —— 两个交互测试都用"晚了才到的状态"命名，失败时报出的是这个具名场景而不是一个行号。
⭐ 组件可"swizzle"（换掉内部实现）：README 提到 "when you need to go deeper, swizzle ejec…" —— 意思是当你需要更深一层时，可以把内部实现换掉，而不必 fork 整个库。
⭐ 它现在仍是 Beta，但已开放 npm 包（@astryxdesign/core）、在线文档站、Storybook 与 Sandbox playground，并挂着 PR 欢迎徽章与 Discord 入口。

值得关注的原因

⭐⭐ "组件可在任意层级组合，不锁在封闭顶层 API 后面"——这一条直接治我 4P 平台前端的一类老问题。 我现在的 neteye 系统（端口 8899，含 admin 后台）用的是自己写的页面结构，每加一个功能就复制粘贴一份样式，长期下来必然漂移。"开放内部结构"意味着 agent 改 UI 时能顺着层级找到该改的那一处，而不是在黑盒封装外面打补丁。 对一个一人公司来说，"能被 agent 安全地修改"这件事本身就是一种可维护性 —— 这条我应该写进选型标准。
⭐⭐ "Markdown 正文保持 680px 阅读行宽"，这条约束正好是我公众号排版一直在做的事。 我一直强调移动端文字可读性（字号、排版），而 680px 是一个被明确写进组件契约的数字，不是"差不多"。"设计规范里写死一个可验证的数字，比写一句"要易读"有用一百倍" —— 我后续做 4P 平台的报告导出页与公众号排版模板时，应该照这个路子把关键排版参数写成可检查的常量。
⭐⭐ 两个交互测试的命名方式（"晚了才到的状态"、"滑翔落地被冻住"）值得我直接抄进自己的测试规范。 我在 11-08 期记过 lights-out 的 test-proof 闸门——"新增的测试必须在基线上跑出失败"。这一期 astryx 补上了另一半：失败时报告的应该是一个具名的用户场景，不是一个断言行号。 因为行号会随代码变动，场景名不会 —— 三周后有人看到 CI 红了，他需要知道的是"哪个交互坏了"，不是"第 412 行挂了"。
⭐⭐ "swizzle 内部实现而不必 fork 整个库"是许可与架构的双重设计。 这对一个每周只有 8 小时的人尤其重要：任何需要 fork 整个上游库才能做的定制，都是一笔我付不起的维护债。 这条应该进我的技术选型 checklist。
⭐ "Meta 内部用了八年、支撑 13000+ 个应用、150+ 个无障碍组件"——这组数字说明它是被真实工程压测过的。 我做健康营养内容，最怕的是"看起来很美但没人真用"的设计稿；"支撑 13000+ 个应用"是使用量的硬证据。 而且组件默认带无障碍支持，这对我这种要服务中年及以上用户群的健康产品是刚需而非加分项。
⭐ MIT 授权，可直接商用。 本期 104 个条目里 MIT 与 Apache-2.0 合计 63 个（61%），astryx 是其中规模最大、授权最干净的一个 —— 对一人公司来说，"可直接用作底座"本身就是选型理由。
⚠️ 一句提醒：它仍在 Beta，150+ 组件的 API 稳定性不能假定。若要接进 4P 平台的生产界面，建议先只在新页面试用，并把版本号钉死。

2. github/squad：GitHub 官方下场做"一支人来指挥的 AI 开发团队"——它把团队成员的 charter（岗位说明书）写进仓库文件，让治理与代码住在同一个 git 里

地址：https://github.com/github/squad ｜ ★3,372 ｜ MIT ｜ TypeScript

事件内容

窗口内 23 次提交（11-09 至 11-10），主线是 v2.0.0-preview.4 预览版发布（11-09 19:04Z）。README 的定位一句话说清："Human-led AI agent teams for any project. One command. A team that helps you move faster with your code."

⭐⭐ 最关键的一条设计声明是它对"这是不是聊天机器人套帽子"的明确否认："It's not a chatbot wearing hats. Each team member runs in its own context, reads only its own knowledge, and writes back what it learned so the work stays inspectable." —— 每个团队成员跑在自己的上下文里、只读自己的知识、写回自己学到的东西，于是整件事仍然可审阅。
⭐⭐ 它把"人不被替代"写成了产品立场而不是免责声明：README 单列一节 "Responsible AI stance — Squad is built to amplify a human operator with GitHub Copilot, not to remove humans from the loop." 并在正文里再强调 "People stay accountable for priorities, approvals, and final changes" —— 人始终对优先级、审批与最终改动负责。
⭐⭐ 本期最大的一条提交把这条路线推进了一层：feat(claude): Claude projection v2: member subagents, skills, governance hooks, watch preset (#2450) —— 一个提交里同时出现了四个关键词：成员级子 agent（member subagents）、技能（skills）、治理钩子（governance hooks）、watch 预设。 也就是说，它不只做"多 agent 协作"，它开始做"给 agent 团队装上治理"。
⭐ 窗口内还有一条值得注意的提交：docs(claude): align Claude Code spec, docs and matrix with the code; add host projection regression guards (#2445) —— "规范、文档与矩阵三者对齐代码"，并为此加了回归守卫。这正是我 11-09 期记的那类教训：文档与实现不一致时，必须有一条会红的测试来裁定谁对。
⭐ 团队成员是有"charter"（岗位说明书）的实体：README 说 Squad 会"propose a team — each member named from a persistent thematic cast"，并且 squad init --preset default 能直接给出一支带成员、charter 与路由规则的完整团队。安装方式是文件进仓库——验证步骤就是检查 .squad/team.md 是否生成。
⭐ 团队配置以文件形态住在你的仓库里：.squad/decisions/decisions.md 承载决策记录（v2.0.0-preview.4 的更新日志里有一处专门删掉了这条文件上残留的过时 gitattributes 规则）。分发渠道覆盖 npm、Homebrew、WinGet 与独立安装包，且独立安装会自带 Node.js，不需要访问 npm registry。
⭐ 它已被包装成可被别的框架调用的组件：README 提到 .NET 侧的 Squad.Agents.AI NuGet 包，可以把一支 Squad 团队当作 Microsoft Agent Framework 的一个 agent 来调用。

值得关注的原因

⭐⭐ "每个成员在自己的上下文里、只读自己的知识、写回自己学到的东西"——这正好治我专家包体系现在最大的一个隐患：上下文串味。 我在 11-09 期记过 sprag 的"1M 上下文模型会借用另一个会话上报的窗口"这个 bug，并且提醒自己回头审计全局状态。squad 的答案更彻底：不是加锁，而是从架构上让每个成员根本看不到别人的东西。 对应到我的 4P 平台（Flask + SQLite 多会话），如果我把干预方案的生成、证据校验、报告渲染共用一个上下文包，那就等于让所有会话共享一个大脑——而 squad 的做法是：拆开，各自只读自己该读的。
⭐⭐ "人始终对优先级、审批与最终改动负责"这条，与我给自己划的那条红线是同一件事。 我明确禁止在任何内容里宣称医疗执业身份，理由不是道德洁癖，而是一人公司没有资格承担那个责任。squad 把同样的判断写进了产品定位：治理不是加在末尾的一节免责声明，而是贯穿在"谁负责"这个问题上的默认答案。 我的 4P 平台每份干预报告输出时，都应该有一个明确的"人负责"字段，而不是靠一句页脚免责。
⭐⭐⭐ "成员级子 agent + 技能 + 治理钩子"三件套同时出现在一条提交里——这是我做专家包（expert-manager）工作流最该盯的信号。 我现在的专家包质检流程是"让模型自评"，而 squad 的做法是把治理做成钩子、做成可继承的规则、做成会红的检查。这与我 11-08 期记的 samd-starter-kit 那 16 条工作流闸门是同一条路的官方版本 —— 而且是 GitHub 官方在做。 下期我该专门去看它的 governance hooks 具体长什么样。
⭐⭐ "规范、文档与矩阵三者对齐代码 + 回归守卫"，这条是本条提交里最便宜也最该抄的一条。 我在 11-09 期给自己列的四件事（证据类型标签、原文定位区间、规则的验证时间字段、失效扫描）都属于"约定"，而约定没有守卫就会烂掉。 squad 的做法是加一条回归测试来裁定"文档和代码不一致时谁说了算"。 这条我可以直接搬进我的内容流水线：每条公众号内容规范也要有一条测试。
⭐ "团队成员是有 charter 的文件"这个形态，对我很有启发。 charter = 岗位职责说明书 + 读取范围 + 输出格式。 我的四个算法（P4 本地 recommend.py / DINGXIANG / JINGYAN）目前只是一段说明文字；把它们写成带"允许读取范围"的 charter 文件，agent 才知道哪个能碰什么。
⭐ 安装路径全平台覆盖且独立安装自带 Node.js、不需要访问 npm registry** —— 这条对"在客户机器上跑起来"的场景是真需求，虽然我目前一人公司用不到。
⭐ MIT 授权，可直接商用。

3. wld007/dsh-medical-anonymizer：给 DeepSeek Harness 装一个"病历批量脱敏"插件——规则先跑、模型盲审、没查清的绝不静默通过，每一批都留下审计报告

地址：https://github.com/wld007/dsh-medical-anonymizer ｜ ★5 ｜ MIT ｜ JavaScript

事件内容

窗口内 47 次提交（11-09 至 11-10），v0.8.0 发布。README 的定位一句话说清："DeepSeek Harness 插件，用于批量匿名化病历文本和表格。它发现直接标识符，用稳定假名替换，保持文件结构不变，并输出审计报告和可还原的映射库。"

⭐⭐ 它的五条设计原则，每一条都值得单独抄下来：结构天然保持（"模型只负责标注文本；插件定位精确片段，只替换这些片段。行数、CSV 列、JSON 键和 Excel 非文本单元格都不会变动"）、规则优先，模型可选（"身份证校验位、电话/邮箱模式、带标签字段、列名/键名策略无需模型即可运行"）、有界修复循环（"复核轮次的发现会回到发现阶段，受轮次上限约束。未解决的条目标记为人工复核，而不是被静默接受"）、本地优先（"无遥测。插件只访问你配置的 OpenAI 兼容端点；指向本机运行时，数据就不会离开本机"）、输出可审计（"每个文件的实体统计、结构校验、残留问题、人工复核清单，以及唯一保存原值的映射库。报告不打印标识符原值"）。
⭐⭐ 校验机制里有一层是"模型盲审"：README 写 "模型盲审（不告知识别结果，可配置独立的核验模型）" —— 复核模型不知道识别结果长什么样，因此它是在独立地找漏网之鱼，而不是沿着识别模型的思路再走一遍。 后面还有规则复扫、原值残留检查与结构比对；"核验报出的残留由识别模型复判，分歧进入人工复核" —— 分歧不靠模型内部表决解决，而是升级给人。
⭐⭐ 覆盖范围比"病历"这两个字大得多：除了 .txt、.md、.csv、.json、.xlsx，还处理 .zip 压缩包（含嵌套） 与 DICOM 影像（只处理元数据）；字段里的编码内容会逐层拆开检查：base64、gzip、URL 编码、\u 转义、HTML 实体、HTML/XML、嵌套 JSON、HL7 等，拆不开的（图片、PDF、二进制、未知编码）转人工复核，复核完成前不交付。
⭐⭐ 标识符的覆盖面是按"中国医院真实的表头"来的：直接标识符包括姓名、医生/职工姓名、身份证号、电话、邮箱、地址、病历号、住院号、就诊号、社保号、银行卡号、医院名称；列名/键名策略直接覆盖 姓名、身份证号、电话、住址 等中文表头，以及 PTT_NM、ID_CRD_NO、CTCT_TEL_NO、CURR_ADDR*、*_DCT_NM、MDC_ORG_NM、PID、INHOS_NO 等院内系统键名；PRM_KEY/RCD_NO 等记录键按记录标识符遮盖。文件名与目录名里的姓名、身份证号、手机号、patient_<编号>、zyh_<住院号>、mzh_<门诊号> 也一并换成与正文一致的假名。
⭐ 假名是"按值和类型稳定生成"的：例如 化名-9F3A2C、证件-1F0B67，共用同一输出根的文件和批次中，同一个值得到同一个假名 —— 跨文件可对得上，且类型可辨。
⭐⭐ 窗口内的提交记录本身就是一次"自查自纠"的完整样本：Fix 12 high-severity leaks found in code review —— 一次性修掉代码评审发现的 12 个高危泄漏；接着 Fix remaining medium and low findings from code review 收尾；再往前是 Cross-check detail tab: every blind-review finding with context, reasons, outcome and human verdict —— 每一条盲审发现都要带上上下文、原因、结论与人工判定；还有 Model table: failure rate above context（失败率排在上下文之前展示）与 C3 cross-check: full layout placeholder before data（先给完整布局占位再填数据）。
⭐⭐ 它有一句自我定位写得极好："这是数据处理工具，不是合规认证。发布任何输出之前，请对照适用法律和本机构的政策进行审查。" —— 工具不替你承担合规责任，它只保证不把活儿干错。
⭐ 本地优先的具体承诺：插件从不调用内置云端模型，只走用户配置的 OpenAI 兼容端点（README 举例 Ollama 指向 http://127.0.0.1:11434/v1）；模型调用不设上限，多文件并发、文件多时自动分组、可取消、可撤销某批新增映射。

值得关注的原因

⭐⭐⭐ 我本机就装着 DeepSeek Harness，这条是直接可用的东西，不是"值得关注"的谈资。 我的记忆里明确写着本机跑着 dsh v0.1.0-rc.6 做原生 agent 开发——而这个插件正好补上 dsh 生态里我一直缺的那一环：处理真实医疗文本时的脱敏。 四类的 GRPM 报告、冀敏的基线体检数据、百十工程的参与者观察指标，这些东西一旦要喂给模型，脱敏就不是可选项。
⭐⭐⭐ "未解决的条目标记为人工复核，而不是被静默接受"——这一条直接命中我平台的现状。 我在 11-08 期记过 assay 的那句话："工具返回 success 只是提供方的断言，永远不是证明。" 这个插件的做法是同一件事的工程形态：脱敏不是"跑完了就算成功"，而是"每一条都有交代"。 对应到我的 OCR 管线：识别不出或置信度低的字段，现在应该进人工复核队列，而不是被默认值填平后一起写进报告。
⭐⭐⭐ "模型盲审（不告知识别结果）"是本条最值钱的一个设计。 这一招把"AI 检查 AI"从陪跑变成了独立复核。 我在 11-09 期记过 bmlib 的"撤稿四态"与"Cochrane 九域"，那条线的本质是别让同一个模型自己给自己盖章。盲审是同一原则的另一种落地：换一个不知道前面结论的模型，重新找一遍。 而我的 4P 平台目前所有的"自检"都是同一个模型在同一段上下文里做的——这在结构上就不可能发现自己的系统性错误。
⭐⭐ "分歧不靠模型内部表决解决，而是升级给人"——这是 AI 参与医疗链条里唯一站得住的分流规则。 识别模型与复核模型意见不一致时，让它们投票或让其中一个"再想想"，都只是把不确定性藏起来。升级到人，代价是人力，但代价出现在正确的位置。
⭐⭐ "报告不打印标识符原值，但另存一份唯一映射库"这个分离是有讲究的。 审计报告要能被交给第三方看，而映射库是要被严格保管的——这两者混在一起，报告就不能外发。 对应到我的平台：干预报告是给客户看的导出物，映射库是内部资产，两者必须走不同的权限边界。
⭐⭐ "结构天然保持"解决了我 OCR 管线的一个老问题：抽取会不会破坏原始结构。 README 明确保证行数、CSV 列、JSON 键、Excel 非文本单元格都不变 —— 这意味着"AI 处理后的文档"仍然可被下游工具按原样解析。 我的化验报告 OCR 如果也追求这个性质（解析结果与原文件结构对齐），就多了一条"处理后仍可复算"的保证。
⭐⭐⭐ 它的表头与键名清单是"中国医院真实的表头"，这份清单本身就是我 4P 平台化验 OCR 规则表的现成输入。 PTT_NM、ID_CRD_NO、CTCT_TEL_NO、INHOS_NO、mzh_<门诊号>、zyh_<住院号>——这些是我在真实病历里要处理的字段，但它已经把它们列全了。 我可以直接把它当成一份需求清单来对照自己的规则表，看漏了哪些。
⭐ MIT 授权，可直接商用；★5 星说明它是新项目、还很早期——这既是"可以自己抄设计"的机会，也是"要自己审代码"的责任。
⚠️ 它自己也强调"这不是合规认证" —— 这个态度我要学：我的任何工具也应该在输出里写明"这不构成合规结论"。

4. liliang-cn/cortexdb：把 agent 的记忆做成"一个 SQLite 文件里的知识图谱 + 本体约束 + 可追溯推理"，而且 Claude Code、Codex、DeepSeek Harness、Obsidian 全都接得上

地址：https://github.com/liliang-cn/cortexdb ｜ ★478 ｜ MIT ｜ Go

事件内容

窗口内 8 次提交（11-09 至 11-10），主线是 v2.148.1 / v2.148.2 连续发布。README 的定位一句话说清："AI memory and a knowledge graph in one SQLite file. Pure Go, no service to run, works without an embedding model."

⭐⭐ "works without an embedding model"是一个被低估的工程选择。 不用向量模型，意味着不依赖任何嵌入服务、不花钱、不需要 GPU，且召回是确定性的（不是"相近"而是"命中"）。 对于要给 AI 用的记忆层，"语义相似"带来的不确定性有时是负担而不是特性。
⭐⭐ 它的三种记忆机制是分层的：README 描述插件给 Claude Code 与 Codex 一个位于 ~/.cortexdb/cortexdb.db 的全局大脑，提供 /remember、/recall 与一个自动 recall 钩子；"A session starts with an index of what the brain knows about its project, an agent about to open a file is told what happened to it before" —— 会开某个文件的 agent，在动手之前就被告知这个文件之前发生过什么。 另有一条提交把这个边界划得更细：chore(release): v2.148.2 — a background task finishing no longer triggers a recall 与 fix(recall): don't recall for a background task's notification —— 后台任务完成不再触发召回，因为那不是人在提问。
⭐⭐⭐ 本体（ontology）约束是这一期最值得我注意的部分：窗口内连续三条提交都在动它——feat(ontology): an object type's aliases resolve on write and on read（一个对象类型的别名在写入与读取时都能解析）、fix(ontology): activating a vocabulary moves no name-keyed entity（激活一个词表不会移动任何按名字索引的实体）、以及 feat(liveview): every client's recall reaches the open page as it happens（每个客户端的召回实时到达打开的页面）。"别名在写入和读取时都能解析"意味着同一个东西的不同叫法，在系统里是同一个东西。
⭐⭐ "Planned recall"（计划式召回）是这一期最像产品的一处设计：README 写 "Before the brain is searched, haiku turns each prompt into keywords in Chinese and English, aliases, entity names and a retrieval mode. A bare 'ok' or 'go ahead' searches nothing." —— "ok"或"继续"这样的应答不触发搜索；输入框上方会显示召回了什么，可以展开看计划与每一条命中；隐藏状态持续到下次召回。 这一条把"agent 为什么想起这件事"从黑箱变成了可见的计划。
⭐⭐⭐ 接入面是我最关心的部分：README 的安装表里同时列出了 Claude Code（/plugin marketplace add liliang-cn/cortexdb）、Codex、DeepSeek Harness（dsh plugin --profile web add "github:liliang-cn/cortexdb#semver:^2&path:/plugins/dsh-cortexdb-memory"）、Obsidian（解压 cortexdb-obsidian.zip 到 <vault>/.obsidian/plugins/）、共享大脑服务器（cortexdb-grpc）以及 Rust / Python / Node 三种客户端。"Point several agents or machines at one cortexdb-grpc and they share the same memory and graph."
⭐ 记忆的隐私边界被写进了使用说明："a session's durable facts are captured with <private> text and credentials kept out" —— 标记为 <private> 的内容会被捕获，凭据类信息则被排除在外。
⭐ 有自诊断工具：cortexdb-mcp --doctor --self-test（v2.119.0+），可以在装不上或连不上时先自查。

值得关注的原因

⭐⭐⭐ 它同时支持 DeepSeek Harness 和 Obsidian——而这两样我本机都在用。 我有一个自建的个人知识库（Obsidian vault），也一直在用 dsh 做原生 agent 开发。"agent 记忆 + Obsidian 知识图谱 + dsh"这三者在我这儿本来是三个互不相通的东西，这个项目把它们接到了一个 SQLite 文件上。 这是我看到的最接近"我想要的东西已经存在了"的时刻。
⭐⭐⭐ "本体约束"是我 GRPM 报告体系最缺的一环，而且它给出的形态比我能想到的更精确。 "别名在写入和读取时都能解析" —— 对应到我的场景："omega-3"、"Omega 3"、"二十碳五烯酸"、"EPA+DHA" 在 GRPM 里必须指向同一条记录，否则同一个 SNP 的判定会被算成两条，报告里就会出现自相矛盾的两套结论。而"激活一个词表不会移动任何按名字索引的实体"这一条更关键：它保证了术语体系的版本更新不会静默改写历史结论。 这与我 11-09 期记的"每条规则加最后验证时间 + 指向目标是否仍存在"是同一个问题的两种解法：一个是给规则打标记，一个是让数据结构本身不会漂。
⭐⭐ "不用嵌入模型"这一条，正好治我 4P 平台的性能与成本问题。 我的平台是 Flask + SQLite 单机部署，若记忆层依赖嵌入模型，就意味着要么再养一个模型服务，要么每次记忆检索都要付一次 API 延迟与费用。 确定性召回 + 零额外依赖，对我这种"每周 8 小时"的一人公司，是能省掉一整条运维线的选择。
⭐⭐⭐ "后台任务完成不再触发召回"这一条，是把我 11-09 期记的 sprag 状态串味 bug 的正解。 我当时的结论是"回头审计全局状态"；这一期 cortexdb 给出的答案是更细的：不是审计状态，而是给召回加一个"谁在提问"的前置判断——不是人在问，就不召回。 这条规则直接可用。
⭐⭐ "'ok' 或'继续'不触发搜索"是一条看似微小但极实用的规则。 我的公众号写作流程里，大量往返就是"继续""下一条""可以"——这些应答如果每次都触发一次全量检索与召回，token 与延迟都是纯浪费。 而且它背后是一条更普适的原则：召回的触发条件应该是"这次输入携带了新的信息"，而不是"有人发了消息"。
⭐⭐ "召回计划可见、每条命中可展开"是 AI 可解释性在记忆层的形态。 我在 11-08 期记过 assay 的"四档声明（verified / self_reported / inferred / absent）"，本质是让读者知道这条结论的来源与强度。"agent 为什么想起这件事"如果不可见，记忆层就变成了一个不可审计的黑箱 —— 而我在 11-09 期已经因为 bmlib 与 mTOR Atlas 反复确认：不可审计的结论撑不起循证内容。
⭐ "<private> 标记 + 凭据排除"是记忆层的隐私默认值。 这与我在 11-08 期记的 OwnHealth 那套"令牌×人×类别三重授权 + notice 机器可读免责"是同一个方向：从架构上让敏感信息默认不外流，而不是靠每个调用点自觉。
⭐ MIT 授权，可商用；纯 Go 单二进制，无服务依赖——部署成本几乎为零。

5. eunomia-bpf/bpf-benchmark：给 AI agent 做 eBPF 级别的性能基准——而且把"论文的可复现制品评测"当成了一门正式的工程

地址：https://github.com/eunomia-bpf/bpf-benchmark ｜ ★26 ｜ MIT ｜ C / Lean 4 / LLVM

事件内容

窗口内 685 次提交（11-09 至 11-10 持续进行），是本期提交量最高的项目，主线是 ATC 2026 论文的制品评测发布（atc26-ae-1）。README 的定位一句话说清："AI Agent eBPF optimization benchmark and framework."

⭐⭐⭐ 它做的是一件我此前没意识到可以"正式做"的事：把一篇已被 ACM ATC '26 接收的论文，做成可被第三方独立评测的制品。 README 写 **"Artifact evaluation (ATC 2026): evaluator instructions for the accepted paper BPF-Ext: Safely Extending the eBPF Compilation Pipeline with Native Operations live in docs/atc26-artifact-evaluation.md"，并且 "Zenodo holds the immutable archival backup"（DOI 10.5281/zenodo.22907396）—— 论文本体在别处，仓库里放的是"给评测者看的操作说明"，归档件在 Zenodo 上不可变。**
⭐⭐ 论文的每个部件在仓库里都有明确落点，README 给了一张对照表：BPF-Ext 内核支持（verifier lowering 与 restore，x86-64 与 arm64 JIT）在 vendor/linux-framework 的独立分支；Kinsn 操作在内核模块目录；编译期识别器与字节码优化器在独立的 LLVM 分支；"Lean 4 proofs that each operation's native code matches its proof sequence" 在 kinsn/lean/；微基准（12 个来自生产程序、15 个合成、另加 2 个基线）在 micro/programs/；论文数据与图表各自归档。
⭐⭐ 制品评测的验收标准被写成了可检查的清单：README 列出这个 tag 包含 "complete no-VM static and formal validation paths"（无需虚拟机的完整静态与形式化验证路径）、"hash-bound formal proof evidence"（哈希绑定的形式化证明证据）、"fresh successful Katran KVM smoke evidence"。"hash-bound"这四个字是关键：证明证据与哈希绑定，意味着证据被换过就会被发现。
⭐⭐⭐ 窗口内的提交能完整看出"评测一件论文制品"到底要干多少事：Publish complete helper-call native payloads for four application sources（为四个应用源码发布完整的 helper-call 原生载荷）、Record the prepared helper-call image and frozen workload identities（记录准备好的镜像与冻结的工作负载标识）、Separate large and small B compile pools in the grouped resident census、Run the grouped resident census with four three-CPU workers、Restore the concurrent census change preserved by the application result publication、Identify the expanded probe-read path in the Tetragon historical installation drop、Record Tetragon and OTel completed requests with the historical installation drop。"frozen workload identities"（冻结工作负载标识）这一条，是可比性的前提。
⭐ 它的评测对象是"AI agent 的 eBPF 开销" —— 也就是说，当 agent 被要求监控与优化系统调用路径时，这套基准衡量的是它到底有多贵。
⭐ 配套的说明文档是给"评测者"看的，不是给"读者"看的 —— docs/atc26-artifact-evaluation.md 是入口，README 明确写着 "Start with this GitHub guide"。

值得关注的原因

⭐⭐⭐ "把已被接收的论文做成可被第三方独立评测的制品"这件事，本身比这个项目本身更值得我记住。 我在 11-08 期记过 bmlib 的"PICO 每一段都必须有论文自己引述的原文支撑"，在 11-09 期记过 mTOR Atlas 的 Zenodo DOI 与证据分级——这两期都在说"证据要能被翻回去看"。 而这一期把这件事推到了极致：不是给结论标等级，是把整个研究过程做成一份别人能独立跑、独立判的制品。 这对我 GRPM 报告的可信度设计是一条完整的路径：数据（Zenodo 不可变归档）→ 判定规则（分级体系）→ 制品（可复现的评测说明）。
⭐⭐⭐ "hash-bound formal proof evidence"（哈希绑定的证明证据）是一条可以直接搬走的工程规范。 我公众号每篇循证文章引用的数据与结论，如果能像这个项目一样绑一个哈希并归档到 Zenodo，那么"这篇文章引用了哪一版数据"就永远可查。 这比在文末写一句"数据截至 2026 年 11 月"强得多。 具体到我的 4P 平台：每份干预报告的输入数据快照都应该带哈希并可回溯到原始版本。
⭐⭐⭐ "冻结工作负载标识"（frozen workload identities）是可比性的前提，这条治的是我一直在犯的一个错。 我做内容效果的对比时，经常是"这一版比上一版好"——但如果两版的输入、参数、评估口径不完全一致，这个对比就无效。 frozen workload identities 的意思是：先把被测对象固定下来、编号、冻结，再跑。 我的公众号 A/B 测试与平台前后对比，都该先立这个规矩。
⭐⭐ "no-VM static and formal validation paths"——"不依赖虚拟机的完整静态与形式化验证路径"说明验证路径本身是被设计过的，而不是"跑得起来就算过"。 我在 11-08 期记过 lights-out 的 test-proof 闸门（"新增的测试必须在基线上跑出失败"）；这一期是同一条思路的学术版本：验证路径必须独立于被验证的东西。
⭐⭐ "评测者说明"与"读者说明"分开写，这个文档分层我该学。 我目前的公众号文章是写给读者的；但如果我要让同行能验证我的干预报告有效性，就需要另一份专门给评测者的文档 —— 两者混在一起，两边都读不懂。
⭐ 它测的是"agent 做系统级监控与优化的代价"——这个视角提醒我一件事：agent 能力越强，基础设施的账单就越需要被度量。 我 4P 平台的每次模型调用都是成本，而我至今没有一套"某个流程花多少钱"的基准。做基准这件事，和被基准测的对象一样重要。
⚠️ 授权与门槛提醒：本项目 MIT，可自由取用；但内核部分、LLVM 分支、Lean 4 证明都是分散在多个仓库与分支里的 —— 要完整复现需要按 README 对照表逐个拉取，这是一笔实打实的工程量，不是 clone 一下就能跑。 我应当把它当方法论参照而非可直接依赖的组件。

二、分类速览

① AI Coding / 编程智能体与技能生态

项目	星标	许可证	一句话
meta/astryx	20,293	MIT	Meta 开源设计系统，150+ 组件且内部结构完全开放，人与 agent 用同一套工具
github/squad	3,372	MIT	GitHub 官方出品：人主导的 AI 智能体团队，成员各有独立上下文与可审阅的决策记录
e2b-dev/runtime	1,830	Apache-2.0	E2B 全栈的运行时底座：云、企业与自有机器都能跑同一套隔离沙箱
elvisun/newsjack	1,687	MIT	把 agent 变成一支完整 PR 团队的开源技能集
okou-ai/okou	1,162	Apache-2.0	接入团队既有工具并替其干活的 agent 工作台，横跨市场、销售、工程与运营
dondai44423/donsetch	981	AGPL-3.0	Rust 从零手写的网页抓取与搜索工具，无需密钥与账号，专供 agent 调用
kody-hq/kody	930	FSL-1.1-ALv2	为 agent 团队准备的云：托管记忆、凭据、代码与自动化
josssphzhou/poki	778	AGPL-3.0	让 AI agent 操作真实 iPhone 的本地 MCP 服务与 agent，免越狱免额外硬件
reacher-z/awesome-cua	652	MIT	计算机使用 agent 的开源溯源目录：论文、GUI 模型、数据集与基准
askalf/dario	585	MIT	一个本地端点同时路由 Claude Code、Cursor、Cline、Aider、Codex CLI 与各 SDK
ikalus1988/misakanet	558	Apache-2.0	500+ 条带证据分级的修复经验，一次 MCP 调用即可取用
liliang-cn/cortexdb	478	MIT	本地优先的 agent 记忆：知识图谱 + 本体约束 + 可追溯推理，全在一个 SQLite 文件里
nicosuave/memex	311	MIT	检索 Claude Code、Codex、Cursor 等工具的历史会话并恢复现场
yangheng95/opencorvus	309	MIT	自建长周期 agent 团队脚手架，含自动化运行历史与进化记录
codecoradev/uteke	285	Apache-2.0	单个 Rust 二进制的 agent 长期记忆，离线运行，LongMemEval-S recall@5 达 98.2%
vstorm-co/agenticos	249	Apache-2.0	开源自托管的 AI agent 平台：搭建、运行并治理你团队的 AI 同事
openjiuwen-ai/agent-studio	195	Apache-2.0	零代码与低代码的可视化 agent 开发与工作流编排平台
fullsend-ai/fullsend	172	Apache-2.0	面向全自主 agent 化工程的开源实践路线
bitsofchris/openaugi	141	Apache-2.0	给 agent 用的「人的记忆」：把个人知识库变成可检索可遍历的知识图谱
awebai/aweb	129	MIT	agent 之间的通信层：稳定身份、持久邮件与聊天、跨会话跨机器的唤醒事件
sleep2agi/agent-network	117	Apache-2.0	一行命令组建多 agent 数字员工军团，兼容 Claude Code、Codex 等四种运行时
poe-platform/poe-code	100	MIT	用 Poe 为主流 coding agent 供能，无需逐个更换模型配置
bike4mind/bike4mind	95	BUSL-1.1（源码可见，非开源）	开放核心的 AI 工作台：笔记本、agent、RAG、语音与图像跨任意模型
hivecommons/hive	80	Apache-2.0	开源与闭源通吃的 agent 编排，可自定义一支 AI agent 舰队
flisk-sh/flisk	36	MIT	coding agent 的本地运行时：一条命令启动、检查并修复你的多服务栈
vite-hub/vitehub	29	Apache-2.0	用单个 Vite 插件把服务端原语组合成任意宿主上的 agent
eunomia-bpf/bpf-benchmark	26	MIT	AI Agent 的 eBPF 优化基准与框架，配套 ATC 2026 论文的完整制品评测
margince/margince	25	BUSL-1.1（源码可见，非开源）	AI agent 真能用的 CRM，源码可见可自托管
constellation-works/orbit	20	MIT	本地优先的 coding agent 运行时：agent 提交任务，Orbit 从沙箱工作树落地执行

② 医学 / 临床研究 AI 与 Agent 技能库

项目	星标	许可证	一句话
verifywise-ai/verifywise	374	VCEL-1.0（自定义，社区与评测许可）	AI 治理与 LLM 评测平台，支持 EU AI Act、ISO 42001、NIST AI RMF 等 20+ 框架
kaapana/kaapana	277	AGPL-3.0	面向野外医疗场景的开源平台部署工具箱
abinauv/dental-erp	35	MIT	面向印度的开源牙科医院管理系统，含 AI 能力与 GST 计费
wld007/dsh-medical-anonymizer	5	MIT	DeepSeek Harness 医疗数据批量匿名化插件：规则识别 + 可选模型盲审 + 审计报告
ehojune/bioinfo-team-3d	2	GPL-3.0	把 Claude Code、Codex、Gemini 编成一间生物信息学实验室，含 CSO 编排与 HPC 调度
yao-care/jptxgnn	1	MIT	日本 PMDA 批准药品的 TxGNN 药物重定位预测与证据验证平台
yao-care/nztxgnn	1	MIT	新西兰 Medsafe 批准药品的 TxGNN 药物重定位预测与证据验证平台
yao-care/notxgnn	1	MIT	台湾 DMP 批准药品的 TxGNN 药物重定位预测与证据验证平台
pmanko/openclinai.org	1	未声明	临床 AI 工具集：病历检索、健康数据分析与可复现评测
jagnyesh/researchflow	1	MIT	基于 FHIR 的临床研究数据请求多智能体（LangGraph）概念验证，含人工复核
jjjy9/medix-agent-swarm	0	MIT	MediX 多智能体医疗助手：Skills-Agent 架构 + Agent Swarm + 本地知识库
dnarram/clinical-research-compliance-assistant	0	未声明	基于 ICH GCP (E6(R3))、ICH E2A 与赫尔辛基宣言的 RAG 合规助手
alaskantuna/catatmd	0	Apache-2.0	把全科问诊转成可复核、可溯源的病历文书的 AI 临床记录副驾
bmartinez-stgo/clinical-ai-platform	0	未声明	用 Kubernetes 搭建 AI 辅助临床系统的开源平台
healthkey-ai/cdew	0	Apache-2.0	临床数据抽取工作流：管理工具加 AI 流程，做清洗、抽取与校验
kienhaminh/triadcare	0	MIT	受治理的多智能体临床框架与评测流水线
hamzacakmakk/med-os	0	未声明	AI 辅助放射工作站：把 X 光路由到匹配的 YOLO 模型并起草报告
timothywisdom/rag-medical-triage-demo	0	未声明	用键值库存放就诊信息的 RAG 医疗分诊演示应用
emranyaseen-alsabry/brain-tumor-mri-classification	0	MIT	脑瘤 MRI 分类临床 AI 系统，测试准确率 95.06%，带可解释性
arjunafransesco/cardiovascular-disease-prognosis	0	未声明	心血管风险预测、biomarker 与分诊的临床机器学习系统

③ 健康管理 / 营养与食品 AI

项目	星标	许可证	一句话
yuhi113/iron-pump-log	55	未声明	AI 健身教练 2026：个性化训练与健身追踪
01helfy/fit-forge-ops	55	未声明	智能健身俱乐部管理系统，含 AI 训练与饮食计划
merran-app/merran	32	AGPL-3.0	自托管的家庭膳食计划器：食谱、周计划、采购清单与食材库存
pivisyyy/pivis-health	20	MIT	本地优先的私人健康管家：iOS App + 健康内核 + DSH 上的 Agent，监测到推动执行
cliftonz/tandoor-recipe-mcp	8	MIT	Tandoor 食谱的 MCP 服务，把菜谱与食材接入 agent
orellbuehler/bissbilanz	3	PolyForm	跨网页、Android 与 iPhone 的热量与宏量素追踪器，支持条码扫描与端上营养识别
quantcli/crono-export-cli	3	MIT	把 Cronometer 的营养、生物指标与饮食日志导出为 JSON
dravr-ai/dravr-platform	2	Apache-2.0	Dravr AI 健身平台
saltylvn/wellness-tracker	1	未声明	iPhone 优先的康养追踪器：照片记饮食、力量与有氧计划、体重目标
saltylvn/dialed-kitchen	1	保留所有权利（专有）	iPhone 优先的膳食计划、食谱与食品价格追踪，面向两人家庭
jmuci/chefai	1	未声明	Chef AI：几秒生成每周膳食计划并导出到你常用的应用
mariomounir1/aura	1	未声明	全栈 AI 营养健身应用：Flutter 移动端 + Node/TypeScript 后端
ark07yad/nutritrack	1	MIT	热量、微量营养素与训练追踪器，覆盖全部 27 种维生素与矿物质
cyoren/datalyst	1	AGPL-3.0	每天几秒记录整个人生，然后拿自己做实验的自托管工具
chariot-ventures/dietary-supplement-analysis	1	MIT	膳食补充剂分析的 Pocket Network 服务
zeroindex-x636a06/intake	0	GPL-3.0	离线优先的 Android 个人饮食记录，合并 AI 照片热量估算与乳制品管理
bouadeikheireddine/ascendlab	0	未声明	面向运动员的 AI 生活伴侣，生成个性化训练、营养与恢复方案
intellifit/food_link	0	未声明	AI 食物分析与饮食分享社区
karthik-v-kumar/clinical-trial-delta	0	未声明	每日快照 ClinicalTrials.gov 并比对变更的 GLP-1、肥胖、糖尿病与胆固醇试验追踪器
thcborges/dieta-ai	0	GPL-3.0	用于饮食控制的应用程序
nassim-assassi/protein-source-helper	0	未声明	对比英国各大超市高蛋白商品的选购助手
supportlik/victus	0	PolyForm	自托管营养追踪：REST API、passkey 网页应用、报告生成器、agent 收件箱与 MCP
bikash-20/nutrivision-ai	0	未声明	双语营养应用，帮用户看懂自己的饮食
d96moe/ha-nutrition	0	MIT	Home Assistant 饮食日志集成：由 AI agent 经 MCP 写入，含今日传感器与每日统计
pete0585/functional-medicine-directory	0	未声明	功能医学医生名录，沿用 IBCLC 名录架构
sabian98/bender	0	MIT	BENDER 代码与逐序列数据：生命之树上 10282 个无序蛋白的粗粒化集成
marcnester/glycofy-api	0	专有源代码声明（不可开源）	由训练上下文驱动的运动员向 AI 膳食规划 API
alexcho783/evidence-desk	0	未声明	按研究设计与发表年代排序的医学文献检索，基于 Europe PMC API 的静态站
nikossakell/pyramid	0	MIT	面向青少年的隐私保护、奖励驱动的饮食与摄入 AI 监测
mdaminsadik/nutriai	0	未声明	提供个性化饮食追踪与 AI 健康服务的营养平台
yansecos/nuragut-2026-aigeo-benchmarks	0	未声明	NuraGut 临床肠道-代谢与抗炎营养基准集

④ 模型底座与 Agent 基础设施

项目	星标	许可证	一句话
milvus-io/milvus	46,621	Apache-2.0	高性能云原生向量数据库，支撑大规模向量 ANN 检索
tencent/ncnn	24,031	BSD-3-Clause	面向移动端优化的高性能神经网络推理框架
huggingface/peft	21,880	Apache-2.0	参数高效微调（PEFT）的官方实现
google/gvisor	19,943	Apache-2.0	面向容器场景的应用内核
firecrawl/firecrawl-mcp-server	7,791	MIT	Firecrawl 官方 MCP 服务：给 agent 的上下文 API，做搜索、抓取与网页交互
volcano-sh/volcano	6,076	Apache-2.0	CNCF 旗下的云原生批处理调度系统
unslothai/notebooks	5,804	LGPL-3.0	250+ 覆盖文本、视觉、音频、嵌入与 TTS 的微调与强化学习笔记本
pytorch/executorch	5,166	BSD-3-Clause	PyTorch 的端侧 AI 运行时，覆盖移动、嵌入式与边缘设备
michaelfeil/infinity	2,984	MIT	面向文本嵌入与重排模型的高吞吐低延迟推理引擎
qualcomm/aimet	2,744	BSD-3-Clause	训练后量化与压缩技术库
syv-ai/hyperqwen	2,639	Apache-2.0	用自己手上的 GPU 跑大 Qwen 模型，Qwen3.8-27B 单张 24GB 显卡即可
matrixorigin/matrixone	2,063	Apache-2.0	AI 原生 HTAP 数据库，内置 Git-for-Data 与向量检索
sgl-project/sglang-omni	1,724	Apache-2.0	面向交互式超级智能的高性能服务运行时
1catai/1cat-vllm	1,489	Apache-2.0	专注 V100 与 SM70 的 vLLM 工程分支，面向现代 LLM 推理
carverauto/serviceradar	932	Apache-2.0	开源网络管理、ITOM、可观测性与安全分析平台
oborchers/fast_sentence_embeddings	638	MIT	快速计算句子嵌入
zolotukhin/zinc	528	MIT	Zig 编写的推理引擎：在 AMD GPU 与 Apple Silicon 上跑本地 LLM
lablup/mlxcel	492	Apache-2.0	面向 Apple Silicon 与 NVIDIA 的 LLM、VLM、嵌入、重排与音频高性能推理
nvidia/tensorrt-model-connect	294	Apache-2.0	两条命令走完从 PyTorch 模型到端到端 TensorRT 推理
leenhawk/gproxy	278	AGPL-3.0	Rust 多通道 LLM 代理，对外暴露 OpenAI、Claude、Gemini 风格 API
amd-agi/hyperloom	265	MIT	在 AMD GPU 上自动优化 LLM 工作负载的 agentic 系统
pie-project/pie	240	Apache-2.0	可编程的高性能模型服务系统
joakimpalm-zen/xyntetik-runner	30	Apache-2.0	可证明的本地推理：单二进制 GGUF 引擎，一套服务、评分并训练 LoRA
Bojieli/opentallas	7	MIT	面向模型专用 mask-ROM LLM 推理芯片的开放研究

三、今日趋势观察

本期最清楚的一条主线是：AI 系统正在被要求"能被独立验证"，而这一期把验证做到了三个从未触及过的深度——制品级、哈希级、盲审级。 bpf-benchmark 把一篇已被 ACM ATC '26 接收的论文做成可被第三方独立评测的制品，并要求证明证据与哈希绑定、工作负载冻结标识；dsh-medical-anonymizer 让复核模型不知道识别结果、要求分歧升级给人而非模型内部表决；cortexdb 把召回计划与每一条命中都摊开给人看。三家的技术栈毫无交集，却各自独立地做了同一件事：把"我自己说自己对"换成"一个不知情的第三方来判"。 这与我在 11-08 期记的 assay（证据包可离线重算）、11-09 期记的 bmlib（PICO 每段须有原文支撑）与 mTOR Atlas（证据按研究设计分级）是同一条线索的第四阶段：前三期把要求下沉到"证据的结构"，这一期把要求下沉到"验证的独立性"。 具体到我：我的 4P 平台目前所有自检都是同一个模型在同一段上下文里做的，这在结构上就不可能发现自己的系统性错误——"盲审"这四个字，是我这期最该带走的那个词。

第二条线，也是对我这个人的工作方式最刺痛的一条：本期出现了三个把"知识会腐烂"当成工程事实来管理的项目，而且都给出了腐烂的具体形态。 cortexdb 的本体层规定"激活一个词表不会移动任何按名字索引的实体"——术语体系升级不会静默改写历史结论；bpf-benchmark 规定被测对象要冻结标识，否则对比无效；dsh-medical-anonymizer 规定未解决的条目进人工复核，而不是被静默接受。三家的共同点是：它们都拒绝"默认状态悄悄改变了结论"。 而我目前的处境恰恰相反：我的公众号文章库、GRPM 的 SNP 判定规则、4P 平台的干预方案模板、专家包里的提示词，全都在持续增长，从来没有被标记为"已过期"，也从来没有被标记为"适用条件已变"。最该立刻动手的还是这一件，但今年可以做得更狠：给每一条进入内容与报告生产链的规则，加上三个字段——「最后验证时间」「指向目标是否仍存在」「术语别名集合」，然后让一个每周任务把失效的挑出来。第三个字段是这一期 cortexdb 教我的："omega-3" 和 "EPA+DHA" 必须在系统里是同一条记录，否则我的报告会出现两套自相矛盾的结论。

第三条线：授权形态在这一期出现了一组我该特别留意的样本——"用授权条款表达商业模式"正在变成常态，而且开始分层。 verifywise 把 BSL 1.1 换成了自定义的 VCEL 1.0（个人、学校、公共部门与非商业研究免费，公司可免费评测 60 天，之后商用需另约许可）；kody-hq 用 FSL-1.1-ALv2（源码可见，但到某个时间点会变成非开源）；margince 与 bike4mind 用 BUSL 1.1；而 saltylvn/dialed-kitchen 与 marcnester/glycofy-api 干脆是专有授权。这五个样本分成了三档：真开源（MIT/Apache，可直接商用）、源码可见但非开源（BUSL/FSL，有时间或场景限制）、完全不开放（专有）。 对我这个一人公司，这三档意味着三件不同的事：第三档一个都不能用（连读都不行）；第二档可以读、可以学设计、但绝不能进我的产品依赖；第三档才是选型候选。本期 104 个条目里 MIT 与 Apache-2.0 合计 63 个（61%），AGPL-3.0 6 个、GPL-3.0 3 个只能读不能抄，PolyForm 2 个连商用都不允许，20 个未声明必须回查 —— 这份三档清单应该直接抄进我的选型文档第一行，且在动手前先看这一行。

第四条线：一条被我低估的架构信号——"agent 记忆层正在从"向量相似度"回到"确定性图谱"。 cortexdb 明确说 "works without an embedding model"，把知识图谱、本体约束与可追溯推理放进一个 SQLite 文件；openaugi 走的是同一条路（一个 SQLite 文件、一个 MCP 服务、把个人知识库变成可检索可遍历的图谱）；uteke 则是单个 Rust 二进制、离线运行、LongMemEval-S 上 recall@5 达 98.2%。三家独立选择"不用嵌入模型"，理由指向同一个判断：语义相似带来的不确定性，在需要可复现与可审计的场景里是负担而不是特性。 这一条对我有直接成本意义——我的 4P 平台是 Flask + SQLite 单机部署，若记忆层依赖嵌入模型，就意味着要么再养一个模型服务，要么每次记忆检索都付一次 API 延迟与费用。 而更值钱的是它附带的那条召回规则："'ok' 或'继续'这样的应答不触发搜索"、"后台任务完成不再触发召回" —— 这两条合起来是一句可以直接写进我的管线的规则：召回的触发条件应该是"这次输入携带了新的信息"，而不是"有人发了消息"。

第五条线，给 Gordon 的直接提醒：这一期最值得带走的不是任何单个项目，而是四个可以今晚就动手的断言。 第一，astryx 的"组件可在任意层级组合，不锁在封闭顶层 API 后面" —— 这是"能被 agent 安全修改"这一性质的工程形态，而可维护性在一人公司里就等于可被 agent 维护。 第二，astryx 把排版写成可验证的数字（Markdown 正文 680px）、把测试失败报成具名场景而非行号 —— 这补上了我 11-08 期记的 test-proof 闸门的另一半：不仅要会红，还要红得让人看懂。 第三，squad 的"规范、文档与矩阵三者对齐代码 + 回归守卫" —— 我给自己列的四件事（证据类型标签、原文定位区间、规则验证时间、失效扫描）目前都只是约定，而约定没有守卫就会烂掉；squad 的做法是加一条会红的测试来裁定谁说了算。第四，bpf-benchmark 的"哈希绑定的证据 + 冻结的工作负载标识 + 给评测者看的独立文档" —— 这三件对应我 GRPM 报告可信度的完整路径：数据归档、对比前提、以及一份同行能独立跑的评测说明。 具体要做的只有五件：① 每条规则加三个字段（验证时间、指向目标、术语别名）；② 关键排版参数写成常量；③ 测试失败报具名场景；④ 每份干预报告的输入快照带哈希；⑤ 内容规范也配一条会红的测试。 五件都不需要新框架，只需要五个字段、几个常量和一条定时任务。

四、GitHub 地址速查

GitHub AI 日报 · 2026-11-10（周二）

一、今日精选 5 条

1. meta/astryx：Meta 把内部用了八年的设计系统开了源，150+ 组件全部"开放内部结构"——它要解决的不是好看，而是让 agent 改 UI 时能读懂、能下手

2. github/squad：GitHub 官方下场做"一支人来指挥的 AI 开发团队"——它把团队成员的 charter（岗位说明书）写进仓库文件，让治理与代码住在同一个 git 里

3. wld007/dsh-medical-anonymizer：给 DeepSeek Harness 装一个"病历批量脱敏"插件——规则先跑、模型盲审、没查清的绝不静默通过，每一批都留下审计报告

4. liliang-cn/cortexdb：把 agent 的记忆做成"一个 SQLite 文件里的知识图谱 + 本体约束 + 可追溯推理"，而且 Claude Code、Codex、DeepSeek Harness、Obsidian 全都接得上

5. eunomia-bpf/bpf-benchmark：给 AI agent 做 eBPF 级别的性能基准——而且把"论文的可复现制品评测"当成了一门正式的工程

二、分类速览

① AI Coding / 编程智能体与技能生态

② 医学 / 临床研究 AI 与 Agent 技能库

③ 健康管理 / 营养与食品 AI

④ 模型底座与 Agent 基础设施

三、今日趋势观察

四、GitHub 地址速查