Claude Agent Teams 的概念公布之后，GitHub 上迅速冒出了一批多 Agent 团队框架。我花了两天时间翻了几个热度比较高的项目，发现它们在角色设计上走了完全不同的路线。有的极简，5 个角色就够了；有的极繁，44 个专业 Agent 分成八个部门。
哪种设计更合理？我把每个项目拆开看了看。
01 bradms98/claude-agent-team：最小核心 + 按需专家
这个项目的思路最清晰。它把 Agent 分成两层：核心团队和专家团队。
核心团队始终在线，包含五个角色。Orchestrator 负责任务分解和分配，是整个系统的调度中心。Engineer 负责写代码，是产出最多的角色。Reviewer 做代码审查，每次提交前都会过一遍。Security 专注安全审计，检查依赖漏洞、权限配置、敏感信息泄露。QA Tester 跑测试用例，确认功能符合预期。
专家团队按需激活。项目需要写文档了，拉一个技术写作 Agent 进来。要做性能优化了，激活性能分析 Agent。要配 CI/CD 了，叫 DevOps Agent。还有产品负责人和可访问性专家可选。
我喜欢这个设计的地方在于它对"始终在线"和"按需激活"做了明确区分。不是每个项目都需要 DevOps Agent。一个写内部工具的小项目，五个核心角色就够了，多余的 Agent 只会增加协调成本和 token 消耗。
02 ciscoittech/claude-agent-framework：自动配置 + 自定义命令
这个框架的卖点是两个数字：97% 上下文缩减，3 到 6 倍速度提升。
97% 上下文缩减怎么做到的？通过让每个 Agent 只加载与自己任务相关的上下文。一个负责数据库的 Agent 不会加载前端组件的代码，一个写 CSS 的 Agent 不会读取 API 路由文件。粗暴但有效。
速度提升来自并行。把原来一个 Agent 串行做的事拆给多个 Agent 同时做，总耗时自然下降。这个道理不复杂，但框架帮你做了任务拆分和并行调度，省去了手动编排的麻烦。
有意思的地方是它的自动配置功能。框架会扫描项目的技术栈——package.json、requirements.txt、Dockerfile、CI 配置文件——然后根据检测结果自动生成一组命令：/build、/debug、/test、/deploy。不同技术栈生成的命令内容不同。一个 Next.js 项目的 /build 和一个 Django 项目的 /build 跑的东西完全不同，框架会自动适配。
对新手来说这个设计降低了入门门槛。你不需要自己写 Agent 配置文件，框架帮你搞定。代价是灵活性有限——如果你的项目结构不符合框架的预设模板，自动配置可能会出错。
03 MakingJamie/claude-colony：tmux + 文件消息
claude-colony 的技术选型很有意思。它用 tmux 做多 Agent 编排。
tmux 是 Linux/macOS 上的终端复用器，一个终端窗口里开多个面板，每个面板跑一个独立的进程。claude-colony 在每个 tmux 面板里启动一个 Claude Code 会话，每个会话就是一个 Agent。
Agent 之间怎么通信？不是通过 API，不是通过数据库，而是通过文件。一个 Agent 要告诉另一个 Agent 某件事，就往一个约定好的文件里写一条消息。另一个 Agent 定期检查这个文件，读取新消息。文件充当消息 broker 的角色。
这个方案简陋吗？确实简陋。但它有一个优点：零依赖。不需要装消息队列，不需要跑额外的服务，一台装了 tmux 和 Claude Code 的机器就能用。
框架内置了几套预设团队配置：fullstack（全栈开发）、frontend（纯前端）、API（纯后端）、mobile（移动端）。选一个配置，tmux 自动开好对应的面板，Agent 们各就各位开始工作。
它和 Claude Code 的 .claude/agents/ 系统做了原生集成。你在 .claude/agents/ 目录下定义好 Agent 的角色描述、工具权限、行为规则，claude-colony 直接读取这些配置来初始化每个 Agent。
04 dylan-gluck/cc-dev-team：44 个 Agent 的企业级编排
cc-dev-team 走的是完全不同的路线。44 个以上的专业 Agent，分成八个团队：Engineering、Product、QA、DevOps、Creative、Research、Marketing、Data。
Engineering 团队内部还有细分：前端工程师、后端工程师、全栈工程师、数据库专家、架构师。Product 团队有产品经理、UX 设计师、业务分析师。QA 团队有手动测试、自动化测试、性能测试、安全测试。
这不是一个开发工具，更像一个虚拟公司。
框架支持斜杠命令控制（/assign、/status、/review），有完整的任务状态管理，有 hook 系统可以在 Agent 执行前后插入自定义逻辑，还有实时可观测性——你可以看到每个 Agent 当前在做什么、消耗了多少 token、产出了什么。
我的直觉是：这个框架适合做 demo，不适合日常使用。44 个 Agent 的协调开销是惊人的。每个 Agent 都需要上下文，Agent 之间的通信需要 token，Lead Agent 要追踪 44 个下属的状态，光是状态同步就是一笔不小的开销。
但它作为一个概念验证很有价值。它回答了一个问题：如果把一个完整的软件公司映射到 Agent 系统里，需要多少种角色？答案是 44 种以上。这个数字让你对"多 Agent 系统的复杂度上限"有一个直觉。
05 五个核心角色就够了吗
看完这几个框架，我的结论是：5 个核心角色——编排、工程、审查、安全、测试——是最小可用配置。
编排者决定做什么、怎么分，是系统的大脑。工程师负责实际写代码，是系统的双手。审查者检查代码质量，是质量关卡。安全 Agent 做安全审计，防止低级安全错误。测试 Agent 确保功能正确。
少了编排者，其他 Agent 不知道该干嘛。少了审查者，代码质量没人兜底。少了安全 Agent，写出的代码可能有漏洞但没人发现。少了测试 Agent，功能做出来了但不知道对不对。这五个角色每一个都不可或缺。
要不要加更多角色？取决于项目复杂度。如果你的项目需要写文档，加一个技术写作 Agent。需要做性能优化，加一个性能分析 Agent。需要处理部署，加一个 DevOps Agent。但起步阶段，五个就够了。
有人可能觉得 44 个 Agent 的企业级方案更"完整"。我不这么看。Agent 数量增加带来的协调成本是超线性的——10 个 Agent 的协调成本不是 5 个 Agent 的两倍，可能是四五倍。在当前 token 价格下，精简团队跑完一个项目的性价比远高于铺一个大团队。
先跑通五个角色的工作流，确认协作机制没问题了，再按需扩展。这和人类公司的做法一样：先五个人的初创团队，验证了商业模式，再招人扩张。