账务服务助手

解决什么问题

Bench 相关操作往往依赖固定的工具调用方式，但实际情况中，工具的输入参数、字段命名和执行流程都可能随版本变化。如果直接在代码里写死工具 slug 或参数结构，一旦上游更新，整条工作流就可能静默失败——错误信息不明确，排查成本高。

这个技能要解决的正是这类问题：把「发现可用工具」和「执行具体操作」拆成两个阶段，在运行时先查询当前可用的工具 schema，再按实际返回的字段构造调用参数。

核心工作方式

技能通过 Rube MCP 接入 Composio 的 Bench 工具包，整体流程分为三步：

1. 发现工具：调用 RUBE_SEARCH_TOOLS 获取当前可用的工具列表、输入 schema、推荐的执行计划以及已知的坑。这一步必须先执行，后续所有调用都依赖它的返回结果。
2. 检查连接：通过 RUBE_MANAGE_CONNECTIONS 确认 Bench 工具包的连接状态为 ACTIVE。如果尚未连接，按返回的认证链接完成授权。
3. 执行操作：使用 RUBE_MULTI_EXECUTE_TOOL 按发现的 slug 执行工具，批量场景可用 RUBE_REMOTE_WORKBENCH 调用 run_composio_tool()。

Rube MCP 的接入方式比较简单：在客户端 MCP 配置里添加 https://rube.app/mcp 端点即可，不需要额外的 API key。

适用边界与注意点

几个实践中容易踩的点：

• 不要硬编码 schema：工具的字段名和类型以 RUBE_SEARCH_TOOLS 的最新返回为准，直接照搬历史调用记录可能因为字段变更而报错。
• 每次执行前确认连接状态：尤其当工作流长时间运行或跨会话恢复时，连接可能已失效。
• memory 参数必须显式传递：即使不需要上下文，也要传 {}，不能省略。
• 会话复用要区分场景：同一工作流内复用 session ID，新工作流则必须生成新的，混用会导致状态错乱。
• 注意分页：返回结果中可能包含分页 token，需要持续请求直到取完，否则数据不完整。

本质上，这个技能适合需要动态适配工具 schema 的 Bench 自动化场景，而不适合那些工具接口已经非常稳定、且你愿意长期维护固定调用代码的场景。