用 Trigger.dev 分析任务成本并优化机器规格…

当需要降低 Trigger.dev 任务/调度/运行的支出、审计用量或调整机器规格时，结合源码静态分析与 MCP 实时运行数据分析给出优化建议。

适用场景

解决思路

1. 先阅读随 SDK 安装的权威成本指南：`@trigger.dev/sdk/docs/how-to-reduce-your-spend.mdx`，以及配套的 `machines.mdx`、`runs/max-duration.mdx`、`queue-concurrency.mdx`、`idempotency.mdx`、`triggering.mdx`、`errors-retrying.mdx`，确保建议与已安装 SDK 版本一致。
2. 确认 Trigger.dev MCP 工具可用：`list_runs`（按状态、任务、时间段、机器规格过滤列出运行）、`get_run_details`（获取日志、时长、状态）、`get_current_worker`（获取已注册任务及其配置）；若不可用，提示用户运行 `npx trigger.dev@latest install-mcp` 安装；没有 MCP 工具时只做静态源码分析，不要编造运行数据。
3. 静态分析步骤 1：扫描任务文件，找出规格过大的机器（无明确需求却使用 `large-1x`/`large-2x`）。
4. 静态分析步骤 2：找出缺少 `maxDuration` 的任务（无执行时长上限，存在成本失控风险）。
5. 静态分析步骤 3：找出重试次数过多的任务（`maxAttempts` > 5 且未对已知永久性失败使用 `AbortTaskRunError`）。
6. 静态分析步骤 4：找出高频触发但缺少 debounce 的任务。
7. 静态分析步骤 5：找出支付/关键任务缺少幂等键（idempotency key）的情况。
8. 静态分析步骤 6：找出用 `setTimeout`/`setInterval`/sleep 轮询代替 `wait.for()` 的写法。
9. 静态分析步骤 7：找出短等待（`wait.for()` 小于 5 秒，不会被 checkpoint，浪费计算资源）。
10. 静态分析步骤 8：找出多个 `triggerAndWait()` 可改为 `batchTriggerAndWait()` 的串行调用。
11. 静态分析步骤 9：找出调度过于频繁的 cron（触发频率超过实际需要）。
12. 运行分析 2a：用 `list_runs` 查询 `period: "30d"`/`"7d"`，找出总计算量高（时长 × 次数）、失败率高、以及大机器但运行时长很短的（过度配置）任务。
13. 运行分析 2b：用 `list_runs` 过滤 `status: "FAILED"`/`"CRASHED"`，区分瞬时（可重试）与永久性失败，对后者建议使用 `AbortTaskRunError`，并估算被浪费的重试计算量。
14. 运行分析 2c：对样本运行调用 `get_run_details`；若 `large-2x` 任务持续运行不到一秒，或属于 I/O 密集型（API/DB），则说明规格过大。
15. 运行分析 2d：用 `get_current_worker` 列出 cron 模式，标记对其用途而言过于频繁的调度。
16. 生成按优先级排序的报告并估算影响，分高/中/低三档，附具体代码修改建议（如 `machine: { preset: "small-2x" }`、`debounce: { key: \`user-${userId}\`, delay: "5s" }`、`maxDuration: 300`）。
17. 参考机器预设相对成本：micro 0.25x、small-1x 1x（基准）、small-2x 2x、medium-1x 2x、medium-2x 4x、large-1x 8x、large-2x 16x。
18. 遵循关键原则：超过 5 秒的等待免费（checkpointed，不计计算费）；从小规格起步再扩；I/O 密集型任务不需要大机器；debounce 对高频任务最省；幂等可防止重复计费；`AbortTaskRunError` 可停止无谓重试。

适用边界 · 注意事项

• 未安装 Trigger.dev MCP 服务器时无法做实时运行分析（仍可做静态源码分析，但不要编造运行数据）。
• 不适用于非 Trigger.dev 的任务系统或未使用 `@trigger.dev/sdk` 的项目。