Chapter 10 · 自测与辨析

自测与辨析

前九章把零件和集成讲完了。这一章不教新东西，只做一件事：用三层梯度的题目戳破"读得很顺"的假象。重点是最后的跨章辨析场景——它检验你能不能在真实需求里把双轴坐标系和各模块的取舍用起来。

用法 · 先合上再答

每道题先合上教程、把答案写在纸上或编辑器里，写完再展开文末的答案对照。直接点开答案，等于把这一章当成再读一遍——那正是流畅感骗你的方式。概念层应该几乎都能答上来；应用判别层会逼你在两个方案之间做选择并说出依据。

·三层梯度

题目分三层，越往上越要求把多章的概念连起来用。底层是"记得住词汇"，中层是"讲得出机制"，顶层是"在场景里选得对"。

迁移 ↑ 机制 记忆 概念层 · 对应各章词汇 记得住：原子循环 / CoALA / RRF / swarm… 原理层 · 机制为什么 讲得出：代价、何时失效 应用判别层 跨章选得对
图 10三层梯度：底宽顶尖，越往上越窄、越难。注意：顶层（朱红）才是这门课的验收线——能在一个真实场景里在两个模式之间选对、并说出代价，才算把双轴框架用起来了；只答得出底层，是"面熟"不是"学会"。

A概念层（对应 01–09 词汇）

  1. 所有 28 个模式共享的那个"原子循环"，四个环节按顺序是什么？（01）
  2. 双轴框架的纵轴、横轴各叫什么、各回答什么问题？（01）
  3. CoALA 的四类记忆是哪四类？哪一类活在 context window 里？（03）
  4. 混合检索里，BM25 和向量各擅长什么、靠什么融合？（03）
  5. 多 agent 的 supervisor 模式和 swarm/handoff 模式，控制权的归属差别是什么？（07）
  6. "渐进承诺"指的是把 agent 的权限怎么分层？（08）

B原理层（机制与代价）

  1. 为什么 temperature=0 仍不能保证 LLM 输出可复现？根因一个词。（01）
  2. "context window 越大越好"错在哪？用 attention budget / context rot 解释。（03）
  3. 摘要式 compaction 的代价有哪两条硬指标？为什么进度要在它触发前写出去？（03）
  4. 失败日记的反馈信号为什么必须来自外部 oracle，而不能是模型自评？（03 / 06）
  5. Anthropic 的多 agent 研究系统强 90.2%，代价是什么？这说明多 agent 的本质是在买什么？（07）
  6. "先 workflow 再 agent、能单别多"这条纪律，背后的成本机制是什么？（01 / 09）

C应用判别层 · 跨章场景（验收线）

每个场景给一个真实需求，要求你在两个方案之间选一个、说出依据，并指出它落在双轴坐标系的哪个格子。这一层是 capstone——答得出它，才算把整门课用起来。

  1. 场景一：一个客服系统要按用户问题动态转给"退款 / 技术 / 账单"等专家 agent，且接手的 agent 要能直接回用户。你用 supervisor（中心调度）还是 swarm/handoff（去中心交接）？为什么？（07 + 01 执行拓扑）
  2. 场景二：要给一个百万行的代码库做"找到处理超时的那段逻辑"这类检索。你预先建一套 embedding 向量库，还是用 grep/glob 现查（agentic search）？为什么？（03 + 02 渐进发现）
  3. 场景三：一个要跑几小时、会多次触发 compaction、还会写文件改库的重构任务。状态该活在哪里？哪些动作需要额外的"门"？（03 进度追踪 + 08 渐进承诺/审批门）
  4. 场景四：修一个有明确单元测试的 bug。你用"模型自己反复检查自己的推理"，还是"跑测试拿报错再改"？区别为什么是决定性的？（06 自愈循环 + 03 失败日记 + 04 迭代假设验证）
  5. 场景五：一个任务步骤明确、可拆成相互独立的子步、环境低动态。你用 ReAct，还是 Plan-Execute / 并行编排？要不要上多 agent？（01 坐标系 + 04 + 07）
亲手画一张图

合上教程，在纸上重画第 01 章的双轴坐标系——横轴执行拓扑、纵轴认知功能——然后把 ReAct、Plan-Execute、Reflexion、Orchestrator-Workers 四个模式各自标到一个位置。画完翻回 图 1.3 对照：你标的 Reflexion 在纵轴上是不是明显高于 ReAct？右上角那一片（多 agent + 记忆）你有没有标得"更贵"？画错的位置，正是你的 schema 还没连上的地方。

答案（先把三层都做完再展开）

A · 概念层

  1. gather context（拼进 prompt）→ LLM 产出 token、解析成动作 → 执行动作（有副作用）→ observation 回填 context。
  2. 纵轴=认知功能，问"一步循环内部在做什么"（感知/记忆/推理/行动/反思）；横轴=执行拓扑，问"循环之间如何连、谁决定下一步"（单循环/规划-执行/编排/多 agent）。
  3. 工作记忆、情景记忆（episodic）、语义记忆（semantic）、程序记忆（procedural）。只有工作记忆活在 context window 里。
  4. BM25 抓罕见精确词（代码标识符、SKU、错误码），向量懂语义改写；用 RRF（倒数排名融合，按名次不按分数）融合。
  5. supervisor=中心 agent 把子 agent 当工具调用、保留对话控制权；swarm/handoff=对等 agent 把控制权交接出去。
  6. 从只读 → 可写逐级放权（read-then-write / dry-run / preview-then-commit），而不是一上来给全部权限。

B · 原理层

  1. 根因：batch 不变性（缺失）——服务器负载让 batch size 浮动，归约顺序变、浮点结果变。
  2. 窗口无状态、每次重填；且 n² 注意力让每个 token 分到的注意力预算被摊薄，token 越多召回越差（context rot，渐进退化）。"塞得下"≠"读得准"。
  3. 两条硬指标：跨会话留存仅约 37%、保真 3.4–4.0/5（约 1/5 事实丢失）；而且它是 blocking（停下来跑一次推理）。进度写在外部文件才不会被压掉，也不必每轮重计费整段历史。
  4. 因为内在自我纠正（无外部反馈）往往降低推理性能（Huang ICLR 2024）——把答案做错的模型，对自己错误的判断通常同样错。只有外部 oracle（测试/编译/工具报错）给得出可靠归因。
  5. 代价是约 15× token，且 token 用量解释了约 80% 的性能方差。本质是"用 token 买并行探索的广度"，不是模型更聪明。
  6. 自主性越高，单步错误越会在后续步骤复合放大；workflow（写死控制流）可预测可调试，agent（模型自主）要为不可预测付误差复合的代价。能用确定方案就别加 agentic 复杂度。

C · 应用判别层

  1. swarm/handoff。supervisor 模式下子 agent 不能直接回用户、要经中心"翻译"，产生信息损耗与 handoff 消息堆积；动态路由 + 需直接回用户正是去中心交接的适用场景（LangChain τ-bench 实测 swarm 占优）。坐标：横轴=多 agent，纵轴=反应式。
  2. agentic search（grep/glob 现查）。代码多是精确标识符（关键词检索更准），向量库还要索引同步、否则静默返回过时内容。Anthropic 实测对代码 agentic search 大幅胜出；官方建议默认从它起步、不够再加语义层。
  3. 状态活在外部进度文件 + git（不靠 compaction，它有损）。写文件 / 改库这类有副作用、不可逆的动作要走渐进承诺（先 dry-run / 只读侦察）+ 必要时审批门；危险操作前留人在回路。
  4. 用跑测试拿报错再改（自愈循环 + 失败日记）。单元测试是外部 oracle，给得出客观归因；纯自我检查没有 ground truth，会让结果更差。配合 §3.5 把失败教训存进情景记忆，避免重复同一错误。
  5. 用 Plan-Execute / 并行编排，不上多 agent。步骤可预先列举 → 横轴落在规划-执行/并行（可并行就上 LLMCompiler）；环境低动态不需要 ReAct 的逐步反应；任务简单时单 agent 更省更准，多 agent 在这里是纯粹的成本失控。
进阶挑战 · 刚好够不着

给一个真实需求走一遍六步选型法

挑一个你手头或设想的 agent 需求，按第 09 章的六步选型法从头走一遍：判三判据（定性/规则/结构化？）→ 步骤能否固定顺序 → 步数是否运行时才知 → 要不要跨会话/多 agent → 叠哪些护栏与人在回路。写出每一步的判断和它把你导向的模式，最后画出这个系统的 Harness 草图（工具 / 循环 / 记忆 / 护栏 / 观测五块）。

提示（卡住再展开）

卡在哪一步，就回对应的章：横轴判断回 01 §1.3 与 05；记忆回 03；多 agent 回 07；护栏与权限回 08。记住第 09 章的纪律：默认走最简方案（单 agent + 工具），只在简单方案被证明不够时，才向更复杂的格子升一级。