基于AI Agent的GitHub与Discord问题自动化处理实践指南

在实际软件开发中项目维护者常常面临一个共同的痛点GitHub Issues 和 Discord 社区频道中充斥着大量重复、琐碎或信息不全的问题。手动回复不仅耗时而且难以保证一致性。SeaTicket 这类 AI Agent 的出现正是为了解决这一工程效率问题。它通过理解自然语言自动分析问题上下文并尝试给出解决方案或引导用户提供更多信息从而将开发者从重复性的支持工作中解放出来。本文将从工程实践角度探讨如何理解、搭建和集成一个类似 SeaTicket 的 AI Agent用于自动化处理 GitHub 和 Discord 上的问题。我们将从核心概念入手逐步完成环境准备、依赖配置、核心逻辑实现并最终运行一个最小可用的原型。文章还会深入分析实现过程中的关键参数、常见错误以及生产环境部署的注意事项。无论你是希望为自己的开源项目引入自动化支持还是对 AI Agent 的工程化落地感兴趣这篇文章都将提供一个清晰的实践路径。1. 理解 AI Agent 在问题处理中的工作机制在开始编码之前我们需要明确 AI Agent 在此场景下的工作边界和核心流程。它不是一个全知全能的 AI而是一个基于规则和大语言模型LLM能力组合的自动化工作流。1.1 核心工作流程从接收到响应的闭环一个用于处理 Issues 的 AI Agent其典型工作流可以抽象为以下几个步骤事件监听与触发Agent 需要持续监听特定来源的事件。对于 GitHub这通常是 Webhook对于 Discord则是通过 Bot 监听消息事件。内容提取与预处理从事件负载中提取出关键信息如 Issue 标题、正文、评论、发帖人、Discord 频道/消息 ID 等。预处理可能包括清理 Markdown 格式、提取代码片段、识别错误日志模式等。上下文构建与意图识别将提取的信息与可能的额外上下文如项目文档、过往相似 Issue、代码库结构结合构建一个清晰的提示Prompt发送给 LLM。LLM 的核心任务是识别用户意图是提问、报 Bug、求功能还是闲聊并判断是否需要以及如何回应。决策与执行根据 LLM 的分析结果Agent 执行相应动作。这可能包括直接回复在 Issue 下评论或在 Discord 频道中发送消息。执行操作给 Issue 打标签如bugquestionduplicate、分配责任人、关闭重复 Issue。请求更多信息引导用户提供版本号、错误日志、复现步骤等关键信息。转发或升级对于复杂问题可以 项目维护者或将其添加到特定看板。日志与反馈记录每一次交互的输入、输出和决策用于后续分析 Agent 的有效性和优化 Prompt。1.2 技术栈选型与关键组件实现这样一个 Agent通常涉及以下技术栈的选型后端框架/运行时Node.js (JavaScript/TypeScript) 或 Python 是常见选择因其拥有丰富的社区库和异步处理能力。本文将以 Python 为例进行演示。LLM 接口OpenAI GPT 系列、Anthropic Claude、或开源的 Llama 系列、DeepSeek 等。通过其提供的 API 完成自然语言理解与生成。平台 SDKGitHub使用PyGithub或 GitHub 的 REST API/GraphQL API。Discord使用discord.py(Python) 或discord.js(Node.js) 库来创建 Bot。向量数据库可选但推荐用于存储项目文档、历史 Issue 等实现基于语义的相似问题检索RAG。常用工具有 Chroma、Pinecone、Weaviate 或简单的本地 FAISS。工作流编排可选对于复杂逻辑可以使用 LangChain、LlamaIndex 等框架来编排 Prompt、工具调用和记忆管理。部署与运维可部署在云服务器、Serverless 函数如 AWS Lambda Vercel或容器中。2. 环境准备与项目初始化我们首先搭建一个最小化的 Python 项目环境并安装核心依赖。2.1 创建项目结构与虚拟环境在本地创建一个新的项目目录并初始化 Python 虚拟环境这能有效隔离项目依赖。# 创建项目目录并进入 mkdir seaticket-agent-demo cd seaticket-agent-demo # 创建虚拟环境使用 Python 3.8 python3 -m venv venv # 激活虚拟环境 # 在 macOS/Linux 上 source venv/bin/activate # 在 Windows 上 # venv\Scripts\activate # 创建基础项目结构 mkdir -p src/{github_agent, discord_agent, core} touch src/__init__.py touch src/core/__init__.py src/core/config.py src/core/llm_client.py touch src/github_agent/__init__.py src/github_agent/webhook_handler.py touch src/discord_agent/__init__.py src/discord_agent/bot.py touch requirements.txt touch .env.example touch main.py2.2 安装核心依赖编辑requirements.txt文件添加以下依赖# 核心HTTP与异步 fastapi0.104.1 uvicorn[standard]0.24.0 httpx0.25.1 # 平台SDK PyGithub2.1.1 discord.py2.3.2 # LLM 接口 (以 OpenAI 为例) openai1.3.0 # 环境变量管理 python-dotenv1.0.0 # 向量数据库 (以轻量级Chroma为例) chromadb0.4.18 langchain0.0.350 # 用于简化RAG和Chain的构建 # 工具类 pydantic2.5.0 pydantic-settings2.1.0然后使用 pip 安装这些依赖pip install -r requirements.txt注意生产环境中务必在requirements.txt中固定主要依赖的版本号避免因依赖库自动升级导致的不兼容问题。2.3 配置环境变量创建.env文件请勿提交到版本库用于存储敏感信息和配置。.env.example文件则列出了所有需要的环境变量供其他协作者参考。.env.example内容# OpenAI API 配置 OPENAI_API_KEYyour_openai_api_key_here OPENAI_MODELgpt-4-turbo-preview # 或 gpt-3.5-turbo # GitHub App 或 Personal Access Token 配置 GITHUB_ACCESS_TOKENyour_github_personal_access_token_here GITHUB_WEBHOOK_SECRETyour_github_webhook_secret_here # Discord Bot 配置 DISCORD_BOT_TOKENyour_discord_bot_token_here # 应用配置 AGENT_NAMESeaTicketAssistant LOG_LEVELINFO你需要前往相应平台创建 Token 并填入.env文件OpenAI API Key在 OpenAI 平台创建。GitHub Token在 GitHub Settings - Developer settings - Personal access tokens - Tokens (classic) 中创建需要repo和write:discussion权限。GitHub Webhook Secret在 GitHub 仓库的 Settings - Webhooks 页面创建 Webhook 时随机生成。Discord Bot Token在 Discord Developer Portal 创建应用和 Bot 后获取。3. 构建核心模块配置、LLM 客户端与上下文管理在编写平台特定的 Agent 之前我们先构建一些共享的核心模块。3.1 统一配置管理使用pydantic-settings可以方便地管理配置并验证环境变量。创建src/core/config.pyfrom pydantic_settings import BaseSettings from pydantic import Field class Settings(BaseSettings): # OpenAI openai_api_key: str Field(..., aliasOPENAI_API_KEY) openai_model: str Field(gpt-3.5-turbo, aliasOPENAI_MODEL) # GitHub github_access_token: str Field(..., aliasGITHUB_ACCESS_TOKEN) github_webhook_secret: str Field(..., aliasGITHUB_WEBHOOK_SECRET) # Discord discord_bot_token: str Field(..., aliasDISCORD_BOT_TOKEN) # Agent agent_name: str Field(SeaTicketAssistant, aliasAGENT_NAME) log_level: str Field(INFO, aliasLOG_LEVEL) class Config: env_file .env extra ignore # 忽略未定义的额外环境变量 settings Settings()3.2 封装 LLM 客户端创建一个简单的 LLM 客户端封装与 OpenAI API 的交互。创建src/core/llm_client.pyimport logging from typing import List, Dict, Any, Optional from openai import OpenAI from src.core.config import settings logger logging.getLogger(__name__) class LLMClient: def __init__(self): self.client OpenAI(api_keysettings.openai_api_key) self.model settings.openai_model async def generate_response( self, system_prompt: str, user_prompt: str, temperature: float 0.2, # 较低的温度使输出更确定 max_tokens: int 500 ) - str: 调用 LLM 生成回复。 Args: system_prompt: 定义 AI 角色和行为的系统提示。 user_prompt: 用户输入的问题或上下文。 temperature: 生成文本的随机性0-1之间。 max_tokens: 生成回复的最大长度。 Returns: LLM 生成的文本回复。 try: response await self.client.chat.completions.create( modelself.model, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperaturetemperature, max_tokensmax_tokens ) content response.choices[0].message.content logger.debug(fLLM 响应: {content}) return content.strip() if content else except Exception as e: logger.error(f调用 LLM API 失败: {e}) # 生产环境应考虑更优雅的降级策略如返回预定义的提示 return f抱歉我暂时无法处理这个问题。错误: {type(e).__name__} async def analyze_issue_intent( self, title: str, body: str, labels: List[str] ) - Dict[str, Any]: 分析 Issue 的意图并返回结构化决策。 这是一个简化示例实际应用可能需要更复杂的提示工程。 system_prompt 你是一个开源项目的 AI 助手。你的任务是分析用户提交的 GitHub Issue判断其意图并决定如何回应。 请以 JSON 格式回复包含以下字段 - intent: 字符串可选值 [bug_report, feature_request, question, documentation, duplicate, invalid, need_more_info] - confidence: 浮点数0到1之间表示判断的置信度。 - suggested_label: 字符串建议给 Issue 添加的标签如 bug, enhancement。 - response_template: 字符串一个简短的回复模板用于直接回复用户。如果 intent 是 need_more_info应包含需要用户补充的信息列表。 - should_assign: 布尔值是否建议分配给人处理。 user_prompt f Issue 标题: {title} Issue 正文: {body} 现有标签: {, .join(labels) if labels else 无} 请分析上述 Issue。 llm_response await self.generate_response(system_prompt, user_prompt) # 这里需要解析 LLM 返回的 JSON。实际中应使用 OpenAI 的 JSON 模式或函数调用功能确保格式。 # 为简化我们假设返回的是可解析的 JSON 字符串。 import json try: return json.loads(llm_response) except json.JSONDecodeError: logger.warning(f无法解析 LLM 的 JSON 响应: {llm_response}) # 返回一个安全的默认决策 return { intent: question, confidence: 0.5, suggested_label: , response_template: 感谢您的反馈。我们已经注意到这个问题会尽快查看。, should_assign: False } # 创建全局客户端实例 llm_client LLMClient()4. 实现 GitHub Issue 处理 Agent现在我们实现一个能够处理 GitHub Webhook 的 FastAPI 应用作为 GitHub Agent 的入口。4.1 创建 GitHub Webhook 处理器创建src/github_agent/webhook_handler.pyimport hashlib import hmac import json import logging from typing import Dict, Any from fastapi import FastAPI, Request, HTTPException, Header, BackgroundTasks from github import Github, GithubIntegration from src.core.config import settings from src.core.llm_client import llm_client logger logging.getLogger(__name__) app FastAPI(titleGitHub AI Agent Webhook) # 初始化 GitHub SDK 客户端 github_client Github(settings.github_access_token) def verify_github_signature(payload_body: bytes, signature_header: str) - bool: 验证 GitHub Webhook 签名确保请求来源可信。 if not signature_header: return False sha_name, signature signature_header.split() if sha_name ! sha256: return False expected_signature hmac.new( keysettings.github_webhook_secret.encode(), msgpayload_body, digestmodhashlib.sha256 ).hexdigest() return hmac.compare_digest(signature, expected_signature) async def handle_issue_opened(event_data: Dict[str, Any]): 处理新 Issue 被创建的事件。 issue event_data[issue] repo_name event_data[repository][full_name] issue_number issue[number] title issue[title] body issue[body] or labels [label[name] for label in issue[labels]] logger.info(f处理新 Issue: {repo_name}#{issue_number} - {title}) # 步骤1: 使用 LLM 分析 Issue 意图 analysis await llm_client.analyze_issue_intent(title, body, labels) logger.info(fIssue 分析结果: {analysis}) # 步骤2: 根据分析结果执行动作 repo github_client.get_repo(repo_name) github_issue repo.get_issue(issue_number) # 2.1 添加建议的标签 suggested_label analysis.get(suggested_label) if suggested_label and suggested_label not in labels: try: github_issue.add_to_labels(suggested_label) logger.info(f已添加标签: {suggested_label}) except Exception as e: logger.error(f添加标签失败: {e}) # 2.2 如果需要更多信息则回复引导性评论 if analysis.get(intent) need_more_info: response_template analysis.get(response_template, 请提供更多信息例如...) comment_body f** {settings.agent_name} 提示:**\n\n{response_template} try: github_issue.create_comment(comment_body) logger.info(已发布请求更多信息的评论。) except Exception as e: logger.error(f发布评论失败: {e}) # 2.3 如果是明确的 Bug 或功能请求可以自动分配这里示例为分配给仓库拥有者 if analysis.get(should_assign) and analysis.get(confidence, 0) 0.7: try: # 获取仓库拥有者作为默认分配者 repo_owner_login repo.owner.login github_issue.add_to_assignees(repo_owner_login) logger.info(f已分配 Issue 给: {repo_owner_login}) except Exception as e: logger.error(f分配 Issue 失败: {e}) # 2.4 对于重复或无效的 Issue可以考虑自动关闭需谨慎此处仅记录日志 if analysis.get(intent) in [duplicate, invalid] and analysis.get(confidence, 0) 0.8: logger.info(f检测到高置信度的 {analysis[intent]} Issue建议人工复核后关闭。) # github_issue.edit(stateclosed) # 谨慎启用自动关闭 app.post(/webhook/github) async def github_webhook( request: Request, background_tasks: BackgroundTasks, x_hub_signature_256: str Header(None), x_github_event: str Header(None) ): 接收 GitHub Webhook 的主端点。 payload_body await request.body() # 验证签名生产环境必须启用 if not verify_github_signature(payload_body, x_hub_signature_256): raise HTTPException(status_code403, detailInvalid signature) event_type x_github_event event_data await request.json() logger.debug(f收到 GitHub 事件: {event_type}) # 只处理我们关心的事件类型 if event_type issues: action event_data.get(action) if action opened: # 将耗时的处理放入后台任务避免阻塞 Webhook 响应 background_tasks.add_task(handle_issue_opened, event_data) return {status: accepted, message: Issue opened event is being processed.} elif action labeled: # 可以处理标签变更等事件 pass return {status: ignored, message: fEvent {event_type}.{action} is not handled.}4.2 编写主应用入口编辑main.py用于启动 Web 服务import uvicorn import logging from src.github_agent.webhook_handler import app as github_app from src.core.config import settings # 配置日志 logging.basicConfig( levelgetattr(logging, settings.log_level.upper()), format%(asctime)s - %(name)s - %(levelname)s - %(message)s ) if __name__ __main__: # 启动 FastAPI 应用 uvicorn.run( main:github_app, # 指向我们的 FastAPI 应用实例 host0.0.0.0, port8000, reloadTrue # 开发环境启用热重载 )5. 实现 Discord 社区 Bot AgentDiscord Bot 的实现逻辑与 GitHub Webhook 类似但交互是实时的。我们创建一个简单的 Bot 来监听特定频道的消息并做出响应。5.1 创建 Discord Bot 处理器创建src/discord_agent/bot.pyimport discord from discord.ext import commands import logging from src.core.config import settings from src.core.llm_client import llm_client logger logging.getLogger(__name__) # 设置 Bot 意图需要读取消息内容和成员列表 intents discord.Intents.default() intents.message_content True intents.members True bot commands.Bot(command_prefix!, intentsintents) bot.event async def on_ready(): Bot 登录成功时触发。 logger.info(fBot 已登录为 {bot.user}) bot.event async def on_message(message): 监听所有消息。避免 Bot 响应自己的消息并可以设置触发条件。 # 如果消息是 Bot 自己发的忽略 if message.author bot.user: return # 示例1如果被 提及则回复 if bot.user.mentioned_in(message): # 移除提及标记获取纯文本内容 content_clean message.content.replace(f{bot.user.id}, ).strip() if not content_clean: content_clean 你好 # 调用 LLM 生成回复 system_prompt f你是一个名为{settings.agent_name}的 Discord 社区助手友善且乐于助人。请用简短、清晰的语言回答用户关于本开源项目的问题。如果问题与项目无关可以礼貌地表示你主要处理项目相关咨询。 llm_response await llm_client.generate_response(system_prompt, content_clean) # 发送回复 await message.channel.send(f{message.author.mention} {llm_response}) return # 示例2在特定频道例如 #support自动响应关键词 if message.channel.name support and error in message.content.lower(): # 这里可以集成更复杂的逻辑比如分析错误日志 await message.channel.send(f{message.author.mention} 看起来你遇到了一个错误。可以尝试提供完整的错误日志和复现步骤这样更容易定位问题哦) return # 必须调用此方法否则其他命令监听器不会触发 await bot.process_commands(message) bot.command(nameissue) async def create_issue(ctx, *, description: str): 一个示例命令让用户通过 Bot 快速创建 GitHub Issue。 # 这里可以集成 GitHub API将 description 创建为一个新的 Issue # 为简化示例我们仅模拟并回复 logger.info(f用户 {ctx.author} 请求创建 Issue: {description}) await ctx.send(f收到已记录你的反馈: {description}。维护者会尽快查看。) # 实际实现调用 PyGithub 创建 Issue # repo.create_issue(titlesummary, bodydescription, assignee...) def run_bot(): 启动 Discord Bot。 bot.run(settings.discord_bot_token)5.2 集成并运行多个 Agent修改main.py使其能够同时运行 FastAPI Webhook 服务和 Discord Bot在实际部署中它们可能作为独立的进程或服务运行。import uvicorn import logging import threading from src.github_agent.webhook_handler import app as github_app from src.discord_agent.bot import run_bot from src.core.config import settings logging.basicConfig( levelgetattr(logging, settings.log_level.upper()), format%(asctime)s - %(name)s - %(levelname)s - %(message)s ) def start_fastapi(): 在一个线程中启动 FastAPI 服务。 uvicorn.run( github_app, host0.0.0.0, port8000, reloadFalse # 生产环境或线程中应关闭 reload ) def start_discord_bot(): 启动 Discord Bot。 run_bot() if __name__ __main__: logger.info(启动 SeaTicket AI Agent 服务...) # 由于 uvicorn.run() 和 bot.run() 都是阻塞的我们使用线程并行运行 fastapi_thread threading.Thread(targetstart_fastapi, daemonTrue) discord_thread threading.Thread(targetstart_discord_bot, daemonTrue) fastapi_thread.start() discord_thread.start() # 等待所有线程实际上会一直运行直到被中断 fastapi_thread.join() discord_thread.join()6. 运行验证与结果分析完成代码编写后我们需要验证整个流程是否跑通。6.1 本地运行与测试启动服务确保虚拟环境已激活并在项目根目录运行python main.py你应该看到日志输出表明 FastAPI 服务在http://0.0.0.0:8000启动并且 Discord Bot 尝试登录。配置 GitHub Webhook将你的服务暴露到公网。开发环境可以使用ngrok或localtunnel等工具创建临时隧道。# 安装 ngrok 后在另一个终端运行 ngrok http 8000复制 ngrok 生成的https://xxxx.ngrok.io地址。进入你的 GitHub 仓库 - Settings - Webhooks - Add webhook。Payload URL 填写https://xxxx.ngrok.io/webhook/github。Content type 选择application/json。Secret 填写你在.env中设置的GITHUB_WEBHOOK_SECRET。选择触发事件仅勾选Issues。点击 Add webhook。测试 GitHub Issue 创建在你的仓库创建一个新的 Issue。观察你的服务终端日志应该能看到处理新 Issue和Issue 分析结果的日志。回到 GitHub Issue 页面你应该能看到 AI Agent 自动添加的标签和/或评论。测试 Discord Bot将你的 Discord Bot 邀请到服务器。在任意频道 你的 Bot 并提问例如SeaTicketAssistant 如何安装这个项目。Bot 应该会 你并回复一个由 LLM 生成的答案。6.2 关键配置参数与调优Agent 的行为很大程度上由 Prompt 和 LLM 参数控制。以下是一些关键参数及其影响参数所在位置建议值/范围作用与影响temperatureLLMClient.generate_response0.1 - 0.3控制回复的随机性。值越低回复越确定、一致值越高回复越有创造性但可能不稳定。对于问题分类和标准回复建议使用较低值。max_tokensLLMClient.generate_response300 - 800限制 LLM 回复的最大长度。根据回复内容的复杂度调整太短可能截断太长浪费资源。system_promptanalyze_issue_intent,on_message自定义定义 AI 的角色、行为边界和回复风格。这是控制 Agent 行为最重要的部分需要精心设计。confidence thresholdwebhook_handler.py(第70行附近)0.7 - 0.9执行自动操作如分配、关闭所需的置信度阈值。阈值越高Agent 越保守。LOG_LEVEL环境变量INFO/DEBUG开发时设为DEBUG可查看详细流程生产环境设为INFO或WARNING减少日志量。7. 常见问题排查与优化实践在开发和部署此类 AI Agent 时你可能会遇到以下典型问题。7.1 问题排查清单问题现象可能原因检查步骤解决方案GitHub Webhook 请求失败返回 403Webhook 签名验证失败1. 检查.env中的GITHUB_WEBHOOK_SECRET与 GitHub 后台设置的是否一致。2. 检查verify_github_signature函数中的 HMAC 计算逻辑。确保密钥一致并确认 payload 在验证时是原始字节流。GitHub Issue 创建后Agent 无反应1. Webhook 未触发。2. 后台任务处理出错。3. LLM API 调用失败。1. 查看 GitHub Webhook 管理页面的 “Recent Deliveries”检查是否有发送记录和响应状态。2. 查看应用日志是否有处理新 Issue的日志。3. 检查 OpenAI API 密钥是否正确网络是否通畅。1. 修复 Webhook 配置或网络问题。2. 在handle_issue_opened函数中添加更详细的 try-catch 和日志。3. 配置正确的 API Key 或设置网络代理。Discord Bot 不响应消息1. Bot 未成功登录。2. 消息监听逻辑有误。3. 缺少必要的 Intents 权限。1. 检查日志是否有Bot 已登录为 ...信息。2. 检查on_message函数中的条件判断如频道名、关键词。3. 在 Discord Developer Portal 检查 Bot 的 Privileged Gateway Intents 是否开启了MESSAGE CONTENT INTENT和SERVER MEMBERS INTENT。1. 确认 Token 正确Bot 已被邀请到服务器且有权限。2. 简化条件进行测试。3. 在开发者门户开启相应 Intents。LLM 回复内容不符合预期或格式错误1. System Prompt 设计不佳。2. Temperature 值过高。3. 未使用 JSON 模式或函数调用。1. 分析 LLM 的完整输入和输出日志。2. 尝试降低 temperature 值。3. 检查analyze_issue_intent中对 JSON 的解析是否健壮。1. 迭代优化 System Prompt明确指令和格式要求。2. 使用 OpenAI API 的response_format{ type: json_object }参数强制 JSON 输出。3. 使用 OpenAI 的 Function Calling 功能来获得结构化输出。处理速度慢响应延迟高1. LLM API 调用是主要延迟源。2. 网络延迟高。3. 未使用异步处理。1. 记录每个步骤的耗时。2. 考虑 LLM 响应的超时设置。1. 对于非实时场景使用后台任务如已做。2. 考虑使用更快的模型如gpt-3.5-turbo或配置 API 调用超时。3. 确保所有 I/O 操作网络请求、数据库查询都使用异步库。7.2 生产环境最佳实践安全性强化Webhook 签名验证必须启用并确保密钥安全。API 密钥管理使用云服务商的密钥管理服务如 AWS Secrets Manager GCP Secret Manager而非硬编码在环境变量文件中。权限最小化GitHub Token 和 Discord Bot 权限只授予必要的最小范围。输入验证与清理对所有来自外部的输入Issue 内容、Discord 消息进行基本的清理和验证防止注入攻击。可靠性设计错误处理与重试为 LLM API 调用、GitHub API 调用等外部服务添加指数退避重试机制。队列与异步将 Webhook 事件推入消息队列如 Redis RabbitMQ由独立的消费者 worker 处理避免请求阻塞和丢失。监控与告警记录关键指标处理量、成功率、延迟和错误日志。设置告警当 Agent 长时间无响应或错误率升高时通知维护者。效果优化Prompt 工程这是 Agent 能力的核心。持续根据实际交互反馈优化 System Prompt 和 User Prompt。上下文增强RAG集成向量数据库将项目文档、Wiki、过往已解决的 Issue 作为知识库让 LLM 在回答时能引用准确信息减少“幻觉”。人工审核与反馈循环对于高风险的自动操作如关闭 Issue可以先添加评论建议或设置为待审核状态由人工最终确认。收集用户对 AI 回复的反馈/用于优化模型。成本控制缓存对常见、通用的问题答案进行缓存避免重复调用 LLM。令牌数限制合理设置max_tokens并在构建 Prompt 时精简上下文减少不必要的令牌消耗。模型选型在效果和成本间权衡。对于简单的分类和回复gpt-3.5-turbo可能已足够对于复杂分析再使用gpt-4。将 AI Agent 集成到问题处理流程中不是要完全取代人工而是作为第一道过滤器和支持者处理那些模式固定、信息明确的问题从而让项目维护者能更专注于真正复杂和有价值的讨论。从本文的最小可行产品出发你可以根据项目实际需求逐步增加如代码片段分析、自动生成测试用例、与 CI/CD 流水线联动等更高级的功能。