3 步跑通 Amazon 自动化：Codex 接入 Rube MCP 实战指南-开发者社区

3 步跑通 Amazon 自动化：Codex 接入 Rube MCP 实战指南

【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills

你让 AI 查一下亚马逊上最便宜的机械键盘，它回你一段 Markdown 表格——然后呢？它没法替你下单，也没法替你盯订单状态。awesome-codex-skills 仓库里的 amazon-automation skill 解决的就是这件事：让 Codex Agent 经 Rube MCP 接入 Composio 的 Amazon 工具集，把查商品、看订单这类动作真正执行掉。这篇按「先跑通一次，再拆完整工作流」的顺序写，从零到第一次真实 API 调用，全程可复制。

读懂触发机制：Rube MCP 才是「前台总机」

仓库里每个 skill 都是一个独立文件夹，核心是一份带 YAML frontmatter（文件头部元数据块）的 SKILL.md。Codex 只读 frontmatter 里的name和description判断何时触发，命中后才加载正文，所以上下文一直保持精简。amazon-automation 的元数据长这样：

--- name: amazon-automation description: "Automate Amazon tasks via Rube MCP (Composio). Always search tools first for current schemas." requires: mcp: [rube] ---

description是触发依据，请求里沾上 Amazon 自动化就会命中它；requires.mcp: [rube]声明了这个 skill 依赖一个叫rube的 MCP 服务器（MCP 是让外部工具接入 AI 客户端的协议，可理解为给 Agent 插外设的接口），环境里没接好它，skill 就是空转。

分工上，Rube MCP（端点https://rube.app/mcp）是统一入口，像前台总机：提供全部RUBE_*工具，负责路由和鉴权；Composio 的 Amazon toolkit 才是业务方，封装了亚马逊的商品与订单 API。连接建好后 Agent 不碰 OAuth（第三方授权流程）细节，AMAZON_*工具直接可调度。仓库里 800 多个 composio-skills 目录共用同一套骨架，composio-automation等姊妹 skill 只是把 toolkit 换个名字，说明这套「Rube MCP 自动化」模式是通用的。

关键纪律只有一条：先搜索工具，再谈执行。每个 toolkit 的 schema（参数结构定义）都会随上游 API 演进，搜索结果相当于当季菜单——工具 slug（工具唯一短名）、输入 schema、推荐执行计划、已知坑点全在里面，是唯一权威来源。硬编码 slug 和参数名是这类自动化失败率最高的原因。

最小可行路径：装好 skill，接上端点，验证一次

📦 先把 skill 装进本地 Codex。克隆仓库后跑安装脚本，期望它把 amazon-automation 复制到$CODEX_HOME/skills/（默认~/.codex/skills）：

git clone https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills cd awesome-codex-skills python skill-installer/scripts/install-skill-from-github.py --repo ComposioHQ/awesome-codex-skills --path composio-skills/amazon-automation

安装脚本的行为：目标目录已存在会中止以防覆盖；默认走 zip 下载，失败（401/403/404）时自动回退 git sparse checkout；--name可自定义安装后的目录名。装完重启 Codex加载新元数据，用ls ~/.codex/skills和head ~/.codex/skills/amazon-automation/SKILL.md确认在位。

然后在客户端 MCP 配置里加上端点https://rube.app/mcp，不需要任何 API Key，加完即用。最后在新会话里调一次RUBE_SEARCH_TOOLS，有响应就算链路通了，Amazon 连接留到下一步处理。

一次调用跑通商品搜索：发现、确认、执行三段式

标准模式就三段，全部可复制。第一段是工具发现：use_case写具体任务，known_fields填已知字段名（可留空），generate_id: true生成会话 ID，期望返回工具 slug 列表、每个工具的输入 schema、推荐执行计划和已知坑点四类信息：

RUBE_SEARCH_TOOLS queries: [{use_case: "search Amazon products", known_fields: "keywords"}] session: {generate_id: true}

第二段查连接状态，确认 Amazon toolkit 处于 ACTIVE 再往下走，避免执行时才发现连接失效、白白浪费调用：

RUBE_MANAGE_CONNECTIONS toolkits: ["amazon"] session_id: "上一步返回的会话 ID"

第三段才真正执行。tool_slug必须来自第一段的结果，arguments严格照搜索返回的 schema 填：

RUBE_MULTI_EXECUTE_TOOL tools: [{ tool_slug: "AMAZON_<搜索返回的 slug>", arguments: { "keywords": "wireless keyboard", "limit": 10 } }] memory: {} session_id: "同一会话 ID"

⚠️ 两个高频翻车点：arguments的字段名和类型必须与 schema 一字不差，多一个少一个都可能直接失败；memory参数必带，哪怕内容是空的{}。同一工作流内继续追问时复用同一会话 ID，上下文是连续的；开新任务才生成新会话。

连接状态不是 ACTIVE 时怎么排查

RUBE_MANAGE_CONNECTIONS返回的不是 ACTIVE 时，按顺序处理：

看返回里有没有授权链接——第一次接入没有属正常，点开按提示完成 OAuth 授权即可；
授权完成后回查一次，状态应变为 ACTIVE。⚠️ 别跳过这步直接执行，连接失效时的报错通常很隐蔽，排查成本远高于提前确认；
连接是一次性成本：OAuth 完成后会持久化，之后的会话直接复用，不必每次重连。

如果状态在 ACTIVE 和其他值之间反复横跳，优先怀疑授权过期，重走一遍授权链接；仍不行再检查 toolkit 名是否严格写成amazon（区分大小写）。

进阶与边界：批量执行、完整 schema 与分页

单条执行之外，Rube 还有两个进阶工具，按场景选：

场景	工具	说明
单次或少量执行	`RUBE_MULTI_EXECUTE_TOOL`	`tools`数组可放多个工具，一次完成多步操作
批量脚本化	`RUBE_REMOTE_WORKBENCH`	配合`run_composio_tool()`跑批量任务
schema 带`schemaRef`引用时	`RUBE_GET_TOOL_SCHEMAS`	拉完整 schema，避免截断信息导致参数误用