multi-review: 放弃 opencode github run 方案，寻求替代方案

[Svtter]

问题

multi-review/ 模块已被移除（PR #101）。经过多次迭代（PR #87, #90, #98），基于 opencode github run 的方案被证实存在根本性设计缺陷。

根本原因

opencode github run 的 stdout 只包含 CLI 框架输出（权限校验、session 信息、工具调用日志），永远不包含 AI 评审的实际内容。AI 评审内容是 CLI 内部通过 GitHub API 直接作为 PR comment 发出的。

这导致：

1. Python 脚本无法从 subprocess stdout 获取有用的评审内容
2. 所有噪声过滤（_filter_noise、_strip_ansi）都是治标不治本
3. snapshot-based comment fetching 虽然解决了并行竞争问题，但取回的 comment 仍然是 CLI 自发的内容，不是我们想要的结构化输出
4. coordinator 的输出同样是纯噪声

已尝试的方案

PR	尝试	结果
#87	噪声过滤 (_filter_noise)	过滤了噪声，但有用的内容本身就不在 stdout 里
#90	git clone --no-local 解决 shallow.lock 竞争	解决了竞争，但根本问题没变
#98	snapshot comments + 只保留 coordinator 评论	评论获取正确了，但内容仍是噪声

替代方案讨论

方案 A: 封装 open-code-review (spencermarx)

• 仓库: https://github.com/spencermarx/open-code-review
• 优点: 成熟的多 agent review 工具，28 个 reviewer persona，支持 discourse 和 synthesis
• 缺点: 不是独立 CLI，review 是通过 AI assistant 的 slash command（/ocr-review）执行的，不支持 headless/CI 模式。它的 CLI 只是辅助工具（init、state、dashboard、post）
• 结论: 不适合直接封装为 GitHub Action

方案 B: 封装 open-code-review (raye-deng fork)

• 这是一个完全不同的项目，专门为 CI/CD 设计
• 有现成的 GitHub Action，支持 SARIF 输出
• 但功能定位不同（静态分析 + hallucinated imports 检测），不是多 agent code review

方案 C: 直接调用 LLM API

• 绕过 opencode CLI，直接在 Python 中调用 LLM API（Claude/GPT）
• 自己管理 prompt、context、多轮对话
• 完全控制输出格式
• 缺点: 需要自己实现 agent 编排逻辑

方案 D: 使用 Claude Code headless mode

• claude -p "review this PR" --output-format json 可以在 CI 中 headless 运行
• 输出是结构化的 JSON
• 可以通过 prompt engineering 控制评审行为

大家觉得哪个方向更合适？或者有其他想法？

[Svtter]

PR #101 已合并，multi-review 模块已完全移除（12 文件 / 1485 行）。替代方案待后续讨论。

[Svtter]

误关闭。此 issue 用于讨论 multi-review 的替代方案，继续开放。