Rillet用AI Agent自动写PR：新功能2小时上线，合并PR翻三倍

当大多数团队还在讨论AI编程助手能不能「靠谱」时，已经有工程团队把从客户请求到生产上线的链路交给了AI Agent。据Twitter上披露的信息，RilletHQ的工程师在Vercel上运行eve agents，将客户需求直接转化为PR，新功能2小时即可进入生产环境，合并PR数量增长到原来的三倍。这组数字背后，是软件交付流程正在被重新定义。

从客户请求到PR：一条被压缩的交付链路

传统流程里，一条客户需求要经过产品经理整理、工程师排期、编码、评审、测试、合并，才能上线。RilletHQ的做法是把其中「需求理解—代码生成—提交PR」这一段交给运行在Vercel上的eve agents完成。客户请求进入系统后，Agent负责生成对应的代码变更并开出PR，人类工程师的角色转向评审与把关。

这种模式的价值不在于让AI「写代码」，而在于把需求到代码之间的转换成本压到接近零。对于重复性高、模式清晰的功能请求，Agent可以立刻产出可评审的变更，工程师不用再花时间在上下文切换和样板代码上。

PR（Pull Request，拉取请求） 是 Git/GitHub 等代码协作平台上的标准机制：开发者在一个独立分支上完成改动后，向主干提交一个合并请求，经过代码评审、自动化测试等手段把关，通过后才被合并进主干分支。PR 同时承担了三重角色——变更的载体、评审的场所、以及可追溯的审计记录。所谓「Agent 开出 PR」，意味着 AI 生成的不只是一段代码片段，而是一个包含提交信息、变更说明、可直接进入评审流程的完整变更单元；这也解释了为什么评审基础设施的质量会直接决定这套模式的成败。

2小时上线与PR翻三倍意味着什么

「新功能2小时进入生产」和「合并PR增长三倍」这两个指标需要放在一起看。前者说明交付周期被显著缩短，后者说明吞吐量实质提升——不是把活干得更快但质量下降，而是有更多变更被真正合并进了主干。

PR数量翻三倍通常有两种解释：一是需求本身变多了，二是每个需求的落地成本降低了，原本因为排期被搁置的小改动现在值得做。结合Agent自动生成PR的背景，后者的可能性更大：当开PR的边际成本极低时，团队会更愿意把细小的客户反馈快速落地，形成更密集的迭代节奏。

你可能没注意到，PR合并数增长并不自动等于工程质量提升。评审环节是否同步加强、测试覆盖是否跟上、Agent生成的代码是否符合团队规范，这些问题决定了这套模式能否长期跑下去。

Agent式交付与传统AI编程助手的区别

市面上多数AI编程工具定位在IDE里的「副驾驶」，帮工程师补全代码、解释报错、生成单测，人始终在驱动每一个动作。RilletHQ的模式更接近「Agent驱动」：由Agent接收一个业务目标（客户请求），自主完成从理解到提交PR的闭环，人类在PR环节介入。

这个差别决定了自动化能覆盖的范围。副驾驶模式优化的是写代码这一动作的效率，Agent模式优化的是从需求到变更的整条流程。后者的天花板更高，但对Agent的可靠性、代码库上下文理解能力、以及团队的评审基础设施要求也更高。

AI Agent 与传统的代码补全类工具在架构上有本质差异。补全工具本质上是一个「单步预测器」：给定上下文，预测下一段代码，人类负责决定何时调用、如何验证。Agent 则是一个具备目标分解、工具调用和反馈循环的系统——它能读取需求、检索代码库、编辑文件、运行测试、根据失败结果重试，直到产出可交付的变更。实现这类能力通常需要接入代码仓库、CI 系统、文档检索等外部工具，并依赖较长的上下文理解和多轮自主决策。正因如此，Agent 的能力上限更高，但错误也更「完整」——它可能自信地提交一份表面合理、实则不符规范的 PR，所以人工评审不可省略。

Vercel作为Agent运行底座的角色

RilletHQ选择在Vercel上运行eve agents，说明这类Agent工作流对部署和运行环境有特定需求：需要能快速响应事件、与代码仓库和协作工具打通、并且足够轻量地扩缩。Vercel的产品定位正好覆盖了事件驱动型应用的部署场景，这让Agent可以作为一种常驻服务来运行，而不是绑在某个工程师的本地环境里。

从架构角度看，把Agent放在云端的部署平台上，意味着它的行为可以被统一观测和管理，这对需要审计每一次代码变更来源的工程团队来说是必要的。

事件驱动型应用 指由外部事件（如一条新工单、一次 webhook 回调、一条客户消息）触发执行、而非持续驻留等待用户请求的服务形态。Agent 工作流天然是事件驱动的：客户请求到达即触发一次「理解—编码—提 PR」的执行链路，随后进入空闲。这类负载具有突发性和间歇性，适合部署在按需扩缩、冷启动快的平台上。」Vercel」 的产品定位正是面向前端与事件驱动型服务的部署，支持与 Git 仓库、Webhook 等生态打通，使 Agent 能以常驻服务的形态运行，而非绑在某个工程师的本地环境里，其每一次执行也因而可被统一观测和审计。

这种模式适合谁，又不适合谁

适合的场景比较明确：需求模式稳定、代码库结构清晰、测试与评审流程成熟的团队。这类团队能让Agent在既定边界内产出高质量PR，人类集中精力做审查和架构决策。

不适合的场景同样明显：代码库耦合严重、需求高度模糊、或者缺少自动化测试兜底的团队。在这些环境下，Agent生成的PR会大量堆积在评审环节，反而增加工程师的负担。RilletHQ的案例给出的不是一套可以直接照搬的方案，而是一个信号——当评审和测试基础设施足够强时，Agent可以承担比「补全代码」大得多的职责。

人类工程师的角色在往哪走

如果需求到PR的路径被Agent接管，工程师的核心工作会向两端集中：一端是把模糊的业务问题拆解成Agent能理解的明确目标，另一端是对生成的变更做严格把关。编码本身仍然存在，但占比会下降。

这对团队的能力结构提出了新要求：评审能力、对代码库的整体把控、以及设计Agent工作边界的能力，会比单纯写代码的速度更重要。RilletHQ的实践说明这条路已经有人在走，并且拿到了可量化的结果。