在大规模 AI 代理实际部署之前，进行充分的测试验证是确保系统稳定性的关键环节。传统单代理测试模式在面对数百个独立任务场景时暴露出了显著瓶颈：顺序执行导致时间成本线性增长，上下文累积引发推理质量下降，失败定位困难等问题层出不穷。Imbue 公司近日发布的mngr工具给出了 一种工程化的解决方案，通过 manager-worker 架构与宿主机无关的沙箱调度机制，实现了百级 Claude 代理的并行运行与统一管理。

核心架构：manager-worker 模式与宿主机无关设计

mngr的设计理念围绕 “manager-worker”（管理器 - 工作器）模式展开，其核心创新在于彻底解耦了代理运行与底层计算资源的耦合关系。从架构层面来看，mngr 将每一个 Claude 代理视为一个独立的工作器实例，每个实例运行在隔离的沙箱环境中，而管理器则负责统一的任务分发、状态监控与结果聚合。

这种架构的关键优势体现在四个层面。首先是沙箱的自动生命周期管理：当工作器完成指定任务并进入空闲状态后，mngr 会自动关闭对应的远程沙箱以释放计算资源，同时对关闭前的系统状态进行快照保存，以便后续调试或恢复。其次是计算平台的无感知切换：用户只需修改--provider参数即可在 localhost、Docker 容器、Modal 云沙箱或任何支持 SSH 的远程主机之间自由切换，当前运行逻辑保持不变。第三是状态的可持久化访问 —— 即使代理已离线，用户仍可通过mngr file命令浏览其文件系统并获取运行数据，这对于大规模并行测试后的离线分析至关重要。第四是模型无关的通用性：由于 mngr 底层将代理实现为 “运行在 tmux 会话中的 Unix 进程”，因此不仅支持 Claude Code 和 Codex，理论上任何具有消息交互机制的 AI 程序乃至 nginx 等传统服务均可纳入同一套调度框架。

具体而言，当执行mngr create worker-123@host-456 --template parallel --message-file input.txt claude --provider modal这一命令时，管理器会在指定的 Modal 沙箱中启动一个隔离的 tmux 会话，并在其中初始化 Claude 代理实例，随后将输入文件中的任务描述作为初始消息注入。整个过程对用户呈现的是完全透明的并行语义，而非底层的网络通信细节。

并行执行模式：xargs 与 Map-Reduce 的融合实践

Imbue 展示的百级并行测试方案采用了经典的分治策略，其核心命令如下：使用seq生成任务序号序列，通过split将大规模任务列表拆分为独立的执行单元，最后借助xargs -P 100实现百并发度的任务分发。这一设计在形式上与 Unix 管道哲学一脉相承，但在工程实现上融入了对 AI 代理特性的深度适配。

传统的并行执行面临的核心困境在于代理上下文窗口的限制 —— 当单个代理被要求同时处理数百个任务时，其上下文会急剧膨胀，导致推理成本激增且输出质量劣化。mngr 的解决思路是将 “巨大的任务列表” 转化为 “数百个独立的小任务”，每个代理仅需处理单一任务或少量任务。这种 Map-Reduce 风格的设计确保了每个代理的上下文规模可控，同时通过 Reduce 阶段的聚合将分散结果整合为统一的测试报告。

在实际工程部署中，建议采用以下参数配置作为初始基准：并发度设定为处理器核心数的 2 至 3 倍（例如 8 核机器可尝试-P 20），每个任务配置独立的输入文件以避免文件锁竞争，任务完成后立即触发mngr wait命令监听 PAUSED、STOPPED、CRASHED、FAILED 等终态，最后通过 git 的 branch 管理机制将各代理产生的结果分支合并至主仓库。对于更大规模（千级）的测试场景，可进一步引入任务分层的两层架构：顶层管理器负责将任务粗粒度分配至多个代理组，每组内部再进行细粒度的任务拆分与结果合并。

任务调度与生命周期管理

mngr 为每个代理实例定义了一套完整的状态机模型，涵盖 CREATING（创建中）、RUNNING（运行中）、BLOCKED（阻塞等待用户输入）、PAUSED（任务完成或主动暂停）、STOPPED（已停止）、CRASHED（异常退出）和 FAILED（执行失败）等状态。这套状态机是实现可靠任务调度的基石：管理器通过轮询机制持续监控所有工作器的状态转换，一旦检测到 CRASHED 或 FAILED 状态即可触发告警或自动重试策略。

在任务调度层面，mngr 支持两种主流模式。第一种是批量分发模式：预先定义好所有任务的输入文件，然后一次性启动全部代理实例，适用于任务列表已知且总时长可预估的测试场景。第二种是流式分发模式：维持固定数量的活跃代理，新任务到达时自动复用已完成任务的沙箱资源，适用于持续涌入的测试用例流。两种模式可以结合使用 —— 先用批量模式完成基础测试集的覆盖，再切至流式模式处理回归测试。

对于失败处理机制，mngr 的设计哲学强调 “隔离失败、快速定位”。当某个代理出现异常时，其状态会被标记为 CRASHED 或 FAILED，但不会波及其他并行运行的任务。用户可以通过mngr connect命令直接 “跳进” 该代理的 tmux 会话进行交互式调试，也可以通过mngr transcript查看完整的消息历史以定位问题根因。这种设计避免了传统单代理方案中 “一点失败、全局停滞” 的脆弱性。

可观测性与调试：大规模并行的必备能力

当并行度达到百级规模时，可观测性设计直接影响问题排查效率。mngr 提供了一系列内置命令来支撑这一需求。mngr list以表格形式展示所有工作器的当前状态、所属宿主机、运行时长等关键指标，支持按状态过滤以快速定位异常实例。mngr transcript可以获取指定代理的完整消息历史，这对于复现特定测试用例的失败路径尤为重要。mngr capture命令则相当于为当前会话拍摄 “快照”，在代理卡死或行为异常时保存完整上下文供后续分析。mngr file允许在代理离线后访问其工作目录的文件系统，这对于批量收集各代理生成的测试产物或日志文件极为实用。

此外，Imbue 还提供了名为mngr_kanpan的 TUI（文本用户界面）插件，以看板视图呈现所有代理的状态概览，支持通过快捷键与单个代理进行交互。这对于持续监控大规模并行测试的运行状态提供了直观高效的交互方式。

在实际工程实践中，建议将可观测性建设与测试流程同步规划：为每个测试任务分配唯一标识符（如 worker 编号），将代理输出写入结构化的 JSON 或日志文件，并在 Reduce 阶段编写专门的解析器来生成汇总报告。对于关键的失败场景，可配置自动告警机制（如 Slack 通知或邮件提醒），并保存失败代理的完整 tmux 会话转录文件以供离线调试。

实用部署参数与工程建议

基于 Imbue 公开的实践案例，以下参数配置可作为生产环境的起始参考。并发数量方面，初期建议以 CPU 核心数的 2 至 3 倍进行小规模验证，确认稳定后再逐步提升至目标规模（如 100 至 1000）。沙箱类型方面，本地开发调试推荐使用--provider local，其利用 git worktree 实现轻量隔离；大规模正式测试推荐使用--provider modal，可在云端弹性扩展的同时保持计费的精细可控。结果聚合方面，推荐为每个代理创建独立的 git 分支（如mngr/test_001、mngr/test_002），测试完成后通过脚本批量合并分支，既保留了完整的变更历史，也便于在 Pull Request 层面进行代码审查。

值得关注的是，mngr 的整个调度框架建立在 tmux 会话管理之上，这意味着其对网络延迟具有一定容忍度 —— 即使远程沙箱与本地管理器之间的网络连接出现短暂中断，已创建的代理仍可继续独立运行，管理器重连后可通过状态同步恢复监控能力。这一特性对于跨地域的分布式测试场景具有实际价值。

参考资料