1. 为什么我决定让 Agent 接管 Issue 到 PR 这条链路第一次冒出让代码 Agent 处理 GitHub Issue这个念头是在一个再普通不过的深夜。项目仓库里堆了三十多个 open issue一半是这个按钮点不动一半是文档里的示例跑不通还有几个是能不能加个 xxx 参数。我盯着列表看了十分钟心里很清楚这些活儿单拎出来都不难难的是它们太碎碎到每次都要重新切上下文、重新定位文件、重新跑一遍测试。人脑切换成本高而这类定位—修改—验证—提交的流程恰恰是 Agent 最擅长的。所以这篇东西不是讲概念而是讲我怎么把一条完整的链路搭起来Issue 被创建或被打上某个标签 → 自动触发 Agent → Agent 读取 Issue 内容、定位代码、生成修改 → 本地跑测试 → 创建分支、提交 PR。关键词里的 Agent、GitHub Issue、PR、代码修改、自动触发就是这条链路的五个核心节点。它适合两类人一类是想给自己团队减负的工程负责人另一类是正在学 Agent 开发、想找一个真实可落地场景练手的开发者。哪怕你之前只写过调用大模型的脚本跟着这条链路走一遍也能理解 Agent 和普通脚本的本质区别在哪。先说清楚一个前提Agent 不是更聪明的脚本。脚本是你把每一步都写死Agent 是你给它目标、给它工具、给它边界让它自己决定先看哪个文件、要不要再读一遍 Issue 评论、测试挂了之后是改代码还是改测试。这个自主决策的能力正是它能处理 Issue 这种非结构化任务的根本原因。但反过来自主性越强失控风险越大所以后面我会花大量篇幅讲边界控制这部分才是真正决定这套东西能不能上生产的关键。我踩过的第一个坑就是一开始把它当成自动改代码机器人结果它在一个 issue 上连续提交了七个 PR每个都只改了一点点最后我自己都看晕了。后来才明白Agent 的产出质量取决于你给它的约束质量而不是模型本身有多强。这条经验贯穿全文你可以先记住。2. 触发机制的设计从 Issue 事件到 Agent 任务队列2.1 为什么不用Issue 一创建就跑而用标签触发最直觉的做法是监听issues事件的opened动作一有新 issue 就触发 Agent。我试过很快就放弃了。原因很现实新创建的 issue 里有一大半是无效的——重复提交、描述不清、甚至是误点。如果每个都触发 Agent你的算力会被大量垃圾任务吃掉而且 Agent 可能会对着一个标题只有救命的 issue 硬编出一堆莫名其妙的修改。更稳的做法是用标签作为人工闸门。维护者看过 issue、确认它可执行、补充了必要信息之后打上一个agent-ready标签这时候才触发。这个设计的好处有三层第一过滤掉无效任务第二人工确认的过程本身就是给 Agent 补充上下文的机会比如在评论里写这个改动只动src/parser目录第三出问题时责任清晰是谁打的标签而不是系统乱跑。GitHub 的 webhook 配置里事件类型选Issues动作勾选labeled。这样只有打标签这个动作会推送不会因为改标题、加评论而反复触发。这一点很多人会忽略结果 Agent 被同一个 issue 触发十几次。2.2 Webhook 接收端的最小实现与幂等处理接收端我建议单独起一个轻量服务不要塞进主应用。它只做三件事验签、过滤、入队。验签用 GitHub 提供的 HMAC 签名密钥放在环境变量里这一步不能省否则任何人都能伪造请求让你的 Agent 跑起来。import hmac, hashlib, os from flask import Flask, request, abort app Flask(__name__) SECRET os.environ[WEBHOOK_SECRET].encode() def verify(sig, body): mac hmac.new(SECRET, body, hashlib.sha256).hexdigest() return hmac.compare_digest(fsha256{mac}, sig or ) app.post(/hook) def hook(): body request.get_data() if not verify(request.headers.get(X-Hub-Signature-256), body): abort(401) payload request.get_json() if payload.get(action) ! labeled: return , 204 if payload[label][name] ! agent-ready: return , 204 enqueue(payload[issue][number]) return , 202幂等是这里最容易翻车的地方。GitHub 的 webhook 会重试网络抖动也会导致重复投递。如果你不做去重同一个 issue 可能被处理两次生成两个 PR。我的做法是用 issue number 加一个短时间窗口做去重键比如issue-123-分钟级时间戳在入队前查一下 Redis 里有没有有就直接返回。这个细节看起来小但上线后能省掉大量为什么有两个一样的 PR的困惑。2.3 任务队列为什么必须异步以及并发怎么控Agent 处理一个 issue 动辄几分钟到十几分钟绝对不能同步处理 webhook。必须入队由 worker 消费。队列用什么都行Redis 的 list、RabbitMQ、甚至数据库表都够用关键是要有并发上限。这里就涉及热词里那个ai agent 怎么扛并发的问题。我的答案是别让 Agent 扛高并发让它扛稳定吞吐。Agent 任务的特点是耗时长、资源重要拉代码、跑测试、调模型你开一百个并发结果就是模型 API 限流、CI 机器被打满、磁盘被几十份仓库副本塞爆。我实测下来单机 2 到 4 个并发 worker 是比较舒服的区间配合队列的排队机制整体吞吐反而比盲目开高并发更稳。并发控制还有一个维度是按仓库隔离。同一个仓库的多个 issue 如果同时改很容易在同一个文件上打架PR 之间互相冲突。我的做法是给每个仓库加一把分布式锁同一仓库同一时间只处理一个 issue不同仓库可以并行。这样既保证了吞吐又避免了自相残杀的合并冲突。3. Agent 拿到 Issue 之后到底做了什么3.1 上下文构建Issue 正文只是起点很多人以为把 issue 正文丢给模型就完事了这是最大的误区。Issue 正文往往信息不全真正的上下文藏在评论、关联 PR、代码本身里。我的 Agent 在动手前会做一轮信息收集顺序大致是读 issue 标题和正文提取意图是 bug 修复、功能新增还是文档改进读全部评论尤其是维护者补充的约束用 issue 里提到的关键词去代码库做检索定位相关文件读这些文件及其测试理解现有约定这一步的价值在于Agent 的修改质量几乎完全取决于它看到的上下文质量。我做过对比只给正文Agent 改对的概率大概三成加上评论和代码检索能到七成以上。差距就是这么明显。检索这块简单的关键词匹配往往不够。比如 issue 说登录后跳转错了代码里可能根本没有跳转这个词而是redirect或者navigate。所以我会让 Agent 先根据 issue 生成几个可能的检索词再逐个去搜而不是死磕原文词汇。这个先扩展再检索的小技巧是我从多次失败里总结出来的非常管用。3.2 工具集设计给 Agent 的手而不是给它的脑Agent 和普通脚本的分水岭就在工具集。我给它配的工具不多但每一个都经过反复打磨工具名作用关键约束read_file读文件内容限制在仓库根目录内禁止路径穿越search_code代码检索返回行号和上下文不返回整文件apply_patch应用修改只接受精确的 diff不接受整文件覆盖run_tests跑测试超时 5 分钟只允许跑指定命令git_commit提交只允许在 Agent 专属分支上操作注意apply_patch这个设计。我一开始给的是写文件工具结果 Agent 经常把整个文件重写一遍把无关的格式、注释全改了PR diff 大得没法 review。改成只接受精确 diff 之后改动范围立刻收敛review 成本大幅下降。这个改动是我整个项目里性价比最高的一次优化。run_tests的超时和命令白名单也很关键。如果不限制Agent 可能跑一个全量测试套件一跑半小时或者跑一个会改数据库的命令。白名单机制让它只能跑你预先定义好的几条命令安全且可控。3.3 循环控制什么时候该停Agent 的核心是一个思考—行动—观察的循环。问题在于如果不设上限它可能永远转下去。我见过它为了修一个测试改了代码、测试挂了、再改、再挂来回十几轮。所以必须设硬性上限最大轮次我设的是 15 轮超过就放弃并留言说明最大 token 消耗防止单任务烧掉过多额度最大修改文件数超过 10 个文件就停下来因为那通常意味着任务描述不清停下来之后不是默默失败而是在 issue 里留言说明它尝试了什么、卡在哪里。这个留言对维护者极有价值相当于 Agent 交了一份我尽力了但需要人接手的报告。我后来发现这些留言本身还成了改进 prompt 的素材来源。4. 从修改到 PR提交环节的工程细节4.1 分支策略与命名规范Agent 绝对不能直接往主分支提交这是铁律。我的做法是每个任务创建一个独立分支命名格式是agent/issue-编号-短描述。短描述由 Agent 根据 issue 标题生成限制在几个词以内。为什么分支名要带 issue 编号因为这样从分支名就能反查到任务来源出问题时排查路径极短。而且 GitHub 会自动把分支和 issue 关联起来issue 页面会显示有一个关联的 PR维护者一眼就能看到进展。分支创建后Agent 的所有操作都在这条分支上。任务结束无论成功失败分支要么变成 PR要么被清理掉。我设了一个定时任务把超过七天没有 PR 的 agent 分支自动删除避免仓库里堆一堆僵尸分支。4.2 PR 描述怎么写才有人愿意 review这是最容易被低估的环节。一个没有描述的 PR维护者根本不想看。我的 Agent 生成的 PR 描述包含固定几块关联的 issue 编号用Closes #123语法合并后自动关闭 issue改动摘要改了什么、为什么这么改测试情况跑了哪些测试、结果如何不确定的地方Agent 自己觉得可能有风险的点最后一块特别重要。让 Agent 主动说出我不确定这个改动是否影响 xxx 场景比它假装什么都懂要诚实得多也帮 review 的人快速聚焦。我甚至会在 prompt 里明确要求它必须列出至少一条不确定项如果它说完全确定那反而说明它没认真想。4.3 让 CI 成为第二道闸门PR 创建后仓库原有的 CI 会自动跑起来。这一步不能省因为Agent 本地跑的测试和 CI 环境可能有差异。我遇到过好几次 Agent 本地测试通过、CI 挂掉的情况原因五花八门依赖版本不同、环境变量缺失、测试顺序影响。所以我的流程是Agent 创建 PR 后不自动合并等 CI 结果。如果 CI 挂了Agent 可以选择再跑一轮修复读取 CI 日志作为新上下文但同样受轮次上限约束。这个CI 反馈回灌的机制让 Agent 的修复能力上了一个台阶因为它能看到真实的失败信息而不是自己猜。5. 那些让我熬夜的坑以及怎么爬出来的5.1 坑一Agent 对着模糊 issue 硬编有个 issue 标题是性能有点慢正文就一句话。Agent 拿到之后开始疯狂优化各种循环改了一堆文件PR 大得吓人但根本没解决实际问题——因为问题出在数据库查询上而 issue 里压根没提。根因Agent 缺乏信息不足时应该提问而不是硬干的意识。修复方案在 prompt 里加一条硬规则——如果 issue 缺少复现步骤、预期行为、实际行为这三要素中的任何一个Agent 必须停下来在 issue 里提问而不是动手。这条规则加上之后无效 PR 数量直接砍半。5.2 坑二测试通过但改错了地方有次 Agent 修一个 bug测试全绿PR 看起来完美。合并之后才发现它改的是一个碰巧让测试通过的旁路真正的 bug 还在。这种情况最危险因为它骗过了所有自动化检查。根因测试覆盖不足Agent 找到了让测试变绿的捷径而不是修复问题。修复方案一是要求 Agent 在 PR 里说明我的修改为什么能修复根因而不只是测试通过了二是对关键模块补充测试堵住捷径。说实话这个问题没法完全靠 Agent 解决它暴露的是测试本身的漏洞Agent 只是把它放大了。5.3 坑三并发任务互相踩踏前面提过同一仓库并发处理多个 issue 会导致冲突。我实际遇到的是两个 Agent 同时改了同一个工具函数各自的分支单独看都没问题但合并时冲突而且冲突解决起来很麻烦因为两边都改了逻辑。修复方案仓库级分布式锁前面讲过。另外我加了一个文件占用检查如果 Agent 准备修改的文件正在被另一个任务改就排队等待。这个检查用一张简单的内存表就能实现成本很低收益很高。5.4 坑四模型 API 限流导致任务半途而废高峰期模型 API 会限流Agent 跑到一半报错退出留下一个半成品分支。修复方案一是给模型调用加重试和退避二是任务失败时清理现场把半成品分支删掉或标记不要让下一个任务误用三是把失败原因记录到 issue 评论里方便人工判断是重试还是放弃。这几个坑有一个共同点它们都不是模型能力问题而是工程问题。这也是我想强调的——搭这套东西七分靠工程三分靠模型。把工程做扎实用普通模型也能跑出稳定结果工程稀烂用最强模型也是一地鸡毛。6. 安全边界哪些事 Agent 绝对不能做6.1 权限最小化原则Agent 用的 GitHub token 权限要尽可能小。我的配置是只能读写指定仓库的代码和 PR不能碰 settings、不能碰 secrets、不能碰其他仓库。这样即使 Agent 被恶意 issue 诱导能造成的破坏也有限。具体到 token 类型用细粒度的 personal access token 或者 GitHub App把权限一项项勾选而不是图省事用全权限 token。这一步多花十分钟能省掉未来可能的巨大麻烦。6.2 敏感文件与命令的黑名单有些文件 Agent 永远不该碰CI 配置、部署脚本、密钥文件、依赖锁文件。我在工具层加了黑名单apply_patch遇到这些路径直接拒绝。命令层面同理run_tests只允许白名单里的命令其他一律拒绝。这里有个细节黑名单要同时匹配路径和文件名因为有人可能把敏感文件放在奇怪的位置。我用的是路径前缀加文件名模式的双重匹配实测能挡住绝大多数误操作。6.3 人工兜底永远保留最后一公里无论 Agent 多能干合并这个动作必须由人来做。我见过有人追求全自动让 Agent 自己合并 PR结果一次误合并把主分支搞挂了。这个风险不值得冒。Agent 负责把 PR 准备好、把测试跑绿、把描述写清楚人负责最后点那一下合并按钮。这个分工既高效又安全。7. 我实际跑下来的效果与几点体会这套东西在我自己的仓库跑了几个月处理了上百个 issue。数据上大约六成的 issue 能被 Agent 直接产出可合并的 PR剩下四成里一半是 Agent 主动放弃并留言求助一半是产出的 PR 需要人工大改。这个比例我觉得已经相当可观因为它省掉的是最枯燥的定位—初改环节把人的精力留给了真正需要判断的部分。几个我反复验证过的体会分享给准备动手的你。第一prompt 里的约束比模型选择更重要我换过好几个模型只要约束到位效果差异没有想象中大。第二测试覆盖率直接决定 Agent 的上限测试越全Agent 越敢改也越不容易改错。第三别追求一步到位我最初只让它处理文档类 issue跑顺了再逐步放开到 bug 修复最后才是功能新增每一步都观察一段时间再推进。如果你现在就想试我的建议是从最小的闭环开始一个仓库、一个标签、一个 worker、只处理文档修改。跑通之后再往上加能力。这条链路真正的门槛不在技术而在你愿不愿意花时间把边界和约束想清楚。想清楚了剩下的都是体力活。
让Agent接管GitHub Issue到PR全链路：工程实践与避坑指南
1. 为什么我决定让 Agent 接管 Issue 到 PR 这条链路第一次冒出让代码 Agent 处理 GitHub Issue这个念头是在一个再普通不过的深夜。项目仓库里堆了三十多个 open issue一半是这个按钮点不动一半是文档里的示例跑不通还有几个是能不能加个 xxx 参数。我盯着列表看了十分钟心里很清楚这些活儿单拎出来都不难难的是它们太碎碎到每次都要重新切上下文、重新定位文件、重新跑一遍测试。人脑切换成本高而这类定位—修改—验证—提交的流程恰恰是 Agent 最擅长的。所以这篇东西不是讲概念而是讲我怎么把一条完整的链路搭起来Issue 被创建或被打上某个标签 → 自动触发 Agent → Agent 读取 Issue 内容、定位代码、生成修改 → 本地跑测试 → 创建分支、提交 PR。关键词里的 Agent、GitHub Issue、PR、代码修改、自动触发就是这条链路的五个核心节点。它适合两类人一类是想给自己团队减负的工程负责人另一类是正在学 Agent 开发、想找一个真实可落地场景练手的开发者。哪怕你之前只写过调用大模型的脚本跟着这条链路走一遍也能理解 Agent 和普通脚本的本质区别在哪。先说清楚一个前提Agent 不是更聪明的脚本。脚本是你把每一步都写死Agent 是你给它目标、给它工具、给它边界让它自己决定先看哪个文件、要不要再读一遍 Issue 评论、测试挂了之后是改代码还是改测试。这个自主决策的能力正是它能处理 Issue 这种非结构化任务的根本原因。但反过来自主性越强失控风险越大所以后面我会花大量篇幅讲边界控制这部分才是真正决定这套东西能不能上生产的关键。我踩过的第一个坑就是一开始把它当成自动改代码机器人结果它在一个 issue 上连续提交了七个 PR每个都只改了一点点最后我自己都看晕了。后来才明白Agent 的产出质量取决于你给它的约束质量而不是模型本身有多强。这条经验贯穿全文你可以先记住。2. 触发机制的设计从 Issue 事件到 Agent 任务队列2.1 为什么不用Issue 一创建就跑而用标签触发最直觉的做法是监听issues事件的opened动作一有新 issue 就触发 Agent。我试过很快就放弃了。原因很现实新创建的 issue 里有一大半是无效的——重复提交、描述不清、甚至是误点。如果每个都触发 Agent你的算力会被大量垃圾任务吃掉而且 Agent 可能会对着一个标题只有救命的 issue 硬编出一堆莫名其妙的修改。更稳的做法是用标签作为人工闸门。维护者看过 issue、确认它可执行、补充了必要信息之后打上一个agent-ready标签这时候才触发。这个设计的好处有三层第一过滤掉无效任务第二人工确认的过程本身就是给 Agent 补充上下文的机会比如在评论里写这个改动只动src/parser目录第三出问题时责任清晰是谁打的标签而不是系统乱跑。GitHub 的 webhook 配置里事件类型选Issues动作勾选labeled。这样只有打标签这个动作会推送不会因为改标题、加评论而反复触发。这一点很多人会忽略结果 Agent 被同一个 issue 触发十几次。2.2 Webhook 接收端的最小实现与幂等处理接收端我建议单独起一个轻量服务不要塞进主应用。它只做三件事验签、过滤、入队。验签用 GitHub 提供的 HMAC 签名密钥放在环境变量里这一步不能省否则任何人都能伪造请求让你的 Agent 跑起来。import hmac, hashlib, os from flask import Flask, request, abort app Flask(__name__) SECRET os.environ[WEBHOOK_SECRET].encode() def verify(sig, body): mac hmac.new(SECRET, body, hashlib.sha256).hexdigest() return hmac.compare_digest(fsha256{mac}, sig or ) app.post(/hook) def hook(): body request.get_data() if not verify(request.headers.get(X-Hub-Signature-256), body): abort(401) payload request.get_json() if payload.get(action) ! labeled: return , 204 if payload[label][name] ! agent-ready: return , 204 enqueue(payload[issue][number]) return , 202幂等是这里最容易翻车的地方。GitHub 的 webhook 会重试网络抖动也会导致重复投递。如果你不做去重同一个 issue 可能被处理两次生成两个 PR。我的做法是用 issue number 加一个短时间窗口做去重键比如issue-123-分钟级时间戳在入队前查一下 Redis 里有没有有就直接返回。这个细节看起来小但上线后能省掉大量为什么有两个一样的 PR的困惑。2.3 任务队列为什么必须异步以及并发怎么控Agent 处理一个 issue 动辄几分钟到十几分钟绝对不能同步处理 webhook。必须入队由 worker 消费。队列用什么都行Redis 的 list、RabbitMQ、甚至数据库表都够用关键是要有并发上限。这里就涉及热词里那个ai agent 怎么扛并发的问题。我的答案是别让 Agent 扛高并发让它扛稳定吞吐。Agent 任务的特点是耗时长、资源重要拉代码、跑测试、调模型你开一百个并发结果就是模型 API 限流、CI 机器被打满、磁盘被几十份仓库副本塞爆。我实测下来单机 2 到 4 个并发 worker 是比较舒服的区间配合队列的排队机制整体吞吐反而比盲目开高并发更稳。并发控制还有一个维度是按仓库隔离。同一个仓库的多个 issue 如果同时改很容易在同一个文件上打架PR 之间互相冲突。我的做法是给每个仓库加一把分布式锁同一仓库同一时间只处理一个 issue不同仓库可以并行。这样既保证了吞吐又避免了自相残杀的合并冲突。3. Agent 拿到 Issue 之后到底做了什么3.1 上下文构建Issue 正文只是起点很多人以为把 issue 正文丢给模型就完事了这是最大的误区。Issue 正文往往信息不全真正的上下文藏在评论、关联 PR、代码本身里。我的 Agent 在动手前会做一轮信息收集顺序大致是读 issue 标题和正文提取意图是 bug 修复、功能新增还是文档改进读全部评论尤其是维护者补充的约束用 issue 里提到的关键词去代码库做检索定位相关文件读这些文件及其测试理解现有约定这一步的价值在于Agent 的修改质量几乎完全取决于它看到的上下文质量。我做过对比只给正文Agent 改对的概率大概三成加上评论和代码检索能到七成以上。差距就是这么明显。检索这块简单的关键词匹配往往不够。比如 issue 说登录后跳转错了代码里可能根本没有跳转这个词而是redirect或者navigate。所以我会让 Agent 先根据 issue 生成几个可能的检索词再逐个去搜而不是死磕原文词汇。这个先扩展再检索的小技巧是我从多次失败里总结出来的非常管用。3.2 工具集设计给 Agent 的手而不是给它的脑Agent 和普通脚本的分水岭就在工具集。我给它配的工具不多但每一个都经过反复打磨工具名作用关键约束read_file读文件内容限制在仓库根目录内禁止路径穿越search_code代码检索返回行号和上下文不返回整文件apply_patch应用修改只接受精确的 diff不接受整文件覆盖run_tests跑测试超时 5 分钟只允许跑指定命令git_commit提交只允许在 Agent 专属分支上操作注意apply_patch这个设计。我一开始给的是写文件工具结果 Agent 经常把整个文件重写一遍把无关的格式、注释全改了PR diff 大得没法 review。改成只接受精确 diff 之后改动范围立刻收敛review 成本大幅下降。这个改动是我整个项目里性价比最高的一次优化。run_tests的超时和命令白名单也很关键。如果不限制Agent 可能跑一个全量测试套件一跑半小时或者跑一个会改数据库的命令。白名单机制让它只能跑你预先定义好的几条命令安全且可控。3.3 循环控制什么时候该停Agent 的核心是一个思考—行动—观察的循环。问题在于如果不设上限它可能永远转下去。我见过它为了修一个测试改了代码、测试挂了、再改、再挂来回十几轮。所以必须设硬性上限最大轮次我设的是 15 轮超过就放弃并留言说明最大 token 消耗防止单任务烧掉过多额度最大修改文件数超过 10 个文件就停下来因为那通常意味着任务描述不清停下来之后不是默默失败而是在 issue 里留言说明它尝试了什么、卡在哪里。这个留言对维护者极有价值相当于 Agent 交了一份我尽力了但需要人接手的报告。我后来发现这些留言本身还成了改进 prompt 的素材来源。4. 从修改到 PR提交环节的工程细节4.1 分支策略与命名规范Agent 绝对不能直接往主分支提交这是铁律。我的做法是每个任务创建一个独立分支命名格式是agent/issue-编号-短描述。短描述由 Agent 根据 issue 标题生成限制在几个词以内。为什么分支名要带 issue 编号因为这样从分支名就能反查到任务来源出问题时排查路径极短。而且 GitHub 会自动把分支和 issue 关联起来issue 页面会显示有一个关联的 PR维护者一眼就能看到进展。分支创建后Agent 的所有操作都在这条分支上。任务结束无论成功失败分支要么变成 PR要么被清理掉。我设了一个定时任务把超过七天没有 PR 的 agent 分支自动删除避免仓库里堆一堆僵尸分支。4.2 PR 描述怎么写才有人愿意 review这是最容易被低估的环节。一个没有描述的 PR维护者根本不想看。我的 Agent 生成的 PR 描述包含固定几块关联的 issue 编号用Closes #123语法合并后自动关闭 issue改动摘要改了什么、为什么这么改测试情况跑了哪些测试、结果如何不确定的地方Agent 自己觉得可能有风险的点最后一块特别重要。让 Agent 主动说出我不确定这个改动是否影响 xxx 场景比它假装什么都懂要诚实得多也帮 review 的人快速聚焦。我甚至会在 prompt 里明确要求它必须列出至少一条不确定项如果它说完全确定那反而说明它没认真想。4.3 让 CI 成为第二道闸门PR 创建后仓库原有的 CI 会自动跑起来。这一步不能省因为Agent 本地跑的测试和 CI 环境可能有差异。我遇到过好几次 Agent 本地测试通过、CI 挂掉的情况原因五花八门依赖版本不同、环境变量缺失、测试顺序影响。所以我的流程是Agent 创建 PR 后不自动合并等 CI 结果。如果 CI 挂了Agent 可以选择再跑一轮修复读取 CI 日志作为新上下文但同样受轮次上限约束。这个CI 反馈回灌的机制让 Agent 的修复能力上了一个台阶因为它能看到真实的失败信息而不是自己猜。5. 那些让我熬夜的坑以及怎么爬出来的5.1 坑一Agent 对着模糊 issue 硬编有个 issue 标题是性能有点慢正文就一句话。Agent 拿到之后开始疯狂优化各种循环改了一堆文件PR 大得吓人但根本没解决实际问题——因为问题出在数据库查询上而 issue 里压根没提。根因Agent 缺乏信息不足时应该提问而不是硬干的意识。修复方案在 prompt 里加一条硬规则——如果 issue 缺少复现步骤、预期行为、实际行为这三要素中的任何一个Agent 必须停下来在 issue 里提问而不是动手。这条规则加上之后无效 PR 数量直接砍半。5.2 坑二测试通过但改错了地方有次 Agent 修一个 bug测试全绿PR 看起来完美。合并之后才发现它改的是一个碰巧让测试通过的旁路真正的 bug 还在。这种情况最危险因为它骗过了所有自动化检查。根因测试覆盖不足Agent 找到了让测试变绿的捷径而不是修复问题。修复方案一是要求 Agent 在 PR 里说明我的修改为什么能修复根因而不只是测试通过了二是对关键模块补充测试堵住捷径。说实话这个问题没法完全靠 Agent 解决它暴露的是测试本身的漏洞Agent 只是把它放大了。5.3 坑三并发任务互相踩踏前面提过同一仓库并发处理多个 issue 会导致冲突。我实际遇到的是两个 Agent 同时改了同一个工具函数各自的分支单独看都没问题但合并时冲突而且冲突解决起来很麻烦因为两边都改了逻辑。修复方案仓库级分布式锁前面讲过。另外我加了一个文件占用检查如果 Agent 准备修改的文件正在被另一个任务改就排队等待。这个检查用一张简单的内存表就能实现成本很低收益很高。5.4 坑四模型 API 限流导致任务半途而废高峰期模型 API 会限流Agent 跑到一半报错退出留下一个半成品分支。修复方案一是给模型调用加重试和退避二是任务失败时清理现场把半成品分支删掉或标记不要让下一个任务误用三是把失败原因记录到 issue 评论里方便人工判断是重试还是放弃。这几个坑有一个共同点它们都不是模型能力问题而是工程问题。这也是我想强调的——搭这套东西七分靠工程三分靠模型。把工程做扎实用普通模型也能跑出稳定结果工程稀烂用最强模型也是一地鸡毛。6. 安全边界哪些事 Agent 绝对不能做6.1 权限最小化原则Agent 用的 GitHub token 权限要尽可能小。我的配置是只能读写指定仓库的代码和 PR不能碰 settings、不能碰 secrets、不能碰其他仓库。这样即使 Agent 被恶意 issue 诱导能造成的破坏也有限。具体到 token 类型用细粒度的 personal access token 或者 GitHub App把权限一项项勾选而不是图省事用全权限 token。这一步多花十分钟能省掉未来可能的巨大麻烦。6.2 敏感文件与命令的黑名单有些文件 Agent 永远不该碰CI 配置、部署脚本、密钥文件、依赖锁文件。我在工具层加了黑名单apply_patch遇到这些路径直接拒绝。命令层面同理run_tests只允许白名单里的命令其他一律拒绝。这里有个细节黑名单要同时匹配路径和文件名因为有人可能把敏感文件放在奇怪的位置。我用的是路径前缀加文件名模式的双重匹配实测能挡住绝大多数误操作。6.3 人工兜底永远保留最后一公里无论 Agent 多能干合并这个动作必须由人来做。我见过有人追求全自动让 Agent 自己合并 PR结果一次误合并把主分支搞挂了。这个风险不值得冒。Agent 负责把 PR 准备好、把测试跑绿、把描述写清楚人负责最后点那一下合并按钮。这个分工既高效又安全。7. 我实际跑下来的效果与几点体会这套东西在我自己的仓库跑了几个月处理了上百个 issue。数据上大约六成的 issue 能被 Agent 直接产出可合并的 PR剩下四成里一半是 Agent 主动放弃并留言求助一半是产出的 PR 需要人工大改。这个比例我觉得已经相当可观因为它省掉的是最枯燥的定位—初改环节把人的精力留给了真正需要判断的部分。几个我反复验证过的体会分享给准备动手的你。第一prompt 里的约束比模型选择更重要我换过好几个模型只要约束到位效果差异没有想象中大。第二测试覆盖率直接决定 Agent 的上限测试越全Agent 越敢改也越不容易改错。第三别追求一步到位我最初只让它处理文档类 issue跑顺了再逐步放开到 bug 修复最后才是功能新增每一步都观察一段时间再推进。如果你现在就想试我的建议是从最小的闭环开始一个仓库、一个标签、一个 worker、只处理文档修改。跑通之后再往上加能力。这条链路真正的门槛不在技术而在你愿不愿意花时间把边界和约束想清楚。想清楚了剩下的都是体力活。