Agentic Software Maintenance

Agentic Software Maintenance 指用编码 Agent 系统性地承担软件维护工作：清理死代码、下线过期实验与 feature flag、修复 flaky 测试、给 CI 降本。要注意这是一个新兴说法：目前没有完全标准化的行业术语，相近的实践在不同来源里叫法各异（GitHub 的 Agentic Workflows 里有定期的 Dead Code Removal Agent 和 “cleanup specialist” 自定义 Agent，agentic-coding-design-patterns 把它叫 Scheduled Maintenance 模式）。本库用这个词概括这一类实践，标题即取自 OpenAI 的文章《Maintaining software with the GPT-6 family》。

它要解决的问题是真实且随 Agent 普及而放大的：Agent 让团队构建更快，也同步放大了维护需求。传统做法依赖集成运行时日志的复杂静态分析系统，但边界情况太多（反射干扰静态分析、看似无用实则保留作事故缓解的代码路径），误删出过真实事故。

与传统静态分析流水线的差异

维度	传统做法	Agent 做法
触发方式	专门的静态分析系统 + 运行时日志集成	一段短 prompt，按需或定期运行
判定证据	工具产出的分析结果	Agent 自行收集：PR 历史、Slack 讨论、feature flag 平台配置、生产 profiling 表
维护成本	分析系统本身需要开发和维护	prompt 比"整套静态分析系统"更容易开发和维护，可靠性相当（OpenAI 自述）
覆盖面	受限于工具能静态判定的情况	可以处理静态分析难啃的动态场景：跨服务引用、动态拼接的名字、运行时才评估的 eligibility

第二点尤其值得展开：对能力足够的模型，可以给出更宽泛、更含糊的请求，让模型自己决定去哪里找证据、需要什么证据才能支撑每一次删除。OpenAI 用的原始 prompt 带着拼写错误，只有三行（“Can you help identify and clean up dead code in the repo please, feel free to check slack, statsig, or any other source you need to confirm……"）——这种模糊度在上一代模型（GPT-5.6 Sol）身上需要拆成带明确验证标准的定向 prompt 才能可靠完成。

OpenAI Core Experimentation 团队的实测结果

OpenAI 内部做实验支持软件的 Core Experimentation 团队（5 名工程师，用 Codex 配 GPT-6 Astra 与 GPT-6.1 Sol）把这套工作流跑成了量产，累计合并 1,400 多个维护 PR、删除超过 80 万行代码，且大部分工作是兼职在两周内完成的。各类任务的量化收益：

维护任务	结果
死代码清理	一个服务的容器镜像从 3.31GB 降到 1.72GB（−48%）；另一轮清理移除约 400 个视觉快照变体
过期实验（stale experiments）	基于全库审计报告清理数百个实验与 feature flag；其中单个 flag 的移除在受影响主服务上省 0.42% CPU
CI 优化	约 30 个优化 PR；CI 中位完成时间 10 分钟 → 4.5 分钟，p90 从 12.5 分钟 → 6 分钟；一处补上缺失 mock 后，63 个测试的 resolver 套件运行时间从 592.6 秒降到 29.8 秒（−95%）
Flaky 测试	按"只修简单问题、不追求穷尽"的范围约束逐个出 PR

其中过期实验是最难的一类：这些实验的代码可能仍在生产运行、依赖随时可能变化的 eligibility 判定，静态分析几乎无能为力，过去靠确定性脚本 + 数据库查询，且自认存在大量漏报。Astra 的做法是先要一份全库审计报告（见下节 prompt 模式），再用团队的 instrumentation 核实每个候选的 CPU 成本——排名前几的结果是"多年没人识别为过期"的大额效率收益。一个能说明模型判断力的例子：一行多年前写下的 Python 映射代码把某个内部 override flag 指到所有其他 feature flag 上，造成显著的 CPU fan-out；Astra 查了 CPU 成本，但因为该 flag 在管理控制台里被显式标记为 “Permanent”、可能仍有运维用途，把它标记出来交人工评审而不是直接删。评审后确认可删。

工作流骨架

各家实践大同小异，OpenAI 的版本可以概括成一个"小步起步 → 收证据 → 小 PR → 评审反馈回流"的循环：

flowchart LR
    A["选定小维护任务
死代码 / stale 实验 / flaky 测试 / CI"] --> B["短 prompt 起步
或让模型自己写 prompt"]
    B --> C["Agent 自行收集证据
Slack · flag 平台 · PR 历史
生产 profiling · CPU 成本"]
    C --> D["小 draft PR 或报告
附证据、所有者、callsites"]
    D --> E{"人工评审"}
    E -->|"反馈"| F["把评审意见写进下一轮 prompt"]
    F --> C
    E -->|"通过"| G["扩大范围
子目录 → 全库"]

Prompt 模式（可直接复用）

给强模型模糊请求，给弱模型定向请求。模型能力决定 prompt 的抽象层级：GPT-5.6 Sol 需要明确验证标准的定向 prompt；Astra 能从三行含糊请求自己推导出"去哪找、找什么证据”。
让模型替你写 prompt。作者不确定怎么开始 stale experiment 清理时，先与 Astra 头脑风暴、请它起草 prompt 到新线程里试跑；全库扫描的 /goal 长指令也是 Astra 自己生成的。这是把 prompt 工程外包给模型的 meta-prompting。
把安全约束写进 prompt 而不是靠事后拦截：保留 killswitch 类 flag、忽略 SDK fallback 与本地覆盖、不改线上配置与服务、每个清理只开一个小 draft PR 并附 flag 控制台链接、报告按可并行的工作流分组并给出证据与所有者。
用 /goal 这类完成契约框住范围，防止模型产出一份"保守短名单"就收工（OpenAI 在 prompt 里明确写了 “do not stop after producing a conservative shortlist”）。
对低成本模型做错误模式分析，再修正 prompt。对比不同模型档位的产出差异，把高成本模型能发现、低成本模型漏掉的 pattern（如"被其他 flag 当依赖引用的常量 flag"）写成 prompt 修正，让便宜配置逼近贵配置的效果。
新模型发布后重审 prompt：针对旧模型弱点写的 prompt 修正，可能在新模型发布后失效甚至帮倒忙（这与 GPT-6 Astra 词条中"换模型是清理指令的好时机"的建议一致）。

模型/effort 的成本-收益实测

同一份 stale experiment 审计 prompt，在 6,000+ 文件、100 万行（Python/TypeScript/Go/Rust）的子目录上跑三种配置，人工评审确认发现的质量（成本含 research subagents 与 Codex 自动追加的后续轮次，按 API 标准定价）：

配置	API 成本	确认发现数	每个发现成本
GPT-6 Astra Ultra	$109.06	142	$0.77
GPT-6.1 Sol Ultra	$15.12	131	$0.12
GPT-6.1 Sol Medium	$5.27	86	$0.06

GPT-6.1 Sol Ultra 以 14% 的成本拿到旗舰 92% 的发现；Medium 档发现更少但单价最低。结论与 GPT-6 Sol 词条记录的"每任务成本"口径互相印证：先在小任务上对比模型与 effort 组合，便宜配置往往就够；确认有效后再扩到子目录乃至全库。

两点保留意见

这是厂商自报的正向案例，发布在 OpenAI 开发者博客上，无独立第三方核验；“1,400 PR"是合并数，不含被评审否决的部分。
作者自己也承认部分提案"增加的复杂度超过预期收益”，所以在找到机会最多的场景里，优先级排序与收益测量仍必须由人负责——Agent 交付候选，人决定做不做。