工作原理
从 diff 到带行号的审查结果，整条审查流水线。
ocra 结合了两种经过验证的设计：按领域分工的专项审查员加一个负责协调的裁决者，以及把所有不能出错的步骤交给确定性的工程代码。
Ingest → Select → Triage → Bundle → Execute → Anchor → (Verify → Judge) → Report| 阶段 | 做什么 |
|---|---|
| Ingest | 通过代码托管平台适配器读取改动和仓库规范。 |
| Select | 逐个文件决定：审查，或者排除并记录原因（二进制、密钥、生成代码、过大……）。 |
| Triage | 根据改动规模和 auth/ 这类敏感路径，给出风险档位（trivial、lite、full）。 |
| Bundle | 把相关文件分到一组。改动少时合成一组；改动多时由 light 模型按文件编号分组。 |
| Execute | 每个审查员在每个分组上作为一个隔离的 agent 任务运行，只有只读工具。 |
| Anchor | 把每条问题引用的代码解析成准确的行号。 |
| Verify、Judge | M2 规划中： 逐条核查每个问题，并跨审查员去重。 |
审查员与工具
审查员是一个带有专门提示词的 agent。它只能读：read_file、read_diff 和 code_search 返回的都是被审查的那个版本（在区间或单个 commit 模式下是对应的 commit，而不是你的工作区），问题通过 report_finding 提交。它不能修改文件、执行命令或访问网络。
行号定位
模型给出的行号并不可靠，所以让模型引用代码，由 ocra 来解析：
- 在该文件改动过的代码段里做规范化匹配；
- 在整个文件里匹配；
- 在其他改动文件里匹配（模型写错了文件）；
- （规划中） 请 light 模型重新定位；
- 以上都不行，问题就挂在文件级别，绝不丢弃。
稳定性
- 单个任务和整次运行都有超时，即使模型不再响应也照样生效。
- 某个任务失败不会导致整次运行失败，它负责的文件会被标记为
failed。 - 每个层级都有模型降级链，会跳过反复失败的模型。
- 每个 agent 最多执行 20 步，因为每一步都会把整个对话重新发送一遍。