GitLab 合并请求也能交给 AI Agent：langgraph-harness 自托管实战
很多团队已经在 GitLab 里积累了完整的 Issue、Merge Request 和讨论记录，但 AI 编程工具往往只在开发者本地工作：它能改代码，却不知道项目历史，也不会自动跟进下一条评论。langgraph-harness 的思路不同：它把 AI 编程 Agent 放进 GitLab 工作流，提供自托管的 MR Review、Issue/Task 修复和项目上下文聊天能力。
项目使用 MIT 许可证，核心实现基于 LangGraph，并通过 Docker Compose 部署。它目前明确面向 GitLab；GitHub 的 Issue 到 PR 支持仍列在路线图中，因此不要把它当作同时支持两个平台的通用机器人。
它解决的不是“让模型写代码”
langgraph-harness 把 Agent 的工作拆成四种入口：
- MR Review：GitLab webhook 触发后读取变更，生成并发布审查意见，不需要轮询。
- Work Item Resolve：把 GitLab Issue 或 Task 分配给 Agent，由它在隔离环境中处理，创建 Draft MR，并继续响应同一分支上的后续评论。
- Task Resolve：直接给一段自由文本任务，可按需运行，也可以设置周期任务。
- Chat：一个了解 GitLab 项目上下文的交互式助手，能调用 GitLab 数据和无头浏览器；敏感操作会先等待人工批准。
它的关键不只是四个入口，而是共享的运行时保护：草拟的评论在发布前会经过筛选；如果运行重复调用工具、陷入循环、以问题结束或跳过检查，系统会在中途捕获并纠正。持久化 checkpoint 还可以让崩溃的运行从原处恢复，而不是从头开始。
架构：把上下文、队列和隔离放在 Agent 之外
项目的前端是 React 管理界面，用来查看运行、线程、聊天和工作流；后端是 Elysia API 服务，里面运行带持久化 checkpoint 的 LangGraph Agent。BullMQ 负责队列、并发上限和重新审查的去抖处理。
模型层支持 OpenRouter、Gemini、Groq、Ollama 或 sglang。GitLab 工具通过 MCP 接入，项目记忆则按项目保存可复用事实，聊天还拥有独立的个人记忆。对代码有实际修改的运行会进入 Kata Containers 虚拟机：它使用独立的 guest kernel，不只是依赖系统调用拦截，因此比把 Agent 直接放在应用进程里更容易划定边界。
这种分层值得借鉴：模型负责推理，队列负责调度，沙箱负责执行边界，GitLab 负责事件和审计。换模型时，不必重写 webhook；更换队列策略，也不必把安全判断塞进提示词。
最小启动流程
官方 Quick Start 要求 Node.js 22+、Docker、具有 api scope 的 GitLab PAT、GitLab OAuth 应用，以及一个远程或本地模型后端。先克隆仓库并安装依赖：
git clone https://github.com/vrajpal-jhala/langgraph-harness.git cd langgraph-harness npm install cp backend/.env.example backend/.env
然后在 backend/.env 中填写 GitLab 和会话安全配置，例如 GITLAB_PAT、GITLAB_OAUTH_CLIENT_ID、GITLAB_OAUTH_CLIENT_SECRET、SESSION_SECRET、SECRETS_ENCRYPTION_KEY、ADMIN_GITLAB_USERNAMES，以及以下模型后端之一：OPENROUTER_API_KEY、GEMINI_API_KEY、GROQ_API_KEY、OLLAMA_BASE_URL 或 SGLANG_BASE_URL。
启动开发环境：
npm run dev
默认情况下，前端地址是 http://localhost:5173，API 地址是 http://localhost:3698。完成 GitLab OAuth 应用和 webhook 配置后，再为每个仓库准备 .harness.yml，把仓库级策略与全局运行时分开管理。生产部署则使用 Docker Compose，官方文档另有部署和 sglang 后端章节。
适合哪些团队
它特别适合三类场景。第一类是内部 GitLab 部署：代码和模型调用希望留在自己的网络边界内。第二类是 MR 数量较大、需要统一初审规则的团队：webhook、队列和草拟评论可以减少人工重复操作。第三类是希望让 Agent 处理低风险维护任务，但又不愿给它长期裸奔权限的团队：隔离运行、敏感操作审批和可恢复 checkpoint 可以组成一条更可控的自动化链路。
不过，部署前要确认成本和责任边界。它需要 GitLab PAT、OAuth 应用、Docker 以及模型供应商或本地推理服务；Agent 生成的评论也不应直接等同于人工结论。建议先从只读 MR Review 开始，观察误报、工具调用和队列积压，再逐步开放 Draft MR 和写操作，并为人工审批保留明确的最后一道门。
实践建议
- 先限制权限：GitLab PAT 只授予确实需要的范围，把写操作放在 Draft MR 和审批流程之后。
- 分离模型后端：先用本地 Ollama 或 sglang 做开发验证，再根据吞吐量选择云端模型，避免把供应商密钥直接写入仓库。
- 把记忆当作项目资产管理：项目记忆会影响后续审查，应该规定哪些事实可以写入、如何复核过时内容。
- 从可观测性开始验收：先看运行是否可恢复、评论是否经过筛选、重复调用是否被捕获，再评价模型回答质量。
- 接受当前边界：官方路线图中的 GitHub 支持、自动维护记忆和网页搜索尚未完成，文章或内部方案不要把它们描述成现成功能。
langgraph-harness 的价值不在于又提供了一个聊天窗口，而在于展示了一种更完整的 Agent 工程形态：事件触发、上下文记忆、队列调度、隔离执行和人工审批共同构成闭环。如果你的团队已经以 GitLab MR 为主要交付单元，这种“自托管 Agent 作为协作者”的方式，比单独给每位开发者安装一个代码补全工具更值得试验。