秋田散人(@akitabtc):btw，我现在每月可能几千个 PR 合并，软件 CI workflow 是高度自动化和高度依赖 github 框架的，特别是 actions 以及 PR 的评论区。整体分三阶段，由三个 agent 来跨期分段处理： 1. Review agent（PR 合并前）：在合并前，3 个不互相蒸馏的模型厂家一一审计，一一留档，没有达成共识的 PR 不允许合并。 2. Release agent（PR 刚合并）: 灰度测试，小额接生产流量，留下验收目标和验收方式（固定字段） 3. Verify agent（生产流量验证期）: 看到验收目标和字段出现在日志中 marker 以后，确认并且操作 gray 翻全量；有明确 error 和适配问题同样要留档 PR 评论区，可以驱动下一个关联 PR 项。 4. Graduate agent（全量翻完在生产跑 15-30 天以后）：每一个灰度 feature tag 都是 candidate，看哪些 feature 已经验收无误，后完整毕业，翻 default value。 ——以确保一个 feature PR 能在软件生命周期早期被准确监督复核，哪怕他是 agent 的一个随机并且未充分验证的 idea，在这套体系下也几乎不可能犯大错误。而这几阶段中间可能隔了几个小时甚至几天几周，完全不是 continuous 的，也完全不可能被同一个短寿的 agent 接管，那么一定需要有一个 “论坛式的记忆”—

2026.08.31 04:35

btw，我现在每月可能几千个 PR 合并，软件 CI workflow 是高度自动化和高度依赖 github 框架的，特别是 actions 以及 PR 的评论区。整体分三阶段，由三个 agent 来跨期分段处理： 1. Review agent（PR 合并前）：在合并前，3 个不互相蒸馏的模型厂家一一审计，一一留档，没有达成共识的 PR 不允许合并。 2. Release agent（PR 刚合并）: 灰度测试，小额接生产流量，留下验收目标和验收方式（固定字段） 3. Verify agent（生产流量验证期）: 看到验收目标和字段出现在日志中 marker 以后，确认并且操作 gray 翻全量；有明确 error 和适配问题同样要留档 PR 评论区，可以驱动下一个关联 PR 项。 4. Graduate agent（全量翻完在生产跑 15-30 天以后）：每一个灰度 feature tag 都是 candidate，看哪些 feature 已经验收无误，后完整毕业，翻 default value。 ——以确保一个 feature PR 能在软件生命周期早期被准确监督复核，哪怕他是 agent 的一个随机并且未充分验证的 idea，在这套体系下也几乎不可能犯大错误。而这几阶段中间可能隔了几个小时甚至几天几周，完全不是 continuous 的，也完全不可能被同一个短寿的 agent 接管，那么一定需要有一个 “论坛式的记忆”——PR 评论区就是最好的跨期开发对话记忆载体。