公司动态

open-code-review语义文件分组原理:一次LLM调用搞定相关文件捆绑

📅 2026/8/31 7:40:56
open-code-review语义文件分组原理:一次LLM调用搞定相关文件捆绑
open-code-review语义文件分组原理一次LLM调用搞定相关文件捆绑【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-reviewopen-code-reviewOCR是一款经过阿里巴巴规模实战验证的 AI 代码审查工具采用确定性流水线 LLM Agent混合架构。它的语义文件分组能力是整个审查管线的巧思在一次 LLM 调用中把同一个 PR 里语义相关的改动文件捆绑成组让大模型带着完整上下文一起审查从而更精准地给出行级评论同时显著节省 Token 开销。为什么代码审查需要文件分组 想象一下这样一个 PR修改了PaymentService.java接口定义修改了PaymentServiceImpl.java实现类修改了message_en.properties和message_zh.properties多语言文案修改了对应的单元测试文件如果审查 Agent逐文件独立审查会出现两个问题上下文割裂接口改了参数实现类必须跟着改——但审查实现类的那次调用根本看不见接口的改动容易漏掉不一致问题Token 浪费每个文件都要独立携带一遍系统提示词、规则、其他变更文件清单等固定开销文件越多重复开销越大。OCR 的思路是先问一次 LLM哪些文件应该放在一起看然后按组并发审查。一次 LLM 调用分组全流程整个机制的核心代码只有约 280 行位于 internal/agent/grouping.go入口函数 groupDiffs() 的注释写得很直白Calls the LLM with file metadata (no diff content) to produce semantic groups. Falls back to one-file-per-group on any error.只把文件元数据交给 LLM不传 diff 内容任何出错都回退为一文件一组。第一步只传文件元数据不传代码内容分组调用发生在正式审查之前见 internal/agent/agent.go#L626-L634。OCR 先把本次所有待审查文件的改动构造成一个极简清单每个文件一行格式为MODIFIED internal/auth/login.go (12/-3) ADDED internal/auth/token_test.go (45/-0)状态 路径 增删行数仅此而已格式化逻辑在 formatDiffEntry()。不携带任何 diff 正文——分组只需要知道改了哪些文件、改了多少这就把这次调用的输入 Token 压到了极低。第二步LLM 输出 JSON 分组方案提示词模板 grouping_task_system.md 定义了分组的语义规则同一模块/功能下的文件归为一组存在生产者/消费者关系的文件如接口与实现归为一组同一资源的多语言/多环境变体如message_en.properties与message_zh.properties归为一组同一目录下围绕同一关注点协作的文件归为一组用户消息模板 grouping_task_user.md 要求 LLM只输出一个 JSON 数组[{label: payment-module, files: [PaymentService.java, PaymentServiceImpl.java]}]第三步确定性后处理 双重安全网 ️LLM 的输出不可全信parseGroupingResponse() 做了四层兜底兜底策略行为对应代码去重同一文件被 LLM 塞进多个组时只保留第一次出现的L182-L198防幻觉路径LLM 返回了不存在的文件路径直接忽略L192-L196防遗漏没被任何组覆盖的文件自动单成一组L205-L210防超大组每组最多10 个文件maxFilesPerGroup超出自动均分enforceMaxFilesPerGroup()另外还有两道保险Token 预算enforceGroupTokenBudget() 会估算每组 diff 的 Token 总量超过限制就把该组拆成单文件组避免单次审查调用爆上下文失败回退只要 LLM 调用失败、返回为空或 JSON 解析失败就打印提示并回退到一文件一组的朴素模式L67-L70分组失败永远不会阻塞审查本身。文件只有 1 个时甚至直接跳过 LLM 调用省一次请求。分组之后按组并发审查分组完成后调度器internal/agent/agent.go#L648-L698为每个组启动一个子任务组内文件拼成一份连续 diff共享一轮 Plan 阶段和主审查循环还能通过其他变更文件清单buildChangeFilesExceptGroup()知道自己组外还改了什么。各组以并发信号量默认并发 8并行执行且调度前会做 Token 预算前瞻超预算的组会被有序跳过并记录警告。这张基准榜直观体现了分组策略的价值OCR 在各模型上的 F1 显著领先而平均 Token 消耗普遍低一个数量级——一次分组调用 按组共享固定开销正是其中的关键贡献之一。源码导览快速定位核心模块分组核心逻辑internal/agent/grouping.goLLM 调用与会话记录callGroupingLLM()单组最大文件数常量L21分组入口与并发调度internal/agent/agent.go#L626-L700分组提示词模板internal/config/template/prompts/ 下的grouping_task_system.md/grouping_task_user.md行为测试internal/agent/grouping_test.go官方架构文档pages/src/content/docs/en/architecture.md小结open-code-review 的语义文件分组是一个典型的小成本 LLM 调用换大上下文收益设计输入极省——只传文件元数据不传 diff 正文输出极稳——JSON 契约 去重/补漏/限大小/限 Token 四重确定性兜底失败无损——任何异常都优雅回退为逐文件审查。一句话先用一次廉价的 LLM 调用理解这次改动的结构再让昂贵的审查调用带着完整语义上下文精准开火。对想要理解 Agent 编排工程的读者来说这份不到 300 行的 grouping.go 值得精读。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考