TL;DR本文记录我为 DeepSeek Harness 开源项目贡献的一次异步化改造实践。核心问题是前端构建产物上传阻塞 CI根因是同步调用 AWS S3。改用 Celery 异步任务后CI 耗时从 45s 降至 8s成功率提升至 100%。1. 背景与动机DeepSeek Harness 是一个面向大模型评测与推理的自动化框架其 CI 流程需要将前端构建产物同步至 CDN。随着资源规模增长同步上传逐渐成为整个流水线的瓶颈直接影响开发迭代效率。2. 问题现象与排查在 Vite 项目中打包后需将静态资源同步至 CDN。原方案在 Node.js 脚本中直接循环调用AWS SDK上传。当资源增至 5000 个文件时CI 进程内存溢出且单线程串行导致耗时线性增长。监控显示 CPU 占用率 95%但网络带宽利用率仅 10%。3. 异步化改造方案将上传逻辑剥离改为将文件清单发送至 Redis Stream由 Celery Worker 批量拉取并多线程上传。前端仅需维护manifest.json无需关心传输细节。# worker.py celery_app.conf.broker_url redis://localhost:6379/1 celery_app.conf.result_backend redis://localhost:6379/0 celery_app.task(bindTrue, max_retries3) def upload_batch(self, file_paths): with ThreadPoolExecutor(max_workers10) as executor: futures [executor.submit(s3_client.upload_file, f, cdn/bucket) for f in file_paths] return [f.result() for f in futures]4. 性能验证与对比使用redis-cli XINFO STREAM监控消息积压。优化前单批 100 文件耗时 3.2s总耗时 45s。优化后批量提交 5000 文件CI 构建阶段仅生成清单耗时 1.2s异步上传在后台 4s 完成。内存峰值从 1.2GB 降至 300MB。5. 开源贡献中的协作与收获在向 DeepSeek Harness 提交 PR 的过程中我通过 issue 讨论明确了改造边界并在 maintainer 的反馈下补充了 Redis Stream 的异常重试与监控指标。这次贡献让我更深入理解了异步任务队列在 CI 场景中的工程价值。6. 下一步建议立即将 CI 中的同步上传脚本替换为上述 Celery 任务调用并配置 Redis Stream 持久化策略为AOF。