docs(chat-skill): 建号改用服务端 API + Stream 建联，下线扫码 device-auth#407
Open
PeterGuy326 wants to merge 5 commits into
Open
docs(chat-skill): 建号改用服务端 API + Stream 建联，下线扫码 device-auth#407PeterGuy326 wants to merge 5 commits into
PeterGuy326 wants to merge 5 commits into
Conversation
PeterGuy326
force-pushed
the
feat/chat-bot-provisioning-openclaw
branch
2 times, most recently
from
0b1e010 to
6047e19
Compare
Introduce the top-level `dws connect` command domain (separate from chat):
- `dws connect bot create`: server-side async robot provisioning (submit + poll),
returns agentId/robotCode/clientId/clientSecret. Routed to a hardcoded
open-platform MCP endpoint via transport key-URL handling (query preserved,
session bearer skipped).
- `dws connect start`: linking only — Go-native in-process DingTalk Stream
(dingtalk-stream-sdk-go). Auto-detects the current host from runtime env
signals (WORKBUDDY_CONFIG_DIR, QODERCLI_INTEGRATION_MODE=qoder_work,
DINGTALK_AGENT, QODER_CLI, CLAUDECODE). Each channel wires the bot to ITS OWN
agent via a per-channel forwarder, in two families:
* session-bridge (workbuddy, qoderwork): HTTP into the CURRENT live desktop
session through the agent-session bridge — not a fresh one-shot CLI, which
would be a disconnected instance.
* one-shot exec (qoder, claudecode): spawn a fresh CLI per message.
openclaw/hermes use their external connector / official channel.
- bare `dws connect`: orchestrates provision + link.
- The Stream callback acks immediately and forwards/replies asynchronously (reply
via sessionWebhook), with MsgId dedup — a slow forward would otherwise delay
the ack and make DingTalk redeliver, bombarding the user with duplicates.
chat bot keeps only find/search; provisioning moves out of chat.
Generic file-queue bridge for channels whose agent is a live desktop session (workbuddy, qoderwork) with no OpenAI-compatible endpoint of its own. dws POSTs the DingTalk message; the bridge enqueues it and waits for the current session to write a reply, then returns it to dws. Parameterised by BRIDGE_PORT / BRIDGE_DIR so one instance per channel can run without colliding.
Add connect.md inside the skill bundle (skills/{mono,multi}/.../connect.md) so the
agent actually loads it: channel-to-agent routing (session-bridge vs one-shot
exec), the provision/link/approve flow, and bridge usage for workbuddy/qoderwork.
chat.md keeps a one-line pointer; SKILL.md routes "build bot / link agent" to
connect.
PeterGuy326
force-pushed
the
feat/chat-bot-provisioning-openclaw
branch
from
6047e19 to
e209960
Compare
The claudecode channel forwarded messages via a bare `claude -p`, which
inherited the operator's full interactive config — user hooks, plugins
(including behavioral-injection ones) and every MCP server. That leaked
internal prompt/hook text into bot replies and turned a quick Q&A into a
slow, multi-step agentic run. Pin the forward to `--setting-sources
project --strict-mcp-config` plus a neutral assistant persona so the bot
answers as a clean assistant; DWS_AGENT_CMD still overrides everything.
Also add receive/reply logging with end-to-end latency in the Stream
callback. The connector was completely silent, so an operator could not
tell a working connector from a dead one ("有没有收到?"), nor see that a
slow reply was claude -p cold start rather than a hang.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Each inbound message cold-starts a fresh `claude -p`; on the default model an end-to-end reply measured ~30s, nearly all of it process startup. A group-chat Q&A bot does not need a frontier model, so pin the claudecode forward to claude-haiku-4-5 by default for a much faster round-trip. DWS_AGENT_CMD still overrides for anyone who wants a heavier model. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景
机器人 provisioning 原走「扫码 device-auth」(
npx -y @dingtalk-real-ai/dingtalk-connector install)，交互式、需人工扫码。本 PR 改为服务端 API 一次建号 + DWClient Stream 建联，并下线扫码老逻辑。改了什么
provisioning recipe 重构为三段链路：
POST /v1.0/microApp/agent/create一次拿robotCode/clientId/clientSecret，无需扫码、可无人值守。DWClient订阅TOPIC_ROBOT，agent 收→回（运行时两条对等路径：openclaw/plugin-sdk契约 / OpenAI-compatible endpoint 保持不变，机制概念 + 指向 dingtalk-openclaw-connector）。qyapi_robot_sendmsg审批闸门（建号≠可用）+ 真实发消息探测 +chat bot search交叉验证（保留）。删除所有「扫码 / 二维码 / device-auth / connector install」表述。best_practices 新增
provision-botrecipe 行。涉及文件
skills/mono/references/products/chat.md、skills/multi/dingtalk-chat/references/chat.md— 主 recipe 重写skills/multi/dingtalk-chat/SKILL.md— 意图表 + 跨产品协作两处skills/mono/references/best_practices/01-messaging.md、skills/multi/dingtalk-chat/references/01-messaging.md— 新增 provision-bot 行新的 API/MCP 建号路径尚未上线（MCP 工具上游待建）。本 PR 合并后到工具上线前，skill 内建号步骤不可直接闭环——存在过渡真空期。文档已明确标注「目标态，依赖上游 MCP 工具上线」，并给出临时
dws api裸调验证方式（需调用者自带带建号 scope 的创建者凭证），不写 discovery 里不存在的幽灵命令。落地分工：建号 API 封成服务端 MCP 工具（含调用方授权校验）在上游服务端；CLI 侧只承接 overlay 入口 + 本文档。
更新（2026-06-04）：建号命令落地为「异步两步 + 轮询」，端到端验证通过
dws chat bot create已落地并在预发真机验证。相比上文初始的同步 API 设计有两点调整 + 一个关键修复：① 接口改为异步两步（上游为「避免重复建号」重新设计）：
submit_robot_create_task→ 返回taskId / status / interval / expiresIn / retryCount，corpId/userid 系统注入，支持传原 taskId 重试query_robot_create_result→ 按 taskId 轮询，WAITING / SUCCESS / FAIL / EXPIRED；SUCCESS 返回agentId / robotCode / clientId / clientSecret命令行为：内部 submit 拿 taskId → 按返回的 interval 阻塞轮询 query 至终态；
FAIL/EXPIRED带 taskId 返回，新增--task-id重试避免重复建号；端点保持命名别名/server/op-app（按登录态归属，不写死?key=密钥）。② 关键修复（commit
c6d95ae）：服务端返回是content → result两层壳，轮询取taskId/status时原代码只解一层 → taskId 读空 → 轮询空转、命令只返回首个WAITING。已改为依次解包content→result。③ 端到端验证（预发，临时把端点指向上游
?key=server 实跑）：status=SUCCESS，真建出机器人（agentId=4644737015、robotCode/clientId=dingkgggfexxdojase8b、返回 clientSecret）DWClientStream：connect success、订阅 TOPIC_ROBOT，建联闭环通go build/go vet/ 轮询单测（mock 还原真实嵌套壳 + 负向验证可兜回归）/ helpers 全量单测 全过④ 待上游：正式 op-app 路径需服务端把
submit_robot_create_task/query_robot_create_result挂到/server/op-app并刷新market_mcp_tools；挂好后跑 op-app 路径端到端即彻底闭环。