今日三荐：混合架构代码审查、Git 工作树并行与 S3 兼容对象存储 (2026)

今天这三个项目有一个共同做法：对外的接口借现成的，引擎自己写。

open-code-review 借的是 git 的差异与行级审查评论，模型那一侧对齐 OpenAI 与 Anthropic 的接口；引擎是确定性规则管道加一个带工具调用的 Agent。worktrunk 借的是 git 自己的 worktree 与 branch，命令用分支名寻址、磁盘路径由模板算出来；引擎是它自己的 CLI、钩子与 shell 集成。rustfs 借的是 S3 的 HTTP API，把兼容范围写成一张矩阵；引擎是 Rust 写的对象存储。

三个仓库在这两天都有动作。open-code-review 在 9 月 16 日连发 v1.12.3、v1.12.4 两个版本，9 月 17 日又发布 v1.12.5；worktrunk 在 9 月 17 日（北京时间）发布 0.78.0；RustFS 的 1.0.0 正式版在 9 月 16 日傍晚发布，9 月 17 日连发两个 1.0.1 预览版。worktrunk 与 rustfs 的主分支到 9 月 18 日早上还有提交，open-code-review 在 9 月 17 日晚上也在更新。1 2 3 4 5 6

1. open-code-review：确定性规则管道加 Agent 的混合代码审查

仓库：alibaba/open-code-review · Go · Apache-2.0 · 34.7k 星

这个工具来自阿里巴巴内部的 AI 代码审查助手，两年里在内部服务过数万名开发者，之后整理成开源项目。它读 git 差异，把改动过的文件交给一个可配置的大模型，再由带工具调用能力的 Agent 生成精确到行的审查评论；ocr scan 则不看差异，直接审查整个文件或某个目录，用来读陌生代码库。7

为什么今天看

9 月 17 日发布 v1.12.5，再往前一天，9 月 16 日发出 v1.12.3 与 v1.12.4。近十天内这个仓库几乎每隔一两天就发一版，主分支一直在改。1

v1.12.5 里既有新增的 Kimi Code 插件，也有对 Agent 预算控制的修复：--max-tokens-budget 现在在每一轮模型调用之前检查，而不再只在派发下一组任务时检查，超预算的组会拿到最后一轮提交发现的机会。同一批提交还处理了增量审查评论的重复上报。1 2

最值得拆的机制

把不能出错的步骤从模型手里拿走。 选哪些文件、过滤掉哪些文件、哪几个文件捆成一个审查单元（比如 message_en.properties 和 message_zh.properties 放进同一组）、每个文件匹配哪几条规则，全部由工程代码决定。每个文件组带着独立上下文并发生成子 Agent，改动再大也能保住文件覆盖率。7
规则匹配走模板引擎。 规则按文件特征匹配，模型每次只需要盯住少数几条有明确判据的规则，内置规则集覆盖空指针、线程安全、跨站脚本、SQL 注入这几类。工具集也是从生产环境的工具调用轨迹里筛出来的，参考了每个工具的调用频率、重复率以及新增工具对整条调用链的影响。想学「怎么把约束写进 LLM 工具」的话，这两处比提示词值得看。7
评论定位与反思单独成层。 通用 Agent 做审查最常见的毛病是位置漂移：问题说得对，标出的文件和行号却对不上。这个项目用独立的定位模块和反思模块来校正位置与内容。想弄明白它凭什么敢给精确行号，这一层就是入口。7

基准数字与一个明确的取舍

项目自己发了一份基于真实 PR 的基准：50 个热门开源仓库、200 个真实 Pull Request、10 种编程语言，由 80 多名资深工程师交叉标注出 1505 个真实问题，数据集公开在 Hugging Face 上。7 8

在同一个底层模型下与通用 Agent（Claude Code）对比，它的精确率（precision：报出的问题里有多少是真缺陷）和 F1 更高，消耗的 token 约为后者的九分之一，出结果更快；召回率（recall：真缺陷里被找到多少）更低。作者把召回率写成了有意为之的取舍——宁可少报，也不让开发者淹没在误报里。7

复现难度：低到中

门槛是一个可用的模型端点（内置多家服务商，也支持自定义的 OpenAI 兼容端点），加上 Git 2.41 以上。不想现在去申请密钥的话有一条零成本路径：ocr delegate preview 让本机已有的编码 Agent 自己执行审查，这个工具只负责选文件和解析规则，不需要配置模型。7

最小上手路径

npm install -g @alibaba-group/open-code-review
ocr config provider
ocr config model
cd your-project
ocr review

两个 ocr config 命令是交互式的，会依次让你选服务商、填密钥、选模型，并自动测一次连通性。装好之后，ocr review 在工作区模式下审查已暂存、未暂存和未跟踪的改动；换成分支区间就是 ocr review --from main --to feature-branch，审查单个提交是 ocr review --commit abc123；没有 git 历史的目录用 ocr scan --path <目录>。7

今晚的练习：拿一个自己写过的课程项目，先跑一次 ocr review，逐条核对它报出的位置是否真的落在你的改动上；再用 ocr review --format json --output result.json 存一份结果，改一处代码后重跑，比较两次报出的问题有什么变化。想读源码，README 给的例子是扫描 internal/agent 这个目录，可以从 Agent 循环和文件分组这两处看起。7

版本动作：用 v1.12.5。9 月 16—17 日的修复集中在预算控制、增量评论去重和路径校验，这几处直接决定长改动集上的稳定性。1

2. worktrunk：把 git 工作树变成和分支一样好用

仓库：max-sixty/worktrunk · Rust · MIT 或 Apache-2.0 · 7.9k 星

git 的工作树（worktree）能让同一个仓库同时检出多份代码，每个 AI 编码任务占一份，互相不踩对方。原生命令用起来很啰嗦：起一个新工作树要把分支名敲三遍，先是 git worktree add -b feat ../repo.feat，再是 cd ../repo.feat。worktrunk 把这个过程压成一条命令，作者的目标场景是同时跑五到十个编码 Agent。9

为什么今天看

9 月 17 日（北京时间）发布 0.78.0；往前一版是 9 月 9 日，大约每周一个版本。主分支最新一次提交在 9 月 18 日早上，内容是给交互式选择器补录演示，并修掉演示过程中暴露的几个 bug。3 4

最值得拆的机制

拿 git 已有的概念当主键。 工作树用分支名寻址，磁盘路径由一份可配置的模板算出来；所有接受分支名的命令，也接受该工作树所在的路径。给底层工具做上层封装时，这个决定值得抄：选一个用户已经熟悉的对象当入口，比发明一套新名字省掉一半学习成本。9
钩子把每个工作树的本地环境自动建起来。 创建工作树、合并前后、移除之前都能挂命令，用来装依赖、起开发服务器；wt list --full 会按分支列出 CI 状态和 AI 生成的改动摘要，模板过滤器 hash_port 能给每个工作树分一个独立端口，几个并行开发服务器就不会抢端口。9
子进程改不了父 shell 的目录，所以它装了一个包装函数。 wt config shell install 会在 bash、zsh、fish、nushell、pwsh 里装一个 wrapper，wt switch 才能真正把当前目录切过去——README 里写得很直白：shell integration allows commands to change directories。想弄清一条 CLI 的能力边界在哪，这是现成的例子。9

复现难度：低

一条安装命令就够，Homebrew、cargo、winget、pacman、conda-forge 都有包，不需要模型端点，也不需要额外服务。wt 本身是纯命令行工具，可以先把并行工作树跑顺，再决定要不要接 Agent。9

最小上手路径

brew install worktrunk && wt config shell install
cd your-repo
wt switch --create feature-a
wt list
wt merge main

wt switch --create feature-a 从当前分支新建分支和工作树，并直接切过去；wt list 列出所有工作树的状态；wt merge main 把当前分支压缩成一次提交、变基到 main 并快进合并，最后在工作树干净时删掉工作树和分支。要给并行 Agent 分发任务，用 -x 在切换后起一个程序，-- 后面的参数原样传给这个程序。9

wt switch -x claude -c feature-a -- 'Add user authentication'

今晚的练习：在一个练习仓库里开两个工作树，各改一个文件，然后跑 wt list，看差异统计、ahead/behind 和 CI 状态这几列怎么显示；再去读一遍 wt config shell install 装进 shell 的那个 wrapper，看它怎么把命令输出的路径变成一次 cd。这一处能解释很多「命令行为什么看起来不像普通子进程」的问题。9

版本动作：用 0.78.0。这一版有破坏性改动：钩子脚本收到的 JSON 换了键名（worktree 改成 worktree_path、repo_root 改成 repo_path、main_worktree 改成 repo、main_worktree_path 改成 primary_worktree_path），配置模板会在加载时自动迁移，但自己解析这段 JSON 的脚本要跟着改。同一版还修了几个丢数据的隐患：status.showUntrackedFiles = no 时不再把只放着未跟踪文件的工作树当成干净的直接删掉，继承 GIT_DIR 时 wt remove 与 wt merge 会检查正确的工作树，被 git worktree lock 锁住的工作树不再被删除。3

3. rustfs：用 Rust 重写 S3 接口的对象存储

仓库：rustfs/rustfs · Rust · Apache-2.0 · 32.8k 星

RustFS 是 Rust 写的分布式对象存储，对外提供 S3 兼容 API，另外支持 OpenStack 的 Swift API 与 Keystone 认证，目标负载是数据湖、AI 与大数据。它处处对着 MinIO 的部署体验做，许可证换成 Apache-2.0，不用 AGPL。10

为什么今天看

1.0.0 正式版在 9 月 16 日傍晚发布，成为当前标记为 Latest 的稳定版本；9 月 17 日又连发 1.0.1-preview.1 与 1.0.1-preview.3 两个预览版。主分支在 9 月 18 日早上还有提交，一处修纠删码存储的位翻转写入，一处让扫描器在换主之后能续跑检查点。5 6 11

最值得拆的机制

兼容性用矩阵管理。 「S3 兼容」到底兼容到什么程度，仓库里有一份兼容矩阵逐项标注；MinIO 的磁盘格式兼容挂在 rio-v2 特性后面，属于预览，而且 MinIO 加密过的对象读不出来。判断任何一个号称兼容某协议的项目，先翻它的兼容矩阵与不支持项列表，这一步比读 README 第一段快得多。10 12
纠删码集合与数据修复是存储侧的核心。 数据按纠删码集合（Erasure Set）切分：一个对象会被切成数据块和校验块分散到不同盘上，坏掉其中几块仍然能还原。配上位翻转保护（bitrot protection，靠校验码发现磁盘上的静默损坏）、修复与扫描、对象锁（WORM，写一次读多次）和版本控制；存储池的扩容与退役各有一套流程。单机单盘部署只能当本地独立路径用，既不能原地扩容，也不能作为存储池加进已有集群——要换拓扑得新建一套部署，再通过 S3 把数据迁过去。这套规则跟着 MinIO 走，但自动选校验盘数的策略两家不一样。10
服务端能力按构建选项拼出来。 Swift API 与 SFTP 是可选的 cargo 特性，FTPS 与 WebDAV 在默认构建里；密钥管理服务（KMS）支持 Vault 的 KV2、Transit 后端以及 AWS KMS，另外两种后端明确只用于开发和测试。想看一个存储服务怎么把可选协议做成插件，这里是现成的样本。10

复现难度：中

跑起来只要 Docker 或 podman：一条 docker run 起服务，S3 API 在 9000 端口，Web 控制台在 9001 端口，数据与日志目录需要把属主改成 10001。读源码的门槛高一档，仓库有六千多次提交，工作区里分成 crates/、rustfs/、protocol/ 几块，顺着目录读容易迷路；建议从兼容矩阵里挑一个想确认的 API，反着找它的实现。10

最小上手路径

mkdir -p data logs && chown -R 10001:10001 data logs
docker run -d -p 9000:9000 -p 9001:9001 \
  -v $(pwd)/data:/data -v $(pwd)/logs:/logs \
  rustfs/rustfs:latest

不想用 Docker 的话，可以跑一键安装脚本 curl -O https://rustfs.com/install_rustfs.sh && bash install_rustfs.sh，或者用仓库根目录的 docker-compose-simple.yml 起 compose。10

服务起来后，浏览器打开 http://127.0.0.1:9001 进控制台建一个桶，再让任意 S3 客户端指向 http://127.0.0.1:9000：aws-cli、boto3、rclone 的 S3 后端都能连上。10

今晚的练习：用两个不同客户端（比如 aws-cli 和一段 boto3 脚本）对同一个桶各做一次上传、下载、列目录，比较两次请求的参数和返回的头；然后回控制台，看这个对象落在哪个池、哪些盘上。想验证兼容边界，就从矩阵里挑一个标着预览或者不支持的接口打一次，看它返回什么错，这比读文档更容易记住边界画在哪。10 12

版本动作：镜像用 README 给的 rustfs/rustfs:latest 或 rustfs/rustfs:1.0.1；1.0.1-preview.3 属于预发布，按预发布对待，读它的发布说明再决定要不要跟。单盘部署不能原地扩容，池布局另有兼容与回归测试文档，动扩容之前先看那份文档。10 11 13

怎么选今晚的第一条路径

你想练的主线	仓库与本期信号	最小条件	第一条可观察路径	主要限制
LLM 工具的分层设计：哪一步交给模型，哪一步交给代码	open-code-review · `v1.12.5`，9 月 17 日发布	Node.js、Git 2.41 以上，模型端点（delegate 模式不需要）	在自己的项目里跑 `ocr review`，改一处代码后重跑，比对两次结果	完整能力需要模型端点；召回率有意低于通用 Agent；Apache-2.0。7
git 内部结构与 CLI 的能力边界	worktrunk · `0.78.0`，9 月 17 日发布	一条安装命令，无外部服务	`wt switch --create` 开第二个工作树，`wt list` 对比两个工作树的状态	`0.78.0` 有破坏性改动（钩子 JSON 键名）；MIT 或 Apache-2.0。3
对象存储服务端：S3 协议、纠删码、修复	rustfs · `1.0.0` 正式版，9 月 16 日发布	Docker 或 podman	一条 `docker run` 起服务，用 S3 客户端传一个文件，回控制台看它落在哪	仓库体量偏大；单盘不能原地扩容；MinIO 加密对象读不出来；Apache-2.0。10

三个项目今晚的第一步都不需要 GPU，也不需要集群：ocr review 一条命令、wt switch --create 一条命令、一条 docker run。先跑出第一个能看见的结果，再决定晚一点往源码的哪一层读。

References

1
open-code-review v1.12.5 发布记录
github.com
2
open-code-review 最近提交
github.com
3
worktrunk v0.78.0 发布记录
github.com
4
worktrunk 最近提交
github.com
5
RustFS 发布列表
github.com
6
rustfs 最近提交
github.com
7
open-code-review README
github.com
8
AACR-Bench 数据集
huggingface.co
9
worktrunk README
github.com
10
RustFS README
github.com
11
RustFS 1.0.1-preview.3 发布记录
github.com
12
RustFS S3 兼容矩阵
github.com
13
RustFS 池布局兼容与回归测试
github.com

今天这三个项目有一个共同做法：对外的接口借现成的，引擎自己写。

1. open-code-review：确定性规则管道加 Agent 的混合代码审查

仓库：alibaba/open-code-review · Go · Apache-2.0 · 34.7k 星

为什么今天看

9 月 17 日发布 v1.12.5，再往前一天，9 月 16 日发出 v1.12.3 与 v1.12.4。近十天内这个仓库几乎每隔一两天就发一版，主分支一直在改。1

最值得拆的机制

把不能出错的步骤从模型手里拿走。 选哪些文件、过滤掉哪些文件、哪几个文件捆成一个审查单元（比如 message_en.properties 和 message_zh.properties 放进同一组）、每个文件匹配哪几条规则，全部由工程代码决定。每个文件组带着独立上下文并发生成子 Agent，改动再大也能保住文件覆盖率。7
规则匹配走模板引擎。 规则按文件特征匹配，模型每次只需要盯住少数几条有明确判据的规则，内置规则集覆盖空指针、线程安全、跨站脚本、SQL 注入这几类。工具集也是从生产环境的工具调用轨迹里筛出来的，参考了每个工具的调用频率、重复率以及新增工具对整条调用链的影响。想学「怎么把约束写进 LLM 工具」的话，这两处比提示词值得看。7
评论定位与反思单独成层。 通用 Agent 做审查最常见的毛病是位置漂移：问题说得对，标出的文件和行号却对不上。这个项目用独立的定位模块和反思模块来校正位置与内容。想弄明白它凭什么敢给精确行号，这一层就是入口。7

基准数字与一个明确的取舍

复现难度：低到中

最小上手路径

npm install -g @alibaba-group/open-code-review
ocr config provider
ocr config model
cd your-project
ocr review

版本动作：用 v1.12.5。9 月 16—17 日的修复集中在预算控制、增量评论去重和路径校验，这几处直接决定长改动集上的稳定性。1

2. worktrunk：把 git 工作树变成和分支一样好用

仓库：max-sixty/worktrunk · Rust · MIT 或 Apache-2.0 · 7.9k 星

为什么今天看

最值得拆的机制

拿 git 已有的概念当主键。 工作树用分支名寻址，磁盘路径由一份可配置的模板算出来；所有接受分支名的命令，也接受该工作树所在的路径。给底层工具做上层封装时，这个决定值得抄：选一个用户已经熟悉的对象当入口，比发明一套新名字省掉一半学习成本。9
钩子把每个工作树的本地环境自动建起来。 创建工作树、合并前后、移除之前都能挂命令，用来装依赖、起开发服务器；wt list --full 会按分支列出 CI 状态和 AI 生成的改动摘要，模板过滤器 hash_port 能给每个工作树分一个独立端口，几个并行开发服务器就不会抢端口。9
子进程改不了父 shell 的目录，所以它装了一个包装函数。 wt config shell install 会在 bash、zsh、fish、nushell、pwsh 里装一个 wrapper，wt switch 才能真正把当前目录切过去——README 里写得很直白：shell integration allows commands to change directories。想弄清一条 CLI 的能力边界在哪，这是现成的例子。9

复现难度：低

最小上手路径

brew install worktrunk && wt config shell install
cd your-repo
wt switch --create feature-a
wt list
wt merge main

wt switch -x claude -c feature-a -- 'Add user authentication'

3. rustfs：用 Rust 重写 S3 接口的对象存储

仓库：rustfs/rustfs · Rust · Apache-2.0 · 32.8k 星

为什么今天看

最值得拆的机制

兼容性用矩阵管理。 「S3 兼容」到底兼容到什么程度，仓库里有一份兼容矩阵逐项标注；MinIO 的磁盘格式兼容挂在 rio-v2 特性后面，属于预览，而且 MinIO 加密过的对象读不出来。判断任何一个号称兼容某协议的项目，先翻它的兼容矩阵与不支持项列表，这一步比读 README 第一段快得多。10 12
纠删码集合与数据修复是存储侧的核心。 数据按纠删码集合（Erasure Set）切分：一个对象会被切成数据块和校验块分散到不同盘上，坏掉其中几块仍然能还原。配上位翻转保护（bitrot protection，靠校验码发现磁盘上的静默损坏）、修复与扫描、对象锁（WORM，写一次读多次）和版本控制；存储池的扩容与退役各有一套流程。单机单盘部署只能当本地独立路径用，既不能原地扩容，也不能作为存储池加进已有集群——要换拓扑得新建一套部署，再通过 S3 把数据迁过去。这套规则跟着 MinIO 走，但自动选校验盘数的策略两家不一样。10
服务端能力按构建选项拼出来。 Swift API 与 SFTP 是可选的 cargo 特性，FTPS 与 WebDAV 在默认构建里；密钥管理服务（KMS）支持 Vault 的 KV2、Transit 后端以及 AWS KMS，另外两种后端明确只用于开发和测试。想看一个存储服务怎么把可选协议做成插件，这里是现成的样本。10

复现难度：中

最小上手路径

mkdir -p data logs && chown -R 10001:10001 data logs
docker run -d -p 9000:9000 -p 9001:9001 \
  -v $(pwd)/data:/data -v $(pwd)/logs:/logs \
  rustfs/rustfs:latest

服务起来后，浏览器打开 http://127.0.0.1:9001 进控制台建一个桶，再让任意 S3 客户端指向 http://127.0.0.1:9000：aws-cli、boto3、rclone 的 S3 后端都能连上。10

怎么选今晚的第一条路径

你想练的主线	仓库与本期信号	最小条件	第一条可观察路径	主要限制
LLM 工具的分层设计：哪一步交给模型，哪一步交给代码	open-code-review · `v1.12.5`，9 月 17 日发布	Node.js、Git 2.41 以上，模型端点（delegate 模式不需要）	在自己的项目里跑 `ocr review`，改一处代码后重跑，比对两次结果	完整能力需要模型端点；召回率有意低于通用 Agent；Apache-2.0。7
git 内部结构与 CLI 的能力边界	worktrunk · `0.78.0`，9 月 17 日发布	一条安装命令，无外部服务	`wt switch --create` 开第二个工作树，`wt list` 对比两个工作树的状态	`0.78.0` 有破坏性改动（钩子 JSON 键名）；MIT 或 Apache-2.0。3
对象存储服务端：S3 协议、纠删码、修复	rustfs · `1.0.0` 正式版，9 月 16 日发布	Docker 或 podman	一条 `docker run` 起服务，用 S3 客户端传一个文件，回控制台看它落在哪	仓库体量偏大；单盘不能原地扩容；MinIO 加密对象读不出来；Apache-2.0。10

References

1
open-code-review v1.12.5 发布记录
github.com
2
open-code-review 最近提交
github.com
3
worktrunk v0.78.0 发布记录
github.com
4
worktrunk 最近提交
github.com
5
RustFS 发布列表
github.com
6
rustfs 最近提交
github.com
7
open-code-review README
github.com
8
AACR-Bench 数据集
huggingface.co
9
worktrunk README
github.com
10
RustFS README
github.com
11
RustFS 1.0.1-preview.3 发布记录
github.com
12
RustFS S3 兼容矩阵
github.com
13
RustFS 池布局兼容与回归测试
github.com

今日三荐：混合架构代码审查、Git 工作树并行与 S3 兼容对象存储

1. open-code-review：确定性规则管道加 Agent 的混合代码审查

为什么今天看

最值得拆的机制

基准数字与一个明确的取舍

复现难度：低到中

最小上手路径

2. worktrunk：把 git 工作树变成和分支一样好用

为什么今天看

最值得拆的机制

复现难度：低

最小上手路径

3. rustfs：用 Rust 重写 S3 接口的对象存储

为什么今天看

最值得拆的机制

复现难度：中

最小上手路径

怎么选今晚的第一条路径

References

Related content

今日三荐：混合架构代码审查、Git 工作树并行与 S3 兼容对象存储

1. open-code-review：确定性规则管道加 Agent 的混合代码审查

为什么今天看

最值得拆的机制

基准数字与一个明确的取舍

复现难度：低到中

最小上手路径

2. worktrunk：把 git 工作树变成和分支一样好用

为什么今天看

最值得拆的机制

复现难度：低

最小上手路径

3. rustfs：用 Rust 重写 S3 接口的对象存储

为什么今天看

最值得拆的机制

复现难度：中

最小上手路径

怎么选今晚的第一条路径

References

Related content