我厌倦了 AI Reviewers 幻觉般的表现，于是我为 GitLab 构建了一个 Autonomous Agent。

Source: Dev.to

Introduction

我们都有过这种经历。你推送了一个 300 行的大型合并请求（Merge Request），几秒钟后，一个“AI 代码审查员”机器人就在你的 PR 上留下了十几条评论。
其中两条抱怨“缺少导入”，而这显然已经在你的框架里全局处理了。另一条建议使用你在上一个冲刺中明确删除的库。其余的都是恼人的格式细节。你默默地点击 Resolve Thread 十二次，叹了口气。

标准的 AI 审查员只是把你的 .patch 文件直接喂给大语言模型（LLM），祈祷能得到好结果。它们缺乏上下文，这正是我构建 AI Review Agent 的原因——一个真正自主、具备上下文感知的代码审查代理，使用 Go 原生实现，专为 GitLab 设计。

Why Existing AI Reviewers Fall Short

Zero Codebase Context

“Why did you use mylog.Info() instead of fmt.Println()?”

审查员根本不了解你项目的日志约定或辅助工具。

Context‑Window Explosions

把一个包含 150 个文件的 MR 差异一次性塞进 LLM，模型的上下文窗口很快就会被耗尽，导致它忘记原始系统提示，产生不相关或幻觉式的反馈。

One‑Way Communication

大多数机器人只会一次性输出审查结果，然后消失。你无法让它们进一步阐述或澄清建议。

How AI Review Agent Works Differently

机器人不仅仅是静态读取差异。它配备了 read_file、search_code、multi_diff 等工具。

当它遇到类似 CacheManager.Get() 的调用时，会暂停，使用 search_code 在代码库中定位 CacheManager 的实现，读取后再判断该代码是否有 bug——从而消除幻觉式的断言。

Persistent Conversation

它不会只留下单条评论后就消失，AI Review Agent 会保持对话：

@reply 在 GitLab 线程中回复它。
“其实我这么做是因为上游服务存在竞争条件。”

每个代码库都有自己的潜规则。AI Review Agent 设计为随时间变得更聪明，从“仓库最佳实践”手册中学习。

Webhook‑Driven Architecture

AI Review Agent 作为高性能 webhook 服务器运行。只需在你的 GitLab 项目上进行一次性配置，webhook 就会在每次 push 时触发代理。审查任务会通过工作池系统异步排队并具备重试机制，确保即使 OpenAI API 出现波动，你的审查也不会丢失。

Usage

你可以直接在终端与代理交互：

./cli review --project-id 123 --mr-id 45 --model claude-3-7-sonnet-20250219

CLI 会打印 AI 的建议，并让你交互式输入 1、3、5 等数字，决定哪些评论要推送到实际的 GitLab MR。

Technical Details

• Language: Go 1.25
• Architecture: Clean Architecture 抽象，便于扩展
• Features:
  • Graceful degradation
  • Multi‑LLM routing (OpenAI, Anthropic, Google Gemini)
  • Persistent storage with SQLite or PostgreSQL for asynchronous jobs and feedback metrics

Get Involved

如果你的团队使用 GitLab，且希望拥有更聪明、噪音更少的 AI 审查员——或者你只是对基于 Go 的 AI 代理感兴趣——欢迎查看项目：

🔗 GitHub Repository:

我正在积极征求反馈、功能需求和早期贡献者。欢迎在评论中告诉我：AI 审查员在你的 PR 上留下的最烦人的评论是什么？