以前你和一个 AI 结对编程，现在你管理一支代理乐队

六个月前，我们还在和单个 AI 助手玩"你一句我一句"的同步游戏。今天，最高效的开发者已经在编排多个异步运行的代理——每个代理有自己的上下文窗口、文件范围和职责领域。

这就像从指挥家（一个乐手，实时指导）变成了编排者（整个乐团，异步协调）。

---

🎯 为什么单个代理不够用？

每个开发者最终都会撞上三堵墙：

问题	表现	解决方案
上下文过载	大代码库撑爆单个上下文窗口	子代理隔离
缺乏专业化	一个代理干所有活，样样稀松	专注代理
无法协调	代理之间不能通信	代理团队

真相是：三个专注的代理 consistently 击败一个通才代理干三倍时间。这不是加法，是乘法！

---

🔄 核心转变：从指挥家到编排者

指挥家模式：你实时指导单个 AI 代理。同步、顺序执行，你的上下文窗口是硬性上限。

编排者模式：你协调整个乐团。多个代理，各自有独立的上下文窗口，异步工作。你规划工作、分配任务、定期检查。

就像管理真实团队一样，你现在需要不同的技能：清晰的规范、工作分解、输出验证，而不是自己写代码。

使用AI的人的发展过程

---

🚀 三大编排模式

模式一：子代理（Subagents）—— 专注委派

子代理是最简单的多代理模式，也是你应该首先尝试的。

具体的例子
当你向Claude Code发出提示：“使用nest.js和SQLite构建一个名为BM的书签管理器”，父级编排器会将其分解为三个子代理任务简报：

1. 数据层子代理 —— 构建包含数据库模式和CRUD操作的 db.js 文件，完成后编写 DATA.md 报告
2. 业务逻辑子代理 —— 构建包含输入规则的 validation.js 文件，完成后编写 LOGIC.md 报告
3. API路由子代理 —— 读取 DATA.md 和 LOGIC.md 报告，构建包含Nest路由的 route.js 文件

优点：零设置，今天就能用
缺点：依赖图要手动管理，代理之间不能直接通信

前两个子代理相互独立，可以并行运行。第三个子代理依赖于前两者，因此需等待其报告文件生成后再启动。父级（主控程序）以手动方式管理这个依赖关系图。

---

模式二：代理团队（Agent Teams）—— 真正的并行执行

这是 Claude Code 的实验性功能，真正的并行执行：

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

核心架构三层：

1. 团队主管 — 分解工作，创建任务列表，合成结果
2. 共享任务列表 — 任务状态追踪 + 依赖管理 + 文件锁定
3. 团队成员 — 独立的 Claude Code 实例，各自有自己的上下文窗口

关键机制：代理之间直接通信，不经过主管，避免瓶颈。

例子
从一个可运行的 BM应用开始，然后向 Claude Code 发出一个指令：“创建一个由三人组成的智能体团队，来添加搜索功能。” 主控智能体随即创建了后端、前端和测试三位“队友”。

• 后端队友 开始构建搜索 API 端点。

• 前端队友 开始构建搜索用户界面。

• 测试队友 初始处于阻塞状态，因为它需要等待 API 完成。

当后端完成工作，并将 API 接口契约发送给前端时，测试任务自动解除阻塞。至此，三者便可以并行工作了。

这种更加接近于日常团队工作的模式。

---

模式三：规模化编排

2026 年的工具 landscape 分三层：

层级	工具	适用场景
Tier 1	Claude Code 子代理/团队	单终端会话，无需额外工具
Tier 2	Conductor, Vibe Kanban	3-10 个代理，本地编排
Tier 3	Copilot Coding Agent, Jules	云端异步，关闭笔记本等 PR

大多数开发者会同时使用三层：Tier 1 做交互工作，Tier 2 做并行冲刺，Tier 3 夜间清理待办事项。

其中cursor glass就是做的这个事情

Glass 是cursor未来的新界面，根本性的界面变化：
代理管理成为主界面：传统的代码编辑器不再是打开软件后看到的第一界面；

编辑器变为调用工具：只有当您需要编写或编辑具体的代码时，才会去“打开”或“切换到”那个我们更为熟悉的传统编辑器。它变成了一个“在需要时才使用的工具”，而不是工作的起点。

---

三个关键质量门禁

1. 计划审批 — 编码前先写计划，主管审核

   队友 >>> 写计划 >>> 主管审核 >>> 批准/拒绝 >>> 实施
   

2. 自动化钩子 — 任务完成自动跑测试

   任务完成 >>> 钩子运行 npm test >>> 通过？允许 | 失败？继续工作
   

3. AGENTS.md — 积累模式和经验，会话间传承

## AGENTS.md 示例
## STYLE
- 使用函数组件 + hooks
- 优先命名导出

## GOTCHAS  
- SQLite 需要 WAL 模式支持并发读取
- Express 中间件顺序对认证很关键

⚠️ 研究警告：ETH Zurich 研究发现，LLM 生成的 AGENTS.md 不仅无益，还会降低约 3% 成功率。必须人工编写！

---

💡 我的观点

这套模式让我想起一个道理：速度不是目标，理解才是。

当人类写代码时，错误慢慢累积，痛苦迫使我们及早修正。但当你有一支代理大军时，小错误会以你无法捕捉的速度复合增长。

核心建议

• 委派任务，不要委派判断 — 架构决策、决定不做什么、全面审查，这些留给自己
• 规范是杠杆 — 模糊的需求会在并行中放大错误
• 3-5 个代理是甜蜜点 — 再多就管不过来了，token 成本线性增长

---

🎬 开始行动：今天就能尝试的 5 个模式

#	模式	难度	时间
1	✅ 用 Task 工具 spawn 子代理	⭐	今天
2	✅ 启用 Agent Teams 实验功能	⭐⭐	本周
3	✅ 每个代理一个 Git worktree	⭐⭐	本周
4	✅ 设置质量门禁（计划审批 + 测试钩子）	⭐⭐⭐	下周
5	✅ 维护人工编写的 AGENTS.md	⭐	今天

---

🏭 工厂模式：你不再只是写代码

你在建造生产软件的工厂。工厂需要：

1. Plan    → 写规范，明确验收标准
2. Spawn   → 创建团队，分配代理
3. Monitor → 每 5-10 分钟检查进度，解决阻塞
4. Verify  → 运行测试，审查代码
5. Integrate → 合并分支，解决冲突
6. Retro   → 更新 AGENTS.md，积累知识

实用技巧：

• 设置 WIP 限制：不要运行超过你能有意义审查的代理数量
• 定义终止标准：如果代理在同一错误上卡住 3+ 次，停止并重新分配
• 一个文件，一个所有者：永远不要让两个代理编辑同一个文件

---

🎸 总结

你不再只是写代码，你在建造生产软件的工厂。

工厂需要质检、流程文档、精确的输入规范——否则输出就是废品。

规范就是你的杠杆。当你并行编排 50 个代理时，模糊的思考不会只是拖慢你——它会成倍放大错误。

优秀的工程师从这些工具中获得更多杠杆，而不是更少。因为代码输入的机械工作正在被自动化，而理解系统的认知工作正在被放大到整个自主工作者舰队。

---