开源雷达 · 2026-10-23：Agent 多了以后，先解决它们互相踩脚

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

1. feder-cr/git-ai ⭐ 966 · Go

GitHub：https://github.com/feder-cr/git-ai

一句话：为并发 Agent 写入设计的 Git 服务端，落地走 compare-and-swap，配合服务端批处理。

它是什么：git-ai 是一个 Git 兼容的服务端加 CLI。它的设计蓝本是 Anthropic 内部的 Scion，后者只在一篇公开文章里描述过；git-ai 是那份公开设计的独立实现，作者在 README 里写明与 Anthropic 无隶属关系。它的起点是 GitLab 的 Gitaly（MIT），项目方称上游 RPC 保持兼容，这一点我没有测。活跃度是个信号：2026-10-15 建仓当天发 v0.1.0，10-18 发 v0.2.0，10-20 发 v0.3.0，10-22 发 v0.3.1，一周内四个版本，贡献者 5 人。

值得注意的地方：

• 落地不排队。 并发客户端遇到冲突时，往往会自己 rebase 再重试 push。git-ai 的 UserLand 把变更 rebase 到当前 tip，用一次 CAS 落地，同一分支上的并发落地会被批处理成一次引用更新。作者用同一个服务端、只关掉批处理做对照（一台 16 核机器、两次运行、50 个 Agent 各落 5 个变更、其中 20% 故意冲突）：成功落地 100–106 对 200，每次成功落地的尝试次数 26.5–28.7 对 1.0，每分钟落地 264–385 对 1,487–1,944。没落地的 50 个正是故意造的冲突（这轮没接 resolver）。
• AI 解冲突只是提案。 这是我觉得最值得抄的一条：冲突交给一个可选的 resolver，但模型的解只有在你自己配的 verify.command 对「即将落地的那个确切 tree」跑通之后才会自动落地，否则把冲突包连提案一起退回给 Agent。服务端从不调用语言模型；按文档的写法，这个 resolver 是可选的，也不绑定供应商。验证命令通过，只说明它跑过的检查通过了。
• 历史查询变成服务端 API。 blame、路径历史、祖先、代码搜索都在服务端算并按 commit 记忆化；客户端保持在线，只取需要的对象或稀疏目录。
• 存储核心是数据库加对象存储。 每条变更写进 SQLite 或 PostgreSQL 的 changeset（WAL），每个引用一次 CAS，pack 放对象存储；按设计，服务节点是无状态缓存；跨节点扩展我没有实测。
• Agent 是一等用户。 每个 Agent 独立 token、RPC 白名单、分支策略；changeset 日志记下操作与 actor。

和同类比：这里的对照不是和某个竞品，而是和「经典 Git 托管 + 每个 Agent 客户端重试」的写路径比——差别在谁负责串行化。作者自己跑的对照实验指向同一结论（尝试次数 27 比 1），但这是项目自测、用项目自己的脚本，不是第三方复现。

最近更新：v0.3.1（10-22）修了一个真 bug——UserLand 原来按 git 的 revision 规则读分支，缺 refs/heads/x 时可能解析成同名 tag 或远端跟踪引用，甚至把「落到一个不存在的分支」答成 already_landed；现在按精确引用名查。同版让 CLI 和 SDK 支持 Windows（服务端仍只 Linux）、减少 land 路径上的 fsync。v0.3.0（10-20）补完存储核心（checkpoint、GC、hydration 的完成处理）。

适合谁：团队里已经有多于一个 Agent 同时改同一个仓库、并且开始被「谁把谁的 push 顶掉了」折磨的人。作者自己在 LIMITATIONS.md 里写得清楚：它不是托管产品（没有 Web UI、issue、MR 评审、CI），不是 GitLab 替代品，也不是安全边界——访问策略是本地配置，改得动配置就改得动谁可以写哪儿，共享 token 等同管理员凭据。四个版本只用了七天的早期项目，按这个节奏，1.0 之前接口我预期还会变。

我的看法：⭐⭐⭐ 想法比代码更值钱，值得读它的设计文档，不建议现在押生产。

核验：读了 README、LIMITATIONS.md、四个版本的发布记录和最近提交，没有安装。

2. openqodex/openqodex ⭐ 790 · TypeScript

GitHub：https://github.com/openqodex/openqodex

一句话：push 之前在你的编码 Agent 里跑一遍代码审查，写代码的那个 Agent 默认不能审自己的代码。

它是什么：OpenQodex 装在本地，从终端或 Agent 里启动，审查对象是「还没 push 的 commit 加全部未提交改动」。第一段是 22 个不带模型的扫描器，覆盖密钥、代码安全问题、依赖漏洞、lint、GitHub Actions、Dockerfile/Terraform/K8s/CloudFormation、SQL 与迁移，只保留落在改动行上的发现；第二段起独立的 Claude Code 或 Codex 进程做审查，用你自己的登录，项目本身不需要账号或 API key。2026-10-02 建仓，10-10 v0.12.0，10-15 v0.13.0，4 位贡献者。

值得注意的地方：

• 引文必须过脚本。 finder 会话读改动的每一部分、提候选时必须附一句被引用的代码，脚本拿每句引文回真实代码里核对；verifier 会话再逐条确认或反驳，每条都要给理由。脚本还查两件完整性：每个扫描器的发现是否都被回应、每一行改动是否都交给了 reviewer。派了人、引文对得上，不等于 reviewer 找全了 bug。
• 没跑完就说没跑完。 任何阶段缺失，review 打 Review incomplete 并列出缺什么，退出码 2。
• push gate 知道自己不知道什么。 Agent 内的 gate 不知道一次 push 会送什么，普通 git push 时只能问「当前工作有没有通过的审查」，其它 push 命令直接说无法判断；init 另装的 pre-push hook 才按这次 push 实际送的 commit 检查。默认两者都只警告，配了 review.block_on_severity 才真拦。
• 基准把弱项一起放出来。 项目自报的植入 bug 集（dev split）：Claude Code 做 reviewer 时问题召回 129/153（84.3%），每次审查 $0.0870；Codex 115/153（75.2%）；只用扫描器 32/51（62.7%）。但同一份 README 里 AACR-Bench（真实 PR）那一行难看得多：语义精度 22.8%、语义召回 5.2%、F1 8.5%、噪声率 77.2%，并标了「recall 尚未裁定」。
• 自定义扫描器要人工批准。 配置里写 GitHub 地址后必须 openqodex trust，下载进隔离目录、展示将执行的命令、问 yes/no；条目改过要重新批准。

和同类比：可以拿来对照的两种做法，一是 CI 里的 review bot，二是编辑器里的行内建议。OpenQodex 把审查放在 Agent 的写与推之间，并且强制审查者与被审者分离、引文可核、未回应即视为未审完。我没有横向跑过别家的审查器，所以这里只写机制区别，不做效果排名；「84% 召回」也只在它自己构造的植入 bug 上成立，真实 PR 那一栏的召回与噪声都还不支持把它当唯一门禁。

最近更新：v0.13.0（10-15）允许仓库所有者用 review.instructions_files 指定团队规范文件，审查简报引用它们、记录提供了哪些与省略了哪些，并把 finalize 绑定到这些文件的原始内容（默认不读任何约定文件）；同版把每轮修正存进 rounds.json，被检查驳回、下一轮又漏掉的发现能显示出来。v0.12.0（10-10）可以作为 Node 库导入，preinstallScanners 装完逐项自检版本、运行时，并用一个极小输入跑真实工具确认能出结果。

适合谁：用 Claude Code 或 Codex 写代码、又在乎「谁审的」这件事的人。约束要看清：Node 22+、只测过 macOS 与 Linux（没有 Windows/WSL 的测试），Cline、Cursor 能发起审查但不能当 reviewer；没有 reviewer 时 review 报 Full review unavailable。隐私上，项目声明它自己不收遥测、扫描器不发代码，但 reviewer 会把改动送到你登录所用的模型服务；--offline 能关掉 semgrep/osv-scanner/kubeconform/cargo-deny 四个联网扫描器，关不掉 reviewer 那一路。

我的看法：⭐⭐⭐ 可以拿它当一道额外的审查步骤试用；它自己报的真实 PR 分数，还不足以让它独当门禁。

核验：读了 README、docs/privacy.md、v0.12.0 与 v0.13.0 的发布记录、最近提交，没有安装。

3. LodyAI/Lody ⭐ 1,536 · TypeScript

GitHub：https://github.com/LodyAI/Lody

一句话：给团队已有的编码 Agent 加一层共享工作台，机器接进来，会话可以分享、可以从手机派活。

它是什么：Lody 不训练模型、不提供 Agent。每台机器跑 npx lody daemon start 接进工作区，本机的 Claude Code、Codex、Kimi、OpenCode 等 ACP 兼容 Agent 都能用；桌面端、手机、web、CLI 是同一个工作区的四个入口。会话可以被队友打开看完整记录、运行状态、文件和 diff，权限请求能在手机上批。2026-08-07 建仓，两个月做到 57 位贡献者、4 个 GitHub Release（v0.100.0 于 09-24、v0.104.0 于 10-08），283 个 open issue。

值得注意的地方：

• 接已有的 Agent 和机器，不换掉它们。 你继续用本机的订阅、登录、模型和权限模式；机器默认私有，owner 主动分享才可见。
• Agent 之间互相派活。 Lody 给 Agent 一组工具：创建或复用别的会话、读状态和历史、发后续指令、取消运行中的工作、把结果拿回来。于是一个会话可以当协调者，把排查、实现、测试拆给并行会话；子会话独立，但保留「由谁创建」的关系，跨会话可以 @ 引用。
• 并行靠 git worktree 隔离。 每个会话可以有独立 worktree，把改动分开，这并不构成安全隔离；diff、终端、预览都在标签页里，PR 状态与 CI 贴在产出改动的 Agent 旁边。
• 协作状态用 CRDT。 用 Loro 栈（Loro + Flock）表示和同步协作状态；packages/e2ee-core 是端到端加密库（签名账本、密钥分发），README 明确标注尚未接进产品。
• local-first 是方向不是现状。 README 自己写「仍在走向完整 local-first」，而 daemon start 会打开一个登录链接、把机器接进工作区，这一步走的是它的线上服务。

和同类比：一端是各家 Agent 自带的界面，另一端是替你把 Agent 分工定死的编排框架。Lody 的定位在中间：不替你决定怎么分工，只给 Agent「创建子会话、读状态、取结果」这组工具，协调逻辑留在 Agent 自己的上下文里。从仓库能看到连接与运行 Agent 的代码在 apps/cli，加密库在 packages/e2ee-core（还没接进产品）；代码库其余部分有没有别的工作流机制，我没有核。

最近更新：v0.104.0（10-08）加了会话内文档查看器与 PDF 控件，把每个模型的 effort/Fast 支持存进独立能力行，CLI 用请求者身份提交（PR #1145 自标 risk:high）。v0.100.0（09-24）是「只读实时会话分享」的起点（PR #539，同样自标 risk:high）。10-23 主线在修磁盘写满后仍写仓库、CLI 退出时的 EPIPE 异常风暴。

适合谁：几个人共用几台机器、Agent 跑在不同机器上、又想互相看得见对方在干什么的小团队。要先接受两个前提：登录要走它的线上服务，且加密层还没进产品。283 个 open issue 本身说明不了稳定性；长时间运行的会话我没有测。

我的看法：⭐⭐ 模型值得借，但今天的形态是「云工作区 + 本地 daemon」，不是纯本地。

核验：读了 README、三个版本的发布记录、最近提交与仓库结构，没有安装。

4. browseros-ai/BrowserOS ⭐ 14,060 · TypeScript

GitHub：https://github.com/browseros-ai/BrowserOS

一句话：一个仓库两个产品——neo 是给 Agent 用的第二个浏览器，BrowserOS 是给人用的 AI 浏览器。

它是什么：AGPL-3.0 的 Chromium 分支（README 标版权归 Felafax, Inc.），一个 monorepo 里并行两个产品。neo 把浏览器做成一个 MCP 端点：claw-server（Rust）暴露 MCP 与 JSON API，Claude Code、Codex、Cursor、VS Code、Zed 等从外部连上来，在各自的标签里干活，你在新标签页看实时 dashboard，或者事后拖进度条回放整个会话。建仓 2025-05-18，22 位贡献者，288 个 Release——这个数字要读懂，它是多组件分通道发版（claw-onboard、ext-browserclaw、claw-server 各发各的），不等于 288 个大版本。

值得注意的地方：

• 跑在 127.0.0.1，用你已有的登录态。 README 说可以从 Chrome 导入登录、书签和扩展，复用已有账号；会话、截图、历史落在 ~/.browserclaw/。这和「新起一个空 Chrome 子进程」或「跑在机房 IP 上」是两种不同的取舍。
• 会话可回放。 每个会话在磁盘上存成可拖拽的视频，配一份逐步操作时间线，出问题能倒回去看是哪一步点错了。
• 并行标签。 同时派几个任务，每个 Agent 用自己标签，你继续在别的标签浏览。
• 托管与本地正在分家。 10-22 的 neo onboarding 版里出现 hosted mode for remotely driven Neo 和读会话的 hosted API（/v1）；10-23 的提交把 CAPTCHA 求解用开关限到 hosted mode，并单独构建带 CAPTCHA 的私有镜像。
• 遥测边界写得具体。 匿名产品用量事件（连接/断开、版本、系统）会上报；README 说这些事件不含 URL、页面内容、prompt、工具结果和截图，可以在设置里关掉。流量我没有抓包核过，这条说明也不覆盖模型或托管服务的全部数据流。

和同类比：可对照的做法有 CI 里新起一个浏览器、云浏览器，也有绑定某个 Agent 的浏览器。登录态能不能留住、能接哪些模型，取决于各自的具体配置。BrowserOS 的分野在「用你已有的登录态 + 用你已有的 Agent」：Agent 从外部经一个独立的 MCP 服务接入。架构上能看到这个连接点：claw-server 是独立进程，暴露 MCP 端点。项目方还声称同一个任务「用的 token 比 Claude 的 Chrome 扩展和 Codex 的浏览器少」，我没有独立测量、也没看到测量方法，所以只记为项目自述。

最近更新：neo onboarding v0.0.18（10-22）落地 hosted mode 与 hosted API，关掉所有产品的浏览器内登录；扩展 v0.2.41.0（10-21）把敏感填充值挡在审计账本之外；claw-server v0.0.77（10-21）加了带 noVNC 与 MCP 的 Docker 镜像、Linux arm64 通道，快照开始包含链接 URL。

适合谁：需要真实登录态、又不放心把账号交给云浏览器的自动化场景——发帖、对账、导报表这类。三个前提先算清：AGPL-3.0（具体义务取决于怎么使用、修改和分发，见许可证原文）；要有第二个浏览器 profile，登录态得重新导一次；验证码这块正在往托管侧收；选哪个版本，先看清那一版的本地/托管功能边界。

我的看法：⭐⭐ 复用账号和可回放的会话是有用的功能，值得核；近期加的托管功能，让部署边界要按版本看。是否整体从本地转向托管，我没有测。

核验：读了 README、三个组件的发布记录、10-23 的提交与许可证，没有安装。

5. labring/FastGPT ⭐ 29,893 · TypeScript

GitHub：https://github.com/labring/FastGPT

一句话：RAG 知识库加可视化工作流的 Agent 平台，自托管用 Docker 起，有专门针对知识库入库之后维护的功能。

它是什么：FastGPT 把「文档变成能问答的应用」拆成四层：知识库（多库复用、chunk 级编辑、QA 拆分、多种文件格式与 URL/CSV 导入）、检索（混合检索与重排、API 知识库）、编排（对话与插件工作流、Agent Skill 编排、双向 MCP）、运营（免登录分享、iframe 嵌入、对话记录标注、应用日志）。2023-02-23 建仓，近两个月里我读到六个版本。

值得注意的地方：

• 先落库、再索引，三态可查。 v4.17.2 把解析分块、图片导入、备份导入在解析完成后立刻落成可见数据行（全流程绑同一个 dataId），训练完成再把向量写回同一条；新增 parsed → indexing → indexed 三态，待索引数据在检索层天然不被召回，前端只读、后端拦住编辑删除，训练失败的数据可以直接改或删。这几条解决的是长训练周期里「没有数据可看、中断留下孤儿数据」。
• 升级被当成一等公民。 我看到的这几次发行说明都带三段：升级指南、镜像 tag、手动触发的迁移脚本。迁移脚本登记进系统后自动执行，用 lease 抢占避免多节点并发、带心跳检测。v4.17.2 一次带了两个迁移，并写明先后依赖。
• v4.17.0 是破坏性升级。 必须部署 AI Proxy 并配 AIPROXY_API_ENDPOINT 与 AIPROXY_API_TOKEN，OPENAI_BASE_URL 和 CHAT_API_KEY 被移除且不再生效，缺任一配置启动校验直接失败。同版加了 CSRF_ENABLED，以及内核不支持 seccomp 时的降级开关（明说会降低系统调用隔离）。
• 检索范围能按目录收。 在某个目录下搜索，范围自动收成该路径及子树，用内存分桶加层序遍历，带成环与最大深度/节点数截断保护。

和同类比：一端是纯 RAG 框架或库（自己拼检索链，灵活但要写代码），一端是托管型 SaaS 知识库。FastGPT 的位置是把知识库的运维细节做成界面和迁移脚本：索引三态、chunk 级修改、训练进度按处理模式分阶段、升级脚本自动登记与并发保护。这些机制给运维的人留下了可查的状态和升级步骤。它们在同样负载下和其他框架比如何，我没有测。

最近更新：v4.17.2（10-09）是上面那套数据落库与三态索引，外加 QA 拆分一对多优化（源数据复用为首条拆分项，其余叶子节点新建预落库数据，入队、写入、清理收在一个事务里）、模型切换与同义词重建只对已索引数据触发。v4.17.1（09-30）给应用发布版本加了资源权限快照，商业版管理界面并入主应用（旧路径不再保留）。

适合谁：要把一批经常改的文档做成「答案必须引用到具体条款」的问答系统、而且必须自托管的人。许可证这块要单独看：FastGPT Open Source License 写明在 Apache-2.0 之上加了使用与贡献条件。与使用相关的两条限制：做与 FastGPT 类似的多租户 SaaS 服务，未经书面授权不行；使用过程中不得移除或修改控制台的 LOGO 与版权信息。两条都是附加条件，所以光看许可证名判断不了某种部署是否被许可，要按自己的用途读许可证全文。另外它是重平台；只给一个场景配检索是否更省，取决于部署和运维成本，这一点我没有测。

我的看法：⭐⭐⭐ 把升级和迁移写清楚，这一点有用；整平台上之前，先估一下部署负担。

核验：读了 README、LICENSE 原文、v4.17.0 至 v4.17.2 的发布记录与最近提交，没有部署。

速览

本期观察

• 并发写入、任务归属和独立审查，需要分开的控制手段。 三个项目在同一个问题的不同层：git-ai 管同一个分支上的并发落地（自测 250 个变更从落 100 个变成落 200 个），Lody 管多个会话怎么分工，openqodex 管写的人不审自己的代码。这三个例子各自处理不同的协作边界，说明不了整个行业在往哪走。

• 这几个项目记录的，是审计链上的不同环节。 git-ai 的每条引用更新带 actor 进 changeset 日志；openqodex 的每轮修正进 rounds.json，每条发现没人回应就判审查不完整；BrowserOS 把敏感填充值挡在审计账本之外。三者记录的事件并不相同。结构化记录便于检查，但本身证明不了结果正确或完整。

• 这一批项目开始认真写「我不做什么」。 git-ai 的 LIMITATIONS.md 把自己不是托管产品、不是 GitLab 替代、不是安全边界写在最前面；openqodex 把真实 PR 基准上 8.5% 的语义 F1 原样放出来并标「尚未裁定」；FastGPT 把多租户 SaaS 与去 LOGO 两条限制写进 LICENSE 首屏。这些边界有助于判断适不适合自己；写了边界，不等于已经能上生产。

• 本地运行要逐项核功能。 Lody 明说还在走向完整 local-first、加密库尚未接进产品；BrowserOS 这两天把 hosted mode、hosted API 和验证码求解一起画进托管侧。看到「本地优先」四个字，先问一句：断网之后它还剩下什么。