GitLab-Runner + AI 代码审查服务 + 远程大模型全套部署运维实战

说明

本文为真实服务器全流程部署、排错、优化、迭代实录，完整记录内网 Linux 服务器搭建 CI/CD AI 自动化代码审查平台的全过程。

涵盖基础环境初始化、依赖安装、GitLab-Runner 部署、Ollama 本地大模型部署、AI 审查服务部署、网络代理调试、服务自启配置、本地模型迭代切换远程阿里云大模型（Qwen3.6-Plus）、全链路问题踩坑与修复方案。

文档所有内容均为现场实操验证，包含完整命令、报错原因、解决方案、架构迭代记录，可作为项目长期运维、复盘、二次部署的标准手册。

一、服务器基础环境信息

1.1 硬件配置

CPU：32 核高性能服务器
内存：125GiB 大内存
交换分区：无
显卡：无（原计划本地部署大模型，后改用远程模型，无需 GPU）
操作系统：Debian / Ubuntu 系列
默认 Python 版本：Python 3.13

1.2 网络与代理环境

服务器处于内网隔离环境 ，无法直连外网，所有外网资源（软件包、依赖、远程大模型接口、工具插件等）必须通过全局 HTTP/HTTPS 代理访问；

同时严格配置 no_proxy 规则，保证本地回环地址、内网网段、内部服务地址不走代理，避免本地接口、内网服务请求、内部 GitLab 仓库被代理劫持、请求卡死、超时等问题。

业务需求特殊：服务需要双网络通路

访问内网 GitLab：拉取 MR 代码、提交审查评论，禁止走代理
访问外网大模型：模型推理，必须走代理（初期尝试本地小模型效果不佳，后续切换为远程大模型）

1.3 最终上线服务清单

本次整套环境共部署三大核心服务，分工明确、链路串联：

服务	职责	状态
GitLab Runner	对接内网 GitLab CI/CD 流水线，自动化执行代码审查任务、拉取代码、调度流程	✅ 生产运行
AI-Review-Server	基于 Flask 开发的核心业务服务，承接 GitLab Runner 调用，转发请求至远程 `qwen3.6-plus` 大模型，完成代码解析、缺陷审查、评语生成，并将结果回传 GitLab	✅ 生产运行
Ollama	初期部署用于运行本地 `qwen2.5:7b` 模型，因本地 CPU 推理慢、模型审查效果不佳，现已切换为远程大模型，服务保留备用	⚠️ 历史留存

1.4 架构迭代历程

scss 复制代码

┌─────────────────────────────────────────────────────────────────────┐
│ V1 版本架构（已弃用）                                                  │
├─────────────────────────────────────────────────────────────────────┤
│ GitLab CI → Runner → AI审查服务 → 本地 Ollama(qwen2.5:7b)             │
│ 痛点：纯 CPU 推理慢、审查效果差、占用大量资源                              │
└─────────────────────────────────────────────────────────────────────┘
                              ↓ 升级迭代
┌─────────────────────────────────────────────────────────────────────┐
│ V2 最终架构（生产可用）                                                │
├─────────────────────────────────────────────────────────────────────┤
│ GitLab CI → Runner → AI 审查服务(5001) → 阿里云 Qwen3.6-Plus          │
│ 优势：释放本地算力、推理速度快、审查精度高、运维成本低                       │
└─────────────────────────────────────────────────────────────────────┘

1.5 整体业务架构（改造后）

arduino 复制代码

GitLab 代码仓库 MR/提交触发 CI/CD 流水线
        ↓
GitLab Runner 接收任务、拉取项目代码
        ↓
Runner 调用本地 AI 代码审查服务（5001 端口）
        ↓
AI-Review-Server 携带请求参数，转发至 远程 qwen3.6-plus 大模型接口
        ↓
远程大模型执行代码审查，返回审查结果
        ↓
结果原路回传：AI服务 → GitLab Runner → GitLab 流水线展示

二、服务器基础环境初始化（前置基础操作）

本节为部署所有服务前的通用环境准备，包含网络代理配置、系统更新、工具安装、基础依赖、常用运维插件安装，是整套环境运行的基础，所有操作按执行顺序记录。

2.1 全局网络代理配置（核心前置，重中之重）

服务器内网环境必须配置全局代理才能访问外网，这是后续所有外网下载操作的前提。同时强制本地/内网地址豁免代理，是解决接口卡死、请求超时的关键。

2.1.1 全局代理配置文件

配置文件路径：/etc/environment（系统级全局环境变量，所有用户、系统服务生效）

编辑文件：

bash 复制代码

vim /etc/environment

2.1.2 最终完整配置内容

bash 复制代码

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# 外网代理地址（根据现场实际代理IP、端口修改）
http_proxy=http://your-proxy-ip:your-proxy-port
https_proxy=http://your-proxy-ip:your-proxy-port
all_proxy=socks5://your-proxy-ip:your-proxy-port

# 兼容大写格式（部分软件/服务优先读取大写变量）
HTTP_PROXY="$http_proxy"
HTTPS_PROXY="$https_proxy"
ALL_PROXY="$all_proxy"

# 免代理规则：本地回环、IPv6、内网标准网段、内网GitLab地址
# 禁止以上地址走外网代理，防止本地服务请求被劫持
no_proxy=localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,your-gitlab-domain.com
NO_PROXY="$no_proxy"

2.1.3 配置生效命令

修改 /etc/environment 后必须重载系统配置并重启服务器，否则代理不生效：

bash 复制代码

# 重载系统服务配置
systemctl daemon-reload

# 重启服务器（全局环境变量必须重启生效）
reboot

2.1.4 代理临时测试命令

重启后验证代理与免代理规则是否正常：

测试外网连通（走代理）

bash 复制代码

curl -I https://www.baidu.com

正常返回 HTTP 200 即为代理生效。

测试本地地址（不走代理）

bash 复制代码

# 强制不走代理访问本地接口，避免代理劫持
curl --noproxy "*" --connect-timeout 5 http://127.0.0.1:11434

可正常连接、无卡死即为 no_proxy 规则生效。

2.1.5 代理相关踩坑记录

问题现象	根因	解决方案
未配置 `no_proxy`	访问 `127.0.0.1`/内网地址请求卡死、超时、无任何返回	配置完整的 `no_proxy` 白名单
仅配置小写 `no_proxy`	部分老服务识别大写 `NO_PROXY`，导致豁免失效	同时配置大小写环境变量
配置代理后未重启服务器	全局环境变量不生效，外网下载失败	必须执行 `reboot` 重启服务器

2.2 系统更新与基础工具安装

代理配置完成并验证生效后，开始安装基础工具。

2.2.1 系统更新命令

bash 复制代码

# 更新软件源索引
apt update

# 升级系统已安装包（可选，生产环境按需执行）
apt upgrade -y

2.2.2 安装运维必备工具

包含网络检测、端口监听、进程查询、文本编辑、解压工具等，后续排错、运维全程使用：

bash 复制代码

# 批量安装常用工具
apt install -y curl wget git vim net-tools iproute2 procps unzip tar lsof

工具说明：

工具	用途
`curl/wget`	接口测试、网络连通性检测
`net-tools/iproute2`	`ifconfig`、`ss`、`route` 网络查询
`procps`	`ps`、`top`、`pkill` 进程管理
`lsof`	查询端口占用、文件占用
`vim`	配置文件编辑

2.3 Python 基础环境与依赖前置处理

系统自带 Python 3.13，Debian/Ubuntu 高版本 Python 开启了系统环境保护机制，禁止直接在系统 Python 中安装第三方包，提前记录解决方案。

2.3.1 核心报错与通用解决方案

执行 pip install 时报错：externally-managed-environment

原因：系统 Python 受保护，防止破坏系统依赖。

统一解决方案 ：安装包时追加 --break-system-packages 参数，全局通用：

bash 复制代码

# 通用 pip 安装格式（后续所有Python依赖均使用此命令）
pip3 install 包名 --break-system-packages

# 示例：安装基础依赖
pip3 install flask requests python-dotenv openai --break-system-packages

三、历史服务：Ollama 本地大模型部署（原方案，现已弃用）

初期为实现本地代码审查，部署 Ollama 框架并运行 qwen2.5:7b 本地大模型，因纯 CPU 推理速度极慢、代码审查效果不佳 ，后续全面切换为远程 qwen3.6-plus 模型。

本节完整记录原部署流程、配置、自启、排错，作为环境历史留存。

3.1 Ollama 安装与本地模型拉取

3.1.1 官方一键安装命令

依托全局代理，执行官方安装脚本：

bash 复制代码

curl -fsSL https://ollama.com/install.sh | sh

3.1.2 拉取本地代码审查模型

bash 复制代码

# 拉取 qwen2.5:7b 模型
ollama pull qwen2.5:7b

3.2 Ollama Systemd 开机自启配置

文件路径：/etc/systemd/system/ollama.service

作用：实现开机自启、进程异常自动重启、隔离代理影响。

3.2.1 完整服务配置文件

ini 复制代码

[Unit]
Description=Ollama Local LLM Service
After=network.target

[Service]
# 强制清空代理变量，彻底杜绝本地请求被代理劫持
Environment=no_proxy=127.0.0.1,localhost,0.0.0.0
Environment=NO_PROXY=127.0.0.1,localhost,0.0.0.0
Environment=HTTP_PROXY=
Environment=HTTPS_PROXY=
Environment=ALL_PROXY=

# 监听所有网卡，允许内网访问
Environment=OLLAMA_HOST=0.0.0.0
ExecStart=/usr/local/bin/ollama serve
User=root
Group=root
# 进程异常自动重启
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

3.2.2 Ollama 服务管理全套命令

bash 复制代码

# 重载Systemd配置（修改配置后必执行）
systemctl daemon-reload

# 启动服务 + 设置开机自启
systemctl start ollama
systemctl enable ollama

# 查看服务运行状态
systemctl status ollama

# 实时查看运行日志（排错核心命令）
journalctl -u ollama -f --no-pager

# 查看11434端口监听状态（Ollama默认端口）
ss -tuln | grep :11434

# 停止/重启服务
systemctl stop ollama
systemctl restart ollama

3.3 Ollama 高频问题与解决方案

问题现象	根因分析	解决方案
`listen tcp 0.0.0.0:11434: bind: address already in use`	残留进程占用端口	`pkill -9 ollama && systemctl restart ollama`
服务状态正常、端口监听正常，但 curl 本地接口卡死	服务未清空代理变量，全局代理劫持本地请求	使用上方 `ollama.service` 配置，清空所有代理环境变量
纯 CPU 运行 `qwen2.5:7b` 推理极慢	7B 参数量模型 + 无显卡加速 + 单次传入代码文本量大（数万字符）	临时优化：切换轻量模型；最终方案：放弃本地模型，切换远程 qwen3.6-plus
日志告警：`context deadline exceeded`	Ollama 访问官方云端超时	不影响本地模型运行，可直接忽略

3.4 本地模型可用性验证

bash 复制代码

curl --noproxy "*" http://127.0.0.1:11434/api/tags

正常返回已下载模型列表，代表 Ollama 部署完成。

重要说明：当前业务已不再使用 Ollama 本地模型，该服务仅作为历史环境保留，可根据需求选择停止/保留。

四、AI 代码审查服务（ai-review-server）部署 + 改造对接远程 qwen3.6-plus

本服务为整套架构核心中转服务 ，基于 Flask 开发，原对接本地 Ollama，现已全面改造为对接远程 qwen3.6-plus 大模型。完整记录目录规划、依赖安装、配置文件修改、代码改造、自启配置、排错全流程。

4.1 服务基础信息

属性	值
开发框架	Flask
项目工作目录	`/path/to/your/ai-review-service`
服务监听地址	`0.0.0.0:5001`
上游依赖	远程大模型接口（如阿里云 Qwen3.6-Plus）
运行用户	root
核心功能	接收 GitLab CI 请求、拉取 MR 代码变更、调用大模型审查、生成报告、提交 MR 评论、阻塞违规合码

4.2 进入项目目录 & 安装 Python 全量依赖

4.2.1 进入工作目录

bash 复制代码

cd /path/to/your/ai-review-service

4.2.2 安装项目依赖

结合系统 Python 限制，统一使用 --break-system-packages 参数：

bash 复制代码

# 安装项目所需依赖：Flask、环境变量解析、OpenAI SDK、网络请求等
pip3 install flask python-dotenv requests openai --break-system-packages

4.2.3 OpenAI SDK 版本报错修复

报错：Client.__init__() got an unexpected keyword argument 'proxies'

原因：openai 2.x 新版 SDK 已移除 proxies 初始化参数。

解决方案 ：删除代码中所有 proxies=xxx 相关配置，服务内网访问远程接口依赖系统全局代理，无需代码内单独配置代理。

4.3 环境变量配置文件 `.env`（核心改造点：切换远程大模型）

文件路径：/path/to/your/ai-review-service/.env

原配置指向本地 Ollama，现修改为远程大模型接口，完整配置如下：

env 复制代码

# ============ 远程大模型配置 ============
# 远程大模型鉴权密钥（根据实际密钥填写）
OPENAI_API_KEY=your-llm-api-key

# 核心改造：由本地127.0.0.1改为远程大模型接口地址
OPENAI_BASE_URL=https://your-llm-api-endpoint/v1

# 指定使用模型名称（根据实际模型填写）
OPENAI_MODEL=qwen3.6-plus

# ============ 业务配置 ============
# GitLab 鉴权Token（项目权限令牌，需赋予read_api权限）
GITLAB_TOKEN=your-gitlab-access-token

# GitLab 服务器地址
GITLAB_URL=https://your-gitlab-domain.com

# 请求超时时间（秒）
REQUEST_TIMEOUT=120

4.4 Systemd 开机自启配置

保证服务开机自动启动、异常自动重启，严格指定工作目录，避免启动失败。

4.4.1 服务配置文件

路径：/etc/systemd/system/ai-review.service

ini 复制代码

[Unit]
Description=AI Code Review Service (Remote LLM)
After=network.target

[Service]
# 智能代理分流：外网模型走代理，内网GitLab不走代理
Environment=http_proxy=http://your-proxy-ip:your-proxy-port
Environment=https_proxy=http://your-proxy-ip:your-proxy-port
Environment=no_proxy=127.0.0.1,localhost,your-gitlab-domain.com,10.0.0.0/8,192.168.0.0/16
Environment=NO_PROXY=127.0.0.1,localhost,your-gitlab-domain.com,10.0.0.0/8,192.168.0.0/16

# 必须和项目实际目录一致，目录错误会直接启动失败
WorkingDirectory=/path/to/your/ai-review-service

# 启动命令：调用系统Python3运行入口文件
ExecStart=/usr/bin/python3 app.py

User=root
Group=root

# 关闭Python缓冲，日志实时输出
Environment=PYTHONUNBUFFERED=1

# 进程异常自动重启
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

4.4.2 AI 服务全套管理命令

bash 复制代码

# 修改配置后重载Systemd
systemctl daemon-reload

# 启动服务 + 开机自启
systemctl start ai-review
systemctl enable ai-review

# 查看运行状态
systemctl status ai-review

# 实时查看服务日志（排错首选）
journalctl -u ai-review -f --no-pager

# 停止/重启服务
systemctl stop ai-review
systemctl restart ai-review

4.5 AI 服务踩坑记录（实操问题）

问题现象	根因分析	解决方案
`status=200/CHDIR` 服务反复启动、启动失败	`WorkingDirectory` 配置的目录与项目真实目录不一致	修正为实际路径 `/path/to/your/ai-review-service`
手动 curl 接口返回 401 未授权	服务内置安全鉴权，仅允许 GitLab CI 内网调用	正常安全逻辑，不影响流水线正常使用，无需修复
调用远程大模型超时	远程接口网络波动、大模型推理耗时久	在 `.env` 中调大 `REQUEST_TIMEOUT` 超时时间，同时延长 GitLab CI 任务超时
切换远程模型后请求无返回	代理配置问题或模型参数错误	检查全局代理、`.env` 配置、服务日志
无法获取 MR 代码变更	重启服务后 GitLab Token 环境变量丢失/权限不足	重新配置有效 `GITLAB_TOKEN`，赋予 `read_api` 权限

4.6 服务连通性验证

bash 复制代码

# 本地测试接口连通性（忽略401鉴权，只要能通即服务正常）
curl http://127.0.0.1:5001

五、核心架构迭代：本地模型升级为阿里云 Qwen3.6-Plus

5.1 迭代核心原因（真实业务痛点）

核心结论 ：本地 qwen2.5:7b 小模型能力不足，无法满足代码审查需求，具体表现如下：

问题类型	具体问题	影响
性能问题	`qwen2.5:7b` 纯 CPU 运行，长代码审查耗时过长（30s~5min/轮）	CI 流水线极易超时阻塞
能力不足	本地小模型仅能检测基础 TS 类型、组件命名等简单问题	审查深度和精度不够，漏检率高
审查效果差	无法识别复杂代码缺陷和安全问题	代码质量把关形同虚设

本地小模型能力局限（模型本身能力不足，真实问题测试的效果不佳）：

无法检测硬编码密钥、密码泄露风险
无法识别 Token 传输安全漏洞
无法发现内存泄漏（监听未销毁）问题
无法预判空指针异常 NPE 风险
无法识别循环串行性能缺陷、代码重复异味

本质原因：7B 参数规模的小模型，在代码理解深度、推理能力、安全漏洞识别等方面存在天然局限性，纯粹是模型能力不足以支撑高质量代码审查需求。

5.2 远程模型核心信息

属性	值
模型名称	通义千问 Qwen3.6-Plus（或其他企业级大模型）
接口地址	`https://your-llm-api-endpoint/v1`
接口规范	兼容 OpenAI 标准格式，无缝适配现有 AI 审查服务
能力优势	支持全方位代码安全、性能、规范、漏洞审查，达到企业级生产标准

5.3 模型效果对比（真实实测）

swift 复制代码

┌──────────────────────────────────────────────────────────────────┐
│ 本地 qwen2.5:7b 效果（差）                                        │
├──────────────────────────────────────────────────────────────────┤
│ ❌ 仅检测基础语法、any类型、组件命名问题                           │
│ ❌ 无安全漏洞、性能、内存、空指针检测能力                           │
│ ❌ 推理速度慢，阻塞CI流程                                         │
└──────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────┐
│ 云端 qwen3.6-plus 效果（生产级）                                   │
├──────────────────────────────────────────────────────────────────┤
│ ✅ 拦截硬编码密钥、密码、Token泄露高危漏洞                         │
│ ✅ 检测内存泄漏、事件监听未销毁问题                               │
│ ✅ 检测空指针NPE风险、代码规范、类型安全                          │
│ ✅ 识别代码异味、重复代码、性能缺陷                               │
│ ✅ 区分P0阻塞级、P1优化级、P2建议级问题                          │
│ ✅ 推理速度快，不阻塞CI流水线                                     │
└──────────────────────────────────────────────────────────────────┘

5.4 迭代后网络适配（终极智能分流）

最终实现完美双向通信：

复制代码

AI服务调用外网大模型 → 自动走代理 your-proxy-ip:your-proxy-port
AI服务调用内网GitLab → 自动不走代理，直连访问，无劫持、无超时

六、GitLab Runner 部署与 CI/CD 流水线对接

GitLab Runner 作为 CI/CD 执行器，负责触发代码拉取、调用 AI 审查服务，是串联整个流程的入口，本节记录安装、注册、配置、排错全流程。

6.1 GitLab Runner 安装

依托全局代理，执行官方安装步骤：

bash 复制代码

# 1. 导入GitLab官方GPG密钥
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash

# 2. 安装 GitLab Runner
apt install -y gitlab-runner

6.2 Runner 注册（关联内网 GitLab 项目）

注册命令需填写内网 GitLab 地址、注册令牌、Runner 标签、执行器等信息（信息从 GitLab 项目后台获取）：

bash 复制代码

gitlab-runner register

按交互式提示依次填写：

GitLab 实例 URL：内网 GitLab 地址
注册令牌：项目/群组 Runner 令牌
Runner 描述：自定义名称（如：AI-Code-Review-Runner）
标签（tags）：流水线匹配标签，用于任务调度
执行器（executor）：选择 shell（本地执行）

6.3 GitLab Runner 基础管理命令

bash 复制代码

# 查看Runner运行状态
gitlab-runner status

# 启停服务
systemctl start gitlab-runner
systemctl stop gitlab-runner
systemctl restart gitlab-runner

# 设置开机自启
systemctl enable gitlab-runner

# 查看Runner日志
journalctl -u gitlab-runner -f --no-pager

6.4 流水线对接逻辑

markdown 复制代码

1. GitLab 项目配置 .gitlab-ci.yml 流水线文件，配置触发规则、任务脚本
        ↓
2. 流水线任务触发后，Runner 拉取代码，调用 http://内网IP:5001 AI 审查服务接口
        ↓
3. AI 服务转发请求至远程 qwen3.6-plus 模型，获取结果后回传给 Runner
        ↓
4. Runner 将审查结果展示在 GitLab 流水线日志中

6.5 GitLab Runner 核心踩坑记录

问题现象	根因分析	解决方案
Runner 无法访问内网 AI 服务（5001端口）	全局代理未配置 `no_proxy`，内网请求被转发至外网代理	检查 `/etc/environment` 内网网段豁免规则，重启服务器生效
CI 任务异常退出、任务被杀死	远程大模型推理耗时较长，CI 默认超时时间不足	在 GitLab 项目流水线配置中，延长 CI 任务全局超时时间
Runner 拉取 GitLab 代码失败	GitLab 内网地址未加入 `no_proxy`	在 `no_proxy` 中补充 GitLab 域名/IP
Token 安全问题	GitLab Token 从 Body 传参可能泄露到日志	优化 CI 脚本，将 GitLab Token 改为 Header 传参

七、全服务日常运维检查手册（一键巡检命令）

整理日常维护、故障排查的全套巡检命令，按服务分类，运维人员可直接复制执行：

7.1 综合资源检查

bash 复制代码

# 查看CPU核心数
nproc

# 查看内存使用
free -h

# 实时进程资源监控
top

7.2 Ollama 服务巡检（历史服务）

bash 复制代码

# 运行状态
systemctl status ollama

# 端口监听
ss -tuln | grep 11434

# 最近20条日志
journalctl -u ollama -n 20 --no-pager

# 实时日志
journalctl -u ollama -f --no-pager

7.3 AI 代码审查服务巡检（核心服务）

bash 复制代码

# 运行状态
systemctl status ai-review

# 实时日志（排错首选）
journalctl -u ai-review -f --no-pager

# 端口监听
ss -tuln | grep 5001

7.4 GitLab Runner 巡检

bash 复制代码

# Runner状态
gitlab-runner status

# 服务状态
systemctl status gitlab-runner

# 实时日志
journalctl -u gitlab-runner -f --no-pager

7.5 网络代理快速验证

bash 复制代码

# 外网连通测试（走代理）
curl -I https://www.baidu.com

# 本地接口免代理测试
curl --noproxy "*" http://127.0.0.1:5001

# 外网模型连通性测试（替换为实际的大模型接口地址）
curl -v https://your-llm-api-endpoint/v1

7.6 AI 服务接口测试

bash 复制代码

# 本地服务测试
curl -X POST http://127.0.0.1:5001/api/review \
-H "Content-Type: application/json" \
-H "token: test-token-123" \
-d '{"content":"function test(){return 1;}"}'

八、全流程问题汇总表（核心踩坑清单）

问题现象	根因分析	最终解决方案
curl 127.0.0.1 本地接口卡死、无响应	全局代理劫持本地回环请求	配置 `no_proxy` 豁免本地/内网地址，服务内清空代理变量
pip 安装包报错 externally-managed-environment	Debian Python 系统环境保护	安装时追加 `--break-system-packages`
OpenAI SDK 报错：unexpected keyword argument 'proxies'	openai 2.x 新版移除 proxies 参数	删除代码内 proxies 配置项
AI 服务启动失败 CHDIR	Systemd 工作目录配置错误	修正为项目真实路径 `/path/to/your/ai-review-service`
手动调用 AI 接口返回 401 未授权	服务内置内网鉴权	正常安全逻辑，无需处理
本地 qwen2.5:7b 推理速度极慢、效果差	纯 CPU 算力不足、模型体量偏大	废弃本地模型，切换远程 qwen3.6-plus 大模型
Ollama 报端口占用、反复重启	残留进程占用 11434 端口	`pkill -9 ollama && systemctl restart ollama`
CI 流水线任务超时退出	远程大模型推理耗时久	延长 GitLab CI 任务超时时间
Runner 无法拉取内网 GitLab 代码	GitLab 地址未加入免代理列表	在 `no_proxy` 中补充 GitLab 地址
切换远程模型后 Connection error	服务无代理，无法访问外网	配置服务代理 + 内外网分流
无法获取 GitLab MR 代码	Token 丢失/权限不足	重新配置有效 `GITLAB_TOKEN`，赋予 `read_api` 权限

九、架构总结、改造说明与运维优化建议

9.1 最终稳定架构

scss 复制代码

GitLab MR事件 → GitLab-Runner触发CI → AI审查服务(5001) → 远程 Qwen3.6-Plus 大模型 → 返回合规审查报告 → 合码门禁拦截/通过

9.2 当前整套架构优势

优势	说明
✅ 全服务 systemd 托管	开机自启、崩溃自动重启，无人值守稳定运行
✅ 智能代理分流	兼顾内网通信安全、外网模型调用
✅ 完成模型迭代	从本地测试模型升级为生产级云端大模型
✅ 全覆盖代码审查	安全、规范、性能、漏洞检测，满足生产合码门禁要求
✅ 全链路问题已修复	无遗留 BUG，可正式投入生产使用

9.3 后续运维优化建议

优化项	说明
超时优化	持续监控远程接口响应时长，动态调整 AI 服务、GitLab CI 双重超时配置
安全优化	限制 5001 端口访问源，仅放行内网网段，禁止公网访问
日志优化	配置日志轮转，防止长期运行日志文件膨胀占用磁盘
容灾优化	记录远程大模型备用接口地址，主接口异常时可快速切换
资源监控	新增服务器 CPU、内存、端口状态定时巡检，提前预警故障
Ollama 保留	保留 Ollama 服务，可作为离线备用审查方案

9.4 整体结论

整套环境从服务器初始化、网络代理、基础工具、Python 依赖、Ollama 本地模型、AI 审查服务、GitLab Runner 全流程部署完成，并完成本地模型 → 远程 qwen3.6-plus 模型的架构改造。

所有部署、改造过程中遇到的端口冲突、代理劫持、Python 依赖、服务自启、接口鉴权、模型性能、CI 超时等问题均已落地解决，整套服务运行稳定，可正式投入日常 GitLab 代码 MR/提交的自动化代码审查工作，本文可作为后续环境维护、复刻部署、问题排错的标准文档。

适用场景：Debian/Ubuntu 系列服务器部署 GitLab-Runner + AI 代码审查服务 + 远程大模型

GitLab-Runner + AI 代码审查服务 + 远程大模型 全套部署运维实战

说明

一、服务器基础环境信息

1.1 硬件配置

1.2 网络与代理环境

1.3 最终上线服务清单

1.4 架构迭代历程

1.5 整体业务架构（改造后）

二、服务器基础环境初始化（前置基础操作）

2.1 全局网络代理配置（核心前置，重中之重）

2.1.1 全局代理配置文件

2.1.2 最终完整配置内容

2.1.3 配置生效命令

2.1.4 代理临时测试命令

2.1.5 代理相关踩坑记录

2.2 系统更新与基础工具安装

2.2.1 系统更新命令

2.2.2 安装运维必备工具

2.3 Python 基础环境与依赖前置处理

2.3.1 核心报错与通用解决方案

三、历史服务：Ollama 本地大模型部署（原方案，现已弃用）

3.1 Ollama 安装与本地模型拉取

3.1.1 官方一键安装命令

3.1.2 拉取本地代码审查模型

3.2 Ollama Systemd 开机自启配置

3.2.1 完整服务配置文件

3.2.2 Ollama 服务管理全套命令

3.3 Ollama 高频问题与解决方案

3.4 本地模型可用性验证

四、AI 代码审查服务（ai-review-server）部署 + 改造对接远程 qwen3.6-plus

4.1 服务基础信息

4.2 进入项目目录 & 安装 Python 全量依赖

4.2.1 进入工作目录

4.2.2 安装项目依赖

4.2.3 OpenAI SDK 版本报错修复

4.3 环境变量配置文件 .env（核心改造点：切换远程大模型）

4.4 Systemd 开机自启配置

4.4.1 服务配置文件

4.4.2 AI 服务全套管理命令

4.5 AI 服务踩坑记录（实操问题）

4.6 服务连通性验证

五、核心架构迭代：本地模型升级为阿里云 Qwen3.6-Plus

5.1 迭代核心原因（真实业务痛点）

5.2 远程模型核心信息

5.3 模型效果对比（真实实测）

5.4 迭代后网络适配（终极智能分流）

六、GitLab Runner 部署与 CI/CD 流水线对接

6.1 GitLab Runner 安装

6.2 Runner 注册（关联内网 GitLab 项目）

6.3 GitLab Runner 基础管理命令

6.4 流水线对接逻辑

6.5 GitLab Runner 核心踩坑记录

七、全服务日常运维检查手册（一键巡检命令）

7.1 综合资源检查

7.2 Ollama 服务巡检（历史服务）

7.3 AI 代码审查服务巡检（核心服务）

7.4 GitLab Runner 巡检

7.5 网络代理快速验证

7.6 AI 服务接口测试

八、全流程问题汇总表（核心踩坑清单）

九、架构总结、改造说明与运维优化建议

9.1 最终稳定架构

9.2 当前整套架构优势

9.3 后续运维优化建议

9.4 整体结论

GitLab-Runner + AI 代码审查服务 + 远程大模型全套部署运维实战

4.3 环境变量配置文件 `.env`（核心改造点：切换远程大模型）