Fleet 并行执行框架：大规模管理 AI 编码代理的实战拆解
管理 AI 编码代理的规模化实践：Fleet 的并行执行框架
AI 写代码不只是模型够强就行，关键在于怎么协调它们。有人试过同时跑 50 多个 Claude Code 会话，发现开发速度确实上去了，但问题也来了——这么多代理一起干活，怎么避免互相干扰？
Fleet 就是为了解决这个问题而生的。它是一个 Python 工具，把「并行跑 AI 代理」这事儿变成了可操作的日常工作流。
多个代理同时跑，问题出在哪？
你要是自己试过同时开几个 AI 编码助手，大概率会遇到这些麻烦：任务怎么分配？代理之间怎么不踩脚？token 用得飞快，怎么跟踪消耗情况？
最简单的做法——在不同目录开几个 Claude 会话，然后听天由命——很快就会乱套。你需要一个统一的系统，能看清任务之间的依赖关系、优先级，还有整个代码库的状态。
Fleet 的核心思路：集中管理
Fleet 通过三个设计解决了这个问题：
1. 所有任务放一个队列
Fleet 把任务统一存在 ~/.fleet 目录里的 beads 数据库（一个基于 Git 的 issue 跟踪器）里。当你用 fleet bd create 创建任务时，它会同时记录任务内容和所在目录。每个代理启动时都能拿到正确的上下文。
这样一来，多个代理可以各自认领任务、独立工作，最后把结果合并，不会产生冲突或重复劳动。
2. 支持多种代理模型
Fleet 不绑定某个特定模型，目前支持：
- Claude（用得最多）
- Agy/Antigravity（简单测试过）
- Codex（已实现但还没充分测试）
换个模型只要几分钟。这点很重要，因为不同模型擅长不同的事儿——架构设计可能 Claude 更强，写样板代码可能新模型更快。你可以给每个任务指定用哪个模型。
3. 控制并发数量
默认最多同时跑 3 个会话，你也可以调到 10 个以上：
fleet config set max_concurrent=10
fleet bd create --title "重构认证模块" --description "..."
fleet bd create --coder agy --model opus --title "写 API 测试" --description "..."
Fleet 会自动排队，保证不超过你设置的并发上限。真正的瓶颈往往不是工具，而是你订阅的 token 额度。
几个好用的命令
Fleet 的命令行界面简单实用：
fleet tasks—— 查看正在跑的任务、用了哪个模型、实时 token 消耗fleet task <id> log—— 查看代理具体做了什么fleet task <id> plan—— 看代理执行前的计划fleet task <id> knowledge—— 检查代理拿到了哪些上下文fleet config show|set—— 随时调整配置
没有花里胡哨的界面，就给你需要的信息。
现实问题：token 才是瓶颈
说实话，限制你的从来不是能跑多少代理，而是 token 额度。
用 Fleet 比较多的人发现，单纯增加代理数量很快就会撞上限。他们的做法是：用多个 Claude 账号轮换 token，同时严格控制上下文长度。
后者其实更重要。他们检查过 CLAUDE.md 文件、插件目录和技能库，发现有些内容被重复加载了两次，白白浪费 token。清理这些之后，效果比多开几个代理还明显。
为什么这个思路值得关注
Fleet 改变了我们对 AI 辅助开发的理解。它不是把代理当单个工具用，而是把它们当成一个团队来协调：
- 基于规格的开发变得可行 —— 你写好详细的需求，Fleet 把子任务分给不同代理，它们通过共享队列协作。
- 上下文变成可管理的资源 —— 集中跟踪任务，每个代理只关注自己需要的部分。
- 实验更容易做 —— 想对比 Claude 和 Agy 在基础设施代码上的表现？用同一个任务规格并行跑两个模型，直接看结果。
实现并不复杂
Fleet 真正厉害的地方在于它不复杂。最初版本就是一个 bash 循环在监控 beads 队列。Python 版本只是加了任务依赖、优先级、并发控制和代理生命周期管理这些必要功能。
这说明一个问题：并行 AI 编码的基础设施，技术上并不难。真正的难点在于 token 预算和任务拆解。
总结
随着 AI 编码代理越来越强，问题从「能不能跑多个代理」变成了「怎么高效地跑」。Fleet 给出了答案。
真正用起来的人发现，收益来自三件事的结合：
- 并行执行（Fleet 负责）
- 合理的任务拆分（你来做）
- token 优化（你来管）
如果你发现单个代理不够用，但又不知道怎么协调多个代理，Fleet 值得试试。它不是什么高深的技术，而是把「显而易见」的需求先做了出来。