GitHub AI 日报 · 2026-11-07（周六）

一、今日精选 5 条

1. nicobailon/skill-diet：给 agent 的"技能包"做减法——70–80% 的 token 就能砍掉而不掉分，而且它把"在别的模型上还灵不灵"也变成了一张可复算的表

地址：https://github.com/nicobailon/skill-diet ｜ ★237 ｜ MIT ｜ Python ｜ 给其它 agent skill 做"减肥"的技能包 + 一个跨模型复检技能 skill-model-gap

事件内容

窗口内 3 次提交（11-06 04:31Z ~ 11-06 06:18Z），主线是发布 v0.2.0，把"技能瘦身"从一次性动作升级成可持续的维护契约。

• ⭐ 核心命题是一句很硬的观察："agent 每次使用技能都会把整个 SKILL.md 读一遍。" 因此技能里多写的每一行，都是每次调用都要付的钱。README 直指四类冗余：只有部分任务用得上的细节、模型本来就知道的东西、写给人看而不是写给 agent 看的说明、以及一个概念就能替代的清单。更隐蔽的一类是：教工具的技能会把工具的参考手册抄一份进自己体内，而这份抄件会随工具演进而变成过期信息。
• ⭐ 瘦身的结论是可复算的，不是感觉：README 明确写"在真实技能上，diet 砍掉了 70–80% 的 token 且测试结果没有下降，并且找出了技能里记录、但实际已经不能用的命令"。也就是说瘦身不只是省 token，它还兼职做技能与工具的漂移检测。
• ⭐ "瘦身"有一套五层归位法，把每条事实放到"仍能到达 agent 的最低层"：① 技能 description（每个场景一个触发器，每次会话都读）② SKILL.md（每个任务都要的，用技能时读）③ 参考文件（只有部分任务要的，场景出现时才读）④ 工具自己的 help（flag、允许值、示例，agent 选命令时读）⑤ 工具自己的报错与检查器（正确名字、怎么修、下一步，agent 猜错时读）。越往下越省上下文——这一层级就是一条明确的"上下文成本账本"。
• ⭐ v0.2.0 新增的 skill-model-gap 解决的是一个我几乎没意识到的问题：大多数技能只在最强的一个模型上写和测，但很多人跑在别的模型上，而它会"悄悄地"做得更差。 做法是在每个你选的模型上跑同一批任务，找出弱模型为什么失败，只保留"对弱模型有帮助且不伤害其他模型"的修法。首次试验的结果被写在发布说明里：改动技能 description 里的一行，把 Kimi 的通过率从 78% 提到 98%、Haiku 从 85% 提到 100%，同时 GPT 与 GLM 不降。
• ⭐ 评分规则被收紧，防止"因为错误的原因而通过或失败"：v0.2.0 明确运行被禁命令现在直接判该次运行失败；存在缺失运行的对比现在判失败，而不是给出一个误导性的结论。这一条比前面的数字更重要——它堵的是"评测本身在说谎"这条路。
• ⭐ 瘦身的判定门槛是"三版对照 + 盲评"：用旧技能、新技能、完全不给技能三种配置跑同一批任务，只要新版不更差就保留；且争议答案由一个没见过哪版写的全新会话来裁决；评分器如果发现新版比"随机水平"还差、或者新版从未通过旧版总能通过的任务，就判瘦身失败。任务集在动手删之前就先写好。
• ⭐ 对"教工具的技能"还有额外三步：逐条证明技能与工具的不匹配（要么真跑一遍，要么指向源码行）；读会话日志找出 agent 最常调用的命令，只把那些展开写全；统计 agent 到底多常打开这个技能， seldom 打开的规则就搬进工具的报错与提示里。README 承认了一件反直觉的事——"请 agent 更新技能"通常会让技能更长，因为 agent 倾向于多加而不是少删。

值得关注的原因

• ⭐ 这直接命中我最痛的一件事：我用 WorkBuddy 的 expert-manager skill 批量生产专家包，而每个专家包都是一份"每次都要全文读进上下文"的 SKILL.md。 截至本期，我已经有 19 期日报、几十个专家包、多个公众号内容模板，但我从来没有量过任何一个技能"每次调用到底烧掉多少 token"。skill-diet 给出的做法是先量、再归位、再用旧版/新版/无版三路对照——这条流程可以原样搬进我的专家包质检流程，作为第一条固定工序：专家包发布前必须报告"瘦身前 token 数 / 瘦身后 token 数 / 测试结果变化"三个数字。
• ⭐ "skill-model-gap"那条实测数字（改一行 description 让 Kimi 从 78% → 98%、Haiku 从 85% → 100%）正好打在我的一人公司利基 C「考证钩子 + 营养 AI 内核轻量助手」的命门上。 我的目标用户群不可能都用最强模型，而我的技能包目前只在最强模型上开发过一次，从没验证过它在弱模型上还灵不灵。更关键的是它揭示了一个我完全没意识到的杠杆：description 的一行文字可能比正文改动更值钱——而我目前的专家包维护习惯是"改正文、忽略 description"。这条应该写进专家包迭代规范：每次迭代先试 description，再动正文。
• ⭐ "只有弱模型有帮助、且不伤害其他模型的修法才保留"这个判据，是我见过最干净的"不引入回归"判定。 我做 GRPM 报告与公众号内容时，修改一个提示词的效果几乎从不跨模型验证——而 WorkBuddy 本机同时接了多个国外模型（OpenRouter 单 key 全家桶），意味着我完全具备做这个对照的现成条件，只是从来没做过。
• ⭐ "运行被禁命令判该次失败 + 有缺失运行的对比判失败"这两条，等于把"评测本身在说谎"这条退路封死了。 我上一期记过的 hermes-fledge 那套"从可观测事实打分"的思路，这里给出了评测侧的对应面：不只是"怎么打分"，还有"什么情况下这个分数不许被采信"。这两半合起来才是完整的可信评测。
• ⭐ "读会话日志找出 agent 最常调用的命令，只把那些展开写全"是一条几乎零成本、立刻见效的优化。 我的专家包与公众号内容模板里，大量篇幅写的是"这个字段有哪几种取值"——但agent 实际每次只用得上一种。
• MIT 授权，可读可改可商用，且它本身就是一份"如何写技能"的现成范本——我可以把它当成技能写作的 lint 工具来用。
• 它也顺带给了一条警告：README 明说"请 agent 更新技能通常会让技能变长"。这意味着我如果直接把专家包的迭代交给 agent 自动做，专家包的 token 成本会单调上升——而这正是我之前完全没有意识到的隐性开销。

2. qf-studio/navigator：把"上下文管理"从提示词搬进运行时——它会拦住没写完任务的退出信号、拦截手写的任务文件，并给每次拒绝留一行日志

地址：https://github.com/qf-studio/navigator ｜ ★355 ｜ MIT ｜ Python ｜ Claude Code 插件，用上下文工程让长会话不崩、并把流程约束从配置文件搬进运行时

事件内容

窗口内 15 次提交（11-06 11:31Z ~ 11-06 16:47Z），主线是把"工作流纪律"从散文变成可执行的钩子（hook）。

• ⭐ 本期最核心的一条：feat(hooks): stop_completion refuses the exit signal while marker_created is unmet after a task doc —— 只要任务文档要求的完成标记还没被创建，它就拒绝发出退出信号。 这是"把承诺写进代码"的又一次出现，但形式更新：不是拒绝输出内容，而是拒绝让 agent 结束这一轮。配合 docs: require_marker_after_task_doc in the configuration reference，这个规则被写进了配置参考文档。
• ⭐ 第二条同族硬闸门：feat(hooks): task_doc_guard — a PreToolUse gate blocks a hand-written .agent/tasks/TASK-*.md unless … —— 手写的任务文件会被前置工具钩子直接挡住（除非满足某个条件，提交标题被截断）。这意味着"绕过流程直接手写结论"在工具层就被拒绝，而不是靠 agent 自觉。
• ⭐ 第三条：每次拒绝都会留下一行日志。 README 写得很清楚：从 v8 起，这套工作流是由跑在 Claude Code 内部的运行时强制执行的，而不是配置文件里的一段散文；它给任务型提示词设闸、拦住扇出式读取、记录每一轮完成了什么，并且每次说"不"的时候都写一行拒绝日志。拒绝日志这一项是我最看重的——它把"闸门拒绝了什么"变成可审计的事实，而不是一个消失在控制台里的提示。
• ⭐ 本期窗口内的其余提交，全在加固这条链的可靠性：build(test): scrub session variables before every suite — make test is hermetic in-session and in the …（每套测试前清空会话变量，保证测试在会话内与线程外都是封闭的）；build(test): run the suites in parallel (TEST_JOBS, default 4)；build(test): make test writes everything to stderr（测试输出全部走 stderr，因为 Pilot 的闸门尾部只捕获 stderr）；build(test): make test ends with a FAILED SUITES block naming each red suite and its FAIL/ERROR line（测试失败时最后必须有一个 FAILED SUITES 区块，逐个点名失败的套件与失败行）；test(hooks): p95 timing budget scales with measured host slowdown（p95 时间预算按实测的主机降速缩放——因为负载下的 Pilot 盒子曾失败）；fix(nav-task): local task IDs come from origin/main and the archive, not only the working tree；ci(tests): pin the Python 3.9 leg to ubuntu-24.04（setup-python 在 Ubuntu 26.04 上没有 3.9 构建）。
• ⭐ 核心指标是可量化的：README 给的对照表是——加载 token 从 150,000 降到 12,000（省 92%）、会话长度从 5–7 轮提到 20+ 轮、结束时的上下文占用从 95%（崩溃）降到 35%（宽裕）。这组数字把"上下文工程"从玄学变成了可对比的工程指标。
• ⭐ 它有一个面向"协作质量"的机制 nav-diagnose：同一个纠正出现两次就触发质量检查（"You're not getting this" → 重新锚定提示）；nav-profile 跨会话记住偏好，并从纠正中自动学习；知识图谱 v6.0 把任务、SOP、系统文档统一检索，会话启动时自动浮出相关上下文。
• ⭐ Loop Mode v5.1 的退出条件是双重的："跑到达标"由启发式与显式信号共同判定（dual-condition exit），并有停滞检测防止无限循环。 README 承认了一个诚实的边界——"你说得出'这看起来不错'，但 agent 的答案其实错了、而你没有反应，这样的运行看起来就是干净的。"

值得关注的原因

• ⭐ "拒绝退出信号"这个机制，正好治我公众号内容生产里最常见的一种静默失败：我给 WorkBuddy 派一个"写一篇循证文章"的任务，它交回来一篇看起来合格的稿子，但没引参考文献、或 24 个风险维度只写了 18 个。 现在的做法是我事后人工核对。navigator 的做法是在 agent 想结束的那一瞬间拦住它，要求先创建完成标记。对应到我的场景：干预报告生成完必须先落一个"证据编号齐全"的标记才允许返回成功态——这条可以做成 4P 平台的一条硬规则，比事后核对便宜得多。
• ⭐ "task_doc_guard 拦截手写任务文件"是我最想抄的一条，因为它堵的是"绕过流程直接写结论"。 我的公众号流程里，AI 有时会直接给我一段看起来成稿的文字，我检查时才发现参考文献是编的。如果生成层有一道 PreToolUse 闸门，规定"未经证据编号校验的成稿不允许落盘"，AI 就无法通过"绕过流程"这条路交差。
• ⭐ "每次拒绝写一行日志"是我这期看到的最便宜、也最该立刻做的一件事。 我现在的所有 AI 流程都没有拒绝日志——AI 拒绝做某件事时，我永远不知道它拒绝过多少次、在哪个条件下拒绝。 有了拒绝日志，"这周 AI 拒绝了几次、都在什么条件下拒绝"就变成了一张可以看的表，这恰好是我上一期记的 Calibrate"按价值分级统计提醒"的同族思路：把提醒做成有分级的清单，而不是同权重的噪音。
• ⭐ "测试失败时最后必须有一个 FAILED SUITES 区块，逐个点名失败的套件与失败行"——这条应该成为我专家包 CI 的固定收尾格式。 现在的失败输出常常是一堆红字里混着一行真正的错误，最后一段点名式的失败清单能把"哪个测试红了、红在哪一行"从需要考古变成一眼可见。
• ⭐ "p95 时间预算按实测的主机降速缩放"是一个我完全没想到但立刻懂了的设计：同一个闸门在空闲机器和满载机器上的耗时不同，用固定阈值会导致负载下误杀。对应到我的场景：化验 OCR 管线如果加一个"证据齐全才放行"的闸门，它的超时阈值不能写死——Gordon 的 Mac 在跑批量导入时和在空闲时性能差好几倍。
• ⭐ 它的"诚实自述"那一段值得抄进我的自检清单："答案错了而你没有反应，这样的运行看起来就是干净的" —— 这句话精确地指出了"干净运行率"作为质量指标的根本缺陷。我的平台如果统计"任务完成率"，同样会系统性高估可靠性。
• MIT 授权，可商用。 且它的"上下文预算"思路与我上一期记的 oh-my-pi "按 wire 上真实字符串量字节"是同一个成本意识——上下文就是钱，而且必须能量。

3. Mason-Levyy/myfitnesspal-mcp：让 AI 直接写进你的饮食日记——但写入后必须"读回日记"验证，这是我见过最朴素也最可靠的一条防幻觉做法

地址：https://github.com/Mason-Levyy/myfitnesspal-mcp ｜ ★30 ｜ MIT ｜ Python ｜ MyFitnessPal 的 MCP server，把"用嘴记饮食"变成可搜索、可追踪、可导出的真实日记

事件内容

窗口内 3 次提交（11-06 05:21Z ~ 11-06 05:32Z），主线是给"写入型"工具补上读回校验与完整的单日生命周期。

• ⭐ 本期最核心的一条提交标题就是答案：Verify food adds by reading the diary back（#54） —— 加完食物之后，把日记读回来核对。 这是一条只有 11 个词、却把整个"AI 写数据"的可信度问题解决的提交。README 也把它的整体立场讲得很清楚："Writes, not just reads: log, modify, and delete real diary entries"。
• ⭐ 紧接着两条补齐了单日维度的语义：Add day goals and remaining macros to day records（#55，单日记录带上目标与剩余宏量营养素）、Add fitness_complete_day to report, complete, or reopen a diary day（#56，一天可以被标记为完成、也可以被重新打开——这意味着"一天的状态"是可变的，不是一次写死的）。
• ⭐ 它解决的认证难题很有工程含量：MyFitnessPal 躲在 Cloudflare + NextAuth 后面，打碎了绝大多数现有集成依赖的账号密码登录。它的做法是用真实 Chrome TLS 指纹携带浏览器会话 cookie（curl_cffi）通过 Cloudflare，并可选开启无头浏览器 profile 自动轮换过期 token，调用失败自动重试。
• ⭐ 它明确写了使用边界："Unofficial. MyFitnessPal has no public API; this reverse-engineers the web app's own endpoints. It can break whenever MFP changes their site. Use at your own risk, with your own account." —— 反向工程的事实、可能随时失效的风险、以及"用你自己的账号"的责任划分，三句话写清楚。
• ⭐ 交互设计是"先搜再记"（search-then-log）：先拿到带宏量营养素的候选食物，再记录其中确切的那一项——不是让 AI 凭记忆写一个食物名和它的热量。README 的 demo 演示的是一次早餐奶昔被拆成逐个配料分别记录。
• ⭐ 工具面覆盖的是真实日记的完整生命周期：记一餐、搜食物库并带宏量营养素、追踪趋势、导出营养历史、改与删，以及上面新加的单日目标 / 完成 / 重开。

值得关注的原因

• ⭐ "写入后读回校验"是我这期看到的最便宜、最直接可搬的一条防幻觉做法，而且它和我上一期记的 OpenAdapt "读回校验四关"完全同族。 我的 4P 平台、GRPM 报告、公众号内容三处都在做"AI 写结构化数据然后落库"，但我从来没做过"写完读回来核对"这一步。myfitnesspal-mcp 只用一次日记读取就把这件事做了——一条工具调用、成本几乎为零，却能把"AI 编了一个不存在的食物名"这类错误变成可检测的。这条应该成为我平台落库管线的统一动作：写入 → 按主键读回 → 比对 → 不一致就标红。
• ⭐ "先搜再记"这条正好治我平台的一个真实痛点。 我的补剂配方引擎在生成食谱与营养素估算时，现在是 AI 直接生成"食物 + 含量"的组合——而 AI 编出来的营养数值在公开数据库里常常根本不存在。myfitnesspal-mcp 的形态是必须先从真实食物库里搜出候选、并带上该食物的宏量营养素，再决定记哪一项。对应到我的场景：营养素估算应该先查 USDA / 中国食物成分表，AI 只负责"选哪几项并解释为什么"，而不是"编一个含量"。
• ⭐ "一天可以被标记为完成，也可以被重新打开"这条状态机语义，对我的补剂方案设计有直接价值。 我现在的 GLP-1 营养伴侣是"早/晚双杯方案 + 化验趋势触发重新优化"，但"某一天方案执行完成"这个状态目前是缺的——我无法区分"这天的方案还没开始"和"这天的方案已完成且有效"。给"每日方案执行"加上可完成/可重开的状态，与给"化验指标"加改善/不变/恶化三态，是同一种建模，而前者我还没做。
• ⭐ 它对"非官方接口"的风险自述方式值得照抄。 README 开门见山写明是逆向工程、可能随时失效、用自己的账号。我给 4P 平台设计任何第三方数据接入（微信、公众号、食物数据库、可穿戴设备）时，都应该有这样一句明确的"它随时会坏"声明，并据此保证坏掉时业务仍可降级运行。
• MIT 授权，可商用，且它已经把"认证 + 自动续期 + 失败重试 + 搜索 + 写入 + 读回校验"整套做完了——如果我要做食物/营养数据接入，这是一个现成的参考实现，而不是从零设计。

4. wilbert-MD-PhD/medical-illustration：给 AI Agent 做的医学绘图技能——每一幅用于讲解的解剖结构，都必须有一份匹配部位、视角和层次的可信依据，而且证据要逐幅登记

地址：https://github.com/wilbert-MD-PhD/medical-illustration ｜ ★174 ｜ MIT（核心 Skill 与脚本）/ CC BY 4.0（原创文档与漫画） ｜ Python ｜ 面向 Codex / Claude Code 等 AI Agent 的医学绘图 Skill，做科普漫画、教学插画与科研示意图

事件内容

窗口内 1 次提交（11-06 14:19Z），并发布 v1.3.7（11-06 14:21Z），主线是修好机制图里"关系类型"的校验。

• ⭐ 本期发布说明写得很克制："修复机制图关系校验：当 relation 误填为数组或对象时，检查器会报告字段错误，并继续检查其余关系"，并新增了"无效类型"与"有效数据"两组回归测试。英文版同义。关键在"继续检查其余关系"这半句——一条坏边不能让它放弃整张图的检查。
• ⭐ 它的核心承诺是强制性的，不是建议性的：README 写明"本 Skill 要求：作品中每项用于医学讲解的解剖结构，都有与部位、视角和层次相匹配的可信依据"；制作时先核验图谱、教材、原始研究或可追溯模型，实际查看参考，再记录它支持的具体结构、是否作为生成时的参考附件、以及成图对照结果。
• ⭐ 证据是逐幅登记的，不是笼统引用。 README 展示了一本《腕骨与关节组成》示例：其中 5 幅解剖底图，共使用 6 次，然后按成图逐幅展开——第 1 页 B01 用 Gray219 + 《Wrist and Hand》Fig.4.18 书页 52，核对内容写的是"指骨、掌骨、腕骨的分区与邻接；BodyParts3D M01 提供右手几何"，并注明"教材只补充腕部关系"；第 4–5 页 B05 用 Gray336 + Fig.4.19a 书页 53，注明"M06 为解释性冠状线稿，B02 仅作配色参考"。
• ⭐ 它对"参考的适用范围"有明确的收窄纪律："教材 Fig.4.18 的采用范围限于腕部，不用一幅腕部图证明全手所有细节"（对第 1 页而言）；对 B04 则写"两张教材图属于同一来源"。
• ⭐ 交付物是可编辑的，且区分文字与图：文字、气泡、医学标签及后加箭头可以独立编辑，改词、移动标注、局部返修都方便；交付内容包括 Markdown 脚本、彩色画面、排版源文件与 PDF。
• ⭐ 许可分层是本仓库最值得学的一点（API 报 NOASSERTION，实文为准）：自有核心 Skill（SKILL.md、references/、agents/、scripts/、CI 与安装配置）= MIT；自有原创仓库文档、教程、漫画、人物、展示图与排版贡献 = CC BY 4.0；第三方图像、字体、模型、软件及其衍生部分 = 保留原许可，另有一份第三方清单与待处理项审计。README 明写"MIT 和 CC BY 4.0 均允许商业使用"，并给出署名示例格式；也提醒"使用 Skill 创作的新作品不自动继承上述许可"。
• ⭐ 它的选题能力也写进了能力表：科普漫画从生活情境出发、教学插画依据真实参考表现解剖层次与损伤位置与修复过程、科研示意图则"区分已证实关系与假说"。

值得关注的原因

• ⭐ "逐幅登记证据 + 明确写出参考的适用范围"这整套，正是我公众号（4P精准营养观察 / 健康100新一观察）循证内容最缺的东西。 我现在的做法是文章末尾列参考文献，但没有"这幅图/这句话支持的是哪个具体结论、依据的是哪本书哪一页、这份依据只覆盖哪一部分"的登记结构。medical-illustration 的"按成图逐幅展开"格式可以直接搬成我公众号的"证据登记表"——每张图、每条机制描述，对应一行：结论 / 依据来源 / 页码图号 / 支持范围 / 是否为假说。
• ⭐ "不用一幅腕部图证明全手所有细节"这一条，是我做精准营养科普时最容易犯的错。 一篇讲"某营养素通路"的文章常常用一张通用示意图去支撑三四个不同层级的结论——而这张图只覆盖其中一个。把"参考的适用范围"显式写出来，能直接掐掉公众号最常见的那类过度引申。
• ⭐ "区分已证实关系与假说"被写进能力表而不是可选备注，正好对上我上一期记的 grotyx 那个 "explicit association caps a sentence at associative"（证据只支持关联时措辞不许升级成因果）。 这是同一个原则在中文科普场景的落地版：同一个技能，两种语言，同一条纪律。
• ⭐ "改一处关系校验后仍要继续检查其余关系"——这条对应我的 GRPM：40 个 SNP 的判定规则里，一条规则解析失败不能让整份报告停在那里，也不能让剩下 39 条跟着被判"未评估"。
• ⭐ 许可分层这件事对一人公司极其重要，而且方向是好的："代码 MIT + 原创内容 CC BY 4.0 + 第三方素材各自保留"是"我要把内容做成商业产品"时最干净的授权结构——代码可以随便商用，原创内容商用只需署名并标改动，第三方素材我只需照它的条款用。这比"整个仓库一个许可证"精确得多，也比我上一期遇到的 AGPL/PolyForm 那种"整仓一刀切"友好太多。
• 它也提醒了我一个我一直没意识到的点："使用 Skill 创作的新作品不自动继承上述许可" —— 也就是说，我用它产出的漫画，版权归属与素材来源需要我自己再确认一遍，不能默认"素材来自 CC BY 4.0 的仓库所以我的产出也是 CC BY 4.0"。

5. archestra-ai/archestra：把"agent 用什么模型、花多少钱、拿谁的权限"收进一个平台——并且把安全默认做成了架构而不是开关

地址：https://github.com/archestra-ai/archestra ｜ ★4,433 ｜ AGPL-3.0-only（默认）/ LicenseRef-Archestra-Enterprise（标记为 Enterprise 的区域） ｜ TypeScript ｜ 企业级 AI 平台：LLM 网关 + MCP 网关 + A2A 网关 + 私有 MCP 注册表 + agent 运行时 + 护栏

事件内容

窗口内 40 次提交（11-06 17:28Z ~ 11-07 02:46Z），并发布 platform-v1.4.22 与 platform-v1.5.0-rc.24（均为 11-06），主线是把 agent 的运行边界（隔离级别、凭据归属、成本上限）下沉到基础设施层。

• ⭐ 本期最硬的一条是运行时隔离本身产品化：feat(agent-runtime): run unprivileged Agent Runtime pods under a configurable RuntimeClass (gVisor o…) —— 让 agent 运行时的 pod 以非特权方式运行在可配置的 RuntimeClass（gVisor 等）下。 也就是说"agent 的沙箱隔离级别"从运维参数变成了产品配置项。
• ⭐ 护栏不是可选项，是 README 第一屏就写着的前提："Built on a strong security and observability foundation: SSO and RBAC, sandboxed code execution, Lethal-Trifecta guardrails, OpenTelemetry traces, and Prometheus metrics — first-class, not bolted on." —— "不是后贴的"这句评价方式本身就是一条产品标准。
• ⭐ 网关层的形态是"一个 URL 解决四件事"：LLM 网关（任意供应商 + 成本上限 + 虚拟 API key + 动态模型路由）、MCP 网关（OAuth + On-Behalf-Of，让工具以用户的身份运行，而不是用一个共享的服务账号）、A2A 网关（agent 间触发）、私有 MCP 注册表（团队自研工具上架）与 MCP orchestrator（K8s operator + 自助式晋升到不同环境）。
• ⭐ MCP 的按用户身份执行是本期最值得注意的一条设计：On-Behalf-Of 意味着审计日志里能分清"是人点的"还是"agent 点的"——这直接解决了"共享服务账号导致权限归属不清"这个我上一期记过的网关治理层问题。
• ⭐ 本期其余提交几乎全是"把凭据从代码里挪出去"：ci(deploy): read staging and demo credentials from synced Kubernetes Secrets；ci: read benchmark and alerting secrets from GCP Secret Manager；ci: scope publish credentials to GitHub Environments；ci: request least-privilege permissions for releaser App tokens；ci: run Release Please through the shared App-authenticated workflow；fix(ci): pass environment secrets to reusable workflows by name；fix(helm): connect to Cloud SQL through the Auth Proxy with IAM login；fix(helm): optional hook ServiceAccount for the migration Job；fix(ci): move remaining CI images and dev caches to GHCR。这是"agent 供应链治理"的一个真实样本——每一条都是"某个凭据原本能被谁看到"的问题。
• ⭐ 许可路由规则本身值得读一遍：默认 AGPL-3.0-only；标 Enterprise 的文件走 LicenseRef-Archestra-Enterprise；判定顺序是"文件顶部 SPDX 头 > 文件内 REUSE snippet 区域 > 路径约定（*.ee.* 或 ee/ 目录）> vendored Dagger SDK 保留上游 MIT > 默认 AGPL"。这比"一个 LICENSE 文件"精细得多。

值得关注的原因

• ⭐ "MCP 工具以用户身份运行（On-Behalf-Of），而不是共享服务账号"这一条，解决的是我 4P 平台最实际的一个架构问题。 我现在所有 MCP 工具调用都走一个连接器身份，审计日志里分不出"是用户点的补剂查询"还是"是 agent 自行发起的抓取"。改成按用户身份执行之后，我才能回答"这条干预建议到底是谁提出的"——这直接关系到 4P 平台的合规叙事。
• ⭐ "成本上限 + 虚拟 API key"是我做一人公司时最需要的两个网关功能，而市面上的网关基本只做"能不能接"。 我上一期就记过这个判断："基础设施线的竞争点已从'能不能接'转向'接上之后会不会吃掉别的东西'（预算、格式、凭据归属）"——这一期它把三件事（预算、凭据归属、隔离级别）同时产品化了，是这条线索上的一个明确节点。
• ⭐ "沙箱隔离级别做成可配置 RuntimeClass"这个形态，对我理解 agent 安全边界很有帮助。 我现在跑批量 AI 任务（OCR、报告生成）时，隔离基本靠"我不开网"这种自觉约定。把隔离级别变成配置项并可收紧，是"合规边界写进代码"的另一种形态。
• ⭐ 那一串"把凭据从代码挪出去"的提交，对我自己的仓库是一份现成的自查清单。 我的 4P 平台、GRPM、公众号内容管线都涉及 API key 与模型凭据，逐条对照这十条提交（部署凭据、基准与告警凭据、发布凭据范围化、最小权限 App token、共享工作流鉴权、镜像与缓存迁到私有 registry、IAM 登录数据库）能立刻发现我自己的漏洞面。
• ⭐ "first-class, not bolted on"这个评价标准我可以直接拿来要求我自己的平台组件。 我现在的很多"合规"表述其实都写在文档里而不是架构里——如果一个安全声明是"贴在旁边的"，那它在压力下第一个掉。
• ⚠️ 但授权要看清：默认 AGPL-3.0-only，且 Enterprise 区域是独立商业许可。 对一人公司来说，AGPL 只能读不能抄；若要把它当底座部署对外服务，需要另谈商业授权。能抄的是它的设计思路，不是它的代码。

二、分类速览

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

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

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

④ 模型底座与 Agent 基础设施

三、今日趋势观察

本期最明显的一条主线是：约束正在从"提示词里的要求"变成"运行时里不可绕过的闸门"，而且闸门开始自带证据。 skill-diet 用"旧版/新版/无版三路对照 + 盲评 + 评分器自己也会失败"来保证瘦身不引入回归；navigator 让 stop_completion 在完成标记缺失时直接拒绝 agent 结束这一轮，并把每次拒绝写进日志；archestra 让 agent 运行时 pod 以非特权方式跑在可配置的 gVisor RuntimeClass 下，并把"工具以谁的身份运行"写进鉴权协议；myfitnesspal-mcp 的做法最朴素——写入后把日记读回来核对。这四条线互不相干，却都在回答同一个问题：不是"AI 该怎么做"，而是"AI 做不到的时候，系统会怎么拦它、拦下来之后有没有留下证据"。 这与我前几期记下的 aureproof 三态闸门、Calibrate 的 2×2 依赖度矩阵、AdelIA 的答案契约、Gaskin 的锁定项是同一条线索的第四阶段：上一阶段把约束下沉到代码，这一阶段把约束下沉到运行时，并让运行时留下可审计的痕迹。

第二条线是"成本的度量单位正在从 token 变成 token × 模型 × 场景"。 skill-diet 报出"砍掉 70–80% token 且测试结果没降"这组数字时，还报了一个更反直觉的：改一行 description 就让 Kimi 从 78% 提到 98%、Haiku 从 85% 提到 100%——同一个"瘦身"动作，在不同模型上的收益完全不同。navigator 报的是"加载 token 从 150,000 降到 12,000、结束上下文从 95% 降到 35%"，也是以可对比的量化指标说话，而不是"体验更好"。这两条合起来意味着：现在评估一个 AI 产物或技能的性价比，不能只看"它多聪明"，必须看"它在哪个模型上、烧多少 token、通过了多少任务"三元组。 我做专家包与一人公司产品时，这正是我一直缺的度量口径。

第三条线：健康与医学线的"本地优先 + 证据可追溯"正在成为默认假设，而不是个人偏好。 syntropy-health 跑在你自己的电脑上，它对健康数据的每一次操作都是只读且有日志的；medical-illustration 强制"每项用于医学讲解的解剖结构都要有匹配部位、视角与层次的可信依据"，并逐幅登记"这份依据只支持哪一部分"；myfitnesspal-mcp 反向工程 MyFitnessPal 的私有接口，但把"这是逆向工程、随时会坏、用你自己的账号"三句话写在最前面。三者共同点是：把"数据在我手上"与"结论有依据"这两件事同时做成可检查的事实。 这与前几期记下的 cairn（HTTP 只绑 127.0.0.1）、DataNyx（无值 schema + schema-diff 进 CI）是同一条趋势的延伸——本地优先已经是这类产品的默认架构假设，而"证据可追溯"正在补上第二块。

第四条线：授权形态正在从"一个 LICENSE 文件"升级为"分层 + 路由 + 三层分别声明"。 medical-illustration 把自有核心 Skill 与脚本定为 MIT、自有原创文档与漫画定为 CC BY 4.0、第三方素材保留原许可，并明说"使用 Skill 创作的新作品不自动继承上述许可"；archestra 用"默认 AGPL-3.0-only + 标 Enterprise 的区域走商业许可"的首条匹配即胜路由规则，把 SPDX 头、REUSE snippet、路径约定（*.ee.* / ee/）与 vendored 依赖逐层排好；ClawBio 上一期记的"三段式许可证"（代码 / 模型 / 数据取最严者）是同一族思路。对一人公司的直接含义是：选底座时不能只看仓库首页那个许可证徽章，必须把"我要用的是哪一部分"和"这一部分归谁"两件事问清楚。 本期实测仍有 5 个条目确认无 LICENSE 文件（dromlakhani/MD2SKILL、ImHangLi/maru、anbeime/skill、linhay/harmony-next.skills、anthropics/skills），其中 anthropics/skills 本期有一条 "Move Office skills to the Apache 2.0 license" 的提交——连最上游的官方技能仓库也在把授权切到更宽松的一侧，这本身是个信号。

第五条线，也是给 Gordon 的直接提醒：我这一期看到的三条"读回校验"，分属三条不同的技术栈，但都在解决同一个错误。 myfitnesspal-mcp 用一次日记读取解决"AI 写了不存在的食物"；navigator 用"完成标记 + 拒绝日志"解决"agent 交回了一个看起来合格的残次品"；medical-illustration 用"逐幅登记证据"解决"这张图其实不支持这句话"。我现在的三个项目——4P 平台、GRPM 报告、公众号内容——三处都在做"AI 生成结构化结论然后落库/发布"，但三处都没有读回校验。 这条几乎是零成本的改进：写入 → 按主键读回 → 比对 → 不一致就标红并阻断下游。相比之下，我更该警惕的是 skill-diet 那句提醒——"请 agent 更新技能通常会让技能变长"，意味着我若把专家包的迭代交给 agent 自动做，成本会单调上升。

四、GitHub 地址速查

https://github.com/nicobailon/skill-diet
https://github.com/qf-studio/navigator
https://github.com/Mason-Levyy/myfitnesspal-mcp
https://github.com/wilbert-MD-PhD/medical-illustration
https://github.com/archestra-ai/archestra
https://github.com/vastsa/PI-Desktop
https://github.com/getpaseo/paseo
https://github.com/langwatch/langwatch
https://github.com/earendil-works/pi
https://github.com/windmill-labs/windmill
https://github.com/repoprompt/repoprompt-ce
https://github.com/genspark-ai/genoffice
https://github.com/generalaction/emdash
https://github.com/open-gsd/gsd-pi
https://github.com/ParadevAI/Paradev
https://github.com/davila7/claude-code-templates
https://github.com/homarr-labs/dashboard-icons
https://github.com/coreyhaines31/marketingskills
https://github.com/wonderwhy-er/DesktopCommanderMCP
https://github.com/anbeime/skill
https://github.com/mjmirza/app-store-compliance
https://github.com/InsForge/InsForge
https://github.com/cobusgreyling/loop-engineering
https://github.com/vercel-labs/deepsec
https://github.com/ValueCell-ai/ClawX
https://github.com/rpamis/comet
https://github.com/kaankiziltug/logo-design-skill
https://github.com/Jakubantalik/transitions.dev
https://github.com/EgoAlpha/prompt-in-context-learning
https://github.com/linhay/harmony-next.skills
https://github.com/DiffoHQ/diffo
https://github.com/pavanbadempet/AI-Healthcare-System
https://github.com/melvinmathew9991/multi-agent-food-concierge-mcp
https://github.com/cfu288/mere-medical
https://github.com/peter-fusek/oncofiles
https://github.com/hapifhir/hapi-fhir
https://github.com/nitrain/nitrain
https://github.com/ohcnetwork/care_fe
https://github.com/earthians/marley
https://github.com/dromlakhani/MD2SKILL
https://github.com/Mayank-cyber-cell/MedGuide-PillTracker
https://github.com/SongyuQi-Francisco/Watch2Whoop
https://github.com/fliptheweb/yazio-mcp
https://github.com/siddsachar/row-bot
https://github.com/GeiserX/OwnGenome
https://github.com/health-assistant-io/health-assistant
https://github.com/sayed0am/unstrap
https://github.com/ArtLogicIKE/frixos
https://github.com/EnriqueNeyra/syntropy-health
https://github.com/ImHangLi/maru
https://github.com/ohuc/CaffeineHealth
https://github.com/pedroberaldo87/daily-screen
https://github.com/CherryHQ/cherry-studio
https://github.com/kestra-io/kestra
https://github.com/topoteretes/cognee
https://github.com/perplexityai/SPACE
https://github.com/smg-project/smg
https://github.com/langfuse/langfuse
https://github.com/pydantic/pydantic-ai
https://github.com/yc-software/qm
https://github.com/zeroclaw-labs/zeroclaw
https://github.com/microsoft/agent-framework
https://github.com/deepset-ai/haystack
https://github.com/pipecat-ai/pipecat
https://github.com/a2ui-project/a2ui
https://github.com/google/adk-go
https://github.com/google/adk-python
https://github.com/strands-agents/harness-sdk
https://github.com/multica-ai/multica
https://github.com/THU-MAIC/OpenMAIC
https://github.com/mastra-ai/mastra
https://github.com/boxlite-ai/boxlite
https://github.com/aklivity/zilla
https://github.com/mozilla-ai/otari
https://github.com/matthiasn/lotti
https://github.com/crewAIInc/crewAI
https://github.com/codescene-oss/codescene-mcp-server
https://github.com/firecrawl/firecrawl
https://github.com/awslabs/mcp
https://github.com/TanStack/ai
https://github.com/dataelement/dsh-desktop
https://github.com/TencentCloud/CubeSandbox
https://github.com/higress-group/higress
https://github.com/vercel/eve
https://github.com/apple/coreai-models
https://github.com/EverMind-AI/EverOS
https://github.com/VoltAgent/voltagent
https://github.com/agentscope-ai/agentscope-java
https://github.com/IBM/mcp-context-forge
https://github.com/hatchet-dev/hatchet
https://github.com/oomol-lab/open-connector
https://github.com/spiceai/spiceai
https://github.com/ysr666/dsh-vision-router
https://github.com/Mintplex-Labs/anything-llm
https://github.com/langchain-ai/deepagents
https://github.com/apache/apisix
https://github.com/casdoor/casdoor
https://github.com/langchain4j/langchain4j
https://github.com/xerrors/Yuxi
https://github.com/truefoundry/trueforge
https://github.com/RLinf/RLinf
https://github.com/0xSteph/patient-zero
https://github.com/googleapis/mcp-toolbox
https://github.com/harbor-framework/harbor
https://github.com/rivet-dev/rivet
https://github.com/mem0ai/mem0
https://github.com/wasmerio/wasmer
https://github.com/TokenRhythm/opensquilla
https://github.com/theagentrouter/agent-router
https://github.com/trpc-group/trpc-agent-go