技能介绍

它解决什么问题

把 WhatsApp Business 接入自动化时，绕不开的几件事是：保管 WABA 的访问令牌、处理凭证过期、上传媒体后拿到 Media ID 再回填到消息里，以及为外发消息准备需要审批的模板。让 Agent 自己去拼这套流程，脚本重复，而且令牌一旦散落在客户端就很难回收。

oo-whatsapp 的做法是把这些细节收进一个连接器：客户端只构造 JSON payload 并执行，凭证由 OOMOL 在服务端注入，本地不需要接触裸 token。

它的工作方式

连接器暴露 17 个动作，大致可以分成四组：

消息发送：send_message、send_media、send_media_by_id、send_location、send_contacts、send_interactive_buttons、send_interactive_list、send_template_message
媒体处理：upload_media 上传后返回 media record，get_media_info 取元数据和短时下载链接
模板管理：create_message_template、delete_message_template、get_message_templates、get_template_status
账号与号码：get_business_profile、get_phone_number、get_phone_numbers

执行姿势很统一：先读动作的参考文件了解用途，再用 oo connector schema 拉一次实时 schema 作为权威输入，然后拼 --data（可以是 JSON 字符串或 @path/to/file.json，省略即发送 {}）。响应固定为 {"data": ..., "meta": {"executionId": "..."}}，执行 id 在 meta.executionId 下。

安全边界也写在了文档里：get / list 类只读动作可以直接跑；send / create 会改变 WhatsApp 侧状态，要先和用户确认 payload 与实际效果；delete 是破坏性的，必须先确认目标并拿到明确批准。

适用边界

从动作列表看，这 17 个动作全部是出站发送和资源管理，入站消息回调不在列表内，需要自己搭 Webhook 来消费进来的消息。

模板消息依赖 Meta 侧审批：send_template_message 只能发送已通过审核的模板，create_message_template 建好不等于能用。交互式按钮和列表消息适合做导航类回复，复杂的多轮对话逻辑仍要由调用方编排。

首次配置是一次性步骤，不要每次调用都重跑。只在命令真的报错时才处理对应问题：找不到 oo 命令就装 CLI，未登录就签一次 OOMOL 账号，scope_missing / credential_expired / app_not_ready / app_not_found 说明 WhatsApp 连接缺失或过期，用 API key 方式重新连一次即可。