Arcade 是什么？7500+ 预置工具的 Agent 工具调用平台，LLM 全程碰不到你的 token（基础篇）
搞 Agent 落地的朋友都知道，编排逻辑其实是最爽的部分，最脏最累的活全在工具调用这一层：接一个 GitHub 要做 OAuth 跳转，接一个 Slack 要管 token 刷新，密钥不敢塞进 prompt 又没地方安全放。Arcade.dev 就是专门干这件事的——把「授权式工具调用」做成一层独立基础设施。本期基础篇，把这个平台讲清楚。
Arcade.dev 是什么
一句话定位，用他们自己在 PyPI 上的原话：Tool Calling platform for Agents（给 Agent 用的工具调用平台）。它不做编排、不做 UI、不抢你现有框架的活，只解决一个问题：Agent 调用带鉴权的外部工具时，授权、凭证存储、token 刷新这一整套脏活。
平台分两部分：
- Arcade Cloud：托管服务，官方 README 里写明目前目录有 7500+ 预置工具，跑在 81 个 MCP 服务器上，覆盖 GitHub、Slack、Google、Notion、Linear、Figma、HubSpot 等 23 类内置 OAuth Provider。
- arcade-mcp：开源的 Python 框架，MIT 协议，GitHub 1049 星（2026-10-14 实测）。老玩家可能记得 arcade-ai 这个包名——它已经在 2.3.0 版本标记 DEPRECATED，官方整体改名成 arcade-mcp，最新版 1.16.2，2026-10-07 刚发过更新，迭代不算慢。
它最核心的机制叫 authorized tool calling。看 README 里的真实代码，一个能读用户 GitHub 仓库的工具，核心就一行声明：
from arcade_mcp_server import MCPApp, Context
from arcade_mcp_server.auth import GitHub
app = MCPApp(name="gh", version="1.0.0")
@app.tool(requires_auth=GitHub(scopes=["repo"]))
async def list_my_repos(context: Context) -> list[str]:
"""List the authenticated user's GitHub repositories."""
token = context.get_auth_token_or_empty()
...
流程是这样的：终端用户触发工具时，Arcade 给他一个 URL，浏览器里完成 OAuth 授权；token 由 Arcade 加密托管、按调用注入、过期自动刷新。LLM 只需要看到「工具叫什么、能干什么」的描述，永远拿不到 token 本体。 这解决了一个很实际的安全问题：以前要么把长期 token 塞给模型上下文（泄露风险），要么自己写一整套授权回调和存储（累死人）。
上手
本地开发门槛很低，README 的 Quick Start 就三步：
# 1. 装 CLI（官方推荐 uv）
uv tool install arcade-mcp
# 2. 脚手架起一个 MCP 服务器
arcade new my_server
# 3. 写工具、部署
arcade deploy # 一键托管到 Arcade Cloud
接你现有的 Agent 框架不用改架构——Arcade 走 MCP 协议，官方明确说 vendor-neutral：LangChain、Mastra、Pydantic AI、CrewAI、Google ADK、OpenAI Agents SDK 都能直接接。框架这边挂一个 MCP client 指向 Arcade 的服务器就完事，跟接任何 MCP server 的姿势一样。工具写完了还有 arcade evals 可以对着真实 LLM 测工具调用的准确率，这个对做生产 Agent 的人挺实用。
自建工具的场景也有覆盖：内部 API、自定义 OAuth provider，用框架的装饰器写好，requires_auth 里声明需要的 scopes，OAuth2(...) 通用类兜底一切非标 OAuth API。
实话
先说星数。arcade-mcp 一千出头的星，跟站里写过的 Composio、n8n 这些比不算多，生态还在爬坡期，别指望社区有海量现成轮子。它的护城河不在 GitHub，在云上那 7500+ 预置工具和 23 类 OAuth 封装——这是实打实的目录苦功夫，自己写一套 GitHub + Google + Slack 的完整 OAuth 流程你就知道有多枯燥。
再说架构上的取舍。凭证托管在 Arcade Cloud 上，这是它的产品形态，也是它的信任边界。 对多数 SaaS 场景这没问题（省得自己存 token），但涉密或合规敏感的场景，要先想清楚再把 OAuth token 交给第三方托管。自托管能拿走 MCP 服务器和工具代码，token 托管这层的边界在哪，接之前务必看清楚。
最后是时机判断。MCP 已经是 Agent 工具调用的事实标准，Arcade 站在这条协议上做增值层，方向没毛病。适合的画像很明确：你想让 Agent 操作一堆 SaaS，又不想在 OAuth 上耗一个月。如果你的工具全是自己内部 API，那直接写 MCP server 就够了，不需要它。想横向对比同类，可以翻翻站内之前写的 Composio 基础篇 和 MCP 服务器入门，三家的路线差异一目了然。
