开源雷达 · 2026-10-21：技能开始像软件包一样被治理

每天从 GitHub 上挑 5 个正在涨的 AI 与开发者工具项目。今天我读了每个项目的 README、发布记录和最近的提交，没有逐个安装运行；哪条试过，会在条目末尾写明。Star 数等数字取自 GitHub，截至 2026-10-21。

今天有个方法上的偏差要先说：GitHub Trending 的周榜和日榜抓取都超时了，5 个项目全部来自 topic 搜索。所以「这周在涨」这个信号今天缺失，我改用建仓时间、最近推送时间和日均涨星来排序。这一点在文末的观察里还会提到。

1. NVIDIA/skills ⭐ 3,669 · Python

GitHub：https://github.com/NVIDIA/skills

一句话：NVIDIA 把自家 SDK 的用法写成 415 个可安装的 Agent 技能，并且给每个技能配了签名、能力卡和评测集。

它是什么：一个只做分发的目录。技能正文维护在各产品自己的仓库里，一条自动化管线每天把它们镜像过来，按 56 个产品分组（CUDA-X、cuOpt、BioNeMo、DeepStream、Holoscan、Omniverse、Nemotron 等），再用 skills 命令行工具装进 Claude Code、Codex、Cursor、Kiro 这类编码 Agent。装一个技能就是一行 npx skills add nvidia/skills --skill <名字>。仓库没有 GitHub Release，靠主干每天同步迭代。

值得注意的地方：

• 准入门槛写在流水线里，不写在文档里。 一个技能要出现在 skills/ 下，必须同时带三样东西：skill.oms.sig（分离式签名，可对仓库根目录的 nv-agent-root-cert.pem 验签）、skill-card.md（身份与治理卡）、一份 Tier-3 评测数据集。缺任何一样，同步时直接丢掉。这比「请提交高质量技能」这类约定硬得多。
• 装进去的东西能被独立验真。 用 model-signing 对技能目录验签，能确认内容自 NVIDIA 签名后没有被改过。它把「我装的是官方技能」变成一次来源校验，而不是靠信任。能确认的是来源与完整性，不保证内容正确、也不保证安全；技能本身也不带凭据、不带权限，它是给宿主 Agent 读的文字，能碰到什么仍由那个 Agent 自己的配置决定。
• 评测结果跟着技能一起发。 评测跑出 BENCHMARK.md 就随技能发布，读者看到的是「相对基线提升了什么」，而不是一句官方推荐。
• 产品团队在注册表里排队。 components.d/ 下一个产品一个 yml，团队在这里接入；plugins.d/ 负责打包成插件形态，两套 marketplace 元数据分别对接不同客户端。
• 规范是公共的。 目录里只有 SKILL.md 加 YAML frontmatter（必填 name 与 description），启动时只加载元数据，命中任务才读正文——就是 Agent Skills 规范的渐进披露。

和同类比：值得对照的是它的准入闸门与产物——签名、能力卡、评测集，以及有就随包发布的评测报告。我只读了这个仓库本身。

最近更新：2026-10-21 当天，同步提交拉入了 CDF 系列（AnomalyGen、Augmentation、Auto-Labeling、Curation）与 Holoscan SDK，同时重新生成 metadata.json、skills.sh.json、benchmarks.json、versions.json；同一天还有把 Physical AI 组件钉到 paidf-26.10 的版本固定提交。从提交密度看，这是一条每天在跑的流水线。

适合谁：用编码 Agent 做 CUDA、仿真、机器人、RAG 的人：技能提供的是对应 SDK 的用法说明，Agent 照着做；凭据、工具与权限仍需另行配置。两个前提要留意：一是双许可证——源码 Apache-2.0，文档与技能 CC-BY-4.0；二是技能是同步来的，上游改动会覆盖本地内容，需要定期 npx skills update，而更新时它会把上游已合并或删除的技能也标出来。

我的看法：⭐⭐。当目录用是好用的，但真正值钱的是它的治理结构——如果你是维护一方技能库的人，这四道闸门（签名、能力卡、评测集、缺件即丢）值得照抄。

核验：读了 README、仓库结构、contents API（415 个技能目录）与最近提交；没有安装任何技能，也没有跑验签。

2. smol-machines/smolvm ⭐ 6,779 · Rust

GitHub：https://github.com/smol-machines/smolvm

一句话：把 microVM 做成一个可以嵌进程序里的库，能给运行中的机器打检查点，再分叉出几个副本继续跑。

它是什么：一个以库形态存在的虚拟机运行时。VMM 是 libkrun，guest 内核由 libkrunfw 提供，宿主侧走 macOS 的 Hypervisor.framework、Linux 的 KVM 或 Windows 的 WHP。镜像用 OCI 格式，兼容的镜像可以不经 Docker 守护进程直接跑起来。兼容要按单个镜像看：具体哪些镜像、哪些宿主特性真的能启动，我没有核。SDK 跑在调用方进程里，也没有独立的后台服务。版本号已经到 v1.30.1，两天内连发三版（10-16 的 v1.29.1、10-17 的 v1.30.0 与 v1.30.1），GitHub 上的发布记录超过 100 条。

值得注意的地方：

• 分支是核心抽象，不是快照的副产品。 检查点捕获内存、CPU 状态和磁盘；machine branch --from agent 得到的是运行中机器的写时复制子机，子机从同一时刻继续跑；还能用 --from <checkpoint> --at '~N' 回退到更早的代数。对「同一个起点，试三条路」的场景，这比重跑三次省得多。
• 默认值按「便宜」设计。 README 自己的表写「到 agent ready 不足 200 毫秒」，默认 4 vCPU / 8 GiB，内存靠 virtio balloon 弹性占用，空闲 vCPU 在 hypervisor 里睡。这几个数字是项目自报，我没有实测。
• 产物可以带走。 一台配好的机器能打包成单个 .smolmachine，推到任意 OCI registry，或者直接当自包含可执行文件运行；README 明确写了 arm64 Mac 上打的检查点可以在 arm64 Linux 上恢复。
• 网络默认关闭。 出网要显式打开，再按主机名、通配主机名或网段放行，而且运行中的机器可以增删规则——放行对下一次连接生效，撤销时连已学到的地址一起清掉。
• 凭据可以不进客户机。 用 --credential 转发密钥时，按文档的设计，客户机里拿到的是占位符，真正的值由运行时在出站请求上替换。我没有实测客户机能否取回它、或在预期请求路径之外使用它。

和同类比：作者在 README 里放了一张对比表，机制层面的差异是可核的：容器是命名空间加共享内核，它给每个负载独立 guest 内核；它是库而不是守护进程，Firecracker 是进程加 jailer 的形态；它支持 macOS 原生与进程内 SDK，表里 Firecracker 这两栏是不支持。有一点要说明——启动速度上它并不领先 Firecracker，表里写自己不足 200 毫秒、Firecracker 不足 125 毫秒，它的优势在平台覆盖与可嵌入。这张表是项目单方面的，我没有对 Firecracker 与 Kata 做独立核验。

最近更新：v1.30.1（10-17）把引擎的命令行暴露成库模块，暂停恢复的输入能塞进内存文件系统时不再做多余的磁盘暂存，并给创建机器的镜像拉取留出超过五分钟的窗口；v1.30.0 把大镜像的 blob 改成并行分段拉取；10-21 还有未发版的提交，处理「分支子机吃爆宿主内存」的问题——加入 OOM 处置顺序与内存压力保护。看提交能看出它正在为真实的多分支负载补硬骨头。

适合谁：需要给 Agent 跑不可信代码的团队。前提是 Linux 上有 KVM，或 macOS Apple Silicon；macOS Intel 目前没有发布构建、标注未测试，Windows 上 GPU 加速还不可用。另外要认清它的定位：它提供的是边界，不是策略——挂进去的目录、放行的主机、转发的密钥，都会变成负载能用的东西；而且边界不撤回已经出去的东西：发出去的请求、写进挂载目录的文件、花掉的钱，回滚检查点一样都收不回来。

我的看法：⭐⭐⭐。「可分支的沙箱」这个组合比单点功能有用，因为实验可以从同一个虚拟机状态开始；分叉不会撤回已经产生的外部副作用。

核验：读了 README、三个版本的发布记录、最近的提交；没有安装，没有启动过任何虚拟机，也没有实测隔离效果与凭据代理——这里的边界是文档写的，不是我测的。

3. pydantic/pydantic-ai ⭐ 20,758 · Python

GitHub：https://github.com/pydantic/pydantic-ai

一句话：Pydantic 团队做的 Python Agent SDK，工具、依赖、输出全部走类型标注，同一份 Agent 定义能跑成命令行、网页、实时语音或后台任务。

它是什么：一个定义 Agent 的库，外加同源的一组组件：Harness（给长任务用的能力包）、Evals（评测）、Graph（类型化控制流）、genai-prices（模型定价）、Monty（跑模型生成代码的沙箱解释器）。核心抽象是 Agent 加 capability——把工具、指令、钩子、模型设置打成一个可复用单元，内置的编码 Agent、研究 Agent 就是若干 capability 组合出来的。版本号到 v2.58.0，GitHub 发布记录超过 300 条，v1 与 v2 两条线仍在同步维护（10-20 同日发了 v1.107.8 与 v2.58.0）。

值得注意的地方：

• 类型一直管到工具边界。 结构化输出、类型化依赖注入、类型化工具签名——编辑器和类型检查器知道 Agent 会返回什么，能在开发阶段暴露已标注接口的不匹配。运行时验证与授权仍需另行检查；没有注解的工具、动态拼出来的载荷、跨 JSON 边界传的东西，仍然要到运行时才炸。
• 同一个定义换接口不换代码。 命令行、内建网页聊天、实时语音、UI 事件流、编辑器 Agent 协议、GitHub Actions，都从同一个 Agent 出来。类型检查只覆盖实际纳入检查的路径与标注。
• 实时语音里，工具能在说话中间被调用。 会话建立后一边推麦克风流、一边播回流式音频、一边收转录；模型在对话进行中调你的函数。后端覆盖 OpenAI Realtime、Gemini Live、Azure、xAI Grok Voice。
• 持久执行接了八个引擎。 Temporal、DBOS、Prefect、Restate、AWS Lambda、Airflow、Absurd、pgtask，其中前五个与对应厂商团队共同维护。Agent 能跨重启活下来、跑几天，并带人工审批的工具调用。
• 评测连工具轨迹一起评。 不只给最终输出打分，还能评工具调用序列，数据来自代码里的数据集或线上流量采样。
• 同一天修掉了一个中危安全问题。 公告写得很具体：provider 原生的 MCP 配置会把 MCP 服务器地址、授权 token 和自定义请求头写进 OpenTelemetry 请求追踪，即使 include_content=False；基于 URL 的 MCP 能力还会把 URL 里内嵌的凭据带出来。v2.58.0 与 v1.107.8 同时修复。

和同类比：它的类型化接口建立在已有的校验生态上——按 Pydantic 官方的说法，它的校验库已经是 OpenAI SDK、Anthropic SDK、Google ADK、LangChain 的校验层，这条路是顺着已有依赖长出来的。README 提到有一份专门的对比页面，覆盖 LangChain、Google ADK、Claude Agent SDK 等十来个框架；我没有打开那份对比逐条核，所以这里写的是它的机制，不是「比谁强」。

最近更新：除了上面那条安全修复，10-21 的提交都在收紧边界：工具调用配额从「每轮查一次」改成「每次嵌套调用前查」；评测器的反馈用引用绑定到自己的帧，伪造的反馈标签不再生效；新增 xAI grok-4.7 的模型条目。

适合谁：Python 栈、要做语音或长任务、并且需要可评测的团队。两个现实提醒：1,564 个未关闭 issue 说明表面积很大；v1 与 v2 双线并行，选版本前先确认依赖方支持哪条。

我的看法：⭐⭐⭐。如果你的语音链路是 Python，它给的「通话中调工具 + 类型化边界 + 轨迹评测」是一套能直接照着搭的骨架。

核验：读了 README、两个版本的发布记录与安全公告摘要、最近提交；没有安装，没有跑过任何示例。

4. kuafuai/andee ⭐ 1,690 · Kotlin

GitHub：https://github.com/kuafuai/andee

一句话：装一个 APK，它就用手点你的手机——读无障碍树和截图，点格子而不是算坐标。

它是什么：一个没有常规界面的安卓应用：入口是一个无障碍服务，结果画在一层悬浮窗上，脸就是那颗球。整个 Agent 循环默认跑在手机上，直连任意 OpenAI 兼容端点；也可以把大脑搬到远端，用一份工具 schema 契约连回来，两半各自可换。一个月建仓拿到 1,690 stars，43k+ 行 Kotlin 全部自己写，明确不用 Compose、不用依赖注入框架、不用协程——理由是悬浮窗宿主放不了 Compose、只有一个服务所以手写构造注入、并发用 Handler 加专用执行器。

值得注意的地方：

• 读屏靠两层降级。 正常情况把屏幕读成缩进式元素大纲，每行一个元素带可点编号；遇到小程序、网页视图、游戏这种自绘像素的界面，退回截图，并在截图上叠一张 8×12 的标注网格。它点击时说「第几格、格子的哪三分之一」，不做坐标换算——理由是通用模型算坐标最差、读格子最好；对不准时放大并画出落点红十字再确认。同一位置的第四次点击会被拒绝，模型只能停下来问。
• 输入走输入法的老路。 Android 13 以上用无障碍服务自己的文本提交通道往焦点框写字，用户自己的输入法不用切走。
• 密码能「用过但看不到」。 保险库用 Keystore 的 AES-GCM 存在本机；模型能列出账号、能让密码被打进焦点框，但没有任何工具会返回它，连打码都不给。
• 陌生人的通知动不了保险库。 通知触发的回合被标成不可信，分发器直接拒掉保险库前缀与场景的增删改——在分发器里拒，不在提示词里劝。
• 它会自己收尾。 对话静下来后给自己发一个回合，独自回读，关掉未兑现的承诺，宁可空手结束也不编一条记忆。
• 作者把「做不到」也写清楚了。 安全文档列了五条已知限制，最重的一条：设备端 WebSocket 服务监听在 0.0.0.0:9008 且不校验任何凭据，同一网段内任何主机都能把它当驱动端，读屏幕、动用已保存的凭据；作者据此要求按「设备可被完全控制」来假设。安全文档还直说当前没有沙箱，对高风险动作的检查是给模型的指令而不是强制，机械拒绝是窄例外。

和同类比：安卓自动化常见的两条路是 ADB 脚本和无障碍加坐标点击。这里的机制差异有三处，都能落到具体文件：格网点击把「算坐标」换成「读格子」；分发器层的拒绝不受提示词影响（虽然只覆盖少数路径）；大脑与身体可分离，换设备是换端口而不是重写。我只核了这个项目，没有读同类实现的代码，所以不评它们缺什么。

最近更新：v0.5.2（10-19）修「元素树被藏起来的应用上对不准」。发布说明给的数字是：在微信朋友圈发一条评论，从 64 步 / 341 秒降到 20 步 / 58 秒，且第一次点击就发出去——作者注明两个修复都不是新能力，是靠测量发现的浪费回合。v0.5.1 修了两处「悄悄失效」：夜间自省随进程死掉不再回来，以及小米系设备的省电策略在后台把它杀掉而界面上毫无提示。另有一个诚实的细节：随包附的 APK 是调试构建，因为发布构建没有配置签名、仓库里也没有密钥库。

适合谁：想在安卓上做端侧 Agent、并且愿意接受高权限的人。三条必须知道的边界：无障碍服务加悬浮窗是安卓上权限极大的一类授权；它能替你发消息、也能花钱（项目明说没有支付工具也不需要，因为它会点）；许可证是 Apache-2.0 加附加条件——不许做多租户 SaaS、不许去掉品牌做白标、未经书面授权不许嵌进别的产品，所以具体用途要按仓库的完整条款逐条复核。

我的看法：⭐⭐。理念（常驻设备的自我，而不是一堆功能）比功能列表有意思，但现在这个版本的安全边界还没到能日常使用的程度。

核验：读了 README、SECURITY 的五条已知限制、LICENSE 条款原文、三个版本的发布记录；没有装 APK，没有在手机上跑过。

5. EverMind-AI/Raven ⭐ 5,532 · Python

GitHub：https://github.com/EverMind-AI/Raven

一句话：一个主 Agent 把多个专职 Agent 编成执行图干活，另有一个 Curator 反复改写它们各自的策略，改完要过验证才装。

它是什么：一个多 Agent 运行环境。给一个目标，主 Agent 拆解任务、把子任务匹配给专门的 Agent、协调依赖、整合结果；内建四个 Agent（研究、编码、设计、值守），通过编辑器 Agent 协议、命令行或 OpenAI 兼容接口接第三方 Agent。记忆与上下文由同门的长期记忆运行时承担，技能检索走它自己的技能检索层。技术报告在 arXiv（2609.33439），摘要的核心论点是：当 harness 复杂度上升、又与特定领域绑得太紧时，问题就从「为一个领域造更强的 harness」变成「自动构造专用 harness、靠经验改进、并跨领域编排」，每个「模型—harness 对」是一个可组合的智能单元。

值得注意的地方：

• Agent 循环被拆成四个可替换的座位。 记忆（这一回合能看到什么）、规划（怎么着手）、能力（这一轮暴露哪些工具）、行动（下一步做什么、执行前怎么判）。Curator 改的就是这四块：可以是一个设置，也可以是一小段专为该 Agent 写的判断代码。
• 改动有闸门，而且只属于那个 Agent。 装之前必须验证，验证不过打回；每轮的信号到达时默认把参考答案剥掉，限制答案被直接看到。Curator 自己标为实验性，随仓库发布而不随安装包。
• 改配置的工具守规矩。 读任何设置不问，写任何设置都先问，密钥永远不经对话传递。
• 编排是有依赖的执行图。 v0.2.5 加入了工作流里的条件分支，以及把任务委派给「已注册机器」上的远端 Agent——用那台机器上 Agent 的能力和工作环境来跑子任务。
• Persona 是它先造出来的东西。 你描述想要的助手，Curator 组一个：一个主角色跟你说话，加上从已有 Agent 里抽的专家；你提的要求落在那个助手的 harness 里——分工、可用的工具、动手前必须过的检查。

和同类比：这里把改写权交给一个独立的 Curator，限定改动对象是单个 Agent 的四块策略，装之前要过评测。这些是可与其他运行时对照的具体机制；我没有核过别家是否也允许运行时改写。

最近更新：v0.2.5（10-20）加强多 Agent 编码、支持把任务委派到已注册机器的远端 Agent、工作流加条件分支、改进原生 Windows 支持，并把轨迹视图对所有人开放；v0.2.4（10-03）加了改配置的工具与新的审批键位；v0.2.3（09-27）把裸命令改成打开浏览器页面。项目自己在 README 顶部标了 pre-alpha，接口与配置会快速变化。

适合谁：研究 harness 自演化、或者想给自己的 Agent 系统做「策略可替换」实验的人。三条要提前接受的现实：pre-alpha；仓库 255 MB，是个大工程；README 里的效果数字（172 次训练把验证集指标降 5.8%、溃坝模拟越界比例从 1 降到 1.36e-10、有限元二分区间从 1800–2000 千牛收到 3.125 千牛）全部来自项目自述与它自己的图表，我没有跑过其中任何一个。

我的看法：⭐⭐。可抄的是结构（四座位 + 验证闸门 + 剥离参考答案），不是结论。

核验：读了 README、arXiv 摘要、三个版本的发布记录、最近提交；没有安装，没有复现任何基准。

速览

本期观察

• 技能的治理正在向软件包看齐。 签名、能力卡、评测集、缺件即丢——这套东西本来属于包管理器与供应链安全，现在被搬到「教 Agent 怎么用某个 SDK」这种内容上。技能从提示词片段变成有版本、有出处、有评测的资产，这是今年值得留意的一条线。
• 两处不同位置的边界。 一边是把每个负载塞进独立内核、还能从运行中的状态分叉；另一边是把「陌生来源不许碰敏感资源」做成分发器里的拒绝。共同点是把边界写成代码路径，而不是交给模型自觉——smolvm 写明的 VM 边界我没有实测，andee 自己的安全文档则写明机械拒绝只覆盖少数路径。
• 语音链路需要对话质量以外的动作检查。 类型化接口与轨迹评测是检查动作选择的方法；两者都不能证明链路会拒绝每一个错误动作。同一天披露的 MCP 追踪公告，是检查受影响版本与 redaction 行为（包括关掉内容记录时）的具体理由。
• 「让 Agent 改自己」开始有可审计的形状，但还早。 把策略拆成四个座位、改动前必须验证、信号里剥掉参考答案——这套流程可讨论、可核对。代价是项目自己标着 pre-alpha，效果数字全自报。这个阶段适合读它的设计，把项目报告与独立复现分开看。