575个PR啃下巨型重构

同步数据库访问这个坑，只有规模大了才会露头。steipete 回头看自己把 OC 迁到 SQLite 时的决定，说最大设计失误就是用了同步的数据库访问。当时那不过是往 Slack 或者 iMessage 给他报个信的单个 agent，同步完全够用。 麻烦在后面。现在一个 agent 能开五十个并发会话，整支团队都押在这套东西上，同步访问就成了天花板。请求串着走，一慢全慢，这不是调优能救的，是当初的选型埋的。 真正让我坐直的是他给出的解法。他给 Astra 一个 /goal，让它把所有同步调用改成异步 worker，五百七十五个 PR，一个接一个落地。改完一段就发一段，团队边重构边拿新版本。最后那句感叹是连巨型重构都不可怕了。 这跟我对大重构的判断不一样了。过去怕的不是工作量，是几百个文件同时动、评审和回归全堵住；现在把目标交给 agent，把切片和验收交给流程，人守着节奏。575 这个数字说明它啃的不是玩具任务。 值得抄的还有验收方式：每落地一段就发布，进度跟着走，不留一个憋了几周的大分支。异步改造和交付节奏被同一套机制捆在一起，出问题随时能回退到上一段。