（多git-repo）的多subagent code-review讨论【业务粒度】

[duringnone]

讨论案例：我们现在有多subagent场景，一个项目目录下有多个业务git-repo仓库

例如：

my-project

• admin_web // 管理后台h5
• admin_server // 管理后台
• user_server // 用户服务
• pay_server // 支付服务
• common_server // 基础服务
• sdk_client // 客户端服务
• biz_wiki // 业务文档（业务知识文档）

1. 管理端调用链路： admin_web => admin_server => common_server

2. 用户设备端调用链路：sdk_client => user_server、pay_server => common_server

biz_wiki知识是所有代码项目的基座，同时每个文件都是一个git-repo仓库

ocr是否支持多subagent的代码code-review，我在目前最新的版本中没有看到类似的功能（v1.7.6），如果支持，麻烦帮忙提供一下操作步骤参考，感谢；

如果还没有，也欢迎类似场景的大佬们一块讨论分享下相关经验

[duringnone]

目前我的设计思路是：

一、 案例1

biz_wiki是总结性知识库（最终业务知识快照），每次需求功能先拆解成若干个子需求，每个subagent负责根据1个子需求；例如：
功能需求：admin后台，增加一个用户开通超级VIP的条件，当且仅当支付付款金额超过$100的用户，才有资格开通super-vip；
0）目录【feature拆解成N个，涉及几个git-repo就拆解成几个feature，本案例中N=3】

• admin_web // 管理后台h5
• admin_server // 管理后台
• user_server // 用户服务
• pay_server // 支付服务
• common_server // 基础服务
• sdk_client // 客户端服务
• biz_wiki // 业务文档（业务知识文档）

1）admin后台页面可配置、可展示
2）pay支付系统订单统计 用户支付金额，按照account用户账号粒度收集，并存储
3）account系统开通super-vip的判断条件新增：>$100 的用户账户ID

涉及到3个系统，拆解成3个子feature（f_01、f_02、f_03），每个git-repo（业务服务）都有自己的子feature；分别由3个subagent开发；【对于ocr不感知，仍然在gitlab粒度-执行ci流程即可】

二、思考：

如果没有拆解子需求这一步，上层开发模式只读取1个feature内容文档，每个git-repo的业务知识都需要读取同一个feature
0）目录【feature不拆解，所有相关git-repo共享1个feature文档】

• admin_web // 管理后台h5
• admin_server // 管理后台
• user_server // 用户服务
• pay_server // 支付服务
• common_server // 基础服务
• sdk_client // 客户端服务
• feature // 迭代过程中的需求文档，本次迭代相关的业务服务，共享一个需求文档【每个git-repo加载同一个文档内容？】
• biz_wiki // 业务文档（业务知识文档）

[lizhengfeng101]

感谢分享，你在案例 1 里的拆解思路其实已经和我们目前推荐的做法基本吻合了 👍

推荐做法：把 OCR 当作「审查原子工具」，跨库编排放在上层

OCR 的设计定位是一个不耦合具体业务、单库单次审查的原子工具，它本身不负责多 repo / 多 subagent 的编排。真正的「多业务、多 repo」能力应该由你在上层的工作流来承担，OCR 只在最内层被调用。所以并不是 OCR 没有多 subagent 功能，而是这一层刻意留给了上层：

1. 上层工作流做子需求拆分：正如你案例 1 里把一个功能需求拆成 f_01 / f_02 / f_03，每个子需求对应一个 git-repo。这一步（关联到每个代码库的子需求拆解）是工作流的职责。
2. 拆解结果作为 --background 传入：每个 repo 的审查任务，把它对应的那个子需求描述通过 --background 传给 OCR。这样每个仓库的审查都带着「本仓库在这次迭代里要做什么」的业务上下文，而不需要 OCR 去感知整个多库拓扑。
3. CI 粒度不变：正如你说的，对 OCR 而言仍然是在单个 gitlab repo 粒度执行 CI 流程即可，多 subagent 的并行发生在上层。

这也回答了你「二、思考」里的疑问：更推荐拆解子需求（案例 1），让每个 repo 拿到属于自己的、精炼过的 background；而不是让所有 repo 共享同一份大而全的 feature 文档（案例 2）——共享文档会带来大量与本仓库无关的噪声，反而降低审查质量。

当前的一个局限，以及推荐的解法

因为「不耦合业务」这个设计取舍，带来一个已知弊端：审查 A 仓库时，OCR 读不到 B 仓库的内容（比如 admin_server 审查时看不到 common_server 的接口实现、或 biz_wiki 里的业务基座知识）。

对于跨库依赖 / 业务知识基座（你这里的 common_server、biz_wiki）这个问题，我们推荐的实践是：

通过 MCP 为你的代码存储平台（gitlab / 自建代码平台）实现一个「读取特定仓库、特定版本的上下文召回」能力。

这样在审查 admin_server 时，subagent / OCR 可以按需通过 MCP 召回 common_server 对应版本的相关代码片段、或 biz_wiki 的业务快照作为补充上下文，而不需要把所有仓库物理地放进同一个审查目录，也不破坏 OCR 单库原子审查的边界。我们认为这条路径可以比较干净地解决跨库评审的上下文问题。

---

小结：子需求拆分 + 每库独立 --background + MCP 跨库上下文召回，三者组合基本能覆盖你描述的这个多 repo、多 subagent 的业务粒度审查场景。欢迎继续交流实践中的细节 🙌

[duringnone]

感谢回复

1. 业务上下文确实通过拆解子feature容易解决（拆解本就是需求落地的一个环节）；【共识】

2. 确实服务之间的代码比较麻烦（因为代码上下文是跨git仓库），mcp的解法是一个不错的方向，后续尝试下

[duringnone]

进一步了解下，ocr后续的规划中，是明确不处理逻辑代码上下文（由业务自行开发mcp工具接入）吗？如果这个方向有新的变化，麻烦同步下

[lizhengfeng101]

进一步了解下，ocr后续的规划中，是明确不处理逻辑代码上下文（由业务自行开发mcp工具接入）吗？如果这个方向有新的变化，麻烦同步下

我认为是没有明确的，OpenCodeReview 的发展方向是开放、包容、规范、先进。所以我们会一直跟进最主流的技术实现来解决代码评审场景下的问题，但是前提是这个实现方案是规范的，如果过于定制化的情况下我们就会考虑通过 mcp 等协议（未来可能会有新的、更好的）来解决各个用户、公司内部业务系统不一致的问题。总之，如果有好的实践非常欢迎找我们交流，我们是愿意去演进的。