--- title: UXC 已经有了最全的 Crypto 和 OnChain Skill 集合 date: '2026-03-19 16:06:29' draft: false summary: 关键不只是 skill 数量多，而是 UXC 已经把交易所执行、实时订阅、链上研究、SQL/Graph 分析、DeFi 路由、节点直连和 gas 判断这些能力面收成了一层连续的执行面。 slug: uxc-most-complete-crypto-onchain-skills syndication: - platform: X / Twitter url: https://x.com/jolestar/article/2034662806444966089 tags: - uxc - crypto - onchain topics: - ai - blockchain type: post --- 如果只看 Crypto / OnChain Agent 这条线，UXC 已经不是“也有一些 skill”了，而是已经把这条线最核心的几块主战场都铺开了。说它最全，我觉得并不夸张。 这里说的“最全”，不是指某一个协议、某一个交易所、某一个数据源挖得最深，而是指对 agent 真正有用的几类能力面，已经被同时铺开了：交易所执行、实时订阅、链上研究、SQL / Graph 分析、DeFi 路由、节点直连、Gas 与执行前判断。 更关键的是，这些 skill 不是技巧型 skill，而是基础工具服务型 skill。每个 skill 后面都对应一个真实服务，UXC 给 agent 的是同一套稳定的 `discover / authenticate / call / subscribe` 界面，把 OpenAPI、GraphQL、MCP、JSON-RPC、WebSocket 这些不同入口，收成一层连续的执行面。 直接落到能力上，就是： - 看多家交易所市场、账户、订单 - 持续盯实时行情和盘口 - 订阅链上 transfer、mempool、DEX trades - 查 token、钱包、地址、合约、持仓、transfer - 做 SQL / subgraph / analytics 研究 - 做价格、market cap、narrative、token discovery 扫描 - 做 route / quote / bridge / yield / TVL 分析 - 直接连链节点和 JSON-RPC - 看 gas intelligence、Bitcoin mempool、Lightning、Solana wallet intelligence 这些事情，现在都已经可以在同一套 UXC 调用面里开始做了。 所以这篇并不只是列一个“看起来很多”的工具单子，也不是在凑热闹式地贴 provider 名单。它真正想说明的是：Crypto / OnChain 这堆原本最碎、最难统一、最依赖具体 provider 语义的执行面，已经开始被 UXC 收成一层可以被 agent 直接消费的基础设施。 ## 1. 交易所执行面：从 public market 到 signed account / order 如果你的问题本质上还是“交易所 API”，那最先看的就是这组。 这组早就不只是“顺手查个价格”了，它其实是在把交易所 execution surface 整块搬进来。public market read 当然重要，但更关键的是 signed account / order / test order / place / cancel 这些原来最容易碎、最容易各说各话的部分，现在也开始进入统一接口。 交易所 REST / 账户 / 订单： - `binance-spot-openapi-skill` - `coinbase-openapi-skill` - `bybit-openapi-skill` - `kraken-openapi-skill` - `kucoin-openapi-skill` - `bitget-openapi-skill` - `mexc-openapi-skill` - `upbit-openapi-skill` 公开市场数据补齐： - `crypto-com-mcp-skill` - `gate-mcp-skill` 这组适合的任务包括： - 查 ticker、depth、orderbook、market snapshot - 查账户、订单、订单状态 - 跑 testnet 交易流程 - 做多交易所市场对比 - 让 agent 拥有可执行的交易所入口，而不是只会读价格 ## 2. 实时订阅线：不是查一次，而是持续接收事件 这条线是 `uxc subscribe` 变得真正有用的地方。它已经不只是抽象能力，而是有真实 skill 承接的。 到今天为止，很多所谓的 agent 本质上还停留在“问一下”。能查，不能盯；能答，不能守；能回一轮，不能持续接事件。实时订阅这条线补起来以后，agent 才开始真的从一次性问答工具，往 watcher、alert、monitor 这种持续运行的角色上走。 交易所和市场实时流： - `binance-spot-websocket-skill` - `okx-exchange-websocket-skill` 链上实时订阅： - `bitquery-graphql-skill` 这组适合： - 持续盯某个交易对或盘口 - 持续盯链上 transfer / mempool / DEX events - 做 watcher、alert、实时监控 - 把 agent 从“问一下”推进到“持续监听” ## 3. 链上数据与地址研究：钱包、token、合约、transfer 这组 skill 更适合回答“这个地址 / 钱包 / token / 合约到底发生了什么”。 这一层真正的价值，是把链上调查工作系统化了。过去这类任务常常要人在 explorer、data API、wallet intelligence 工具之间来回跳页面、拼结果、自己兜语义，现在 agent 已经可以在一套更连续的工具面里把地址、资产、合约、transfer、holder、history 这些问题串起来。 通用 Web3 数据 API： - `alchemy-openapi-skill` - `chainbase-openapi-skill` - `moralis-openapi-skill` - `nodit-openapi-skill` - `helius-openapi-skill` - `binance-web3-openapi-skill` 浏览器 / Explorer 语义： - `blockscout-openapi-skill` - `etherscan-mcp-skill` - `mempool-space-openapi-skill` 聚合型钱包 / 市场工作流： - `goldrush-mcp-skill` - `okx-mcp-skill` ## 4. SQL / Graph / Analytics / Narrative：更适合研究，而不是单点查询 这组 skill 更适合“研究”和“分析工作台”场景。 这组不是查完即走的小工具，它是在给 agent 搭一张真正的研究台面。也就是说，agent 不只是能把某个 token 价格报出来，还开始能沿着 SQL、subgraph、GraphQL、narrative、discovery 这几条线，把“找问题、追问题、验证问题”的过程接起来。 SQL / Analytics： - `dune-mcp-skill` Graph / Subgraph / Token Graph： - `thegraph-mcp-skill` - `thegraph-token-mcp-skill` - `bitquery-graphql-skill` 市场研究 / Narrative / Discovery： - `coinmarketcap-mcp-skill` - `coingecko-openapi-skill` - `coinapi-openapi-skill` - `birdeye-mcp-skill` - `dexscreener-openapi-skill` - `hive-mcp-skill` ## 5. DeFi、跨链、收益率、Gas、节点：真正进入基础设施层 这一组已经不只是“数据站 API”，而是比较接近链基础设施本体。 到了这里，UXC 碰到的已经不是边角料，而是 crypto infra 最硬的那层。重点也不再是“能不能多看几类数据”，而是 agent 是否真正碰到 execution planning 和底层节点语义。JSON-RPC、跨链 route、TVL / yields、gas intelligence 这些东西一旦进入统一调用面，agent 处理链上任务的方式就会明显不同。 JSON-RPC / 节点直连： - `ethereum-jsonrpc-skill` - `sui-jsonrpc-skill` - `near-jsonrpc-skill` 跨链 / 路由 / DeFi 执行规划： - `lifi-mcp-skill` 收益率 / TVL / 价格 / 协议数据： - `defillama-openapi-skill` - `defillama-prices-openapi-skill` - `defillama-pro-openapi-skill` - `defillama-yields-openapi-skill` Gas / 执行前环境判断： - `blocknative-openapi-skill` ## 6. 这批 skill 真正说明了什么 如果只看表面，很容易把这件事低估成： - 又多接了很多 OpenAPI - 又接了一些 MCP - 又补了 WebSocket、GraphQL、JSON-RPC 但更关键的变化其实是：真正被验证的，已经不只是某几个 skill，而是 UXC 这层抽象本身。 UXC 正在把 crypto / Web3 这堆原本非常碎的执行面，慢慢收成一个更稳定的 agent interface。 原来 agent 每次都要重新面对这些差异： - 有的要签名 - 有的要 OAuth - 有的要 app credentials 换 token - 有的走 GraphQL - 有的走 JSON-RPC - 有的走原始 WebSocket - 有的走 MCP 而 skill 层和 UXC 的组合，开始把这些差异压成： - 一个更稳定的命令入口 - 一个更稳定的 auth / setup 流程 - 一个更统一的 help / discovery 方式 - 一个可以复用到 subscribe 的事件面 所以现在这批 crypto / onchain skill 的价值，早就超过了“支持更多 provider”这层意思。当 OpenAPI、GraphQL、JSON-RPC、WebSocket、MCP 这些完全不同的入口，都能被压进同一套 `discover / authenticate / call / subscribe` 界面里时，它们真正说明的，其实是 agent 终于开始有了一层足够稳定、也足够可组合的通用执行面。 换句话说，UXC 现在验证的已经不只是一个 skill catalog，而是一种可以稳定复制的 skill 生产方式。 ## 7. 以后见到新接口，先扔给 Agent 更直接的办法，是把这篇列表连同你的任务一起扔给 Agent。无论是 OpenClaw、Codex，还是 Claude Code，都可以直接问它： - 这些 skill 里哪些适合做我的任务 - 哪几个 skill 应该组合起来 - 如果我要进一步封成更高一级的 skill，该怎么抽 另外，以后你再碰到任何新的 API、MCP，甚至某个垂直领域自己的工具协议，默认思路都不需要从零开始。更直接的办法，就是把接口文档、认证方式、调用样例扔给 agent，让它按 UXC 的约束先产出一套 skill，再往上继续组合 workflow。 如果你是想把一个新 provider 更系统地封成 skill，`uxc-skill-creator` 本身也已经把这套套路沉淀出来了。 这才是这篇文章真正想卖的瓜：不只是 UXC 今天已经很全，而是它已经证明了一种可以继续复制、继续扩张的能力生产方式。 到这个阶段，UXC 在 Crypto / OnChain 方向上已经不只是“能接很多工具”，而是开始像一层通用执行底座。这个差别很大。前者只是让 agent 看起来懂很多，后者才是真的让 agent 进场干活。 仓库地址：[holon-run/uxc](https://github.com/holon-run/uxc)