基于版本
- CLI
- 0.2.17
- 预览 ref
- a2c45c8
让 Claude Agent Teams 显得毫无用处的捷径，就是不断把消息发给错误的对象。
这很隐蔽。
你以为让队友去跑测试，其实告诉的是主助手。
你以为广播了一条全局约束，其实只发给了一个队友。
结果你又在做团队本该避免的事：
- 重新解释上下文
- 重复自己
- 怀疑到底有没有人听到
这份指南是一本路由手册：主助手、队友与广播的区别，以及让消息发到正确地方的小习惯。
简要总结
- 对于 Claude Agent Teams，在决定说什么之前，先决定对谁说。
- 使用：
- 主助手负责协调和最终决定
- 队友负责具体工作
- 广播用于全局约束
- 优先发送可验证的消息：
- 要求一行确认（“收到 + 当前步骤”）
- 在有风险的操作前要求一份检查点总结
- 如果你想要一个让路由一目了然的界面，Happier 是一种有帮助的选择：它有 发送给（Send to）选择标签，并把路由后的消息显示为带收件人的卡片。
问题所在
路由是团队的隐性成本。
在单线程会话中，每条消息都只去一个地方。
在团队中，消息是一个有方向的动作。
如果你不把方向说清楚，就会出现：
- 重复劳动
- 遗漏约束
- “这个队友怎么在做错的事？”的困惑
常见做法及其权衡
- 总是和主助手说话：安全，但团队退化成了一个代理。
- 只和队友说话：感觉很快，但失去了协调层。
- 什么都广播：制造噪音，责任混乱。
可行的路由图
主助手（协调）
当你想要以下内容时，找主助手（应用中显示为 主助手（Lead））：
- 一个计划
- 一份总结
- 解决队友产出之间的冲突
- 一个最终决定
好的主助手消息模式：
总结每个队友的发现，列出分歧，并提出一个决定。
队友（执行）
在以下情况找队友：
- 任务清晰且有边界
- 输入和输出可以描述清楚
好的队友消息模式：
做 X。完成后停下。回复时包括：(1) 你改了什么，(2) 你没改什么，(3) 你需要我提供什么。
广播（全局约束）
在以下情况使用广播：
- 消息是适用于所有人的约束
- 消息是协调性的（“暂停”“检查点”“下一步后停下”）
好的广播消息：
- “不要碰迁移。”
- “下一步后停下并总结。”
- “如果你要安装依赖，先问一下。”
不好的广播消息：
- “重构这个文件”（负责人不明确）
- “修好这些测试”（谁负责？）
实际示例（可复制）
示例 1：广播一条安全约束
不要碰迁移和认证代码。如果你觉得必须改，先停下来问我。
示例 2：把测试任务交给一个队友
为这次改动运行最小测试计划。
回复时包括：
- 你运行的确切命令
- 失败项（完整错误文本）
- 一个建议的修复（如果有）
示例 3：把裁决交给主助手
两个队友意见不一。用 5 个要点总结双方立场，然后推荐其中一个。
如何证明你的消息发到了哪里
关键是事后能验证路由。
如果界面不显示路由，你就只能猜。
在 Happier 中，路由后的消息会以结构化的参与者消息保存，并显示为带有清晰收件人标签（“发送给：…”）的消息卡片。
当团队超过 2 个成员时，你需要的就是这种明确程度。
故障排查
我发了一条消息，结果是错误的代理在执行
常见原因：
- 你没有明确指定路由
- 你以为广播就是“主助手”
解决方法：
- 把消息重新发给目标对象
- 让不该收到的那个代理停下，并总结它做了什么
广播显得很吵
广播应该用于约束和协调，而不是分配任务。
如果你的广播里全是任务，说明路由没起作用。
队友总是问同样的问题
加一条检查点规则：
先问一个澄清问题，然后按稳妥的理解继续。
常见问题
每条消息都要指定路由吗？
不用。
路由在以下情况下尤其重要：
- 你有不止一个队友
- 你给出的指令不应适用于所有人
稳妥的默认对象是谁？
主助手。
如果你不确定任务该由谁负责，发给主助手，让它去分派。
常见错误
- 用广播分配细节任务
- 把本该发给某个队友的纠正发给了主助手
- 忘了要求确认或检查点
相关指南
claudeteamsworkflows
最后更新: 2026-10-26