云雾api令牌创建方法

好，现在讲在八 a 中如何调用我们的第三方 api， 先是新建一个这个， 再连接一个 h t t p 请求， 然请求要改成 pos， 请求网址就填入我准备好的， 这是填入我们的调用地址，这边要开启请求头和请求体， 请求头这里也给大家准备好了，可以输入以下这些， 以下这些，这里两个文件， 这个 tmi 来到我们的官网，在令牌管理这边新建一个令牌， 然后令牌分组，记得选 auto， 无限额度可以打开，其他的就不要动了，令牌就创建好了，创建好之后复制这个令牌密钥，再回到这里，令牌输入进去， 然后再新建一个， 再把内容类型也填进去， 这样就好了。然后请求体这边我们要给它用 json 格式，我这边已经给你们准备好了，整个复制进去就行。 复制一张可以 ct l o s 保存，等它保存成功就可以把它关掉了。选中运行，我们稍微等待一会儿， 这样就请求成功了。返回后台看一眼，点击令牌管理，这样就是请求成功了。

open code 的 第三方配置教程来了，首先打开命令行，先去安装 open code n p m i g open code a a 安装完之后就可以去命令行配置 json 文件， 这里已经安装就不演示了，开我们的 c 盘用户文件夹下，然后有个点 com fake 文件，安装之后会出现一个 open code 文件夹， 进入之后我们新建一个 open code json， 打开这个 js 文件进行配置，我们把要配置的内容复制进来。 这边我们默认的模型是 model a game n 三 pro 调用地址已经填入了，可以不用修改。 后面只要把我们站点内的密钥复制过来，回到我们站点令牌管理这边，把密钥复制下来，再粘贴到这里，记得保存，之后关闭文件， 就可以用我们的 open code 项目。 然后在 models 这里进行模型选择，我们要的是真 m i 三，就第一个发个 hi 试试， 这样就可以正常交流了， 这样就可以正常调用了。来到我们的使用日记处检查一下，是可以看到有一个调用信息的。

今天给各位老板出一期在新版清检客服中， api 令牌如何绑定？先给大家解释一下什么是 api 令牌？ api 与令牌要分开？介绍什么是 api， 不 同软件之间的翻译官。举个例子，你在美团点外卖时，美团 app 需要获取餐厅的菜单、库存、配送费等信息， 但美团和餐厅的系统是分开的，怎么让他们对话？ api 就是 他们的翻译官。什么是 api 令牌？还是以餐厅为例子？令牌是使用 api 通道的身份凭证，就像餐厅只给美团、饿了么等合作平台发门禁卡，只有持令牌者才能通过 api 获取信息。 一句话总结， api 等于软件之间的对话通道，让功能互通。 api 令牌等于这个通道的钥匙，保证只有授权者能用。现在我们再来看看清检客服的 api 令牌该如何绑定。 我们来到首页，打开机器人管理界面，找到 ai 配置，就能看到 api 基础地址，下面是 api 令牌，点击获取令牌会跳转到算力符网页，点击左边栏的令牌，找到添加令牌， 设置好相关参数，一个专属你的 a p i 令牌就设置好了。回到 ai 配置页面，将令牌复制即可，点击测试，看是否连接成功。

回到我的频道，那么在进入工作流程之后呢，首先是需要先创建 open， loop， k i e 还有 google 这四个平台的，呃，其实这两个是一样的，但是需要创建两种形式，那么首先介绍第一种形式，呃，获取 api key 的 方式都在 google 呃 no 首文档里面了， 点击创建立牌，然后一直下滑，找到这个这个 bear out， 然后记得先把这里重命名一下，然后把你在那个平台拿到了 api key 输入这里就行了，输入完了，效果就这样子。 那么获得完这两个，这个的方式已经写在 note 文档里，也有教程，然后这个也是一样的，只是说再要再配几遍也是在这里，然后直接这里也可以直接搜索， 然后选择这个也是一模一样，把这里刚才得到 apikey 这个平台输入就行了。那么现在介绍工作流里面怎么用上这些令牌？ 以这个合并视频为例，打开这样的一个球状的图标，就是网络请求，只需要看这个 url 里面的关键字，如果像这个是 for 平台的， 那么就把你在 four 平台的那个 api key 输入到这里就行了。我这里就做一个双引号，把这个覆盖就行了，并且记住这个 key 和这个令牌之间是有一个空格的，然后同理把这两个也改就行了。那么还有另另外一种形式， 是啊，这是主的工作流，就像这个分析视频的主工作流里面有一个叫 rap 的 平台，也只有这个节点需要，也是双击打开后呢， 你可以看到这里有 rap 的 api， 你 只需要把你的 api 输入到这个里面就行了。好的。还有另一种形式，就是像这个分析视频的节点，看这里的话是要用的 open root， 我 们也就如果你前面已经配置好了，那么你只需要选择这个 bios， 然后选择这个同样名字就行了。下面说一下谷歌文档的问题，谷歌文档之后，首先你得有个谷歌账号，然后进入这个谷歌的表格这个形式， 然后创建一个名字是这个的，你也可以自己改，默认形式就是以这样这几个列为形式，当然如果你要改的话，要同时记得去改工作流里面的就行了。例如像这个生成图片呢，打开之后呢，像这样图标的都需要去改，如果你改了对应的列的话， 首先这个的话就是显示你是哪个表，可以看到这个名字跟我刚才说的那个名字是一样的，同时呢这就是裂了，所以如果你改了，像开头或者是这些，你要这里也会显示一个感叹号，显示你需要同步，所以你只需要点这个，他就会自动同步，然后你只要把左边的拖过来就行了。

接下来我就不客气了，模板剪辑教程，三秒钟教会大家首先触碰这里找到它，然后打开小圆圈， a i， 选择这个 seedens 二点零上传宠物的照片，粘贴我评论区的指令，看不到的保存这张截图，这里可以更改比例，还有时长发送，等待一会就可以了。

大家好，在 web 项目中，用户身份验证是非常重要的。从这节课开始，我们要介绍一下 jason web token， 简写为 j w t， 它是一个安全机制。在一个系统中，除了注册用户登录系统等部分， api 接口可以不用验证请求者身份。大多数情况下， api 接口是需要验证请求者身份的， 除了要了解请求者身份，服务器还要判断请求者有没有权限请求接口相关数据。目前比较流行的是 tok 令牌机制， 即用户登录成功后，服务端用数字加密技术将用户信息和权限信息以及有效期加密，生成一个令牌 tok 字符串返回给客户端， 由客户端在本地保存。用户每次向服务器请求信息，都要一并将令牌字串通过信息头的 authorization 授权项提交给服务器，再由服务器对令牌 token 信息进行解密，解密成功说明令牌有效， 并从中读取用户信息和用户权限。然后 api 接口就可以根据该信息判断用户是谁，有否权限，并据此进行响应。 这节课我们安装 express 版的 json web token， 并写一个中间键部署到服务器中。下面安装 jwt 软件包，在项目的 server 文件夹中打开 windows 命令窗口， 输入 npm install json web token 空格 express 杠 jwt 回车。然后我们等一会儿 安装成功。下面我们回到编辑器，在 server 的 user 文件夹下新建一个 j w t， 点 j s 文件， 首先是引入 j w t， 如果可以自动完成剩余部分，则说明安装成功。 定义一个 secret key， 密钥就是一串乱码，自己记不住，别人猜不着就行。再定义一个 n less url， 排除指定 url 的 宿主，该宿主中的所有 url 接口均不执行数据解码工作，以提高服务器响应速度。 我们封装一个有 export 关键字的可导出函数，叫 create gt， 参数为 payload 有 效载荷一个 max age， 有 效期默认是二十四小时。 调用 jwt 的 send 函数，它返回一个加密的 token 定牌字符串儿。我们再封装一个 jwt 的 verify 验证函数，其功能是将 token 定牌用当前的密钥进行解码，并返回解码后的内容。 下面我们开发借 w t 身份验证中间键。用 export 关键字定义一个可导出函数，借 w t mid y 中间键函数， 其参数是中间键固定的。第一步是验证当前请求接口是否在排除之列。先定一个变量，以 exact 为真，代表可以执行解码， 然后便利 unless url 宿主。如果匹配上当前的接口 url， 则将 is exact 置为假，不再执行解码。 如果可以解码，则从用户上传的信息头中提取 authorization 授权项，其内容应该是 virus， 意思是持有者 空格后是 togg 令牌字母串儿，我们从其中去掉 builder 后便得到 togg 令牌字母串儿。如果其存在内容，则进行解码，并在 request 请求对象上加上一个 user 用户属性，其内容就是 togg 解码后的内容， 其保存的就是用户信息，方便其他接口函数调用。最后调用回调函数 next， 结束中间键。 下一步我们要部署该中间件。我们打开服务器 server 文件夹下的 index， 点 j s 文件，在设置和中间件部分进行部署，写入 app， 点 user 括号 j w t midy， 中间件会自动引入， 为了代码清晰，我们将引入从引入接口部分移到上面，这样我们的中间键就部署完成了。我们就完成了借 w t 身份验证包的部署工作。今天的课就到这里，再见。

inception labs 刚刚发布了 mercury 二亿款扩散语言模型，速度突破了每秒一千个 token， 同时还能处理复杂的推理任务。性能与逻辑的结合迫使重新审视现代大模型构建。过去几年，你用过的几乎所有大模型 都遵循着同一个核心逻辑，当你提出问题，模型会预测出下一个 token， 接着是再下一个，如此循环往复，直到生成完整的答案为止。 这种方法效果显著，催生了聊天机器人、代码助手和早期的智能体应用，但这同时也让整个行业在速度与成本上遇到了瓶颈，即便优化底层架构也难以彻底突破。 而这款模型另辟蹊径，选择绕过而非强行冲破这一上线。它由 inception labs 研发，帕罗奥图初创公司由研究人员创立。它们曾协助发明了扩散技术，本身这种技术也是驱动 mid、 journey 和 sora 等图像及视频生成器的核心原理。不同于以往将语言视为一种必须逐字生成文本的方式， nukey 二将回复视为一个整体，并进行同步优化。系统最初生成的更像是结构化造声， 随后通过并行重复去造，直到答案最终锁定。这一关键转变彻底重塑了延迟与成本 以及模型在推理阶段的逻辑表现。当你看到这些性能数据时，在理解原理之前，你可能会觉得这太夸张了。该模型的处理速度突破了一千个 token 每秒。在实际精准测试中， cloud 四点五 hack 的 速度约为每秒八十九个 token， 而 gpd 五 mini 则在七十左右。这可不是微小的优化差距，这完全是另一个速度量级。 这种提升源于架构本身，而非依靠硬件黑科技或激进的捷径。比起单纯地秀速度，更重要的是， mercury 二是一款推理模型， 它能自主规划解决多部问题，调用工具还能处理结构化输出。它在运行智能体循环时，消除了每一步累积的延迟损耗， 这种结合才是真正的核心突破推理通常会拖慢模型的速度，每多出一个步骤，延迟都会不断叠加。在传统模型上，运行智能体工作流时，每一次调用都必须等待上一步完成，导致即使是简单的任务，在实际应用中也会有明显的迟滞感。 而这款 ai 彻底改变了这种现状，因为它是在扩散过程中进行推理，从而对答案进行整体优化。系统可以自行调整和修正， 并且能同时优化多个 token， 从而确保推理高效，避免过程永长。你可以把它理解为编辑与打字的区别。传统模型是逐字输入，打完即止。 mercury 二则会先生成整体草稿，然后不断润色，直至结果准确。这种循环优化使其在推理精准测试中准确率更高，同时在实际应用中保持极速，实现即时响应。这种平衡在基于数学推理的 a i m e 测试中得到了清晰体现。在考察高级数学推理的 a i m e 测试中， 模型得分超过九十分。在考察研究生水平科学推理的 g p q a 测试中，其得分落在七十五分左右。 在 live code bench、 i f bench 和指令遵循测试中，其表现其性能媲美或超越了主打速度的自回归模型，且运行速度更是快出数倍。这些并非刻意挑选的亮眼数据，在所有实际应用的关键领域，模型表现都非常稳定。 延迟数据也从另一个角度印证了这一点。系统的端到端响应时间约为一点七秒，在精准测试环境下，而同类模型要慢上几秒才能完成相同任务。 这一差距决定了 ai 助手是否能无缝融入工作流，还是一个让你时常停下来等待的割裂工具。这点的重要性远超人们的想象。 尤其是脱离了单纯的聊天演示之后，语音系统必须实现压秒即响应才够。自然代码助手则需要急速的往复交互，以确保开发者进入新流状态。搜索客服和内部工具都对延迟有着严苛的要求，哪怕微小的延迟也会累积成巨大的体验损耗。 mercury r 的 设计显然充分考虑了这些限制，另一个关键点在于它的实用性。该模型提供兼容 open ai 的 a p i 接口， 它支持工具调用、结构化输出解锁增强生成，即十二点八万 token 的 上下文窗口。这意味着你可以将其直接接入现有系统，且无需重构技术栈。 你无需在集成层改变现有范式，即可享受模型层带来的范式革新。定价策略也体现了生产环境优先的思路，每百万输入 token 仅需零点二五美元，输出 token 的 价格为每百万个零点七五美元。 结合吞吐量的巨大提升，每个完成任务的实际成本大幅下降。相比极其耗时、速度较慢的自回归模型，且逐个深层 token 的 低效自回归模型完成单项任务的实际成本大幅下降。尤其值得注意的是， 这种速度源自架构本身的创新，而非单纯依靠压榨硬件性能。过去几年，行业内的主要进展都集中在提升芯片速度、优化内核以及量化和蒸馏技术上。当然，这些进步固然重要，但这些改进本质上仍未脱离传统的序列生成框架。 而 mercury 二则彻底革新了这一框架。扩散技术让每次前向传播都能优化多个 token， 而非死板地逐一预测，这从根本上重塑了速度与质量之间的权衡关系。 这更像是一次跨越式的突破，而非微小的渐进式提升，虽然符合我们此前在图像深层领域、点锤贴纸以及视频深层领域见证过的扩散技术革命， 在此次发布背后还隐藏着更深层的规模化逻辑。自回归缩放定律曾让模型性能突飞猛进，但如今已陷入了边际收益递减的瓶颈， 单纯增加模型规模和数据量提升已微乎其微。而扩散架构则开辟了一条截然不同的道路，它更侧重于深沉的机制，而非盲目追求模型规模。该系统证明了这种方法在处理语言与推理任务时表现卓越，且已具备生产级规模，不再仅仅是实验室里的演示原型。 回过头看， inception 深厚的背景让这一切都在情理之中。其创始人由斯坦福、 ucla 和康奈尔大学的教授组成，并在扩散模型研究领域有着深厚积淀， 并曾主导过 flash、 attention 等早期突破性研究以及决策 transformer 及直接偏好优化这家公司于两千零二四年正式亮相，并迅速获得了 melon ventures， mayfield 和微软风投的青睐，还有英伟达风投， snowflake ventures， letter breaks 以及 innovation endeavors。 此外还包括吴恩达等个人投资者，以及 andre kopis 和 erik schmidt。 这种深厚的学术底蕴对工程实践的重视 在 murray 设计中尽显。我认为这里最吸引人的一点是，该模型重塑了关于推理的探讨。长期以来，业界一直认为推理能力与速度不可兼得， 要么为了更优质的答案而忍受缓慢的响应速度或者选择追求速度，从而限制了模型的思考深度。它消除了这种性能权衡。通过在变形精炼过程中进行推理， 这种方式更贴近人类解决问题的逻辑，先在脑海中构建整体框架，再通过逐层迭代不断精炼。这也正是该模型在智能体工作流中表现卓越的原应。当智能体需要不断规划、执行和观察时，延迟会迅速叠加。能够快速完成每步推理的系统 意味着更高效的反馈、更强的控制力和更可靠的表现。这让智能体不再只是有趣的演示，而是可靠的系统足以胜任 it、 运维等生产环境以及客户支持、销售工具及内部自动化。 你已经可以看到这些提示词由 inception 鼓励创作者尝试复杂模拟、交互式、格式化、结构化、指令遵循 以及受限深层挑战，这能发挥扩散模型架构优势。这类任务需要模型具备自我修正的能力，实现 token 间全局对齐，而非在深层初期草率定稿。然后既希望与后续内容能资源齐说，还有一个值得关注的细节， 就是他处理纠错的方式。由于模型在生成过程中会反复回溯，其输出错误就不会引发连锁反应，前期的偏差可以在后续的优化步骤中得到修正。单凭这一特性就彻底改变了多步推理的可靠感。 尤其在处理复杂长任务时，这一切所传达的意义远比发布一个新模型本身更为长远。 业界多年来一直致力于提升系列生成的效率，而 maker 二则向我们展示了当你不再执着于优化瓶颈，而是直接将其彻底消除会发生什么。扩散技术已彻底重塑了图文视频生成领域，在其完成规模化验证之后，如今语言模型领域 也正步入这一阶段。若你正致力于打造实时 ai 系统，且要求其响应灵敏、无缝集成，且在实际产品中体验自然的实时 ai 系统， 那么这项 ai 技术绝对值得你重点关注。真正的改革在于，推理体验正从底层逻辑上发生质变，更急速地响应让以往无法实现的产品设计方案成为可能。更低的延迟 正在悄然刷新用户对 ai 交互的既有认知。强大的高速推理能力让智能体工作更高效，既能保持操作连贯，又不消磨用户耐心。 mercury 二让扩散架构成为了有力竞争者在未来语言建模领域，尤其是在对速度 与可能性的要求远超参数规模的场景下，它已在多家财富，这说明该技术早已超越了实验阶段， 所以核心问题是扩散架构最终会重塑语言模型的构建方式，还是仅仅作为实时推理的一个特定分支？大家可以亲自上手体验。 mercury 二、相关链接已放在视频简介中，欢迎在评论区分享你的观点，订阅频道获取更多此类深度解析。我们下期视频。