开源雷达 · 2026-10-22：技能管线与独立工作区

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

1. wshobson/agents ⭐ 41,493 · Python

GitHub：https://github.com/wshobson/agents

一句话：一套用 Markdown 写的插件、agent、技能和命令，经适配器分发到七种编码工具。

它是什么：仓库里有 94 个插件（92 个本地、2 个外部条目），下面挂 202 个 agent、185 个技能、105 个命令，全部按 Claude Code 的插件格式写成一份源。安装到 Codex、Cursor、OpenCode、Antigravity、Copilot、Pi 时不是复制文件，而是由适配器生成目标格式。91 位贡献者，建仓于 2025 年 7 月，最近一次提交在 2026-10-17。

值得注意的地方：

• 生成与校验也是这套东西的一部分。 同源生成之外还有 make validate STRICT=1、make garden 和一个不调模型的静态评分器，设计目的是检查 185 个技能在七个工具上是否一致；这些检查我没有跑过。只给 Markdown 加安装说明也能算一个技能合集；它在这之上还有生成、校验与能力矩阵。
• 被目标工具的限制逼出来的细节。 Codex 路线下，生成副本会把超长技能正文拆成引用文件，塞进 8 KB 预算；原生安装则直接读原始正文。
• 模型别名统一写、按工具映射。 源文件里写 opus、sonnet、haiku、fable、inherit，适配器负责落到各家设置，部分 inherit 会被固定成默认值。
• 对自己的评测有保留。 静态检查之外还有 LLM judge 与 Monte Carlo 两层，README 明说这两层是实验性的、未用人标校准，分数只代表模型评估，不证明任务在真实项目里能成。

和同类比：它能确认的差异是「生成层 + 静态校验 + 各工具能力矩阵」这三件同时存在。其它技能合集是否也有等价物，我没有读对方的一手材料，不下判断；要比较的维度就是这三项，加上是否有可回退的版本标签。

最近更新：没有正式 Release，跟 main 走。2026-10-15 一天内合并了 5 个修复：reflog 过期说明、Cypress 与 Playwright API 纠错、monorepo 管理更新到 Turborepo 2 与 pnpm workspaces；10-17 修了文档生成会覆盖 ADR README 的问题。

适合谁：同时在两种以上编码工具之间切换的人，收益最大；只用一种工具、只想要几个技能，用 gh skill install 或 npx skills add 单独装更省事。MIT 许可，外部插件各自有许可。没有版本标签意味着升级等于跟最新 main。

我的看法：⭐⭐⭐ 内容可以慢慢挑，产线思路值得直接借。

核验：读了 README、最近提交，没有 Release 可读，没有安装。

2. OrchestratorInc/agent-orchestrator ⭐ 13,466 · Go

GitHub：https://github.com/OrchestratorInc/agent-orchestrator

一句话：把多个编码 agent 放进一个本地工作台，每个任务独立工作区，看板按 PR 与 CI 的真实状态归位。

它是什么：桌面应用加本地 daemon 的编排台。一个 worker 等于一个任务、一个 agent、一个隔离工作区；Git 任务给独立分支与 worktree。项目级 orchestrator 是常驻的规划 agent，管方向、优先级和顺序，worker 管实现、测试、提交、开 PR。131 位贡献者，2026 年 2 月建仓，10-21 发布 v0.14.4，同日还发了两个 nightly 构建。

值得注意的地方：

• 看板跟随仓库状态。 Working、Needs you、In review、Ready to merge 四列由 session、PR、CI、review 状态算出来；Needs you 包含阻塞、缺输入、CI 失败、被要求改、信号丢失。
• 失败要回到原 agent。 CI 报错与 review 意见可以送回拥有该任务的会话，不用新开会话重新解释背景。
• 隔离有粒度，而且写明了。 临时浏览器 profile 每个 worker 一个；命名 profile 则刻意复用 cookie 与 storage。worktree 隔的是改动，不是安全沙箱的证据。
• 遥测边界写清楚。 默认采集安装 ID 与 GitHub 用户名，登录云服务再加用户 ID 与该账号邮箱；声明不采代码、prompt、对话与凭据，设置里能整体关闭。
• 发布与问题记录。 仓库有 971 个未关 issue，稳定版与 nightly 并行发布；单凭这些数字判断不了可靠性。

和同类比：与「多开几个 agent 终端」相比，它多了三件结构性东西：分支级隔离、以版本控制事实为准的状态机、持有项目记忆的规划层。与其它看板式编排工具的逐项差异，我没有读对方一手材料，列为待比较项：是否强制 worktree 隔离、状态是否由 CI/PR 推导、失败能否回到原会话。

最近更新：v0.14.4（2026-10-21）支持会话运行中更新 harness、撞到用量上限后自动恢复并在重置后续跑、桌面内嵌浏览器改为流式预览；10-22 又合并了集成另一种 agent 终端界面的提交。

适合谁：手上同时跑三个以上编码 agent、并且被分支冲突和「不知道哪个会话在干什么」折磨过的团队。Apache-2.0。桌面端覆盖 macOS、Windows、Linux；我会先在非关键任务上试用，再考虑依赖它的恢复行为。

我的看法：⭐⭐ 我喜欢这个状态驱动的看板；恢复与长时间运行的稳定性我没有测过。

核验：读了 README、发布记录与最近提交，没有安装桌面端。

3. trailhq/Trail-Code ⭐ 10,615 · TypeScript

GitHub：https://github.com/trailhq/Trail-Code

一句话：给编码 agent 一张本地代码地图，外加一份可以随仓库提交的「学习记录」。

它是什么：原名 graft，2026 年改名后分成两层。代码地图用 tree-sitter 解析仓库，得到文件、函数与调用关系，不调模型、不联网，未提交的编辑也会触发刷新。学习记录存的是会话里想清楚的事和用户纠正过的做法。36 位贡献者，2026 年 7 月建仓，10-21 发布 0.23.1。

值得注意的地方：

• 两层分工说得准。 地图回答「东西在哪」，学习记录回答「为什么是这样、这里该怎么干」。README 的判断是：只给地图的 agent 还是会把队友做过的决定再推翻一次。
• 学习记录按「给谁看」分流。 README 把个人偏好放在 ~/.trail，不进仓库提交；关于代码的决定进仓库的 .trail/，跟着代码走，队友的 Claude Code 在没装的情况下也能读；团队级空间在 README 里标着「soon」，尚未可用。
• 冲突提前到动作之后。 改了队友开着的分支也在改的代码，会立刻提示并说明是否冲突；trail check 还会在开 PR 前指出「你在推翻谁的决定」，引用是谁、为什么。
• 初始化会读你的历史。 trail init 读该仓库里过去的会话，把重复说过的话变成学习记录；装了 gh 还会读最近 50 个已合并 PR 的 review 评论，密钥脱敏是项目自述的做法。这一步用你自己的模型登录和额度，项目方不做代理；脱敏与数据流我没有审计，本地存储本身也不等于模型请求不出本机。
• 基准同时报告成本与正确率。 项目自报 162 次运行、两个仓库、每个任务三次：push 模式成本 0.0429 → 0.0292 美元（-32%）、未缓存输入 token 8,070 → 4,650（-42%）、工具调用 4.2 → 2.3（-46%）、延迟 39.8 → 15.8 秒（-60%），正确率两档都是 93%；pull 模式正确率到 98%，代价是速度。项目还报告了一组 SWE-bench Verified：50 个真实 issue，带地图解 33 个，不带 27 个；两组基准我都没有复现。

和同类比：它的差异在「把决定与代码结构分开存，并按个人/仓库分流」。其它代码图谱类工具是否也这样做，我没有读对方一手材料，列为待比较项；要比较的是：是否区分决定与结构、是否按人/仓库分流、是否提供推翻他人决定的检查。

最近更新：0.23.1（2026-10-21）修复学习记录要到打开文件时才送达的问题；10-22 新增 shell 解析、命令风险检查与学习记录字段，从「代码可审」往「命令也可审」扩；10-15 的 0.23.0 让初始化不再残留旧目录。

适合谁：用 Claude Code、Cursor、Codex 的多人仓库，收益来自「队友的决定不再被重复推翻」；单人项目里，团队协作那部分能力可能没那么重要。MIT。0.23.x 迭代快、281 个未关 issue，团队接入前先在一两个仓库试。

我的看法：⭐⭐⭐ 我会先为那些可审的决定文件试它，token 省不省另算。

核验：读了 README（含基准段）、发布记录与最近提交，没有安装。

4. semantica-agi/semantica ⭐ 14,175 · Python

GitHub：https://github.com/semantica-agi/semantica

一句话：把企业数据做成受本体约束的知识图谱，并把每个决定做成可检索、可溯源的对象。

它是什么：图原生的上下文层。多源摄入、实体感知切块、抽取、构图，再在图跑分析与因果推理，全程带 W3C PROV-O 溯源。本体侧支持 OWL、SHACL、SKOS；推理侧是前向链、Rete、Datalog、SPARQL，构图与推理都不需要 LLM。138 位贡献者，2025 年 6 月建仓，9-22 发布 v0.7.0。

值得注意的地方：

• 决定是一等对象。 每个 decision 可检索、可按先例查、可因果链接，不是日志里的一行文本。
• 确定性是卖点，也是约束。 构图、推理、溯源都不依赖模型；用 LLM 是可选项且供应商中立。代价是复杂语义得先写成规则或本体。
• 存储可换。 RDF 侧支持 Oxigraph、Blazegraph、Jena、RDF4J，属性图侧支持 Neo4j、FalkorDB、AGE、Neptune，项目称换后端不用改代码；后端之间是否等价，我没有实测。
• 边界写得很克制。 它只解释模型外部：喂进去的上下文、产出的决定、来源、关系、适用策略、执行轨迹；明确不暴露也不重建模型内部推理。
• 供应链做得实。 项目称 v0.6.8 起每个 release 带 SLSA 构建来源证明与 Sigstore 签名，.sigstore.json 随包发布；这些签名我没有验证。
• 性能数字自带口径。 v0.5.0 在 11.8 万节点图上节点搜索 24 ms → 0.004 ms（称 6,000×），去重与候选生成的数字注明来自 CHANGELOG 历史测量、不是自动化测试断言。

和同类比：与 Graphiti 相比（两边 README 都读了），Graphiti 强调事实随时间变化、增量更新不必全图重算、混合检索；Semantica 强调本体约束、规则推理、决定对象与合规导出。这两种侧重是文档里写的。溯源链记录的是输入与动作，不证明决定本身正确。谁更适合生产取决于检索与审计需求，我没有在同一数据上实测两者，不做优劣判断。

最近更新：v0.7.0（2026-09-22）把核心安装的直接依赖从 44 个降到 22 个，torch、spacy、faiss 等移入可选 extras；v0.6.7 加了 LangChain 集成、SAP OData 摄入器、Markdown 往返持久化与规则驱动的断言/撤回推理层；10-21 修了图片解析器的格式与体积上限、升级依赖修安全公告。

适合谁：受监管行业里需要回答「系统为什么这么决定」的团队，以及想把图谱与溯源自托管、不交给 SaaS 的企业。MIT，Python 3.10+。代价是本体建模与 RDF 栈的学习曲线，轻装安装只是「不装重依赖」，不等于轻量使用。

我的看法：⭐⭐ 方向正确，工程偏重，先借「决定即对象」的模子。

核验：读了 README（含边界声明、性能段）、发布记录与最近提交，没有安装。

5. vllm-project/vllm ⭐ 94,954 · Python

GitHub：https://github.com/vllm-project/vllm

一句话：开源 LLM 推理与服务引擎，一个 OpenAI 兼容端点就能把模型服务起来。

它是什么：伯克利 Sky Computing Lab 起家的推理引擎，仓库累计 3,835 位贡献者。核心是用 PagedAttention 管 KV 显存，配合连续批处理、chunked prefill、前缀缓存与多种量化把吞吐拉高。文档列出 200 多种模型结构与多种硬件后端；具体模型、后端与版本要逐个核对支持情况。v0.32.0 一个版本就有 814 次提交、363 位贡献者，其中 121 位是新面孔。

值得注意的地方：

• 接口不止 OpenAI。 同一进程还能出 Anthropic Messages API 与 gRPC；--api-server-count 大于 1 时按连接分到最闲的 API worker。
• 低精度 KV 在特定硬件上才铺开。 NVFP4 KV 覆盖 SM8x、SM12x、SM90，MiniMax-M3 稀疏注意力在 SM100 也支持。发布说明里 GLM-5.x 在 SM100 上默认 FP8 KV，KV 每 rank 显存减半，PR 自带基准是吞吐 +2.3–5.5%、首 token 延迟 +7–11%。
• 启动时间也在抠。 vllm download-kernels 预装编译好的 FlashInfer kernel；vllm preload --preload-autotune 让 autotune 表跨重启保温。
• 短请求并发有具体数。 --api-server-count 提升后，Qwen3-0.6B、32 输入 / 1 输出的短请求在 PR 自带基准里多 43–85% 的每秒请求数。
• 破坏性变更敢列。 v0.32.0 明确弃用 Python 3.10、默认收紧 CORS、移除 cascade attention，升级前必须读。

和同类比：从一手材料能确认的是广度：三种接口、200 多种架构、五类以上量化、跨厂商后端矩阵同时在一个引擎里。我没有读 SGLang、TensorRT-LLM 的一手材料，不作优劣判断；要比较的维度是同等硬件与模型下的吞吐与首 token 延迟、前缀缓存命中率、结构化输出与工具调用解析覆盖、以及升级破坏性。

最近更新：v0.32.0（2026-10-18）新增 POST /v1/systemone 处理结构化选择与打分问题并默认开启；新增通用 hf 工具与推理解析器，直接读 checkpoint 自带的响应模板；Model Runner V2 加了 GPU n-gram 投机解码、Elastic EP 与流水并行；安全侧修复了 chat template 资源耗尽、tokenizer 越界、P2P socket 耗尽三个已编号漏洞。

适合谁：要自托管推理、又不想自己写服务层的团队。Apache-2.0。要确认所选后端及设备内存能支撑该模型和负载；版本节奏快，升级前先读破坏性变更。它只解决模型侧，ASR、TTS 与网络延迟不在其中。

我的看法：⭐⭐⭐ 装起来最容易的一档，难的是选版本与量化口径。

核验：读了 README、v0.32.0 发布说明与最近提交，没有部署。

速览

本期观察

• 技能合集也需要维护机制。 在 wshobson/agents 里，同源生成、静态校验与能力矩阵给维护者一套可具体核对的东西，目标工具变了能查；这些机制本身也要维护。
• agent-orchestrator 让归属更容易看清。 独立 worktree、由 CI 推导的看板、失败回到原会话，这三件解决的是并行最常见的两种事故：改同一处、失败后找不到主人。
• Trail-Code 报的是成本与正确率的取舍。 它自报的 push 结果省 32% 成本、正确率持平；自报的 pull 模式正确率 98%，代价是更慢。把取舍摆出来，比只报最好看数字更有用。
• 审计与成本同时被工程化。 一边把决定做成可溯源对象，一边把 KV 精度和启动时间继续往下压。这是两件不同的要求。有用的评估应同时测服务成本与外部审计轨迹的完整度；一件不能推出另一件。