GitHub AI 日报 · 2026-10-30（周五）

一、今日精选 5 条

1. lightpanda-io/browser：AI 专用浏览器开始替模型「遮住密码」——把凭据从模型可见的上下文里抹掉，这比任何运行时拦截都靠前一层

地址：https://github.com/lightpanda-io/browser ｜ ★37,948 ｜ AGPL-3.0 ｜ Zig 从零编写的无头浏览器，为 AI agent 与自动化而生（不是 Chromium 分叉、不是 WebKit 补丁），内存约为 Chromium 的 1/16、速度快约 9 倍

事件内容

这个 37,948 星的项目今天有 45 条提交，密度在今天所有仓库里排第一，而其中两条直接指向一个我一直在盯的问题：模型到底"看见"了什么。

• agent: mask a literal login password in what the model is shown（今天 12:43）——不是遮住输入框，而是遮住"模型被展示的那份页面内容"里的字面密码。 紧接着 13:50 的 agent: rebuild the masked /login line instead of searching it 补上一个关键工程细节：遮蔽之后要重建那一行，而不是去页面上搜索替换——因为原页面的 DOM 已经被破坏，再搜索必然失败。
• 同一天还有 browser: give each Jev tool its own module, as search has（每个 Jev 工具独立成模块，不再共用 search 的实现）与两条合并：#4067（plumber v0.7.6）、#4165（jev-fallback 回退路径）。
• 性能数字是它能进 agent 链路的真正原因：在 AWS EC2 m5.large 上跑 933 个真实网页，100 页峰值内存 123MB（无头 Chrome 2GB，约 1/16），执行耗时 5 秒（Chrome 46 秒，约 9 倍）。README 明写"为 AI agent 从零写的浏览器"——它优化的指标不是"人看网页快不快"，而是"agent 每次工具调用的边际成本"。
• 许可与形态：AGPL-3.0，Zig 编写，提供 nightly 二进制（Homebrew / AUR / curl / Nix），Linux 二进制链接 glibc，Alpine 需换基础镜像。

值得关注的原因

• 它把"密钥不外泄"这件事从运行时挪到了更靠前的一层，而且这一层我此前没想到。 上一期我记录 hashgraph-online/hol-guard 阻断运行中的危险工具调用与密钥访问，那是"agent 已经拿到工具、我们不让他用"；而 lightpanda 解决的是更早的问题——页面里那个密码根本不该出现在模型的输入里。我给 4pwellness 的 AI 助手接模型密钥、给营养平台做化验报告 OCR 导入时，真正的风险窗口就是"敏感串先被渲染进 DOM、再被 agent 读进上下文、然后随请求发出去"。"重建被遮蔽的那一行，而不是去原页面搜索"这个实现细节，尤其值得我抄——它意味着遮蔽不是文本后处理，而是要回到渲染管线里做。
• 16× 内存、9× 速度这两个数字，对我"每周 8 小时"的一人公司路径有直接商业含义。 我的最小可行版要跑的东西恰好是"抓取 → 读 → 判 → 出报告"这种工具调用密集的活；如果每次工具调用的浏览器成本是 Chromium 的 16 倍，那同样的机器预算能跑的会话数就少 16 倍。这不是技术选型偏好，是直接影响我能不能在有限预算里把"考证钩子 + 营养 AI 内核"跑出可用体验的成本问题。
• 它和我做 4pwellness 微信群客服 Bot 的一个具体风险点重合：如果 Bot 要帮用户查营养方案、或帮用户在小程序后端跑一次体检报告解析，任何一次"截屏/抓页面"的动作都会把 token、用户 ID、甚至身份证号带进上下文。有了这套遮蔽，"抓取"这一环才敢真正开放给 agent。
• 一个提醒：AGPL-3.0 意味着如果我把它作为服务的一部分对外提供，需要认真做 copyleft 合规评估。对一个人公司来说，"能不能用"和"能不能改完再闭源卖"是两件事——这一条我必须在上产品前问清楚，而不是等到写完再发现。

2. seancpc/MedAgent-EHR：Planner–Executor–Verifier 三段式 + 两阶段写入，临床 agent 在 300 题 MedAgentBench 上做到约 88%，且完全自架本地模型

地址：https://github.com/seancpc/MedAgent-EHR ｜ ★0 ｜ MIT ｜ Python + Flask + MCP + HAPI FHIR R4，自架 LLM 的临床 agent，在写入病历前自我把关

事件内容

星数只有 0，但它是今天医学线里架构最完整、且唯一给出可复现基准分数的一个。

• 架构是三段式：临床任务 → Planner（拆解计划）→ Executor（ReAct 循环：观察结果→决定下一步）⇄ MCP 工具 ⇄ FHIR → Verifier（写入前安全闸：approve → commit / reject → 重试）→ 最终答案。Planner / Executor / Verifier 三个角色全部由 LLM 驱动，控制流无固定路径、无固定步数。
• 写入是"两阶段"的：stage → commit，先暂存再落库，中间隔着 Verifier 安全闸，外加医疗编码与剂量校验。README 原话是"guarded by a safety gate before any write"。
• 分数是可核对的：在 Stanford MedAgentBench（300 题）官方 refsol grader 上达 ~88%（259–263 / 300），高于论文公布的最佳 baseline Claude 3.5 Sonnet v2（69.67%）。但作者自己加了限定——"此分数为对齐该 benchmark 的 agent 系统表现，非原始模型能力的纯比较"，并诚实标注 9 类稳定任务共 258/270、task10 是所部署模型的已知输出弱项、以区间表述。
• 模型可替换：默认自架 Gemma-4-26B-A4B-it（也在 Qwen3.6-35B-A3B 上验证过），走 GGUF + llama.cpp，完全不依赖云端 LLM API；从 Qwen 迁到 Gemma-4 几乎零代码改动、分数近乎持平——作者据此声称"系统与模型解耦"。
• 10-30 当天 14 条提交，包括 Update README.md、Update baseline.svg、Update progress.en.svg（结果图与进度图更新），以及一条很有信息量的依赖治理：fix(deps): pin mcp to >=1.27,<2——mcp 2.x 重命名了核心 API（FastMCP、streamablehttp_client），直接破坏导入并让 CI 测试收集失败，于是干脆把版本钉死。
• 边界写得很克制：MedAgentBench 的测试数据与官方 grader 不随仓库分发（版权归原作者），需自行获取；缺 grader 时 runner 仍能跑但只评分 task1；项目自有代码 MIT。

值得关注的原因

• "两阶段写入 + Verifier 安全闸"就是我上一期在 JuneYaooo/open-medical 里读到的那套"待确认提案"的同构实现，但它做在了真正的临床系统里。 我做 GLP-1 营养伴侣 V2 的"Mazdutide 用药与停药 cascade"、做 4P 补剂平台的干预报告落库，一直靠的是我自己在应用层写的那层校验。他们把它做成了 agent 架构里的原生角色，并配了 88% 的公开基准——这意味着我可以拿他们的架构当参照，而不必自己论证"为什么必须有一道人工确认闸"。
• "自架本地模型 + 分数不掉"这个组合，对我意义很大。 我本机跑着 Ollama qwen2.5:7b，我一直关心的问题是"如果我把一个临床/营养 agent 全部落在本地小模型上，效果会掉多少"。他们给出的答案是：从 Qwen 迁到 Gemma-4（连尺寸规格都不同）几乎零改动、分数近乎持平——说明决定 agent 表现的主要是那套 Planner/Executor/Verifier 结构与工具对齐，而不是底座模型。 这对"一人公司 + 每周 8 小时"意味着：我可以放心把成本压在结构与确定性资产上，而不是去追更强的模型。
• "pin mcp 到 >=1.27,<2，因为 2.x 重命名了核心 API"这条提交，是一份免费的兼容性情报。 我给 4pwellness 接 MCP 连接器、给自己搭 MCP server，迟早会撞上同一堵墙。别人已经把墙的位置和绕法写进了 commit message，我直接抄版本区间就行。
• 它诚实的边界表述值得我学：分数给区间、注明"非模型能力纯比较"、明确数据与 grader 不随仓库分发、列明不支持项。这正是我在健康内容上一直守的"强制循证 + 零 AI 幻觉"——把"这个数字不能证明什么"写在数字旁边。

3. whiteravens20/diet-app：把营养计算做成确定性引擎、AI 降级为可选助手——"it never invents nutrition facts" 是写进 README 的一句话

地址：https://github.com/whiteravens20/diet-app ｜ ★2 ｜ AGPL-3.0 ｜ TypeScript，可自托管的饮食与配餐平台，确定性营养计算 + BYOK AI

事件内容

只有 2 星的新项目（2026-05-22 创建），但它把"AI 做营养方案"这件事的边界划得比大多数商业产品清楚——而且和 4P 的处境几乎一模一样。

• 一句话的产品定位就是分工声明："Diet App generates calorie-targeted meal plans, optimises ingredient reuse across a planning window, and produces consolidated shopping lists — all from a curated product database so every calorie and macro is deterministic and reproducible. AI is an optional assistant: it drafts recipes, suggests substitutions and weighs what the planner proposes; it never invents nutrition facts."
• 热量引擎是确定性的：Mifflin-St Jeor 公式算 BMR，活动系数换算，每周减重目标限定在 0.25–1.0 kg/wk，换算成每日热量缺口后再限制为维持量的四分之一以内，且任何计算出来的目标都不允许低于这个地板值，另留人工覆盖入口。
• AI 起草 → 校验层重算：AI 只能从"已批准食材"里起草配方，然后由 validation layer 重新计算每一个数字。用户也可手写配方（引擎自行推算一份的量），还可导入 schema.org 文档——但每一行都必须对应食材库里已知的一种食材与一个数量，且每一份草稿都要有人批准，配方还需标注来源与授权协议。
• 配餐优化器真的在做优化：一个计划会声明"它买了哪些整包、这些整包多久能吃完"，为备餐设计的计划里同一道菜会做两天吃；计划中的某一天可单独设定（训练日/休息日/跳过/换餐数/独立目标），这些改动对当餐的影响会在保存前先说清楚。
• 购物清单按"人是怎么买菜的"来算：鸡蛋按个、面包按片、重量向上取整到 5 g、按整包占用行数；库存里已有的先扣，买超了的部分回填库存；导出有 PDF、表格、文本三种出口。
• 10-30 当天 11 条提交，主线是"让食物与餐次带上自己的图"与"把日记条数计入任何填满计划某一天的东西里"：feat(web): show the pantry's banner with its food in the frame、feat(web): give the favourites a banner photo of their own、feat(web): give the diary's banner a photo of its own、feat(api): count the diary's entries in whatever fills a day of a plan。
• 边界同样克制：README 顶部有醒目 WARNING——早期开发、非生产就绪、API 与数据模型可能随时变、尚未经过安全审查，"自托管来实验，不要用于你依赖的东西"。

值得关注的原因

• 它和我 GLP-1 营养伴侣 V2 的核心分歧点正好相反，而这个分歧我必须想清楚。 我现在是"153 个食材模板 + 15 个功能靶点 + 早/晚双杯方案 + 配方引擎"，模型参与度不低；他们走的是"受治理的成品食材库 + 确定性计算 + 模型只做提议与替换建议 + 校验层重算每一个数字"。换成白话：他们把"算"和"说"彻底分开了。 我上一期在 craft-b/formula-forge 那里已经认可过这个方向（"模型只提结构、数字由确定性层重算"），今天又一个独立团队在饮食场景独立走到同一处——两次独立收敛，比任何论证都有说服力。
• "任何计算出来的目标都不允许低于地板值"，是我见过最朴素也最有效的护栏。 我做减脂/增肌方案时一直在纠结"AI 生成的摄入量太低了怎么办"，他们用一句"缺口不超过维持量四分之一、且目标值有地板"就把这个问题关掉了。这不是靠模型自觉，是靠公式里写死的约束。 我可以直接把这个结构搬进 4P 的干预报告。
• "每一份草稿都要有人批准 + 校验层重算每一个数字"——这套流程就是我在 4P 补剂平台反复想要的东西。 我一直缺的是一个把"谁批准了、批的是哪一层"结构化落库的位置。他们把批准动作卡在配方进入库之前，我应该把同样的卡点放在干预报告落库之前。
• 但它的 WARNING 恰好是我要避开的坑：只有 2 星、AGPL-3.0、尚未安全审查。 所以我的用法是当设计参照，不当依赖——抄它的公式约束与审批卡点，不引入它的代码。AGPL-3.0 在我这里同样只作参考。

4. CopilotKit/OpenBot："每个动作在发生前被决定、发生后才被记录"——AI 同事拿到自己的浏览器、自己的登录、自己的文件，但只有你授权的工具

地址：https://github.com/CopilotKit/OpenBot ｜ ★8,507 ｜ MIT ｜ TypeScript + AG-UI，自托管的"AI 同事"工作区：每个 coworker 拥有独立浏览器、文件与工具授权，动作执行前决定、执行后留痕

事件内容

这是今天 GitHub 趋势榜第四（今日 +707 星，Trendshift 当日仓库第 3），它的产品定义句就是一份权限设计。

• README 核心段："Each coworker gets a real browser with its own logins, its own files, and only the tools you grant. Every action decided before it happens and recorded after." 交付形态是"任何 AG-UI agent（无论用哪个框架或手写）带过来，它就以一个同事的身份出现，拥有自己的频道；你可以在它屏幕上看着它干活，遇到不该由它独自决定的事就接管，之后再交还"。
• 定位极其克制："A template, not a product. OpenBot is meant to be cloned and made your own. 没有可注册的托管版本，也没有任何东西以包的形式发布；你把仓库拉下来，把 examples/ 下的示例租户包换成你自己的同事、频道与技能，然后自己跑。" 并且明确标注 Beta, and under active development，预期有粗糙边缘与 bug。
• 形态上是本地优先：README 写明"Everything below is written for a laptop"，.env.example 直接把本地起服务作为默认路径；MCP 市场、Today 面板、桌面 v0.6.0/v0.7.0 的更新也在同一天推进。
• 10-30 当天的实质提交是 Give Bots the whole standard catalog but four (#875)——"给了机器人除四项以外的全部标准目录"。这意味着它的工具目录今天被进一步打开，只保留四项不放开；工具面越大，"只授权你允许的工具"这条约束的工程难度就越高。
• 同时当天还有 Add marketplace schema snapshot coverage（给 MCP 市场加 schema 快照测试）与 Harden marketplace MCP client and add tests（加固市场 MCP 客户端并补测试）——市场化的 agent，工具可信度就得靠 schema 快照和测试来兜。

值得关注的原因

• "每个动作在发生前被决定、发生后才被记录"这句话，是过去两期日报在我脑子里反复出现的那条主线第一次被写成了产品承诺。 我在 10-28 记 hol-guard 的 fail-closed，在 10-28 记 open-medical 的待确认提案，在更早的期里记"报告里任何一句'已优化'背后都必须有真实的计算痕迹"——这三件事其实是同一件事：让 AI 的每一次动作都有前置决定与后置痕迹。 他们把它做成了"每个 coworker 各自一套浏览器、登录与文件"的隔离模型。"隔离 + 前置授权 + 后置留痕"这三件套，是我要给 4pwellness 微信群客服 Bot 和营养 AI 助手画的架构图。
• "only the tools you grant"这句对我最刺痛的一点是：我现在还没做工具授权。 我的营养 AI 内核准备接的东西不少——食材库、化验指标、GRPM 的 40 个 SNP、Excel 导出——用户如果一句话让我"顺便把导出也做了"，我是没有闸门的。 他们的做法是默认只给除四项外的全部目录、逐项授权，等我要收紧时再加成本。我应该反过来：默认最小授权、逐项放开，并且把"这次对话里这个用户能调哪些工具"做成显式可见的状态。
• "A template, not a product"这个定位，对我这种一人公司几乎是量身定做的。 它没有托管版、没有可依赖的发布包，唯一交付方式是你把仓库拉下来改成自己的。我做考证钩子 + 营养 AI 内核时，本来就不打算做一个通用 SaaS——这类"模板而非产品"的 MIT 项目，比闭源 SaaS 更适合我做底座（MIT 的宽松授权对我这种要自己改造的人是刚需，AGPL 那两个项目我只能读不能抄）。
• Beta 状态 + 今日仍在扩大工具目录，说明它正在"用广度换真实反馈"。 我要观察的是：随着工具目录扩大，它的授权模型会不会出现"授权过宽导致越权"的裂缝——这正是我做 4pwellness MCP 连接器时最担心的一类问题，可以拿它的演进当公开样本看。

5. nambok/mentedb：专门为 AI agent 记忆造的数据库引擎——不是现有数据库的包装，Rust 从底层写起

地址：https://github.com/nambok/mentedb ｜ ★122 ｜ Apache-2.0 ｜ Rust，为 AI agent 记忆而生的数据库引擎（WAL + HNSW 向量索引 + 知识图谱），云托管或自托管

事件内容

星数不高，但它解决的是我一直在找现成方案的那个具体问题："每次交互数据持久化以支持自我进化学习"应该落在什么存储上。

• 定位一句话说清："MenteDB is a purpose built database engine for AI agent memory. Not a wrapper around existing databases, but a ground up Rust storage engine that understands how AI/LLMs consume data." 名字来自西班牙语 mente（心智、 intellect）。
• 两种运行方式：Cloud（拿 API key 走托管，过夜维护由平台跑）或 Self-host（cargo install mentedb-server 或 Docker，夜间维护内置）；另外还有 Python / Node / Rust 三种客户端与云/自托管的全部组合示例。
• 接入路径对 AI 工具开发者非常直接：npx mentedb-mcp@latest setup claude-code（同样支持 cursor、copilot、claude）——它自己就带 MCP server，一行命令把自己的记忆挂进我正在用的编码 agent。
• 10-30 当天三条提交里有两条是发布与存储格式加固：chore: release v0.44.1（正式发版）、fix(storage): refuse to open a directory migrated to the record format（拒绝打开一个已迁移到新记录格式的目录——这是一个"数据格式演进时不静默损坏旧数据"的具体防线，比"迁移失败报错"更严格），以及 lz4_flex 依赖升级。
• 存储三件套：WAL（预写日志）、HNSW（分层可导航小世界，做向量近邻）、知识图谱，面向"LLM 实际怎么读写数据"来设计而不是面向关系模型；npm、PyPI、crates.io、docs.rs 全都有发布物。

值得关注的原因

• 它给我的"自我进化学习"这件事，提供了一个我原本打算自己写的那一层。 我在 GLP-1 营养伴侣 V2 里坚持"每次交互数据持久化"，但目前的落法是往 SQLite 里塞交互日志——那是应用日志，不是 agent 记忆。差别在于：应用日志记"发生了什么"，agent 记忆要能"按语义召回过去的相关经验"。WAL + HNSW + 知识图谱这三件套，正好对应"可靠的写入 + 语义检索 + 结构化关系"三层需求。
• "拒绝打开已迁移目录"这条防线，是我做数据版本管理时最该抄的一条。 4P 精准营养平台的干预报告有版本管理、化验指标有趋势追踪、GRPM 有 40 个 SNP 的提取流程——这些数据模型一定会演进。"格式变了就明确拒绝打开，而不是尽力读一下"，比"尽量兼容"安全得多，因为对健康数据来说，静默读错一行比直接报错危险得多。
• 它自带 MCP server 且一行命令接进 Claude Code / Cursor / Copilot——这条降低了我做"营养 AI 内核"的第一道工程门槛。 我每周只有 8 小时，任何能省掉"自己写记忆层 + 自己写 MCP 适配"的现成件都是直接的时间收益。我下周要做的第一件事就是拿它跑一遍我自己的交互日志，看能不能替掉我那套"每次交互都存一遍"的笨办法。
• Apache-2.0 对我的路径友好得多。 对比今天的 diet-app（AGPL-3.0）与 lightpanda（AGPL-3.0），Apache-2.0 允许我改造后闭源提供，这对"考证钩子 + 营养 AI 内核轻量助手"这种要卖的东西是刚需。选型时把许可证当成一等筛选项，比选完再补救便宜得多。
• 一个诚实的观察：122 星、处于 Beta、API 可能在小版本间变化。 所以我的态度是先当"接口设计参照"看——看它怎么定义"什么是 agent 记忆"、夜间维护到底维护什么——而不是现在就把它接进生产链路。 我的最小可行版还经不起一次数据层重构。

二、分类速览

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

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

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

④ 模型底座与 Agent 基础设施

三、今日趋势观察

• 今天最值得记的一条，是「凭据不进模型上下文」这件事被提到了比运行时拦截更靠前的一层。 上一期 hashgraph-online/hol-guard 讲的是 agent 运行中如何阻断危险工具调用与密钥访问；今天 lightpanda-io/browser 讲的是页面里的那个密码根本不该被渲染进模型看到的那份内容，而且工程上强调"遮蔽之后要重建那一行，不能去原页面搜索替换"。两件事叠加起来才是一条完整的安全链：先别让模型看见，再别让模型动手。 我做 4pwellness 助手与营养 AI 内核时，这两层目前只有后半层。

• 临床 AI 今天给出的数字和它的自我限定方式，都值得我反复读。 seancpc/MedAgent-EHR 在 Stanford MedAgentBench 官方 grader 上报 ~88%（259–263/300），高于论文的最佳 baseline 69.67%；但作者立刻写明"此分数为对齐该 benchmark 的 agent 系统表现，非原始模型能力的纯比较"，并把 task10 明确标成所部署模型的已知弱项、以区间表述。更关键的是它自架 Gemma-4 / Qwen3.6 走 llama.cpp，从一个模型迁到另一个几乎零改动、分数近乎持平——结论是"决定 agent 表现的是 Planner/Executor/Verifier 结构与工具对齐，不是底座模型"。 对我这种本地跑 qwen2.5:7b 的人，这是最有分量的一条：该把钱和力气花在结构与确定性资产上，不必追更强的模型。

• 营养类项目集体在做同一件事：把"算"和"说"分开，并把这件事写进产品定位句。 whiteravens20/diet-app 的 README 原话是"AI is an optional assistant … it never invents nutrition facts"，配套的是确定性热量引擎（缺口不超过维持量 1/4、目标值有地板）与"AI 起草 → 校验层重算每个数字"的流程；JlMoreno00/sabor 用 MCP 把自托管 Mealie 变成"agent-ready 厨房"，同步到 Bring! 前必须先预览再带 digest 确认；NMH1988/fitcoach-ai-assistant 把人放在教练位、agent 在后面。加上我上期记的 craft-b/formula-forge 的"模型只提结构、数字由确定性层重算"，这是四个互不相识的团队在相邻领域收敛到同一条工程原则上。 对我这一周的取舍很明确：把确定性资产（受治理食材库、公式约束、审批卡点）先建硬，再让模型去填剩下的。

• Agent 的"权限边界"今天被两个项目从两侧夹住了。 一侧是 CopilotKit/OpenBot：每个 coworker 一个独立浏览器、一套自己的登录、自己的文件，只有你授权的工具，每个动作事前决定事后留痕，而且今天还把工具目录放开到"除四项外的全部标准目录"——授权面越大，闸门越难守。 另一侧是 nolabs-ai/nono：网络审批提示时暂停 PTY 中继、并实时记录代理审计事件。前者是"给多少权限"，后者是"运行时不许绕过审批"——两个方向必须同时做，只做一个都不够。 我现在的营养 AI 内核一个都还没做。

• 一条不该被忽略的负面信号：微软 AutoGen 已停止维护，而 LangChain 在同一天发了 1.7.3。 AutoGen 自己在 10 月中旬的提交标题里写明"AutoGen is archived and no longer maintained"，10-28 又在落地页加了 archive caution；同期 LangChain 于 10-29 发布 core 1.7.3。这不是新闻，但它是"我该把自己的 agent 建在谁身上"这道题的答案在收窄。 我这一周还在用的 dsh（DeepSeek Harness）本地框架、WorkBuddy 客户端、以及准备接的 MCP 生态，底层依赖的选择空间比一年前小了一圈——这反而说明我应该把力气花在自有的确定性资产与业务逻辑上，而不是押注某个 agent 框架的长期存活。

四、GitHub 地址速查

精选

• lightpanda-io/browser — https://github.com/lightpanda-io/browser
• seancpc/MedAgent-EHR — https://github.com/seancpc/MedAgent-EHR
• whiteravens20/diet-app — https://github.com/whiteravens20/diet-app
• CopilotKit/OpenBot — https://github.com/CopilotKit/OpenBot
• nambok/mentedb — https://github.com/nambok/mentedb

AI Coding

• https://github.com/anthropics/claude-code
• https://github.com/NanmiCoder/cc-haha
• https://github.com/milind-soni/OpenMausBot
• https://github.com/macro-inc/macro
• https://github.com/dotnet/skills
• https://github.com/gadievron/raptor
• https://github.com/zzet/gortex
• https://github.com/dyoshikawa/rulesync
• https://github.com/coleam00/skills
• https://github.com/griddynamics/rosetta
• https://github.com/TerminalSkills/skills
• https://github.com/Goldziher/ai-rulez
• https://github.com/andrewstellman/quality-playbook
• https://github.com/expo/skills

医学 / 临床研究 AI

• https://github.com/sunlabuiuc/PyHealth
• https://github.com/jamesrosing/your-procedure-is-denied
• https://github.com/MaSunKing/medical-research-agent-grpo
• https://github.com/heilashahidi/adversarial-openemr
• https://github.com/Nikhil0167/MedSynapse

健康 / 营养

• https://github.com/tahaygun/ai-calorie-tracker
• https://github.com/ivzxan/nutrisyai
• https://github.com/JlMoreno00/sabor
• https://github.com/NMH1988/fitcoach-ai-assistant
• https://github.com/sslugic/pulse
• https://github.com/ariefandw/saestu-pwa

模型底座 / Agent 基础设施

• https://github.com/langchain-ai/langchain
• https://github.com/kortix-ai/suna
• https://github.com/opensandbox-group/OpenSandbox
• https://github.com/kyegomez/swarms
• https://github.com/Anil-matcha/open-duet
• https://github.com/ModelEngine-Group/nexent
• https://github.com/nolabs-ai/nono
• https://github.com/kubernetes-sigs/agent-sandbox
• https://github.com/microsoft/autogen
• https://github.com/NVIDIA/NeMo-Agent-Toolkit
• https://github.com/Agent-Field/agentfield
• https://github.com/rome-os/rome
• https://github.com/mindroom-ai/mindroom
• https://github.com/Antseed/antseed

本期分类共 44 个项目，全部与往期去重。Star 数、许可证与提交时间均以 GitHub API / 仓库默认分支记录为准，截至 2026-10-30 21:00（北京时间）。