GitHub AI 日报 · 2026-10-28（周三）

一、今日精选 5 条

1. TencentCloudBase/CloudBase-AI-Toolkit：腾讯把「云开发后端」正式做成了 AI 编程 Agent 的插件、Skill 与 MCP 三件套

地址：https://github.com/TencentCloudBase/CloudBase-AI-Toolkit ｜ ★1,152 ｜ MIT ｜ TypeScript，腾讯云 CloudBase 官方出品，为 Claude Code / Cursor / CodeBuddy / DeepSeek Harness / OpenCode / Codex CLI 等 Agent 提供云开发后端能力

事件内容

这是一个三天前刚把重点从"文档"转向"运行时防护"的项目，而今天它的提交全部指向把安全与一致性写进 agent 的日常操作路径。

• 10-28 当天四条提交全是"防错"性质的：同步上游 cloudbase plugin skills、生成 cloudbase-intl 连接器包、docs(skills): 虚拟支付补入站通知验真与退款判定（把虚拟支付的入站通知验真与退款判定写进 Skill 文档）、fix(mcp): 环境候选补齐 platform 类型，平台代建环境不再消失。
• 供应链安全从"指南"升级为"可执行策略"：chore(supply-chain): fold npm security guide into AGENTS.md and drop specs exception 把 npm 安全指南折叠进 Agent 指令文件，并取消 exceptions 豁免；同一天补齐安全策略、漏洞报告表单与"报告渠道收敛"三份文档。
• MCP 服务已具备生产级规模：38 个 MCP 工具、全量工具体系测试 482 个用例通过；托管远程连接器采用 Streamable HTTP + OAuth 并已提交平台审核，工具描述与运行期消息支持 zh/en 双语。
• 能力面覆盖完整后端链路：云开发环境创建与切换、PostgreSQL/NoSQL 查询与 DDL、RLS 策略查看与编辑、云存储读写、云函数与云托管部署、静态托管发布、腾讯云 API 受控调用（服务白名单已扩至 57 个产品）。

值得关注的原因

• 这一条直接命中我正在做的两件事。 一是我在推的微信小程序后端本来就是 CloudBase 路线（cloudbase skill 里已有 web-development / postgresql / cloud-functions / auth-web / cloud-storage 五个 skill），二是我的 dsh（DeepSeek Harness）本地 agent 也在跑。这份仓库今天正好把 dsh-plugin 的技能同步路径、.cursor/rules、.claude-plugin、.codebuddy/skills 这几种分发格式一起刷新了——等于直接告诉我"别人的多 Agent 生态是怎么铺的"，比我自己逆向猜要快得多。
• "虚拟支付补入站通知验真与退款判定"这条提交的价值远超它本身。 我做 GLP-1 营养伴侣 V2 时，"用药与停药的 cascade 判定"就是典型的"必须有确定性规则、不能靠模型自由发挥"的环节。他们把这条写成 Skill 文档并配 MCP 工具，说明这条路径已经在别人的生产环境跑过了——我可以直接对照他们怎么定义边界，而不是自己拍脑袋。
• "平台代建环境不再消失"是一条关于 agent 记忆的教训。 环境候选列表里补上 platform 类型，说明 agent 之前会把"平台代建"的环境从候选里漏掉，导致用户以为环境不存在。这类"类型标记不全导致状态丢失"的 bug，我在 4P 精准营养平台的干预报告版本管理里也踩过同款。 看别人怎么补这个字段，比自己 debug 快。
• 它同时立了个标准：新建关系型数据库优先推荐 PostgreSQL，MySQL Skill 只留给存量环境。 这条对我在做云端存储选型时是现成的决策依据。

2. itsoso/health-llm-driven：中文圈把「个人健康 OS」做成了产品——数字健康孪生、安全守护、行动排序、干预周期四段闭环

地址：https://github.com/itsoso/health-llm-driven ｜ ★3 ｜ 未声明 ｜ Python / FastAPI + Swift + Expo，大模型驱动的个人健康管理与执行系统（项目名"复元 Reva · Personal Health OS"）

事件内容

星数只有 3，但它是我看过的产品结构最完整的个人健康管理开源系统，而且是中文团队写的、面向 35–55 岁有早期代谢风险的人群——定位几乎就是我的目标用户。

• 产品闭环写得很明确：体检/可穿戴/症状/用药/补剂/行为记录 → 数字健康孪生（整理个人状态与证据）→ 安全检查 → 行动排序 → 健康日程（Mobile/Watch/Mac 辅助执行）→ 执行记录 → 复查与结果回顾 → 下一轮行动。长期目标是形成可追溯的"行动与结果账本"：建议了什么、实际执行了什么、哪些结果被验证、证据有哪些局限。
• 安全守护是一个独立 Agent，不是提示词里的一句话：对生命体征、化验、药物与补剂相互作用、药物基因组、血糖、症状和训练负荷执行规则检查；健康日程排序明确按"可执行性、可验证性、信心、执行成本与安全等级"五个维度打分。
• 10-28 当天的提交全部围绕"发布可信度"：docs(chat): record photo-reference safety review and release blockers（记录照片引用的安全评审与发布阻塞项）、fix(chat): clarify supplement photo references and adopt guardian icon（澄清补剂照片引用并启用监护人图标）、docs(release): record verified guardian icon and supplement delivery（记录已验证的监护人图标与补剂交付）、fix(ota): preserve Store 282 native branding boundary、fix(release): bind completed credential and preserve recovery cwd。
• 技术底座：后端 FastAPI + PostgreSQL + Redis + Celery，Agent 执行用官方 Pi runtime（Node.js）并由 Python 负责模型传输与健康工具执行；Mobile 用 Expo/React Native，Watch 与 Mac 端是 Swift 原生，另含 Next.js Web 与 mcp-server/ 目录。
• 边界写得很克制：不开处方、不自主调药量、不以模型回答替代诊断、证据不足时明确说明不确定性、高风险路径走安全规则 + 人工审核 + 临床随访；趋势变化必须结合噪声与缺失数据解释，不能直接视为因果证明。

值得关注的原因

• 它的四段结构和我 GLP-1 营养伴侣 V2 的模块几乎是一一对应的：我把功能拆成"食材模板 + 15 功能靶点 + 早/晚双杯方案 + Mazdutide 用药停药 cascade + 化验指标趋势追踪"，它拆成"健康孪生 + 安全守护 + 行动排序 + 干预周期"。但它多出两个我还没有的东西：执行成本与安全等级作为排序维度，以及"可追溯的行动与结果账本"。 后者正是我说的"每次交互数据持久化以支持自我进化学习"想达到的效果，它给出了更工程化的表述。
• "补剂照片引用"这件事，它踩的坑和我一样。 补剂干预报告里最容易出事的就是"用户拍照上传的产品图 → 系统认成什么成分 → 生成剂量建议"这条链。它把照片引用的安全评审单独作为发布阻塞项记录在案，还专门给补剂交付做了"监护人图标"这种防误导设计。这等于替我把一遍坑先踩了。
• "不能直接视为因果证明"这句提醒，比任何功能都值钱。 我所有的健康内容都要附循证证据，如果我的系统开始说"因为你吃了 X 所以指标变好了"，那就是幻觉的另一种形态。它把这句话写进了产品目标而不是 FAQ。
• 它是"中文 + 移动优先 + 多端"的完整实现，这一点比它 3 个星重要。 我做一人公司的最小可行版，最缺的不是算法而是"多端 + 后台 + 数据模型"这套骨架——它把 FastAPI + Postgres + Celery + Expo + Swift + Next.js + MCP server 全部摆在明面上。

3. craft-b/formula-forge：临床营养配方 agent 划出了一条硬边界——模型只许提结构，营养数字一律由确定性层重算

地址：https://github.com/craft-b/formula-forge ｜ ★0 ｜ MIT ｜ Python / FastAPI + LangGraph + Groq，面向临床与机构营养场景的食品配方设计系统（肾病人群、糖尿病、高蛋白、低脂、纯素）

事件内容

这是一个只有 0 星的新项目，但它把"AI 生成营养方案"这件事的工程边界划得比大多数商业产品都清楚。

• 信任边界是单一函数：_resolve_formula() 是生成结果进入界面的唯一路径，系统只接收每个配方行的三个字段（ref、percentage、notes），模型输出的其他营养字段直接丢弃；CandidateFormula 类型本身就不含营养字段，也不含 overrun_pct。
• 解析失败硬拒绝：食材引用解析不到受治理食材库就硬拒绝，绝不猜测替换成相近食材；配方总百分比偏离 100% 不超过 40 个百分点时做有界比例修复，超过即拒绝。
• 一次受限修复：首次生成违规后最多重新生成一次，修复提示里写明每个违规项的实测值与限值；仍违规就明确标记为不合规返回，不伪装成已验证配方。_resolve_formula() 是直线代码没有循环，结构上不存在第三次生成。
• 指标是硬数字：受治理食材库 34 种、数据集版本 2026.10.0（USDA FDC Foundation Foods）、后端与领域测试 420 项、golden compliance set 18 个用例、schema 有效率 100%、合规准确率 100%、路由评估 46 个已标注 brief、意图路由正确率 100%、规则集激活正确率 100%。
• 10-28 当天三条提交在收拾"多嘴"问题：Stop the UI narrating a pipeline it cannot see, and the proxy failing silently（让界面停止叙述它看不见的流程，并修掉代理静默失败）、Merge b3-verified: close B3, and stop three surfaces asserting what they cannot see（关闭 B3，并让三个界面不再断言它们看不到的东西）、Explain the wait on the Idea Stream, where a first visitor actually lands。

值得关注的原因

• "模型只提结构、数字由确定性层算"这句话，就是我一直在说的"强制循证 + 零 AI 幻觉"的工程版本。 我在 GLP-1 营养伴侣 V2 里靠"食材模板 + 规则引擎 + 禁用补剂清单"来实现，它靠"受治理食材库 + 领域层纯 Python 计算 + 声明式 JSON 规则集 + 一次性受限修复"。两条路殊途同归，而且它的可验证性做得更硬——合规准确率 100% 这种数字，是能直接写进我方报告的说服力资产。
• "最多一次修复"这个上限设计，比"循环直到通过"高明得多。 我在做补剂配方冲突时的逻辑一直是"给一次带具体违规反馈的重来机会"，但我从来没把它写成硬约束。它用代码结构（直线函数、无循环）保证"不存在第三次生成"——把产品原则写进类型定义和函数形状，而不是写进文档里靠人记，这是我可以整体搬过去的一招。
• 它最戳我的是最后那条提交：让界面停止叙述它看不见的流程。 这正是我反复警惕的"AI 说得好听但其实啥也没跑"。它把"界面不许宣称自己没验证过的东西"当成 bug 级别的问题来修。这条对 4P 补剂平台的干预报告是直接的：报告里任何一句"已优化""建议调整为"，背后都必须有真实的计算痕迹。
• 它把"受限食材库 + 版本化数据集"当成核心资产，而不是附属数据。 我做 4P 精准营养的食材库时，一直把它当成"查表用的静态资源"；它把它当成需要版本号、需要定期 ETL、需要人工补充功能属性的一等公民（PAC/POD、过敏原、成本）。这个定位差别，会决定我后面数据维护的成本结构。

4. hashgraph-online/hol-guard：Agent 运行时终于有了自己的「杀毒软件」——危险工具、密钥外泄、提示注入、恶意包与 MCP 一并拦截

地址：https://github.com/hashgraph-online/hol-guard ｜ ★1,002 ｜ Apache-2.0 ｜ Rust + Python，AI Agent 运行时防护（阻断高风险工具调用、密钥访问、提示注入、恶意包、MCP 服务器、插件与 Skills）

事件内容

今天它的提交密度是全站 AI Coding 类里最高的一档，而且八条提交里有五条在做同一件事：把"谁批准的、批的是哪一层"固化成可验证的状态。

• 10-28 当天：feat(guard): preview a redacted source export from the Workspaces tab（从工作区页预览脱敏后的来源导出）、refactor(approvals): settle an approval's scope and persistence in one resident ask（在一次驻留询问里同时确定审批的范围与持久化）、refactor(supply-chain): settle a package review from the resident's verdict（依据驻留判定结论确定一次包审查结果）、refactor(codex): walk a Codex hook source's inventory in the resident（在驻留态里遍历 Codex hook 来源的清单）、fix(runtime): watch mode keeps the known-vulnerable runtime finding over an earlier warning（watch 模式下保留"已知存在漏洞的运行时"这条发现，而不是被更早的警告覆盖）、feat(dashboard): load commands for command-line tools Guard has only seen in use、fix(command): read npm's report verbs as the reads they are（把 npm 的 report 动词按"读"来解析）、fix(command): create a branch at a start point without asking。
• 防护面覆盖六类风险：危险工具与命令（含 shell、工作区沙箱、cd 路径、工具权限）；密钥与凭据访问（在持久化工具调用通知前遮蔽 Bearer token、API key、X-Api-Key、X-Auth-Token、--password、--api-key）；提示注入（prompt policy、approval context、提交 hook）；恶意包与供应链（manifest 依赖解析、lockfile 一致性、版本冲突、离线安装前校验 bundle 签名，拒绝签名无效/过期/回滚的 bundle）；MCP（provider catalog、工具权限、URL 安全、持久化子进程生命周期）；插件与 Skills（发布者信任绑定、命令描述符、审批规则）。
• 核心工程原则是 fail closed：原生运行时无法完成可信决策时不会自动降级为放行；策略决策有作用域粒度（global / harness / artifact / family）；本地一次性审批使用完整性材料并原子消费，避免重复使用。
• 多 harness 集成：Claude Code、Codex、Copilot、Grok、Oh My Pi、Pi、OMP；分发形式包括 CLI、GitHub Action、Claude Code plugin、devcontainer feature、dashboard，以及 Kubernetes（k0s / k0rdent）部署示例。

值得关注的原因

• "fail closed"这一条是我做 AI 助手产品最该抄的默认值。 我在 4pwellness 的 MCP 连接器和营养 AI 助手上，默认应该是"检测不到风险就按通过处理"吗？不是。默认应该是"无法确认就阻断并提示人工"——这个默认值决定了我的产品在上线后的第一周会不会被用户投诉。
• "审批的作用范围"这个概念，正是我在 4P 精准营养千人先锋项目里最缺的一块。 我一直担心的是"授权一次就被无限复用"。它把作用域拆成 global / harness / artifact / family 四层，再用完整性材料 + 原子消费实现"一次性授权只能用一次"——这正是我一直想要却没想清楚怎么表达的"授权边界"。
• secret 遮蔽的具体字段清单可以直接复制。 我给 AI 助手接模型密钥时，token 会不会被打进日志、会不会出现在错误信息里被 agent 读走再回传给模型——这是真实风险。他们把这些字段名逐一列出来，我照抄即可。
• 它同时说明了另一件事：agent 安全正在从"扫描仓库"转向"运行时拦截"。 NVIDIA 的 SkillSpector 扫的是安装前的技能包，hol-guard 管的是运行中的每一次工具调用。两道闸门不冲突，而且是标配。 我在做"考证钩子 + 营养 AI 内核"的一人公司产品时，这两样都不该省。

5. JuneYaooo/open-medical：给医生用的开源桌面 Agent——把"证据从哪来"做成三级分层，把"AI 改档案"做成待确认提案

地址：https://github.com/JuneYaooo/open-medical ｜ ★11 ｜ MIT ｜ TypeScript / Electron + Node.js + SQLite，面向医生的开源桌面 Agent（macOS / Windows）

事件内容

这是今天医学线里设计最完整的一个，它对"循证"和"人机分工"的处理方式值得逐条看。

• 证据三级分层：治疗审查按 knowledge → literature → web evidence tiers 组织；知识库命中后可查看原文行号；资料保留作者或机构、年份、来源链接与版本；知识图谱、思维导图与流程图节点均可回溯原文；提取不到依据时不会自动补齐关系。文献检索支持 PubMed 与 Europe PMC，循证任务可准备 PICO 与检索式。
• AI 改档案走提案制："AI 对档案的更新以待确认提案呈现，医生核对后才写入"；同日冲突的数据保留供核对，不把不同单位的数值混成同一条趋势；检验结果导入保留项目、日期、数值、单位与出处。
• 14 个临床任务模板覆盖收治病例全流程、整理病历、摘录检验、核对用药资料、生成病历草稿、用药安全核查、患教大白话、检验报告解读、出院小结草稿、值班交班记录、诊疗决策流程图（Mermaid，保留节点出处）、不良反应筛查（辅助准备 Naranjo 评估）、个案报告写作（CARE 框架）、准备循证检索。其中用药安全核查依赖有限的内置规则，检验报告解读依据报告单打印的参考范围。
• 随访走微信：支持企业微信或个人微信渠道，流程是"AI 起草 → 医生确认发送 → 回复按条目整理 → 确认归档"；知识库机器人只引用明确允许对外使用的资料。
• 10-28 当天：Improve clinical evidence review and overview recovery（改进临床证据复核与概览恢复）；10-27 一天六条：Document evidence-based clinical interface development rules、Improve clinical overview hierarchy and reading contrast、Complete lab, source export and verifiable backup recovery workflows、Improve case context, follow-up linkage and source reading、Clarify task context, model connection status and patient intake、chore: release desktop 1.0.30。
• 本地优先但坦白边界：患者与消息数据存本机 SQLite（~/.open-medical-workbench/medical.sqlite，数据库本身未加密），模型密钥走本地凭据保险库加密；明确承认"本地优先"不等于用云模型时材料不会离开本机；同时明确列出不支持项——多人权限体系、机构级审计、HIS/EMR/FHIR 对接、机构部署验收。

值得关注的原因

• "AI 对档案的更新以待确认提案呈现，医生核对后才写入"这一句，是我全部健康内容生产原则的产品版。 我做 4P 补剂平台的干预报告时，一直坚持"用户确认后才落库"，但从来没用过"提案"这个载体——提案天然带 diff、带撤回、带审计痕迹，这是把"强制循证"从口号变成数据结构的正确方式。
• 它把"证据从哪来"分成三级并要求可回溯到原文行号，这正好补上我 GRPM 系统一直缺的外部标尺。 我在评估自家生成的营养建议质量时，最大的痛点就是"我拿什么当标准答案"。当一个系统能把每条结论指回原文行号，我就可以拿它的结构去做我的回归测试基准——这比我自己写一套 rubric 靠谱得多。
• 它的自我边界披露方式值得学。 明确写"数据库本身未加密""本地优先不等于数据不出本机""DRG 是演示规则不能用于实际医保结算""AI 临床有效性尚未验证不能替代医生判断"。这不是示弱，是把合规风险提前声明——对一个要面对真实用户健康数据的产品，这种坦白比多几个功能更能建立信任。
• "医生确认 → 发送 → 按条目整理回复 → 归档"这条微信链路，和我 4pwellness 微信群客服 Bot 的设想几乎一模一样。 差别只在垂直方向——它是临床随访，我做的是营养与补剂指导。这是我第一次看到一个把"真人确认后再触达用户"写进产品流程的开源实现，值得逐行读一遍它的边界处理。

二、分类速览

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

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

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

④ 模型底座与 Agent 基础设施

三、今日趋势观察

• 今天最值得记的一条，是腾讯云把"云开发后端"正式做成了 Agent 生态位。 CloudBase-AI-Toolkit 38 个 MCP 工具、482 个测试用例、托管远程连接器走 Streamable HTTP + OAuth 并已提交审核、Cursor Plugin 0.2.1、.codebuddy/skills / .cursor/rules / .claude-plugin / dsh-plugin 五种分发格式同步刷新——这不是一个功能更新，是一个生态位的宣告：云后端不再是 agent 去"猜"着调 API，而是主动长出 Skill 和 MCP。 同一周里 HKUDS/AutoSwarm 把 Codex、Claude Code、DeepSeek Harness、Muse、Grok、WorkBuddy 统一编排，OrchestratorInc 在 30+ 编码 agent 之间做统一调度，三件事指向同一件事——"多 harness 统一"正在从个人技巧变成标准工程动作。

• AI 生成健康方案的信任边界，今天被两个项目从两侧夹住了。 formula-forge 从模型侧收口：只接收三个字段、营养数字由确定性层重算、解析失败硬拒绝、最多一次修复、420 项测试与合规准确率 100%；open-medical 从医生侧收口：证据三级分层、AI 更新以待确认提案呈现、提取不到依据就不补齐关系、明确列出不支持项。两个项目星数分别是 0 和 11，但它们定义的东西——"模型负责提议，规则负责判定，人负责确认"——正是我在 4P 补剂平台干预报告里已经写死却还没找到参照实现的三段式。

• Agent 运行时安全的重心，从"扫描安装包"移到了"每一次工具调用"。 NVIDIA/SkillSpector 扫的是装之前的技能包，hol-guard 管的是运行中的危险工具、密钥外泄、提示注入、恶意包与 MCP；今天的提交里"审批的作用范围"被固化成 global / harness / artifact / family 四层、一次性审批用完整性材料原子消费、fail closed 成为默认。这跟上一期日报里"agent 系统的下一个战场是状态与权限"完全接上了——只是这一期，权限开始有了具体的层级和默认拒绝语义。

• 健康类项目开始集体学一件事：不把"我算出来的"说成"我验证过的"。 formula-forge 让界面停止叙述它看不见的流程；open-medical 承认本地优先不等于数据不出本机、承认数据库未加密、承认 DRG 只是演示规则；itsoso 的发布提交把"照片引用的安全评审"直接当阻塞项；BrooklynD23 在文档批次里专门处理"RAG-TIMEOUT-GROUNDED 已被回答""开放项保持开放"这类措辞。四个不同团队、同一天、在四个不同的项目里，做同一件容易被忽略的事：把"没做到"写进产品里，而不是藏起来。 对健康内容而言，这种"自我限制的可见性"比任何功能都更接近专业。

• 三个零星项目提示了"营养 AI 内核"的另一种建法：不追求大模型能力，而追求确定性资产。 formula-forge 用 34 种食材的受治理库 + 版本化 USDA FDC ETL + 声明式 JSON 规则集，做出一个合规准确率 100% 的系统；forma 用训练师 + 营养师 + 厨房 + 医疗安全复核四个角色分工而不是一个全能 agent；itsoso 用规则 Agent 专门看药物与补剂相互作用、药物基因组和训练负荷。共同的思路是：让模型去处理"人写不清规则"的部分，把"必须算准"的部分交给代码。 这对每周只有 8 小时的一人公司路径是最现实的架构——先建小而硬的确定性资产库，再让模型去填剩下的。

四、GitHub 地址速查

精选

• TencentCloudBase/CloudBase-AI-Toolkit — https://github.com/TencentCloudBase/CloudBase-AI-Toolkit
• itsoso/health-llm-driven — https://github.com/itsoso/health-llm-driven
• craft-b/formula-forge — https://github.com/craft-b/formula-forge
• hashgraph-online/hol-guard — https://github.com/hashgraph-online/hol-guard
• JuneYaooo/open-medical — https://github.com/JuneYaooo/open-medical

AI Coding

• https://github.com/OrchestratorInc/agent-orchestrator
• https://github.com/HKUDS/AutoSwarm
• https://github.com/superdesigndev/treg
• https://github.com/elayadesign/ai-design-skills
• https://github.com/NVIDIA/SkillSpector
• https://github.com/nightly-labs/openbot
• https://github.com/ZHangZHengEric/Sage
• https://github.com/useLexora/Lexora
• https://github.com/ChesterRa/cccc
• https://github.com/Cotal-AI/Cotal
• https://github.com/Undertone0809/rudder
• https://github.com/jmagly/aiwg
• https://github.com/Blave-TW/blave-agent
• https://github.com/NanmiCoder/open-image-prompts

医学 / 临床研究 AI

• https://github.com/Deng-GuiFeng/LPSGM
• https://github.com/jkelleman/health-biometrics-biotech-agentic-system
• https://github.com/organicoder42/openclawresearch
• https://github.com/tridaai/blueprint-agentcore-pharmacovigilance

健康 / 营养

• https://github.com/lhzin2129-wq/forge-nutrition-clients
• https://github.com/BrooklynD23/HealthCentral
• https://github.com/CraftedByMehathab/meTune-app
• https://github.com/VoMinhKhoii/Kallo
• https://github.com/Manvith-d/forma
• https://github.com/im-tnyx/tio-world

模型底座 / Agent 基础设施

• https://github.com/paradigmxyz/centaur
• https://github.com/ongridio/ongrid
• https://github.com/Azure/agent-landing-zone
• https://github.com/bex-co/bex
• https://github.com/brycewang-stanford/StatsPAI
• https://github.com/NVIDIA/auto-ontology

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