绿然智老照片修复器
58.03M · 2026-02-12
大家好，我是易安，AI超级个体，大厂程序员二孩奶爸。 Claude Opus 4.6 带来了 Agent Teams 功能，可以让多个 Claude Code 实例并行工作。我用它做了个小项目，踩了一些坑，也顺便把底层原理和市面上几个主流多 Agent 框架做了个对比。这篇文章干货比较多，建议收藏。
简单说就是一个 Lead Agent 可以 spawn 出多个 Teammate Agent，每个 Teammate 是一个完全独立的 Claude Code 会话实例，有自己的 200K 上下文窗口，并行处理不同的任务。完成后 Lead Agent 负责集成。
不需要特殊的 CLI 命令，用自然语言告诉 Lead Agent 怎么分工就行。
但这里有个关键点很多教程没讲清楚——Agent Teams 和之前的 Subagents 是两码事：
Subagents 更像是"我派你去查个资料回来告诉我"，Agent Teams 则是"我们组个团队一起干"。
这部分我觉得是理解 Agent Teams 的关键。搞清楚原理，才能知道什么时候该用、怎么用才高效。
Agent Teams 的底层是一套叫 TeammateTool 的系统，2026 年 1 月社区开发者 kieranklaassen 在 Claude Code 二进制文件上跑 strings 命令时发现了它——当时功能还被两个门控函数隐藏着。11 天后 Anthropic 就正式发布了。
这套系统包含 13 个操作，分三类，同时配合本地文件系统做状态管理：
没有专有云数据库，没有复杂的消息队列。就是 JSON 文件 + 文件锁。并发安全靠原子写入（tempfile + os.replace）和跨平台文件锁。
这意味着你可以直接 cat ~/.claude/tasks/my-team/1.json 看任务状态，甚至手动改它。跟 git 一样，对开发者很友好。
任务之间支持依赖关系，形成有向无环图（DAG）。队友完成任务后，依赖它的任务会自动解除阻塞：
每个队友有个 JSON 格式的收件箱。关键设计——Claude 的文本输出对团队不可见，必须用 write 操作才能让其他队友看到消息。
这很重要：如果 API 队友完成了类型定义，它可以直接通知 UI 队友开工，不需要经过 Lead 中转。测试队友也可以直接请求 API 队友启动开发服务器。这比纯层级汇报灵活很多。
系统会自动检测环境选择后端，tmux 是最稳的选择：
按 Shift+Tab 可以把 Lead 切换到 delegate 模式。这个模式下 Lead 只能做协调——生成队友、发消息、管理任务，不能直接改代码。
为什么需要这个？因为 Lead 有时候会"手痒"，明明该分配给队友的任务自己偷偷实现了。delegate 模式是个强制约束。
在 ~/.claude/settings.json 里加两个配置：
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"experimental": {
"agentTeams": true
}
}
推荐在 tmux 里启动，可以看到分屏效果：
tmux new -s my-team
claude
我选了一个 Python CLI 记账工具作为测试项目，功能不复杂但可以拆成清晰的并行任务：
每个 Agent 拿到的 prompt 里详细描述了要创建的文件、类名、方法签名、参数类型。三个任务同时发出去，并行执行。
三个 Agent 全部完成，总共生成 7 个文件、21 个测试用例。速度确实快——三个 Agent 最慢的那个大概用了不到 3 分钟，如果串行做至少要 6-7 分钟。
跑测试的时候问题来了：8 个模型测试全过，13 个存储测试全挂。
这是多 Agent 并行开发最典型的问题——每个 Agent 独立工作，对同一个接口的理解不完全一致。
三个 Agent 之间出现了 3 类冲突：参数名不同、类型不匹配、返回值 key 名对不上。
修复分两步：
第一步改测试文件 test_storage.py，对齐实际的 storage.py 接口：
data_dir= 改成 data_path=Path(...) / "data.json".value 转字符串str() 转字符串this_month 改成 monthly_total第二步改 cli.py，对齐 models.py 的类型要求：
args.category 改成 args.category.valuestr() 转换int 改成 str（因为实际用的是 UUID）改完之后 21 个测试全部通过，CLI 也能正常跑了：
已添加支出: ¥35.50 [FOOD]
已添加支出: ¥100.00 [TRANSPORT]
已添加支出: ¥299.00 [SHOPPING]
共 3 条记录，合计: ¥434.50
市面上做多 Agent 编排的框架不少，我重点对比了三个有代表性的：
Oh-My-OpenCode 是给 OpenCode（开源终端 AI 工具）做的插件，GitHub 上有 24000+ Star。它的设计挺有意思——用希腊神话人物命名 11 个 Agent 角色：
核心设计是多模型混合——Opus 做决策、GPT 做执行、Grok 做搜索、Gemini 做多模态分析。用便宜模型做侦察，贵模型做决策，成本控制比较灵活。
但有个现实问题：2026 年 1 月 Anthropic 限制了第三方 OAuth 访问，明确提到 Oh-My-OpenCode 是封锁原因之一。它之前允许用 Claude Pro/Max 订阅驱动 OpenCode，被认定违反了服务条款。
BMAD（Breakthrough Method for Agile AI-Driven Development）走了一条完全不同的路——不追求并行速度，追求流程可控。
它的核心理念是把 AI 组织成一支完整的敏捷团队：分析师、产品经理、架构师、Scrum Master、开发者、QA。每个角色的定义是版本化的 Markdown/YAML 文件，可以 Git 管理。
开发分两个阶段：
第一阶段：规划。Analyst 做调研 → PM 写 PRD → Architect 定架构 → Product Owner 对齐验证 → Scrum Master 生成开发故事。整个过程产出的文档就是持久化的上下文。
第二阶段：执行。开发者 Agent 打开一个故事文件，里面有完整的实现细节、架构指导、设计原理、测试标准。不需要额外沟通，文档即上下文。
BMAD 还有个"文档分片"的概念——把复杂的项目文档拆成原子化的、AI 可消化的片段。这解决了大项目上下文塞不进去的问题。
它是工具无关的，支持 Claude Code、Cursor、Windsurf、GitHub Copilot 等多种 AI IDE。
Agent Teams 适合：已经在用 Claude Code，项目可以清晰拆分并行任务，接口契约比较明确。胜在零配置、原生体验好。
Oh-My-OpenCode 适合：想混用多个模型控制成本，项目需要复杂的规划-执行分离。但要注意 OAuth 合规问题。
BMAD-METHOD 适合：大型复杂项目，需要完整的文档链路和角色分工。可以和 Agent Teams 互补——用 BMAD 做规划阶段，用 Agent Teams 做并行执行阶段。
其实这三个方案不互斥。BMAD 可以运行在 Claude Code 之上，Oh-My-OpenCode 的设计理念（多模型混用、层级化 Agent）对 prompt 设计也有参考价值。
Agent Teams 的优势：
Agent Teams 的坑：
/resume 暂时不能恢复 teammate 会话建议：
class ExpenseStorage(data_path: Optional[Path] = None)，而不是"构造函数接受可选的目录参数"多 Agent 协作是 AI 辅助开发的下一步，不管用哪个框架，核心问题都是一样的：怎么把"接口契约"定义清楚，怎么在并行效率和协调成本之间找到平衡。跟人类团队协作其实是一个道理——分工越清晰，扯皮越少。
