入门篇的模拟器展示了 ReAct 顺风局。生产环境更值得研究的是逆风局：模型没有全局计划，每一步只看眼前，遇到反复失败的工具时容易陷入"换汤不换药"的重试循环。逐步播放一个真实的卡死案例和工程解法👇
① 步数预算：超过 N 步强制停下来汇报；② 重复检测：连续相同的（工具, 参数）调用直接拦截，把"你在重复自己"写进上下文；③ 失败记录显式化：让模型维护一个"已试过 & 不行"清单——写下来的失败比埋在历史里的失败更能改变行为。
这个模式的精髓不是"先列清单"，而是清单是活的。点击"推进"，看一个数据迁移任务怎么在第 3 步翻车，又怎么靠重规划（replan）救回来——注意计划修改的不是失败那一步，而是后续所有步骤👇
计划是天然的 human-in-the-loop 切入点：执行前用户能审一眼（Claude Code 的 plan mode 就是这个思路），执行中清单就是进度条，出错时也容易定位"卡在第几步"。相比之下 ReAct 的决策埋在每轮思考里，人很难提前干预。
"生成 → 批评 → 修订"听起来可以无限循环下去，实际上第一轮反思吃掉大部分收益，之后快速递减，而每一轮的 token 成本是恒定的。点击"再反思一轮"，体会这条曲线👇
纯"自我感觉"式反思容易空转——模型夸自己写得不错，然后改两个变量名交差。反思的质量取决于反馈信号的质量：能跑测试就跑测试，能 lint 就 lint，能让另一个模型当评审就别让作者自评。外部信号 ≫ 自我感觉。
"多个 Agent 协作"不是一种模式，是一族。拓扑选错，沟通成本会吃掉全部并行收益。点击切换四种常见拓扑，注意各自的信息流向和翻车方式👇
能单 Agent 解决的别上多 Agent。子 Agent 之间不共享上下文，每次交接都是有损压缩——A 知道的细节传到 B 手里只剩一段转述。收益要来自真并行（互不依赖的子任务）或真隔离（每个子任务的上下文都很重），否则只是把一个模型的活拆给三个模型干，又慢又贵还容易口径不一。
没有最好的模式，只有匹配任务的模式。回答下面几个问题，拿到一个起步建议（注意只是起步——真实系统经常是混合体）👇
真实系统很少"纯血"：Claude Code 是 ReAct 主循环 + 可选 plan mode + 测试驱动的 reflection + 按需派生子 Agent。先用最简单的模式跑通，eval 指出短板后再针对性叠加——架构是长出来的，不是选出来的。
5 道题。答错没关系，解析比答案重要。