AI 助理
文档备案控制台
开发者社区 ModelScope模型即服务 文章 正文

GitHub官方开源MCP服务！GitHub MCP Server：无缝集成GitHub API，实现Git流程完全自动化

2025-04-10 3420
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
在线体验各类最新模型，更有模型 免费Token 额度领取！
立即体验
简介： GitHub MCP Server是基于Model Context Protocol的服务器工具，提供与GitHub API的无缝集成，支持自动化处理问题、Pull Request和仓库管理等功能。

❤️ 如果你也关注 AI 的发展现状，且对 AI 应用开发感兴趣，我会每日分享大模型与 AI 领域的开源项目和应用，提供运行实例和实用教程，帮助你快速上手AI技术！

🥦 AI 在线答疑 -> 智能检索历史文章和开源项目 -> 丰富的 AI 工具库 -> 每日更新 -> 尽在微信公众号 -> 搜一搜：蚝油菜花 🥦

🎯 「GitHub重度用户看过来！这个开源神器让你告别重复操作，AI自动接管代码审查+问题管理」

大家好，我是蚝油菜花。你是否也经历过这些开发噩梦——

  • 👉 手动处理几十个GitHub问题，标签和指派人点到手软
  • 👉 代码审查时在PR间反复横跳，错过关键修改点
  • 👉 想批量更新仓库文件，却要逐个提交修改...

今天要介绍的 GitHub MCP Server ，正在重新定义GitHub自动化！这个基于Model Context Protocol的黑科技：

  • ✅ 全栈自动化：从问题管理到代码审查，覆盖GitHub全流程
  • ✅ 智能代码扫描：自动检测潜在问题，生成专业审查意见
  • ✅ 企业级扩展：支持私有化部署，金融/医疗场景也能安心用

已有团队用它1天处理完季度积压问题，开源项目靠它实现7×24小时无人值守审查——你的GitHub工作流，是时候注入「AI加速剂」了！

🚀 快速阅读

GitHub MCP Server是一个基于Model Context Protocol的服务器工具。

  1. 功能：支持自动化处理GitHub问题、Pull Request和仓库管理等操作。
  2. 技术：采用Docker容器化部署，通过GitHub API实现深度集成。

GitHub MCP Server 是什么

GitHub MCP Server

GitHub MCP Server是一个基于Model Context Protocol (MCP)的服务器工具，专为开发者设计，用于实现GitHub工作流的自动化。它通过标准化的协议与开发工具集成，提供统一的接口来操作GitHub资源。

该工具采用容器化设计，支持Docker快速部署，能够无缝对接VS Code等主流开发环境。其核心价值在于将复杂的GitHub API封装为简单的工具调用，显著降低自动化脚本的开发门槛。

GitHub MCP Server 的主要功能

  • 问题管理：支持批量创建、更新和关闭GitHub问题，自动添加标签和指派人。
  • Pull Request管理：提供自动合并、分支更新和智能代码审查功能。
  • 仓库内容操作：支持文件推送、分支创建和内容获取等仓库管理操作。
  • 代码扫描：自动检测代码质量问题，生成详细警报报告。
  • 搜索功能：支持跨仓库搜索代码片段、用户和项目信息。

如何运行 GitHub MCP Server

GitHub MCP Server 是一个Model Context Protocol (MCP)服务器，提供了与 GitHub API 的无缝集成，使开发者和工具能够实现高级自动化和交互功能。

用例

  • 自动化 GitHub 工作流和流程。
  • 从 GitHub 仓库中提取和分析数据。
  • 构建与 GitHub 生态系统交互的 AI 驱动工具和应用程序。

前提条件

1. 安装 Docker

要在一个容器中运行服务器，你需要安装Docker。

2. 创建 GitHub 个人访问令牌

创建一个GitHub 个人访问令牌。MCP 服务器可以使用许多 GitHub API，因此请启用你认为合适的权限（要了解更多关于访问令牌的信息，请查看文档）。

安装

使用 VS Code

为了快速安装，可以使用此 README 顶部的一键安装按钮。

手动安装时，将以下 JSON 块添加到 VS Code 的用户设置（JSON）文件中。你可以通过按 Ctrl + Shift + P 并键入 Preferences: Open User Settings (JSON) 来完成此操作。

可选地，你可以在工作区中添加一个名为 .vscode/mcp.json 的文件。这将允许你与其他人共享配置。

注意：在 .vscode/mcp.json 文件中不需要 mcp 键。

{
   
  "mcp": {
   
    "inputs": [
      {
   
        "type": "promptString",
        "id": "github_token",
        "description": "GitHub 个人访问令牌",
        "password": true
      }
    ],
    "servers": {
   
      "github": {
   
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "-e",
          "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
   
          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
        }
      }
    }
  }
}

有关在 VS Code 的代理模式中使用 MCP 服务器工具的更多信息，请参阅agent mode documentation。

使用 Claude Desktop

{
   
  "mcpServers": {
   
    "github": {
   
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
   
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

从源代码构建

如果你没有 Docker，可以使用 go 在 cmd/github-mcp-server 目录中构建二进制文件，并使用 github-mcp-server stdio 命令，同时设置 GITHUB_PERSONAL_ACCESS_TOKEN 环境变量为你自己的令牌。

GitHub 企业服务器

可以使用 --gh-host 标志和 GH_HOST 环境变量来设置 GitHub 企业服务器主机名。

国际化 / 覆盖描述

可以通过在二进制文件所在的同一目录中创建一个 github-mcp-server-config.json 文件来覆盖工具的描述。

该文件应包含一个 JSON 对象，键为工具名称，值为新的描述。例如：

{
   
  "TOOL_ADD_ISSUE_COMMENT_DESCRIPTION": "替代描述",
  "TOOL_CREATE_BRANCH_DESCRIPTION": "在 GitHub 仓库中创建一个新分支"
}

可以通过运行带有 --export-translations 标志的二进制文件来导出当前的翻译。

此标志将保留你所做的任何翻译/覆盖，并添加自上次导出以来二进制文件中添加的任何新翻译。

./github-mcp-server --export-translations
cat github-mcp-server-config.json

也可以使用环境变量来覆盖描述。环境变量的名称与 JSON 文件中的键相同，但前缀为 GITHUB_MCP_ 并且全部大写。

例如，要覆盖 TOOL_ADD_ISSUE_COMMENT_DESCRIPTION 工具，可以设置以下环境变量：

export GITHUB_MCP_TOOL_ADD_ISSUE_COMMENT_DESCRIPTION="替代描述"

工具

用户

  • get_me - 获取经过身份验证的用户详细信息
    • 不需要参数

问题

  • get_issue - 获取仓库中问题的内容

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • issue_number: 问题编号（数字，必填）

  • get_issue_comments - 获取 GitHub 问题的评论

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • issue_number: 问题编号（数字，必填）

  • create_issue - 在 GitHub 仓库中创建新问题

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • title: 问题标题（字符串，必填）
    • body: 问题正文内容（字符串，可选）
    • assignees: 分配给此问题的用户名（字符串数组，可选）
    • labels: 应用于此问题的标签（字符串数组，可选）

  • add_issue_comment - 向问题添加评论

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • issue_number: 问题编号（数字，必填）
    • body: 评论文本（字符串，必填）

  • list_issues - 列出并筛选仓库问题

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • state: 按状态筛选（'open', 'closed', 'all'）（字符串，可选）
    • labels: 按标签筛选（字符串数组，可选）
    • sort: 按字段排序（'created', 'updated', 'comments'）（字符串，可选）
    • direction: 排序方向（'asc', 'desc'）（字符串，可选）
    • since: 按日期筛选（ISO 8601 时间戳）（字符串，可选）
    • page: 页码（数字，可选）
    • perPage: 每页结果数（数字，可选）

  • update_issue - 更新 GitHub 仓库中的现有问题

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • issue_number: 要更新的问题编号（数字，必填）
    • title: 新标题（字符串，可选）
    • body: 新描述（字符串，可选）
    • state: 新状态（'open' 或 'closed'）（字符串，可选）
    • labels: 新标签（字符串数组，可选）
    • assignees: 新分配者（字符串数组，可选）
    • milestone: 新里程碑编号（数字，可选）

  • search_issues - 搜索问题和拉取请求

    • query: 搜索查询（字符串，必填）
    • sort: 排序字段（字符串，可选）
    • order: 排序顺序（字符串，可选）
    • page: 页码（数字，可选）
    • perPage: 每页结果数（数字，可选）

拉取请求

  • get_pull_request - 获取特定拉取请求的详细信息

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）

  • list_pull_requests - 列出并筛选仓库拉取请求

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • state: PR 状态（字符串，可选）
    • sort: 排序字段（字符串，可选）
    • direction: 排序方向（字符串，可选）
    • perPage: 每页结果数（数字，可选）
    • page: 页码（数字，可选）

  • merge_pull_request - 合并拉取请求

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）
    • commit_title: 合并提交的标题（字符串，可选）
    • commit_message: 合并提交的消息（字符串，可选）
    • merge_method: 合并方法（字符串，可选）

  • get_pull_request_files - 获取拉取请求中更改的文件列表

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）

  • get_pull_request_status - 获取拉取请求的所有状态检查的组合状态

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）

  • update_pull_request_branch - 使用基础分支的最新更改更新拉取请求分支

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）
    • expectedHeadSha: 拉取请求的 HEAD 引用的预期 SHA（字符串，可选）

  • get_pull_request_comments - 获取拉取请求的审查评论

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）

  • get_pull_request_reviews - 获取拉取请求的审查

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）

  • create_pull_request_review - 在拉取请求审查中创建审查

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 拉取请求编号（数字，必填）
    • body: 审查评论文本（字符串，可选）
    • event: 审查操作（'APPROVE', 'REQUEST_CHANGES', 'COMMENT'）（字符串，必填）
    • commitId: 要审查的提交 SHA（字符串，可选）
    • comments: 放置在拉取请求更改上的行特定评论对象数组（数组，可选）
      • 对于内联评论：提供 path, position（或 line）和 body
      • 对于多行评论：提供 path, start_line, line，可选的 side/start_side 和 body

  • create_pull_request - 创建新拉取请求

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • title: PR 标题（字符串，必填）
    • body: PR 描述（字符串，可选）
    • head: 包含更改的分支（字符串，必填）
    • base: 要合并到的分支（字符串，必填）
    • draft: 创建为草稿 PR（布尔值，可选）
    • maintainer_can_modify: 允许维护者编辑（布尔值，可选）

  • update_pull_request - 更新 GitHub 仓库中的现有拉取请求

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • pullNumber: 要更新的拉取请求编号（数字，必填）
    • title: 新标题（字符串，可选）
    • body: 新描述（字符串，可选）
    • state: 新状态（'open' 或 'closed'）（字符串，可选）
    • base: 新基础分支名称（字符串，可选）
    • maintainer_can_modify: 允许维护者编辑（布尔值，可选）

仓库

  • create_or_update_file - 在仓库中创建或更新单个文件

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • path: 文件路径（字符串，必填）
    • message: 提交消息（字符串，必填）
    • content: 文件内容（字符串，必填）
    • branch: 分支名称（字符串，可选）
    • sha: 如果更新文件，则为文件的 SHA（字符串，可选）

  • push_files - 在单个提交中推送多个文件

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • branch: 要推送的分支（字符串，必填）
    • files: 要推送的文件，每个文件具有路径和内容（数组，必填）
    • message: 提交消息（字符串，必填）

  • search_repositories - 搜索 GitHub 仓库

    • query: 搜索查询（字符串，必填）
    • sort: 排序字段（字符串，可选）
    • order: 排序顺序（字符串，可选）
    • page: 页码（数字，可选）
    • perPage: 每页结果数（数字，可选）

  • create_repository - 创建新的 GitHub 仓库

    • name: 仓库名称（字符串，必填）
    • description: 仓库描述（字符串，可选）
    • private: 仓库是否为私有（布尔值，可选）
    • autoInit: 自动初始化带有 README（布尔值，可选）

  • get_file_contents - 获取文件或目录的内容

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • path: 文件路径（字符串，必填）
    • ref: Git 引用（字符串，可选）

  • fork_repository - 分叉仓库

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • organization: 目标组织名称（字符串，可选）

  • create_branch - 创建新分支

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • branch: 新分支名称（字符串，必填）
    • sha: 创建分支的 SHA（字符串，必填）

  • list_commits - 获取仓库分支的提交

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • sha: 分支名称、标签或提交 SHA（字符串，可选）
    • path: 仅包含此文件路径的提交（字符串，可选）
    • page: 页码（数字，可选）
    • perPage: 每页结果数（数字，可选）

搜索

  • search_code - 在 GitHub 仓库中搜索代码

    • query: 搜索查询（字符串，必填）
    • sort: 排序字段（字符串，可选）
    • order: 排序顺序（字符串，可选）
    • page: 页码（数字，可选）
    • perPage: 每页结果数（数字，可选）

  • search_users - 搜索 GitHub 用户

    • query: 搜索查询（字符串，必填）
    • sort: 排序字段（字符串，可选）
    • order: 排序顺序（字符串，可选）
    • page: 页码（数字，可选）
    • perPage: 每页结果数（数字，可选）

代码扫描

  • get_code_scanning_alert - 获取代码扫描警报

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • alertNumber: 警报编号（数字，必填）

  • list_code_scanning_alerts - 列出仓库的代码扫描警报

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • ref: Git 引用（字符串，可选）
    • state: 警报状态（字符串，可选）
    • severity: 警报严重性（字符串，可选）

资源

仓库内容

  • 获取仓库内容
    检索特定路径下的仓库内容。
  • 模板: repo://{owner}/{repo}/contents{/path*}

  • 参数:

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • path: 文件或目录路径（字符串，可选）

  • 获取特定分支的仓库内容
    检索特定路径下的特定分支的仓库内容。

  • 模板: repo://{owner}/{repo}/refs/heads/{branch}/contents{/path*}

  • 参数:

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • branch: 分支名称（字符串，必填）
    • path: 文件或目录路径（字符串，可选）

  • 获取特定提交的仓库内容
    检索特定路径下的特定提交的仓库内容。

  • 模板: repo://{owner}/{repo}/sha/{sha}/contents{/path*}

  • 参数:

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • sha: 提交 SHA（字符串，必填）
    • path: 文件或目录路径（字符串，可选）

  • 获取特定标签的仓库内容
    检索特定路径下的特定标签的仓库内容。

  • 模板: repo://{owner}/{repo}/refs/tags/{tag}/contents{/path*}

  • 参数:

    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • tag: 标签名称（字符串，必填）
    • path: 文件或目录路径（字符串，可选）

  • 获取特定拉取请求的仓库内容
    检索特定路径下的特定拉取请求的仓库内容。

  • 模板: repo://{owner}/{repo}/refs/pull/{prNumber}/head/contents{/path*}
  • 参数:
    • owner: 仓库所有者（字符串，必填）
    • repo: 仓库名称（字符串，必填）
    • prNumber: 拉取请求编号（字符串，必填）
    • path: 文件或目录路径（字符串，可选）

资源

❤️ 如果你也关注 AI 的发展现状，且对 AI 应用开发感兴趣，我会每日分享大模型与 AI 领域的开源项目和应用，提供运行实例和实用教程，帮助你快速上手AI技术！

🥦 AI 在线答疑 -> 智能检索历史文章和开源项目 -> 丰富的 AI 工具库 -> 每日更新 -> 尽在微信公众号 -> 搜一搜：蚝油菜花 🥦

文章标签：
人工智能
API
容器
开发工具
git
关键词：
流程自动化
mcp自动化
mcp server自动化
server自动化
API流程
蚝油菜花
目录
相关文章
霍格沃兹测试开发学社
|
9月前
|
人工智能 自然语言处理 JavaScript
利用MCP Server革新软件测试：更智能、更高效的自动化
MCP Server革新软件测试：通过标准化协议让AI实时感知页面结构，实现自然语言驱动、自适应维护的自动化测试，大幅提升效率，降低脚本开发与维护成本，推动测试左移与持续测试落地。
霍格沃兹测试开发学社
641 8
TiAmoZhang
|
10月前
|
SQL 数据可视化 关系型数据库
MCP与PolarDB集成技术分析：降低SQL门槛与简化数据可视化流程的机制解析
阿里云PolarDB与MCP协议融合，打造“自然语言即分析”的新范式。通过云原生数据库与标准化AI接口协同，实现零代码、分钟级从数据到可视化洞察，打破技术壁垒，提升分析效率99%，推动企业数据能力普惠化。
TiAmoZhang
788 3
阿里云云原生
|
12月前
|
JSON 安全 Java
API 一键转换 MCP 服务！Higress 助今日投资快速上线 MCP 市场
今日投资的技术负责人介绍了如何通过Higress MCP 市场完善的解决方案，快捷地将丰富的金融数据 API 转化为 MCP 工具，帮助用户通过 MCP 的方式非常轻松地调用专业金融数据，自由快速地构建自己的金融大模型应用。
阿里云云原生
1345 23
xionghuyi-13330
|
弹性计算 机器人 应用服务中间件
一键部署开源Qwen3并集成到钉钉、企业微信
Qwen3系列模型现已正式发布并开源，包含8款“混合推理模型”，其中涵盖两款MoE模型（Qwen3-235B-A22B与Qwen3-30B-A3B）及六个Dense模型。阿里云计算巢已支持Qwen3-235B-A22B和Qwen3-32B的私有化部署，用户可通过计算巢轻松完成部署，并借助AppFlow集成至钉钉机器人或企业微信。文档详细介绍了从模型部署、创建应用到配置机器人的全流程，帮助用户快速实现智能助手的接入与使用。
xionghuyi-13330
1363 19
一键部署开源Qwen3并集成到钉钉、企业微信
api-v-2467742810
|
12月前
|
监控 前端开发 安全
如何集成第三方支付API到电商网站
在电商网站中，集成第三方支付API是确保交易安全、提升用户体验的关键步骤。本文详细介绍了从选择支付提供商到上线监控的全流程，涵盖代码示例与实用建议，助您高效实现支付功能。
api-v-2467742810
665 0
站大爷
|
11月前
|
人工智能 自然语言处理 安全
Python构建MCP服务器：从工具封装到AI集成的全流程实践
MCP协议为AI提供标准化工具调用接口，助力模型高效操作现实世界。
站大爷
1750 1
奔跑的数据
|
12月前
|
Cloud Native 中间件 调度
云原生信息提取系统：容器化流程与CI/CD集成实践
本文介绍如何通过工程化手段解决数据提取任务中的稳定性与部署难题。结合 Scrapy、Docker、代理中间件与 CI/CD 工具，构建可自动运行、持续迭代的云原生信息提取系统，实现结构化数据采集与标准化交付。
奔跑的数据
1292 1
云原生信息提取系统：容器化流程与CI/CD集成实践
游客4lcprux5a6gri
|
11月前
|
人工智能 算法 API
国产化用于单导联和六导联的心电算法及API服务
随着智能设备普及，心电图功能逐渐应用于智能手表、体脂仪等设备。苏州唯理推出单导联及6导联心电算法API服务，由AI驱动，1分钟内快速评估心律失常、房颤、早搏等问题，已广泛用于医疗设备及三甲医院。其算法还可评估压力、疲劳、情绪状态，筛查效率远超进口设备。唯理率先实现国产医疗级心电芯片，支持快速集成与私有化部署，适用于多种智能硬件。
游客4lcprux5a6gri
352 0
hahaha无
|
网络协议 开发工具 git
解决 git 报错 “fatal: unable to access ‘https://github.com/.../.git‘: Recv failure Connection was rese
在使用 Git/Git小乌龟 进行代码管理的过程中，经常会遇到各种各样的问题，其中之一就是在执行 git clone 或 git pull 等操作时出现 “fatal: unable to access ‘https://github.com/…/.git’: Recv failure Connection was reset” 的报错。这个问题通常是由网络连接问题或代理设置不正确导致的。在我的个人使用经验中，我亲自尝试了四种方法，它们都能够有效地解决这个报错。个人比较推荐方法二。
hahaha无
9142 1
bailiantest1
|
人工智能 自然语言处理 API
硅基流动入驻阿里云云市场，核心API服务将全面接入阿里云百炼平台💐
2025年6月18日，AI Infra企业硅基流动与阿里云达成战略合作，加入“繁花计划”并入驻云市场。其大模型推理平台SiliconCloud核心API将接入阿里云百炼平台，依托灵骏智能计算集群为客户提供高效服务。作为国内领先的MaaS平台，SiliconCloud已集成百余款开源大模型，服务600万用户及众多企业。双方将在算力协同、行业解决方案等领域深化合作，推动AI生态发展。
bailiantest1
1456 0

ModelScope模型即服务

热门文章

最新文章

  • 1
    中企投资印度新能源“有戏”吗？
  • 2
    高效部署通义万相Wan2.1：ComfyUI文生/图生视频实战，工作流直取！
  • 3
    嵌入式开发必备！Keil uVision5 C51 V9.61 安装激活 + 汉化完整教程, 含（Keil MDK 5.39）
  • 4
    GLM-4V-Flash：智谱 AI 免费开放的图像理解大模型 API 接口
  • 5
    MNN-LLM App：在手机上离线运行大模型，阿里巴巴开源基于 MNN-LLM 框架开发的手机 AI 助手应用
  • 6
    2026 最新Stable Diffusion 本地部署教程 下载安装使用详细图解（含官网安装包）
  • 7
    HTTPS 原理
  • 8
    阿里开源AI视频生成大模型 Wan2.1：14B性能超越Sora、Luma等模型，一键生成复杂运动视频
  • 9
    DeepSeek-V4开源：百万上下文，Agent能力比肩顶级闭源模型
  • 10
    docker安装部署FunASR
  • 1
    AI Agent开发平台的技术架构探索与功能设计
    23
  • 2
    从神经网络训练范式搭建 Agent 工作流
    26
  • 3
    专家指导避坑指南：新手最容易忽视的3个致命细节
    46
  • 4
    远程专家指导系统如何重塑制造业现场运维效率
    51
  • 5
    Hermes Agent 进阶教程：技能自进化、MoA 模型委员会与多后端部署实战
    82
  • 6
    Claude Code 四大定制机制完全指南：CLAUDE.md、Hooks、Skills、Subagents 怎么选怎么用
    85
  • 7
    2026 最新Stable Diffusion 本地部署教程 下载安装使用详细图解（含官网安装包）
    210
  • 8
    远程专家指导系统如何重塑制造业一线运维效率
    61
  • 9
    MCP 工具生态升温后，企业 AI 中台要解决什么问题？
    88
  • 10
    我受够了在四个 AI 编程工具之间当"复制粘贴工程师"，于是写了 Roundtable
    112

    • 相关课程

    更多
  • 事件总线EventBridge生态集成课程
  • Git从入门到进阶
  • 消息队列 RocketMQ 消息集成
  • MSE微服务测试最佳实践 - 自动化回归
  • Git 基础入门到实战详解

    • 相关电子书

    更多
  • 新一代自动化渗透平台的设计与实现
  • 自动化、智能化网络运维
  • 从自动化到智能化的阿里运维体系

    • 相关实验场景

    更多
  • 基于Assistant Api的旅游助手
  • 快速体验智能体API应用
    • 下一篇
    一条命令迁移，帮你实现 OpenClaw 与 Hermes Agent 记忆互通！