GitHub AI 日报 · 2026-10-31（周六）

一、今日精选 5 条

1. can1357/oh-my-pi：把 IDE 真正接进编码 agent——37,251 星的 pi 分支在 24 小时内跑了 74 次提交，今天的主题是"让 agent 少猜、多量"

地址：https://github.com/can1357/oh-my-pi ｜ ★37,251 ｜ MIT ｜ TypeScript + Rust（核心约 8 万行 Rust）｜ Stencil Labs 出品的 pi 分支，60+ 模型供应商、31 个内置工具、28 个 DAP 操作、14 个 LSP 操作

事件内容

这是今天提交密度最高的仓库之一：10-30 至 10-31 两天共 74 次提交，10-31 00:39 发布了 v18.14.1。提交看起来琐碎，但串起来指向一个很明确的方向——让 agent 在"读上下文"和"算大小"这两件事上不再凭感觉。

• 一整个上午都在修"标题漂移"（title drift）：feat(coding-agent): judge title drift before refreshing after prompts → fix(coding-agent): keep user-set titles and redact title drift judgments → refactor(coding-agent): opt-in title drift checks that consume their prompts, redact native ...。这一串的逻辑是：agent 每轮跑完想刷新会话标题，但刷新前要先判断标题是不是真的漂了，而且用户手动设过的标题不能被覆盖；判定逻辑本身会消耗 prompt，所以改成"opt-in"，且判定结论要在展示时脱敏。
• 图片预算被精确到字节：feat(catalog): raise Anthropic inline image budget to 120 MB for the 128 MB Messages limit → fix(catalog,coding-agent): keep Anthropic inline images within the 128 MB request body → fix(coding-agent): measure tool arguments as the string the Responses wire sends。先按"协议真正发出去的那个字符串"来量，而不是按内部对象来量——这正是把 Anthropic 120MB 预算填满后又回收 8MB 余量的做法。
• 一天之内发版到 v18.14.1：10-31 00:37 修 Windows 路径处理（walker stat 与 rsync filter 的合并文件），00:39 直接 chore: bump version to 18.14.1。
• 其他值得记的两条：新增 providers.openai-codex.daybreak 设置项，允许按会话退出 Daybreak Blue；以及 fix(agent): removed intent length rejection（取消了意图长度拒绝）。
• 仓库当前临时向所有人开放 PR（README 明写此前要求 vouch 背书，现暂时取消以评估开放贡献的效果）。

值得关注的原因

• "刷新标题前先判断是否漂移、且不覆盖用户设过的标题"这条，对我这个站的实际意义超过它的星数。 我做 4pwellness 的 AI 助手、给营养平台做报告生成时，遇到的正是同一个问题：agent 会自动把会话标题改成一个"看起来更贴题"的名字，而用户自己写的那个名字才是有业务含义的（比如"冀敏 2024 基线方案 第一阶段"）。oh-my-pi 的做法是把这件事拆成三步——先判断、再决定刷新、最后脱敏展示——判断本身要消耗 prompt，所以默认关掉、让用户主动开。这个"opt-in + 不覆盖用户设置 + 结论脱敏"的三件套，是我做 4P 补剂平台的 AI 助手时可以直接抄的交互契约。
• "按协议真正发出去的那个字符串来量大小，而不是按内部对象来量"，是一个我以前会踩的坑。 我做化验报告 OCR → AI → App 导入时，一开始是按"文件多大"来算能不能塞进上下文，后来才发现真正决定成败的是最终拼进请求体的那个字符串长度（base64 会膨胀、转义会变长）。他们把量测口径从"对象"改成"wire 上发出去的东西"，并据此把 128MB 限制下的可用预算定到 120MB——这就是"留 8MB 余量"这个数字的来源，而不是拍脑袋。对我做多模态（报告图片 + 化验单）批量导入时怎么定安全阈值，这是一条能直接用的工程结论。
• 37,251 星 + 74 次提交 + 一天一发版，这个节奏说明一件事：编码 agent 底座已经从"能不能用"进入"细节打磨"阶段。 上一期我记录 LangChain core 1.7.3 与 AutoGen 停止维护时，写的判断是"选哪个 agent 框架底座的答案在收窄"。今天这条让我要把判断再往前推一步：底座的竞争点已经从"抽象好不好"转到了"这些边缘情形有没有被处理干净"——标题漂移、图片预算、字节级量测、Windows 路径——全都不是模型能力问题，而是工程细节。对我这个每周只有 8 小时的一人公司，这是个好消息：差异化不在于训练模型，而在于把边界情形收干净。
• MIT 许可，可读可改可商用，对"要做成产品的一人公司"没有 copyleft 负担。

2. ayuayue/PiDeck：中文社区里把 pi 与 DSH 两个后端塞进同一个桌面工作台——而 DSH 正是我本机在跑的那套 harness

地址：https://github.com/ayuayue/PiDeck ｜ ★1,170 ｜ MIT ｜ Electron + TypeScript ｜ 把 pi 与 DSH（DeepSeek Harness）会话统一管理在本地项目目录下的开源桌面工作台

事件内容

10-30 至 10-31 两天 45 次提交，10-30 06:36 有明确的 chore: release v0.9.9 提交，README 更新日志同日切到 v0.9.9（GitHub Release 页面最新仍显示 10-27 发布的 v0.9.8，v0.9.9 的 tag 尚未推送——这一区别如实记下）。今天的提交密度主要来自两条主线：ACP（Agent Client Protocol）会话能力的补齐，以及多端与商业化的收口。

• ACP 侧一整天在做"把别的 agent 接进来"：feat(acp): 新增 Copilot CLI 预设（copilot --acp）、feat(acp): 新增 MiMo Code 预设（mimo acp）、feat(acp): 新增 Kilo Code 与 Cline 预设、feat(acp): 模型列表显示 magpie 倍率与模型描述、feat(acp): 会话补齐待办与子代理展示（工具调用推导）、feat(acp): 历史会话恢复后补回 bypass 权限档、feat(acp): 参数过多时折叠底栏，引导页选 ACP 自动建会话并预热。
• DSH 侧有两条正中我兴趣的提交：feat(thinking): 移植 DSH rc.5 的思考签名展示净化——把思考签名（thinking signature）在展示前做净化，这是模型多轮对话里防止"思维链串味"的关键一步；以及 fix(dsh): npm pack 前先建目标目录，修用户插件安装必然 spawn npm ENOENT——修掉了插件安装必然失败这个必现 bug。
• 一条很见功力的中文输入法修复：fix(composer): 中文输入法提交的文字不再丢出草稿（发送键常灰 / 预测灰字压字）。中文 IME 的组合态（拼音预编辑窗口）会吃掉一次按键，如果不做特殊处理，用户打完的中文会"丢出草稿"——这是所有做中文输入框的桌面应用都会踩的坑。
• 商业化统一与安全：有 refactor(ui): 商业化统一 Wave 2——共享模式冻结、fix(ui): 商业化统一 Wave 1 全量——P0 安全修缺、fix(config): 保存 models.json 前清洗 pi schema 非法值，修 #458 供应商整列消失。
• EasyTier 被升级为可托管渠道（系统服务启停 + 手机配置下发），外网访问新增只读渠道。

值得关注的原因

• "移植 DSH rc.5 的思考签名展示净化"这一条，是我本机就在跑 dsh v0.1.0-rc.6 却从未想清楚的一个问题。 我一直用 DSH 做原生 agent 开发，思考签名是用来保证多轮对话里模型"记得自己上一轮是怎么想的"的东西——但它直接展示出来就是泄漏和串味的双重风险。他们把它从"移植"到"净化"做成了展示层的一道工序，这个位置选得对：净化发生在渲染之前，而不是在模型调用层。这正好对应我上一期记 hashgraph-online/hol-guard 时写的"防线要尽可能靠前"——只不过这次防的不是泄漏给外部，而是防泄漏给用户自己的眼睛。
• PiDeck 证明了"一个桌面壳同时托管多套 agent 后端"这个形态是有人愿意做、且做得下去的。 它的做法很克制：README 明写"PiDeck 不是 pi 的分支，它是一个轻量 Electron 外壳，通过启动多个 pi --mode rpc 进程……所有 Agent 能力由 pi 原生提供，会话文件也由 pi 原生读写，PiDeck 不复刻、不劫持"。"不复刻、不劫持"这六个字，是我评估任何 agent 生态工具时的第一条标准——因为一旦开始复刻上游能力，上游一升级你就得跟着修。我的 GLP-1 营养伴侣 V2 与 4P 精准营养平台（8899 端口）也是"薄壳 + 独立数据层"的架构，它证明了这条路在中文社区也走得通、且有人愿意投入 45 次提交/天的密度打磨。
• "商业化统一 Wave 1 全量——P0 安全修缺"和"共享模式冻结"这两个 commit 标题，对我正在做的 GLM 营养伴侣 V2 有直接参照。 一个涉及 153 个食材模板、15 个功能靶点、Excel 导出公式的产品，真正卡住它的往往不是功能，而是"哪些开关可以给用户自己动"这个边界。他们用"Wave 1 全量 + Wave 2 冻结"两阶段推进，把"安全修缺"和"模式冻结"分成两批做，这个节奏值得我抄——安全项先补齐、共享类接口再冻结，不要混在一次改动里。
• 那三条 ACP 预设（Copilot CLI / MiMo Code / Kilo Code + Cline）说明一件事：现在接入一个新 agent 的成本已经降到"加一个预设"了。 这对我的"考证钩子 + 营养 AI 内核轻量助手"是好消息——意味着我的产品未来可能不需要自己实现 agent 运行时，只要做那层"营养领域的确定性资产"（食材模板、靶点映射、禁忌规则）就够了。MIT 许可，Electron 技术栈，与我现有工具链无冲突。

3. OpenAdaptAI/OpenAdapt：把"agent 说自己成功了"变成可以证伪的命题——在开源 EHR 上，30 次故意写坏的记录被读回校验抓住

地址：https://github.com/OpenAdaptAI/OpenAdapt ｜ ★1,854 ｜ MIT ｜ Python 3.10–3.12 ｜ 面向 computer-use agent 的开源"可验证执行层"：把一次人工操作编译成程序，之后 agent 把程序当工具调用

事件内容

这个项目解决的问题非常具体，而它给出的数字非常硬。10-30 至 10-31 两天 13 次提交，几乎全部集中在把"读回校验"（read-back）做扎实上。

• 核心机制：人（或 agent）先在 Web / Windows / macOS / Linux / 远程桌面应用里把一件事做一遍，OpenAdapt 把它编译成一个程序；之后 agent 只调用这个程序。程序运行时的关键性质是：不发模型调用、不把任何截图发到任何地方；每次保存前确认要写的是哪条记录，保存后从系统记录源把数据读回来，只返回朴素的结果；任何不匹配就停下来告诉 agent，而不是猜。
• 在 OpenEMR（7.0 已获 ONC 认证的开源 EHR）上的对照测量：从全新浏览器登录、填表、到保存后读回，中位数——纯 agent（Claude Sonnet 5.5 computer use）36.5 秒、63 例中正确 62 例、模型成本约 $0.08；OpenAdapt 程序走屏幕步骤 22.5 秒、18/18 正确、模型成本 $0；OpenAdapt 程序走 API 步骤 3.3 秒、18/18 正确、模型成本 $0。API 步骤把程序的 41 个屏幕步骤替换为应用自己发出的那一次表单提交，然后读回记录。
• 最关键的一个数字：在故意注入数据库故障的 OpenEMR 副本上（字段被清空、值被改、重复病历、病历被删、另一份病历被删改），agent 对全部 30 次坏保存都宣称成功；读回校验抓住了 30 次中的 25 次，并确认了全部 5 次干净保存，无误报。在 MockMed（一个在服务器应答前就显示"保存完成"的测试应用）上，agent 同样宣称 30 次全部成功，读回校验全部 30 次抓住。
• 另一个开源系统上的验证：在 openIMIS（尼泊尔国家医保体系使用的开源保险与理赔系统）测试副本上，编译出的程序录入 149 条合成理赔、零模型调用，读回 148 条正确，没有一条被错误保存。
• 今天的提交几乎全在校验器上：fix(verifier): compare a stored number with an expected number by exact value（数字必须按精确值比较）、Verifier: a None parameter matches a stored null instead of making the read-back unre...（None 应匹配存储的空值，而不是让读回失败）、Verifier: SQL guard refuses placeholders in literals, locking reads and more s...（SQL 守卫拒绝字面量里的占位符、拒绝加锁读等）、Verifier: tokenize the read-only SQL guard instead of matching substrings（把只读 SQL 守卫改成词法切分，而不是字符串子串匹配）、以及 Whole-database frame and recheck on PostgreSQL（把整个数据库纳入框定并在 PostgreSQL 上复检）。

值得关注的原因

• 这个项目直接命中我一直在解的一个问题，而且解法比我的更狠。 我做化验报告照片 OCR → AI → App 导入时，一直担心的是"AI 生成的补剂方案会不会自己编一个指标值出来"。我的做法是在应用层写校验；他们把这件事上升成了"保存后必须读回"的架构不变量，并且用 30 次故意写坏的记录证明了它的必要性。 那组数字里最该让我警觉的是：agent 对全部 30 次坏保存都宣称成功——也就是说，在一个只看模型输出的界面上，错误率看起来是 0%。这比我担心的"AI 编造指标"严重得多，因为它连报错的机会都没有。
• "Verifier 的 SQL 守卫从子串匹配改成词法切分"这一条，是我做对照实验时最容易写错的地方。 我判断"这条化验单有没有被写进数据库"时，最初也是用字符串匹配 SQL——但子串匹配会被注释、字符串字面量、嵌套子句骗过。改成词法切分（tokenize）之后，守卫才是可靠的。 同理还有三条：数字必须按精确值比较（不能用字符串相等）、None 匹配存储空值（否则读回会假失败）、拒绝字面量里的占位符（防止注入）。这四条加起来是一份可以直接照抄的"读回校验 checklist"，我打算拿它去审 4P 补剂平台的干预报告落库逻辑。
• "编译成程序，运行时零模型调用、零截图外发"这个形态，对我处理真实健康数据意义重大。 我的 4pwellness 平台要处理用户的体检报告与生活方式问卷，这些数据一旦进模型上下文再随请求发出去，就是 PHI 外流。OpenAdapt 的架构给了一个更彻底的答案：把需要接触数据的那部分固化成不调用模型、不外发截图的程序，只让模型决定"调用哪个程序"。 这比在 prompt 里写"请不要外传患者信息"要可靠得多——前者是结构保证，后者是指望模型听话。
• 成本对比 $0.08 vs $0 加上 36.5 秒 vs 3.3 秒，对我"每周 8 小时 + 1 个月现金跑道"的约束是直接的。 一人公司产品的每一次调用都是真实成本，而编译式执行的边际成本趋近于零。MIT 许可、Python 技术栈，与我的 Flask+SQLite 净眼系统（8899）兼容。

4. meltforce/FreeReps：把五路可穿戴数据收进自建服务器，再用 MCP 交给 LLM——今天它修的是两个 Go 漏洞和一次 MCP SDK 升级

地址：https://github.com/meltforce/FreeReps ｜ ★21 ｜ MIT ｜ Go + Vue ｜ 自托管的健康与训练数据服务器：采集 Apple Health / Oura / Withings / Hevy / Alpha Progression，可视化并以 MCP Server 暴露给 LLM

事件内容

星数只有 21，但它做的事在架构上是我一直在找的那块拼图。10-31 01:44 与 10-30 有三次提交，看起来琐碎，但正好点出这个项目当前最要紧的一件事：

• 10-31：fix(deps): update module tailscale.com to v1.104.4。
• 10-30 16:48：deps: golang.org/x/net v0.62.0 for GO-2026-6860 and GO-2026-6866——一次同时修两个 Go 官方漏洞公告（GO-2026-6860 / GO-2026-6866）。
• 10-30 01:44：fix(deps): update module github.com/mark3labs/mcp-go to v1.4.0——升级 MCP Go SDK 到 1.4.0。
• 往前看 10-25 还有 security: Go 1.27.3 (GO-2026-6809) 与 ci: pin the reusable workflow to ci-workflows@v7、ci: rebuild weekly on Go 1.27.2 and block on govulncheck（CI 里卡住 govulncheck，不让有漏洞的依赖进主干）。连续两周都在补安全债，说明这个项目把"处理真实健康数据"这件事当真了。
• 它自己提供的能力更值得记：一是多源采集（Apple Health、Oura、Withings、Hevy、Alpha Progression），数据落本地持久化；二是相关性格探器——任意两个指标做散点图叠加，给出 Pearson r，并从同一份 payload 重算四个滞后期的 r（"correlation explorer"）；三是睡眠分期、HRV、血氧的夜间曲线、心率区间按用户自设或按出生日期估算的最大心率推算、力量训练组次、GPS 路线；四是 MCP Server 接口把这一切交给 LLM；五是 iOS 端已上 App Store（2.2 版），只同步 HealthKit 增量数据，可用小组件或 Siri 触发同步。

值得关注的原因

• "相关性格探器：任意两指标散点 + Pearson r + 四个滞后期重算"，是我做 4P 精准营养干预效果分析时最想要但一直没找到现成实现的东西。 我目前的分析都是"某指标改善/不变/恶化"的三档触发式判断（血糖、HbA1c、血脂、肝功、维 D、铁/铁蛋白、尿酸、体重/腰围），本质上缺了"两个指标之间是否存在时间上的相关性"这一层。比如"维 D 补充后 8 周，铁蛋白变化与 HbA1c 变化是否存在滞后相关"——他们的四个滞后期重算，正是这个问题的工程解。MIT 许可、Go 后端，我可以只借鉴算法不必引入整个栈。
• "只同步增量"这个设计细节，和我上一期记 Q00/ouroboros 时写的"可信资产"是同一个思路。 它在 iOS 端只发 HealthKit 自上次同步以来新增的部分，这既省流量，更让"数据何时进入系统"这件事有明确边界。我做 4pwellness 的微信群客服 Bot、GRPM 营养基因组学的报告导入时，同样的边界问题一定会出现——用户换了手机、数据补传了一半、时区变了，同一个指标出现两次。"增量同步 + 明确 provenance"应该是我所有健康数据入口的统一约定。
• "CI 里卡 govulncheck，不让有漏洞的依赖进主干"——这是我该抄到自己项目里的一条硬规矩。 我在腾讯轻量服务器（101.42.26.85）上跑着 sync-backend，也在本地跑着 Flask 平台，依赖升级一向靠人肉记忆。FreeReps 用一条 CI 规则把这件事自动化了："有 GO-2026-6860 这种级别漏洞的依赖，PR 直接过不去"。对一个要在 1 个月现金跑道内交付的一人公司产品，这条规则比多写两个功能更能保住产品不塌。
• 它还提醒了一件事：一个项目对"数据可信"的重视程度，可以从它怎么对待依赖漏洞看出来。 三次提交里有两次是安全修复，这在我见过的健康类开源项目里不多见——大多数是把数据存在别人服务器上然后收订阅费。21 星、MIT、自托管、暴露 MCP，这套组合对"个人健康数据要自己掌握"这个诉求，给出了一个可以照着搭的最小架构。

5. deeplethe/sandstorm：把"一个 agent 一个沙箱"变成"一台机器几千个沙箱"——34 次提交把 Firecracker 与 gVisor 两种后端跑进同一套调度

地址：https://github.com/deeplethe/sandstorm ｜ ★3,246 ｜ Apache-2.0 ｜ Rust ｜ 用最便宜的机器跑成千上万个 AI agent 沙箱：空闲时暂停并快照到磁盘，请求到来时快速恢复

事件内容

10-30 至 10-31 两天 34 次提交，今天这一组提交把它从"概念"推到了"可测量"。

• 核心机制：把空闲沙箱暂停并快照到磁盘，请求到来时快速恢复，因此一台机器能承载的沙箱数远多于它能同时运行的沙箱数。支持两种后端——gVisor 容器与 Firecracker microVM——每个沙箱有独立网络命名空间，两种后端可以在同一个集群里混跑，各自形成独立资源池；master 提供 Web 控制台查看与管理沙箱、跨集群调度。
• 今天的提交几乎全在"跑起来"上：feat(sdk-python)!: drive Sandbox through the master's API（带 breaking change，把沙箱调度统一收口到 master 的 API 上）、fix(node): remove a gVisor container that failed to start（清理启动失败的 gVisor 容器，避免僵尸占用）、fix(firecracker): let a restored guest through before setting its clock（恢复出来的 guest 要先放行、再校时——顺序反了会导致恢复失败）、bench: latency under gVisor, KVM and PVM on one build（在同一个构建版本下横向测 gVisor / KVM / PVM 三种运行时延迟）、docs: a tidier tiers table, and what was done for each backend（把各后端分别做到了哪一步写成分档表）、docs(sdk-python): a program that fails to load now raises。
• 许可与形态：Apache-2.0，Rust 编写，README 提供中文版（README-zh.md），CI 徽章同时挂着 gVisor 与 Firecracker。

值得关注的原因

• "先放行、再校时"这个顺序问题，是我自己写沙箱一定会踩的坑。 我在腾讯轻量服务器（101.42.26.85，公网 IP 101.42.26.85）上跑 sync-backend，也计划在上面部署更多 agent 服务。恢复一个快照出来的 guest，时钟通常是不对的——如果先校时再放行，可能会触发 guest 内部的时钟一致性检查而卡住；先放行再校时，是能跑通的那条路。这类"顺序错了就不 work"的坑，没有别人踩过并写进 commit message 的话，我大概率要花半天 debug。
• "同一个构建版本下横向测三种运行时"，这个测法对我做成本测算有直接价值。 我需要在"一人公司 + 有限预算"的约束下决定：跑 agent 沙箱该用 gVisor（轻量、共享内核）、Firecracker（microVM、隔离强、启动慢）还是直接 KVM？他们的做法不是各写一篇 benchmark，而是锁死一个构建版本横向比延迟——这是唯一能得出可比结论的测法。我把这张表当成选型依据，比自己零散试要可靠。
• "空闲沙箱暂停 + 快照到磁盘"这个机制，直接对应我的成本结构。 我最关心的指标从来不是"单个沙箱多快"，而是"同样一台机器能同时服务多少个会话"。上一期我记 lightpanda 时算过一笔账（Chromium 的 1/16 内存 → 同样机器预算下会话数多 16 倍），今天的 sandstorm 是在另一个维度上做同一件事：不是让每个 agent 更轻，而是让"闲置的 agent"不再占着机器。 对我的营养 AI 内核（白天要给客户出方案、晚上跑批量处理），"按需唤醒、闲时快照"意味着我不用为峰值容量常年付费。
• Apache-2.0（可商用、可闭源分发、无 copyleft 传染）+ Rust + 提供中文 README，对中文开发者的可及性也明显高于同类英文项目。"两种隔离后端混跑在同一集群、各自成池"的架构，还顺带给出了一个多租户隔离的思路——这对"一个人的产品要服务多个客户"这件事，比单纯的"每人一个容器"更有想象空间。

二、分类速览

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

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

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

④ 模型底座与 Agent 基础设施

三、今日趋势观察

今天最值得记的一条主线是：AI agent 生态的重心正在从"能不能跑通"整体转向"边缘情形有没有被处理干净"——而这个转向，几乎在四条线上同时发生。 37,251 星的 oh-my-pi 在修"标题漂移判定"和"按 wire 上真实字符串量字节"；1,854 星的 OpenAdapt 在修"数字必须按精确值比较""None 要匹配存储空值""SQL 守卫要词法切分而非子串匹配"；1,170 星的 PiDeck 在修"中文输入法提交的文字不再丢出草稿"和"DSH 用户插件安装必然 spawn npm ENOENT"。没有一条是关于模型能力的——全是关于工程细节的。这对资源有限的一人公司是个明确信号：差异化不在训练模型，而在把边界情形收干净。

• "验证"正在成为 agent 架构里的一等公民，而不是附加功能。 OpenAdapt 那组数字是今天最有说服力的证据：在故意注入 30 次坏保存的场景下，agent 对全部 30 次都宣称成功，而读回校验抓住 25 次（OpenEMR）与全部 30 次（MockMed），同时无误报。换句话说，在只看模型输出的界面上，错误率看起来是 0%。 这条结论比任何"模型能做到 XX%"的能力宣称都更重要——它说明我们过去评估 agent 的方式，可能系统性高估了可靠性。我准备把"保存后必须读回、且读回校验本身要过 tokenize/精确值/空值/注入四关"写进 4P 补剂平台与 GRPM 报告落库的设计约定里。
• MCP 生态开始进入"依赖治理"阶段，不再只是"接进来"。 FreeReps 今天把 mcp-go 升到 v1.4.0、连着两周修 GO-2026-6860/6866/6809 三个漏洞并把 govulncheck 卡进 CI；PiDeck 在做"ACP 预设 + 思考签名展示净化 + 商业化模式冻结"；oh-my-pi 的 fix(ai): key steering refusals by credential and record them only after a steer 则是在管"多次重试里的凭据轮换边界"。三个项目、不同技术栈，却在处理同一类问题：agent 拿着凭据和权限反复调用外部服务时，边界在哪里。 我给 4pwellness 接 MCP 连接器、给自己搭 MCP server，这些坑一个都跑不掉。
• 中文开发者社区在 agent 工具链上的存在感和产出密度都在上升。 PiDeck 的 ACP 接入 Copilot CLI / MiMo Code / Kilo Code / Cline、思考签名净化、中文输入法修复；sandstorm 提供中文 README、Firecracker 与 gVisor 双后端；oh-my-pi、claude-skills、archify 这类高星项目里中文贡献者密集。一个判断：中文市场的 agent 工具链，正在从"跟随英文社区"转向"有自己场景驱动的原生实现"——这对做中文健康内容、面向中文用户的产品是利好。
• 安全与成本在同一天被摆上桌面，而且指向同一件事。 FreeReps 连修漏洞、CI 卡 govulncheck；oh-my-pi 把 Anthropic 内联图片预算定在 120MB（128MB 上限留 8MB 余量）并按 wire 真实字符串量测；sandstorm 测 gVisor/KVM/PVM 三运行时延迟、把空闲沙箱快照到磁盘。三条线索合起来说的是同一句话：这个阶段的胜负手是"每单位成本下的可靠吞吐"，不是"单次演示有多惊艳"。 我那个"考证钩子 + 营养 AI 内核"的最小可行版，评估标准也该跟着改。
• 同时要警惕一件事：今天有 8 个条目是低星项目（★0–★176），其中 6 个是 MIT/Apache-2.0。 这正是我最关心的那一档——信息密度远超星数、且授权干净、可以拿来直接读或直接用。 但同样要诚实：低星意味着没有社区验证，shadowlzt/ironclaw-ai-vision 与 haoruilee/awesome-agent-native-services 甚至没有 LICENSE 文件，引用前必须先确认授权。读它们的代码可以，把它们当底座要先解决授权问题。

四、GitHub 地址速查

• can1357/oh-my-pi — https://github.com/can1357/oh-my-pi
• ayuayue/PiDeck — https://github.com/ayuayue/PiDeck
• OpenAdaptAI/OpenAdapt — https://github.com/OpenAdaptAI/OpenAdapt
• meltforce/FreeReps — https://github.com/meltforce/FreeReps
• deeplethe/sandstorm — https://github.com/deeplethe/sandstorm
• farion1231/cc-switch — https://github.com/farion1231/cc-switch
• nextlevelbuilder/ui-ux-pro-max-skill — https://github.com/nextlevelbuilder/ui-ux-pro-max-skill
• tt-a1i/archify — https://github.com/tt-a1i/archify
• alirezarezvani/claude-skills — https://github.com/alirezarezvani/claude-skills
• Q00/ouroboros — https://github.com/Q00/ouroboros
• Gentleman-Programming/gentle-shell — https://github.com/Gentleman-Programming/gentle-shell
• sno-ai/sno-station — https://github.com/sno-ai/sno-station
• jmfederico/pi-web — https://github.com/jmfederico/pi-web
• OHIF/Viewers — https://github.com/OHIF/Viewers
• Slicer/Slicer — https://github.com/Slicer/Slicer
• InsightSoftwareConsortium/ITK — https://github.com/InsightSoftwareConsortium/ITK
• fo-dicom/fo-dicom — https://github.com/fo-dicom/fo-dicom
• medic/cht-core — https://github.com/medic/cht-core
• avinashkranjan/lifeMEDeasy — https://github.com/avinashkranjan/lifeMEDeasy
• mdbabumiamssm/LLMs-Universal-Life-Science-and-Clinical-Skills- — https://github.com/mdbabumiamssm/LLMs-Universal-Life-Science-and-Clinical-Skills-
• simonEllershaw/llm-discharge-summaries — https://github.com/simonEllershaw/llm-discharge-summaries
• thetahealth/mirobody — https://github.com/thetahealth/mirobody
• OpenStrap/edge — https://github.com/OpenStrap/edge
• Lethe044/hermes-life-os — https://github.com/Lethe044/hermes-life-os
• brandonp2412/FitBook — https://github.com/brandonp2412/FitBook
• shadowlzt/ironclaw-ai-vision — https://github.com/shadowlzt/ironclaw-ai-vision
• fitguyfitguy/Chompass — https://github.com/fitguyfitguy/Chompass
• Regevba/FitTracker2 — https://github.com/Regevba/FitTracker2
• Teamz-Lab-LTD/device-gpt — https://github.com/Teamz-Lab-LTD/device-gpt
• jaronskijakub/fatsecret-mcp — https://github.com/jaronskijakub/fatsecret-mcp
• flashinfer-ai/flashinfer — https://github.com/flashinfer-ai/flashinfer
• lemonade-sdk/lemonade — https://github.com/lemonade-sdk/lemonade
• kserve/kserve — https://github.com/kserve/kserve
• gpustack/gpustack — https://github.com/gpustack/gpustack
• tastyeffectco/sandboxd — https://github.com/tastyeffectco/sandboxd
• desplega-ai/agent-swarm — https://github.com/desplega-ai/agent-swarm
• agentic-os-org/ANOLISA — https://github.com/agentic-os-org/ANOLISA
• haoruilee/awesome-agent-native-services — https://github.com/haoruilee/awesome-agent-native-services
• lobu-ai/lobu — https://github.com/lobu-ai/lobu