
## 一、缘起：GitHub 有「毒舌」，CNB 没有

前段时间 [毒舌 GitHub（ghfind.com）](https://ghfind.com/) 挺火——丢一个 GitHub 用户名进去，AI 会把你的仓库、PR、commit 翻个底朝天，给你一段不留情面又有理有据的锐评。它的技术底子是开源项目 [github-roast](https://github.com/hikariming/github-roast)（AGPL-3.0）。

问题是，我平时的代码托管主战场是  **[cnb.cool](https://cnb.cool/) **（腾讯云的一站式研发协作平台），身边同事的仓库、PR、贡献记录都在 CNB 上，不是 GitHub。GitHub 版的毒舌工具压根读不到这些数据。于是动了个念头：做一个 CNB 版的。不是简单换个 API 域名了事，CNB 的贡献日历、PR 状态、活动接口跟 GitHub 完全不是一套数据结构，取证逻辑得重新设计一遍。

项目最后叫 **CNBRoast**（站点展示名「CNB 烤场」），仓库在 [cnb.cool/Bring/Project/CNBRoast](https://cnb.cool/Bring/Project/CNBRoast)。写代码用的是 **WorkBuddy**，运行时和 Agent 沙箱托管在 **EdgeOne Makers**，模型走腾讯云 TDP 的内置大模型资源。下面按设计、编码、托管、踩坑的顺序说一遍，尽量说具体的事，少讲空话。

---

## 二、先想清楚再动手：用 WorkBuddy 把想法磨成 PRD

我吃过好几次「边写边想」的亏——需求没捋清楚就动手，写到一半发现数据模型不对，只能推倒重来。这次换了个做法：先在 WorkBuddy 里把整个项目当一次架构评审来聊，把关键决策在写代码之前定下来，落成两份文档：`PROJECT.md` 讲清楚这是什么、为什么这么设计；`PLAN.md` 讲怎么落地——分几个阶段、接口怎么冻结、哪些活可以并行分给不同的编码任务同时干。

![image.png](https://developer.qcloudimg.com/http-save/yehe-10211746/9568877a64927f8af82e12c464318222.png)

![image.png](https://developer.qcloudimg.com/http-save/yehe-10211746/b68125fe9e923eea8d21c458b00b6839.png)

这一轮磨出来最重要的一条决策，是放弃让大模型直接打分。理由很直接：LLM 给分不可复现，同一个账号刷新几次分数会跳来跳去，体验差,也容易被质疑是不是随便打的。于是把职责拆开——Agent 只管取证，不管算分。六个维度（账号资历、原创质量、贡献质量、生态影响、社区影响力、活跃真实性）需要的客观证据，比如 merge 了多少 PR、star 数多少、贡献跨度多少天，由 Agent 自主调用工具收集齐，提交给终结工具 `submit_result`；真正算分的逻辑在 `lib/scoring.ts` 里是一套写死的公式。同一份证据，永远算出同一个分数，「再毒一次」只有账号数据真变了分数才会变。

`PLAN.md` 里进一步把工程拆成冻结接口、并行开发、集成、联调四个阶段：CNB 客户端、缓存层、Agent 主循环的接口先固定死，8 个 CNB 数据工具、终结工具、前端页面分给几路并行的编码任务同时写，互不打架。这套先写 PRD、冻结接口再并行的方法论，是这次跟 WorkBuddy 协作下来觉得最值的部分——不是省了多少打字时间，是逼着我在动手前把架构决策想透。

---

## 三、8 个 CNB 工具 + 一次工具调用循环

设计定下来之后，核心实现是一个标准的 LLM 工具调用循环：系统提示词里塞进账号主页摘要和 8 个 CNB 工具的说明，Agent 自主决定调用顺序——`list_repos` 看仓库、`list_activities` 逐月翻贡献日历、`list_pulls` 加 `get_pull_detail` 抽样看 PR 是不是刷量、`get_ranking` 看有没有上过 CNB 官方榜单——边取证边推理，直到证据攒够，调用终结工具收尾：

```ts
// submit_result 的结构化载荷（不含分数，分数由 lib/scoring.ts 算）
interface SubmitResult {
  evidence: Record<string, number | boolean>  // 六维度证据
  redFlags: { flag: string; detail: string }[]  // 刷量红旗
  roast: string                                  // 毒舌正文
}
```

其中 `GET /users/{username}/activities?date=yyyyMM`（CNB 的贡献日历接口）是整个取证链的基石。它不仅按 `commit / pull_request / issue / code_review` 拆分计数，还会列出当月贡献过的所有仓库，包括外部仓库——这一举解决了「这人到底给哪些仓库做过贡献」这个原本要挨个仓库排查的难题。

从「效果图（个人详情」那张截图能看出这套取证逻辑跑起来是什么样子：账号 `leun` 简介写着「不会写代码，也不会 CNB」，但实际有 348 个仓库、6600+ 月贡献量——Agent 没有被表面数字唬住，翻出仓库名里 `ai-models/Ollama/OneClick/qwen3.5`、`Bring/NPC/Tangy` 这类模板化命名，指出这更像是批量生成的仓库而非手写项目，六维度里「原创质量」和「贡献质量」也相应扣了分。这段点评不是模型编的,是从贡献日历和仓库列表里抠出来的证据支撑的。

---

## 四、EdgeOne Makers：省掉了「拼服务」的那一半工作量

写业务逻辑之前最担心的是部署——一个要跑几十秒、要维护会话状态、要能观测每一步在干什么的 Agent,如果自己拼 Node 服务加队列加日志系统,工作量不比业务逻辑本身小。这正是 EdgeOne Makers Agents 这类托管平台要解决的问题：运行时、沙箱、对话记忆、可观测、模型接入全部内置，业务代码只管写 `agents/roast/index.ts` 里的逻辑。

### 本地起服务

`npm run dev` 背后跑的是 `edgeone makers dev`，几秒钟内本地起好 Agent Runtime，顺带给了一个本地可调试的 Observability 面板入口：

![Cli执行.png](https://developer.qcloudimg.com/http-save/yehe-10211746/f0eec24aa4056ed551ab327df2b5e485.png)

### 会话状态交给 context.store

每次生成要记录这次扫描请求、最终评分结果、出错原因，Makers 提供的 `context.store` 直接当会话存储用，不用自己额外拉一个数据库存中间状态：

```
[Makers Agent]  agents/roast/index.ts  (Agent Runtime)
   │ ① context.store 记录扫描请求 → 缓存命中?
   │ ② 未命中：限流 + CNB 预检 → 起 Agent 工具调用循环
   ▼
[落缓存 + 会话记录] Blob 保存结果缓存；context.store 保存请求 / 结果 / 错误
```

### 可观测性

这块是实际用下来觉得最省心的。Agent 一跑起来就是十几秒到几分钟的多轮工具调用，没有链路追踪基本没法排障。Makers 的 `context.tracer` 让我们几乎零配置就拿到了完整的调用链。

本地 Metrics 面板能看到 Agent 调用量、模型调用错误率随时间的变化：

![本地Agent Dashboard.png](https://developer.qcloudimg.com/http-save/yehe-10211746/9562ab034646d336b844cfc32c9a2635.png)

点开一次成功的 `/roast` 请求，能看到从限流检查、CNB 预检到 Agent 循环里每一次 `llm.chat` 和 `tool.execute` 的耗时，`roast.username` 这类自己打的业务标签直接挂在 Span 上：

![本地Agent Dashboard Items.png](https://developer.qcloudimg.com/http-save/yehe-10211746/8932feef2f869c9df6b0b3ac35739538.png)

线上项目控制台也能按环境、时间范围检索所有 trace（这是 `cnb-roast` 生产环境的调用列表，跑了小一百次）：

![线上Agent Dashboard.png](https://developer.qcloudimg.com/http-save/yehe-10211746/0ccdb34a9fa250e4c47ab8ca7e7a0fae.png)

点进具体的 `llm.chat` span，模型名直接标出来，调试时不用再去日志里翻：

![线上Agent Dashboard Items.png](https://developer.qcloudimg.com/http-save/yehe-10211746/7167e1073abd5ee2c8ce74311783af95.png)

Timeline 视图能直观看出一次生成里模型调用和工具调用是怎么穿插的，图里这次最长的一次 `llm.chat` 耗时 37.87 秒：

![线上Agent Dashboard Items（Time Cost.png](https://developer.qcloudimg.com/http-save/yehe-10211746/a1a9044af27e7114be0e5d8216f65bb6.png)

### 一个真实踩到的坑

联调阶段，Trace 面板帮我们抓到过一次真实的失败：Agent 在工具调用循环里转了 40 轮还没调用终结工具 `submit_result` 提交结果，被自己设的超时保护掐断：

![本地Agent Dashboard Items（fail.png](https://developer.qcloudimg.com/http-save/yehe-10211746/a65c67710bd2bfba874ea53c6c26c9e8.png)

这不算 bug 修复,是设计上本来就该有的安全网。`lib/agent.ts` 主循环有一个 `maxTurns` 硬上限（默认 40，`AGENT_MAX_TURNS` 可调），快到上限时先提醒模型一次必须调用 `submit_result` 收尾,仍不收敛就抛错,而不是让请求悬空挂起耗光资源：

```ts
export class AgentTimeoutError extends Error {
  constructor(public maxTurns: number) {
    super(`已达到最大对话轮次（${maxTurns}），Agent 未提交结果`)
  }
}
```

没有 Trace 面板的话，这种模型自己绕圈子不收敛的问题基本只能靠加日志、猜时间点排查；有了 Span 树，一眼就能看出是取证阶段某个工具被反复调用，还是模型迟迟不肯下终结判断。

### 内置模型

`.env.example` 里 `LLM_MODEL` 是唯一必填项——配了 `LLM_BASE_URL` + `LLM_API_KEY` 就走外部 OpenAI 兼容端点,不配就直接由 EdgeOne 内置的 AI 网关运行这个模型名,外部端点调用失败也会兜底回网关模型。线上实测跑的是 `qwen3.6-35b-a3b`，前面几张 trace 截图里的模型名就是证据。从写完第一行 Agent 代码到看到第一次真实生成，中间不用单独去开一个模型服务账号。

### 缓存：Blob + CAS 互斥锁

结果缓存和排行榜快照存在 EdgeOne Pages Blob 里，Next.js 侧通过外部访问 `projectId + token` 读写。这里有个容易被忽略的并发问题：同一个冷门账号被多人同时访问，如果不去重，会有好几个请求同时起 Agent、同时消耗 LLM 配额,最后还可能互相覆盖分数。我们用 Blob 的 `setJSON(..., { onlyIfNew: true })` 做了一把真正原子的 CAS 锁（`lock/roast/{username}`），抢到锁的请求才真正跑调研，其余请求轮询结果直到出现更新的 `scannedAt` 直接复用，比自己拿 Redis 搭一套分布式锁省事不少。

---

## 五、腾讯云 TDP 大模型资源

做 Agent 应用最现实的顾虑往往不是技术方案，是模型调用成本。这次项目能跑起来，很大程度靠了两层资源：EdgeOne Makers 内置 AI 网关，不配外部 `LLM_BASE_URL`/`LLM_API_KEY` 时 `LLM_MODEL` 直接由平台网关运行，省了单独开模型账号、管密钥的步骤；再加上腾讯云 TDP（腾讯云开发者先锋）的大模型调用资源，站点首页底部也标了「大模型资源由 TDP 提供」。

![image.png](https://developer.qcloudimg.com/http-save/yehe-10211746/c3ee333f78570acede9e7556396b7f7f.png)

对预算有限的个人项目来说，这个组合基本能做到先用免费额度把原型跑通、验证有没有人真的想用，再考虑要不要换更贵的模型，试错成本压得很低。

---

## 六、上线效果

[CNB Roast · 毒舌评分](https://roast.commit.cool/) 。首页很简单，一个输入框，几个预置示例账号，底部标了托管加速、模型资源、代码托管和灵感来源：

![效果图.png](https://developer.qcloudimg.com/http-save/yehe-10211746/b0f559c37cba945374de7736e039621a.png)

结果页是雷达图 + 分数卡 + 毒舌正文,前面第三节引用的 `leun` 这段点评就是从这张图截的：

![效果图（个人详情.png](https://developer.qcloudimg.com/http-save/yehe-10211746/bd3aa8e2467f85c99079292345fc276b.png)

名人堂按综合评分排序，能看到不同账号的分数和档位：

![效果图（名人堂.png](https://developer.qcloudimg.com/http-save/yehe-10211746/90c33166adf53b3bb4169d5efc4e58ab.png)

页面路由是 RESTful 的，`/u/{username}` 可以直接分享、直链、被搜索引擎收录；分享到社交平台时用缓存分数生成的 OG 卡片会直接带分数展示，不用点进去才知道结果。

---

## 七、还没解决的问题

几个没有回避的真实取舍：Blob 没有原生 TTL 和原子自增，限流计数是近似的 read-modify-write，高并发下会有轻微误差,对「防刷、不是银行级一致性」的场景够用，但要做计费级别的计数就不能直接照搬。放弃「AI 直接打分」换来了确定性，但也意味着评分准则是写死的固定公式，账号数据的边界情况需要持续观察调准公式里的曲线参数，不是一次设计就能完全兜住所有 case。

**相关链接：**
- 本项目仓库：[cnb.cool/Bring/Project/CNBRoast](https://cnb.cool/Bring/Project/CNBRoast)
- 上游灵感来源「毒舌 GitHub」：[ghfind.com](https://ghfind.com/)
- 上游开源项目 github-roast：[github.com/hikariming/github-roast](https://github.com/hikariming/github-roast)（AGPL-3.0）
- EdgeOne Makers 产品介绍：[pages.edgeone.ai/zh/document/agents](https://pages.edgeone.ai/zh/document/agents)


前段时间 毒舌 GitHub（ghfind.com） 挺火——丢一个 GitHub 用户名进去，AI 会把你的仓库、PR、commit 翻个底朝天，给你一段不留情面又有理有据的锐评。它的技术底子是开源项目 github-roast（AGPL-3.0）。

从 0 到 1：我用 WorkBuddy 写代码，用 EdgeOne Makers 托管出一个「CNB 烤场」评审 Agent

用 EdgeOne Makers 托管出一个「CNB 烤场」评审 Agent

腾讯云TDP 先锋会员

开发工具

人工智能

云计算

CNB烤场（CNBRoast）是一款基于腾讯云CNB平台的AI代码分析工具，通过智能Agent分析用户代码仓库、PR记录等数据，提供犀利点评和六维评分。采用WorkBuddy规划开发流程，依托EdgeOneMakers实现快速部署，利用腾讯云TDP大模型资源降低成本。支持RESTful接口和社交分享，为开发者提供客观的代码质量评估。

2026上云采购 | AI焕新·智启新局

coding

热销域名限时优惠，新客首年免费！


domain

agsx

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

CNB烤场（CNBRoast）是一款基于腾讯云CNB平台的AI代码分析工具，通过智能Agent分析用户代码仓库、PR记录等数据，提供犀利点评和六维评分。采用WorkBuddy规划开发流程，依托EdgeOneMakers实现快速部署，利用腾讯云TDP大模型资源降低成本。支持RESTful接口和社交分享，为开发者提供客观的...

从 0 到 1：我用 WorkBuddy 写代码，用 EdgeOne Makers 托管出一个「CNB 烤场」评审 Agent-腾讯云开发者社区-腾讯云

从 0 到 1：我用 WorkBuddy 写代码，用 EdgeOne Makers 托管出一个「CNB 烤场」评审 Agent

从 0 到 1：我用 WorkBuddy 写代码，用 EdgeOne Makers 托管出一个「CNB 烤场」评审 Agent

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐