在2026年5月28日，我做了一件大多数开发者都认为疯狂的事：我将自己的GitHub账户完全授权给一个自主AI Agent，并让它在没有任何人类监督和审核的情况下，自主去搜寻开源社区的悬赏任务（Bounties）。
我的核心目的很简单：验证当前的AI Agent究竟能否真正为开源社区做出有价值的贡献，还是仅仅在制造无意义的垃圾代码？在经历连续96小时（4天）的不间断自主运行后，我获得了一手硬核数据。其结果比我预期的要微妙得多。
系统架构与技术栈
这个名为 ZKA (Zero Knowledge Agent) 的系统并非简单的自动化脚本，而是一个全自动的闭环系统。它的工作流程包括：每30分钟扫描一次GitHub的悬赏任务；评估任务的真实性、难度和竞争激烈程度；克隆仓库并深度分析代码库；编写修复代码并运行相关测试；提交附带专业描述的Pull Request（PR）；监控反馈并与审查机器人（如CodeRabbit、Cubic）互动；自动在Dev.to上发布技术文章以赚取被动收入。
该系统的底层技术栈非常实用且精简：使用GitHub CLI (gh) 进行API交互；Python负责整体调度和代码分析；Hermes Agent作为自托管的AI Agent骨干框架；Cron job负责每30分钟触发一次循环；通过Dev.to API实现内容自动发布。
其核心循环逻辑伪代码如下：
while True:
bounties = search_bounties()
for bounty in bounties:
if is_legitimate(bounty) and is_low_competition(bounty):
clone_repo(bounty.repo)
fix = analyze_and_fix(bounty.issue)
if fix.passes_tests():
submit_pr(bounty, fix)
monitor_existing_prs()
publish_articles()
sleep(30 * 60)96小时实战硬核数据
以下是系统连续运行4天后的原始数据。我们可以清晰地看到前两天与后两天之间的巨大性能跃升：
| 指标 (Metric) | 第1-2天 | 第3-4天 | 总计 |
|---|---|---|---|
| 扫描悬赏数 | 200+ | 500+ | 700+ |
| 合规悬赏数 | 12 | 45 | 57 |
| 提交PR数 | 5 | 235 | 240 |
| 合并PR数 | 0 | 72 | 72 |
| 拒绝PR数 | 3 | 87 | 90 |
| 开启中PR数 | 2 | 86 | 88 |
| 垃圾仓库数 | 2 | 14 | 16 |
| 发布文章数 | 8 | 24 | 32 |
| 总收益 | $0 | $500-800 | $500-800 |
策略转型：从“广撒网”到“信誉库”
从数据中可以看出，第1-2天到第3-4天发生了戏剧性的跃升。前两天的尝试极为惨淡，Agent几乎颗粒无收。这是因为最初的 Agent 只是盲目地通过 gh search issues "bounty" 搜索并广撒网式地往任何随机仓库提交PR。这些仓库很多是低质量甚至带有欺诈性质的。在第三天，我及时调整了策略，让其专注于高信誉、竞争度低的优质项目，才使得合并率和收益迎来了爆发式增长。
【AgentUpdate 深度解析】本次实验展示了 AI Agent 在实际软件工程（Software Engineering）场景中的惊人潜力，同时也暴露了当前“AI 垃圾代码膨胀”的隐忧。相比于 Devin 等重型、高成本的商业云端方案，作者采用的自托管 Hermes Agent 结合轻量级 CLI 脚本，展现了一种极具性价比的“轻量级自主黑客（Micro-Agent）”范式。然而，72 个 PR 被合并的同时伴随着 90 个 PR 被拒绝，表明 AI 在缺乏全局上下文时仍会给开源维护者带来极大的审阅负担。未来，AI Agent 生态的演进不仅取决于大模型代码生成能力的提升，更取决于“信誉过滤机制”和“自动化沙箱测试”的完善。只有建立起 Agent 与代码仓库之间双向信任的协议（如 MCP 协议），自主编程 Agent 才能真正走向规模化，而不是沦为开源社区的“PR 垃圾制造机”。
