2026 年 8 月，Cloudflare 公开了其内部实践：一组隔离运行在 GitHub Actions 中的 AI 智能体，在 Astro 开源仓库里完整接过了问题分类与修复流程，将未解决问题从 200 多个压缩到约 30 个。这不是实验室 demo——这是每天都在真实仓库里运行的维护流水线。
report.md 传递结论，不共享上下文，错误不会传染。Astro 是近两年最受欢迎的静态站点框架之一，Issue 堆积曾是维护者的日常负担。每个 Bug 报告都要经历手动复现、根因猜测、反复询问报告人，再被搁置数月。
Cloudflare 决定让一组 AI 智能体把这套流程整个接过去。
手动复现 → 猜测根因 → 反复沟通 → 修复遥遥无期
自动复现 → 插桩定位 → 测试验证 → 预览版本 + PR 自动生成
注：约 85% 是依据「200+ → 约 30」的数量级推算的约数，并非官方公布的精确统计口径。
数字背后，是一套把维护者经验拆解为流水线的工程实践。它没有发明新的维护策略，只是把维护者头脑中隐性的判断过程显性化了。
这套流水线没有让一个巨型智能体包揽所有事。
它复刻了维护者手动处理问题时的完整步骤——每一步都由一个独立的子智能体执行。
验证上报的现象是否真实存在，排除伪 Bug，确保后续环节不白跑。
对代码插桩定位，追踪运行时行为，锁定问题根源。
核对测试用例、文档与注释，确认对问题的理解没有跑偏。
先把复现场景固化为测试用例，再实施修复，防止“修了 A 坏了 B”。
最值得注意的设计是信息传递方式：所有智能体不共享执行上下文，只通过 report.md 传递结论。每个阶段的输入、输出边界都清晰可查，错误不会在链路中无声传染，任何一个环节都可以被人工介入检查。
注：这四个环节对应的正是人类维护者从「它能复现吗」到「这么改行不行」的完整思考顺序。
整个工作流被实现为一台状态机。状态流转由一个 GitHub Issue 标签驱动。
新提交的问题自动被打上 triage needed 标签；当修复方案被确认有效，问题流转为 fix verified；上报者验证补丁后，自动化流程创建拉取请求。每一个状态变化都记录在 Issue 时间线上。
这套系统并非全知全能。
它甚至会在简单的问题上反复横跳。
一次热模块替换相关的案例中，由于对应逻辑缺少足够的测试用例，智能体反复修改同一处条件判断，不断引入功能退化。开发者在关键位置补了一行描述性注释后，智能体的行为随之改变，不再反复修改。
Cloudflare 把这类失败看作代码库可维护性的信号——测试用例与代码注释不是文档负担，而是智能体稳定运行的地基。
注：以上日志为基于公开描述的示意性重建，非真实日志原文。真实日志随 Issue 时间线公开可见。
Astro 工作流后来演化成两个独立项目：可直接接入任何 GitHub 仓库的 triagebot-action，和通用声明式智能体编排框架 Flue。
开发者声明上下文（模型 / 技能 / 沙箱 / 指令），而非编写编排循环。
仅追加事件日志，工作流中断后可从上次状态继续运行。
可接入 GitHub、Slack、Linear 与 Discord，从 Issue 到 IM 全覆盖。
支持 Node.js、GitHub Actions 与 Cloudflare 基础设施。
在 Cloudflare 平台上，智能体可以作为 Durable Objects 运行，获得持久化执行与隔离存储。Astro 的问题分级流水线，只是 Flue 通用模型的一个实例。
有边界的智能体任务 + 持久化状态 + 外部事件 + 人工审批节点——这就是 Flue 给出的高可靠软件工作流公式。
这套做法在开发者社区里引发了不少讨论。
「先复现问题，再诊断问题；让上报者能方便地测试修复方案——这两条原则救了整个流程。」
「这是显式智能体系统设计的典型范例，而不是又一个依赖智能体循环抽象的黑盒 demo。」
「意义不止在于让 AI 验证问题，而在于在沙箱中运行智能体任务——审核人员看到的，基本都已经是经过自动化处理的结果。」
智能体维护开源项目的真正价值，不是替维护者干了多少活，而是把「判断一个问题」这件最依赖经验的事，变成了可复现、可审计、可改进的工程流程。但它的地基依然是测试与注释——AI 能加速一切，唯独不能加速对代码库的理解。
Astro 工作流已沉淀为两个开源项目，可直接接入你的仓库。