把 GitHub Issue 的“第一轮脏活”交给 AI：Issue AI Agent 接入蓝耘元生代实战

本文我选了 2026 年 5 月开源的 Issue AI Agent，把它接到蓝耘元生代 MaaS，并放进 GitHub Actions：新 Issue 创建后，自动判断类型和优先级、检查重复问题，再生成一条可供维护者审核的回复。

先说这次要解决的问题

维护小型开源项目时，真正消耗精力的往往不是写代码，而是处理描述质量参差不齐的 Issue。

有人只写一句"启动失败"；有人贴了几百行日志，却没说系统版本；还有不少功能建议和历史 Issue 重复。维护者打开一条新 Issue 后，通常要先做这些事：

判断它是 Bug、功能建议、使用问题还是文档问题；
根据影响范围判断优先级；
搜索仓库里有没有相似 Issue；
检查复现步骤、版本号和日志是否齐全；
打标签并回复提问者。

单条处理不难，难的是重复。项目一忙，Issue 就会积压。

我这次选用的开源项目是 Issue AI Agent。它在 2026 年 5 月发布，形态很轻：本质上是一个 GitHub Action，不需要单独准备数据库或常驻服务器。项目原生支持 OpenAI 兼容接口，正好可以通过蓝耘元生代的统一 API 接入模型。

这不是把接口地址改掉就结束。完整链路是：

text 复制代码

用户创建 Issue
    ↓
GitHub Actions 被触发
    ↓
Issue AI Agent 读取标题、正文和仓库配置
    ↓
调用蓝耘元生代 MaaS 模型
    ↓
返回类型、优先级和回复内容
    ↓
搜索历史 Issue，进行重复问题确认
    ↓
自动添加标签，并发布回复

蓝耘在这个项目里承担的是模型服务层。GitHub 负责事件触发，Issue AI Agent 负责流程编排，蓝耘负责把 Issue 文本交给指定模型推理，并通过 OpenAI 兼容接口返回结构化结果。

为什么选蓝耘，而不是自己部署模型

一开始我也考虑过本地部署。Issue 分类并不要求模型持续占满 GPU，看起来用一台机器跑开源模型就行。但认真算了一下，这个场景的请求是离散的：可能半天没有新 Issue，也可能发布新版本后突然集中出现十几条。为了偶发请求一直维护推理服务，机器利用率不高，还要处理模型下载、显存、服务重启和接口鉴权。

MaaS 更适合这种"平时请求少、忙时突然增加"的任务。

我选择蓝耘主要看中三点：

蓝耘提供 OpenAI 兼容接口，Issue AI Agent 已经支持自定义 llm-base-url，不需要改它的 TypeScript 源码；
模型 ID 由配置文件管理，后续想换 DeepSeek、Qwen 或其他模型，不用重写 GitHub Action；
API Key、调用入口和模型统一放在一个平台管理，适合继续接入日志总结、PR 摘要等任务。

几类方案没有绝对高下，适用边界不同：

方案	接入工作量	运维工作	模型切换	更适合什么情况
本地部署开源模型	较高	较高	需要准备不同模型或服务	数据不能离开内网、调用量长期稳定
直接连接单一模型厂商	较低	低	通常要改模型和供应商配置	团队长期固定使用某一家模型
蓝耘元生代 MaaS	较低	低	统一接口下修改模型 ID	希望快速接入并保留多模型选择

这里不做"谁碾压谁"的结论。对我的 Issue 分诊工具来说，少维护一套推理服务、能直接复用 OpenAI SDK，比追求极限定制更实际。

准备蓝耘 MaaS 的三项配置

接入前需要准备：API Key、Base URL 和模型 ID。

1. 创建 API Key

登录蓝耘元生代 MaaS 后，进入 API KEY 管理页面，新建一个只用于 GitHub Actions 的密钥。不要把真实密钥写进工作流文件，更不要放进公开仓库。

蓝耘官方文档给出的 OpenAI 兼容 Base URL 是：

text 复制代码

https://maas-api.lanyun.net/v1

完整的聊天接口由 SDK 自动拼接为：

text 复制代码

https://maas-api.lanyun.net/v1/chat/completions

2. 在模型列表复制模型 ID

我在配置示例里使用官方文档出现过的模型 ID：

text 复制代码

/maas/deepseek-ai/DeepSeek-V3.2

模型名称必须完整复制。展示名是"DeepSeek-V3.2"，不代表接口里的 model 可以只写 DeepSeek-V3.2。少了前面的命名空间，服务端就可能找不到模型。

蓝耘 MaaS 模型列表或模型详情页，画面中应能看到完整模型 ID。

3. 先做一次最小调用

在折腾 GitHub Actions 前，建议先用本地脚本检查 Key、地址和模型名。这样如果后面工作流失败，至少能排除蓝耘账号配置问题。

python 复制代码

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["LANYUN_API_KEY"],
    base_url="https://maas-api.lanyun.net/v1",
)

response = client.chat.completions.create(
    model="/maas/deepseek-ai/DeepSeek-V3.2",
    messages=[
        {
            "role": "user",
            "content": "请只回复：蓝耘接口连接成功",
        }
    ],
    temperature=0,
)

print(response.choices[0].message.content)

安装依赖并运行：

bash 复制代码

pip install "openai>=1.0"
export LANYUN_API_KEY="替换为自己的密钥"
python test_lanyun.py

Windows PowerShell 设置环境变量的写法是：

powershell 复制代码

$env:LANYUN_API_KEY="替换为自己的密钥"
python test_lanyun.py

这一步看起来普通，但很有用。它把问题拆成两段：本地调用失败，就查 Key、模型名和 Base URL；本地成功而 Action 失败，再查 GitHub Secrets 和工作流配置。

把蓝耘密钥放进 GitHub Secrets

进入目标仓库：

text 复制代码

Settings
→ Secrets and variables
→ Actions
→ New repository secret

新建 Secret：

text 复制代码

Name: LANYUN_API_KEY
Secret: sk-xxxxxxxxxxxxxxxx

工作流只能通过 ${``{ secrets.LANYUN_API_KEY }} 读取它。GitHub 日志会隐藏 Secret，但前提是我们没有主动把密钥拼进输出字符串。

接入 Issue AI Agent

项目原版工作流默认以 Anthropic 为例，但它同时支持 OpenAI Provider 和自定义 Base URL，所以不需要 fork 源码。

在目标仓库创建 .github/workflows/issue-ai.yml：

yaml 复制代码

name: Issue AI Agent

on:
  issues:
    types: [opened]
  issue_comment:
    types: [created]

jobs:
  triage:
    runs-on: ubuntu-latest
    permissions:
      issues: write
      contents: read

    steps:
      - uses: alexyan0431/issue-ai-agent@v1
        with:
          openai-api-key: ${{ secrets.LANYUN_API_KEY }}
          llm-provider: openai
          llm-base-url: https://maas-api.lanyun.net/v1
          config-path: .github/issue-ai.yml

这里有四个关键点：

openai-api-key 传入蓝耘 Key；
llm-provider 必须选 openai；
llm-base-url 只填到 /v1；
issues: write 不能省，否则 Action 能分析，却没有权限打标签和回复。

接着创建 .github/issue-ai.yml，指定蓝耘模型和分诊规则：

yaml 复制代码

enabled: true

features:
  classify: true
  reply: true
  duplicateSearch: true
  commentReply: true

label_mapping:
  bug: ["bug"]
  feature: ["enhancement"]
  question: ["question"]
  docs: ["documentation"]
  duplicate: ["duplicate"]
  invalid: ["invalid"]
  security: ["security"]

security:
  max_issue_length: 10000

exclude:
  labels: ["wontfix", "skip-ai"]
  users: ["dependabot[bot]"]

llm:
  provider: openai
  model: /maas/deepseek-ai/DeepSeek-V3.2
  max_tokens: 2048

max_issue_length 建议保留。Issue 内容来自外部用户，不能默认它永远简短、正常。限制长度既能控制 Token 消耗，也能避免一条超长日志把有效上下文挤出去。

用三条 Issue 验证，不拿"你好"糊弄过去

单次聊天成功不能证明项目真的可用。我准备了三类输入，分别检查分类、优先级和信息追问。

用例一：高优先级 Bug

标题：

text 复制代码

升级 2.4.0 后登录页白屏，所有用户无法进入后台

正文：

text 复制代码

环境：Ubuntu 22.04、Node.js 20、Chrome 126
版本：2.4.0

从 2.3.7 升级后，登录页提交账号密码会立即白屏。
控制台报错：TypeError: Cannot read properties of undefined (reading 'token')
回退到 2.3.7 后恢复正常。
目前生产环境所有账号都无法登录。

期望结果：

text 复制代码

category: bug
priority: critical 或 high
labels: bug, priority: critical/high
reply: 确认影响范围，并追问最小复现或相关网络请求信息

这条 Issue 包含版本、环境、错误日志和回退验证，信息已经比较完整。模型不应该再机械地问"请提供版本号"，而要针对缺失信息继续追问。

运行后应该看哪里

提交测试 Issue 后，进入仓库的 Actions 页面，打开 Issue AI Agent 任务。正常情况下可以看到工作流依次完成分类、标签映射、重复项搜索和回复。

Issue 页面会出现两类变化：

自动添加分类标签和优先级标签；
机器人发布一条结合当前内容生成的回复。

本人仓库的 GitHub Actions 成功日志

蓝耘 MaaS 调用记录或用量变化

实际最容易卡住的地方：Base URL 填多了

这类接入最常见的问题不是代码，而是路径。

我最初容易写成：

yaml 复制代码

llm-base-url: https://maas-api.lanyun.net/v1/chat/completions

看起来很合理，因为这确实是完整聊天接口。但 OpenAI SDK 会在 Base URL 后继续拼接 /chat/completions。最终请求可能变成：

text 复制代码

https://maas-api.lanyun.net/v1/chat/completions/chat/completions

结果就是 404。

正确写法只到 /v1：

yaml 复制代码

llm-base-url: https://maas-api.lanyun.net/v1

排查时不要一上来反复换 Key。先看错误类型：

现象	优先检查
401 / Unauthorized	GitHub Secret 名称、Key 是否有效、是否多写了 `Bearer`
404 / Not Found	Base URL 是否填成了完整接口
model not found	是否复制了完整模型 ID
能分类但不能打标签	工作流是否声明 `issues: write`，仓库中标签是否存在
回复内容被截断	`max_tokens` 是否过小，Issue 是否过长

另一个小坑是标签。Issue AI Agent 会把模型分类映射成仓库标签，但 GitHub 仓库未必提前存在 enhancement、documentation 或优先级标签。正式使用前，最好按配置先创建这些标签，或者把 label_mapping 改成仓库已有名称。

如果不想让 AI 直接发言

自动回复很省事，但不一定适合所有仓库。尤其是安全漏洞、付费问题、法律合规问题，直接让机器人对外回复有风险。

更稳妥的上线顺序是：

yaml 复制代码

features:
  classify: true
  reply: false
  duplicateSearch: true
  commentReply: false

先让它只做分类、优先级和查重，维护者观察一段时间。分类稳定后，再打开自动回复。

仓库还可以约定 skip-ai 标签。遇到不希望模型处理的 Issue，维护者加上该标签即可跳过。这个开关很朴素，但比设计一套复杂的审批系统实用。

蓝耘在这套方案中带来了什么

接入前，维护者要逐条阅读、搜索、打标签和组织回复。接入后，第一轮整理由 Action 自动完成，维护者主要做两件事：检查判断是否合理，以及处理真正需要技术决策的问题。

流程上的变化比较明确：

环节	接入前	接入后
Issue 类型判断	人工阅读	模型先分类，人工复核
优先级判断	依赖维护者经验	按统一 Prompt 给出初判
重复问题搜索	手动关键词检索	GitHub 搜索后由模型确认
首次回复	手工组织语言	自动生成或作为回复草稿
模型服务	自建或单独对接	蓝耘统一 API 提供推理

蓝耘的作用并不是替代 GitHub，也不是替代 Issue AI Agent。它解决的是模型接入和推理服务问题，让开源工具不必绑定某一个默认模型供应商。

对后续扩展也有好处。例如：

Issue 分类使用响应较快的通用模型；
复杂 Bug 的日志分析切到推理能力更强的模型；
周报任务使用长上下文模型汇总一周 Issue；
所有任务仍通过同一套 MaaS 接口和 Key 管理方式接入。

本文先用一个模型跑通闭环，没有为了"多模型"硬加复杂度。等真实 Issue 数量起来后，再根据错误率、耗时和 Token 使用量决定是否拆分模型，比较靠谱。

当前限制也要说清楚

这套方案能减少机械工作，但不能代替维护者做最终判断。

第一，优先级依赖上下文。同样是"登录失败"，个人测试环境失败和生产环境全部账号失败，严重程度完全不同。Issue 描述不清时，模型只能根据有限信息推测。

第二，重复检测不是向量数据库级别的全库语义检索。它先依赖 GitHub 搜索找候选，再由模型确认。标题和关键词差异太大时，仍可能漏掉历史 Issue。

第三，外部用户输入不能被当成可信指令。项目已经提供长度限制和不可信内容标记，但公开仓库仍需要防范 Prompt Injection。至少不要给 Action 超出 issues: write 和 contents: read 的权限。

第四，自动回复要保守。模型可以帮忙追问信息、确认已收到建议，但不应擅自承诺修复日期，更不能在未经核实的情况下声称"问题已经解决"。

这次接入最让我满意的地方，不是模型能把 bug 标签贴上去，而是整个项目没有新增常驻服务。

GitHub 事件负责触发，Issue AI Agent 负责流程，蓝耘元生代负责模型推理。工作流和规则都留在仓库里，API Key 放在 GitHub Secrets 中。想暂停时关掉工作流，想换模型时改一行模型 ID，维护成本比较低。

如果你的仓库每天只有一两条 Issue，这套工具不会带来"十倍效率"这种夸张变化。但在发版、活动或用户集中反馈时，它能先把问题排好队，让维护者打开 Issue 列表时不再面对一片没有标签的标题。

这就够实用了啊。