让 Agent 会合并容易，难的是定义它什么时候不许合并

Jiayuan 在 X 上贴了一个 Merge 工作流 Prompt，给 Agent 用。Agent 在这里指能读仓库、跑检查、发评论的自动化代理。PR 是代码合并请求，CI 是持续集成检查，issue 是任务单。

流程分四步。

1. 检查冲突或 CI 问题。有问题先修。遇到重大变更或需要决策的变更，不合并，mention Jiayuan 决策。修完且不需要决策，就直接合并。

2. 没有冲突和 CI 问题，就直接合并。

3. 搜索 GitHub repo 里的相关 issue 和 PR。找到关联项，就在对应位置评论，并注明评论由 agent 自动发送。判断能否关闭对应 issue 或 PR。能关就关，同时提示用户，如果错误关闭可以手动打开。

4. 再 review 这个 issue 里的内容，分析哪些可以之后沉淀。没有就不硬写。每条给置信度，超过 70% 的直接创建 issue 推进。

让 Agent 会合并，容易。定义它什么时候不许合并，难。第一步里的重大变更就是暂停点，但原文没有列出更细的条件。ziziran 在回复里补了一条：把重大变更列成明确的暂停条件，例如数据库迁移、权限变化、对外接口不兼容。命中时让 Agent 一次贴出改动位置、继续合并的影响、可选处理方案。其余 PR 继续按原流程走。这样 mention 时能直接进入决策，不用先追问它卡在哪。

这个补充的价值在于，它把决策所需的信息也写进了暂停条件。Agent 只报一句需要决策，人还得追问它卡在哪，合并流程就断在沟通上。暂停条件越模糊，Agent 越容易在错误的地方继续。写清暂停条件，等于把决策点前置。

四步里，第三步和第四步容易被忽略。它们不直接决定代码能否合并，却决定合并之后仓库是否更清楚。自动评论注明来源，关联 issue 能关闭就关闭，错误关闭可手动打开，这些动作让 Agent 的行为可追溯。第四步不硬写沉淀，置信度超过 70% 才创建 issue，也避免了为了流程而制造任务。

原文链接：https://x.com/jiayuan_jy/status/2118771384122061091