background-agents 后台编码会话调度

问题：前台会话被长任务拖住

日常开发里最常见也最浪费的一件事：一次重构、一轮批量 issue 修复，动辄十几分钟甚至更久。让 agent 在前台跑，你只能干等——要么刷着手机等它结束，要么中途切走再回来发现上下文已经凉了。更麻烦的是，代码生成完了没人 review，结果散落在临时目录里，最后还得手工搬回仓库，合并时冲突一片。

background-agents 的思路是把这类工作挪到后台：任务入队，agent 在隔离的沙箱环境里跑，你该开会开会、该写别的分支写别的分支，事后再回来看结果。

工作原理

核心能力可以拆成三块：

• 触发：同一套路由接入多种触发面——cron 定时任务、Sentry 告警、webhook 回调，以及 GitHub、Slack、Linear 的交互入口。任务从哪个地方来，都走同一个队列。
• 排队执行：每个任务拿到一个完整开发环境（Node.js、Python、git、浏览器自动化、VS Code），agent 在其中独立作业，多个会话并行排队而不会互相污染。
• 回收结果：跑完的产出带 review 状态，可以拉回主仓库流程，而不是丢在沙箱里自生自灭。

典型步骤就是：在触发面上提交任务 → 确认它已进入队列 → 期间不阻塞主会话 → 需要时查询进度 → 把通过评审的输出合入目标仓库。

适用边界

这套方案不是白拿的。它要求你已经部署好 background-agents 服务栈，有 GitHub App 或仓库权限，有沙箱基础设施，有模型供应商的凭证，并且目标仓库可达。换句话说，它解决的是“已有 agent 基础设施、缺调度层”的问题，不是给零部署环境开箱即用的玩具。

另外，环境里预装的是特定版本：Node.js 22、Python 3.12、Bun、git、GitHub CLI 和 build-essential。如果你的任务依赖别的运行时，要么它本来就兼容，要么你得自己补进去。