在整个集群中并行运行一条 AWS CLI 命令：数百个账户在几秒钟内安全完成。一个命令同时在每个账户和地区分发（默认 100 个并行工作线程，--concurrency 可提高这个数量），在任何操作运行之前验证身份，将结果合并为一个流。不再有需要咖啡休息的 shell 循环来遍历整个集群。并且任何会导致变更的操作会被审批边界阻止，即使是拥有您管理员凭据的 AI 代理也无法绕过。这段演示是在捆绑的 100 账户沙箱集群上进行的真实终端；您可以通过一次命令自己重放它：make build fleet-up 。对于代理来说，这在计量上更便宜也更快。在一个 150 次会话、三个臂的基准测试中（相同的 Claude Opus 4.8 代理，相同的提示，100 个账户相同的集群），awsmux 的执行比原始 shell aws CLI 的执行在每个单元中都更便宜更快：1.3 倍到 2.9 倍更便宜，2.3 倍到 5.4 倍更快，输出令牌减少至 7.4 倍，在明确的 4 次轮次中无论集群大小（CLI 单元仅在 10 个账户时匹配，然后增长至 10.5；成本和输出令牌的差异均经过 Holm 调整 p < 0.05）。在 150 次会话中有 138 次通过了环境验证，所有 12 次排除都是 awsmux 自身的过失：在并发下的 MCP 启动竞争，所以它们完全落入了带有 MCP 的臂内。任务集群每次运行的成本（cli 与 awsmux）的墙时间列出所有 VPC 10 个账户 $0.090 vs $0.068 (1.3x) 34s vs 13s 列出所有 VPC 50 个账户 $0.239 vs $0.120 (2.0x) 84s vs 23s 列出所有 VPC 100 个账户 $0.274 vs $0.193 (1.4x) 94s vs 41s 查找全球开放组 50 个账户 $0.229 vs $0.079 (2.9x) 75s vs 14s 查找全球开放组 100 个账户 $0.152 vs $0.098 (1.5x) 90s vs 17s 完整设计、统计和注意事项：docs/BENCHMARK.md 。在 100 个账户上试用（都不是实际账户）前提条件：Go，Docker 和 aws CLI。 make build fleet-up && source .tmp/fleet/env.sh 这将构建 ./bin/awsmux，启动一个固定的 LocalStack 容器，并配置一个虚构的 100 账户集群（10 个团队，生产和阶段，5 个分片，3 个地区）以供娱乐。真实的 aws CLI 与本地的真实模拟 AWS 通信，每个配置文件是其自己的账户（加上一个种植的管理员遗留副本用于 --dedupe 捕获），您所进行的更改会实际保留。零凭据，零真实 AWS，零风险。 ./bin/awsmux targets --profiles ' payments-* ' # 验证身份，每个账户 ./bin/awsmux run --dedupe --format jsonl -- ec2 describe-vpcs --query ' Vpcs[].VpcId ' # 所有 100 个账户在几秒钟内 ./bin/awsmux run --profiles ' *-prod-* ' -- ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0 # 查找全球开放组 ./bin/awsmux plan --profiles payments-prod-1 -- ec2 revoke-security-group-ingress --group-name legacy-bastion --protocol tcp --port 22 --cidr 0.0.0.0/0 最后一个是破坏性的，因此它不会直接运行：您首先会得到一个不可变计划以供审批。用令牌应用它并重新运行查找；结果会真实消失，因为沙箱是一个真实（模拟的）AWS。尝试在审核和应用之间编辑计划文件，看看哈希检查会拒绝它。 make e2e 构建二进制文件，配置集群，并从 STS 验证的发现通过审批门到计划 / 审批 / 应用往返和哈希拒绝的一次篡改计划（完整列表在 docs/ARCHITECTURE.md 里）； make fleet-down 移除容器。真实集群 相同的命令，指向您自己的 AWS 设置，而不是沙箱环境。零配置：awsmux 从您现有的共享配置文件（~/.aws/config）和共享凭据文件（~/.aws/credentials）中发现配置文件，遵守 AWS_CONFIG_FILE 和 AWS_SHARED_CREDENTIALS_FILE。SSO、静态密钥和 credential_process 配置文件的工作保持不变，因为 awsmux 始终通过 aws CLI 执行并在运行任何操作之前验证每个身份： awsmux doctor # 第一次运行？ 验证 aws CLI，文件，配置文件 awsmux targets --regions us-east-1,us-west-2 awsmux run --profiles ' prod-* ' --exclude ' *-sandbox ' --format jsonl -- ec2 describe-instances --query ' Reservations[].Instances[].InstanceId ' awsmux plan -- ssm put-parameter --name /app/flag --value on --type String awsmux approve plan-01k... # 打印一次性令牌，永不存储 awsmux apply plan-01k... --approval-token < token > 没看到您的配置文件？ awsmux doctor 显示检查了哪些文件，每个文件贡献了多少配置文件，以及 aws CLI 和状态目录是否可用。 awsmux targets 报告每个配置文件来自哪里（表格模式中的 SOURCE 列，jsonl 中的源字段：配置、凭据或两者）。 在运行时和应用/重放时，除非特别注明，实用的标志： --concurrency (默认 100: 整个集群并行处理是重点；每个正在进行的目标都是一个 aws CLI 子进程)， --timeout 30s， --max-errors N， --stop-on-access-denied， --output-dir (每个 tar 的一个结果文件