4.1
六种 Agent 架构：复杂度要花在刀刃上
学习目标
根据任务形态选择架构，并能反驳「多 Agent 一定更强」这个假设。
前置知识
阶段 1 的循环；3.1 的推理模式。
核心要点
- 单 Agent 循环：最常用，适合 80% 的工具型任务；瓶颈是上下文增长。
- 路由 / 分诊：先判断任务类型，再交给专门的处理链；适合客服、工单等类别清晰的场景。
- Plan-and-Execute：规划者 + 执行者，适合长任务；需要重规划机制。
- 多 Agent / 层级：任务可分解且子任务异构时才有收益；协调成本与错误放大是主要代价。
- 评估器-优化器：生成 + 评审循环，适合有明确质量标准的内容任务；没有外部标准时会退化为互相吹捧。
动手任务（30 分钟）
为「每周自动生成团队周报」和「跨三个仓库的代码迁移」各选一个架构，画不超过 5 个框的图，并写一句「为什么不用更简单的单 Agent」。如果写不出来，说明你不需要更复杂的架构。
自检
什么情况下多 Agent 反而是负优化？
任务线性、上下文可以共享、子任务同质时。多 Agent 会引入信息丢失、重复工作和调试困难，成本上升但质量未必提升。先尝试单 Agent + 更好的工具与提示。
评估器-优化器架构什么时候有效？
当「好」可以被外部标准检验时（测试通过、格式校验、事实核对）。如果只让模型自评，容易产生偏好偏差，评审轮次越多不代表质量越高。