GitHub AI 日报 · 2026-11-04（周三）

一、今日精选 5 条

1. ovumcy/ovumcy-web：把"预测可不可信"变成一道代码闸门——不只算出受孕期，还要在数据不够时整段扣住不放

地址：https://github.com/ovumcy/ovumcy-web ｜ ★133 ｜ AGPL-3.0 ｜ Go ｜ 自托管月经周期追踪器，单个 Go 二进制 / 容器，SQLite 或 PostgreSQL，无账号、无分析、无遥测

事件内容

窗口内 54 次提交（11-03 08:20Z ~ 11-04 02:00Z），主线是预测展示闸门（forecast notice）的重构与日历订阅的可靠性修复。

• 本期的核心动作是"显示"与"计算"彻底分离：文档 docs/cycle-prediction.md 明确写"whether a given estimate is shown is a separate gate"，那个会扣住整段受孕信息的闸门，被描述为"the one that withholds the whole fertility half until the account completes three cycles"——即用户完成 3 个周期前，整个受孕半边（含排卵日与易孕窗）一律不显示。闸门本身也被收进一个 flag（refactor(dashboard): drop the forecast notice in its flag, not per site），而不是散落在每个界面里逐站点判断。
• "一个规则决定周期从哪天开始，所有界面读同一个答案"：完成周期数、各周期长度、末次经期开始日、仪表盘的周期第几天、日历的"已记录"标记、统计洞察与黄体期推断——六处口径必须一致，"两块屏幕不能对同一段历史给出不同答案"。规则本身写得极其具体：相邻不足 5 个完全无出血的日子算同一次出血事件；事件在满足下列任一条件时开启一个周期：连续 ≥2 个非点滴的经期日；用户手动标记为周期开始（非"不确定"）的一天；一个孤立的非点滴经期日且日期为今天或昨天（经期可能还没结束）。
• "点滴永远不开启一个周期，即使被标记过"：流量为点滴、或唯一出血信号是 Spotting 症状而未选流量流量的那一天，即使打了标记也不算开始。被标为"不确定"的开始（短间隔警告后选"Mark anyway"）等同于没标记。未来日期的开始被忽略。
• 文档与实现被强制绑定：文档中的所有算例由 internal/services/cycles_reference_test.go 逐条镜像，因此文档与实现不可能悄悄漂移。这是"循证内容必须附可复算依据"这条规则在代码里的落地形态。
• 文档首行就写死了边界：> [!IMPORTANT] 引用块写明"这是基于日历的估计，不是医疗建议，也不是避孕方法"，并逐条列出它不能做的事：不能检测排卵、不考虑疾病/压力/药物/激素状况、对不规律周期不可靠。文档 3.8 万字节，security-invariants 10.9 万字节，GDPR 专章 2.3 万字节。

值得关注的原因

• "计算得出来"和"可以给你看"分成两个闸门，这正是我 GRPM 报告与 4P 干预报告最需要的那一层。 我现在的算法能算出"这个用户缺维生素 D、镁吸收率偏低、B12 边缘不足"，但我缺一把尺子来决定什么时候可以把这些话说出口、什么时候必须扣住。ovumcy 的做法是：数据不够就不显示整段，而不是显示一个低置信度的数字。 对应到我的场景——GRPM 里 40 个 SNP 只覆盖部分位点时，报告不该给出"你的叶酸代谢能力偏低"这种半截结论，而是应该把"这段结论的证据基础不足"明确写出来。这和我上一期记的 aureproof 的"闸门能返回 inconclusive"是同一族思路，但 ovumcy 给得更狠：inconclusive 的实现方式是整段不显示，而不是显示 inconclusive。
• "三个周期之前不显示易孕窗"是可以直接抄成产品规则的。 我的补剂方案也有同类问题：用户刚填完问卷，算法给出的干预建议在数据量不足时其实只是猜测。用"完成 N 个周期/填满 N 项数据"当显示闸门，比在报告里写"仅供参考"要有效得多——后者用户根本不看。
• ⭐ 文档与参考测试 1:1 镜像，这条直接命中我公众号循证内容的痛点。 我的公众号文章（4P精准营养观察、健康100新一观察）要附参考文献、要零 AI 幻觉，但我目前没有任何机制保证"文中写的机制"与"平台里实际跑的算法"是同一套。ovumcy 的做法是把文档里的每个算例变成一个测试用例，文档改了但代码没改，CI 就红。这一条可以直接搬到 GRPM：每个 SNP 位点的判定规则写进文档 + 每条规则一个测试用例。
• "六处口径必须一致、两块屏幕不能对同一段历史给出不同答案"是数据一致性的教科书表述。 对应我的 4P 平台：同一个人的化验指标在仪表盘、AI 建议、Excel 导出、干预报告里必须完全一致，现在这四处是四份代码写的。ovumcy 把"one rule decides it, and every surface reads the same answer"写进文档第一屏，这个约定值得照抄。
• "点滴永远不开启一个周期，即使被标记过"——把例外规则写成绝对禁令，而不是优先级排序。 我上一期记的 grotyx 那条"证据只支持关联时措辞不许升级成因果"是同一族思路：给提示词和给算法加"硬否决条件"，比加"优先级"可靠得多。
• AGPL-3.0，只能读不能抄。 对一人公司来说这不影响我学它的设计思路，但如果哪天想直接把它的周期预测算法拿来做 GLP-1 营养伴侣的女性周期模块，这条授权是硬墙。真要用，得看 ovumcy 是否有"仅用于个人健康用途"的单独授权路径。

2. vercel-labs/agent-desktop：让 agent 操作桌面不靠"看图猜坐标"，而是读系统的无障碍树并给每个可点元素一个稳定引用——今天正式加上了 MCP

地址：https://github.com/vercel-labs/agent-desktop ｜ ★12,940 ｜ Apache-2.0 ｜ Rust ｜ 给 AI agent 的电脑操作能力，macOS / Windows / Linux 三平台，走操作系统无障碍树，CLI + C 库双形态

事件内容

窗口内 6 次提交（11-03 23:13Z 前后），但本期是它登顶 GitHub 热度榜之后的第一个版本，且这个版本本身带一个标志性动作。

• ⭐ 本期最重要的一个提交是 feat: agent-desktop mcp (#519)——它把桌面操作接进了 MCP。 这意味着任何 MCP 客户端（Claude Code / Codex / Claude Desktop）都能直接驱动真实桌面应用，不再需要各家的私有扩展协议。对一个要卖的产品来说，这一步的分量比 1 万星更重要。
• 核心机制是"读无障碍树 → 发稳定引用 → 动作 → 再读一次验证"：命令 agent-desktop snapshot --app Finder -i 列出该 app 的可交互元素并给每个元素一个 ref（形如 @s8f3k2p9:e8，ref 自带 snapshot id），agent 对 ref 执行点击/输入后重新读一次界面确认结果。"这个循环住在你的 agent 里，agent-desktop 内部没有模型。"
• 失败方式是显式的，不是猜的：引用过期返回 STALE_REF，目标不唯一返回 AMBIGUOUS_TARGET，裸写 @e8（不带 snapshot id）直接返回 INVALID_ARGS。默认无头运行——不移动鼠标指针、不抢焦点，需要真实物理输入才显式加 --headed。
• 输出是一个 JSON 信封，内含 complete 布尔字段：{"version":"2.6","ok":true,"command":"snapshot","data":{"app":"Finder","snapshot_id":"s8f3k2p9","ref_count":59,"complete":true,"tree":{...}}}。"complete" 这个字段是给调用方的一个完整性自证——和我在 11-03 期记的 aft 的 shown N of M 是同一族设计。
• 架构上刻意做了一层隔离：CLI 与 C 库都经过 agent-desktop-core 和 PlatformAdapter trait，编译期只选一个平台 crate，分别走 macOS 的 AX API、Windows 的 UI Automation、Linux 的 AT-SPI。进程内可直接被 C / Python / Go / Node 调用。
• 另有两个 macOS 细节修复：光标覆盖层画在菜单与系统面板之上（fix(macos): draw the cursor overlay above menus and system panels）；只允许容器选择的列表行现在能被正确选中（feat(macos): select list rows that only their container can select）。两者都是"真实桌面自动化里最烦人的那类边角"。

值得关注的原因

• "不靠截图猜坐标"是这一整代工具的分水岭。 目前大部分 agent 操作 GUI 的方式是截图 → 让模型猜像素坐标 → 点下去 → 再截图确认。这条链路在按钮位置微调、窗口滚动、主题变化时就会失效，且失败方式很隐蔽。 ovumcy 那条我要单独讲，但 agent-desktop 这条更直接：用系统无障碍树拿到的是"按钮叫这个名字、类型是按钮、可执行动作是 Click"，是语义而不是坐标。
• ⭐ 对我最重要的可迁移物是那个 complete 字段和 STALE_REF / AMBIGUOUS_TARGET 的显式失败。 我 4P 平台的化验报告 OCR 管线现在遇到识别失败时的默认行为是"跳过这一项继续"——这就会产出"24 个风险维度里其实只识别到 18 个"的报告，而且报告自己不知道。agent-desktop 的做法是：要么给完整结果并附 complete: true，要么明确告诉你哪一项目标不唯一、哪一条引用过期。 这和我上一期记的 aft 的"没有 shown N of M 就代表列表完整"是同一条规则的两个方向。
• "默认无头：不移鼠标、不抢焦点"这一条，对要在用户机器上跑的 agent 是决定性的。 用户不会接受一个后台 agent 在他工作时把鼠标抢走。同理，我的 4P 补剂平台如果要在用户本地跑任何自动化，默认必须是可逆、可见、不干扰。 这条我可以直接当产品原则写进需求文档。
• ⭐ 三个平台各走各的系统原生接口，编译期只选一个 crate——这个"薄适配层 + 单一核心"的结构，正是我接 4pwellness.org.cn MCP 连接器时应该照抄的。 现在我的 MCP 工具是逐个手写的，每个工具自己处理参数、自己处理错误。agent-desktop 的做法是：所有工具共用一个 core，平台差异只在一个 trait 后面。
• Apache-2.0，Vercel Labs 出品，可读可改可商用。 而且它同时提供 CLI 和 C 库并明确说"进程内直调"，这对我的 SaaS 形态（服务器上跑）比只能在本机跑的方案更合适。
• 注意它的隐私提示写得很硬："Snapshots, clipboard reads, screenshots, command output, and debug artifacts can contain private desktop content. Keep them out of public logs and uploads."——快照里就是用户屏幕上的真实内容，包括剪贴板。 这条对我做 4P 平台的日志脱敏是直接的提醒。

3. zarnautovic/tdeemon：把补剂/热量方案的"硬底线"写进代码里，AI 只能提议、不能执行——而且有一个 AI 永远无法下调的下限

地址：https://github.com/zarnautovic/tdeemon ｜ ★0 ｜ AGPL-3.0 ｜ Go ｜ 自托管、AI 优先的营养追踪，自适应 TDEE，AI 教练可在代码强制的上限内调整目标

事件内容

窗口内 22 次提交（11-03 ~ 11-04 02:24Z），主线是第二次界面重构（redesign 2）——从 app shell 开始，逐屏推进（day / foods and recipes / settings / progress，PR #252~#256）。注意这是一个"早期开发"项目，README 明确写了当前只有服务端骨架、数据库层、API 契约与 web 应用的框架。

• ⭐ 最有价值的东西在 docs/limits.md 里，一共三层限制，且最底层"谁都不能降低"：
  1. 代码里的地板线，管理员也不能下调：绝不建议每日低于 800 kcal；蛋白质不低于参考体重每公斤 0.8 g；减重速度不快于趋势体重的每周 1.5%、增重不快于每周 1%（这是一个约定，防止任何配置把方案推到文献范围之外）；不给 18 岁以下的人出方案；BMI 低于 18.5 的人，不做任何启动或加深减重的变更（包括减重期、低于 0 的增肌减脂、隐含减重的热量目标，以及在校准信任 TDEE 之前降低周均值）；目标体重或里程碑体重也不得低于该值。已在进行的减重当趋势跌破 18.5 时，自动舵不继续加步数，而是提议维持，并在摘要里标出来。
  2. 实例级限制：管理员在配置里设定，是这个实例上所有人的外层边界。
  3. 用户级限制：在实例限制之内，用户可以自由收紧；放宽某一项需要一次明确的确认。
• 只有一个函数 Validate 负责检查所有方案变更，且它会说明是哪条规则被打破、对应限值是多少、提议的值是多少。"AI 客户端可以提议改变用户的限制，但只有用户能从网页会话里应用它，且需要放宽时那一次确认"——提议的其余部分在被应用时依然受限制约束。
• 日志永远不受限、不受评判：一个 4000 kcal 的日子就是被记下来，"Limits apply to plans only"。这个区分很关键——限制的是"建议"，不是"记录"。
• 自适应校准带置信区间（从摄入与体重趋势里学习真实能量消耗），且 AI 只能通过"你接受的提议"来改变方案。文档明确标注 "not medical advice"，并列出"应该找临床医生"的情形。
• 技术底座与 Gordon 的形态高度一致：一个容器、一个 SQLite 文件、多用户（一个家庭共享厨房、食材与食谱，但每个人的餐次、体重与方案各自独立）；MCP server，任何 MCP 客户端配任何模型（Claude Code / Codex / Hermes / 本地模型）都能接入，且"教练会话读取的数字就是 tdeemon 自己算出来的那些数字"。

值得关注的原因

• ⭐ "AI 只能提议，用户才能执行，放宽还要再确认一次"——这几乎就是我 4P 补剂平台 GLP-1 营养伴侣应该照抄的那条规则，而我目前是反着做的。 现在的实现里，AI 拿到"化验指标变差"这一信号后会直接重算并落库整套早晚双杯方案，用户看到的是一个已经生效的结果。tdeemon 的三层限制 + Validate 函数 + 提议/执行分离，是我目前最需要补上的一层。
• ⭐ "800 kcal 地板线 / 蛋白每公斤 0.8 g 下限 / 减重每周不超过 1.5% / BMI 18.5 以下不加深减重 / 18 岁以下不出方案"——这五条是我做补剂方案引擎时最该直接引用的硬底线。 我之前的方案引擎里，这些约束是散落在提示词里的自然语言约束，LLM 可以被说服放弃其中任何一条。tdeemon 的做法是把它们写成代码里的地板线，管理员也改不动。 这几条本身也符合我公众号一贯的循证口径。
• "限制只作用于方案，不作用于记录"这一条切分，是我见过最干净的处理。 用户偶尔一天吃 4000 kcal 不该被系统说教，但系统绝不能基于这一餐给出一个 1200 kcal 的方案。我的平台现在这两件事是混在一起的。
• "Validate 会说明是哪条规则被打破、限值是多少、提议值是多少"——这是给 AI 用的错误信息，而不是给人看的。 这一条极其关键：当 AI 的方案越界时，错误信息必须能指导它自己修正，而不是只说"非法"。 我 4P 平台的校验器目前只返回"失败"，LLM 只能瞎猜怎么改。
• "跌破 BMI 18.5 时不自动加步数，而是提议维持并在摘要里标出来"——这是"自动化的边界要停在危险动作之前"。 对应到我的场景：当某个用户出现需要停用补剂或转诊的信号时，系统应该提议并提示，而不是自动执行。
• "一个容器 + 一个 SQLite 文件 + 多用户 + MCP"这一整套形态，和我 GLP-1 营养伴侣的技术路线几乎一致。 可以直接做架构对照。AGPL-3.0 意味着只能读不能抄代码，但设计思路随便学。
• ★0 星、不要因为星数就跳过它。 这是本期 119 个条目里第 8 条 0 星项目，而 docs/limits.md 的信息密度超过本期一半的高星项目。上一期（11-02）已经验证过这条规律：低星项目往往是最好的选题矿脉。

4. cyanheads/clinicaltrialsgov-mcp-server：把 60 万条临床试验注册记录做成一个 MCP 服务，并且把"患者匹配"明确写成"不检查入排标准"

地址：https://github.com/cyanheads/clinicaltrialsgov-mcp-server ｜ ★100 ｜ Apache-2.0 ｜ TypeScript ｜ 美国 NIH 临床试验注册库 ClinicalTrials.gov 的 MCP 服务，7 个工具 / 1 个资源 / 1 个提示 / 1 个技能，STDIO 或 Streamable HTTP，无需 API key

事件内容

窗口内 11 次提交，且本期正式发布 2.11.0 版本（chore(release): 2.11.0 — published skill, nctIds fitting, site-bound locations）。

• 7 个工具覆盖了从"找试验"到"读结果"的完整链路：clinicaltrials_search_studies（全文与字段级检索、状态/期别/地理过滤、分页、排序、字段选择）、clinicaltrials_get_study_record（按 NCT ID 取完整方案记录，可选 location/outcome/reference 上限）、clinicaltrials_get_study_count（只取总数不取数据）、clinicaltrials_get_field_values（发现某个 API 字段的合法取值，并附每个取值的试验数）、clinicaltrials_get_field_definitions（解析合法字段名）、clinicaltrials_get_study_results（取已发布结果：结局、不良事件、受试者流程、基线）、clinicaltrials_find_eligible（按人口学与疾病匹配候选的在招试验）。
• ⭐ 那个工具的描述里写着一句自我限定：clinicaltrials_find_eligible 的说明是"match patient demographics and conditions to candidate recruiting trials, without checking inclusion/exclusion criteria"。"匹配"与"符合条件"被明确分开——它匹配的是"人大概在哪类试验里"，不宣称这个人符合入组标准。 这是一个 AI 医疗工具最容易越界的地方，而它写在了工具说明里。
• 资源层的列表是有上限的：资源 clinicaltrials://{nctId} 取回研究 JSON 时，"capped lists and results replaced by counts"——列表被截断时不是悄悄截断，而是把结果部分替换成计数。
• 2.11.0 版本本身带了三个新东西："published skill"（技能首次随包发布）、"nctIds fitting"（把超长的 NCT ID 列表塞进输出）、"site-bound locations"（试验地点信息）。对应一个明确的技术处理：当参数过长时返回 request_too_long 错误，而不是静默截断。
• 本期还有一次很具体的正确性修复：fix(tools): name the AREA[] names the advancedFilter case correction skips——高级过滤器的某些大小写变体会被这个修复跳过，工具现在会把这些字段名明确列出来。 配套的测试是 test(get-study-results): fold every line break in the linear-growth oracle——把线性增长断言里的每一个换行都折掉，说明这个断言本来会因为格式差异而误判。

值得关注的原因

• ⭐ "不检查入排标准"这句话，是我做循证内容时最需要的那条免责声明的技术形态。 我公众号写补剂干预时，经常要引用某个临床试验的结论。如果一个工具能对某个用户说"你和这个试验的入组条件很像"，那几乎必然会有人理解成"这个试验证明这个方案对你有效"。 cyanheads 把这句话写在工具描述里而不是文档角落里，这比任何免责声明都管用。
• "列表有上限，超出就替换成计数"这个设计可以立刻搬到我的化验报告抽取管线。 我的 GRPM 与 4P 平台在处理长列表时，目前的做法是截断。换成"把完整列表换成计数"之后，下游的 LLM 就不会以为拿到了全部。
• "field_values 工具：发现某个字段的合法取值，并附每个取值的试验数"——这是"让 LLM 自己做 schema 发现"的做法。 比硬编码枚举更抗 API 变更。对应到我的场景：4P 平台的化验指标字典如果能自动发现合法项与每项的样本数，指标越界的判断就能基于真实分布而不是拍脑袋。
• "request_too_long" 这种显式错误码值得抄。 我的平台在给 LLM 塞化验数据时，超长截断是常规操作。把"装不下"变成一个明确的错误类别，让调用方自己决定分页还是取舍，比默默截断好得多。
• Apache-2.0，有公开托管实例（https://clinicaltrials.caseyjhand.com/mcp），无需 API key，可直接用 npx 装。 对一人公司来说，这是零成本接入的循证数据源。
• 而且它是 MCP，不是又一个 SaaS。 我正在推 4pwellness.org.cn 的 MCP 连接器，这类"权威公共数据库 + MCP 封装"的项目，正是我那个连接器应该优先接的一类——比自建 API 省事得多。

5. eltmon/overdeck：把"提示词时代"换成"循环时代"——并且给 agent 配了一条由四个视角组成的评审流水线

地址：https://github.com/eltmon/overdeck ｜ ★34 ｜ MIT ｜ TypeScript ｜ 面向 agent 时代的 IDE，"Loop 不是 Prompt"，内建三层循环与专家评审流水线，可 npx 直接启动

事件内容

窗口内 505 次提交——本期提交量最高的仓库之一，且提交高度自动化（标题多为 chore(workspace): backlog sequence），说明它背后是一套持续运行的 agent 流水线在给自己派活。

• ⭐ 核心主张只有一句，但很重："IDEs were built for humans who type code. Overdeck is built for humans who direct it — not with prompts, with loops." 它把 AI 辅助工作的单位从"提示词"重新定义为"循环"——行动、验证、纠正、再来一遍。
• 三层循环被明确分层：
  • 内层 —— agent 本身（秒到分钟）：harness 循环，写代码、跑它、读结果、再试。
  • 中层 —— 流水线（分钟到小时）："包在每个 agent 外面的验证者"，包括 four-lens review convoy（四视角评审车队）、质量闸门、测试、浏览器 UAT、逐 bead 检查，以及"让 main 保持绿的 merge train（合并列车）"。
  • 外层 —— Flywheel（持续）："提示那些循环的循环"——从 backlog 里拉下一个 issue，端到端驱动它，沿途把它发现的东西归档，然后继续。
• 原文对"稀缺能力"下了定义："Models write better prompts than we do now; the scarce skill is designing the loop that keeps agents pointed at the goal, and the verifier that decides whether the work is actually done." ——模型比我们更会写提示词了，稀缺的是设计循环和做验收的人。
• 使用门槛低：npx @overdeck/core 直接启动 Command Deck 并打开浏览器仪表盘；Node.js 22.16+ 起，若 shell 默认 Node 太旧会自动在已装的兼容 Node（Homebrew node@22 / nvm / fnm / volta / asdf）下重新拉起，找不到就打印确切的安装命令；仪表盘跑在 https://overdeck.localhost。
• MIT 授权，可直接商用。

值得关注的原因

• ⭐ "中层流水线 = 包在每个 agent 外面的验证者"这个分层，对我 4P 平台的干预报告生成是直接可搬的。 现在的做法是"一次 LLM 调用生成报告"，没有独立的验证者。overdeck 的结构是：agent 负责产出，中层流水线负责验证（四个视角评审 + 质量闸门 + 测试 + 合并列车）。我上一期记的"干预报告落库 checklist"（精确值比较 / None 匹配存储空值 / 拒绝字面量占位符）就是这样一个"验证者"的最小版本。
• ⭐ "four-lens review convoy"（四视角评审车队）这个形态值得细看。 它和我上一期记的 athril（遗传 / 生物学 / 安全性 / 临床 / 商业 / 监管 六个独立视角打 0-100 分）是同一个思路：用一组互相独立的视角，而不是一个更精细的分数。 我现在的干预报告是单一维度打分（风险等级 6 档），改成"多视角分别出结论"能消除掉"分数掩盖了某一维度的极端值"这类问题。
• "merge train 让 main 保持绿"——这条映射到我的内容生产。 我的公众号文章和干预报告是"批量生成 → 人工审 → 发布"，但目前人工审是串行的、一篇一篇看。如果有一个"合并列车"，让每一篇文章先过自动闸门（数字核对 / 引用存在性 / 字数与格式 / 禁用词），再进人工队列，我的内容产能会明显不一样。
• "外层 Flywheel：从 backlog 拉下一个 issue，端到端驱动，沿途归档发现"——这是无人值守的自我推进。 对应我的 4pwellness MCP + AI 助手：它应该能自己从待办队列里取任务。我现在每次都要手动说"继续"。
• "模型比我们更会写提示词了"这句话本身就是对"提示词工程"这个工种的一个判断。 这与我上一期记的"AutoGen 已停止维护、LangChain 同日发 core 1.7.3"是同一条趋势线：价值正在从"写好提示词"迁移到"设计验证回路"。 这对一人公司是好消息——提示词不是护城河，回路设计才是。
• ★34 星，MIT，npx 就能跑。 这是本期"低星高密度"名单里最值得跑起来试的一个。

二、分类速览

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

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

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

④ 模型底座与 Agent 基础设施

三、今日趋势观察

本期最值得记住的一条判断：AI 工具的竞争焦点正在从"谁能生成"移向"谁能证明"。 三个互不相干的项目在同一周给出了同一个答案。agent-desktop 的快照 JSON 里带 complete 字段、过期引用返回 STALE_REF、目标歧义返回 AMBIGUOUS_TARGET；ovumcy 把"数据够不够展示"从计算逻辑里拆出来做成独立闸门，文档与参考测试 1:1 镜像；tdeemon 把 800 kcal 地板线、蛋白每公斤 0.8 g、减重每周 1.5% 这些硬约束写成管理员也改不动的代码，AI 只能提议、用户才能执行。共同点是：都不让"生成成功"等于"内容可信"。 这条对做健康产品的人尤其重要——健康建议一旦被采纳就会变成行为，错误的代价远高于一次写错的文案。

第二条观察：把"计算"与"呈现"分开，正在成为健康类产品的标准做法。 ovumcy 的受孕信息要满 3 个周期才解锁；tdeemon 的"记录"永远不受限但"方案"永远受限；clinicaltrialsgov 的 find_eligible 明确声明不检查入排标准。三个项目都在同一个位置设闸门：数据不足或条件不足时，宁可不给，也不给一个看起来完整的错答案。 目前我的 GLP-1 营养伴侣和 4P 干预报告都是"能给就给"，这一层是明确缺口。

第三条观察：agent 的界面在从"聊天框"变成"循环控制台"。 overdeck 把工作单位从 prompt 重定义为 loop，分出内层 agent / 中层验证者流水线 / 外层 Flywheel；vespin 让所有编码 agent 往同一个收件箱里发问；ai4kanban 是"草稿优先"的工作区；commonly 让 agent 像有主人的成员一样坐在任务板上。共同点是：人不再守着聊天框等 agent 说话，而是看板上有一堆待决策卡片。 overdeck 那句"模型比我们更会写提示词了，稀缺的是设计循环和验证者"说得最直接。

第四条观察，也是本期最刺眼的一条：许可证字段不能信。 本期 24 个仓库 API 报 NOASSERTION，逐个读 LICENSE 实文后发现里面有 MIT 和 Apache-2.0（可商用），也有 Elastic-2.0、SSPL-1.0、BSL-1.1、FSL-1.1、CC BY-NC-SA、PENN 学术许可和三个"保留所有权利"（不可商用）。如果只看 API 字段，误判率是 100%。 对一人公司尤其致命：Elastic-2.0 有明确的服务端 SaaS 限制，SSPL-1.0 几乎禁止任何商业分发，CC BY-NC-SA 明确禁止商用，三个"保留所有权利"的项目连个人使用都要谨慎。这应该固化成一条选型流程：任何要当底座的仓库，第一步不是读 README，是打开 LICENSE 文件读第一段。

第五条观察：GitHub 热度榜上今天的两个第一名（vercel-labs/agent-desktop +1,179 星、thedotmack/claude-mem 日增 1,803）都不是新的架构范式，而是"给 agent 补上人类已有的能力"——补视觉、补记忆、补桌面操作。 而本期真正在架构层面给出新东西的，是那些星标不超过 120 的项目（ovumcy ★133、clinicaltrialsgov-mcp-server ★100、overdeck ★34、tdeemon ★0）。这不是新项目赢了，而是"补齐"类需求在 2026 年已经饱和，接下来要看的是谁把细节做对。

四、GitHub 地址速查

https://github.com/vercel-labs/agent-browser
https://github.com/vercel-labs/agent-desktop
https://github.com/zeronsh/zeron
https://github.com/MiniMax-AI/minimax-code
https://github.com/devswha/ovis
https://github.com/nicobailon/pi-web-access
https://github.com/autonomous-ai/openharness
https://github.com/Team-Commonly/commonly
https://github.com/reticlehq/reticle
https://github.com/Einsia/agent-git
https://github.com/pleaseai/shunt
https://github.com/nuphos/nuphos
https://github.com/3x-haust/oh-my-design
https://github.com/fallow-rs/fallow-skills
https://github.com/alamops/agetor
https://github.com/moonrunnerkc/swarm-orchestrator
https://github.com/discobox-ai/discobox
https://github.com/slopus/happy-desktop
https://github.com/thefrederiksen/devthrottle
https://github.com/appandflow/stim
https://github.com/monte-carlo-data/mc-agent-toolkit
https://github.com/JKHeadley/instar
https://github.com/Mouseww/Prometheus
https://github.com/firewalker06/tycho
https://github.com/ai4kanban/ai4kanban
https://github.com/ReviewStage/vespin
https://github.com/lichdotdev/lich
https://github.com/middleapi/uncheck
https://github.com/curie-eng/curie
https://github.com/eltmon/overdeck
https://github.com/nottelabs/browserarena
https://github.com/knewstimek/agent-tool
https://github.com/epicsagas/epic-harness
https://github.com/memtomem/memtomem
https://github.com/doughayden/agent-foundation
https://github.com/cefege/roost
https://github.com/obophenotype/human-phenotype-ontology
https://github.com/zhihuanglab/TissueLab
https://github.com/cyanheads/clinicaltrialsgov-mcp-server
https://github.com/FerroHEALTH/FerroEHR
https://github.com/Nanboy-Ronan/awesome-medical-imaging-agents
https://github.com/HeliosSoftware/hfs
https://github.com/bcgov/healthgateway
https://github.com/pharmaverse/aNCA
https://github.com/insightsengineering/teal.gallery
https://github.com/mdbabumiamssm/LLMs-Universal-Life-Science-and-Clinical-Skills-
https://github.com/ClinicalBrainLab/clinicalbrainlab.github.io
https://github.com/ontogr/agentic-med-diag
https://github.com/ikmdev/komet
https://github.com/openmrs/openmrs-esm-form-builder
https://github.com/Delatolla-lab/PHESD
https://github.com/Clinical-Genomics/cg
https://github.com/healthkey-ai/promop
https://github.com/pardesline/pardesline
https://github.com/ulsklyc/yuvomi
https://github.com/ovumcy/ovumcy-web
https://github.com/AnandChowdhary/life
https://github.com/ErBharatMalhotra/open-source-ai-radar
https://github.com/cobuildwithus/murph
https://github.com/Absence0760/threkir
https://github.com/ThomasJuhasz/fitfoodway-scraper
https://github.com/abramsluka/atlas
https://github.com/staylan488-ux/hyPer
https://github.com/Break-Through-Tech/Nutrition-1A-dynamic-nutrition-orchestrator
https://github.com/PNelsonFTP/health-drudge
https://github.com/better-content/better-survival-physiology
https://github.com/cr2551/FitPath
https://github.com/daolvera/Dao.Maxxing
https://github.com/joaovitorsantos397/AI-Diet-Manager
https://github.com/liangzixuan/cronometer-gold
https://github.com/ndambra/human-nutrition-study
https://github.com/producer456/bio45-nutrition
https://github.com/rbinnovationllp/mamaai
https://github.com/refreshrefreshclan-lang/triton-fuel
https://github.com/tmje30/NTUC-and-other-scrapers-nutrition
https://github.com/tobiadonadon1/health-in-perspective
https://github.com/willbl3/daily-plate
https://github.com/zarnautovic/tdeemon
https://github.com/cheaper-inference/OmniRoute
https://github.com/nocobase/nocobase
https://github.com/kortix-ai/CompanyOS
https://github.com/experientiallabs/experiential
https://github.com/EKKOLearnAI/ekko-studio
https://github.com/TykTechnologies/tyk
https://github.com/maximhq/bifrost
https://github.com/qixing-jk/all-api-hub
https://github.com/HarnessRouter/harnessrouter
https://github.com/Draculabo/AntigravityManager
https://github.com/nottelabs/notte
https://github.com/ENTERPILOT/GoModel
https://github.com/Ozark-Connect/NetworkOptimizer
https://github.com/Sidiora-Labs/paxeer-monorepo
https://github.com/respanai/respan-gateway
https://github.com/rasonyang/ai-native-callcenter
https://github.com/tingly-dev/tingly-box
https://github.com/mcowger/plexus
https://github.com/Mistgate/mistgate
https://github.com/xibai6668/Android-AI-gateway
https://github.com/gnacho/netpulse
https://github.com/wink-run/tokenbank
https://github.com/doublewordai/control-layer
https://github.com/modelship-ai/modelship
https://github.com/Alakazam-211/K2
https://github.com/m1keluka/OperationKit
https://github.com/ferr079/pixelium-site
https://github.com/lostlight530/welcome-to-github
https://github.com/Anureyki/Mycelial-
https://github.com/ShieldLogic/neural-pulse
https://github.com/Tyox-all/Weave_Protocol
https://github.com/brandontan/walkermind-os
https://github.com/cinic0101/grepsignal
https://github.com/edithatogo/searchright
https://github.com/Lucien-rose/Raven
https://github.com/Republika-Network/Frontera
https://github.com/camilohurtado/agentic-context-infrastructure
https://github.com/d-hinders/Haven-AI
https://github.com/hirotomasato/agenmail
https://github.com/krizaka/orazaka
https://github.com/pipeworx-io/mcp-pitchprotocol