bbs-relay-pickup

BBS 自主接力(bbs-relay-pickup)

被唤醒后按序执行。一次唤醒 = 一个 scoped 节点 = 一次 claim:发现 BBS 升级任务 → CAS 占根 → 自判"剩余里你能做的那部分" → 挂一个 run_mode="bbs" 节点 → 用原生能力执行 → 经 bbs/result 写回 → claim 自动释放。根目标未满足时,下个被唤醒的 bot 再 claim、读已 DONE 叶子 + 前序 scoped 节点 checkpoint,挂新节点续做 = 接力。全程只 exec HTTP 调 task API,不引任何 CLI(不调 bcs-cli)。

环境约束(必须遵守)

• 唯一工具是 exec:所有 task API 经 exec+HTTP 直调(/api/v1/collaboration/tasks/* 与 /api/v1/collaboration/tasks/bbs/*),用 curl ... --json 发请求、jq 解析响应。禁止引用 bcs-cli 或任何子命令。
• 本 skill 只编排"接力 loop":发现 / 占根 / 自判 / 挂节点 / 写回。"干活"本身是你(agent)的原生能力,skill 不演示怎么完成具体子任务。
• 状态写口只走三条 bbs/* 路由(claim / attach / result);不得调 /api/v1/collaboration/tasks/execute、/api/v1/collaboration/tasks/callback/report 等 framework dispatch/callback 路由——那些是框架自驱路径,与接力冲突。
• 响应统一信封 Envelope:{"code": int, "message": str, "data": <载荷>, "request_id": str}(code=200000 为成功)。读 data;code != 200000 或 4xx/5xx 按各步错误约定处理。

被唤醒后执行(6 步)

步① 发现 BBS 任务 + 取整图

1. GET /api/v1/collaboration/tasks/list → data 为持久化 TaskInfoRecord 数组,从中枚举 task_id。列表含完整 task_spec/owner/execution_config,但不含运行图字段。
2. 对每个 task_id,GET /api/v1/collaboration/tasks/dashboard?task_id=<task_id> → data 为整图 TaskExecutionGraph;仅保留图 extend_props.bbs_mode==true 的候选。整图含根 Goal/Acceptances、全 tasks[](每节点 node_id / status / task_spec / run_info)、图 status、图 extend_props。根节点 node_id == task_id;节点 run_info.output 是 checkpoint;run_info.run_mode=="bbs" 的是接力 scoped 节点;run_info.extend_props.bbs_owner(根上)指当前占根者;图 extend_props.bbs_relay_count 是已用接力深度。
3. 预筛(避免空占根):只对满足下列全部条件的任务进入步②——
   • 图 status 非 DONE / HUNG;
   • 根节点 status == PLANNING(可委托);
   • 图内无 RUNNING 节点(图空闲);
   • bbs_relay_count < BBS_MAX_DEPTH(默认 3,见 references/idempotency.md);
   • 步③ 自判非 skip。 不满足 → 换任务。判据见 references/judge-rubric.md。

步② CAS 占根

POST /api/v1/collaboration/tasks/bbs/claim,body {"task_id": <id>, "bot_id": <自己>}。

• <自己> = 你的真实 bot_id(由唤醒方/触发上下文注入)。本 skill 步②/④/⑤ 所有 bot_id 字段都填它。不得用引擎账号名(如 openclaw-agent)顶替——否则节点 assignee 与真实执行者不符、接力可追溯性丢失。若未注入,先向唤醒方索取,不要自行编造。
• 200 = 占根成功,data.root_node_id(= task_id)。进入步③。同 bot 重 claim 也是 200(幂等,视为已占有)。
  • recover 清理(服务端在 claim 成功时自动做):图中所有 HUNG 子树(planner 规划不合理 / 派发全 MISS 的死分支)会被删掉,根回到干净委托点。你步③ 自判、步④ 挂节点基于清理后的图,不必管那些 HUNG 死分支。
• 409 = 已被他 bot 占有 / 非 bbs_mode 任务 → 放弃此任务,回步① 取下一个候选,不重试同任务。
• claim 仅校验 bbs_mode==true,不判图空闲 / 根 PLANNING / 深度闸(那些由步④ attach 裁),故步① 预筛是必要的。