全自动AI Agent修复GitHub Issue：我的实操心得

把GitHub Issue直接扔给AI，然后看着它自己分析、写代码、跑测试、过评审，最后直接甩给我一个PR，这种体验确实有点诡异。很多人吹自主AI，但大多数 demo 其实就是个死循环，这次我搭的这套工作流真正做到了“无人工干预”。

我没用那种让LLM自己决定下一步走哪的模糊架构，因为太容易产生幻觉导致死循环。我直接用 Python 的 if/else 逻辑写死了调度流程，强制分成了四个角色：

• Architect（架构师）： 负责读库、分析结构并出方案，方案会直接评论在 Issue 下面。
• Coder（程序员）： 在 E2B 的云沙箱里克隆代码、写实现、跑 Linter 和测试。失败了最多尝试3次，得不到结果就挂掉。
• Reviewer（评审员）： 逐行扫描 diff，专门查硬编码密钥、SQL注入和输入校验。
• PR Agent（提交员）： 汇总变更点和测试结果，开 Draft PR。

最关键的一点是：这四个 Agent 之间是信息隔离的。Reviewer 看不到 Architect 的计划，只能基于代码结果评审，这样才能避免 AI 之间互相“拍马屁”导致 Bug 溜进去。

我的技术栈全是白嫖方案，成本几乎为零：

• 推理： Groq (Llama 3.1) 每天 50w token 足够跑几次。
• 执行环境： E2B 提供秒级启动的 Ubuntu 沙箱，跑真代码、真测试，不是模拟。
• 编排： LangGraph + FastAPI + Next.js (WebSocket 实时看日志)。

当然，过程并不丝滑。最离谱的一次是模型连续调用了 11 次一个不存在的工具，原因是我在系统提示词里写了，但代码里忘了定义。

给想尝试部署类似 AI Agent 工作流的人一个建议，别迷信“全自动”，调度层必须硬编码。

# 简单的调度逻辑示例，不要让LLM决定流程
def workflow_supervisor(current_state):
    if current_state.status == "PLANNING_DONE":
        return call_coder_agent(current_state)
    elif current_state.status == "CODE_READY":
        return call_reviewer_agent(current_state)
    elif current_state.status == "REVIEW_PASSED":
        return call_pr_agent(current_state)
    else:
        return handle_error(current_state)