CNB NPC 任务调度

要解决什么问题

在 CNB 上给 NPC 派活，如果跳过前置检查，很容易重复消耗积分、@ 了未 Star 的 NPC 却无人响应，或在仓库组织迁移后仍用旧路径创建 Issue。社区 NPC 还有响应时序与流水线错误类型差异，缺少统一流程时，Agent 往往会盲目重试，把配置或积分问题放大成多次失败。

技能如何工作

本技能把派单拆成可执行的步骤链，核心能力包括：

• 需求确认：明确任务类型（审查/开发/设计/文档/云开发等）、目标仓库与输出形态。
• 复用检查：memory_search 与近期 Issue 对照；同仓库同类任务 7 天内完成可直接复用结果。
• 路径与积分：验证仓库是否仍存在（errcode 5 则跨组织搜索并更新 memory/cnb-repo-paths.json）；credit 为 0 则停止派单。
• NPC 匹配：仅使用已 Star 列表中的 NPC；优先免费 CodeBuddy，再按任务类型选社区 NPC；一次只 @ 一个。
• 触发与轮询：在 Issue body 内 @ NPC（勿另发评论重复触发）；创建时必须 "work_mode": true 否则无法写代码/提 PR。轮询间隔 120 秒、超时 600 秒，以 is_npc=true 的评论或流水线状态为准。
• 失败诊断：区分 Docker 镜像缺失、NPC 配置、积分枯竭与任务过大，环境/配置/积分类问题止损不重试。

适用边界与注意点

• 未 Star 的目标 NPC 不会触发，需先 Star 再创建 Issue。
• CodeBuddy 实测约 5–6 分钟才有回复，社区 NPC 约 3–5 分钟，不宜在 2–3 分钟内判失败。
• Token 缺 bill scope 时积分查询可能失败（errcode 7），需提醒权限风险。
• office 与 document 是不同 NPC：前者靠 Issue 描述区分 PPT/Word/Excel，后者偏全能文档创建与格式转换。