AgentKey AgentKey 是一个连接 AI 智能体到实时外部数据的插件，适用于开发者，提供一键数据访问，无需集成，自动故障转移。 热门评论 PH 用户Hi Product Hunt，我是 Mogu，Chainbase 创始人。今天很高兴分享我们实验室的最新项目：AgentKey。它已经内测了一段时间，有几千人在用并帮我们打磨，现在终于觉得可以在大家面前亮相了。我们反复纠结的是这个问题：智能体做任务确实很在行了，但它们没有眼睛。它们能推理、能行动，但看不到真实的互联网——而几乎所有有用的工具和实时数据都在那里。于是出现了一个奇怪的缺口：一个足够聪明的智能体，却坐在一扇它看不到的窗户后面。而今天，给智能体装上眼睛是一件麻烦事。你要接一个 API 做搜索、另一个做爬取、再一个做社交、又一个做市场数据。你得照看一大堆 key 和账单，基本上得先懂底层管道才能开始。大多数能用上它的人，在这一步就停下了。所以我们建了 AgentKey。你像装插件一样安装它，你的智能体就能通过一个账户访问整个能力市场。不用折腾多个 API，不用管 key，也无需技术背景。一个账户、一张账单，你的智能体瞬间强大很多。目前市场分为几个层级，而且还在不断增长：- 日常工具：搜索、网页爬取、社交媒体- 专业数据：金融、加密货币、商业数据- 生活与旅行：天气、地图、行程规划等它已经接入了 20 多个人们常用的智能体，包括 Claude、Codex、Openclaw、WorkBuddy 和 Cursor。而且因为所有东西都在一个市场背后，如果某个供应商出问题，你的智能体可以自动切换到另一个源继续运行。我们深信智能体即将绽放成一个庞大、混乱、美妙的生态。最让我激动的是，人们终于可以把手头上真正复杂的工作交给智能体，而不只是基础任务，并且能信任它来完成。这也是我们在这里发布的主要原因。免费开始，不需要信用卡。请尽管来试，搞坏它，然后告诉我缺什么。我今天会在评论区待一整天。PH 用户说实话，工具发现方面的 token 数学是整个介绍里最具体的细节。从大约 35,000 个 token 降到大约 1,500 个，是通过训练一个检索层而不是把每个端点定义都塞进上下文——这是一个真正的架构决策，不只是营销话术。而且这也是那种一旦 MCP 集成扩展到几个工具以上就会悄悄搞崩很多集成的问题，确实如此。但当检索模型对模糊请求选错了端点，这个错误能被看到吗？还是说选错了只是下游悄悄得到糟糕结果？PH 用户Hey PH，我是 Cong，Chainbase 的创始工程师。过去几个月我一直在构建 AgentKey——一个为你的智能体提供一站式实时数据市场的平台。我想分享一下我们花最长时间才搞定的三个问题。1. 工具发现我们有大约 1,800 个 API 端点。如果把它们作为静态工具丢进 MCP，智能体光加载定义就要消耗大约 35,000 个 token 的上下文，而且有一半概率选错工具。所以我们构建了自己的意图识别层：智能体用自然语言描述它想要什么，比如“在 reddit 上找正在流行的防晒霜帖子”，然后一个我们用自有目录训练出来的检索模型直接把它映射到正确的端点。参数 schema 只在它实际选到那个工具时才加载。整个过程大约只消耗 1,500 个 token，而且不管我们加多少端点，这个开销都保持不变。2. 每个智能体都想以不同的方式集成。Claude Code、Codex、WorkBuddy、Openclaw……我们支持 20 多个，每个都有自己的怪癖。我们的答案是分层架构：一个轻量的 skill 运行在你的机器上，自动检测你拥有的智能体并保持更新；再加上一个我们云端的标准化 MCP 服务器，始终最新。你设置一次，之后就不用再管。新端点、修复、升级都落在服务器端，所以本地不需要跟着升级。3. 上游 API 不稳定。提供商会限流、性能下降，有时直接宕机。我们做基于 QoS 的流量整形和供应商之间的自动故障转移，所以当一个供应商挂掉时，请求会自动静默路由到健康的供应商。你的智能体拿到的是答案，而不是 503 错误。我今天都在，很乐意回答任何关于底层工作原理的问题。PH 用户自动故障转移是悄悄最棒的部分。上个月有个搜索供应商出问题，我的研究管道甚至都没察觉。PH 用户Hello PH 社区，我是 Luki，AgentKey 创始成员，负责产品合作。Mogu 和 Cong 已经讲了为什么和怎么做，我就从合作角度说说我的两分钱。我不断看到的最大阻碍是：没有人愿意为了启动一个功能花几周时间去折腾多个 API 的注册、key 和续费。几个例子：一个旅行 AI 团队想添加航班和酒店价格。这个想法在待办列表里躺了很久，因为没人愿意设置多个数据供应商。用了 AgentKey，他们立刻就能跑起来。一家金融科技创业公司需要实时加密货币和市场数据。他们一天内就用真实数据开始测试，而不是花几周注册不同供应商。一个游戏工作室正在构建 NPC 智能体，需要网页搜索和社交上下文。一次集成就给了他们所有，不用拼凑多个服务。这就是我最兴奋的 AgentKey 部分。我们帮助团队减少在账户设置和供应商切换上的时间，把更多时间用来构建他们真正想交付的产品。今天我会在评论区，如果 anyone 想聊合作、集成或者使用场景，欢迎来聊 :)PH 用户我一半的智能体演示都在直播时挂掉，因为某个上游API恰好在那时候宕机。故障转移本该是基本要求，但不知为何其他产品都没做。 热门产品Mogu2026-07-13原文 打开互动版
我们反复纠结的是这个问题：智能体做任务确实很在行了，但它们没有眼睛。它们能推理、能行动，但看不到真实的互联网——而几乎所有有用的工具和实时数据都在那里。于是出现了一个奇怪的缺口：一个足够聪明的智能体，却坐在一扇它看不到的窗户后面。
而今天，给智能体装上眼睛是一件麻烦事。你要接一个 API 做搜索、另一个做爬取、再一个做社交、又一个做市场数据。你得照看一大堆 key 和账单，基本上得先懂底层管道才能开始。大多数能用上它的人，在这一步就停下了。
所以我们建了 AgentKey。你像装插件一样安装它，你的智能体就能通过一个账户访问整个能力市场。不用折腾多个 API，不用管 key，也无需技术背景。一个账户、一张账单，你的智能体瞬间强大很多。
目前市场分为几个层级，而且还在不断增长：
- 日常工具：搜索、网页爬取、社交媒体
- 专业数据：金融、加密货币、商业数据
- 生活与旅行：天气、地图、行程规划等
它已经接入了 20 多个人们常用的智能体，包括 Claude、Codex、Openclaw、WorkBuddy 和 Cursor。而且因为所有东西都在一个市场背后，如果某个供应商出问题，你的智能体可以自动切换到另一个源继续运行。
我们深信智能体即将绽放成一个庞大、混乱、美妙的生态。最让我激动的是，人们终于可以把手头上真正复杂的工作交给智能体，而不只是基础任务，并且能信任它来完成。这也是我们在这里发布的主要原因。免费开始，不需要信用卡。请尽管来试，搞坏它，然后告诉我缺什么。我今天会在评论区待一整天。
但当检索模型对模糊请求选错了端点，这个错误能被看到吗？还是说选错了只是下游悄悄得到糟糕结果？
1. 工具发现
我们有大约 1,800 个 API 端点。如果把它们作为静态工具丢进 MCP，智能体光加载定义就要消耗大约 35,000 个 token 的上下文，而且有一半概率选错工具。所以我们构建了自己的意图识别层：智能体用自然语言描述它想要什么，比如“在 reddit 上找正在流行的防晒霜帖子”，然后一个我们用自有目录训练出来的检索模型直接把它映射到正确的端点。参数 schema 只在它实际选到那个工具时才加载。整个过程大约只消耗 1,500 个 token，而且不管我们加多少端点，这个开销都保持不变。
2. 每个智能体都想以不同的方式集成。
Claude Code、Codex、WorkBuddy、Openclaw……我们支持 20 多个，每个都有自己的怪癖。我们的答案是分层架构：一个轻量的 skill 运行在你的机器上，自动检测你拥有的智能体并保持更新；再加上一个我们云端的标准化 MCP 服务器，始终最新。你设置一次，之后就不用再管。新端点、修复、升级都落在服务器端，所以本地不需要跟着升级。
3. 上游 API 不稳定。
提供商会限流、性能下降，有时直接宕机。我们做基于 QoS 的流量整形和供应商之间的自动故障转移，所以当一个供应商挂掉时，请求会自动静默路由到健康的供应商。你的智能体拿到的是答案，而不是 503 错误。
我今天都在，很乐意回答任何关于底层工作原理的问题。
我不断看到的最大阻碍是：没有人愿意为了启动一个功能花几周时间去折腾多个 API 的注册、key 和续费。
几个例子：一个旅行 AI 团队想添加航班和酒店价格。这个想法在待办列表里躺了很久，因为没人愿意设置多个数据供应商。用了 AgentKey，他们立刻就能跑起来。一家金融科技创业公司需要实时加密货币和市场数据。他们一天内就用真实数据开始测试，而不是花几周注册不同供应商。一个游戏工作室正在构建 NPC 智能体，需要网页搜索和社交上下文。一次集成就给了他们所有，不用拼凑多个服务。这就是我最兴奋的 AgentKey 部分。我们帮助团队减少在账户设置和供应商切换上的时间，把更多时间用来构建他们真正想交付的产品。
今天我会在评论区，如果 anyone 想聊合作、集成或者使用场景，欢迎来聊 :)