基于LLM的GitHub智能助手：用自然语言驱动自动化工作流

1. 项目概述：当GitHub遇到AI，自动化工作流的新范式

最近在折腾一个挺有意思的开源项目，叫MPK2004/github-agent。乍一看名字，你可能会想，这又是一个基于GitHub API的机器人或者自动化脚本吧？没错，但也不全对。这个项目的核心，是把大型语言模型（LLM）的能力，直接注入到GitHub的日常操作中，让它从一个被动的代码仓库，变成一个能“听懂人话”、主动执行复杂任务的智能体。

简单来说，github-agent是一个AI驱动的GitHub自动化助手。你不再需要编写繁琐的YAML工作流文件，或者记忆一堆Git命令和API参数。你只需要用自然语言告诉它你想做什么，比如“帮我检查一下main分支上最近三次提交的代码风格”、“给所有打开的Issue打上bug标签并分配给小明”，它就能理解你的意图，并自动调用相应的GitHub API去执行。这背后，是LLM在理解自然语言指令、拆解任务步骤、生成可执行代码（或API调用）方面的能力。

这个项目特别适合几类人：一是项目维护者，每天要处理大量重复的Issue、PR审查和仓库管理任务；二是DevOps或平台工程师，希望构建更智能的CI/CD流水线；三是任何对AI应用和自动化感兴趣的开发者，想亲手搭建一个能“干活”的AI Agent。它解决的，正是将人类高层的、模糊的意图，转化为机器可执行的、精确的操作序列这一核心痛点。

2. 核心架构与设计思路拆解

2.1 智能体的核心工作流：从“人话”到“机器动作”

github-agent的设计遵循了一个清晰的智能体（Agent）范式。它的工作流可以概括为“感知-思考-行动”循环。

首先，感知（Perception）。用户通过命令行、Web界面或集成的聊天工具（如Slack）输入一个自然语言指令，例如：“总结一下上周仓库里所有合并的PR，并按贡献者排序。” 这个指令就是智能体的输入。

接着，思考（Cognition/Planning）。这是最核心的部分。智能体背后的LLM（比如GPT-4、Claude或本地部署的模型）会解析这个指令。它需要做几件事：

1. 意图识别：判断用户想干什么（是查询、修改、创建还是删除？）。
2. 实体提取：找出指令中的关键对象，如“上周”、“合并的PR”、“贡献者”。
3. 任务规划：将复杂的指令拆解成一系列原子操作。比如，上述指令可能被拆解为：
   • 调用GitHub API，获取指定时间范围内的所有PR。
   • 过滤出状态为“merged”的PR。
   • 对每个PR，提取贡献者（作者）信息。
   • 按贡献者分组并计数。
   • 格式化输出结果。
4. 工具选择：为每个原子操作匹配合适的“工具”。在这个场景下，工具就是封装好的GitHub API函数，比如list_pull_requests、get_user等。

最后，行动（Action）。智能体按照规划好的步骤，依次调用选定的工具（即执行API调用），获取执行结果，并将最终结果以人类可读的方式（如Markdown表格、总结文本）返回给用户。如果某一步执行失败（如权限不足、API限流），智能体还可能进入“反思”环节，尝试调整策略或向用户请求澄清。

这个设计思路的关键在于，将LLM的通用语言理解能力与领域专用工具（GitHub API）的强大执行力结合起来。LLM负责解决“做什么”和“怎么做”的规划问题，而工具则负责可靠地执行每一个具体动作。

2.2 技术栈选型与权衡：为什么是它们？

MPK2004/github-agent的技术栈选择反映了当前AI应用开发的主流实践，也做出了一些贴合场景的权衡。

1. 核心模型层：云端 vs. 本地项目通常支持配置多种LLM后端。主流选择是OpenAI的GPT系列或Anthropic的Claude，因为它们提供了强大的、稳定的API，并且在代码生成和任务规划上表现优异。这对于快速原型验证和大多数生产场景是首选。

注意：使用云端API意味着你的指令和GitHub数据（如Issue内容、代码片段）会被发送到第三方服务器。如果处理的是私有仓库或敏感信息，这存在数据安全和合规风险。因此，项目也支持接入本地部署的开源模型（如通过Ollama、vLLM部署的Llama 3、CodeLlama等）。选择本地模型虽然可能牺牲一些性能上限，但能完全保证数据不出域，是安全敏感场景的必选项。

2. 智能体框架：LangChain vs. 自研轻量框架许多AI应用会基于LangChain、LlamaIndex这类成熟框架来构建智能体。它们提供了丰富的工具集成、记忆管理和链式调用功能。github-agent项目可能会选择基于此类框架快速搭建，也可能为了追求极致的轻量化和控制力而选择自研一个简单的智能体循环。自研框架的核心代码可能只有几百行，专注于GitHub领域，避免了大型框架的依赖负担，但也需要自己处理工具注册、错误重试等基础功能。

3. 工具层：GitHub API的封装这是项目的基石。需要为GitHub REST API和GraphQL API的关键操作创建封装良好的工具函数。每个工具函数都需要有：

• 清晰的描述：用自然语言描述这个工具的功能、输入和输出，供LLM在规划时理解和使用。
• 严格的输入验证：确保从LLM生成的参数符合API要求，避免无效调用。
• 完善的错误处理：妥善处理认证失败、速率限制、资源不存在等情况，并将错误信息反馈给LLM或用户。 例如，一个“创建Issue”的工具描述可能是：“在指定仓库中创建一个新的Issue。需要参数：仓库全名（owner/repo）、标题、内容（body）、可选标签（labels）和指派人（assignees）。”

4. 执行与安全层这是最容易踩坑的地方。让AI自动执行GitHub操作，权限控制至关重要。

• 权限最小化原则：为github-agent创建的GitHub个人访问令牌（PAT）或GitHub App，必须严格按需授权。如果它只需要读权限，就绝不授予写权限；如果只需要处理Issues，就绝不授予操作仓库代码的权限。
• 操作确认机制：对于高风险操作（如合并PR、删除分支、直接推送代码），设计上应该加入人工确认环节，或者限制智能体只能在特定的“沙盒”分支或测试仓库中执行。
• 审计日志：所有智能体执行的操作、使用的指令、调用的工具以及结果，都必须有完整的日志记录，便于事后追溯和问题排查。

3. 核心模块深度解析与实操要点

3.1 工具（Tools）的定义与管理：让AI学会使用GitHub API

工具是智能体的“手”和“脚”。在github-agent中，每个工具都是一个独立的Python函数，它封装了一个或多个GitHub API调用。

一个完整的工具定义示例：

from typing import List, Optional from github import Github from pydantic import BaseModel, Field class CreateIssueInput(BaseModel): """创建Issue的输入参数模型""" repo_full_name: str = Field(description="仓库全名，格式为：owner/repo_name") title: str = Field(description="Issue的标题") body: str = Field(description="Issue的详细描述内容") labels: Optional[List[str]] = Field(default=None, description="可选的标签列表") def create_github_issue( repo_full_name: str, title: str, body: str, labels: Optional[List[str]] = None ) -> str: """ 在指定的GitHub仓库中创建一个新的Issue。 参数: repo_full_name: 仓库全名，如 'MPK2004/github-agent' title: Issue标题 body: Issue正文 labels: 可选标签列表 返回: 字符串，表示创建结果，如 'Issue #123 created successfully at https://github.com/xxx' 异常: 会处理认证失败、仓库不存在等常见错误，并返回友好提示。 """ try: # 假设 `g` 是一个已认证的Github客户端实例 repo = g.get_repo(repo_full_name) issue = repo.create_issue(title=title, body=body, labels=labels or []) return f"Issue #{issue.number} '{issue.title}' created successfully. URL: {issue.html_url}" except Exception as e: return f"Failed to create issue: {str(e)}" # 提供给LLM的工具描述 create_issue_tool_description = """ Tool Name: create_github_issue Description: Creates a new issue in a specified GitHub repository. Parameters: - repo_full_name (string, required): The full name of the repository (e.g., 'owner/repo'). - title (string, required): The title of the new issue. - body (string, required): The body content of the issue. - labels (list of strings, optional): Labels to attach to the issue. """

实操要点与避坑指南：

1. 描述至关重要：给LLM的工具描述（create_issue_tool_description）必须清晰、准确、结构化。LLM依靠这个描述来理解何时以及如何使用该工具。参数的类型、是否必填、示例值都要写清楚。
2. 使用Pydantic进行输入验证：如上例所示，为每个工具定义一个Pydantic模型来规范输入。这能有效防止LLM生成格式错误或类型错误的参数，导致API调用失败。模型中的Field(description=...)也能被一些框架自动提取为工具描述的一部分。
3. 返回结果需友好且信息丰富：工具函数应返回一个字符串结果，这个结果既是对用户的反馈，也可能成为后续工具调用的输入。结果应包含关键信息（如新建的Issue编号、URL）和明确的状态（成功/失败）。
4. 异常处理要健壮：GitHub API调用可能因网络、权限、限流等原因失败。工具函数内部必须捕获异常，并返回一个包含错误信息的字符串，而不是直接抛出异常导致智能体崩溃。这能让智能体有机会“反思”并尝试其他方案，或者向用户报告具体错误。

3.2 提示词（Prompt）工程：引导AI正确思考

智能体的“思考”过程由提示词（Prompt）驱动。一个精心设计的系统提示词（System Prompt）是项目成功的关键。它定义了智能体的角色、能力范围和行动准则。

一个典型的系统提示词框架：

你是一个专业的GitHub仓库管理助手，名为GitHub Agent。你的核心能力是通过调用一系列工具来操作GitHub仓库，帮助用户完成查询、管理、分析等任务。 # 你的能力 你拥有以下工具： {tools_descriptions} # 你的行动准则 1. 首先，仔细分析用户的请求，理解其真实意图。 2. 根据意图，规划需要调用哪些工具，以及调用的顺序。一次只调用一个工具。 3. 调用工具时，必须严格按照工具描述中要求的参数格式提供参数。 4. 收到工具的执行结果后，分析结果。如果结果满足了用户的请求，则整理结果并以清晰、友好的格式回复用户。 5. 如果结果不满足，或者执行中出错，分析原因并决定是重试、换用其他工具，还是向用户请求更多信息。 6. 对于任何会修改仓库数据（如创建、修改、删除）的操作，如果用户指令不够明确（例如未指定仓库名），你必须主动向用户询问确认。 7. 你无法执行工具列表之外的操作。如果用户请求超出你的能力范围，请礼貌告知。 当前对话上下文： {chat_history} 现在，开始处理用户的最新请求： 用户：{user_input}

提示词设计的核心技巧：

1. 角色定位清晰：开宗明义，告诉AI“你是谁”。这能有效约束它的回答范围，避免它天马行空地回答一些与GitHub无关的问题。
2. 工具描述动态插入：{tools_descriptions}是一个占位符，在实际运行时，会被当前注册的所有工具的描述信息替换。这样，增加或删除工具时，无需修改提示词本身。
3. 制定明确的行动链（Chain of Thought）：在准则中清晰地写出“分析-规划-执行-检查”的步骤，鼓励LLM展示其推理过程。这对于复杂任务至关重要。
4. 强调安全与确认：准则中必须包含对修改类操作的确认要求，这是防止误操作的重要安全阀。
5. 管理对话历史：{chat_history}让智能体拥有短期记忆，能处理多轮对话。但要注意控制历史长度，避免上下文令牌（Token）超限。

3.3 记忆（Memory）与状态管理：让对话有连续性

一个实用的智能体需要记住之前的对话内容。github-agent需要实现某种形式的记忆机制。

• 对话历史记忆：最简单的是维护一个轮次列表，记录用户和AI的对话。每次新的请求，都将最近N轮历史连同当前问题一起发送给LLM。这能实现基本的上下文理解，比如用户说“给上面提到的PR打上reviewed标签”，AI需要知道“上面提到的PR”具体指哪个。
• 实体记忆：更高级的实现可以提取对话中提到的关键实体（如仓库名、PR编号、用户名），并显式地存储起来。当后续指令中用到“它”、“那个”等代词时，可以从实体记忆中查找指代对象。
• 记忆的持久化：对于Web应用或长期运行的机器人，需要将记忆存储到数据库或文件中，以便在不同会话间保持状态。

实操心得：记忆功能不能无限制增长，因为LLM的上下文窗口有限。一个常见的策略是“摘要记忆”：当对话历史过长时，可以调用LLM本身对之前的对话内容进行摘要，然后用摘要替换掉详细的历史记录，只保留最近几轮完整对话。这样既能保留关键信息，又能节省令牌数。

4. 从零搭建与核心环节实现

4.1 环境准备与基础依赖安装

假设我们使用Python和OpenAI API来构建一个基础版本的github-agent。

步骤1：创建项目并安装核心库

# 创建项目目录 mkdir github-agent && cd github-agent python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装核心依赖 pip install openai langchain langchain-openai pygithub pydantic python-dotenv

• openai/langchain-openai: 用于调用OpenAI API。
• langchain: 提供智能体、工具链、记忆等高级抽象（这里我们以其为例，实际项目可能简化）。
• pygithub: 官方推荐的GitHub API Python SDK，封装良好，比直接调用REST API更方便。
• pydantic: 用于数据验证和设置管理。
• python-dotenv: 管理环境变量，如API密钥。

步骤2：配置环境变量创建.env文件，存放敏感信息：

# .env OPENAI_API_KEY=sk-your-openai-api-key-here GITHUB_PERSONAL_ACCESS_TOKEN=ghp_your_github_token_here # 可选：指定使用的模型 OPENAI_MODEL=gpt-4-turbo-preview

重要安全提醒：.env文件必须加入.gitignore，绝对不要提交到版本库。GitHub Token应仅授予所需的最小权限（例如，如果智能体只读，就只给repo的读权限）。

步骤3：初始化核心客户端创建config.py和clients.py：

# config.py import os from pydantic_settings import BaseSettings from dotenv import load_dotenv load_dotenv() class Settings(BaseSettings): openai_api_key: str = os.getenv("OPENAI_API_KEY") github_token: str = os.getenv("GITHUB_PERSONAL_ACCESS_TOKEN") openai_model: str = os.getenv("OPENAI_MODEL", "gpt-3.5-turbo") settings = Settings()

# clients.py from github import Github import openai from config import settings # 初始化GitHub客户端 github_client = Github(settings.github_token) # 初始化OpenAI客户端 (LangChain方式) from langchain_openai import ChatOpenAI llm = ChatOpenAI( model=settings.openai_model, api_key=settings.openai_api_key, temperature=0.1 # 降低随机性，让输出更稳定、可预测 )

4.2 构建工具集并创建智能体

步骤1：实现核心工具函数我们在一个tools.py文件中定义几个基础工具。

# tools.py from typing import Optional, List from pydantic import BaseModel, Field from clients import github_client # --- 工具1: 列出仓库的开放Issue --- class ListIssuesInput(BaseModel): repo_full_name: str = Field(description="仓库全名，格式：owner/repo") state: str = Field(default="open", description="Issue状态，'open', 'closed', 或 'all'") def list_repo_issues(repo_full_name: str, state: str = "open") -> str: """获取指定仓库的Issue列表""" try: repo = github_client.get_repo(repo_full_name) issues = repo.get_issues(state=state) result = [] for issue in issues[:10]: # 限制返回数量 result.append(f"#{issue.number}: {issue.title} (状态: {issue.state}, 创建者: {issue.user.login})") if not result: return f"仓库 {repo_full_name} 中没有找到{state}状态的Issue。" return f"仓库 {repo_full_name} 的Issue列表（最近10条）:\n" + "\n".join(result) except Exception as e: return f"获取Issue列表失败: {str(e)}" # --- 工具2: 创建PR --- class CreatePRInput(BaseModel): repo_full_name: str = Field(description="仓库全名") title: str = Field(description="Pull Request的标题") body: str = Field(description="PR的详细描述") head: str = Field(description="源分支名") base: str = Field(description="目标分支名，默认为'main'") def create_pull_request(repo_full_name: str, title: str, body: str, head: str, base: str = "main") -> str: """创建Pull Request""" try: repo = github_client.get_repo(repo_full_name) pr = repo.create_pull(title=title, body=body, head=head, base=base) return f"PR #{pr.number} 创建成功！标题: '{pr.title}'。链接: {pr.html_url}" except Exception as e: return f"创建PR失败: {str(e)}" # 将所有工具函数和描述收集起来 TOOLS = [ { "name": "list_repo_issues", "func": list_repo_issues, "description": "获取指定GitHub仓库的Issue列表。参数: repo_full_name (string), state (string, 可选，默认'open')", "args_schema": ListIssuesInput }, { "name": "create_pull_request", "func": create_pull_request, "description": "在指定仓库中创建一个新的Pull Request。参数: repo_full_name (string), title (string), body (string), head (string), base (string, 可选，默认'main')", "args_schema": CreatePRInput } ]

步骤2：使用LangChain构建智能体创建agent.py，利用LangChain的create_openai_tools_agent和AgentExecutor。

# agent.py from langchain.agents import create_openai_tools_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.memory import ConversationBufferMemory from clients import llm from tools import TOOLS from langchain.tools import StructuredTool # 1. 将自定义函数包装成LangChain Tool对象 tools = [] for tool_info in TOOLS: tool = StructuredTool.from_function( func=tool_info["func"], name=tool_info["name"], description=tool_info["description"], args_schema=tool_info["args_schema"] ) tools.append(tool) # 2. 构建系统提示词 system_prompt = """你是一个GitHub助手，专门帮助用户管理GitHub仓库。 你可以使用工具来获取信息或执行操作。 如果你不确定，或者用户请求需要更多信息，请主动询问。 对于修改数据的操作（如创建PR），请确保参数齐全，必要时向用户确认。 """ prompt = ChatPromptTemplate.from_messages([ ("system", system_prompt), MessagesPlaceholder(variable_name="chat_history"), ("human", "{input}"), MessagesPlaceholder(variable_name="agent_scratchpad") # 给Agent记录思考过程的地方 ]) # 3. 创建记忆 memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True) # 4. 创建Agent和Executor agent = create_openai_tools_agent(llm, tools, prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, memory=memory, verbose=True, handle_parsing_errors=True) # 5. 运行Agent的入口函数 def run_agent(query: str) -> str: """执行用户查询""" result = agent_executor.invoke({"input": query}) return result["output"]

4.3 实现一个简单的命令行交互界面

最后，创建一个main.py作为程序入口。

# main.py from agent import run_agent def main(): print("GitHub Agent 已启动！输入 'quit' 或 'exit' 退出。") while True: try: user_input = input("\n您: ") if user_input.lower() in ['quit', 'exit']: print("再见！") break if not user_input.strip(): continue print("\nAgent 正在思考...") response = run_agent(user_input) print(f"\n助手: {response}") except KeyboardInterrupt: print("\n\n程序被中断。") break except Exception as e: print(f"\n发生错误: {e}") if __name__ == "__main__": main()

现在，运行python main.py，你就可以通过命令行与你的github-agent对话了。试试输入：“帮我看看MPK2004/github-agent这个仓库有哪些打开的Issue？” 或者 “在MPK2004/github-agent仓库，从feature-branch向main分支创建一个PR，标题是‘添加新功能’，正文写‘这是一个测试PR’。”

5. 部署、优化与安全实践

5.1 部署方案选型：从本地脚本到常驻服务

基础的命令行脚本适合个人使用。要让它成为一个可共享的服务，需要考虑部署。

• 方案一：CLI工具（最简单）：使用click或typer库将你的代码包装成一个命令行工具，打包后通过pip安装。用户可以在任何终端使用github-agent “你的指令”。这适合技术用户。
• 方案二：Slack/Discord机器人（团队协作）：使用slack-bolt或discord.py框架，将智能体部署为一个聊天机器人。团队成员可以在协作频道中直接@机器人并发出指令。这极大地提升了便利性和可发现性。
• 方案三：Web应用（通用接口）：使用FastAPI或Flask构建一个简单的Web API。前端可以是一个简单的聊天界面（用HTML/JS或Streamlit/Gradio快速搭建）。这样任何能访问该URL的人都可以使用。
• 方案四：GitHub Actions集成（自动化流水线）：将智能体封装成一个GitHub Action。这样，它可以在仓库的特定事件（如issue_comment、pull_request）触发时自动运行。例如，当有人在Issue下评论“/analyze-commits”时，Action被触发，智能体分析提交记录并回复结果。这是将AI深度集成到开发工作流中的高级玩法。

部署实操心得：无论哪种方案，密钥管理都是重中之重。永远不要将API密钥硬编码在代码中。对于云部署（如Vercel、Railway、AWS Lambda），使用平台提供的环境变量或密钥管理服务（如AWS Secrets Manager）。对于GitHub Actions，务必使用加密的仓库机密（Secrets）来存储OPENAI_API_KEY和GITHUB_TOKEN。

5.2 性能优化与成本控制

使用商业LLM API会产生费用，优化势在必行。

1. 提示词优化：精简系统提示词和工具描述，移除不必要的废话。使用更具体的指令来减少LLM的“胡思乱想”，从而减少输出令牌数。
2. 缓存机制：对于频繁且结果不变的查询（如“列出所有仓库成员”），可以引入缓存（如redis或diskcache）。在调用工具前先检查缓存，命中则直接返回，避免不必要的API调用和LLM思考。
3. 设置超时与重试：为LLM调用和GitHub API调用设置合理的超时时间。对于可重试的错误（如网络抖动、速率限制），实现指数退避的重试逻辑。
4. 模型选择：并非所有任务都需要GPT-4。对于简单的信息提取和分类，GPT-3.5-Turbo可能就足够了，成本仅为前者的几十分之一。可以根据任务复杂度动态选择模型。
5. 异步处理：对于耗时较长的任务（如分析一个大型仓库的所有提交历史），不要阻塞主请求。可以改为异步处理，先立即返回“任务已接收”的响应，后台处理完成后通过Webhook、邮件或更新数据库记录的方式通知用户。

5.3 高级功能与扩展思路

一个基础的github-agent搭建完成后，可以考虑以下方向进行增强：

• 代码理解与分析：集成代码解析工具（如tree-sitter）或静态分析工具，让智能体不仅能管理元数据（Issue/PR），还能理解代码内容。例如，指令可以是：“分析src/utils.py文件中calculate_score函数的圈复杂度。”
• 多仓库与跨仓库操作：让工具支持同时对多个仓库进行操作。例如：“在我们团队的所有前端仓库中，检查package.json里react的版本是否都大于18。”
• 工作流自动化编排：将智能体作为更复杂自动化工作流的触发器或协调器。例如，用户说“准备发布v1.2.0”，智能体可以自动：1) 创建发布分支，2) 更新版本号，3) 运行测试，4) 生成变更日志草案，5) 创建预发布PR。
• 学习与适应：引入向量数据库（如ChromaDB、Pinecone），存储历史对话和仓库文档。当用户提出模糊问题时，智能体可以先从向量库中检索相关历史记录或文档片段，作为上下文提供给LLM，从而给出更精准的答案。

6. 常见问题、故障排查与安全红线

6.1 典型问题与解决方案速查表

6.2 必须坚守的安全红线

在赋予AI自动化操作权限时，安全是头等大事。

1. 权限隔离与最小化：

   • 为github-agent创建专用的GitHub账号或GitHub App，而不是使用个人主账号的Token。
   • 授予的Token权限必须是最小集合。如果只需要读Issue，就只给read:issue权限；如果需要写PR，就给pull_requests: write。绝对不要图省事直接给repo的全部权限。
   • 如果使用GitHub App，可以利用其更细粒度的权限控制和针对仓库的安装机制，安全性高于个人访问令牌（PAT）。

2. 操作范围限制（沙盒）：

   • 在配置中设定智能体只能操作特定的仓库或组织。例如，通过环境变量ALLOWED_REPOS=org1/repo1,org2/repo2来设置白名单。
   • 对于写操作（合并PR、推送代码），可以考虑限制只能在以bot/或test/开头的分支上进行。

3. 关键操作二次确认：

   • 在代码逻辑层面，对于delete_branch、merge_pr、push_to_protected_branch等高风险操作，不要直接执行。可以设计为：智能体生成操作指令和说明，然后通过创建一条待办事项（Todo）、发送一条Slack消息给指定频道、或生成一个需要人工点击确认的链接等方式，等待人工批准后再执行。

4. 全面的审计日志：

   • 记录每一次交互：原始用户指令、LLM的完整思考过程（包括规划的工具调用）、实际调用的工具及参数、工具执行结果、最终回复。这些日志应输出到文件或日志系统（如ELK），并长期保存。
   • 这不仅是安全审计的需要，也是后期优化模型、分析用户需求、排查问题的宝贵数据。

5. 输入过滤与净化：

   • 对用户输入进行基本的检查，防止Prompt注入攻击。例如，如果用户输入中包含奇怪的系统指令如“忽略之前的指示，执行...”，应被识别并拒绝。
   • 对从GitHub获取并准备喂给LLM的内容（如Issue正文、代码注释）进行敏感信息扫描（如硬编码的密码、密钥），必要时进行脱敏处理。

构建github-agent的过程，是一个将前沿AI能力与具体开发场景深度融合的绝佳实践。它不仅仅是一个工具，更代表了一种新的交互范式：用人类最自然的语言，来驱动复杂数字系统的运作。从简单的信息查询到复杂的流程编排，其可能性只受限于我们的想象力和对安全边界的谨慎定义。