Astro的GitHub问题积压量五年来首次趋近于零。如今，Cloudflare将这一功臣工具开源。
内容提要
Astro开源项目利用AI代理工具triagebot-action自动处理GitHub问题，将积压从200多个降至约20个，预计下月清零。该工具分四阶段：复现、诊断、验证和修复，由独立代理执行，并已开源供其他维护者使用。团队强调分诊优先，修复难度高，未来可能实现自主合并请求。
延伸解读
AI分诊为何先于自动修复
Astro团队选择优先实现问题分诊而非自动修复，因为分诊是维护者最耗时的环节，且AI代理在此任务上表现稳定。修复代码的质量门槛极高，难以保证可合并性，因此团队将修复视为次要功能，先确保分诊的可靠性，再逐步提升修复能力。
开源工具的实际采用情况
triagebot-action目前仅Astro在生产环境使用，Cloudflare的workers-sdk团队正在内部试用。该工具及其底层框架Flue均不依赖Cloudflare特定技术，可运行于任何基础设施，这降低了其他项目采用的门槛，但广泛采用仍需时间验证。
维护者保留最终决定权
尽管AI代理能自动复现、诊断并尝试修复问题，但所有输出仍需维护者审核。Schott强调，修复是否被接受完全由维护者决定，AI生成的代码可能质量不足，维护者可能选择自行编写修复。这确保了项目质量，但也意味着AI并未完全取代人工。
Q&A
Astro项目是如何将GitHub问题积压从200多个减少到约20个的？
Astro团队开发了一个名为triagebot-action的AI代理工具，作为GitHub Action运行。当有人提交issue时，它会启动一个四阶段流水线：在沙盒中复现bug、诊断根本原因、验证是否为真实bug、尝试修复。每个阶段由独立的AI代理处理，整个过程由GitHub标签编码的状态机驱动。通过这种方式，Astro将问题积压从年初的200多个减少到约20个，并预计下月清零。
triagebot-action的四个阶段分别是什么？
triagebot-action的四个阶段是：1. 复现（在沙盒中复现bug）；2. 诊断（诊断根本原因）；3. 验证（验证是否为真实bug）；4. 修复（尝试修复）。每个阶段由独立的AI代理处理，整个过程由GitHub标签编码的状态机驱动。
为什么Astro团队优先实现问题分诊而不是自动修复？
Astro团队优先实现问题分诊是因为AI代理在分诊方面表现出色，且分诊对维护者来说非常耗时。自动修复的难度很高，因为修复代码需要达到可合并的质量标准，而分诊只需完成阶段任务即可。因此，团队先实现了分诊自动化，修复功能作为次要目标逐步完善。
triagebot-action的修复阶段为什么最难？
修复阶段最难是因为它要求AI代理写出足够高质量的代码，能够被合并到项目中。其他阶段（复现、诊断、验证）只需完成各自的任务，而修复必须达到可合并的标准，这需要高水平的代码质量和正确性。因此，修复是系统中最难的部分。
Cloudflare收购Astro后，Astro团队和项目发生了什么变化？
Cloudflare于2025年1月收购了Astro背后的公司，但Astro团队仍然独立运作，拥有自己的路线图和发布节奏。团队仍有四名全职工程师，包括联合创始人Fred Schott，所有通过收购加入的成员都继续全职参与项目。Astro项目继续发展，例如在1月发布了Astro 6测试版，并推出了triagebot-action工具。
triagebot-action是否依赖Cloudflare特定的技术？
不依赖。triagebot-action及其底层代理框架Flue都设计为可在任何基础设施上运行，没有对Cloudflare特定工具的依赖。目前只有Astro在生产环境中使用它，但Cloudflare的workers-sdk团队正在内部试用。
triagebot-action的未来发展方向是什么？
未来发展方向是逐步提升自动修复的能力。目前系统已经能够从无修复能力，发展到在分支上留下建议修复，再到直接打开拉取请求。未来可能让代理自行判断信心或修复规模，并最终自主打开甚至合并拉取请求。但修复的最终决定权仍在维护者手中。
Cloudflare最近还开源了哪些与AI代理相关的工具？
Cloudflare在发布triagebot-action之前，于7月底开源了pvcli，一个用于隐私协议调试的命令行工具，它被明确设计用于基于代理的调试。这两个工具都体现了将传统需要人工操作的工作打包成AI代理可自主执行的软件的理念。
