大 MR 场景下 open-code-review 可能在超时前产生极高 token 成本

[xunzou]

OpenCodeReview Version

v1.7.13

Operating System

macOS (Apple Silicon)

Installation Method

npm (global)

LLM Provider

Anthropic (Claude)

Bug Description

我们在实际接入 open-code-review 的过程中，遇到一次大 MR 场景下的成本异常。

这次异常不是由消息重复消费导致，也不是 review 任务被重复重试导致。实际情况是：某个较大的私有 MR 进入 open-code-review 后，流程在超时前进行了大量搜索、读取文件和模型请求，产生了非常高的 token 消耗。

随后 open-code-review 超时/失败，外层调用方 fallback 到其他 review runner，最终 review 有结果，但 open-code-review 失败链路中的成本已经实际产生。

脱敏后的本地日志里，观察到：

• 覆盖文件数：约 308 个
• 内部工具调用：约 2612 次
• 单次失败的 open-code-review 尝试产生约 90,433,182 token（9000多万）
• 其中 input_tokens 约 89,543,960，output_tokens 约 889,222
• 该次尝试耗时约 1h12m，随后超时/失败并 fallback
• 失败发生在 open-code-review 编排/执行链路上；在失败前，模型调用成本已经产生

这类失败链路会产生较大实际成本；如果外层只统计最终 fallback 结果，很容易漏掉这部分消耗。

Steps to Reproduce

由于涉及私有仓库，无法提供原始 MR 或代码内容。脱敏后的复现条件如下：

1. 准备一个较大的 MR，变更文件数达到数百级。
2. 使用 open-code-review 对该 MR 执行 review。
3. review 过程中允许 agent 式搜索、读取文件和生成评论。
4. 在缺少 token / 请求数 / tool call / 执行时长护栏的情况下，流程可能持续展开。
5. 最终 open-code-review 超时或非 0 退出。
6. 如果外层调用方 fallback 到其他 runner，最终 review 可能成功，但前一次 open-code-review 的 token 成本已经产生。

Expected Behavior

希望 open-code-review 可以提供内置的成本与规模护栏，特别是大 MR 场景：

1. Review 前规模预检

   • 变更文件数
   • diff 行数
   • 预计输入规模 / token 估算
   • 超过阈值时拒绝、降级或要求确认

2. 运行时预算护栏

   • 单次 review 最大 token 数
   • 单次 review 最大模型请求数
   • 单次 review 最大工具调用数
   • 最大执行时长
   • 单文件 / 单 agent loop 最大展开次数

3. 超限后的安全退出

   • 达到预算上限后主动停止
   • 尽可能返回部分结果
   • 明确标记 partial / budget_exceeded / timeout 等状态

4. 失败时也输出结构化 usage 信息

   即使 open-code-review 超时或失败，也希望能输出一份结构化 usage manifest，包含：

   • 模型请求数
   • input_tokens / output_tokens / total_tokens
   • 工具调用次数
   • 覆盖文件数
   • 耗时
   • 退出原因
   • 是否 partial
   • 是否 budget exceeded

这样外层系统可以准确记录失败尝试产生的成本，而不是只看到 fallback 后的结果。

Logs / Error Output

reviewed_files: ~308
internal_tool_calls: ~2612
total_tokens: ~90,433,182
input_tokens: ~89,543,960
output_tokens: ~889,222
elapsed: ~1h12m
result: timeout / non-zero exit
follow-up behavior: caller fallback to another review runner

未观察到消息重复消费或任务重试风暴。问题主要出现在单次 open-code-review 运行过程中的 agent 式展开。

Additional Context

这个反馈主要是希望增强大 MR 场景下的成本可控性和失败链路可观测性。

建议支持类似以下配置，示例值仅供参考：

max_total_tokens: 1000000
max_model_requests: 300
max_tool_calls: 500
max_changed_files: 100
max_elapsed_seconds: 900
large_mr_policy: fail | warn | require_confirmation
emit_usage_manifest_on_failure: true

这些配置可以让实际接入方在大 MR 场景下更安全地启用 open-code-review，避免一次异常展开造成不可控成本。

[lizhengfeng101]

感谢这么详细的反馈,尤其是脱敏后的成本数据,对定位问题很有帮助 🙏

我们把你的诉求拆成了两条线来跟进:

一、失败链路可观测性 / 结构化 manifest(对应诉求第 3、4 点的状态部分)—— 正在支持中

这块正通过 #367(PR #379)推进:会输出一份版本化、不可变的 run manifest,并且在超时/失败链路下也会写出(由 Finalize() 保证,持久化 session 与 --format json 输出同源)。目前已覆盖:

• 终态标记:complete / partial / failed / skipped——partial 不会再被当成 success;
• 每个失败项的类型分类:provider_error / timeout / cancelled / panic / skipped_limit;
• 覆盖文件集:selected / completed / reused / failed / waived;
• 耗时。

也就是你要的「是否 partial / 退出原因 / 覆盖文件数 / 耗时 / 失败时也输出」这几项会随该 PR 落地。

二、成本字段 + 成本护栏(对应诉求第 1、2 点,以及第 4 点的成本部分)—— 还需后续增量

你最关心的那几个成本数字目前还没进 manifest:

• total_tokens / input_tokens / output_tokens
• model_requests(模型请求数)
• tool_calls(工具调用次数)
• 明确的 budget_exceeded 标记

好消息是这些指标内部已经在统计(llmloop 里有原子 token 计数和按工具名的 tool-call 计数),只是目前只进了 summary/OTel,还没接进 #367 的 manifest。把它们补进同一份 manifest 是个低成本增量,我们会作为 #367 的 follow-up 跟进。

至于运行时预算护栏(diff review 路径的 max_tokens / max_model_requests / max_tool_calls、全局 deadline)和review 前规模预检的拦截/降级/确认,目前 diff review 路径确实还比较薄(仅 scan 模式有 --max-tokens-budget,超时也只是 per-file 级别),这部分我们会单独立项跟进,以便大 MR 场景能真正“提前刹车”而不是跑到超时。

会持续在本 issue 同步进展。

[cddypang]

同样的场景在 scan 命令执行中也会出现，初步查看了OCR实现代码，以java项目为例，无论是 scan 还是 review 命令，最终都会用相同的 java.md 扫描规则进行全面扫描。对于历史项目执行全量扫描和大diff这种场景能否给出扫描级别的支持，用户自定义的规则去覆盖内部system角色的执行规则不太现实。对OCR代码的理解可能有误，问题现象和题主的一致。

[nonothingless]

针对大文件或者大MR可以提供退化策略，不在关联上下文，直接按照当前文件内容输出，当然意见可能会存在较大误差

[xunzou]

这一个mr ，直接干了平时一个半月的成本。[捂脸]