1. 项目概述：GitMCP，一个为AI开发者准备的“项目说明书”自动生成器

如果你和我一样，每天都在和Cursor、Claude Desktop这些AI编程助手打交道，那你肯定也遇到过这个让人头疼的问题：当你问AI助手“怎么用Three.js画一个3D立方体”或者“LangGraph里怎么给Agent加记忆”时，它要么给你一段过时的、甚至错误的代码，要么就开始“一本正经地胡说八道”——也就是我们常说的“幻觉”（Hallucination）。这背后的原因很简单，无论多强大的大语言模型，它的知识都有截止日期，对于GitHub上那些日新月异、或者相对小众的库，它根本“没见过”最新的文档和代码。

今天要聊的这个开源项目 GitMCP ，就是专门为解决这个问题而生的。简单来说，它是一个基于 Model Context Protocol 的远程服务器。你可以把它理解为一个“智能翻译官”或者“实时资料员”。它的核心工作流程是：当你的AI助手（比如Cursor）遇到一个它不熟悉的GitHub项目时，它会通过GitMCP这个“翻译官”，去向目标项目的GitHub仓库“现场查阅”最新的README、文档（特别是 llms.txt ）甚至源代码。然后，GitMCP把这些“新鲜出炉”的信息整理好，喂回给AI助手。这样一来，AI助手给出的答案，就不再是基于它陈旧的训练数据“脑补”，而是基于项目最新的、真实的官方资料生成的。这相当于给你的AI编程伙伴装上了一双能实时“翻阅”GitHub的“眼睛”。

我最初是在一个关于Agentic AI（智能体）的讨论群里看到这个项目的，当时就觉得这个思路非常“正”。它没有试图去重新训练或者微调一个巨无霸模型，而是巧妙地利用了MCP这个新兴的协议标准，在模型外部构建了一个动态的、可扩展的上下文供给系统。这对于我们这些需要频繁使用各种前沿、快速迭代开源库的开发者来说，实用性直接拉满。无论是前端领域的Three.js、Vue，还是AI应用层的LangChain、LlamaIndex，只要它在GitHub上，GitMCP就能帮你把最新的项目文档“搬”到AI助手的对话窗口里。

1.1 核心价值：从“幻觉编码”到“精准编码”

在没有GitMCP之前，我们的工作流存在一个明显的断层。AI助手很强大，但它是个“闭门造车”的学霸，手里的教材可能是一年前的版本。GitHub上的项目很活跃，但AI助手看不到。GitMCP的价值就在于，它用极低的成本（对你来说是零配置）架起了一座桥，弥合了这个断层。

它的价值具体体现在几个方面：

  1. 准确性革命 ：最直接的提升就是代码和答案的准确性。AI基于实时文档生成的内容，其可靠性与直接阅读官方文档无异，极大减少了因信息过时导致的错误。
  2. 覆盖度扩展 ：那些刚刚发布一周的库、你公司内部私有的库（如果部署了私有GitMCP实例）、或者过于小众以至于没被大模型训练数据收录的库，现在都能被AI助手有效理解和调用。
  3. 开发体验升级 ：你不再需要频繁地在IDE和浏览器之间切换，去手动查找API文档。你可以用自然语言直接向AI提问：“这个库的 init 函数最新版本接受哪些参数？”，然后获得一个基于最新源码或文档的准确回答。这不仅仅是省了几次点击，更是将“查找-理解-应用”这个认知链条极大地缩短了。
  4. 生态友好 ：它完全遵循开源的Model Context Protocol，这意味着它不是一个封闭的黑盒服务。你可以自己部署、修改，它也能兼容所有支持MCP的客户端（Cursor, Claude Desktop, Windsurf等），不会把你绑定在某个特定的工具链上。

在我自己的实际体验中，用GitMCP接入一个我正在调研的、文档还不太完善的AI框架后，Cursor给出的代码示例和架构建议明显更贴切了，因为它“看到”了仓库里 examples 文件夹下的真实用例，而不是根据对类似框架的模糊记忆进行泛化。这种“精准制导”的感觉，对于追求效率和代码质量的开发者来说，是非常爽的。

2. 核心机制与架构拆解：GitMCP是如何工作的？

要理解GitMCP为什么有效，我们需要先搞懂两个关键概念： Model Context Protocol 和 llms.txt 。这是它的两大技术基石。

2.1 基石一：Model Context Protocol —— AI的“外接硬盘”协议

你可以把MCP想象成给大语言模型用的“USB协议”或者“插件系统”。以前，大模型的能力和知识都被固化在它的参数里，就像一个装满了书但无法联网的电脑。MCP定义了一套标准化的通信方式，允许像Cursor、Claude Desktop这样的AI客户端（我们称之为“AI助手运行时”），在需要的时候，向外部服务器（比如GitMCP）请求特定的信息或执行特定的操作。

这个过程是结构化和安全的：

  1. 工具暴露 ：GitMCP作为一个MCP服务器，启动后会向连接的客户端“宣告”：“我这里有这些工具可用： fetch_documentation （获取文档）、 search_code （搜索代码）等。”
  2. 请求与授权 ：当你在Cursor里提问关于某个库的问题时，Cursor（作为MCP客户端）会判断：“这个问题需要查询外部资料”。它会向你展示一个提示，例如“想要调用GitMCP的 search_code 工具来查找相关实现，是否允许？”。你批准后，它才会发出请求。
  3. 执行与返回 ：GitMCP收到请求，解析参数（比如要查哪个仓库，搜索关键词是什么），然后代表AI去执行真正的操作——调用GitHub API获取文件内容、进行代码搜索等。
  4. 上下文注入 ：GitMCP将获取到的原始文本、代码片段等数据，按照MCP规定的格式整理好，返回给Cursor。Cursor将这些信息作为“上下文”插入到给大模型的提示词中，最后大模型基于这份“新鲜”的上下文生成回答。

为什么这很重要？ 因为它实现了 “计算与知识分离” 。模型专注于它最擅长的推理、理解和生成，而动态的、实时的、私有的知识则由像GitMCP这样的专业服务器来提供。这比一味地追求把全世界知识都塞进模型参数里要灵活和高效得多。

2.2 基石二：llms.txt —— 面向AI优化的“项目说明书”

如果让AI去读一个庞大的、充满格式和导航的完整文档网站，效率很低，且会消耗大量token。 llms.txt 是一个新兴的、针对大语言模型优化的文档格式规范。它的理念是：为你的项目提供一个精简、结构化、纯文本的“速查手册”，专门给AI看。

一个典型的 llms.txt 文件可能包含：

  • 项目简介和核心用途。
  • 最重要的API列表及简短示例。
  • 关键概念的定义。
  • 快速上手的步骤。
  • 常见问题解答。

GitMCP在为一个仓库提供服务时，会 优先寻找并读取 llms.txt 文件 。如果找到了，它就会把这个高度优化过的内容作为主要文档源提供给AI。如果没找到，它会优雅地降级，去获取 README.md 或者其他它能找到的文档页面。这种设计非常聪明，它鼓励项目维护者提供对AI友好的文档，同时也保证了与现有大量项目的兼容性。

2.3 GitMCP的两种服务模式：精准制导与灵活探索

GitMCP提供了两种接入模式，对应不同的使用场景，这是它在设计上的一个亮点：

模式一：特定仓库模式

  • URL格式 ： https://gitmcp.io/{owner}/{repo} 或 {owner}.gitmcp.io/{repo}
  • 工作方式 ：就像你给AI助手一本固定的参考书。你配置好后，所有关于这个仓库的查询都会定向到这里。例如，你配置了 gitmcp.io/microsoft/playwright-mcp ，那么AI在回答任何关于Playwright MCP的问题时，都会去这个固定的地址找资料。
  • 优点 ：
    • 精准安全 ：AI不会“跑偏”到其他仓库，避免了上下文污染。
    • 性能优化 ：服务器可以针对该仓库做缓存等优化。
    • 意图明确 ：适合你深度使用的核心依赖库。
  • 实操心得 ：我建议将你项目最核心、最常咨询的2-3个依赖库配置为这种模式。比如你的前端项目主要用React和Tailwind CSS，那就为它们分别配置特定的GitMCP服务器。这样能获得最稳定、最相关的支持。

模式二：通用动态模式

  • URL格式 ： https://gitmcp.io/docs
  • 工作方式 ：就像你给了AI助手一张进入整个GitHub图书馆的通用门票。当AI遇到一个它不认识的库名时，它会通过这个通用端点，动态地向你询问或自行判断：“用户提到的‘three.js’对应的是GitHub上的 mrdoob/three.js 这个仓库吗？” 确认后，再临时去获取该仓库的文档。
  • 优点 ：
    • 极度灵活 ：无需预先配置，即可查询任何公开的GitHub仓库。
    • 探索性强 ：非常适合学习、调研新库的场景。
  • 注意事项 ：
    • 依赖AI的识别能力 ：如果AI错误地关联了仓库名，可能会得到不相关的信息。比如它把用户说的“vue”错误地关联到某个叫“vue”的个人笔记仓库，而不是 vuejs/core 。
    • 略有延迟 ：每次查询可能都需要一个“确认仓库”的交互步骤。
  • 避坑技巧 ：对于通用模式，在提问时尽量使用 完整的、常见的仓库标识 （如“mrdoob/three.js”），这能大大提高AI首次关联的准确率。如果AI询问确认，务必仔细核对它提议的仓库是否正确。

3. 全平台配置实战：手把手连接你的AI工作流

理论说再多，不如动手配一遍。GitMCP号称“零配置”，这里的“零”指的是你不需要自己搭建服务器。但将GitMCP服务连接到你的AI助手，还是需要一些简单的配置步骤的。下面我以最常用的几个工具为例，提供详细的配置指南和注意事项。

3.1 配置Cursor：深度集成开发环境

Cursor是目前对MCP支持最深入、体验最好的IDE之一。配置GitMCP后，它能在你写代码、提问题、甚至进行代码补全时，智能地调用GitMCP获取上下文。

操作步骤：

  1. 找到Cursor的MCP配置文件。它通常位于你的用户目录下： ~/.cursor/mcp.json （MacOS/Linux）或 C:\Users\<你的用户名>\.cursor\mcp.json （Windows）。如果文件不存在，直接创建它。
  2. 用任何文本编辑器打开这个文件。
  3. 添加GitMCP服务器的配置。假设你想连接 three.js 的文档，配置如下：
{
  "mcpServers": {
    "threejs-docs": {
      "url": "https://gitmcp.io/mrdoob/three.js"
    },
    "langchain-docs": {
      "url": "https://langchain-ai.gitmcp.io/langchain"
    }
  }
}
  1. 保存文件。
  2. 关键一步 ： 完全重启Cursor 。仅仅关闭窗口可能不够，需要从系统托盘或任务管理器彻底退出Cursor再重新启动，以确保配置被加载。

配置解析与避坑：

  • mcpServers 对象 ：你可以在这里定义多个GitMCP服务器，每个用一个唯一的键名（如 "threejs-docs" ）来标识。这个键名只是为了你在配置里区分，不会影响功能。
  • url 字段 ：这就是GitMCP服务器的地址。注意，对于GitHub Pages站点（如 langchain-ai.github.io/langchain ），GitMCP提供了第二种URL格式 {owner}.gitmcp.io/{repo} ，如上例所示。这两种格式是等价的，选择你记得住的那种即可。
  • 权限管理 ：首次配置后，当Cursor首次尝试调用GitMCP工具时，会在编辑器内弹出一个权限请求。 务必点击“允许”或“始终允许” 。如果你错过了或点了拒绝，需要到Cursor的设置（Settings）里，找到MCP或AI相关的权限管理页面，手动为 gitmcp.io 域名开启权限。
  • 验证是否成功 ：重启Cursor后，打开一个新对话，尝试提问：“Three.js中如何创建一个基础的旋转立方体场景？” 观察Cursor的回复。如果它开始工作前有一个“正在调用工具...”或类似的提示，并且最终给出的代码示例非常贴切、包含最新的API用法（例如使用了较新的 WebGPURenderer 如果文档里有提及），那就说明配置成功了。

3.2 配置Claude Desktop：对话式AI助手

Claude Desktop是Anthropic官方的桌面应用，通过MCP可以极大地扩展Claude的能力边界。

操作步骤（推荐方法）：

  1. 打开Claude Desktop应用。
  2. 点击左下角的你的头像，进入 Settings 。
  3. 在左侧边栏找到 Developer 选项。
  4. 点击 Edit Config 按钮。这会打开一个JSON配置文件。
  5. 在 mcpServers 部分添加配置。这里与Cursor不同，Claude Desktop通常需要通过一个叫 mcp-remote 的桥接工具来连接SSE服务器。
{
  "mcpServers": {
    "gitmcp-generic": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://gitmcp.io/docs"
      ]
    }
  }
}
  1. 保存配置文件并重启Claude Desktop。

原理解析 ：为什么Claude Desktop的配置更复杂？这是因为MCP支持多种传输方式，Claude Desktop默认更倾向于使用“命令式”服务器（通过 command 启动一个本地进程）。而GitMCP是一个运行在远端的“SSE”（Server-Sent Events）服务器。 npx mcp-remote 这个命令的作用，就是启动一个本地的小型适配器，这个适配器会去连接远程的GitMCP SSE服务，并将其转换成Claude Desktop能理解的“命令式”接口。这是一个非常标准的连接远程MCP SSE服务的方式。

注意事项 ：使用此方法需要你的系统已安装Node.js和npm/npx。如果不想依赖本地Node环境，也可以寻找或构建一个直接集成SSE的Claude Desktop配置方式，但目前通过 mcp-remote 是最通用和稳定的方法。

3.3 配置Windsurf / VSCode等编辑器

Windsurf、VSCode（通过扩展）以及Cline、Highlight AI等工具的配置逻辑与Cursor类似，都是修改一个特定的JSON配置文件。

通用流程与核心差异：

  1. 定位配置文件 ：这是最关键的一步。不同工具、不同操作系统的配置文件路径不同。
    • Windsurf : ~/.codeium/windsurf/mcp_config.json
    • VSCode (with MCP extension) : 通常在项目根目录或工作区设置中的 .vscode/mcp.json 。
    • Cline : ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json (MacOS)
    • 其他工具 ：请务必查阅该工具的官方文档，关键词是“MCP configuration”或“custom tools”。
  2. 编写配置内容 ：JSON结构大同小异，核心都是定义一个服务器，并指定其URL或命令。
    • Windsurf示例 : 
      {
  "mcpServers": {
    "gitmcp": {
      "serverUrl": "https://gitmcp.io/vercel/next.js"
    }
  }
}
    • VSCode示例 (使用 saraford 等人的MCP扩展): 
      {
  "servers": {
    "gitmcp": {
      "type": "sse",
      "url": "https://gitmcp.io/vercel/next.js"
    }
  }
}
  3. 重启生效 ：修改配置后， 必须完全重启对应的编辑器或AI助手应用 ，新的MCP服务器才会被识别和加载。

一个常见的坑 ：很多开发者修改了配置文件但没看到效果，八成是因为没有彻底重启应用。有些应用只会启动时读取一次配置。

4. 高级用法与实战技巧：像专家一样使用GitMCP

配置好了只是开始，真正发挥GitMCP的威力，需要一些技巧和对它底层工具的深入理解。GitMCP向AI暴露了几组核心工具，了解它们各自擅长什么，能让你在提问时更加有的放矢。

4.1 理解GitMCP的工具箱：四把利刃

当你配置好GitMCP后，你的AI助手就获得了以下能力（工具）。这些工具会在后台被智能调用，但你了解它们有助于你提出更精准的问题。

1. 获取项目概览 ( fetch_<repo>_documentation )

  • 功能 ：这是AI的“第一眼”。当它完全不了解一个项目时，会首先调用此工具，获取项目的核心介绍、主要功能、快速开始指南等。数据源优先是 llms.txt ，其次是 README.md 。
  • 最佳提问场景 ：“这是什么库？”、“ project-alpha 是干什么用的？”、“我该如何开始使用这个库？”
  • 实战技巧 ：当你调研一个新库时，可以直接让AI“给我总结一下 owner/repo 这个项目”。AI会调用此工具，然后给你一份清晰的摘要。

2. 深度搜索文档 ( search_<repo>_documentation )

  • 功能 ：当AI需要回答一个具体问题时，它不会把整个文档都塞进上下文（那太浪费token了）。相反，它会用这个工具，带着你的问题关键词（如“authentication”、“middleware”）去搜索文档，只提取最相关的片段。
  • 最佳提问场景 ：“在这个库里如何实现用户认证？”、“ Config 类有哪些参数？”、“错误处理的最佳实践是什么？”
  • 避坑指南 ：尽量使用 项目文档中可能存在的专业术语 进行提问。例如，问“怎么处理异步操作”而不是“怎么让代码等一会儿”。前者更容易匹配到文档中的“Async/Await”或“Promise”章节。

3. 抓取链接内容 ( fetch_url_content )

  • 功能 ：项目文档里经常包含指向其他页面的链接（如API详细说明、教程博客）。这个工具允许AI“点击”这些链接，获取更深层次的内容。
  • 工作流程 ：通常是 search_documentation 找到了一个相关章节，里面有个链接看起来能解答更多细节，AI就会自动调用此工具去获取那个链接的内容。
  • 开发者无需主动干预 ：这个过程是AI自动判断和执行的，体现了其“智能体”的特性。

4. 源代码搜索 ( search_<repo>_code )

  • 功能 ：这是“终极武器”。当文档不够详细，或者你需要看一个功能的具体实现时，AI会使用这个工具，直接搜索仓库中的源代码。它利用的是GitHub强大的代码搜索能力。
  • 最佳提问场景 ：“给我看一个使用 useEffect 钩子的完整组件例子”、“ utils/validation.js 这个文件里是怎么校验邮箱的？”、“这个错误码 ERR_001 是在哪里定义的？”
  • 威力展示 ：你可以直接对AI说：“在 expressjs/express 仓库里，帮我找找错误处理中间件（error handling middleware）的官方示例代码。” AI会调用代码搜索工具，找到 examples/ 或 test/ 目录下的相关文件，把代码片段呈现给你，并可能附上解释。

4.2 动态模式 ( gitmcp.io/docs ) 的进阶提问法

通用动态模式非常强大，但也更考验“提问的艺术”。以下是几个让合作更顺畅的技巧：

  1. 明确指定仓库 ：在问题开头就指明仓库。不要问“怎么用路由？”，而是问“在 remix-run/react-router 这个项目中，怎么配置嵌套路由？” 这能极大减少AI的猜测和确认回合。
  2. 利用对话上下文 ：一旦AI在本次对话中成功识别并连接了一个仓库（比如 vuejs/core ），后续的提问如果明显是关于Vue的，它通常会延续使用这个上下文，无需再次确认。
  3. 处理歧义 ：如果AI询问“你指的是 ownerA/repoX 还是 ownerB/repoX ？”，请务必根据你的真实意图选择。选错了会导致它查阅完全无关的文档，给出风马牛不相及的答案。

4.3 为你的项目添加GitMCP Badge：拥抱AI优先的文档

如果你是一个开源项目的维护者，为你的项目README添加一个GitMCP Badge，是一个向社区展示你对AI友好态度的很棒的方式。这个徽章不仅是一个链接，还会显示你的文档被通过GitMCP访问的次数。

添加方法： 在你的 README.md 文件中合适的位置（通常在顶部或“Getting Started”部分附近），添加以下Markdown代码：

[![GitMCP](https://img.shields.io/endpoint?url=https://gitmcp.io/badge/你的用户名/你的仓库名)](https://gitmcp.io/你的用户名/你的仓库名)

例如，对于这个项目本身，就是：

[![GitMCP](https://img.shields.io/endpoint?url=https://gitmcp.io/badge/idosal/git-mcp)](https://gitmcp.io/idosal/git-mcp)

它的作用：

  1. 一键直达 ：用户点击徽章，可以直接打开一个内置了GitMCP聊天功能的页面，让他们能立即开始针对你的项目文档提问。
  2. 数据反馈 ：徽章上的数字会随着访问量增加。这让你直观地看到有多少开发者正在通过AI工具了解你的项目。
  3. 社区信号 ：这表明你的项目积极适配现代AI辅助开发工作流，是一个很酷的“开发者体验”亮点。

维护者提示 ：为了让GitMCP效果最好，强烈建议为你的项目创建一个 llms.txt 文件。这不需要你重写文档，而是从现有文档中提炼出最核心、最常被问到的内容，以纯文本、结构化的方式呈现。这能确保AI在第一时间获得最高质量的项目概述。

5. 私有化部署与开发贡献：深入项目核心

虽然公用的 gitmcp.io 服务非常方便，但有些场景下你可能需要自己部署一个实例。

5.1 为什么要自托管？

  1. 访问私有仓库 ：公司内部的私有GitHub仓库，显然不能通过公共服务访问。自托管后，你可以配置GitHub App或Personal Access Token来让GitMCP访问你的私有库。
  2. 定制与增强 ：你可能想修改搜索逻辑、增加对非GitHub源（如GitLab、内部Wiki）的支持，或者集成其他内部工具。
  3. 网络与合规 ：出于网络策略或数据合规要求，所有流量必须留在内网。
  4. 学习与贡献 ：你想深入了解MCP服务器是如何构建的，并为其添加新功能。

5.2 本地开发环境搭建

GitMCP项目本身结构清晰，基于现代Node.js技术栈（从代码库看推测是TypeScript + Vite等工具），便于上手。

# 1. 克隆代码库
git clone https://github.com/idosal/git-mcp.git
cd git-mcp

# 2. 安装依赖 (项目使用 pnpm，确保已安装)
pnpm install

# 3. 启动本地开发服务器
pnpm dev

运行后，本地服务通常会启动在 http://localhost:5173 （具体端口请查看控制台输出）。现在，你就可以将你的AI助手配置指向这个本地地址了，例如在Cursor中配置 "url": "http://localhost:5173/docs" 来测试通用模式。

5.3 使用MCP Inspector进行调试

开发或调试自己的MCP服务器时， @modelcontextprotocol/inspector 是一个必不可少的工具。它是一个独立的调试客户端，可以连接并测试任何MCP服务器。

# 全局或临时安装MCP Inspector
npx @modelcontextprotocol/inspector

运行后，它会打开一个命令行界面或Web界面。你需要：

  1. 选择传输类型为 SSE 。
  2. 输入你的GitMCP服务器地址，例如 http://localhost:5173/docs 。
  3. 点击连接。

连接成功后，你可以在Inspector里手动调用GitMCP暴露的所有工具（ list_tools , call_tool ），并查看原始的请求和响应数据。这对于理解工具的工作流程、调试参数错误、验证返回结果格式是否符合MCP规范，具有无可替代的价值。

5.4 核心工作流程与扩展思路

通过阅读源码和调试，我们可以梳理出GitMCP的核心工作流：

  1. 路由解析 ：服务器接收到形如 /{owner}/{repo} 或 /docs 的请求。
  2. 工具注册 ：根据请求路径，动态生成并注册对应的工具集（ fetch_xxx_documentation , search_xxx_code 等）。对于通用模式，工具名是通用的，并在调用时需要额外参数指定仓库。
  3. 处理工具调用 ：当AI客户端发起 call_tool 请求时，服务器解析参数。
  4. 获取GitHub内容 ：
    • 文档 ：优先尝试获取 https://raw.githubusercontent.com/{owner}/{repo}/main/llms.txt ，失败则回退到获取 README.md 或尝试爬取GitHub Pages。
    • 代码搜索 ：构造查询，调用GitHub的代码搜索API（或模拟其行为）。
  5. 内容处理与返回 ：将获取到的原始文本进行清理、格式化（如去除无关HTML标签），然后按照MCP的 TextContent 格式封装，返回给客户端。

如果你想为其贡献代码或自定义开发，可以关注以下几个方向：

  • 支持更多文档源 ：比如从 docs/ 目录自动生成索引，解析 pyproject.toml 或 package.json 中的描述字段。
  • 增强搜索精度 ：集成更先进的本地文本搜索库（如FlexSearch），提供比简单关键词匹配更精准的文档片段召回。
  • 缓存策略优化 ：为频繁访问的仓库实现更智能的缓存机制，减少对GitHub API的调用，提升响应速度。
  • 认证集成 ：完善对GitHub Personal Access Token或GitHub App的支持，使其能稳定、安全地访问私有仓库。

这个项目的架构很好地体现了MCP的“工具调用”哲学，将外部能力封装成标准化的工具，供AI调度。理解了这个模式，你甚至可以尝试为自己公司的内部API、数据库、知识库构建类似的MCP服务器，打造专属的、强大的AI辅助开发环境。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

DeepSeek API涨价500%！Agent框架同步开源

avatar 亚马逊云科技技术品牌专区
cover

DeepSeek 又放大招！开源 AI Agent 框架 Harness：一切皆插件

avatar 亚马逊云科技技术品牌专区
cover

Agent Run 的状态机：别把智能体交给 LLM 自己管

avatar 亚马逊云科技技术品牌专区