一个斯坦福论文仓库的 946 个 star,有一半像是买的
它是什么 给 LLM agent 外挂的失败管理层:发现 agent 卡循环、跑偏或格式出错时,从外置手册里取几条对得上的经验让它改,确认修好了才把经验记下来。
为什么火了 星数主要靠刷:fork 账号是 10 月下旬批量注册的新号,star 和 fork 在 10-19 到 10-22、11-03 两次同步暴涨,中间被 GitHub 清掉一批;真实热度只是斯坦福 ACE 团队一篇论文在学术圈里的那点关注。
D你可以怎么跟 别再做一个论文仓库;要做就把「只在出错时递经验、修好才记」做成 Claude Code / Codex 的 hook 或插件,配一段装前卡死、装后绕出来的录屏。
- 数据(每天更新) · 建库 2026-10-02 · 1,048 星 · 7 天 +458
GitHub · 星数 数据 2026-10-09 → 2026-11-08(31 天,31 次观测)。10-28 以前的点来自 deeply / 存档补录,不是每天都有
Sentry 是斯坦福一篇真论文的配套代码,给 LLM agent 外挂一个「失败管理层」:发现 agent 卡住或跑偏时,只把对得上的几条经验递给它,修好了才记下来。论文是真的,作者里有 ACE 的作者和斯坦福的 Kunle Olukotun 教授;但它在 GitHub 上一个月涨到近千 star,主要不是因为有人读了论文。下面说清楚它是什么、star 从哪来、真实热度有多大,以及想做同类项目的人能从里面拿走什么。
11 月 5 日早上的 10 个 fork
2026 年 11 月 5 日 UTC 早上 5 点到 6 点多,Sentry 仓库在一个多小时里多了一串 fork。按时间倒着看:chloewilson22 在 06:18:38,taohanefw 在 06:18:37,前后差一秒;再往前是 gardenderekavk、adamcoopermrf、jiang-guangkga(这两个也只差一秒)、carl-pricevwj、yang-leijf、adam-wilsonwje、devclarachan、hanjunnfr——最后两个是同一秒(GitHub fork 列表,11-06)。
名字的格式都一样:一个英文名或拼音,后面跟三四个随机字母。往前翻到第 100 个 fork,全是 11-03 到 11-05 这三天建的;抽查其中 15 个账号,注册日期都在 10 月 20 日到 22 日,每个账号四五个仓库、0 个 follower、一辈子只给一个仓库点过 star。这是刷 star 和 fork 的服务批量养出来的号,不是读论文的人。
它到底是什么
一句话:agent 跑任务的时候,在旁边放一个「值班员」。
Sentry 每看最近 5 步就判断一次 agent 有没有出问题。格式错了(工具调用参数不对、动作不合法),直接让 agent 按格式重来;卡在循环里、偏离任务、凭空推理,就按细粒度的失败标签,从一本外置的「经验手册」里取 5 条对得上的经验递给它。之后再观察 10 步,确认 agent 真的恢复了,才把这次的经验写回手册。整本手册从来不进 agent 的上下文。
论文(arXiv 2610.02994,10-02 提交)的核心观点是:失败经验是「有条件的知识」,不该常驻在上下文里。ACE、Reflexion 这类方法把经验一直塞在 prompt 里,没出那种错的时候反而会误导 agent。论文里报的结果:在 WebShop、AppWorld、SWE-bench Lite、Mind2Web 上比最强的运行时干预方法平均高 37%,比 ACE 一类方法高 39%;token 用量是原 agent 的 1.54 倍;939 次检测到的失败里恢复了 81.7%(README 和 arXiv 摘要,结果没人复现过)。
接入也轻:每走完一步把这一步交给 runner.step(),它要是返回一段修复提示,就塞进 agent 的消息里,agent 本身不用改。
作者 Leo Ji(Changxiu Ji)是斯坦福数学和计算机的学生,在 Olukotun 的 PPL 实验室;合作者 Qizheng Zhang 是 ACE(ace-agent/ace,约 1,430 star)的作者。可以把 Sentry 看成 ACE 团队的后续工作。
star 曲线:两次暴涨,一次回跳
| 日期 | star | fork | 发生了什么 |
|---|---|---|---|
| 10-17 | 244 | 4 | |
| 10-19 | 311 | 34 | fork 突然开始涨 |
| 10-22 | 474 | 76 | |
| 10-23 | 349 | 5 | 一天少了 125 个 star、71 个 fork |
| 10-31 | 532 | 4 | |
| 11-02 | 607 | 6 | |
| 11-03 | 703 | 67 | 单日 +96 star,fork 一天多 61 个 |
| 11-06 | 828 | 103 | GitHub 页面实时显示 946 |
(GitHub star 和 fork 数,每天记录)
真实用户点的 star 不会一夜消失,fork 更不会从 76 掉回 5。10 月 23 日那次回跳,最像的解释是 GitHub 清掉了一批假号(推断,把握大)。之后 11 月 3 日 star 和 fork 又一起往上冲,正好对上那批 10 月下旬注册的小号开始干活。
不刷的那几天能看出真实底子:10-24 到 11-02,每天涨 15–30 个 star,fork 一直停在 4–6 个。照这个速度算,它的真实 star 大概在 400–500 之间(估,没法直接核实,因为点 star 的人的名单拉不到)。
作者另外几个仓库也是同一个样子:学生作业性质的 Options-Analytics-Agent 646 star / 85 fork,Factor-Research 422 / 62,Job-Recommendation-System 234 / 36,都早已停更,fork 列表里也能看到 miliwe3vision 这类随机名字。是作者自己买的,还是刷量服务为了「养号」挑热门新仓库顺手刷的,外面判断不了;但几个仓库都这样,前一种可能性更大(推断)。
真实有多少人知道
很少。论文 10 月 6 日被人发到 Hacker News,1 分,没有评论;X 上近 40 天搜「Sentry agent failures」、论文编号、作者 ID,一条都没有;能找到的只有一篇 LinkedIn 个人帖,以及 alphaXiv、ResearchGate、Moonlight 这类论文自动收录页。OpenReview 上有一篇同主题投稿《Sentry: A Self-evolving Failure Manager for Agentic LLM Systems》,评审情况没看到。
仓库本身 10 月 11 日推了最后一个 commit「Release Sentry」,一共 5 个 commit,之后再没更新,issue 是 0。一个近千 star 的项目没有一个人来提 issue,这本身就说明问题。
还有一个小坑:名字和做错误监控的 sentry.io 撞了,搜「Sentry agent」出来的大多是 sentry.io 的 AI 监控功能,真想找它的人反而不好找。
谁在做同一件事
| 项目 | 做的是什么 | star(11-06) |
|---|---|---|
| Reflexion | 任务结束后自我反思,下次再试 | 3,403 |
| ace-agent/ace | 经验写进不断演化的 playbook,常驻上下文;同一团队 | 1,434 |
| Agent Workflow Memory | 记成功的工作流,不管失败 | 482 |
| ag2ai/Agents_Failure_Attribution | 失败归因的评测集 | 396 |
| Dynamic Cheatsheet | 测试时累积常驻的 cheatsheet | 279 |
| ExpeL | 从成功和失败轨迹里提炼 insight 放进 prompt | 251 |
| AgentDebug | 事后做失败归因,不做运行时修复 | 108 |
| AgentOps / Langfuse / sentry.io | 只观测、报警,不修也不学 | 数千 / 商业产品 |
论文层面它的位置说得清:在「经验常驻上下文」的 ACE/Reflexion 和「固定规则的运行时监控」之间。但这些项目都是论文代码,真正给开发者日常用的形态——比如直接装进 Claude Code 或 Codex 的插件——还没人做。
如果是你
判断:Sentry 的近千 star 大半是刷出来的,真实热度是一篇斯坦福论文在学术小圈子里每天二三十个 star 的水平,而这点真实热度靠的是 ACE 团队和斯坦福的名字,你借不到。照着它再做一个「agent 失败恢复」的论文仓库,不值得。
适合谁:在做 coding agent 工具、天天被 agent 卡循环和工具报错折磨的开发者。值得拿走的是论文那个思路:失败经验只在对应的失败出现时才递给 agent,修好了才记。
不适合谁:想靠「论文复现 + 漂亮 README」攒 star 的人。这一格已经有 Reflexion、ACE 这些千星项目,没有论文和实验室背书,起不来。
怎么做:如果一定要动手,唯一有意思的方向是做它没做的那部分——把这套思路做成 Claude Code / Codex 的 hook 或插件:检测到同一个工具连续报错、同一条命令重复跑三次,就从本地经验文件里取两三条匹配的提示注入进去,事后看问题有没有解决再决定要不要记下来。配一段「装之前卡死、装之后自己绕出来」的录屏(推断:这种形态比论文代码更容易被开发者收藏)。
怎么获客:Claude Code、Codex 的插件和技能合集仓库、X 上做 agent 工具的开发者圈子;README 第一屏放录屏和一条安装命令。不要买 star:这个仓库 10 月 23 日一天被清掉 125 个,假号被清的那一下,曲线上谁都看得见。
什么时候之前:Claude Code 和 Codex 都在往「从失败里自动学习」的方向加功能,做 hook 这条路大概只有几个月窗口(估)。
什么情况说明看错了:① 论文中了会议,或者有知名账号转发,带来一波没有小号 fork 的真实增长,说明这个方向的学术热度比这里估的大;② 有人把它做成 coding agent 插件后很快拿到几百个真实 star,说明「失败触发的经验」是开发者真想要的东西,值得早点跟;③ Claude Code 或 Codex 官方加上了同样的机制,外挂这一层就没必要了。
研究底稿:竞品表、获客证据、完整研究报告
- 竞品
名字 在哪 上线 规模 它和这家不同在哪 ACE (ace-agent/ace) 开源 2025-11 1434 星 经验常驻上下文的演化 playbook;Sentry 只在检测到失败时暴露经验,同一团队,可叠加 Reflexion 开源 2023-03 3403 星 任务结束后自我反思、跨 trial 学习;Sentry 是任务中实时修复并验证 ExpeL 开源 2023-12 251 星 从轨迹提炼 insight 放进 prompt,没有失败触发和恢复验证 Dynamic Cheatsheet 开源 2025-04 279 星 测试时累积常驻 cheatsheet Agent Workflow Memory 开源 2024-08 482 星 记成功工作流,不针对失败 AgentDebug / Agents_Failure_Attribution 开源 2025 108 / 396 星 事后做失败归因和评测,不做运行时恢复 AgentOps / Langfuse / sentry.io AI Observability 其他 2023 起 数千星 / 商业产品 只观测报警,不自动修复也不学习 - 用户从哪来
- 查实 刷 star/fork:最新 100 个 fork 全在 11-03 到 11-05 创建,抽查 15 个账号都注册于 10-20 到 10-22,0 follower、4–5 个库、只点过 1 个星;10-23 星 -125、fork -71 回跳;作者其他学生项目也是 234–646 星且停滞
- 查实 arXiv 论文 + 斯坦福团队背书:arXiv 2610.02994,作者含 Qizheng Zhang(ACE)、Kunle Olukotun;alphaXiv、Moonlight、ResearchGate 收录
- 查实 HN:2026-10-06 提交,1 分
- 推断 X / 大号转发:x-radar 近 40 天 0 条
nuglifeleoji/Sentry:为什么能跑出来
一句话:Sentry 是斯坦福一篇 arXiv 论文(2610.02994)配套的开源代码,做的是 LLM agent 运行时的「失败管理层」:检测失败、引导修复、验证修复成功后把经验存进外部 playbook。论文是真的,但 GitHub 上 946 星里有相当一部分是刷出来的:能查到的 fork 账号几乎全是机器批量注册的小号,10-23 那次星数和 fork 数回跳,就是 GitHub 清了一批假号。它在我们数据里「跑出来」,主要是靠刷量,不是靠真实传播。
1. 基本情况
- 仓库:github.com/nuglifeleoji/Sentry,2026-10-02 建库,MIT。到 10-11 一共 5 个 commit(最后一个是「Release Sentry」),之后再没推送(GitHub API,2026-11-06)。
- 作者:Leo Ji(Changxiu Ji),bio 写的是「Math & CS @ Stanford @stanford-ppl」,124 个 follower。
- 论文:*Sentry: Learning to Recover from LLM Agent Failures at Test Time*,作者 Changxiu Ji、Amy Lu、Qizheng Zhang、Kunle Olukotun(arXiv 页 citation_author 字段),v1 提交于 2026-10-02。Qizheng Zhang 是 ACE(Agentic Context Engineering,ace-agent/ace 有 1434 星)的作者;Olukotun 是斯坦福 PPL 的教授。可以看成 ACE 团队的后续工作。
- 方法:每看最近 5 步就判断一次有没有失败;格式错误走 hard repair,让 agent 按格式重来;卡死、跑偏、无依据推理走 soft repair,按细粒度失败标签取 k=5 条经验;之后观察 10 步,确认恢复了才把这次经验写进 playbook,整本 playbook 不进 agent 上下文。论文宣称:比最强的运行时干预基线平均高 37%,比 context-evolution 基线(ACE 一类)高 39%,token 用量是基础 agent 的 1.54 倍,939 次检测到的失败里恢复了 81.7%(README、arXiv 摘要、Moonlight 综述)。
2. 星数曲线与刷量证据
数据卡 / 库 github.repo_day:
| 日期 | stars | forks |
|---|---|---|
| 10-17 | 244 | 4 |
| 10-19 | 311 | 34 |
| 10-22 | 474 | 76 |
| 10-23 | 349 | 5 |
| 10-31 | 532 | 4 |
| 11-02 | 607 | 6 |
| 11-03 | 703 | 67 |
| 11-06 | 828(GitHub 实时 946) | 103 |
- fork 账号全是小号:用 GitHub API 拉了最新 100 个 fork,全部在 11-03 到 11-05 这三天创建。账号名都是「英文名 + 随机 3–4 个字母」这种格式(chloewilson22、taohanefw、gardenderekavk、adamcoopermrf、jiang-guangkga、carl-pricevwj……)。抽查的 15 个,注册日期都在 2026-10-20 到 10-22,每个 4–5 个仓库、0 follower、只给 1 个库点过星。这是典型的刷 star/fork 服务账号。
- 10-23 回跳:一天之内 stars 474→349(少了 125),forks 76→5(少了 71)。符合 GitHub 清理一批假号的情形。11-03 forks 又一下子从 6 涨到 67,同一天星数单日涨 96(数据卡里的最高单日),说明又进了一批。
- 自然量的基线:不在刷量窗口的时候(10-24 到 11-02),每天大约涨 15–30 星,fork 一直停在 4–6 个。真实读者的规模大概是这个量级。
- 作者的其他库也有同样的迹象:学生项目 Options-Analytics-Agent 有 646 星 / 85 fork,Factor-Research 有 422 / 62,Job-Recommendation-System 有 234 / 36,现在都停滞了(github.repo_profile)。fork 列表里也有不少名字像随机生成的账号(miliwe3vision、bnz2299Holzsch 等)。这类求职向的作品集项目星数这么高,本来就不正常,只是没逐个核实。
- 库里 suspect 列是空的:它的几条规则(零 fork、同简介批量等)抓不到这种「星和 fork 一起刷」的做法。
3. 真实的曝光
- HN:2026-10-06 有人提交过论文链接,1 分(HN Algolia)。
- X:x-radar 近 40 天搜「Sentry agent failures」「2610.02994」「nuglifeleoji」「Sentry playbook」,全是 0 条。没有发现大号转发。
- 其他:有一篇 LinkedIn 个人帖(Harshit Mishra,约 2 周前)、ResearchGate 收录、Moonlight 的 AI 文献综述、alphaXiv 页面;OpenReview 上有一篇同主题的投稿 *Sentry: A Self-evolving Failure Manager for Agentic LLM Systems*(id QT7ROtt9Lh,页面要验证码,没读到)。都属于论文自动聚合级别的曝光。
- 结论:只在学术小圈子里有人知道,没有破圈。
4. 竞品
| 名字 | 形态 | 上线 | 规模 | 和 Sentry 的区别 |
|---|---|---|---|---|
| ACE(ace-agent/ace) | 开源/论文 | 2025-11 | 1434 星 | 把经验写进不断演化的 context playbook,全部放在上下文里;Sentry 认为这样会误触发,只在检测到失败时才暴露经验。两者来自同一团队,可以叠加用 |
| Reflexion | 开源/论文 | 2023-03 | 3403 星 | 任务结束后用语言自我反思,跨 trial 学习;Sentry 是任务进行中实时修复 |
| ExpeL | 开源/论文 | 2023-12 | 251 星 | 从成功和失败轨迹里提炼 insight,放进 prompt;没有失败触发和恢复验证 |
| Dynamic Cheatsheet | 开源/论文 | 2025-04 | 279 星 | 测试时累积 cheatsheet,也是常驻上下文 |
| Agent Workflow Memory | 开源/论文 | 2024-08 | 482 星 | 记的是成功的工作流,不针对失败 |
| AgentDebug(ulab-uiuc) | 开源/论文 | 2025-09 | 108 星 | 事后做失败归因和调试,不做运行时恢复 |
| ag2ai/Agents_Failure_Attribution | 开源 benchmark | 2025-04 | 396 星 | 失败归因的评测集 |
| GEPA | 开源 | 2025-08 | 7311 星 | 离线优化 prompt,不是运行时机制 |
| AgentOps / Langfuse / sentry.io AI Observability | 商业/开源 | 2023 起 | 数千星 / 商业产品 | 只观测、报警,不自动修复也不学习;名字和 sentry.io 撞了 |
| neosigmaai/auto-harness、Tracely-ai | 开源 | 2026 | 500–1000 星 | 离线挖失败、做回归;Tracely 也有 -168 的星数回跳 |
(星数来自 GitHub GraphQL / github 库,2026-11-06)
5. 差异化
论文层面的差异化说得清:「失败知识是条件知识,只在条件满足时暴露」,再加上「只存验证过的恢复」,正好落在 ACE/Reflexion 这类常驻上下文的方法和固定规则的运行时 monitor 之间。集成方式也轻:作为一个外挂层接在 agent loop 旁边,不用改 agent。但这个差异化不是它在 GitHub 上涨星的原因:真实曝光几乎没有,涨星的节奏和 fork 小号的注册时间对得上。
6. 可借鉴
- 论文的思路(按失败触发去检索、只存验证过的恢复)对做 agent harness 的人有用,可以直接做成 Claude Code / Codex 的 hook:检测到循环或连续工具报错时,注入几条匹配的经验。
- 选品方面:刚建库的学术仓库,星和 fork 同涨、fork 账号是批量新号、中间出现大幅回跳,基本可以认定是刷量。光看 suspect 列不够,要现查 fork 账号。
7. 不确定
- stargazer 明细用我们的 token 拉不到(REST 返回 404,GraphQL totalCount=0,对照库 pallets/click 也一样,是权限问题),所以星数里刷的比例没有直接测,只能靠 fork 账号和回跳间接推断。按非刷量期每天约 20 星估算,真实星数大概在 400–500(未核实)。
- 刷量是作者自己买的,还是刷量服务为了「养号」随便挑热门新库刷的,没法判断。不过作者其他几个库也有类似的高星低活跃,前者可能性更大。
- 论文结果没有复现;OpenReview 投稿的评审情况没读到。