第 34 节 · NPC 是什么：仓库里的 AI 角色

一句话回答

NPC = 挂在代码仓库里的自动化 AI 角色。 当团队成员在 Issue / PR 评论里 @ 它时，平台触发流水线，让容器里的 Agent 处理任务并回写评论。

从"本地工具"到"团队协作者"

从本地 Agent 到仓库 NPC

	Day6 的本地 Agent	Day7 的仓库 NPC
谁在跑	你自己的电脑	云端流水线 / 容器
谁能触发	只有你	团队成员在 Issue / PR 评论里 @
什么时候跑	你手动启动	事件触发（评论、PR 讨论等）
回复到哪	终端输出	自动回复到 Issue / PR 评论
知道项目代码吗	知道（你指定 workdir）	知道（流水线 checkout 当前仓库）
适合什么	个人编程助手	团队协作、代码评审、自动问答、Issue 处理

NPC 不是"真的加入团队的人"，而是有身份的自动化入口。它能做多少事，取决于：镜像里装了什么、流水线给了什么权限、Secrets 配了什么、是否开启 Work Mode。

NPC 的触发机制

1. 有人在 Issue 评论里写: @owner/repo(my-agent) 帮我看看这个 bug
2. CNB 平台检测到 @ 了 NPC → 触发 NPC 事件流水线
3. 流水线 checkout 当前仓库并启动 Docker 镜像
4. 镜像里的 npc-entrypoint 读取评论内容和环境变量
5. 调 my-agent --solo exec 处理任务
6. 用 git-cnb / CNB API 把答案以 NPC 身份回复到原评论下方

CNB 当前支持的典型 NPC 事件：

事件	什么时候触发
`issue.comment@npc`	Issue 评论里 @ NPC
`pull_request.comment@npc`	PR 评论里 @ NPC

NPC 需要什么

零件	来自哪天	作用
`my_coding_agent` / `examples/full-agent`	Day6	Agent 本体（处理任务的引擎）
Dockerfile	今天写	把 Agent、依赖和入口脚本打包成镜像
`npc-entrypoint.sh`	今天写	接收 CNB 事件 → 调 Agent → 回写评论
`.cnb.yml`	今天写	告诉 CNB：NPC 事件来了就跑哪个镜像
`.cnb/settings.yml`	今天写	定义 NPC 角色名、口吻和提示词

NOTE

2026 年 CNB 官方还提供了 npc:go 内置插件，可以帮你跑更标准的 NPC 流程。本课程保留 npc-entrypoint.sh，是为了让你看清楚底层链路：取任务、跑 Agent、回写评论。

`.cnb/settings.yml` 里定义的是角色

新版 CNB NPC 配置更像"角色卡"：

yaml

npc:
  defaultRole: 小光
  roles:
    - name: 小光
      slogan: code is cheap, show me your prompt
      prompt: |
        你叫"小光"，是仓库里的 Coding Agent NPC。
        你擅长阅读代码、定位 bug、写补丁、总结文档。
      enableThinking: true

字段	含义
`defaultRole`	默认 NPC 角色
`roles[].name`	角色名，@ 时会用到
`roles[].slogan`	展示用的一句话介绍
`roles[].prompt`	这个 NPC 的人设、能力边界和回答风格
`enableThinking`	是否展示平台支持的思考过程

Work Mode：权限边界要讲清楚

CNB 的 NPC 可以在评论区启用 Work Mode（替我上班）。开启后，NPC 可能拥有更高权限，例如创建分支、提交代码、创建 MR、处理 Issue。

这很强，也很危险。所以要记住：

没有权限的 NPC 只能回复评论，不能替你改仓库
有权限的 NPC 也应该遵守最小权限原则
涉及写代码、推送、发 MR 的能力，必须让团队知道风险
Secrets 不要写在 prompt 或 skill 里，要放平台 Secrets

CNB 平台注入的环境变量

NPC 流水线运行时，CNB 会注入一些上下文变量。课程里最常用的是：

变量	含义
`CNB_NPC_TRIGGER_CONTENT`	触发 NPC 的原文内容
`CNB_REPO_SLUG`	仓库路径（`owner/repo`）
`CNB_ISSUE_IID`	Issue 编号（Issue 评论时有值）
`CNB_PULL_REQUEST_IID`	PR 编号（PR 评论时有值）
`CNB_WORKSPACE`	流水线工作目录（已 checkout 代码）
`CNB_TOKEN`	平台注入的临时凭证，权限受事件和模式限制

npc-entrypoint.sh 本质上就是读这些变量，然后决定：任务是什么、在哪个仓库跑、结果回复到 Issue 还是 PR。

动手试试

在脑子里过一遍完整链路：

谁触发？（团队成员在 Issue / PR 评论里 @ NPC）
谁启动容器？（CNB 流水线）
容器里跑什么？（npc-entrypoint → my-agent --solo exec）
结果怎么回去？（git-cnb / CNB API 回写评论）
权限从哪来？（CNB_TOKEN + 当前事件 + Work Mode）

小结

NPC = 仓库里的自动化 AI 角色，@ 它就触发流水线
触发链路：评论 @ → CNB 事件 → Docker 容器 → Agent 处理 → 回写评论
.cnb/settings.yml 定义角色，.cnb.yml 定义事件怎么跑
Work Mode 决定 NPC 是否能做更高权限的仓库操作
后面两节依次搞定 Docker 镜像和 CNB Pipeline

第 34 节 · NPC 是什么：仓库里的 AI 角色 ​

一句话回答 ​

从"本地工具"到"团队协作者" ​

NPC 的触发机制 ​

NPC 需要什么 ​

.cnb/settings.yml 里定义的是角色 ​

Work Mode：权限边界要讲清楚 ​

CNB 平台注入的环境变量 ​

动手试试 ​

小结 ​