开源雷达 · 2026-10-24：技能文件开始被当成有规范的交付物

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

1. OpenBMB/VoxCPM ⭐ 40,329 · Python

GitHub：https://github.com/OpenBMB/VoxCPM

一句话：不做离散 tokenizer 的开源语音合成，2B 参数、30 种语言、48kHz 输出，权重与代码都是 Apache-2.0。

它是什么：一条绕开语音离散化的合成路线——不先把声音压成 codec token，而是在 AudioVAE V2 的连续潜空间里做「扩散自回归」，流程分四段：LocEnc → TSLM → RALM → LocDiT。当前主推版本 VoxCPM2 是 2B 参数，在 200 万小时以上多语种语料上训练。2025 年 9 月建仓，一年内从 0.5B 走到 2B，至今 14 个正式 release，主线提交到 2026-10-08 还在进。

值得注意的地方：

• 模型架构里包含 48kHz 输出。 编解码器不对称：编码端吃 16kHz 的参考音频，解码端直接出 48kHz，自带超分，不需要外挂升采样器。这类设计比参数量更能说明取舍——省掉了一整级后处理。
• 「支持 30 种语言」要按语言列读。 项目自报的 MiniMax-MLS-test 多语种表里，错误分数包含 Chinese 1.136、German 0.679、Dutch 0.913，而 Arabic 13.046、Czech 24.132、Romanian 21.577、Hindi 19.699——同一张表里 Minimax 的 Arabic 是 1.665、ElevenLabs 是 1.666。覆盖面和每种语言的质量，在这一张表里分得很清楚。
• 声音设计写进括号里，不用参考音频。 把「年轻女声、轻柔、语速偏慢」这类描述放在待合成文本开头的括号中即可造新音色；克隆则给一段参考音频，还能叠加风格指令改情绪和语速而保留音色。README 自己写明这两项结果有随机性，可能要生成 1~3 次才拿到想要的。
• 项目自报了实时因子与显存占用。 在其设置下，RTX 4090 上实时因子（RTF）约 0.30，用 Nano-vLLM 加速约 0.13，显存约 8GB。0.30 意味着生成 10 秒语音要算 3 秒，但这不能说明首包延迟、端到端延迟或并发承载能力。
• 项目描述微调用 5–10 分钟音频即可；门槛不等于质量保证。 SFT 与 LoRA 都支持；2.0.3 加了 voxcpm validate，先校验训练清单的字段、音频可读性、采样率与时长统计，把「训到一半才发现数据格式错」往前挪。

和同类比：项目自报的 Seed-TTS-eval 表里，VoxCPM2（2B）英文 WER 1.84 / 说话人相似度 75.3、中文 CER 0.97 / 79.5、难样本 CER 8.13 / 75.3；同表 FishAudio S2（4B）英文 WER 0.99、Qwen3-TTS（1.7B）1.23 更低，LongCat-Audio-DiT（3.5B）在难样本上相似度 79.7 更高。这些分数是项目自己跑的，我没有复现，跨表只能当参考。机制上它是连续潜空间生成，与主流「离散 token + 自回归」是两条路，上面那张多语种表显示结果并不均衡，但没有区分是哪项架构选择造成的。

最近更新：v2.0.3（2026-05-11）——新增训练清单预检；微调数据支持可选参考音频（打包格式 [103, ref_audio, 104, text, 101, target_audio, 102]，损失只算目标段）；新增有状态的 StreamingVAEDecoder，流式解码只处理最新 latent 片段并在内部携带因果卷积状态，去掉重复的重叠计算；LoRA 加载改 weights_only=True；CLI 加 --device 支持 cpu / mps / cuda 与带索引的设备。主线 09-30 给微调数据预处理提速，10-08 合入 i18n 与 Hugging Face 训练两个社区 PR。

适合谁：要做多语种语音产品的团队，尤其是需要本地部署、需要按坐席或角色克隆音色、又不想被 SaaS 计价绑住的场景。下手前先做一件事：拿目标语种的文本各跑一遍识别回测，别按「支持 30 种」下结论。克隆差异要用固定设置和「参考音频 + 转写」的完整克隆模式去评估；固定 seed 本身不能证明跨设备可复现。项目把代码与权重表述为 Apache-2.0；投产前请核对具体发布文件与适用条件；项目同时要求使用方自行做安全评估，并禁止用于冒充与欺诈。

我的看法：⭐⭐⭐

核验：读了 README 全文、2.0.1–2.0.3 三份发布记录、最近 6 条提交；没有安装，没有跑评测。

2. SnailSploit/Claude-Red ⭐ 8,579 · Python

GitHub：https://github.com/SnailSploit/Claude-Red

一句话：按安全评估面组织的 78 份结构化 SKILL.md，另附一份技能写作规范。规范本身不能证明专业能力，也不能证明触发正确。

它是什么：纯内容型仓库——Skills/<分类>/<技能>/SKILL.md，文件夹名必须等于 frontmatter 里的 name。分类按攻击面切：Web 16 个、无线 14 个、基础设施与红队 7 个、漏洞利用开发 6 个、模糊测试 4 个，其余十几类各 1~3 个，合计 78 个 / 23 类。2026 年 3 月建仓，8 月 30 日的 v0.3.0 把 37 个平铺技能重组成了现在这套结构，之后主线只合社区 PR（新增 OSINT 元数据查看器、忽略 .DS_Store、技能评审指向当前 commit）。

值得注意的地方：

• 写作规范把 description 当作路由输入。 规范要求 50–500 词，写清这个面覆盖哪些技术、什么时候该用它，并且明确要求「密集堆操作者会说的词，避免营销语言」——模型就是拿这段做触发匹配的。抽一份 SQL 注入技能看，那一段把 error-based 到 NoSQL、GraphQL、WebSocket、WAF 绕过、四种数据库、ORM 漏洞全列进去了。
• 正文有固定骨架。 一段定位 → Quick Workflow 编号步骤（现场按序执行）→ 按技术分节（可直接复制的命令与 payload）→ Detection / Defender View（防守方会看到什么）→ Engagement Cheatsheet（一屏可粘贴的流程摘要）→ Key References（ATT&CK / CWE / OWASP 编号、论文、公告链接）。典型长度 200–800 行。
• 一个技能一个面，明确反对大而全。 规范第一条就是「优先聚焦技能，而不是概览式大块」；无线那 14 个专项就是从原来的单体 offensive-wifi 拆出来的。拆细让描述可以更窄；我没有测过它是否提高触发准确率。
• 正文设计为按需加载。 项目说技能按对话触发词按需加载；这不等于索引本身没有上下文成本。预期好处是避免每次都把全部技能正文塞进对话，实际加载与索引开销取决于宿主工具。
• 红线写在贡献规范里。 不许硬编码真实受害者域名、客户数据或凭据；每条技术要给可追溯的出处。
• 路线图公开且不装完整。 9 个阶段、目标约 130 个技能，目前 3/7/8/9 阶段标完成，活动目录、云身份、IoT、Web 基础与进阶五段还是计划中——也就是说现覆盖大约六成。

和同类比：可核的差异在工程约束这一层：我没有足够广地读过其他技能仓库，无法概括它们的格式规范；这个仓库把技能当成要评审的交付物——有 frontmatter 硬要求、有正文骨架、有长度区间、有安全红线、有阶段路线图。它的内容也不是原创：README 致谢里写明许多技能的底稿来自另一份公开的攻击 checklist 合集。别家技能库是否也拿 description 当触发键写、是否也有评审规范，我没有逐份读，所以只能说这三条它写明了。

最近更新：v0.3.0（2026-08-30）从 37 个平铺技能扩到 78 个 / 23 类，新增容器逃逸、CI/CD 投毒、API 安全、密码学实现攻击、提权、后渗透、反取证与 C2、供应链、社会工程、网络层攻击共 10 类 20 个技能；无线部分拆成 14 个按面切分的技能（802.11 侦察、WPA2/3、EAP、WPS、evil-twin、BLE、Zigbee、Z-Wave、LoRa、sub-GHz 等）。09-19 一口气合了四个社区 PR。10-12 更新 README 的分类计数与索引。

适合谁：两类人。写 Agent 技能库的，借它的格式规范——description 怎么写、正文分几节、长度控制在多少，这几条比内容本身更通用。做授权渗透测试与红队演练的，借它的内容，但要自己复核时效性（漏洞利用类文档过期很快）。许可证 MIT。必须说清楚：这些内容本身是攻击方法，只能用在有书面授权的目标上，用在别处是违法。

我的看法：⭐⭐⭐

核验：读了 README、CONTRIBUTING、v0.3.0 发布记录、最近 6 条提交，并抽读了 Skills/web/offensive-sqli/SKILL.md 全文；没有安装。

3. autonomous-ai/openharness ⭐ 1,358 · TypeScript

GitHub：https://github.com/autonomous-ai/openharness

一句话：把散在几台机器上的编码 Agent 收进一个窗口——每台机器一个守护进程、Agent 跑在 tmux 里，机器之间端到端加密直连。

它是什么：一个多机、多引擎的 Agent 操作台。可选 14 个引擎（Claude Code、Codex、Cursor、OpenCode、Devin、Amp、Copilot 等），Store 里另有 49 个按手艺切分的封装（Blender、KiCad、FreeCAD、MuJoCo、RDKit、Typst、Strudel、vLLM……），每个是一个带 harness.json 的文件夹，装上就能让 Agent 操作那门工具并配实时查看器。2026 年 8 月 4 日建仓，两个多月发到命令行 0.4.60 / 网页 1.3.66，单个 release 的 changelog 常有十几条，PR 编号已到 #1675——发版节奏很快，但快本身不能证明可靠或已被采用。

值得注意的地方：

• 不包裹 Agent，只读会话。 每个 Agent 跑在自己的 tmux pane 里，滚动缓冲、颜色、按键都是真终端；一个会话一个 git worktree，主工作副本保持干净。项目明确写「从不包裹 Agent，只读 transcript、用厂商自己的 hook」——兼容性仍取决于 transcript 格式与厂商 hook；我没有测过升级后的表现，也没有测过这些接口能看到多少内部状态。
• 守护进程只往外拨号。 每台机器一个守护进程，主动连出去，项目称这套连接方式不需要在被管机器上开入站端口、提供 SSH 密钥或配置组网与端口转发。我没有审计实际网络暴露面。加机器的动作是「在目标机跑几条命令 + 在应用里输密码」。
• 三级链路自动降级，中继不持密钥。 有直连条件时走机器之间的 WebRTC；防火墙挡住就走 Cloudflare 的 TURN；再不行用自家中继过渡，中继只转发密文。项目文档写明 ChaCha20-Poly1305、X25519 会话密钥与 Ed25519 固定身份。这是协议描述，不是独立安全审计。远端终端传的是文本字节而不是像素，所以不需要远程桌面。
• 原生应用而非浏览器套壳。 Flutter 写的，关掉窗口 Agent 继续干活。项目给的闲置测量（M2 Max、16 个终端各 1000 行滚动缓冲的 Release 构建）：界面响应中位 11–13ms、p95 15–18ms；本地终端回显中位 1.1ms、p95 7.2ms（不含渲染）；常驻约单核 0.1% 加 304MiB（含终端渲染与滚动缓冲，不含 Agent 进程本身）。
• 协作接口还在长。 同一标签页里的会话可以用命令互相传消息（标注实验性、默认关闭）；另有 Swarm——按项目配自定义角色、有 Lead 角色，机器被移除时会连带清理它的角色、目录与 worktree。10-23 一天就进了「按项目自定义角色」「机器 owner 移除机器并清理」「resume 失败可恢复」好几条。
• 硬件也开源。 可选的桌面圆盘：ESP32-S3、466×466 圆 AMOLED、触摸与麦克风，USB 接守护进程，固件、PCB（含 Gerber 与 BOM）、外壳（STEP/STL）全在仓库里。作用是「哪个 Agent 在等我」一眼可见。

和同类比：和「多 Agent 终端管理器」这一类比，它把三个决定摆在明面上：Agent 不被包裹（只靠 transcript 与厂商 hook）、远端链路自己实现三级降级且中继不持钥、扩展单位是「文件夹 + 一个 JSON」。值得逐个对照的四个维度我没法替它下结论：远端传字节还是传像素、是否需要公网可达或第三方组网、会话状态存在本机还是服务端、多机身份怎么校验。这四条决定了出故障时数据在谁手里。

最近更新：命令行 0.4.60（2026-10-24）——按项目自定义 Swarm 角色并被命令行识别；机器 owner 可把机器移出 Swarm 并联动清理目录与 worktree；resume 失败变成可恢复；修复旧版守护进程回复时切换 Agent 出错；Windows 上把 Claude Code 的 > 输入框正确识别成 prompt。同一天还有网页版 1.3.66（与桌面端同一份 Flutter 代码的浏览器构建）。

适合谁：手上有两台以上机器、同时用两三个不同厂商编码 Agent 的人。要注意两点：协作相关接口近两周改得很勤，别急着在它上面焊长期流程；它需要每台机器装守护进程并接受「密码 + 固定身份」的连接方式，安全模型要自己评估——中继不持钥只说明它自己不存密钥，不等于整条链路没有信任假设。

我的看法：⭐⭐⭐

核验：读了 README 全文、三份发布记录、最近 6 条提交；没有安装，性能数字取自项目自报。

4. FengZhenfei/carrel ⭐ 463 · Python

GitHub：https://github.com/FengZhenfei/carrel

一句话：给 Agent 用的自托管知识库，检索服务只负责召回证据、不负责生成答案。

它是什么：文档进来先解析（PDF、Word、PPT、表格、图片、HTML、Markdown、源码，用 MinerU 加各格式的原生解析器）、切块、建向量与关键词索引，可选再建知识图谱；Agent 通过一个搜索接口拿原文片段、图片和关联事实，自己组织答案。组件不自己造：向量用 Qdrant、关键词用 OpenSearch、图谱用 Neo4j、文件与任务状态用 SQLite。2026 年 9 月 28 日建仓，不到一个月三个 release，star 只有 463、fork 3——仓库计数不能证明生产使用或可靠性。

值得注意的地方：

• 「检索不生成」是硬边界。 项目原话是服务只召回、重排、整理证据，不做生成。好处是同一批证据能被不同模型复用，服务里没有生成答案这一步；但检索、解析与证据挑选本身仍可能出错，答案质量也取决于这些环节和调用方 Agent。
• 加上批不变设置，减少检索结果波动。 v0.2.1 把三个模型服务切到批不变模式（VLLM_BATCH_INVARIANT=1），原因是此前分数会随批大小与缓存轻微漂移，导致排名靠后的候选时有时无。代价写在发布记录里：文本嵌入与重排吞吐不变，图像嵌入会慢一些。可复现除了写报告，对测试与排查也有用。我没有复现它的吞吐与 top-k 稳定性数据，而且单靠这个设置不能证明完全确定性。
• 解析任务做两次一致性检查。 解析前比对磁盘文件与扫描记录，写回前再比一次；内容变过的文件留给下一轮，只改了修改时间的按哈希判断——所以重试和全量重解析不会被误挡。
• 图谱能从中断里恢复，而且有次数上限。 进程死掉的构建由下一轮扫描标失败；整机断电中断的全量构建在同一版本下续跑，最多两次——上限本身就是一种诚实，避免无限重试耗资源。
• 关系不能当证据。 附带那份 24KB 的检索技能规定：结果分七种标签（来源、事实、页、实体、关系、邻域、邻域关系），后续命令用短引用指回结果而不用抄 ID；超一页就翻页读完再用；只有来源、事实、页可以作为结论依据，图谱关系只是「线索」。把「别拿关系当事实」写成操作纪律，比写进设计文档有用。
• 权限边界自承不足。 默认把控制台绑在 localhost，存储与模型服务只听回环，README 提醒：只听回环并不能防住同一台机器上浏览器里打开的网页。我没有审计它的鉴权、浏览器来源校验或完整访问边界。

和同类比：它不自己造检索组件，项目的价值在编排与边界——谁负责什么、证据怎么标、什么时候能下结论。可核的两条差异是「检索侧不生成」和「批不变的检索」；同类自托管 RAG 是否也把「重复查询结果一致」当默认目标、是否给图谱关系标注「不可当证据」、是否把解析与写回做成两次校验，我都没有逐份去读，这三条是可拿去对照的维度。

最近更新：v0.2.1（2026-10-22）——批不变检索；同一处短命中旁边的拼接片段在来源里只出现一次；解析两次一致性检查；死进程图谱构建标失败、断电中断最多续跑两次；夜间清理回收无人引用的解析缓存；路径匹配不到文档时明确说明路径写法而不是返回空。10-20 补了作者在 DGX Spark 上的实际部署页与「Mac 用云盘同步、或用 NAS 做入口」的做法。

适合谁：手里有一堆会变的文档（合同、政策、产品资料、会议记录）、又要求答案必须能指回原文的团队。前提是能接受一套 Docker 编排：Qdrant、OpenSearch、Neo4j、MinerU 一起上，资源需求随模型与语料规模变。从组件清单看，部署工作量大于单一检索进程；我没有把它与自建栈的资源占用和运维成本做过对比。许可证 MIT，依赖与模型权重各按自己的许可。

我的看法：⭐⭐

核验：读了 README、v0.2.1 发布记录、最近 6 条提交，以及仓库内 skills/carrel-search/SKILL.md；没有部署。

5. Renhuai123/ziwei-doushu ⭐ 6,975 · TypeScript

GitHub：https://github.com/Renhuai123/ziwei-doushu

一句话：紫微斗数排盘引擎，加上一套由引擎确定性生成的解读语料——67.5 万张命盘、877 万段解读、约 204 亿字。

它是什么：两件东西装在一个仓库。一是排盘引擎（纯 TypeScript，含四化飞星、1100 多行格局规则、三本古籍原文、14 主星 × 12 宫位的结构化知识）；二是用它批量生成的语料：覆盖公历 1950–2026 年每一个真实日期 × 12 时辰 × 男女，共 674,976 张盘，每张盘 13 个维度，合计 8,774,688 段、解压 56.6GB、压缩后只有 161MB（zstd，按年切 77 个文件，可以只下需要的年份）。2026 年 5 月建仓，9 月那次把积压 issue 从 18 条清到 4 条（现在 6 条）；10 月初那次大修把排盘核心从 181 行扩到 641 行、新增 8 个模块共 1367 行，并补上仓库此前完全没有的测试。

值得注意的地方：

• 语料被描述为不经模型推理的确定性规则文本。 解读由「引擎 + 断语库」确定性生成，数据集还带一个内容版本号与线上对齐。这支持对固定输出做回归校验，但不能验证占星预测的有效性，也不能证明每一条输入与规则都正确。
• 口径做成开关，而不是替用户选边。 闰月有四种归法可配（归前月、归后月、按日切分、按本月）；星曜亮度七档，不同流派（含主流软件的不同版本）的判法也是开关；晚子时（23:00–23:59）换日策略可切。这是对「一个流派一个软件、互相不认」的正面回答。
• 回归测试覆盖了指定的排盘约定。 npm test 跑 768 张盘，覆盖紫微铁律、1986–1991 年中国夏令时、立春边界、红鸾天喜、样本时辰一致性、时辰序号边界、日期合法性、同宫双四化；每次 push 与 PR 在 Actions 上跑。10 月起引擎开始直接拒绝不存在的公历日期。
• 授权分四层，边界写得比功能清楚。 代码 MIT；数据集按项目表述为 CC BY 4.0（需标注来源）；具体以数据集自身的许可与排除条款为准；三本古籍属公有领域；倪海厦讲课原话 1848 条（每条带视频时间码）单独走「署名—非商业—相同方式共享」，且明确数据集里引用的原话不在数据授权内。
• 「不开源什么」列成了表。 开：引擎、公版古籍、结构化知识、Demo 界面、两套数据集。不开：断语库（仓库里是占位实现）、AI 解读提示词、后端接口、用户与支付系统、防刷与水印。
• README 把 Demo 代码与线上系统分开说明。 排盘页 75 行 vs 线上 1227 行、解读面板 467 vs 5088、命盘方格 285 vs 1334。README 直接写「Demo 画得出盘，但给不出线上那套解读」，另单独披露 51.8 万条样本里有 2,520 条（0.49%）是不存在的日期。这个分母与上面 674,976 张盘的语料不是同一个；承诺下一版修好，不等于已发布修正版。

和同类比：底座不是从零写的，技术栈里写着基于 iztro 与 lunar-javascript，所以差异要看叠在底座上的口径层。它列了六项：真太阳时校正（经度差加均时差）、1986–1991 年中国夏令时、四种闰月口径、晚子时换日、亮度七档与流派开关、十二神煞分层起法。我核了两边 README：iztro 公开的是全局配置与插件机制，用来做四化表、亮度表的流派差异，README 里没有真太阳时与中国夏令时这两项；这套引擎把它们各自做成独立模块，出生地经度表还补到了省直辖县级单位与新疆兵团各市。iztro 源码里是否另有实现我没有读，所以只能说「README 层面这两项是它补的」。

最近更新：v4.0 数据集（2026-10-15）——比上一版体积增 71%、每张盘解读字数从约 2.1 万增到约 3.0 万；项目称发布前把 77 个文件逐个解压并与原始数据逐字节比对。我没有重复这些校验。项目称断语已按出处逐句核对：查不到出处的引文删掉或换成逐字可查的原话，不会发生的四化相关句子删去，古籍引证从 244 处增到 405 处。10-20 把亮度默认切换到《斗数全书》并补齐杂曜亮度，用 5 张金标准盘逐宫核对。

适合谁：想研究或二次开发紫微斗数、又不想从零写历法与排盘逻辑的人；需要一批结构一致的领域语料做检索或微调实验的人（674,976 条输入输出配对，许可允许商用）。要注意：解读是确定性的，别指望它「更像人」；商用版的关键资产（断语库）不开源，想自己做解读得自己写规则；讲课原话那部分不许商用。

我的看法：⭐⭐⭐

核验：读了 README 全文、v3.0/v4.0 与引擎三次发布记录、最近 6 条提交；另读了 iztro 的 README 用于核对底座差异；没有安装。

速览

本期观察

• 技能文件开始被当成有格式规范的交付物。 两个完全不相干的项目在写同一件事：一个规定技能描述要当路由键、正文固定六节、一个技能一个面；另一个在技能里规定「超一页就翻页读完」「关系只能当线索」。共同前提是技能是按需加载的索引，不是提示词堆；正文更长、描述更宽都需要实测触发与上下文预算，长度本身不能说明触发是否出错。

• 几个项目都写了可复现或状态恢复机制。 有项目称为了让同一查询结果更稳定而压低了部分环节的吞吐，有人坚持 204 亿字语料不经模型生成，有人这周的更新一半是「状态怎么恢复、机器移除后怎么清理」。三个方向不同，问的是同一个问题：出问题时，你能不能把状态复原。

• 公开失败案例有助于决定测什么。 一张多语种表里，中文错误率 1.1% 和阿语 13.0% 并排；一份 README 里，Demo 与商业版的逐页行数差直接列出来，还附上「这批样本里 0.49% 是不存在的日期」。这些披露暴露的是测试用例，不能证明整体成熟度，也不能证明其余样本正确。

• 「支持 N 种语言」和「每种语言都能用」是两个数。 覆盖面看总数，选型看单列。这一期最容易被误读的就是这一条：上线语种数要看分语种结果与目标负载，这张表本身不足以给出可辩护的可部署语种数。