Skip to main content

用三种竞争策略降低结账延迟

让 3 个并行 Devin 会话与一个缓慢的结账 API 展开竞赛——每个会话尝试不同的优化，然后将最佳方案上线。
AuthorCognition
CategoryDevin 优化
Features高级
1

明确问题及成功标准

你的 checkout API（POST /api/checkout）的 p99 延迟为 1.8 秒——用户正在放弃购物，而你的 SLA 目标是 400ms。要修复它，有多种有效方式：缓存、查询优化、异步处理、连接池。在真正尝试之前，你无法知道哪种效果最好，而依次尝试这些方案将意味着等待数天。相反，你可以使用 Advanced Devin 并行启动 3 个会话，每个会话探索一种不同的策略。3 个会话全部完成后，Advanced Devin 会比较结果并将最优方案发布——或者将各个方案中最好的部分合并到一个单独的 PR 中。要开始使用，请在 Devin 主页 的 agent 选择器中选择 Advanced，然后点击 Start Batch Sessions 选项卡。
2

编写一个提示，使每次会话都朝向不同的修复方案推进

运行 3 个会话的价值取决于每个会话是否真正探索了一种彼此截然不同的方案。编写提示时要鼓励多样化探索——给出具体策略，并定义什么是“最佳”，这样结果才能直接进行对比。编写优质多策略提示的建议：
  • 用排序后的标准定义“最佳”。 列出对比维度——延迟、错误率、复杂度、一致性——可以避免 Devin 只默认追求速度本身。
  • 提出具体策略选项。 像 “caching, query rewriting, async processing” 这样的选项，可以引导每个会话走向不同的优化路径。
  • 包含基准测试命令。 每个会话都需要一种可复现的方式来衡量自己的结果——如 npm run bench、k6 run load-test.js，或一个简单的 curl 循环。
  • 指向具体代码。 像 src/routes/checkout.ts 这样的文件路径，可以确保 3 个会话都从同一个起点出发。
3

比较结果并选出最佳方案

当 3 个会话全部完成后，Advanced Devin 会根据你的评估标准，将它们的成果进行并排审查——包括采用的策略、基准指标、权衡取舍——然后要么选出最佳方案，要么将多个方案综合成一个最终 PR。下面是针对结账延迟问题的对比结果示例：
会话 1 — Redis 响应缓存
  策略：      将序列化的购物车 + 库存查询缓存至 Redis，
              TTL 30 秒，重复请求绕过数据库
  p99：       1.8s -> 320ms（通过 — 降低 82%）
  错误：      无变化
  复杂度：    +1 个依赖项（ioredis），2 个新文件
  权衡：      库存数据最多延迟 30 秒；占用 40MB Redis 内存

会话 2 — 查询优化 + 连接池
  策略：      将 N+1 查询替换为单次 JOIN，添加 PgBouncer
              连接池（25 个连接）
  p99：       1.8s -> 580ms（失败 — 仍高于 400ms）
  错误：      无变化
  复杂度：    0 个新依赖项，查询更简洁
  权衡：      无显著影响 — 整体降低数据库负载

会话 3 — 异步订单处理
  策略：      将支付处理和邮件发送移至后台队列
              （BullMQ），库存检查完成后立即返回 202
  p99：       1.8s -> 190ms（通过 — 降低 89%）
  错误：      无变化
  复杂度：    +1 个依赖项（bullmq），3 个新文件，webhook 处理器
  权衡：      结账流程变为最终一致性；需要 webhook
              确认支付结果

结论：会话 1 和会话 3 均达到 400ms 目标。会话 2 的
查询优化有价值，但单独使用仍不足。

最终 PR：将会话 2 的查询优化（零成本，纯收益）与
会话 3 的异步处理相结合。支付 + 邮件移至队列，
N+1 查询已修复。最终 p99：150ms。PR #412 已创建。
在 Advanced Devin 创建汇总 PR 之前，你可以先审查每个会话各自的 PR。如果你更倾向于其中一种方案，只需告诉 Devin — “采用第 3 次会话的方案，跳过合并。”
4

何时在同一问题上并行运行 3 种策略

适用场景 — 存在多种可行方案时：
  • 性能瓶颈问题，可以通过缓存、查询调优或架构调整等多种方式解决
  • 需要权衡取舍的架构决策（如从单体拆分、重新设计状态管理）
  • 针对海量数据问题的算法选择（不同索引方式、排序策略或 ML 方法）
不适用场景 — 解决方案非常显而易见时：
  • 具有明确根因的 Bug 修复
  • 添加一个标准的 CRUD 接口
  • 更新依赖或配置文件
此模式会使用单次会话 3 倍的 ACUs。仅在那些否则你可能需要花上几天时间依次尝试不同方案的问题上使用。对于简单任务，单次 Devin 会话更快且更省成本。你也可以通过在 API 中 将 advanced_mode 设置为 batch 来触发批量会话——非常适合集成到 CI 流水线中，让其自动并行尝试多种修复方案来应对性能回归。如果你希望 Devin 完全自主运行，而不必等待你对方案的批准，可以启用 bypass permissions 开关，让会话自动批准并持续推进。