Inkitt自动化PR流程：Webhook去重、CI失败修复与合并冲突

Inkitt 做了一套一次性的拉取请求（PR）生成器，专门处理那些体量小、风险低的软件改动，从接到任务开始，一路跑到产出草稿 PR，供人测试和审查。触发方式有三种：Slack、Linear，或者由另一个智能体发起 API 调用。整套流程跑在远程基础设施上，开发者不必在本地配置、也不用盯着编码智能体干活。Inkitt Tech 在一篇技术文章里称，这套系统如今每天都在用于交付代码。

它的编排器由事件驱动，负责调度一批生命周期很短的智能体容器，并没有沿用固定流水线。

需求说明、实现、验证、CI 失败修复、合并冲突解决，各由单独阶段承担。每次运行的状态都会由编排器写进数据库，所以执行可以接着已记录的状态往下恢复。

Inkitt 一次性 PR 创建器架构（来源：Inkitt 博客文章）

决策逻辑与副作用在这套编排器里是分开的。核心的状态转换函数只根据当前运行状态和传入事件判断下一步做什么，不会直接去碰数据库、网络或语言模型。外部系统的凭证由编排器保管，智能体容器拿到的只是短期有效的代码仓库 Token 和模型凭证。智能体碰不到 Slack、Linear 的凭证，也拿不到云身份，更不能随意建立网络连接。此外还有一道独立检查，直接看实际的 Git Diff，确认改动没有碰到受限制的路径。

自动化被 Inkitt 限定在预设范围里。数据库迁移、Schema 或共享契约变更、CI 与容器构建配置、身份验证、支付代码，以及软件包的添加或更新，这类任务一律拒绝。验证、CI 修复、合并冲突解决各自最多尝试两次。Webhook 重复投递的情况，靠去重和条件数据库写入来应对，也就是把幂等原则用到那些可能重试、可能收到重复事件的工作流上。判断 CI 是否完成时，编排器会去查 GitHub，确认所有相关任务都已结束，而不是把每个任务事件都当成整个工作流完成的信号。

在讲幂等性、锁、重试预算和权限这些实现难题时，Tanner 写道：

模型反而是最简单的部分。

这套设计与其他编码智能体在防护措施上有重合，编排模型却不一样。GitHub Copilot 的云端智能体同样会限制智能体权限，也要求在合并前人工审查；SWE-agent 则把重点放在用模型驱动的界面去浏览、编辑、执行代码，从而解决代码仓库里的问题。Inkitt 的方案更看重的，是持久化的工作流状态、有限次数的重试，以及对外部操作的集中管控。

人工审批依旧留在 Inkitt 的流程里。系统只创建草稿 PR，绕不过分支保护，也不能自己合并改动。CI 通过、变更进入预发布环境后，系统会通知任务发起者。接下来得由人把 PR 标记为可供审查，并处理审查者请求和审批。任务规模较大时，Inkitt 还另有一个本地版本，让开发过程始终有人参与。