Agent工坊

【Agent工坊】AI机器人正在淹没开源仓库:Archestra团队血泪防守实录与可复用工具链

Archestra 一个 $900 bounty issue 被 AI 机器人灌了 253 条评论,同一功能收到 27 个未经测试的 PR。团队成员每周花半天清理 AI 垃圾。这不是个例——你的开源项目可能就是下一个。

一、当 AI 成为开源社区的"垃圾制造机"

2026 年 4 月,VC 背书的开源平台 Archestra(GitHub 3.7k stars)发布了一个带 $900 赏金的 issue,希望社区贡献者帮忙实现"MCP Apps"支持。

前几个小时一切正常——真实开发者在讨论方案、提交尝试。然后 AI 机器人来了。

数据触目惊心:

  • 单个 issue 被灌到 253 条评论,真实讨论被淹没
  • 同一个功能(x.ai provider)收到 27 个 PR,绝大多数未经测试
  • 团队成员每周花半天手动清理 AI 垃圾
  • GitHub 通知变成噪音墙,真实贡献者 @ethanwater、@developerfred 的讨论被深埋

CTO Ildar Iskhakov 在博文中写道:"AI accounts started flooding not just this issue — but the entire repo. Every sloppy comment triggered a notification for every team member."

更让人不安的是,这不是 Archestra 一家的问题。HN 讨论中有人指出:某些开源仓库最近一个月的 commits 中,超过一半是 AI 噪音

对于 AI 创业者来说,这个问题加倍致命:你的开源项目是你的技术名片、招聘漏斗、社区资产。被 AI slop 淹没 = 真实贡献者流失 = 项目慢性死亡。

二、Archestra 的三次防守升级(附工具链)

2.1 第一道防线:信誉机器人 "London-Cat"

Archestra 最早建立了一个叫 London-Cat 的微型 bot,根据 merged PR 数量等信号计算贡献者信誉分。

# London-Cat 核心逻辑简化版

import requests

import os

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

REPO = "archestra-ai/archestra"

def get_contributor_reputation(username: str) -> dict:

    """计算贡献者在目标仓库的信誉分"""

    headers = {"Authorization": f"Bearer {GITHUB_TOKEN}"}

    # 1. 统计 merged PRs

    merged_prs = requests.get(

        f"https://api.github.com/search/issues"

        f"?q=repo:{REPO}+is:pr+author:{username}+is:merged",

        headers=headers

    ).json().get("total_count", 0)

    # 2. 检查是否被标记为 spam

    spam_labels = requests.get(

        f"https://api.github.com/search/issues"

        f"?q=repo:{REPO}+author:{username}+label:spam",

        headers=headers

    ).json().get("total_count", 0)

    # 3. 计算综合分数

    score = min(100, merged_prs * 20 - spam_labels * 50)

    return {

        "username": username,

        "merged_prs": merged_prs,

        "spam_count": spam_labels,

        "reputation_score": max(0, score),

        "trust_level": "high" if score >= 60 else "low" if score < 20 else "medium"

    }

# 在 issue comment webhook 中调用

def on_issue_comment(comment):

    rep = get_contributor_reputation(comment["user"]["login"])

    if rep["trust_level"] == "low" and rep["merged_prs"] == 0:

        # 自动标记为可疑

        label_comment_as_spam(comment["id"])

        post_warning(comment["issue_url"],

                     f"⚠️ @{comment['user']['login']} 信誉分 {rep['reputation_score']},"

                     f"此评论已被标记为待审核。")

效果评估: London-Cat 帮助团队快速识别"谁是谁",但并不能阻止 spam——bot 不在乎被标记,它们只是继续灌。

⚠️ 踩坑1:单纯的信誉系统在 AI spam 面前是纸老虎。AI bot 不会因为被打低分就停止——它们没有羞耻心。信誉系统只对真实人类有效。

2.2 第二道防线:AI Sheriff(用 AI 打 AI)

Archestra 接着构建了"AI Sheriff"——一个用 AI 检测 AI 内容的机器人。

# GitHub Actions workflow: AI Sheriff

name: AI Spam Detector

on:

  issues:

    types: [opened, edited]

  pull_request:

    types: [opened, edited]

  issue_comment:

    types: [created, edited]

jobs:

  detect-spam:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

      - name: Analyze content with AI

        id: analyze

        uses: archestra-ai/spam-detector-action@v1

        with:

          openai-key: ${{ secrets.OPENAI_API_KEY }}

          content: ${{ github.event.comment.body || github.event.issue.body }}

          thresholds: |

            spam_probability: 0.85

            ai_generated_probability: 0.90

            min_account_age_days: 7

      - name: Auto-close if spam

        if: steps.analyze.outputs.is_spam == 'true'

        uses: actions/github-script@v7

        with:

          script: |

            const reason = `${{ steps.analyze.outputs.reason }}`;

            const spamLabel = '🤖 AI-generated';

            if (context.eventName === 'pull_request') {

              await github.rest.issues.createComment({

                ...context.repo,

                issue_number: context.issue.number,

                body: `⚠️ 此 PR 被 AI Sheriff 检测为疑似 AI 生成内容。\n原因:${reason}\n\n如果你是真实开发者,请回复 "!human" 触发人工审核。`

              });

              await github.rest.pulls.update({

                ...context.repo,

                pull_number: context.issue.number,

                state: 'closed'

              });

            }

            await github.rest.issues.addLabels({

              ...context.repo,

              issue_number: context.issue.number,

              labels: [spamLabel]

            });

效果评估: 这个方案更激进,但也更容易误伤——Archestra 承认 AI Sheriff 关闭了一些合法 PR 🤦。

⚠️ 踩坑2:用 AI 检测 AI 内容存在根本性的军备竞赛问题。GPT-4 检测 GPT-4 生成内容的准确率不超过 70%。更糟的是,检测模型有偏见——非英语母语者的内容更容易被误判为 AI 生成。

2.3 第三道防线:贡献者入门白名单(核选项)

前两道防线失败后,Archestra 祭出了"核选项":

核心机制: 利用 GitHub 的"Limit to prior contributors"设置 + 自定义 onboarding CI 脚本。

# onboarding.py — Archestra 贡献者白名单系统的简化实现

import hashlib

import hmac

import json

import os

import time

import requests

from flask import Flask, request, jsonify

app = Flask(__name__)

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

WEBHOOK_SECRET = os.environ["WEBHOOK_SECRET"]

REPO = "archestra-ai/archestra"

# 使用 GitHub 的 co-author 机制将用户标记为"prior contributor"

@app.route("/onboard", methods=["POST"])

def onboard_contributor():

    """五步入门流程,完成后自动创建一个 co-authored commit"""

    data = request.json

    github_username = data.get("github_username")

    if not github_username:

        return jsonify({"error": "Missing github_username"}), 400

    # 步骤1-4:CAPTCHA + 行为准则确认 + 文档阅读 + 小测验

    # (此处省略前端流程,假设已通过)

    # 步骤5:创建 co-authored commit 将用户标记为 prior contributor

    result = create_onboarding_commit(github_username)

    return jsonify({

        "status": "onboarded",

        "commit_sha": result.get("sha"),

        "message": "你现在可以创建 issues、PR 和评论了!"

    })

def create_onboarding_commit(username: str) -> dict:

    """利用 GitHub co-author 机制创建白名单 commit"""

    # 1. 获取当前 CONTRIBUTORS.md 的 SHA

    headers = {

        "Authorization": f"Bearer {GITHUB_TOKEN}",

        "Accept": "application/vnd.github+json"

    }

    file_resp = requests.get(

        f"https://api.github.com/repos/{REPO}/contents/CONTRIBUTORS.md",

        headers=headers

    ).json()

    # 2. 在 CONTRIBUTORS.md 末尾追加用户名(实际操作用无害的微小改动)

    current_content = requests.get(file_resp["download_url"]).text

    new_content = current_content + f"\n- @{username} (onboarded {time.strftime('%Y-%m-%d')})"

    # 3. 创建 commit,使用 co-author 将用户标记为 contributor

    commit_payload = {

        "message": f"docs: onboard @{username} as contributor\n\n"

                   f"Co-authored-by: {username} <{username}@users.noreply.github.com>",

        "content": base64_encode(new_content),

        "sha": file_resp["sha"],

        "branch": "main",

        "committer": {

            "name": "Onboarding Bot",

            "email": "bot@archestra.ai"

        },

        "author": {

            "name": username,

            "email": f"{username}@users.noreply.github.com"

        }

    }

    resp = requests.put(

        f"https://api.github.com/repos/{REPO}/contents/CONTRIBUTORS.md",

        headers=headers,

        json=commit_payload

    )

    return resp.json()

def base64_encode(content: str) -> str:

    import base64

    return base64.b64encode(content.encode()).decode()

if __name__ == "__main__":

    app.run(port=5000)

关键机制解读:

GitHub 的"Limit to prior contributors"选项的判断依据是:该 GitHub 账户是否有 commit 被合并到默认分支(main/master)的提交历史中

Archestra 的巧妙之处:让新贡献者通过 CAPTCHA 验证后,自动创建一个以该用户为 co-author 的微小 commit。此后该用户就是"prior contributor"了,可以正常创建 issue/PR/评论。

效果: 上线后成功拦截了 至少 500 个 AI bot 账户——bot 不会过 CAPTCHA,也不会点击行为准则确认。

⚠️ 踩坑3(安全风险):HN 用户 @captn3m0 在讨论中指出——GitHub 文档警告,成为 prior contributor 后,该用户的 fork PR 将绕过审批要求而自动运行 CI。这意味着如果 bot 绕过了白名单(例如用人肉打码平台),就有可能推送恶意代码并获得自动 CI 执行权限。

> 缓解方案: 始终在 CI 中对 fork PR 进行额外审查,不依赖 GitHub 的"prior contributor"状态来做安全决策。

⚠️ 踩坑4(噪音转移):HN 用户 @optionalsquid 发现了一个讽刺的现象——Archestra 仓库最近一个月的 commits 中,超过一半(369/3521)是 onboarding 产生的"噪音 commits"。垃圾从 issues 转移到了 commits 历史。虽然 commits 不会触发通知,但 git blame 被污染了。

三、社区正在涌现的防御工具(2026年5月)

除了 Archestra 的自研方案,社区也在快速响应这个问题:

工具原理适用场景状态
Git --author flag在 CI 中检查 PR 作者的 commit 历史所有 GitHub 仓库原生支持
GitHub Interaction Limits临时限制新账户互动短期 spam 攻击内置但有时效
terminal-guardian-mcpMCP 服务器,沙箱化终端访问+风险分析Claude Code 等 Agent 工具新项目(2 stars)
Reputation Bot (London-Cat)基于 merged PRs 计算信誉分有 bounty 的活跃仓库原型阶段

3.1 利用 Git `--author` flag 做第一轮过滤

HN 讨论中反复出现的一个简单方案——在 CI 中用 git log --author 检查:

#!/bin/bash

# .github/scripts/check-first-timer.sh

# PR 创建时运行,检查作者是否在仓库历史中

AUTHOR_EMAIL="$1"

MIN_COMMITS=2

EXEMPT_LABEL="legitimate-newcomer"

# 例外:手动标记的合法新人

if gh pr view --json labels | grep -q "$EXEMPT_LABEL"; then

    echo "✅ 已标记为合法新人,跳过检查"

    exit 0

fi

# 检查该 email 在仓库历史中的 commit 数量

COMMIT_COUNT=$(git log --all --author="$AUTHOR_EMAIL" --oneline | wc -l)

if [ "$COMMIT_COUNT" -lt "$MIN_COMMITS" ]; then

    echo "⚠️ 警告:$AUTHOR_EMAIL 在仓库中仅有 $COMMIT_COUNT 个 commits"

    echo " 此 PR 被自动标记为待审核"

    gh pr edit --add-label "needs-review"

    gh pr comment --body "🤖 自动检测:你在本仓库的 commit 数量不足 $MIN_COMMITS。\n

维护者将在 24 小时内审核。为加快流程,请在 PR 描述中说明你的实现思路。"

else

    echo "✅ $AUTHOR_EMAIL 有 $COMMIT_COUNT 个历史 commits,通过检查"

fi

四、AI 创业者的防守清单

如果你是维护开源项目的 AI 创业者,以下是分阶段的防守策略:

阶段1:基础防御(今天就可以做)

# 1. 开启 GitHub 仓库的互动限制

# Settings → Moderation → Interaction limits →

# "Limit to prior contributors" (临时模式)

# 2. 在 CI 中添加作者历史检查

# 将上面的 check-first-timer.sh 加入 PR workflow

# 3. 设置 issue template 要求贡献者描述实现思路

# .github/ISSUE_TEMPLATE/feature_request.md 中添加:

# "请用至少50字描述你的实现思路(AI生成的泛泛而谈将被关闭)"

阶段2:工具化防御(本周可以部署)

  • AI 内容检测 Action:类似 Archestra 的 AI Sheriff,但调低阈值避免误伤
  • 信誉系统:基于 merged PRs 的轻量评分
  • 速率限制:限制单个账户每天最多创建 3 个 issue / 2 个 PR

阶段3:白名单系统(适合活跃社区)

  • 贡献者入门流程(CAPTCHA + 行为准则 + 文档阅读)
  • co-author commit 机制自动授予 prior contributor 状态
  • 定期审计 onboarding commits,清理长时间无活跃的权限

五、常见踩坑问题

Q1: 用 AI 检测 AI,会不会误伤真实开发者?

会。 Archestra 的 AI Sheriff 就关掉过合法 PR。建议:

  • 检测阈值设高(>0.9 概率才自动关闭),低概率只标记
  • 提供申诉机制(如回复 !human@maintainer 触发人工审核)
  • 对已知社区成员加白名单

Q2: GitHub 为什么不直接解决这个问题?

HN 讨论中很多人问了同样的问题。可能的原因:

  • GitHub 的贡献者增长指标("每秒钟新增一个开发者")依赖 AI 贡献数据
  • 区分 AI 和人类的准确率还不够高
  • 误伤真实新人的代价太大

但在微软/OpenAI 和 GitHub 同属一个生态的背景下,社区对此的耐心正在耗尽。

Q3: 这些防御措施对小型仓库也适用吗?

更要防。 小仓库的问题不是 spam 量,而是人力不足——小团队没有半天/周来清理。建议:

  • 小型项目直接开启"Limit to prior contributors"
  • 设置 Discord/论坛作为讨论入口,GitHub issues 仅限核心开发
  • 将 bounty 改为定向邀请而非公开悬赏

Q4: 白名单 onboarding commit 污染 git 历史怎么办?

这是目前方案最大的副作用。Archestra 已经有超过 10% 的 commits 是 onboarding 噪音。缓解方案:

  • 使用独立分支存放 onboarding commits,定期 squash
  • 或者使用 GitHub App 权限而非 co-author commit——用 App 将用户加入团队(需要组织账号)
  • 长期来看,希望 GitHub 提供原生的"verified contributor"机制

六、总结

AI 机器人正在从根本上改变开源协作的信任模型。以前你可以假设来提 PR 的都是善意的开发者,现在你必须假设第一个 PR 可能是无人审查的 AI 生成代码

Archestra 的三道防线是一个逐步升级的实战路径:

  1. 信誉系统(了解"谁是谁")
  2. AI 检测(用 AI 打 AI,但小心误伤)
  3. 白名单门槛(放弃开放,换取质量)

对于 AI 创业者来说,保护你的开源项目就是保护你的技术品牌。一个被 AI slop 淹没的仓库不会吸引真实贡献者,也不会让潜在客户相信你的技术能力。

立即行动: 花 30 分钟在你最重要的仓库里部署阶段1防御(interaction limits + CI 作者检查)。这是最低成本、最高收益的投资。


*本文参考:Archestra 团队博文《Let's talk about AI slop》(2026.4.17)、HN 讨论(234 points / 101 comments)、GitHub 社区讨论。*

#AI创业 #开源维护 #AI Agent #防spam #GitHub

本文由AI辅助创作,经人工审核编辑发布