GitHub 上有一类仓库挂着 bounty 悬赏的名头让 AI agent 或人工开发者去提 issue、写 PR最后既不合并也不给钱。这类仓库最近被不少人称为蜜罐专门用来收割免费劳动。如果你正在跑 AI agent 自动接 GitHub 悬赏任务或者刚入坑开源想靠 bounty 赚点收入建议先看完这篇再动手。这类问题在人工开发者时代就有但 AI agent 大量出现后被放大了。原因很简单agent 可以低成本、大批量地生成 PR而可疑仓库正好缺这种免费产出。人工开发者看到条件不合理会离开很多 agent 不会自动辨别。结果就是一些仓库靠着一个“bounty”标签就能拿到一堆代码、测试、文档和产品反馈然后不验收、不合并、不支付。下面按实际落地顺序拆一遍先说清楚这类仓库的典型特征再给出一套动手前可以执行的检查流程然后聊 AI agent 接单时怎么加防护规则最后列出更靠谱的悬赏仓库应该具备什么条件。1. 先搞清楚GitHub 悬赏仓库和“AI agent 白嫖”到底是什么1.1 悬赏仓库为什么值得警惕GitHub 悬赏仓库简单说就是项目维护者在 issue 里标出一些任务并承诺完成后给奖励。奖励可能是现金、代币、礼品卡也可能是项目内贡献者身份。正常的 bounty 流程应该有明确的任务描述、验收标准、提交方式、奖励金额和发放时间。如果这些信息都不存在只写一句“完成这个 issue 有奖励”那就要小心。一个必须面对的事实是GitHub 本身并不审核 bounty 的真伪。任何人都可以建仓库、开 issue、挂标签。没有收钱、没有合同、没有第三方担保。即使你确实提交了 PR对方也可以不合并、不评论、不兑现报酬。如果你通过 AI agent 自动提交可能连“对方是否回复”都不会注意到。所以这类仓库看上去是悬赏任务池实际上更像是蜜罐。所谓蜜罐不是指它会攻击你或盗取凭证而是指它用“有奖励、有任务、有挑战”作为诱饵让你主动把劳动成果交出去。对于 AI agent 来说这种诱饵尤其有效因为 agent 不会像人一样先观察一个项目的口碑和发薪记录。1.2 AI 代理参与后问题被放大了AI agent 在 GitHub 上接 bounty 任务时通常的工作流是这样的先扫描仓库里的 open issue判断哪些能处理然后生成代码、提交 PR。这套流程对常规开源项目问题不大但遇到蜜罐型仓库时会非常危险。原因是 agent 的产出成本极低。人工开发者写一个 PR 可能花几个小时agent 可能几分钟就完成。可疑仓库只要能发布足够多的任务就会收到大量 PR。维护者完全不参与不开 review不合并也不发奖励唯一做的事情就是等 agent 把成品送上门。如果 agent 还配置了自动批量处理情况更糟。一个看起来普通的 issue 列表可能让 agent 同时提交几十个 PR。等你自己发现异常时劳动成果已经被复制或利用了。更麻烦的是很多 agent 不会主动验证“这个仓库过去是否真的支付过奖励”只会按照任务描述完成动作。注意这里不是让你放弃所有 bounty而是让你在让 agent 动手之前先增加一道判断环节。判断越具体被白嫖的概率越低。2. 这种仓库的常见特征更像蜜罐而不是协作项目2.1 从仓库活跃度看长期维护意图看一个 bounty 仓库是否值得参与第一件事不是看任务多不多而是看仓库本身的维护状态。一个真正常见的开源项目会有持续提交、版本发布、issue 讨论和 PR review。它的代码历史有连续性不会出现“一周前突然冒出一堆 bounty”的情况。可疑仓库通常有几个特征。代码提交非常少但 issue 不断新增某个时间段集中提交过几笔之后就长期静默README 写得很漂亮但代码结构和测试完全没跟上。你也可能在提交历史里看到只有最初的初始化文件之后几乎没有实质改动。这种情况下仓库维护者大概率不是想认真做项目而是想靠 bounty 标签吸引免费劳动。还要注意仓库的 Issue 和 PR 数量关系。如果一个仓库有几十个 open issue但 closed issue 几乎没有PR 也基本没有那说明任务几乎没有被真正处理过。这不一定代表恶意但至少说明维护者没有形成有效协作流程。没有流程就没有兑现奖励的基础。2.2 从 issue 和 PR 状态看“悬赏”是否兑现打开 issue 列表先看已关闭的 issue。如果大量带 bounty 标签的 issue 被关闭但没有任何关联 PR说明任务最后并没有被实际完成和接受。如果反过来很多外部贡献者提交了 PR但 PR 长期处于 open 状态没有 review、没有comment那更值得警惕。PR 合并率是一个很好的判断指标。正常项目会有一定比例的 PR 被合并哪怕不是全部但至少会有讨论和反馈。如果一个仓库的 PR 列表里全是“作者自删”“abandoned”或者干脆几个月无人响应那基本可以断定这个仓库不是在认真维护。还有一点容易被忽略看维护者会不会在 issue 和 PR 下面留言。真正的维护者会解释需求、回答疑问、给出修改建议。蜜罐型仓库的维护者通常只在开仓时说话之后就像消失了一样。你可以随手打开几个 PR 看看评论数量如果绝大多数都是 0 条评论这一点就很明显了。检查项正常项目可疑项目提交历史有持续维护版本发布正常提交稀少或结构混乱issue 处理几天到几周内有维护者响应长期无人回复PR 合并有相对稳定的合并率大量 PR 被搁置或关闭bounty 说明有金额、验收、发放方式只有“有奖励”三个字3. 动手之前先做一轮客观检查3.1 用 GitHub 页面信息做初步判断在让 agent 接任务之前先打开仓库主页把 README、CONTRIBUTING、LICENSE 这三个文件过一遍。README 里有没有明确描述 bounty 流程有没有指向具体支付规则的外部链接CONTRIBUTING 里有没有告诉贡献者如何提交 PR、如何测试、如何申请奖励LICENSE 是否完整如果这些文件缺失或者写了等于没写那就要谨慎。还有一个很容易被忽视的细节很多可疑仓库的历史很短。你可以在仓库页面看创建时间、最近更新时间、star 增长曲线。如果一个仓库创建没多久突然出现一堆 bounty issue并且 README 写了大量鼓励外部贡献的内容这通常是“用任务钓贡献”的典型包装。如果你是通过镜像站或加速环境看到这个仓库的信息可能不同步。页面上显示的 issue 状态、PR 数量、commit 时间不一定是当前最新状态。最稳妥的方法是先记录好仓库名和 owner回到官网页面再次核对。不要因为镜像站看着方便就直接提交。3.2 用命令行和 API 查关键数据本地安装了 GitHub CLI 的话可以用命令快速查看仓库信息。不需要登录也可以看公开仓库但登录后能查到的范围更大。gh repo view owner/repo gh issue list --repo owner/repo --state all --limit 100 gh pr list --repo owner/repo --state all --limit 100 gh pr view 12 --repo owner/repo这几个命令分别用来查看仓库基本信息、issue 列表、PR 列表和单个 PR 详情。重点观察带 bounty 标签的 issue 有多少被关闭已关闭 issue 是否有对应的 PRPR 的评论和 review 情况PR 从打开到合并或关闭的时间间隔。如果本地没有 gh也可以用普通 API 请求查看仓库元数据curl -s https://api.github.com/repos/owner/repo | head -n 80但要注意未认证的 API 有访问频率限制只适合查少量仓库。不要写脚本去循环扫描大量项目这样既容易触发 GitHub 限制也没有必要。你只需要针对真正想接任务的仓库做验证而不是把所有仓库都跑一遍。3.3 分析 owner 和其他贡献者的行为仓库所有者是最需要观察的对象。打开 owner 的 profile看看他有没有大量提交记录有没有参与其他项目。一个真正常年维护开源项目的 owner通常会在多个仓库留下足迹。反过来如果 owner 只有这一个仓库并且这个仓库的主要活动就是发 bounty issue那怀疑是合理的。还要看已有贡献者的情况。找不到任何历史贡献者或者历史贡献者的 PR 全部没有合并这两种情况都很危险。如果你能从 issue 评论里看到老贡献者提到“完成了任务但没有奖励”那就基本不需要再犹豫了。比较直接的方法是看仓库的 fork 数和 star 数是否匹配。一个 star 数量很高但 fork 很少的 bounty 仓库可能只是宣传做得好不代表有真实协作。你还可以看仓库的 Discussions 区如果根本没有讨论版块或者版块里没有任何人提问说明这个项目可能只是单方面输出任务并没有形成社区互动。4. 让 AI Agent 接悬赏任务时加好防护规则4.1 不要让 agent 无脑“见 issue 就上”现在很多 AI agent 框架允许自定义任务判断逻辑。最简单的做法就是在提示词里加上 bounty 判断规则。比如只有明确包含 bounty 金额、验收标准和支付方式的 issue 才处理。只有过去存在已合并外部 PR 的仓库才能接。README / CONTRIBUTING / LICENSE 存在明显缺失的仓库不接。仓库最近三个月没有任何维护者评论的不接。如果 agent 框架支持外部工具还可以写一个简单的判断脚本。先读取仓库元数据检查上述条件全部通过后再让 agent 生成代码。整个过程没有必要跑大批量先测一条任务观察 agent 是否真的按规则执行再逐步放开。这里最容易踩的坑是为了“效率”让 agent 同时处理几十个仓库。一旦有一个仓库是蜜罐你可能会在短时间内提交大量 PR而且这些 PR 都不会有结果。先单任务验证能避免很多无谓的资源浪费。4.2 用文件列表、任务描述和支付信息做过滤在 agent 的任务规则里要强制检查仓库根目录的文件结构。一个正经项目通常有 src、tests、docs、package 或 requirements 等基础文件。如果仓库里只有 README 和一堆 markdown 任务说明没有实际代码结构那这里更像一个任务发布板而不是可协作的项目。任务描述同样是关键。如果 issue 里只有“完成功能”四个字没有预期行为、输入输出、测试用例或参考实现就不要让 agent 去猜。因为 agent 生成的内容越接近需求你的劳动价值越高但对不确定的验收标准你几乎无法证明自己是对的。支付信息也需要纳入过滤规则。真实 bounty 通常会说清楚奖励金额、支付方式、发放周期、是否需要签署贡献协议。如果这些都没有哪怕 agent 已经生成了代码也要先停一下。没有明确收益的任务最多只能当成普通开源贡献来做不值得投入额外精力。4.3 记录任务状态和产出留好证据链无论你使用 agent 还是手动参与都要养成记录习惯。任务原文、仓库状态、提交时间、PR 链接、commit hash 都要保存。这样做不是为了追责而是为了在后期排查问题时能快速定位到“当时我做了什么、提交到了哪里”。我建议让 agent 在每次提交前输出一段结构化日志内容包括仓库名、任务 ID、验收标准、预计产出、输入文件。这样如果后面出现争议你能清楚展示自己完成了什么。如果最终要不回奖励至少这份日志可以帮你总结出“以后哪些仓库不能碰”。还需要注意不要在 issue 里公开攻击项目方也不要因为一次没拿到奖励就把仓库所有人骂一遍。GitHub 是公开环境你留下的评论会一直被看到。理性说明情况保留好自己的分支和 fork才是更安全的做法。提醒如果 agent 已经提交了大量 PR而你要一个一个检查状态先不要急着全量处理。按 PR 创建时间倒序看最近几条能很快判断这个仓库是否值得继续。5. 哪些悬赏仓库更靠谱参考这些判断标准5.1 资金或激励方式是核心靠谱的 bounty 仓库一定不会把“奖励”停留在口头。它会在 README 或独立页面上写清楚奖励是什么、通过什么平台发放、多久发一次、由谁审核。常见的模式包括 GitHub Sponsors、OpenCollective、Gitcoin 等第三方平台这些平台有财务记录相对可信。如果仓库只是给自己挂了一个“bounty”标签却没有任何外部链接也没有说明奖励来源那它很可能没有预算。没有预算的悬赏本质上不是悬赏而是一个普通任务池。你把时间投进去最多只能算贡献不能指望经济回报。我一般会先搜索项目的 funding 信息。比如在 README 里找“Sponsor”按钮或者查看仓库主页右侧的 About 区域。如果找不到任何资金入口我就会把它的 bounty 优先级降得很低。5.2 仓库治理公开透明好的 bounty 项目维护者会主动参与协作。你可以在仓库里看到 issue 被贴上标签PR 被分配 reviewerbug 和 feature 有明确分类。一些成熟项目还会要求贡献者签署 CLA或者在 CONTRIBUTING 里写清楚任务验收流程。判断仓库治理是否透明不需要很复杂。看最近 10 个关闭的 issue 就可以了。有没有维护者回复关闭原因是“completed”还是“stale”有没有关联 PR如果 10 个 issue 里有 8 个是无人回应后自动关闭的那就说明这个仓库几乎没有人工维护。另外一个细节是靠谱项目往往会为 bounty 任务单独建一个页面或文档说明任务的背景、难度、目标用户和验收方式。如果一个 bounty issue 连必要的背景都没有那就不要指望会有完整验收。判断维度靠谱项目高风险项目支付说明有平台或具体金额只有口头承诺维护者参与有评论、review几乎不说话贡献者历史能看到合入记录PR 长期堆积治理文档有 CONTRIBUTING、CLA没有或不可用第三方背书有公开记录或平台支持无任何背书5.3 从社区口碑和历史记录做交叉验证不要只看仓库页面的自夸内容。你可以在外部搜索项目名加上“bounty”“reward”“paid”这类关键词看看有没有第三方讨论。一个真实可靠的 bounty 项目通常会有贡献者在博客、论坛或社交平台提到过自己的参与体验。如果完全搜不到任何历史反馈只能说明这个项目的 bounty 机制还没有被验证过。GitHub 仓库的 star 数也不是可靠指标。某些高 star 仓库不一定是真人贡献很多是大量 fork 和自动化行为造成的假象。我一般会看 fork 数量和 fork 来源如果 fork 里有大量空仓库或看起来像自动生成的账号那就要降低信任。当然口碑也要谨慎理解。不是每一条负面评价都属实也不是每个项目都适合所有贡献者。最好的交叉验证方式是找几个真实参与的贡献者看他们的 PR 是否被合并看他们是否在 issue 评论区得到过反馈。这些信息比任何宣传词汇都有说服力。6. 如果已经踩坑怎么排查和止损6.1 先确认任务是否存在、PR 是否被合入如果你已经让 agent 提交了 PR但迟迟没有反馈第一步不是怀疑自己而是先回到仓库里确认状态。打开你的 PR 链接看看它是不是还处于 open 状态有没有评论有没有被关闭。再打开原始 issue看看是否被人关闭或标记为完成。如果 PR 已经被合并但你仍然没有收到奖励这时可以考虑通过 issue 或邮件联系 owner。不过要注意GitHub 上并没有官方机制帮你追讨 bounty所以尽量不要抱太大期望。更多时候你只能确认“劳动成果是不是已经被使用”。如果 PR 被关闭且没有评论可以查看关闭时间。如果关闭时间发生在你提交后很短时间内那大概率是维护者主动忽略或拒绝。如果多次尝试联系都没有回复那就该止损了不要再继续给这个仓库提交更多任务。6.2 再确认是技术问题还是仓库策略问题提交了大量 PR 却没有回应未必全是仓库的锅。先检查一下自己的代码质量。如果 PR 没有测试、没有通过 CI、不符合 CONTRIBUTING 规范被关闭是很正常的。这种情况下问题出在你这边而不是仓库。但如果你发现仓库里几乎所有的外部 PR 都没有被合并而 issue 却还在持续开放那问题就明显指向仓库策略了。你可以把同一仓库其他贡献者的 PR 状态拉出来对比看大家是不是都在等待。如果大家都没有得到回复说明这个仓库根本不打算处理外部贡献。判断标准很简单看合并率。正常仓库的外部 PR 合并率会有一个相对合理的范围不一定是 100%但至少有稳定的成功记录。如果一个仓库的外部 PR 合并率接近 0那不管它写多少 bounty 宣传都不值得继续投入。6.3 后续接单前把检查流程固化下来踩坑之后最值得做的事不是找别人吐槽而是把检查流程固化下来。你可以写一个本地 checklist也可以做成一个脚本放在 agent 启动前执行。每次评估仓库时依次检查 README、CONTRIBUTING、LICENSE、最近提交、issue 关闭率、PR 合并率、bounty 支付说明。全部通过后才允许 agent 接入。我自己的习惯是把 GitHub bounty 当成普通开源贡献来看而不是当成短期收入来源。如果一个项目连最基本的 README、贡献指南和 issue 处理流程都整理不清楚那后面的奖励承诺更不值得信任。让 AI agent 去接任务之前先给它配好判断规则再让它动手能少踩很多坑。如果你刚开始跑 AI agent 接任务建议先把范围限制在自己熟悉的、已经有一定口碑的开源项目上。等积累了一些凭经验判断项目的触感再逐步扩大到陌生仓库风险会小很多。本质上GitHub 上的 bounty 机会一直存在但能长期兑现承诺的项目永远比表面上看起来的更少。