项目简介#

把 AI 评审接进终端和 CI：读取 git diff，把改动的文件交给可配置的 LLM Agent，产出可以直接照着改的行级评审意见。Agent 有权读完整文件、检索代码库、查看本次改动中的其他文件——也就是把「评审一个 diff」变成「在仓库上下文里评审一个 diff」。除了评审 diff，它还有 ocr scan 模式，对没有有意义改动的目录或陌生代码库做全量文件审计。对使用者来说，门槛主要在于配置模型端点，工具本身是一个 CLI。

图：open-code-review 的 provider 选择界面（来源：仓库 README）

为什么值得关注？#

它把自己和「通用编码 Agent 顺手做 review」的路线明确分开，并给出了可核对的数字：README 的统计是内部 20K+ 活跃用户、3M+ 真实任务、npm 近 30 天 329K+ 下载，AACR-Bench 上 SEM.F1 25.10%；在 1,000 个 PR 的对比里，token 消耗约为 Claude Code 的 1/9（README 同时说明其 Recall 低于对方）。这不是「模型更强」的故事，而是「把评审做成专用工具链」的故事。热度上，它从上周周榜的 2,213 直接跳到 15,504，接近 7 倍。

项目观察#

定位清楚是它最大的优点：写码和验收是两种不同的工作，评审工具可以慢一点、但要稳、要能对齐行号、要能进 CI。对已经有评审流程的团队，它是很好的一层「机器初筛」；局限也很实在——Recall 偏低意味着漏检仍会发生，超大仓库的上下文成本需要自己掂量。别把它当成能替代人类评审的终局，当成第一道筛子更合适。

项目简介#

一个把 coding agent 变成安全审计员的 skill，流程分六个阶段：侦察（产出 architecture.md 与 coverage-ledger.json，标出架构、信任边界、输入面与已有证据）→ 覆盖驱动的狩猎（按 ledger 单元分派互相隔离的 hunter，并用 coverage critic 找缺口）→ 候选验证（每个唯一候选交给全新的 verifier 去尝试证伪）→ 结构化输出（把 confirmed / needs_validation / rejected 写进 findings.json，并按 report-schema.json 校验）→ 独立复核（由新 Agent 复核最终结论，重大替换要再过一次独立验证）→ 目标中立的报告。README 说得很坦白：它是 Cloudflare 漏洞发现 harness 的种子版本，后续长成了多阶段、全舰队规模的系统，官方博客《Build your own vulnerability harness》记录了这条路径。

为什么值得关注？#

这一周它几乎没有新代码，却拿下 14,864 的周榜新增——说明「Agent 技能的工程方法论」本身正在成为可传播的资产。它解决的是 AI 做安全审计最被诟病的两个问题：覆盖面不可证明、结论不可复核。用 ledger 记录覆盖、用独立 verifier 反复证伪、用 schema 约束输出，最后把「AI 说这里有问题」变成「记录链条说这里有问题」。这套结构对任何需要 AI 给出可审计结论的场景都适用，不只是安全。

项目观察#

这是方法论型项目，价值在流程设计而不是代码量：抄它的阶段划分很容易，抄它的严谨程度很难——独立验证、失败记录、schema 校验，缺一环就退化成「让 Agent 随便看看」。直接套到自家代码库时，范围界定、误报处理和人员分工仍要自己补。它更像一份可执行的检查表，而不是开箱即用的扫描器。

项目简介#

用纯 C 写的 MoE 推理引擎，零引擎依赖。它最核心的想法是把显存、内存和存储当成一个统一的多级层级来管（README 称之为 AI memory multitiering）：参数按热度分布在不同层级，缺点用流式方式补齐，从而让前沿级别的稀疏模型跑在消费级或异构硬件上。README 里给出的能力范围是 744B–2.8T 级 MoE，覆盖九个模型家族（GLM-5.2 / GLM-5.3 的 744B、GLM-5.3-Flash 321B、OLMoE 7B 等），同一套 coli chat / coli serve / coli web 前端。它自报的运行画面是：colibri v1.12.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU，ready in 32s，常驻 9.9 GB。

图：colibri 自带的 Web 界面（来源：仓库 README）

为什么值得关注？#

它明确承诺了一件事：默认策略下绝不静默改变模型精度或 router 语义，内存不够就牺牲速度，而不是悄悄换掉模型行为。这恰好戳中本地推理社区最痛的信任问题——「跑起来了，但不知道跑的是不是同一个模型」。工程上，纯 C 也意味着依赖少、可移植性好。周榜从 2,188 涨到 7,441（约 3.4 倍），说明「用便宜硬件跑大模型」这条需求始终有人等着被满足。

项目观察#

野心和速度都摆在那里：版本迭代到 v1.12.0，模型覆盖也在快速扩张。但它是典型的研究型项目——性能强依赖具体硬件、存储介质与参数分布，没有服务承诺，实际吞吐要自己端到端测过才算数。适合愿意折腾的本地部署玩家、把大模型搬下云的团队做技术预研；如果是生产环境的关键路径，请先做完整压测再说。

项目简介#

桌面端的 AI 编排器，自我定位是「The AI Orchestrator for 100x builders」。做法是把多个编码 Agent（Codex、Claude Code、OpenCode、Pi 等）并排放进各自的 git worktree 里跑，统一在界面里跟踪进度。功能面很宽：Parallel Worktrees、Terminal Splits、Design Mode、原生 GitHub 与 Linear 集成、SSH worktrees、给 AI diff 做标注、把文件直接拖给 Agent、Orca CLI，桌面端覆盖 macOS / Windows / Linux，另有 iOS / Android 的 Mobile Companion。MIT 许可。

图：Orca 桌面工作台与移动端（来源：仓库 README）

为什么值得关注？#

它把「同时开几个 Agent」从脚本技巧变成了有界面的工作流，而 worktree 隔离解决的是多 Agent 最容易翻车的地方——抢同一个工作区、互相覆盖改动。Mobile Companion 补上了另一个现实缺口：长任务跑起来之后，人总要离开电脑。连续两周周榜都在 5k+ 量级，说明这不是一次性曝光，而是已经形成使用习惯的产品。

项目观察#

Orca 自己不做模型，做的是编排与可见性层，因此它的价值上限与被编排的 Agent 生态绑在一起：上游 CLI 换接口、改默认行为，它就得跟着追。对个人开发者它很合适——重 GUI、重多任务并行；团队落地前建议先想清楚 worktree 与分支策略怎么和 CI、代码评审衔接，否则并行跑得快，合并起来照样堵。

项目简介#

腾讯开源的 LLM 知识框架，面向企业级文档理解、语义检索与自主推理，主要围绕三块能力组织：面向日常检索的 RAG 快速问答；一个 ReAct Agent，能自主编排检索、MCP 工具、租户级技能目录、会话持久化的 Docker / E2B / Cube 沙箱以及联网搜索来完成多步任务；以及 v0.8.0 新引入的 Wiki Mode——让 Agent 把原始文档蒸馏成一份自维护、互相链接的 markdown 知识库，带交互式知识图谱、手工编辑、修订历史与一键回滚。此外还有跨会话长期记忆、保留上传目录结构的树状视图、chunk 级编辑与修订历史，以及飞书 Wiki / 飞书云盘 / GitLab / Tencent IMA / Notion / 语雀等多源接入。

图：WeKnora 架构（来源：仓库 README）

为什么值得关注？#

企业知识库的痛点从来不是「检索不准」这一条，而是检索结果没人愿意维护。Wiki Mode 的思路是让 Agent 把问答产生的内容沉淀成可编辑、可回滚的文档资产，把 RAG 从一次性工具推向持续维护的知识结构。加上多源接入和沙箱执行，它明显是照着企业内部真实数据流设计的，而不是 demo。周榜从 1,302 涨到 5,242，约 4 倍，是本周加速最明显的项目。

项目观察#

功能密度高是优点，也意味着部署、权限与治理成本不低：沙箱、多源同步、租户技能目录，每一样都需要有人管。仓库同期有 593 个未关 Issue，提醒我们它仍处在快速迭代期，升级前值得看一眼变更记录。适合有自建知识库需求、也养得起运维的团队；只想快速试一把 RAG 的个人，可以先从更轻的方案起步。