移动表单助手

解决什么问题

把表单类任务交给 LLM 处理时，最麻烦的不是"模型不会写提示词"，而是模型根本没有执行入口：没人替它点击、填表、提交。Tapform 的操作要么靠人工在网页里手动点，要么得先写一套定制脚本。结果是自动化流程卡在最后一环，前面的推理都白做。

@org-02qudk26/tapform-automation 的思路是把执行层外包出去：通过 Rube MCP 接上 Composio 的 Tapform 工具包，让模型负责"决定做什么"，让外部工具负责"真的去做"。

它是如何工作的

核心依赖三个 MCP 工具，配合一套固定的工作流：

1. 先发现工具：任何操作前都必须先调用 RUBE_SEARCH_TOOLS，拿到当前可用的工具 slug、入参 schema、推荐执行计划和已知坑点。
2. 再确认连接：用 RUBE_MANAGE_CONNECTIONS（参数 toolkit tapform）检查连接状态；未激活就按返回的授权链接完成授权，确认状态变为 ACTIVE 再往下走。
3. 最后执行：用 RUBE_MULTI_EXECUTE_TOOL 按发现到的 slug 逐个执行；批量操作可以走 RUBE_REMOTE_WORKBENCH 里的 run_composio_tool()。

底层工具包的文档在 composio.dev/toolkits/tapform，本技能本身不含业务逻辑，只是把这条链路固化成可复用的流程。

适用边界与注意点

这套流程有几个容易踩的坑：

• 不要硬编码工具名和参数。schema 会随上游更新变化，一切以 RUBE_SEARCH_TOOLS 返回为准。
• 执行前务必确认 ACTIVE，连接掉线时工具调用会直接失败。
• memory 参数必须传，即使是空对象 {}，否则会报错。
• 会话要复用：同一流程内重复用同一个 session ID，新流程再生成新的，否则容易串数据。
• 注意分页：返回里有分页 token 就要继续拉，别默认一次拿全。

另外，它只解决"如何执行"这一层，不包含表单业务规则的设计。适合已经明确要做什么、缺的只是执行通道的场景。