多路 AI 编码 Agent 同时跑构建，怎样避免互相拖垮？load-lock 用机器级信号量排队
当 Claude Code、Codex CLI 和 OpenCode 同时在一台开发机上工作，真正的瓶颈未必是模型，而可能是本机的 CPU、内存与磁盘缓存。多个 Agent 一起执行测试、编译或打包，容易争抢资源；把每个任务都串行化虽然简单，却也让 Agent 在等待期间无事可做。
load-lock 提供一个更细的协作原语：机器范围的计数信号量。各客户端在重型工作开始前申请 permit；容量用尽时进入队列，可以继续做轻量工作，轮到自己时再领取许可，任务结束后释放。它是协作式、建议性的协调机制，不会自动识别任意命令，也不会强行拦截未接入的程序。
它解决的是跨会话的本机资源争用
传统上，Agent 的会话、仓库甚至 worktree 相互隔离，但它们仍共享同一台机器。load-lock 把预算放在机器级别：README 描述的默认池名为 heavy，容量为 1；不同 harness 的客户端使用同一池时，就不会各自误以为自己独占资源。
基本生命周期是“申请—排队或获准—执行—释放”。队列采用 FIFO；容量释放后，等待者收到一个有时限的 offer，需要在窗口内 claim。若错过窗口，客户端可以重新加入队列。项目文档也说明了崩溃场景的恢复与 heartbeat lease 权衡，因此生产使用时仍需考虑客户端失联和租约配置，而不能把它当成操作系统级强制锁。
安装与接入
项目 README 要求 Node.js 20 或更新版本，npm 包名为 @aron98/load-lock，可全局安装：
npm install -g @aron98/load-lock load-lock install --harness opencode
安装器支持多种 harness；上面只展示 README Quickstart 明确列出的 OpenCode。项目还提供 Claude Code、Codex CLI 的 MCP 工具和会话钩子，并可让其他 MCP 客户端连接通用 stdio server。对于普通 shell，README 给出的 run 辅助命令会包住一条明确指定的工作命令：
load-lock run --reason "nightly build" -- npm run build
这适合先把 CI 之外的重型本机任务纳入统一预算。不要期待它自动判断 npm run build 是否“重”：调用方要明确接入，其他未使用客户端的任务也不会自动受管。
从容量 1 开始，逐步调整
小团队可以先把编译和完整测试套件放入同一个 heavy 池，观察排队是否减少缓存抖动，再依据硬件能力调整容量。容量不应照抄其他机器的设置：CPU 核数、内存、磁盘速度以及测试的并行度都会影响合适值。
还要区分重型与轻型工作。申请 permit 后，Agent 可在排队时继续分析代码、整理测试计划或检查文档；但任务真正开始前必须完成 claim，结束时应释放。若只在提示词里约定“先申请”，没有让 Agent 使用接入工具，协调就只是约定，不是约束。对于重要任务，应在团队的 Agent 指令或工作流中明确何时调用 load-lock run，并检查异常退出时 permit 的清理情况。
适合何时采用
load-lock 的价值不在于提升单次构建速度，而在于让多个 Agent 对共享资源形成一致预期。它适合一台开发机上并行运行多个编码会话、测试耗时且缓存敏感、又不希望把所有工作完全串行的场景。相反，如果任务分散在多台独立主机，或者所有重任务都由已有 CI 队列统一调度，机器级本地信号量就未必是主要解法。
项目当前 README 将核心 daemon、协议和 CLI 标为已实现，并提及 68 项自动化测试；不同 harness 的适配状态并不完全相同，应查看兼容性说明再推广。npm registry 与仓库 package.json 均确认当前包版本为 1.5.0、MIT 许可证及 Node.js >=20 要求。版本、安装器覆盖范围会变化，部署前以发布页和当前文档为准。
相关链接