企业官网建设流程全解析

Deepgram 语音服务自动化 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

在 awesome-codex-skills 仓库中，deepgram-automation 是一份教 Codex 通过 Rube MCP 网关操作 Deepgram 语音服务（语音转写、说话人分离等 Deepgram API 能力）的 Agent 技能说明。本文完整拆解该技能的元数据触发机制、MCP 端点接入方式、"先搜索后执行"的三步工作流，以及 6 条已知陷阱的成因，读完后可自行将同类 composio-skills 技能接入自己的 Codex 环境并验证运行。

技能定位与前置条件

技能文件位于 composio-skills/deepgram-automation/SKILL.md，是一个只含单个 SKILL.md 的最小技能目录。其 YAML frontmatter（SKILL.md 第 1–6 行）定义如下：

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

三个字段的作用分别是：

• name：技能标识，安装后对应$CODEX_HOME/skills/deepgram-automation目录名；
• description：Codex 依据该描述判断何时触发技能。仓库 README 在 "What Are Codex Skills?" 一节中说明：Codex 先读取元数据决定是否触发，触发后才加载正文，从而保持上下文精简。因此这份 description 同时强调了两点——用途（Deepgram 任务自动化）与行为约束（先搜工具再执行）；
• requires.mcp: [rube]：声明该技能依赖名为rube的 MCP 服务器，即 Rube MCP（Composio 的 MCP 网关端点）。若客户端未配置该端点，技能内的所有工具调用都无从谈起。

原文档列出的三项前置条件（SKILL.md 第 14–18 行）：

1. Rube MCP 已连接，即RUBE_SEARCH_TOOLS工具可用；
2. 已通过RUBE_MANAGE_CONNECTIONS建立 toolkit 为deepgram的活跃连接（ACTIVE 状态）；
3. 任何工作流执行前，先调用RUBE_SEARCH_TOOLS获取当前工具 schema。

第 3 条是整个技能最重要的设计约束：Deepgram 侧的工具列表、字段名和参数结构可能随上游版本变化，因此技能禁止 Agent 凭记忆硬编码工具 slug 或参数，一切以搜索结果的实时返回为准。

接入 Rube MCP

原文档 Setup 一节（SKILL.md 第 20–27 行）给出的接入方式是把 Rube MCP 的远程端点https://rube.app/mcp添加进 MCP 客户端配置。由于鉴权交由网关侧处理，客户端不需要配置 API Key，添加端点即可工作。接入后的验证步骤：

1. 确认RUBE_SEARCH_TOOLS有响应，证明 Rube MCP 可用；
2. 调用RUBE_MANAGE_CONNECTIONS并指定 toolkitdeepgram；
3. 若连接状态不是 ACTIVE，按返回的授权链接（auth link）完成 Deepgram 侧的授权；
4. 在运行任何工作流之前，确认连接状态显示为 ACTIVE。

需要注意适用前提：连接状态是"按 toolkit 维度"管理的，同一 Rube MCP 端点下可以为deepgram、composio_search等不同 toolkit 分别建立连接，某个 toolkit 的 ACTIVE 状态不自动覆盖其他 toolkit。

工具发现：RUBE_SEARCH_TOOLS

原文档 Tool Discovery 一节（SKILL.md 第 29–39 行）给出了标准调用形态：

RUBE_SEARCH_TOOLS queries: [{use_case: "Deepgram operations", known_fields: ""}] session: {generate_id: true}

调用约定有两点：

• queries是数组，use_case用自然语言描述目标操作（此处为 "Deepgram operations"），known_fields可选，用于提示已知字段名；
• session传{generate_id: true}时由服务端生成新的 session id，后续同一条工作流的调用应复用该 id。

搜索的返回内容包括：可用工具的 slug、各工具的输入 schema、推荐的执行计划（recommended execution plans）以及已知陷阱（known pitfalls）。也就是说，"这个 Deepgram 任务该调哪些工具、参数怎么填、有哪些坑"这四类信息在搜索这一步一次性拿到，后文的三步工作流全部建立在它之上。

核心三步工作流

这是原文档的主体（SKILL.md 第 41–69 行），完整保留如下。

第一步：发现可用工具

RUBE_SEARCH_TOOLS queries: [{use_case: "your specific Deepgram task"}] session: {id: "existing_session_id"}

与工具发现一节的差别在于use_case写的是具体任务（例如"把会议录音转写并做说话人分离"），并且session复用已有 session id 而不是生成新 id，使发现与后续执行共享上下文。

第二步：检查连接状态

RUBE_MANAGE_CONNECTIONS toolkits: ["deepgram"] session_id: "your_session_id"

注意参数是toolkits数组：一次可以检查多个 toolkit 的连接状态，Deepgram 场景下只传["deepgram"]即可。只有确认状态为 ACTIVE 才进入第三步，否则先回到 Setup 阶段的授权流程。

第三步：执行工具

RUBE_MULTI_EXECUTE_TOOL tools: [{ tool_slug: "TOOL_SLUG_FROM_SEARCH", arguments: {/* schema-compliant args from search results */} }] memory: {} session_id: "your_session_id"

其中tools是数组结构，意味着一次调用可以编排多个工具依次执行，tool_slug必须来自第一步搜索结果的原文，arguments必须严格符合搜索返回的 schema。memory与session_id为必填字段，即使没有记忆内容也要传空对象{}——这一点在已知陷阱一节中被再次强调。

快速参考表与 Rube 工具族

原文档 Quick Reference 一节（SKILL.md 第 80–88 行）汇总了五种操作的入口：

表中有两项值得展开：

• 批量操作走RUBE_REMOTE_WORKBENCH，其中run_composio_tool()是面向脚本化批量场景的执行入口。从文档结构看，它与RUBE_MULTI_EXECUTE_TOOL的区别在于使用场景：前者适合 Agent 会话内按需编排，后者适合在远端工作台里循环执行大批量工具调用；
• 完整 schema走RUBE_GET_TOOL_SCHEMAS。部分工具在搜索结果中只返回schemaRef引用而非内联完整 schema，此时必须再用该工具拉取全量定义，才能保证arguments的字段名与类型完全合规。

已知陷阱逐条解析

原文档 Known Pitfalls 一节（SKILL.md 第 71–78 行）列出 6 条，逐条说明其背后原因：

1. 先搜索再执行：工具 schema 会变更，未经RUBE_SEARCH_TOOLS确认的 slug 或参数结构可能已经失效，硬编码是这类技能最常见的失败来源；
2. 先查连接：执行前必须用RUBE_MANAGE_CONNECTIONS确认 ACTIVE，连接未授权或已过期时所有工具调用都会失败；
3. schema 严格合规：字段名和类型必须原样取自搜索结果，包括大小写，自创同名字段会被网关拒绝；
4. memory 参数必填：RUBE_MULTI_EXECUTE_TOOL即使无记忆也要显式传memory: {}，省略该字段不符合调用契约；
5. 会话复用规则：同一条工作流内的调用复用同一个 session id，只有开启新工作流时才生成新 id。session 承载发现→执行链路上的上下文，中途换新 id 会丢失已发现的工具信息；
6. 分页处理：列表类响应可能带分页 token，必须检查并持续拉取直到完整，否则后续对"全量结果"的判断（如"所有录音任务"）都会遗漏数据。

仓库中的同类技能模板与配套路径

从源码结构看，composio-skills/ 目录下收录了数百个结构几乎完全一致的自动化技能。以 composio-automation/SKILL.md 和 composio-search-automation/SKILL.md 对照 deepgram-automation/SKILL.md 可以发现：三者的 frontmatter、Setup、三步工作流、陷阱清单与快速参考表逐段相同，差异只在 toolkit 标识（deepgram/composio/composio_search）与 use_case 描述文本。这说明 deepgram-automation 遵循的是 composio-skills 统一的"Rube MCP 网关 + 搜索驱动"模板——把 toolkit 名替换成目标服务，即得到对应服务的自动化技能。这一观察也解释了为何陷阱清单强调"先搜索"：模板本身不内置任何具体工具名，全部运行时动态发现。

仓库内另有两条与 Deepgram 技能互补的路径，可作为交叉参考：

• connect/SKILL.md 提供基于 Composio CLI 的 shell 路线：通过命令行登录并在终端直连 1000+ 服务，适合不需要 MCP 客户端的场景；而 deepgram-automation 走的是 Rube MCP 端点路线，两者面向不同的集成方式；
• skill-installer/ 提供安装脚本。README 的 Quickstart 给出了安装单个技能的命令形态：

python skill-installer/scripts/install-skill-from-github.py --repo ComposioHQ/awesome-codex-skills --path deepgram-automation

安装后技能落到$CODEX_HOME/skills/deepgram-automation（默认~/.codex/skills），随后需重启 Codex 才会加载新技能的元数据。验证方式按 README "Using Skills in Codex" 一节：ls ~/.codex/skills列出已装技能，head ~/.codex/skills/deepgram-automation/SKILL.md检查 frontmatter 是否完整。

适用前提与限制

• 该技能是纯指令型技能，目录内没有脚本、测试或配置文件，全部"实现"依赖运行时对 Rube MCP 端点的工具调用，因此本地无法用仓库内文件直接验证其正确性，验证只能发生在真实 MCP 会话中；
• 运行前提包括：MCP 客户端支持远程端点并已完成 Rube 端点接入、Deepgram toolkit 连接处于 ACTIVE 状态、use_case描述足够具体以命中正确工具；
• 技能正文不声明任何具体 Deepgram 工具名、API 版本或参数示例，这是刻意的防漂移设计，但也意味着读者不能从技能文件本身查到 Deepgram 工具的字段级细节，这些必须以RUBE_SEARCH_TOOLS的实时返回为准。

【免费下载链接】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