1688 询盘

向1688供应商发起询盘，20分钟后自动查询结果并回复。

前置配置（必须先完成）

⚠️ 使用本 SKILL 前，必须先配置以下环境变量，否则询盘接口调用会失败。

⚠️ AlphaShop 接口欠费处理： 如果调用 AlphaShop 接口时返回欠费/余额不足相关的错误，必须立即中断当前流程，提示用户前往 https://www.alphashop.cn/seller-center/home/api-list 购买积分后再继续操作。

配置方式

在 OpenClaw config 中配置：
CODEBLOCK0

如果用户没有提供这些密钥，必须先询问用户获取后再继续操作。

核心机制：询盘任务提交后，API 端最多执行 20 分钟，到时间后任务一定结束。通过 cron 在 20 分钟后查询结果并写入文件，用户下次发消息时 agent 检查文件并回复。

工作流程

CODEBLOCK1

Step 1: 提取信息

从用户消息中提取：

• - 商品链接或ID（必须）
• 询盘问题：自由文本（必须）
• 期望订购量（可选）
• 地址（可选）

如果用户没提供商品链接，必须询问。

Step 2: 提交询盘

CODEBLOCK2

从响应中提取 result.data 作为 taskId。提交成功后告知用户：

询盘已发送给供应商，20分钟后给你结果 ✅

Step 3: 写入追踪文件 + 创建 cron 查询任务

3a: 写入追踪文件

将待查询的任务信息追加到追踪文件：

CODEBLOCK3

3b: 创建 cron 查询任务（钉钉主动推送）

⚠️ 时间计算必须用 date 命令，禁止手算！

CODEBLOCK4

然后创建 cron 任务。核心：查询结果后通过 message 工具直接推送到钉钉：

CODEBLOCK5

关键参数：

• - sessionTarget: isolated（独立 session 执行，不抢主 session 锁）
• payload.kind: agentTurn（独立 agent turn）
• delivery.mode: none（不走 announce，由任务自己用 message 工具推送钉钉）
• 钉钉 target: 238382（流畅的钉钉 peer ID）

Step 4: 结果投递（钉钉主动推送）

cron 任务查到结果后，直接通过 message action=send channel=dingtalk target=238382 推送到流畅的钉钉私聊。用户在钉钉即时收到通知 ✅

兜底机制

回复格式参考：

📋 询盘结果

商品: {taskInfo.title 或商品名称}（¥{价格}）
供应商: {sellerInfo.companyName}
状态: ✅/❌ {taskInfo.status}

AI 总结

脚本命令参考

注意事项

• - questionList 固定填 ["自定义"]，用户实际问题放入 INLINECODE16
• INLINECODE17 设为 true，原文发送
• 不要轮询！ submit 后创建 cron，20 分钟后 query 一次就够
• cron 用 sessionTarget: isolated + payload.kind: agentTurn，在独立 session 里查询结果
• delivery.mode 必须是 none（由任务自己用 message 工具推送钉钉）
• 时间计算必须用 INLINECODE22
• 如果用户中途问"结果出来了吗"，可以提前 query 一次看看
• 钉钉推送目标: target=238382（流畅的钉钉 peer ID）
• ⚠️ 不要用 systemEvent + main session！（教训 #13）
• ⚠️ 不要用 sessions_send 推送结果！（教训 #15）

兜底机制：心跳检查未完成询盘

追踪文件：/home/admin/.openclaw/workspace/skills/inquiry-1688/pending_inquiries.json（JSON Lines 格式）

心跳检查流程（已加入 HEARTBEAT.md）：

CODEBLOCK6

教训记录

2026-03-05 ~ 03-06 连续踩坑：

1. 1. ❌ cron isolated + announce：delivery 配置问题 + announce 不送达
2. ❌ sessionsspawn + announce：用户收不到结果
3. ❌ sessionsspawn + message 推送 webchat：webchat 不支持
4. ❌ 同步 poll：阻塞进程，无中间输出
5. ❌ 循环 query：process poll 延迟导致超时 / yieldMs 超系统上限被后台化
6. ❌ sleep 1200 同步等：yieldMs 超系统上限，exec 被后台化，结果拿不回来
7. ❌ cron systemEvent + wakeMode 默认（next-heartbeat）：systemEvent 注入了但要等心跳才处理，用户等不到结果
8. ✅ 最终方案：submit → cron systemEvent（20分钟后注入主session，wakeMode=now 立即唤醒）→ agent 收到后 query 一次 → 直接回复用户
9. ❌ cron systemEvent wakeMode=now 但主 session 忙：报 "timeout waiting for main lane to become idle"，任务被 skipped，用户收不到结果
10. ✅ 兜底修复：除 cron 外，同时写入 pendinginquiries.json 追踪文件，心跳时兜底检查超时任务并补回结果
11. ❌ 用户 /new 重置 session 后，cron systemEvent 注入新 session，新 session 没有上下文不知道该干啥，结果又丢了
12. ✅ 修复：systemEvent 文本改为完全自包含，包含所有必要信息和明确操作指令，不依赖任何 session 上下文
13. ❌ systemEvent 触发后，回复发到了 heartbeat session（agent:main:main），而不是用户的 webchat session（agent:main:openresponses-user:xxx）。用户看不到回复。根本原因：systemEvent 走主 session 的心跳通道，回复目标是心跳 session，不是用户 session
14. ✅ 彻底重构：改用 isolated agentTurn + sessionssend。cron 触发独立 session 查询结果，然后用 sessionssend 主动推送到用户的 webchat session。不再使用 systemEvent
15. ❌ isolated agentTurn + sessionssend：sessionssend 确实把消息注入到了用户 session，agent 也生成了回复，但回复的 delivery.mode 是 "announce"（跨 session 投递），用户看到的是 "Agent-to-agent announce step" 而不是直接对话。内容虽然最终送达了，但用户体验差，看起来像系统消息而不是正常回复。根本原因：sessionssend 触发的回复走 announce 通道，不走 webchat 直连通道
16. ❌ message 工具发 webchat：webchat 不是可外发的 channel，message action=send channel=webchat 报 "Unknown channel: webchat"，不指定 channel 报 "no configured channels detected"
17. ✅ 被动模式（webchat 时代）：cron isolated agentTurn 只负责查询结果并写入文件（results/{taskId}.md），不尝试任何跨 session 推送。用户下次发消息时 agent 检查 results 目录，发现新结果就直接回复。心跳也可兜底检查。牺牲实时性换取可靠性
18. ✅ 钉钉主动推送（v2.0）：接入钉钉 channel 后，cron isolated agentTurn 查询结果后直接用 message action=send channel=dingtalk target=238382 推送到流畅的钉钉私聊。delivery.mode 仍为 none（不依赖 announce），由任务自己调 message 工具发送。实时性 + 可靠性兼得 🎉