CNB NPC 任务调度

要解决什么问题

在 CNB 上给 NPC 派活，往往不是「@ 一下就行」：仓库可能在组织间迁移、同类任务会重复扣积分、未 Star 的 NPC 不会触发、Issue 里重复 @ 还会浪费轮次。这套工作流把实战里踩过的坑（路径失效、积分枯竭、轮询过早判失败）收成可执行的步骤，让 Agent 按同一套规则派单、止损和归档。

工作流在做什么

需求确认先锁定任务类型（审查/开发/设计/文档/云开发等）、目标仓库和输出形态。复用检查用 memory_search 与近期 Issue 比对，同一仓库同类任务 7 天内完成可直接复用。仓库路径验证不信任记忆里的旧路径，Resource not found 时在 cnbmm、cnbnn、cnbvv、cnbyy、cnbll、yunjinhong、W3C 等组织里搜索并更新 memory/cnb-repo-paths.json。

积分与 NPC 匹配：credit 为 0 则停派；优先 CodeBuddy（免费审查/改码），云开发、重构、UI 审查、文档、OCR 等按表选社区 NPC，原则是一次只 @ 一个、能免费不花钱。创建 Issue 时在 body 内直接 @，不要另发评论触发。轮询默认 120s 间隔、600s 超时；CodeBuddy 实测常需 5–6 分钟，不宜过早判死。失败时按阶段诊断：镜像未重建、.cnb.yml 配置、积分耗尽、任务过大需拆分等，环境/配置/积分问题不盲目重试。

适用边界与注意点

• 只能使用已 Star 的 NPC；匹配后创建 Issue 前必须做 Star 前置检查。
• Token 需含 bill 相关 scope，否则积分查询可能 errcode 7。
• 组织积分枯竭时仓库会迁移，每次派活前应验证路径；流水线 error 涉及 charge/billing 时要标记组织并提示用户。
• office 与 document 是不同 NPC：前者靠 Issue 描述区分 PPT/Word/Excel，后者偏全能文档创建与格式转换。