Pattern 01
Generator-Verifier
一个 Agent 生成输出，另一个评估。通过就结束，不通过就把反馈打回给生成方，重新来一轮。循环直到通过或达到最大迭代次数。
最典型的应用是代码生成：一个 Agent 写代码，另一个写测试、跑测试。客服场景也适用——生成方起草邮件回复，验证方检查是否准确引用了产品文档、是否回应了用户提到的每个问题。
适用条件：输出质量关键且评估标准可以明确化
一个 Agent 生成输出，另一个评估。通过就结束，不通过就把反馈打回给生成方，重新来一轮。循环直到通过或达到最大迭代次数。
最典型的应用是代码生成：一个 Agent 写代码，另一个写测试、跑测试。客服场景也适用——生成方起草邮件回复，验证方检查是否准确引用了产品文档、是否回应了用户提到的每个问题。
适用条件：输出质量关键且评估标准可以明确化
一个 Agent 当 Team Lead，负责规划任务、分配工作、汇总结果。子 Agent 接到具体任务后执行完就汇报。Claude Code 就是这个模式——主 Agent 自己写代码，需要搜索代码库时就在后台派 subagent，自己继续手头的活。
适合任务拆分清晰、子任务之间依赖少的场景。比如自动化代码审查：一个 PR 进来，需要查安全漏洞、检查测试覆盖率、评估代码风格、验证架构一致性，每个检查维度独立、输出格式明确。
编排模式里的子 Agent 是用完即弃的，但团队模式里的 Worker 是持久的——不重置，不遗忘。协调者启动多个 worker 作为独立进程，领任务、干活、交结果，每个 worker 在多轮迭代中积累对自己负责领域的熟悉度。
最直观的例子是大规模代码迁移。每个 worker 分管一个服务，在反复处理这个服务的依赖、测试、部署配置的过程中逐渐摸清它的脾气。一次性 subagent 每次接手都要重新理解，持久 worker 第一次弄明白之后后续迭代直接复用。
共享通信层，核心操作就两个：发布和订阅。Agent 订阅自己关心的 topic，路由器负责分发。新 Agent 上线不需要改已有连接，订阅相关 topic 就能接收工作。搞过微服务事件驱动架构的不陌生，本质上就是 Kafka 那套思路。
Anthropic 举的例子是安全运维自动化。告警从多个来源进来，分诊 Agent 分类后路由给对应的调查 Agent，调查结果再流向响应协调 Agent。事件一个阶段接一个阶段地流下去，新出了什么威胁类型就加个新 Agent。
没有中央协调者。Agent 自主运行，读写共享的数据库、文件系统或文档。工作从往存储里丢一个问题或数据集开始，停下来条件有几种：时间到了、结果收敛了，或者有个专门的 Agent 判断存储里的东西已经够用了。
研究综合是主场。多个 Agent 分头调查一个复杂问题的不同方面——学术 Agent 发现了一个关键研究者，这条信息对行业 Agent 立刻有用。发现直接写进存储，其他 Agent 马上就能看到。附带好处是没有单点故障，任何一个 Agent 停了，其他 Agent 继续读写。
两者都有协调者分派工作，区别在于 worker 需要维持上下文多久。
子任务短小、输出明确，subagent 不需要跨调用保留状态 → 编排模式
子任务需要多步骤持续工作、从积累的上下文中受益 → 团队模式
例：代码审查用编排（每次检查独立），代码迁移用团队（每个 worker 需要持续理解服务上下文）
两者都能处理多步骤工作流，区别在于工作流结构是否可预测。
步骤顺序事先已知（固定流水线）→ 编排模式
事件驱动、随发现变化、新类型不断出现 → 消息总线
经验法则：编排 Agent 里的条件分支越来越多、需要处理越来越多的特殊情况时，就该考虑换消息总线了。
两者都让 Agent 自主工作，区别在于发现是否需要实时流通。
各管各的互不交叉，最后汇总结果即可 → 团队模式
Agent 之间需要互相沟通而不只是汇总结果 → 共享状态
例：代码迁移用团队（各改各的服务），研究综合用共享状态（学术发现影响行业调查）
两者都支持复杂协调，区别在于工作是离散事件还是持续积累。
事件从一阶段触发到下一阶段然后完成 → 消息总线
Agent 在持续积累的知识基础上反复迭代 → 共享状态
值得留意的信号：如果消息总线里的 Agent 发布事件是为了分享发现而不是触发动作，那你可能需要的是共享状态。
