10 分钟用 TaoToken Key 跑通 GitHub MCP Server 并核对 Token 消耗

🚀 告别海外账号与网络限制!稳定直连全球优质大模型,限时半价接入中。 👉 点击领取海量免费额度

1. github/github-mcp-server 的两段链路,先分清楚再动手

github/github-mcp-server 是 GitHub 官方开源的 MCP server,它本身不做任何模型调用;这次我把它接到 TaoToken 的统一通道上,Key 和用量都在 https://taotoken.net/?utm_source=taotoken_aicg_blog_generate&utm_content= 核对。这个 server 用 Go 写的,仓库名就是 github/github-mcp-server,发布形态给得挺全:官方 Docker 镜像 ghcr.io/github/github-mcp-server、可以自己 go build 的源码、以及 GitHub 托管的远端 HTTP 端点。它把仓库文件、Issue、Pull Request、Actions 运行记录、代码搜索这些能力包装成一组标准 MCP 工具,客户端接上以后,模型在对话里就能直接调。

但接之前得先把链路上的两段分开看,否则后面所有成本数字都会算错。第一段是 MCP 通道:客户端到 server,走 stdio 进程管道或者远端 HTTP,传的是工具定义(tools/list 返回的 JSON Schema)和工具执行结果(tools/call 的返回体)。第二段是模型通道:客户端到模型服务,传的是完整 prompt,也就是系统提示、工具定义、历史对话、工具结果的拼接体,拿回来的是模型输出或者 tool_call 请求。Token 计量只发生在第二段,MCP 通道自己一个 token 都不花。

这个区分直接决定了成本怎么看。GitHub 的 toolset 数量很多,全开的话 tools/list 返回的工具定义 JSON Schema 加起来很容易上万 token,而且每一轮请求都要原样重发一次。所以经常出现的情况是:用户只问了一句话,账却主要花在工具定义和工具返回的 JSON 上。想把 Token 压下来,要动的不是提问方式,而是 toolset 裁剪和返回字段控制。

客户端这边,Claude Code、Cline、Claude Desktop、Cherry Studio 这类支持 stdio 的都能接。远端 HTTP 版本省掉本地 Docker,但要走 OAuth 授权流程,可控性弱一些;本地 Docker 版本能把 GitHub PAT 留在自己机器上,还能用 toolset 参数做裁剪,做用量核对时更顺手。本文走本地 Docker 版本,因为它的每一步都能被观察和复现,出问题也容易定位在哪一层。

还有一点需要提前说清楚:MCP server 拿到的是真实的 GitHub 凭据,模型通过工具调用能真的去读仓库,如果权限给大了也能真的改东西。所以这条链路的第一原则是权限最小化,只给读权限,让模型只做查询和解释;确实需要写操作时,让它把命令或 API 调用打印出来,由你自己在本地执行、再把结果贴回对话。本文的 Prompt 也只做只读查询。

2. 把 github-mcp-server 起起来:PAT、Docker 启动命令与探活

2.1 先做一把只读 PAT

在 GitHub 的 Settings → Developer settings 里建 token。Fine-grained token 的话,Repository access 只勾你要查的仓库,Permissions 至少给 Metadata: Read(这个是必选)、Contents: Read、Issues: Read、Pull requests: Read;需要看 Actions 运行日志再加 Actions: Read。Classic token 的话,勾 repo 和 read:org 对查询场景基本够用。别为了省事把写权限一起勾上,MCP 工具是模型在调,权限越大越容易出意外。

2.2 stdio 启动命令

export GITHUB_PAT=github_pat_xxxxxxxx
export GITHUB_TOOLSETS=repos,issues,pull_requests

docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN="$GITHUB_PAT" \
  -e GITHUB_TOOLSETS="$GITHUB_TOOLSETS" \
  ghcr.io/github/github-mcp-server

-i 必须留,stdio 靠标准输入输出通信,去掉 -i 容器起来就退。--rm 让容器用完即清,免得本地堆一串停止的容器。镜像默认进 stdio 模式,如果你用的版本要求显式传子命令,就在末尾补一个 stdio。启动参数和环境变量的确切名字以官方 README 为准,不同版本对 --toolsets 的位置要求可能不一样。

2.3 手工探活,把 server 和客户端分开验

在接客户端之前先单独确认 server 能起来:

printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}' \
| docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN="$GITHUB_PAT" \
  ghcr.io/github/github-mcp-server

返回体里能看到 serverInfo 字段,就说明进程和握手都正常。这一步如果就报错,问题一定在 Docker 或 PAT 上,跟客户端、模型通道都没关系。先把这个层面排干净再去配客户端,能省掉大量来回试。

2.4 不想用 Docker 就本地编译

git clone https://github.com/github/github-mcp-server.git
cd github-mcp-server
go build -o github-mcp-server ./cmd/github-mcp-server
GITHUB_PERSONAL_ACCESS_TOKEN="$GITHUB_PAT" ./github-mcp-server stdio

本地编译的好处是启动快、日志直接打在终端上,调 server 本身的问题时看得清楚;坏处是 Go 版本和依赖得自己维护。Docker 版本的好处是换机器复制粘贴就能跑,团队里共享配置片段更省事。两种都行,关键是别在同一个环境里混着用,否则排查时会分不清当前跑的是哪个。

2.5 toolset 做减法

GitHub MCP server 的工具按 toolset 分组,常见的有 repos、issues、pull_requests、actions、code_security、discussions、notifications、orgs、users、gists、labels、context 等。具体名字和数量以你启动后 tools/list 的返回为准。做仓库查询只需要 repos + issues + pull_requests 三个,Actions 日志、代码扫描、通知这些用不上就别开。每开一个 toolset,工具定义就多一段,而这段是每一轮请求都在重复发送的固定成本。

2.6 用 context 里的轻量探针先试一次

如果你只想验证「客户端能不能正常调工具」,用 context 这个 toolset 里的账号信息查询是最省 token 的一条路。它返回的是当前 token 对应的用户信息,结构简单,不会像 Issue 列表那样一次带回来几千 token 的正文。先跑这条通了,再换到真实的仓库查询,能把「配置问题」和「上下文太大」这两类故障分开。

3. 客户端两个配置块:MCP server 片段与模型通道三件套

3.1 Claude Code 加 MCP server

命令行方式最省事:

claude mcp add github --scope user -- \
  docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=github_pat_xxx \
  -e GITHUB_TOOLSETS=repos,issues,pull_requests \
  ghcr.io/github/github-mcp-server

加完用 /mcp 看 server 状态。想手写配置就放到 ~/.claude.json 或项目下的 .mcp.json

{
  "mcpServers": {
    "github": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "-e", "GITHUB_TOOLSETS=repos,issues,pull_requests",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "github_pat_xxx"
      }
    }
  }
}

-e 后面只写变量名,值由 env 块注入 docker 进程环境,这样 PAT 不用明文写进 args 里。

3.2 模型通道三件套

MCP 配好只解决了第一段链路。第二段要把客户端指向统一通道,Key 在 TaoToken 创建。Claude Code 走 ~/.claude/settings.json 的 env 块:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://taotoken.net/api",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY",
    "ANTHROPIC_MODEL": "以模型广场为准"
  }
}

三个字段各管一件事:BASE_URL 是网关地址,AUTH_TOKEN 是刚创建的 Key,MODEL 是模型 ID。Base URL 固定 https://taotoken.net/api,末尾不带 /v1,也不要把任何 UTM 参数拼上去——UTM 只用于官网页面统计,拼到 API 地址上会直接 404,而且报错信息通常不会告诉你原因。

3.3 命令行方式

npm install -g @taotoken/taotoken
taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID

-m 后面的模型 ID 以模型广场当前展示为准,别用记忆里的名字硬填。

3.4 Codex 不套 ANTHROPIC_*

Codex 走的是 ~/.codex/config.toml,字段是 modelmodel_providerbase_urlenv_key 这一套。把 ANTHROPIC_BASE_URL 搬到 Codex 里是配不上的,这是两个客户端两套变量命名,混着填只会看到连接失败,然后误以为是 Key 有问题。同一个账号下两个客户端可以并存,但配置文件各写各的。

3.5 CC Switch 场景

如果你用 CC Switch 在多个供应商之间切,就新增一个自定义供应商:Base URL 填 https://taotoken.net/api,Key 填 YOUR_API_KEY,模型 ID 填广场里的 ID,然后切过去重启客户端。切换后先跑一条最轻的纯对话,确认新的 BASE_URL 生效,再去跑带 MCP 的仓库查询。否则 401、工具报错、模型 ID 错误会混在一起,排查时间比配置时间还长。

3.6 确认工具真的加载了

配完重启客户端,用 /mcp 或客户端自带的 MCP 面板看 github 这个 server 暴露了多少工具。三个 toolset 加起来工具数一般在几十个量级,具体数字以你自己的返回为准。如果显示 0 个工具,先检查 Docker 镜像有没有拉下来、环境变量有没有传进去,再确认客户端是不是需要完全退出重开。有些客户端改完配置只重载窗口,MCP 子进程不会重启。

4. 跑通第一条仓库查询

固定 Prompt 如下,后面所有 Token 数字都基于这一条,方便你对照:

用 github 的 MCP 工具查询 facebook/react,列出最近 5 个仍处于 open 状态的 issue:
编号、标题、标签、最后更新时间。
只读,不要留言、不要改标签、不要关 issue。
最后用三句话总结这批 issue 集中在哪些方向。

执行过程通常是两轮模型调用。第一轮模型看到工具定义和你的问题,决定调用哪个工具,比如列 issue 或者搜索 issue;MCP 工具执行完把精简后的 issue 列表返回给客户端;第二轮模型拿到工具结果,写成你要的总结。如果返回内容特别多,可能会多一轮,但只读查询的场景一般两轮就够。

只读边界要写在 Prompt 里,也要在权限上兜底。MCP 工具能做什么取决于 PAT 权限,只读 token 下模型就算想写也写不了,但 Prompt 里明确「只读」还能减少它去尝试写操作的概率,少一轮无效的失败调用就是少一轮 token。如果确实需要模型帮你准备一个改标签或关 issue 的命令,正确做法是让它把命令或 API 调用打印出来,你自己在本地执行,再把结果贴回对话。

第一次跑建议把返回条数限制在 5 到 10 条。Issue 正文、评论、标签加起来很容易几千 token,条目一多,第二轮汇总的输入就撑起来了。等链路稳定、账也核清楚了,再逐步放宽条数,这样每加一档你都知道多花在哪儿。

结果回来后,把工具返回的原始列表和模型的总结并排看:如果总结里出现列表里没有的编号,说明它在编,这时候应该要求它只基于工具返回值作答,或者干脆把返回的 JSON 贴回去让它重新整理。MCP 的价值是让模型读到真实数据,不是让它自由发挥。

5. 一次仓库查询的 Token 消耗核对表

先说清楚这张表的性质:它是本地一次运行的观测,环境是同一把 Key、同一条 Prompt、同一组 toolset,不代表任何公开榜单,本文也不含排行分数。你自己的数字会因为客户端版本、工具集数量、返回条数不同而明显变化,有价值的是拆分方法,不是这几个具体值。

环节输入 Token(约)输出 Token(约)说明
系统提示 + 三个 toolset 的工具定义6,9000每轮请求重复发送
固定 Prompt450见第 4 节
第 1 轮模型响应(选择工具)6,95085决定列 issue 还是搜 issue
MCP 工具返回(5 条精简字段)1,4000进上下文,下一轮重发
第 2 轮模型响应(写总结)8,400380输出自然语言
单次会话合计约 23,700约 465条数一变,数字就变

自己取数的方式:Claude Code 会把每轮请求写进 transcript,usage 字段里有 input_tokens、output_tokens、cache_read_input_tokens。一条命令能把一个项目的账合起来:

jq -s 'map(select(.message.usage)) | {
  input: (map(.message.usage.input_tokens) | add),
  output: (map(.message.usage.output_tokens) | add),
  cache_read: (map(.message.usage.cache_read_input_tokens // 0) | add)
}' ~/.claude/projects/*/*.jsonl

把时间窗口卡在你跑那条 Prompt 前后,得到的数才是这次会话的。另一个口子是官网的用量页面,TaoToken 控制台能按 Key、按模型看请求数和 token 消耗,跟本地 transcript 对一遍,差得多就说明别的会话混进来了。计费单价、缓存折扣这些以官网展示为准,本文不猜价格。

表里有两个可以立刻动手的优化点。第一个是 toolset 裁剪:全开和只开三个,工具定义那一项能差出几千 token,而这是每轮都要重发的固定成本,省下来的是整条会话的比例项。第二个是工具返回体积:把 per_page 从 30 降到 5,或者让工具只返回编号、标题、标签这几个字段,第二轮的输入会直接少一大截。缓存命中会进一步影响实际计费,但缓存行为跟客户端提示词结构有关,别把「这次一定命中缓存」当默认前提。

还有一点值得注意:输入 Token 是累加的,第一轮 6,950 和第二轮 8,400 是两次独立计费,不是「总量 8,400」。很多人看 transcript 时只取最后一条的 usage,结果算出来的账只有实际的一半,对不上控制台就以为通道有问题。核对的时候把每轮的 input_tokens 加起来,才是这次会话真正发出去的输入量。

6. 排障:401、空工具列表、模型 ID 与 PAT scope

现象大概率原因处理
模型侧 401AUTH_TOKEN 空着,或 Base URL 填成了官网带 UTM 的页面地址三件套重填,BASE_URL 用 https://taotoken.net/api
模型侧 404Base URL 末尾多写了 /v1去掉 /v1 再试
报模型不存在模型 ID 用了记忆里的名字以模型广场展示为准,重新填
MCP 工具数为 0镜像没拉下来 / PAT 变量没注入 / 客户端没重启先用第 2.3 节探活命令单独验证 server
GitHub 侧 401 或 403PAT 过期,或 scope 不够重新签发只读 token,检查仓库范围
工具结果被截断单次返回体积太大降低 per_page,或减少返回字段
Docker 启动即退出漏了 -i补上交互式标准输入

这几个坑我自己踩过一遍,最费时间的不是任何一个单点,而是没按顺序排。合理的顺序是:先用探活命令确认 server 单独能起来,再确认客户端能看到工具列表,最后确认模型通道能正常出字。三步里同时改多个地方,最后根本判断不出是哪一处生效了,只能靠反复试。

另外提醒一个容易误判的现象:模型侧报错和 GitHub 侧报错都会显示成 HTTP 401,但来源完全不同。模型侧 401 出现在对话开始之前,你还没看到任何工具调用;GitHub 侧 401 出现在工具执行阶段,通常能看到工具名和失败状态。看报错出现在哪一步,比读报错文案更快。

7. 复现清单与下一步

把整条路径收拢成一份可照着走的清单:

  1. GitHub 侧建只读 PAT,仓库范围只勾需要查的。
  2. 用第 2.2 节的命令起 server,探活能看到 serverInfo。
  3. 把 MCP 片段写进客户端,/mcp 能看到几十个工具。
  4. 三件套把模型通道指向 https://taotoken.net/api,模型 ID 按广场填。
  5. 用第 4 节的固定 Prompt 跑一次,记录每轮的 usage。
  6. 本地 transcript 和官网用量页对一遍,确认这次调用入账。

这套流程走顺之后,下次换成别的 MCP server,比如本地文件系统只读、内部文档检索、数据库结构查询,要改的只有 MCP 片段,模型通道那三个字段不用动。这也是统一通道的实际价值:不同 server 共享同一套 Key 和 Base URL,用量能在同一个面板里对账,换模型只改一个模型 ID。TaoToken 在这里承担的正是 Key、Base URL 和对照基线这个角色,被查询和被评测的始终是 GitHub 的数据和你选的那个模型。

跑完这条查询,可以打开 模型对话 确认刚才用的模型 ID 与广场展示是否一致;打算把 MCP 查询做成日常动作的话,Coding Plan 更适合长期跑。Key 在 控制台创建,Claude Code 三件套的写法对照 接入文档。先把这次调用的本地记录和用量页对平,再决定要不要把 toolset 开大。

🚀 告别海外账号与网络限制!稳定直连全球优质大模型,限时半价接入中。 👉 点击领取海量免费额度

相关推荐

如何打造具有区域竞争力的智能制造公共服务平台?.docx

科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。

10 分钟TaoToken Cline 的 GitHub MCP 仓库操作

Cline 挂 GitHub MCP issue→PR 的仓库操作复现:先在 cline_mcp_settings.json 里接 DockerGitHub MCP Server,只读工具进 autoApprove、写操作留手动;再读真实 issue #12,只改 src/cli.js,最后生成 commit 与 PR 内容自行在终端执行 git 命令。TaoToken 作为统一入口,单次会话记录 30,380 输入 / 2,400 输出 tokens,非公榜排名,附 401/404 与 MC

Ceshi01的博客 2

政府科技部门如何构建高效的产业融合创新中心?.docx

政府科技部门如何构建高效的产业融合创新中心?

10 分钟TaoToken Claude Code + GitHub MCP server

10 分钟为限,用 TaoToken 统一 API Claude Code 与 GitHub MCP server 的组合。文章按实测路径给出环境变量配置,强调模型 ID 须以模型广场为准,用同一把 Key 依次执行列 issue、读文件、提 PR 三个操作。作者记录了自己的 Token 消耗差异:提 PR 约为列 issue 的 3 倍,且 MCP 操作本身不消耗 Token。完整流程及排障见 https://taotoken.net/?utm_source=taotoken_aicg_b

Ceshi01的博客 7

10 分钟TaoToken 让 Continue GitHub MCP Server

在 Continue 里接入 GitHub MCP Server,用 TaoToken 作模型后端,完成列出仓库 issue、读取 PR 内容两个动作。文中给出可粘贴的 mcp.json 片段、TaoToken 的 OpenAI 兼容 config.json 配置,以及 MCP 工具调用日志示例,列出 401、404、MCP server not found 等失败分支的排查顺序。GitHub TokenTaoToken Key 分开管理,模型 ID 以 TaoToken 官网为准。

weixin_35750747的博客 165

10 分钟TaoToken Cline 的 GitHub MCP Server

在 VS Code 用 Cline 调 GitHub MCP Server,完成列出 issue 与创建 issue 两个动作,模型侧经 TaoToken 统一转发。含可粘贴的 cline_mcp_settings.json 片段、GitHub PAT 与 TaoToken Key 的分工说明、Claude Code/Codex/CC Switch 的接入写法,以及 MCP 启动失败、401/404、模型不调用工具等失败分支排查表。

weixin_35751412的博客 18

10 分钟TaoToken MCP 官方 memory server

TaoToken 接入 MCP 官方 memory server,实测义 Qwen3.7 Flash 完成 create_entities 写入与 search_nodes 检索两次 Tool call。给出 npx 启动命令、Claude Code/Codex/CC Switch 配置写法、Base URL 与 Key 填法,附 401/404/检索为空等失败分支排查,最后在 TaoToken 控制台核对 Token 用量。

weixin_42602726的博客 51

如何高效组织校地合作技术转移活动?.docx

科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。

rtl8822蓝牙驱动资料

代码下载地址: https://pan.quark.cn/s/48b01f0717eb 本文将详细研究有关rtl8822蓝牙驱动及其适配的相关信息。rtl8822是由Realtek公司设计的一种无线信芯片,主要应用于提供Wi-Fi和蓝牙功能。该芯片被广泛应用于多种现代电子设备中,例如笔记本电脑、路由器、智能手机以及平板电脑等。 我们首先需要理解“驱动”的定义。驱动程序充当计算机硬件与操作系统之间的中介,负责将硬件指令解释为操作系统能够识别的语言。对于rtl8822芯片而言,蓝牙驱动是控制该芯片执行蓝牙信的核心软件模块,它确保设备能够准确识别连接其他蓝牙设备。 rtl8822驱动资料常包括以下几个部分: 1. **Bluetooth Baseband (BB) 驱动**:这一部分负责处理蓝牙的底层信,包括射频信号的编码与解码,以及数据包的发送和接收。 2. **Bluetooth Host Controller Interface (HCI)**:HCI层是蓝牙驱动的重要组成部分,它确立了蓝牙主机(例如CPU)与控制器(例如rtl8822芯片)之间的接口协议。借助HCI,应用程序能够与蓝牙设备进行互动,如配对、建立连接、传输数据等。 3. **移植文档**:移植文档是将rtl8822蓝牙驱动适配至不同操作系统或平台的关键指南,其中常包含了详尽的步骤、注意事项以及可能遇到的问题的解决方案。这些文档有助于开发者理解驱动的工作原理,根据目标系统进行必要的调整。 4. **芯片手册**:Realtek为rtl8822芯片提供的手册是开发和调试驱动的重要参考资料,其中涵盖了芯片的硬件特性、寄存器布局、接口规范、功耗管理等内容。熟悉这些信息能够帮助开发者更深入地...

技术转移中心如何过专业化服务提升区域创新活跃度?.docx

科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。

OpenCV乒乓球运动检测跟踪(陈锴)

源码直接下载地址: https://pan.quark.cn/s/95b325c17039 本研究着重研究了运用OpenCV技术对乒乓球竞赛中运动中的乒乓球进行检测与跟踪的方法。乒乓球运动具有极高的速度,且在比赛期间常被运动员的身体部分遮挡,这对图像处理和模式识别技术提出了较高的标准。文中阐述了采用C++语言开发的算法程序,过即时视频分析乒乓球的运动路径,对相关技术的应用进行了深入的研究。 OpenCV是一个由Intel公司支持的开源计算机视觉库,在图像处理、模式识别、目标检测与跟踪等方面展现出卓越的性能。OpenCV能够兼容多种编程语言,具备跨平台运作和轻量化的特点,因此被选作本研究的核心技术平台。本研究的宗旨在于协助教练员精确评估运动员的击球技术特征和乒乓球的运行表现,过实时追踪乒乓球的运动路径、落点及击球时刻,为乒乓球竞赛的视频转播、技术数据统计等提供自动化服务。 为了达成乒乓球比赛视频录像中乒乓球运行路径的检测与跟踪,本研究采用了改良的Surendra算法执行乒乓球体的识别,同时运用CamShift算法对高速运动的乒乓球进行追踪。另外,还引入了Kalman预测算法以提升对乒乓球路径的精确跟踪。 在技术方案中,研究者最初选择了现场拍摄随后进行后期处理的方法,在验证成功后改用实时拍摄实时处理的方法进行乒乓球的识别与跟踪。研究视频选取了符合竞赛规范的场地和乒乓球,且设置了特定的摄像机位置。由于乒乓球容易被运动员的身体遮挡,给识别和跟踪带来了挑战,研究中采用了YUV图像格式的模式识别,在必要时进行运动目标的判定识别。此外,由于乒乓球运动速度极快且带有弧线旋转,研究中加入了预测算法以保证路径的精确跟踪。 整体的研究计划涵盖了乒乓球运动球体的检测、跟踪以...

如何提升科研项目路演活动的转化效果?.docx

科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。

信soc-pmu状态机设计

信soc-pmu状态机设计

如何突破高校科研经费不足与产学研合作的瓶颈?.docx

科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。

国央企如何优化科技创新资源配置,提升技术成果转化效率?.docx

科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。

园区企业智能制造转型面临资源分散、服务获取难如何破局?.docx

科易网基于40亿+科创知识图谱数据库,深度探索AI技术在技术转移、成果转化、技术经纪、知识产权、产业创新、科技招商等垂直领域的多样化应用场景,研究科技创新领域的AI+数智化解决方案,推动科技创新与产业创新智能化发展。

钉钉02.docx

钉钉02

上一篇: Hugging Face:Kimi K2.7 Code 权重下载后,TaoToken 当默认供应商
下一篇: TaoToken 10 分钟跑通 Roo Code + GitHub MCP Server 的 repo 读取任务
ceshi01
博客等级 码龄18年 1粉丝 4603原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值