让AI Agent自动接Issue、写代码、上线：我用200行代码搭了一个全自动开发流水线

你有没有想过这样一个场景：

GitHub上有人提了一个Issue——"希望增加深色模式"。5分钟后，一个PR自动创建了，代码写好了，测试跑过了，CI绿了。你作为维护者，只需要点一下Merge。

再激进一点：连Merge都不用你点。Agent评估需求合理性、自动实现、自动验证、自动部署。整个项目变成一台"需求进、功能出"的机器。

这不是科幻。2026年，这件事已经有人在做了，而且做得比你想象的成熟。

从"人写代码"到"人审代码"

传统开发流程：

用户提Issue → 维护者看到 → 排期 → 开发 → 自测 → Code Review → 合并 → 部署

一个普通的"加个按钮"需求，这个链条走完可能要3天到3周。

AI Agent驱动的流程：

用户提Issue → Agent接收 → 评估可行性 → 自动实现 → 跑测试 → 提PR → 人审/自动合并 → 自动部署

同样的需求，从Issue到PR，5分钟。

关键转变：开发者的角色从"写代码的人"变成了"审代码的人"。 你的价值不再是能不能写出这个功能，而是能不能判断这个功能该不该做、做得对不对。

已经跑起来的开源方案

这个想法不是我一个人的灵光一现。开源社区已经有一批成熟的工具：

OpenHands（原OpenDevin） 是目前最完整的方案。它专门做了一个叫 openhands-resolver 的模块，直接对接GitHub Issues。有人提Issue，它自动fork、开分支、写代码、提PR。SWE-bench上的表现已经接近人类开发者水平。

GitHub Copilot Coding Agent 是官方下场。你在Issue里@copilot，它就开始干活。背后跑的是Codex，直接在GitHub的沙箱环境里执行。优势是和GitHub生态无缝集成，劣势是目前只对Enterprise用户开放。

SWE-agent 来自普林斯顿，学术底子最扎实。它的思路是把代码仓库当作一个"环境"，让Agent像玩游戏一样在里面探索、修改、验证。

还有 Cline（VS Code插件形态）、Sweep（专注PR自动生成）、CodeRabbit（专注Review）等等。生态已经相当繁荣。

核心架构：200行代码的最小实现

说了这么多，不如直接看代码。下面是一个用Node.js + GitHub Webhooks实现的最小可用Agent流水线，核心逻辑只有200行左右：

// agent-pipeline.ts — 核心调度器
import { Octokit } from "@octokit/rest";
import Anthropic from "@anthropic-ai/sdk";

const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });
const anthropic = new Anthropic();

// Step 1: 需求评估 — 用LLM判断Issue是否值得自动处理
async function evaluateIssue(issue: {
  title: string;
  body: string;
  labels: string[];
}): Promise<{ shouldProcess: boolean; reason: string; complexity: string }> {
  const response = await anthropic.messages.create({
    model: "claude-sonnet-4-20250514",
    max_tokens: 1024,
    messages: [
      {
        role: "user",
        content: `你是一个项目维护者。评估这个Issue是否适合自动处理。

Issue标题: ${issue.title}
Issue内容: ${issue.body}
标签: ${issue.labels.join(", ")}

评估标准:
1. 需求是否清晰明确（模糊需求不处理）
2. 是否是纯代码变更（涉及基础设施、安全的不处理）
3. 预估复杂度（simple/medium/complex，只处理simple和medium）

返回JSON: { "shouldProcess": boolean, "reason": string, "complexity": "simple"|"medium"|"complex" }`,
      },
    ],
  });

  return JSON.parse(
    response.content[0].type === "text" ? response.content[0].text : ""
  );
}

这是第一层过滤。Agent不是什么Issue都接——模糊的、复杂的、涉及安全的，统统打回去。需求过滤是整个系统的安全阀。

// Step 2: 代码生成 — 读取仓库上下文，让Agent写代码
async function generateFix(
  owner: string,
  repo: string,
  issue: { title: string; body: string }
): Promise<{ files: Array<{ path: string; content: string }> }> {
  // 读取仓库结构和关键文件
  const tree = await octokit.git.getTree({
    owner, repo,
    tree_sha: "HEAD",
    recursive: "true",
  });

  const relevantFiles = tree.data.tree
    .filter((f) => f.path?.match(/\.(ts|js|py)$/) && f.type === "blob")
    .slice(0, 20); // 限制上下文大小

  const fileContents = await Promise.all(
    relevantFiles.map(async (f) => {
      const content = await octokit.repos.getContent({
        owner, repo, path: f.path!,
      });
      return {
        path: f.path,
        content: Buffer.from(
          (content.data as any).content, "base64"
        ).toString(),
      };
    })
  );

  const response = await anthropic.messages.create({
    model: "claude-sonnet-4-20250514",
    max_tokens: 4096,
    messages: [
      {
        role: "user",
        content: `根据以下Issue和代码库，生成修复代码。

Issue: ${issue.title}
${issue.body}

代码库文件:
${fileContents.map((f) => `--- ${f.path} ---\n${f.content}`).join("\n\n")}

返回JSON: { "files": [{ "path": "文件路径", "content": "完整文件内容" }] }
只修改必要的文件，不要过度工程化。`,
      },
    ],
  });

  return JSON.parse(
    response.content[0].type === "text" ? response.content[0].text : ""
  );
}

// Step 3: 创建PR — 自动开分支、提交、创建Pull Request
async function createPullRequest(
  owner: string,
  repo: string,
  issueNumber: number,
  files: Array<{ path: string; content: string }>
) {
  // 获取默认分支的最新commit
  const ref = await octokit.git.getRef({
    owner, repo, ref: "heads/main",
  });
  const baseSha = ref.data.object.sha;

  // 创建新分支
  const branchName = `agent/fix-issue-${issueNumber}`;
  await octokit.git.createRef({
    owner, repo,
    ref: `refs/heads/${branchName}`,
    sha: baseSha,
  });

  // 逐个提交文件变更
  for (const file of files) {
    // 尝试获取已有文件的sha（更新需要）
    let fileSha: string | undefined;
    try {
      const existing = await octokit.repos.getContent({
        owner, repo, path: file.path, ref: branchName,
      });
      fileSha = (existing.data as any).sha;
    } catch {}

    await octokit.repos.createOrUpdateFileContents({
      owner, repo,
      path: file.path,
      message: `fix: auto-resolve #${issueNumber}`,
      content: Buffer.from(file.content).toString("base64"),
      branch: branchName,
      ...(fileSha ? { sha: fileSha } : {}),
    });
  }

  // 创建PR
  const pr = await octokit.pulls.create({
    owner, repo,
    title: `[Agent] Fix #${issueNumber}`,
    body: `Automated fix for #${issueNumber}\n\n由AI Agent自动生成，请review后合并。`,
    head: branchName,
    base: "main",
  });

  return pr.data;
}

// Step 4: Webhook入口 — 监听Issue事件，串联整个流程
import { serve } from "bun";

serve({
  port: 3000,
  async fetch(req) {
    if (req.method !== "POST") return new Response("OK");

    const event = req.headers.get("x-github-event");
    if (event !== "issues") return new Response("ignored");

    const payload = await req.json();
    if (payload.action !== "opened" && payload.action !== "labeled")
      return new Response("ignored");

    const { owner, repo, issue } = {
      owner: payload.repository.owner.login,
      repo: payload.repository.name,
      issue: payload.issue,
    };

    console.log(`📥 收到Issue #${issue.number}: ${issue.title}`);

    // 1. 评估
    const evaluation = await evaluateIssue({
      title: issue.title,
      body: issue.body || "",
      labels: issue.labels.map((l: any) => l.name),
    });

    if (!evaluation.shouldProcess) {
      console.log(`⏭️ 跳过: ${evaluation.reason}`);
      await octokit.issues.createComment({
        owner, repo,
        issue_number: issue.number,
        body: `🤖 Agent评估结果：暂不自动处理\n原因：${evaluation.reason}`,
      });
      return new Response("skipped");
    }

    // 2. 生成代码
    console.log(`🔧 开始生成修复代码...`);
    const result = await generateFix(owner, repo, {
      title: issue.title,
      body: issue.body || "",
    });

    // 3. 创建PR
    const pr = await createPullRequest(
      owner, repo, issue.number, result.files
    );
    console.log(`✅ PR已创建: ${pr.html_url}`);

    // 4. 在Issue下评论
    await octokit.issues.createComment({
      owner, repo,
      issue_number: issue.number,
      body: `🤖 Agent已自动生成修复PR: ${pr.html_url}\n\n复杂度评估: ${evaluation.complexity}\n请review后合并。`,
    });

    return new Response("done");
  },
});

整个流程：Issue进来 → LLM评估 → LLM写代码 → GitHub API提PR → 等人review。一共4步，每步职责清晰。

从半自动到全自动的信任鸿沟

上面的代码实现的是半自动——Agent写代码，人来审。这是现阶段最务实的方案。

但很多人想要的是全自动——Agent写完直接上线，不需要人参与。这两者之间隔着一道巨大的信任鸿沟：

维度	半自动	全自动
人的角色	审核PR	设定规则后不参与
出错成本	低（PR被拒）	高（有bug的代码上线）
测试要求	有基本测试即可	需要极高覆盖率
适用场景	所有项目	内部工具、低风险项目
现在能用？	能	特定场景能

全自动的前提是：你的测试覆盖率高到足以替代人类review。 如果CI全绿就意味着代码没问题，那Agent自动合并就是安全的。问题是，绝大多数项目做不到这一点。

想要实现全自动，还需要加几层防护：

// 全自动模式的安全防护层
const SAFETY_RULES = {
  // 只允许修改特定目录
  allowedPaths: ["src/features/", "src/components/"],
  // 禁止修改的文件
  blockedPaths: [".env", "package.json", "tsconfig.json", "*.lock"],
  // 单次PR最大修改行数
  maxChangedLines: 200,
  // 必须通过的CI检查
  requiredChecks: ["test", "lint", "type-check", "e2e"],
  // 需要人工审核的标签
  humanReviewLabels: ["security", "breaking-change", "database"],
};

async function canAutoMerge(pr: PullRequest): Promise<boolean> {
  // 检查修改范围
  const files = await octokit.pulls.listFiles({
    owner, repo, pull_number: pr.number,
  });

  const hasBlockedFile = files.data.some((f) =>
    SAFETY_RULES.blockedPaths.some((p) =>
      f.filename.match(new RegExp(p.replace("*", ".*")))
    )
  );
  if (hasBlockedFile) return false;

  // 检查修改量
  const totalChanges = files.data.reduce(
    (sum, f) => sum + f.changes, 0
  );
  if (totalChanges > SAFETY_RULES.maxChangedLines) return false;

  // 检查CI状态
  const checks = await octokit.checks.listForRef({
    owner, repo, ref: pr.head.sha,
  });
  const allPassed = SAFETY_RULES.requiredChecks.every((name) =>
    checks.data.check_runs.some(
      (c) => c.name === name && c.conclusion === "success"
    )
  );

  return allPassed;
}

核心思路：通过限制Agent的能力边界来建立信任。 不是让Agent什么都能改，而是划一个安全区域，在这个区域内Agent可以自由发挥。

这代表什么趋势

往大了说，这是软件开发从"手工业"到"工业化"的最后一步。

• 2000年代，CI/CD自动化了构建和部署
• 2010年代，容器化自动化了环境管理
• 2020年代，AI Copilot自动化了代码编写
• 2025-2026年，AI Agent正在自动化整个开发流程

每一次自动化，都会有人说"这会取代程序员"。结果每一次，程序员反而变得更值钱了——因为自动化掉的是重复劳动，留下的是更高阶的决策。

这次也一样。Agent能自动修bug、加feature，但它不能决定产品方向、不能理解用户的真实需求、不能做技术选型的权衡。Agent越强，能做判断的人越稀缺。

落地建议

如果你想在自己的项目上跑起来，我的建议是分三步走：

第一步：先跑半自动。 用OpenHands Resolver或者直接用上面的代码，在你自己的一个小项目上试。Issue进来，Agent提PR，你review合并。感受一下这个流程。

第二步：加测试，提覆盖率。 这是通向全自动的前提。Agent生成的代码质量，最终取决于你的测试能不能兜住。

第三步：逐步放开自动化程度。 先让Agent自动合并"修typo"级别的PR，再扩展到"加简单功能"，最后到"修复bug"。每一步都验证充分再进下一步。

不要一上来就追求全自动。 半自动已经能把开发效率提升3-5倍了。从Issue到可review的PR只需要5分钟，这已经是质变了。

全自动是终局，但通往终局的路上，每一步的半自动都已经足够有价值。