思考题参考答案¶
本文件汇总全书十章思考题的参考答案提纲。思考题多为开放性问题，答案不唯一。参考答案为 AI 生成，人工略作审校，仅供读者对照启发之用。建议读者使用 LLM 结合书稿内容进一步讨论这些问题。
第一章 AI Agent 入门¶
1. (★★) 如果你只能给一个 Agent 系统增加一项能力——更强的模型、更丰富的上下文、还是更多的工具——你会选哪个？在什么条件下你的选择会改变？
对应"大脑/眼睛/手脚"公式，先找短板：通常优先补上下文，即补充观察空间（observation space）。若任务超出模型推理能力，换更强模型。若动作空间不足（例如无法访问公司内部系统），加工具。判断依据是分析失败轨迹，定位瓶颈在感知、决策还是行动。
2. (★★★) ReAct 循环中，Agent 的每一次 LLM 调用都会看到完整的历史轨迹。随着轨迹增长，这种设计的成本是二次方增长的。有没有办法在不丢失关键信息的前提下打破这个二次方？
可行手段：静态前缀不变可用 KV 缓存复用，降低重复计算；上下文压缩——摘要早期轨迹、只保留结论与关键状态（第二章的多层压缩）；外部化学习——把中间结果写入文件/知识库，按需检索而非常驻上下文；委托子 Agent，各自保持短轨迹，只回传生成的 artifact。
3. (★★) "模型即 Agent" 范式意味着模型在工具调用决策上越来越自主。但本章论证了 Harness 工程的重要性反而在增加。这两个趋势如何共存？Agent 框架未来的核心价值体现在哪些方面？
马与缰绳隐喻：模型越强、自主空间越大，出错影响面越大，越需约束、验证、纠正。框架价值从"编排 LLM 调用"转向 Harness 五要素中的保障层：权限分类、熔断器、错误恢复、上下文压缩、工具生态。模型厂商优势是模型与 Harness 协同优化；框架应以最小抽象让开发者专注业务逻辑。
4. (★★) 消融实验中 "工具结果反馈" 的缺失导致 Agent 陷入无限循环。在生产环境中，除了工具结果缺失，还有哪些情况可能导致 Agent 循环？你会设计怎样的检测和终止机制？
其他诱因：工具反复报同一错误、幻觉调用不存在的工具、上下文被压缩丢失关键状态、思考过程被剥离导致模型 API 报错、任务本身无解。机制：设最大迭代次数等停止条件；检测重复调用（相同工具+参数指纹）；熔断器在连续失败时"跳闸"；超过失败阈值升级人工干预（LangChain 的循环检测即例证）。系统的讨论见第五章"故障与错误恢复"一节：四层故障分类，以及"检测—恢复—终止"三层机制。
5. (★) 本章用感知、行动、策略三个维度分析了五个 Agent 产品。请选择一个你日常使用的 AI 产品，用这三个维度进行分析，并思考它的架构设计是否合理。如果由你来设计这个 AI 产品，有哪些改进空间？
开放题。要点：仿照章中表格，写出眼睛（能看到什么信息源）、手脚（动作空间是否开放式、能否内部思考）、策略（Agent 执行循环的模式）；评估三者是否匹配——常见短板是感知不足（看不到关键状态）或缺人工干预点；改进可从补上下文、通用化工具、加约束/验证/纠正三层入手。
6. (★★) 如果你要设计一个专门处理航班订票的客服系统，你会选择工作流模式还是自主 Agent 模式？有没有可能在同一个系统中混合使用两种模式？
主体用工作流：身份核实→搜索→付款→预订四节点，保证"付款前不能预订"等合规顺序，且把提示注入攻击面限制在单节点内。开放性环节（理解需求、改签、航班取消推荐替代方案）切换自主 Agent。可混合；高风险操作（大额付款、退款）加人工确认。
7. (★★★) 护栏部分提到了工具风险评级。如果一个工具在大多数情况下是低风险的，但在特定参数组合下变为高风险（如 delete_file 删除普通文件 vs 删除系统文件），你会如何设计动态风险评估？
评级对象从"工具"细化到"工具+参数"：按可逆性、权限、影响面在调用时计算风险。用基于规则的确定性检查（路径黑白名单、正则）而非模型判断——验证应只看结构化数据，防提示注入操纵。辅以故障安全默认值（默认拒绝、显式放行）、沙盒试执行、高风险触发人工确认，多层护栏组合。
8. (★★) 本章的 Agent 产品表格中，所有 Agent 的动作空间都是 "开放式" 的。一个受限的动作空间（比如只能从预定义选项中选择）在什么场景下反而优于开放式？
高合规、高风险、错误不可逆场景：如退款、付款，受限选项即"约束"，天然防呆，从设计上让错误无法发生。也适合单步简单任务（章中提到可用不带思考的模型的场景）——受限空间降低幻觉与提示注入影响面、便于验证、延迟成本更低。开放式的价值在步骤数不可预测的开放问题。
9. (★★) 人工干预机制要求 Agent 能 "优雅地移交控制"。但在实践中，用户可能不在线、响应很慢、或者给出模糊的指令。此时 Agent 应该怎么办？
要点：默认故障安全——高风险操作在无确认时暂停而非默认执行；先做可逆的低风险部分，留下清晰的交接制品（状态、待决策项），便于恢复；用异步沟通工具（消息、邮件）通知并设超时策略；指令模糊时用意图澄清（如 GPT-5.6 先提问再执行）；保持透明，展示决策轨迹让用户可快速接管。
10. (★★★) 引言指出 "好的设计原则应该穿越模型的迭代周期"。试举一个你认为可能会随模型进步而过时的当前 Agent 设计原则，并说明理由。
示例：少样本提示、精细提示工程——模型零样本泛化增强后收益递减；通过限制采样实现的严格工具调用格式——目前 SOTA 模型工具调用格式已经比较稳定；人工编排的多步工作流——模型指令遵循能力提高后不再需要。而约束、验证、纠正这类原则会长存。
第二章 上下文工程¶
1. (★★★) 实验 2-3 发现，滑动窗口对话历史会导致 Agent 反复执行相同的工具调用。但完整保留历史又会让上下文不断膨胀。设计一种策略，既能避免信息丢失，又能控制上下文长度，且不破坏 KV Cache 前缀。
用压缩代替丢弃：消息只追加不删改，接近阈值（如窗口 80%）时在两次 API 调用之间批量压缩旧 tool results，失效仅限替换点之后。参照分层机制：大输出落盘留摘要、噪声直删、归档式摘要保留脉络；标识符与 pass/fail 原样保留。更釜底抽薪的是子 Agent 隔离，让海量中间状态不进主上下文。
2. (★★) Qwen3 的 Chat Template 思维链保留机制只保留 "最后一个真实用户消息之后" 的思考。如果一个 ReAct 循环跨越了上百轮工具调用，累积的思考内容可能消耗大量上下文。你会如何修改这个机制来应对超长循环？对比 DeepSeek（剥离全部历史思考）的策略，各有什么利弊？
可只完整保留最近若干轮思考，更早的在调用间隙做归档式摘要或提炼进状态栏，一次性付缓存重建代价。Qwen3 保留：多步思路连贯（草稿纸不被收走），但超长循环膨胀、易腐化；DeepSeek 剥离：省 token，但每轮改写历史破坏前缀缓存、推理连贯性受损。Claude 则要求带签名回传 thinking block。
3. (★★) 上下文感知压缩实验中，从约 148K 个字符压缩到约 2,000 个字符，这种极端的压缩是否存在"不可逆信息损失"的风险？如何解决？
有风险，压缩是任务相关的有损投影，问题落到未保留维度就崩塌。解法："有损压缩＋无损索引"，每条事实带来源 URL 可回溯；原始输出存磁盘、只看摘要预览；显式保留优先级——架构决策、语义完整性（时间、公司名）、验证状态、UUID/hash 等标识符原样保留；自适应窗口化推迟压缩时机。
4. (★★) Agent 状态栏将隐式状态显式化。但如果状态栏本身包含了错误信息（比如工具计数器出了 bug），Agent 可能基于错误的信息做出有害的决策。这种"元信息可靠性"问题如何缓解？
模型几乎无条件相信状态栏，错误会原样传导。缓解：①用确定性代码维护，绝不让 LLM 批量统计长历史（要用也逐条抽取、代码汇总）；②把状态栏准确率当一线生产指标盯；③信息只来自对真实世界的可靠观测，防状态栏投毒。
5. (★★) 提示工程消融实验表明，信息组织的混乱导致成功率下降 30% 以上。但在实际开发中，系统提示词往往由多人在不同时间维护。你会用什么工程实践来防止系统提示词的 "熵增"？
①把提示词当代码：版本控制、评审，产品经理定业务规则、工程师负责编码；②用 Tau-Bench 类基准测试做回归测试，改动前后跑消融实验定位影响；③强制结构化：SOP 流程驱动而非规则堆砌，XML/Markdown 分层；④片段按"可缓存/破坏缓存"分类命名，动态内容归到缓存边界后；⑤膨胀内容拆成 Skills 按需加载。
6. (★★★) 本章提出"上下文学习本质上是检索而非推理"。如果这个论断成立，当前所有基于"把更多信息塞进上下文"的优化方向都需要重新审视。你认为应该如何突破这一局限？
给"只有一半的检索引擎"补提炼层：①上下文蒸馏/状态栏，用代码提前算好结论供直接检索；②主动压缩，把原始记录换成高密度结构化知识；③子 Agent 隔离，噪声不进主上下文；④交互作为第三轴，外部仪器观测写回模型想不出的新信息；⑤前沿方向：可编辑、可组合的 KV Cache"笔记"，及跨会话记忆沉淀。
7. (★★★) Skills 的渐进式披露只在 Agent 判断需要时才加载完整内容。但这个判断本身依赖模型的能力——如果模型不知道自己不知道什么，就无法正确触发 Skill 的加载。这个"元认知"问题如何解决？
①元数据常驻上下文末尾（注意力最优位置），让模型始终"知道自己拥有什么"，把元认知转化为路由匹配；②description 写成路由条件而非功能介绍："Use when / Don't use when"加反例——缺反例路由准确率明显下降；③避免宽泛描述（如"help with backend"）；④对齐厂商训练方法论：Claude 对该模式专门训练过；⑤把路由准确率当可测指标迭代。
8. (★★) Skills 机制中，Agent 从 SKILL 文件中动态读取提示词之后，后续的操作能否正确遵从这些指令？不同的模型对 Skills 模式的支持有什么区别？
取决于 Skill 的注入方式：注入 system prompt 遵循最强但破坏 KV Cache；作为普通文件读到上下文中间，模型的指令遵循可能较差；注入到上下文末尾，指令遵循较好，但每次工具调用都需要重新计算 skill 部分的 KV，成本较高。
9. (★★★) 本章强调动态信息（如系统时间戳、工具列表顺序）的变化会破坏 KV Cache 前缀命中。在一个拥有大量工具且工具集频繁变动的生产系统中，你会如何设计上下文布局来最大化缓存命中率？
①少量稳定核心工具（如七个）＋通用执行器，具体能力走 Skills 渐进披露，工具定义冻结在静态前缀、固定顺序（动态排序对选择能力几乎无影响却毁缓存）；②动态可用性经末尾 user-role meta 消息增量注入，只发一次、永不重复；③运行时条件归到缓存边界之后，避免 2^N 缓存键爆炸；④子 Agent 与父 Agent 前缀字节级对齐。
第三章 用户记忆和知识库¶
1. (★★) 在用户记忆系统中，当同一用户在不同会话中提供了矛盾信息（比如两次提到不同的家庭住址），记忆系统应该如何处理这种冲突？
用 Mem0 式"提取—对比—决策"流水线：先向量检索出相近旧记忆，再由 LLM 判定 ADD/UPDATE/DELETE/NOOP，如"搬到上海"应 UPDATE 覆盖"住在北京"；版本化：地址类信息只保留最新版并标记时间戳，工作经历类保留完整历史；检索侧可借上下文前缀（人物、时间、意图，如电汇三次修改案例）判断哪条最终有效。
2. (★★) 上下文感知检索将原始文档的上下文附加到每个分块。但如果原始文档本身结构混乱或存在矛盾信息，这种方法可能传播甚至放大错误。你会如何在检索阶段引入 "信息质量" 信号？
借鉴"知识库时效与治理"：给分块附加版本号、生效/失效时间、来源等元数据，检索时过滤已失效内容，或在前缀中显式标注"此条已于某日废止"；重排序阶段把来源权威性、时间新鲜度纳入打分，而非只看语义相关性；索引期让生成前缀的 LLM 顺带检测块间矛盾并标记，类似记忆的版本化冲突检测。
3. (★★★) 智能体化 RAG 让 Agent 主动决定何时搜索、搜索什么、以及是否需要继续搜索。但如果模型不知道自己不知道什么，就无法正确触发搜索。这个 "元认知" 问题如何解决？
①在 prompt/skills 中把"评估信息是否充分"固化为显式步骤：如实验 3-9 中先并行检索子问题，发现缺"前科如何影响过失罪量刑"这一关联，再二次检索；②让轻量元信息常驻上下文提供全局视野：JSON Cards 概览、OpenViking 的 L0/L1 摘要，使 Agent 知道"库里有什么"，从而发现自己缺什么。
4. (★★) 多模态信息提取将图表转为文本描述后再进行检索。这个 "翻译" 过程可能丢失视觉信息中的空间关系。举一个具体例子，说明纯文本描述无法完整传达的图表信息，并设计一种保留该信息的方案。
例：折线图中两条曲线的交叉点位置（"A 在 2023 年中反超 B"）、或 PDF 表格中单元格与表头的行列对应，OCR 成线性文本后空间对应关系丢失。方案一：原生多模态处理，ViT 把图切成 patch 与文本共存于统一语义空间，模型直接"看"版式；方案二：工具化分析——先低成本文本摘要入库，检索命中后再调用 analyze_image 对原图按需深入。
5. (★★★) Rich Sutton 的 "苦涩的教训" 认为通用方法（搜索和学习）最终会胜过手工设计的特征。本章构建的整个知识系统（分块策略、索引结构、检索管道）是否本身就是一种 "手工设计"？如果模型能力足够强，这些设计是否会被简单的 "全量输入" 所替代？
确实是手工设计，部分环节（分块、融合调参）可能随长上下文而弱化；但黑猫白猫案例表明"全量输入"也不够：注意力是软检索，跨文档聚合统计仍需索引期预提炼；知识过期更新、权限/租户隔离、可审查性、成本这些工程约束与模型能力无关；且检索与索引期 LLM 提炼本身就是"搜索+学习"的通用方法，并非与苦涩教训对立。
6. (★★★) 随着模型能力的提升，你认为领域知识库还重要吗？未来强大的基座模型是否有可能包含领域知识库中所有的信息，从而不再需要领域知识库？
仍重要：训练数据有截止日期，知识库可随时更新；企业内部流程、私有判例等根本不在公开语料中；多用户共享需权限过滤与租户隔离，参数中的知识无法按调用者裁剪；外部存储可审查、可版本控制、可下线失效内容，参数记忆做不到；即使走参数化路线（User as Engram），也面临"存进去是一回事、知道何时取用是另一回事"的难题。
7. (★) RAPTOR 通过自底向上的层次摘要构建树形索引，GraphRAG 通过实体关系构建图结构索引。这两种结构化索引分别擅长回答什么类型的查询？
RAPTOR：从宏观概念逐步钻取细节的"跨层穿梭"式查询，如先定位"SIMD 指令集"摘要再下钻到 SSE 细节，兼顾总览与细节两种粒度。GraphRAG：多跳关系推理（"我的医生所在医院的地址"沿关系链遍历）与实体消歧（两个"张医生"是不同节点）等"A 和 B 有什么关系"类查询，社区摘要还提供主题聚类。生产中组合使用更佳。
8. (★★) 文件系统范式将知识组织为类似文件系统的层次结构。这种方式和传统的向量数据库 RAG 相比，在什么场景下更有优势？
纯文本可被用户直接阅读、编辑、修正，可用 Git 版本控制与回滚——适合需要人机共同维护、审查知识的场景；Agent 有 write_file 能力即可自主记录经验，形成记忆自演化循环（外部化学习）；L0/L1/L2 渐进披露使多数查询到 L1 即可决策，省 token；前提是像 Wikipedia 一样建立交叉链接和索引页，否则孤立文件越多越难检索。
9. (★★★) 从结构化数据（如司法判决数据库）中自动发现 "裁判因素" 和 "因素重要性层级"，本质上是让 Agent 从数据中归纳规则。这种数据驱动的知识提取是否能达到人类专家手工编写规则的质量？
优势：如 CAIL2018 实验，"自下而上"因子发现更贴合数据而非人类先验，能捕捉散落在成千上万判例中、专家难以显式写出的隐性权衡经验，且可量化。局限：LLM 提取出错会造成知识污染，数据本身的偏差会被继承，聚类原型只反映相关性、说不清因果。折中：数据驱动建模＋专家审核 Schema 与结果，模型驱动提问、统计支撑解释。
第四章 工具¶
1. (★★) MCP 标准将工具定义从 Agent 框架中解耦了出来。但标准化也意味着复杂的工具交互模式（如流式输出、双向通信、有状态会话）可能难以在标准协议中表达。你认为 MCP 未来最需要扩展的能力是什么？
最需要跨会话的事件驱动能力。MCP 主体是请求-响应式，notifications、progress、sampling、elicitation 等原语都限于保持连接的单个会话内，通知只能说"资源变了"，无标准方式触发 Agent 思考循环，更无法唤醒离线 Agent。
2. (★★) 在异步 Agent 架构中，事件队列的优先级策略需要在设计时确定。但如果优先级判断本身需要语义理解（比如判断一条新消息是否比当前任务更紧急），这个判断应该由谁来做——规则引擎还是另一个 LLM 调用？各有什么代价？
分层混合：事件类型明确的（user.interrupt、tool.result）用规则硬编码，零延迟、确定性强，但无法理解"马上停下来"与"今天天气怎样"的语义差异；语义模糊的交给轻量分类 LLM 做事件路由器（章中建议），代价是数百毫秒延迟、额外费用、可能误判，且需像 Sidecar 一样只读结构化字段防提示注入。
3. (★★) 在 MCP 生态中，不同的 MCP 服务器可能提供功能高度重叠的工具。当 Agent 面对多个来源不同但功能相似的工具时，应该如何选择？如果不同来源的同名工具在行为上略有差异（比如一个返回摘要，另一个返回全文），Agent 是否有能力感知并利用这种差异？
选择依据：接入前审查描述、锁定版本、配最小权限凭证，警惕同名工具遮蔽（tool shadowing）把敏感调用路由给恶意方；运行时靠层次化分类和动态发现缩小候选。差异感知取决于描述质量：若描述明确写出返回格式、边界和执行代价（如"只需元信息请用 get_page_metadata"），模型能据此利用差异；描述含糊则只能猜测——应优先修描述而非怪模型。
4. (★★★) Agent 代表用户与外部世界交互时，本质上面临一个身份选择：是用独立的虚拟身份（专属邮箱和电话号码）以第三方身份行动，还是直接以用户本人的身份操作其个人账号？前者可以在后台自主操作，但第三方可能不信任一个非真人的身份；后者拥有更完整的上下文和权限，但引入了信任授权和安全边界的问题。你认为在什么场景下应该选择哪种模式？
默认虚拟身份：后台自主、可审计，出错或被攻破时不暴露用户全部数字身份，如秘书用自己的办公邮箱；需应对 CAPTCHA/IP 信誉问题（住宅代理）。必须以本人身份的场景（账户身份验证、三方通话确认，如 Pine 打客服电话）用 HITL 认证：VNC/RDP 让用户可视化亲自登录，会话令牌有效期内复用。判断标准：对方是否要求账户持有人本人、操作风险与凭证范围。
5. (★★) 在队列式事件处理中，模型倾向于只关注最后一个事件，本章通过 Agent 状态栏标记和汇总来缓解。但如果队列中积压了 20 个事件（10 个工具结果 + 5 条用户消息 + 5 个系统提醒），你会如何组织这些事件的呈现顺序和格式，使模型不遗漏关键信息？
先用轻量 LLM 分类去重：紧急事件（告警、用户中断）单独走取消式处理，不混入批量。呈现时按类型分组编号（[未处理事件 i/20]），10 个工具结果超长的截断持久化到文件、只留头尾与路径；用户消息因训练偏好"最新输入"而放末尾突出；结尾加汇总清单（各类事件数量+要求逐条回应），并让模型输出对照确认，防遗漏。
6. (★★★) 子 Agent 的上下文传递有四种策略（最小化/手动/自动/LLM 生成）。过少的上下文会导致子 Agent"盲目执行"，过多的上下文则引入噪声和隐私风险。请设计一个自适应的上下文传递机制，根据任务类型和敏感度自动选择合适的策略。
用轻量分类器（Sidecar 式）对任务打两个标签：复杂度与敏感度。简单高频（查天气）→最小化传递；中等复杂→自动裁剪（用户基本信息+近 3 轮对话+相关工具结果）作默认；复杂任务（报告、客服）→LLM 生成上下文，业务规则内置隐私过滤（不传支付信息）与压缩（超 10 轮只传摘要）。兜底：子 Agent 报信息不足时升级策略或多轮交互追问，来源须打 [FROM_MAIN_AGENT] 等标注。
7. (★★) 本章提出了"执行-验证-反馈"闭环（如写代码后自动运行 linter）。这种"操作后立即自动验证"的模式还可以应用到哪些工具场景？是否存在某些操作，其验证本身的成本或风险超过了操作本身，导致这种模式不可行？
可推广：改配置后沙盒实际运行验证生效；生成文档/演示文稿后渲染成截图做模态切换检查排版；Excel 写公式后重算比对；命令执行后检查退出码与关键词。不可行的：发邮件、拨电话、对外转账等不可逆不可幂等操作——"验证"要么无从观察，要么本身再触发一次真实世界事件；此时应改用事前手段：预检-确认两段式加提议者-审核者事前审批。
8. (★★) 本章提出了"工具爆炸"问题——Agent 面对数千个工具时选择精度下降。除了主动工具发现，还有哪些方案？可以参考人类专家在面对大量可用工具时的策略。
①检索式预筛选（本章"工具生态"一节，语义相似度先筛候选）；②层次化分组：先定位"服务器/App"再选具体工具，如图4-8；③Skills 式"按需查阅"：像查工具书，薄目录常驻、细节按需加载；④仿人类专家：少数常用基础工具"放在手边"常驻上下文，其余靠目录索引；⑤多 Agent 分工，每个子 Agent 只带本领域工具子集。
第五章 Coding Agent 与代码生成¶
1. (★★) 代码生成被称为 Agent 的"元能力"。但代码执行引入了安全风险——Agent 生成的代码可能包含漏洞、无限循环或资源耗尽。沙盒隔离能解决部分问题，但也限制了代码能力（比如无法访问网络或文件系统）。如何在安全性和能力之间找到最优平衡点？
沙盒不是开关而是一组工程选型：按场景分级隔离（进程级/容器/microVM）；网络默认断网、白名单代理按需放行——掐断外传出口比识别注入更确定；源码只读挂载、凭证根本不挂载；资源限额加超时，且返回结构化错误让 Agent 可修正；持久会话保活在沙盒内，持久化的是可审计的文件与脚本而非运行中进程。
2. (★★★) Agent 自举——能创造 Agent 的 Agent——实现了"智能的自我繁殖"。但每次自举都可能引入新的偏差或错误，这种错误会在代际间累积吗？如何防止 Agent 自举的退化？
若每代在上代产物上继续繁殖，四类缺陷（上下文管理随意、工具描述不规范、技术选型滞后、生态脱节）会累积。防退化：始终以人类验证过的高质量范例为基线"复制加变异"，而非链式继承；用 Harness 验证兜底——标准消息格式与工具协议检查、可运行测试作验收（实验 5-12）；维护 SOTA 知识库防选型过时；Git 回退不合格产物。
3. (★★) 代码生成 Agent 在处理日志解析时，能自动跟随格式演化。但如果格式变化是一个 bug 而非预期改动，Agent 的适应性反而掩盖了问题。Agent 应该如何区分"需要适应的变化"和"需要报告的异常"？
适应前先诊断：对照架构文档与 PRD 判断新格式是否符合预期（实验 5-8 的思路）；核对版本控制记录，确认变化对应合法代码提交还是无来源漂移；类比 τ-bench 的 log_mismatch，即使选择适应也记录告警、自动建 issue 而非静默兼容；不确定时走人在回路确认。原则：适应与报告并行，适应不吞掉异常信号。
4. (★★) 本章在 PPT 生成、视频编辑和日志可视化中反复使用提议者-审核者机制。如果 Reviewer 的审美偏好与目标用户不一致，比如 Reviewer 认为信息密度合理但用户觉得太拥挤，反馈循环会收敛到错误的局部最优。如何让用户的偏好反馈也参与 Reviewer 循环？
把用户反馈作为最高优先级的结构化事件注入 Proposer 轨迹，与 Reviewer 建议同格式（页码、问题类型、严重程度）；用户裁决覆盖 Reviewer 判断；将用户偏好外部化沉淀——写入 MEMORY.md 或项目指令文件，更新 Reviewer 的评审标准（共享目标约束），使偏好跨任务生效；交付 HTML 活文档，降低用户下钻和点评的成本。
5. (★★) 本章展示了 Coding Agent 把执行和调试中获得的经验沉淀回代码库的多种方式——写入知识库文件、更新架构文档、维护项目指令文件、把操作序列固化为代码。如果把这些经验进一步提炼为系统提示词中的规则，规则集会随时间不断膨胀。如何对沉淀下来的规则做"垃圾回收"——识别并清理冗余或过时的条目？这种由 Agent 自己沉淀经验的机制，与第八章将讨论的系统提示词自动优化有何异同？
GC 思路："约束优先于指导"——能编码进 Linter/CI/工具校验的规则移出提示词；追踪规则命中率，借鉴 LangChain"分析失败轨迹"的数据驱动方法识别冗余；定期让 Agent 对照代码库验证规则仍成立（过时文档比没有更糟）；Markdown+Git 使删改可审计可回滚。与第八章同属不改权重的外部化学习；异在本章是执行中增量沉淀，第八章靠评估信号驱动系统性增删优化。
6. (★) "对远程工作友好的团队往往也对 AI Agent 友好。"你所在的团队或组织，在知识文档化方面距离"AI-ready"还有多远？最大的障碍是什么？
开放题。可用本章代理指标自查：远程新人只靠仓库和文档能否独立开展工作。检查项：决策是否记录在文档、上下文是否写进 issue/PR、构建测试命令是否有 CLAUDE.md/AGENTS.md 类指令文件、部落知识是否沉淀为开发者指南。常见最大障碍：依赖"问旁边同事"的口头传递与白板文化——Agent 读不到口头约定，只读得到文档。
7. (★★★) Simon Willison 提出了 Agent 的"致命三要素"（访问私有数据、暴露于不受信任内容、具备外部通信能力），本章在此基础上增加了第四个——持久记忆。在一个需要同时处理这四种要素的生产环境中，你会如何设计安全策略？
按四类边界分层设防。数据边界：凭证不挂载、源码只读，最小可见。输入信任边界：来源标注、外部内容降格为"可参考、无指令效力"的数据（忠诚度守则）。输出影响边界：默认断网加白名单出口、命令语义解析而非黑名单、Sidecar 独立复核加人在回路——关键操作必须由上下文之外的机制复核。跨会话边界：写入 MEMORY.md 需经与外部内容同等的信任审查。目标是被注入也执行不出去。
8. (★★) Artifact 模式让 Agent 生成的 SQL 或前端代码直接在用户浏览器或数据库中执行。但生成的 SQL 可能执行破坏性操作，生成的 HTML 可能包含漏洞。如何确保系统的安全性？
SQL：查询用最小权限只读账号执行；语义解析识别嵌套的破坏性操作（如 DROP/UPDATE），不可逆操作走独立审批与人在回路；数据不经 LLM 直达前端，也缩小泄露面。HTML/UI：优先 A2UI 类声明式协议——Agent 只输出界面描述 JSON，客户端用受信组件目录渲染，不执行任意代码（防提示注入导致的类 XSS 效果）；确需任意代码时沙盒化渲染并限制外联。
9. (★★) 将业务规则编码为工具内部基于数据库真值的校验，并用参数设计引导模型在调用前核对政策条件，本质上是用代码结构来约束 Agent 行为。这种"代码即规则"的模式相比自然语言规则有什么优势和局限？
优势：无歧义、确定性（同输入同输出）、擅长复杂条件组合；政策事实一律取自数据库真值和服务端时钟，不采信模型自报值，幻觉和提示注入都绕不过，是防不可逆操作的最后守门员；expected_* 参数兼作强制 checklist 引导思考。局限：代码不会解释政策、不会找变通方案（如"改签而非取消"），且有维护成本。结论：与自然语言规则互补而非替代，三重保障配合。
10. (★★) Artifact 模式让 Agent 生成 SQL 或可视化代码，由前端直接执行，绕过 LLM 处理大量数据。这种"Agent 生成代码，系统执行代码"的分工模式，与传统的"Agent 直接给出答案"的模式相比，有什么优劣？
优：数据从数据库直达前端，绕过 LLM"中间人"——快、省 token、避免抄写数千行数据时的幻觉错误；代码可审计、可复用，还能组成流水线（SQL 结果直接喂给可视化代码）。劣：LLM 看不到查询结果，无法基于数据内容做进一步归纳和决策；依赖前端执行基础设施并引入第 8 题的安全问题；出错需回传报错再迭代。适合大数据量呈现，不适合需模型消化数据再推理的任务。
第六章 Agent 的评估¶
1. (★★) LLM-as-a-Judge 使用语言模型评估语言模型的输出。这种 "自我评估" 是否存在系统性盲区——比如模型可能一致地给某种风格的回答打高分，而这种偏好与人类评判不一致？如何检测和校正这种偏差？
存在：长度偏差、位置偏差、同源模型被钻空子（古德哈特定律）。检测：建 100-200 例人工金标集，测评判与人类的 Cohen's kappa（>0.7 才放量）；定期审计评分与回答长度的相关性；红队构造对抗案例。校正：Rubric 显式惩罚冗长、限长度；配对评判交换顺序各评一次；多源异构评判（不同模型家族偏见正交）。
2. (★★★) 评估数据集的 "防泄漏" 设计至关重要。但在开源生态中，benchmark 数据一旦公开，很快就会被纳入训练数据。这场 "猫鼠游戏" 有终局吗？设计一种从根本上抵抗数据泄漏的评估方法。
静态题库无终局，只能追赶（SWE-bench-Live 靠收录训练截止后的新 issue；canary GUID 只能让泄漏可检测）。根本出路是公开"生成机制"、私有"具体实例"：像 τ²-bench、AndroidWorld 那样参数化模板每次随机实例化，验证基于最终环境状态而非固定答案序列——背题无用，只能靠真实能力。
3. (★★) Scale AI 的四准则（基于专家指导、全面覆盖、标准重要性权重、自包含评估）旨在消除评估的主观性。但某些任务维度（如 "回答是否有帮助""语气是否恰当"）天然具有主观性。如何为这些主观维度设计可靠的 Rubric？
用"自包含评估"准则把抽象标准翻译成可验证行为：不写"展示深刻理解"，写"引用至少两个权威理论并准确解释"。每档配具体示例和边界案例；Rubric 是迭代产物——试用中收集评价者分歧，逐渐演化为判例集。再辅以多评委加权/一致性检查、分歧案例送人工复核，并在金标集上校准一致率。
4. (★★) τ-bench 通过模拟真实用户行为来评估 Agent。但模拟用户本身也是一个 LLM——它可能系统性地低估某些边缘场景（如情绪激动、表达不清的用户）。如何验证模拟用户本身的质量？
τ-bench 初版教训：模拟器过于机械、指令过简（Agent 能猜对答案）。验证手段：人工抽检模拟对话，检查是否遵守渐进式透露、事实锚定（不编造脚本外信息）；与真实用户对话记录对比行为分布（模糊表达、情绪波动是否覆盖）；用小样本真实用户测试，看与模拟评估的排名是否一致；像 τ² 那样制定行为规范并迭代。
5. (★★) 配对比较（Bradley-Terry 模型）假设偏好是传递的（如果 A > B 且 B > C，则 A > C）。但人类偏好经常违反传递性。在 Agent 评估中，非传递偏好可能出现在哪些场景？这如何影响排名的可靠性？
场景：多维权衡时（A 准确但慢、B 快但简略、C 详尽但贵），不同评判者/任务看重的维度不同；长度、位置偏差也会制造循环判决。Chatbot Arena 的排名本就依赖用户提问分布。影响：BT 把实力压成单一分数，非传递时排名不稳定、随对局分布漂移。缓解：按能力维度分别排名、报告两两胜率矩阵、多源评判取一致。
6. (★★) 本章提出 "观察→假设→实验→验证" 的科学方法。但在实践中，Agent 的行为空间巨大，验证一个假设可能需要数百次评估运行。如何在有限计算预算下最大化评估的信息量？
分层假设、分阶段验证：低成本表层假设（H1/H2 提示词类）并行先跑，昂贵深层假设（H5/H6 换模型）条件化启动。统计上：先用标准误做保守筛子排除够不着的分差；同批任务用配对分析（McNemar），比独立比较灵敏得多；分差小于噪声带宽就不决策；多重比较要收紧阈值或复跑验证；评估集分辨不出预期收益时先扩集再迭代。
7. (★) 本章的假设案例中，全局启用思考（H4）虽然提升了总体成功率，却因延迟和成本被否决，最终演化为条件化启用（H7）。哪些信号（任务描述特征、历史失败模式、运行中的不确定性）适合作为"是否启用思考模式"的路由依据？是否存在思考反而有害的 Agent 场景？
路由信号：任务描述含计数/复杂推理特征（H7 用 1-2 秒快速 LLM 预判）；能力标签矩阵中历史失败集中的任务类型（如 math_counting）；运行中回退次数增多、工具连续报错等不确定性信号。有害场景：延迟敏感的实时交互（语音、UI 操作）；简单任务成本翻 3-5 倍纯属浪费——且思考长度与效果不一定正相关。
8. (★★) τ-bench 的用户模拟采用了 "渐进式信息透露"——不一次性提供所有信息，而是根据 Agent 的提问逐步透露。这种设计如何影响评估结果？如果模拟用户的信息透露策略与真实用户差异较大，评估结论还可靠吗？
影响：把"主动提问澄清需求"纳入考察，这是与全盘托出式 benchmark 的根本区别；分数由行动正确性和沟通策略共同决定。若透露策略失真（过于机械或过于配合），Agent 可能只是学会了"适配模拟器"（古德哈特），绝对分数不可外推；相对排序仍有参考价值。补救：用真实对话校准模拟器、人工抽检、明示结论适用边界。
第七章 模型后训练¶
1. (★★) 灾难性遗忘——一次针对特定任务的微调破坏了模型原有的通用能力（如通用工具调用）——在 Agent 场景下尤其棘手。相比全参微调，LoRA 冻结基座权重、遗忘风险更低，但并非免疫。有哪些策略可以进一步缓解微调带来的能力遗忘？
数据配比：仿实验 7-5，混入约 20% 通用/原分布数据，防新任务占比过高压垮旧能力；训练量克制：SFT 到"格式稳定、能力初具"即止，早停防塌缩；RL 用小 rank（8–32）并保留 KL 惩罚，把策略摁在参考模型附近；冻结关键组件（如 VLM 只训投影层）；按任务挂多个 LoRA adapter 隔离能力，并用通用基准做回归测试。
2. (★★) 后训练将能力固化为模型权重（"肌肉记忆"），而上下文学习将知识放在推理时的输入中。但有些能力（如领域知识）既可以通过后训练学习，也可以通过 few-shot 示例提供。你会用什么标准来决定某项能力应该走哪条路径？
知识类型：协议性（格式、风格、流程）适合固化进参数；事实性知识交给 RAG/上下文，SFT 记不住大量事实。更新频率：常变的放上下文（可动态更新、可追溯），稳定的才写参数。阶段与成本：探索期用 ICL 快速试错；产品定型、调用量大、延迟费用敏感时做 Prompt 蒸馏式固化。分布稳定性：部署分布可预期才值得训练。
3. (★★) 模型蒸馏让小模型学习大模型的行为。按能力层次，被蒸馏的模型大致可分为三级——Chat 模型（单轮对话、直接作答）、Reasoning 模型（带长链思考再作答）、Agentic 模型（多轮调用工具、与环境交互）。分别蒸馏这三类模型，难点有什么不同？
Chat：只学"输入→输出"映射与风格，标准 SFT 即可，难点最小。Reasoning：要完整思考轨迹，闭源模型有"思维围墙"，须选开源教师；须过滤答案错误的轨迹，否则学生连错带冗长一起继承（约恢复 70–80%）。Agentic：轨迹混有环境返回 token，必须 loss masking；学的是决策策略，离线模仿有协变量漂移，成败信号又稀疏滞后——最终需 On-Policy Distillation 加真实仿真环境。
4. (★★★) 在多轮 Agent 交互中，奖励的归因（credit assignment）问题比单轮更严重——一个最终的成功或失败很难归因到第 3 轮还是第 7 轮的决策。你会如何设计奖励分配策略？
算法层：长轨迹用带价值网络的 PPO+GAE 做细粒度归因；GRPO 把优势均摊到全轨迹、信号被稀释；turn-level 分摊是折中；γ 设 1。奖励层：中间步骤可判定时加过程奖励（V-IRL 每步 ±1）；仿 RLVP 用确定性规则逐动作给路径信号，补回全败/全胜组的组内方差。信号层：用教师逐 token 打分（On-Policy Distillation）把归因密到 token 级。
5. (★★★) 后训练、外部化学习和上下文学习构成 Agent 能力的三个维度。如果你有固定预算（比如 $10,000），要提升一个客服 Agent 的性能，你会如何在这三个维度之间分配预算？你的决策取决于哪些因素？
先用 ICL/Harness 工程快速迭代定位瓶颈（多数问题在这层就能解决）；产品知识、套餐规则等事实性、常更新内容投 RAG（可更新、可追溯、抑制幻觉）；语气、流程协议、工具调用格式稳定后用 LoRA SFT 固化（成本低）；RL 贵几十到上百倍，仅当分布漂移或示范拿不到时才上。决策因素：知识更新频率、调用量摊销、示范数据质量、能否搭建高保真环境。
6. (★★★) 在没有明确奖励函数、样本稀少的情况下，自主实现模型学习，被一些人认为是后训练的终极目标。当前的 RL 训练方法距离这个目标还有多远？你认为下一个突破最可能来自哪个方向？
差距：如 Silver 与 Sutton 所指，当前 RL 只能从最终成败学习，客服说"需要信用卡后四位"这类丰富反馈全被浪费，需数百次盲目试错；样本效率是主要瓶颈。可能的突破：基于世界模型；稠密化每步信号（On-Policy Distillation）；生成式奖励模型自主定原则、从一次失败学到方向；以及建模环境动态的 world model 路线。
7. (★★) 本章指出 LoRA 微调的成本并不高。那么，是否有可能给每个用户（或每个客户公司）训练一个专属的 LoRA，将用户记忆或企业知识写入参数，而非像第三章那样存储在外部知识库中？在什么场景下，"记忆写入参数" 比 "记忆存入知识库" 更有优势？又在什么场景下会适得其反？
技术上可行：一台推理服务器可挂多个 LoRA adapter 做多租户。参数化占优：稳定的术语、风格、流程协议等"该怎么说怎么做"；高频调用时省去长上下文的延迟与费用（Prompt 蒸馏逻辑）。适得其反：SFT 难以准确记忆大量事实（须继续预训练，成本剧增）；事实频繁变更、需可追溯审计时 RAG 更优；单用户样本少易过拟合，且有遗忘和隐私隔离风险。
8. (★★★) On-Policy Distillation 依赖更强的教师模型来监督学生。但 OpenAI 的 Weak-to-Strong Generalization 研究提出了一个反直觉的发现：弱模型的监督信号有时能激发强模型本身潜在但未被激活的能力。如果将这一思路应用到 Agent 训练，是否可能实现 "小模型教大模型" 的逆向蒸馏？
可能，关键是"验证比生成容易"：弱模型不当示范者（SFT 上限即示范者水平），而当验证器/奖励模型，由强模型自己探索、弱信号只负责挑好。章中先例：实验 7-7 显示 SFT 只是激活预训练已有能力——弱监督起"解锁"作用；DeepSeek-R1-Zero 证明强基模靠奖励即可涌现推理。风险：逐 token 模仿弱教师会硬编码其错误，须用结果级奖励而非分布对齐。
9. (★★) 过程奖励模型（PRM）评估每个思考步骤，而结果奖励模型（ORM）只看最终结果。但"正确的过程导致错误结果"和"错误的过程侥幸得到正确结果"哪个更值得奖励？在 Agent 的多步工具调用场景中，你会如何权衡？
侥幸成功更危险：违规抄近路往往抬高表面成功率（改测试文件、跳过验证），纯 ORM 会反向激励，是 reward hacking 温床。按 RLVP"奖励结果、惩罚路径"：坏动作便宜可验证，逐动作扣分；正确过程可给可验证的部分奖励（多过一个测试）。但过程约束勿过密——"推切"式更优策略正是结果奖励的探索自由发现的；中间步骤易判定用过程奖励，最优路径未知留给结果奖励。
10. (★★★) 本章讨论的评估数据集（如 SWE-Bench Verified、τ²-bench、AndroidWorld）既可以用于评估也可以用于后训练。但如果将评估集用于训练，它就不再是独立的评估集——这是否违反了训练集与测试集必须分离的基本原则？τ²-bench 的动态参数生成和 AndroidWorld 的参数化模板在一定程度上缓解了这个问题，但模板结构本身仍然是固定的。如何在充分利用评估数据的训练价值与维护评估独立性之间找到平衡？
复用环境，不复用题目：像 SWE-Gym 从同源数据新构建训练任务，SWE-Bench Verified 500 题严格隔离。分离要做到结构级：动态参数只防"背答案"，防不了模板过拟合——应留出整批未见模板/域外场景做评估（类比 V-IRL 训练纽约、测试九个陌生城市）。用参数化模板批量生成训练变体支撑课程学习，并以 OOD 成绩（而非同模板成绩）作为真正的泛化指标。
11. (★★★) 本章提出 "先形后神" 的训练范式：SFT 到 "格式稳定、能力初具" 即止，然后切换到 RL。但实践中，如何判断 SFT 已经 "足够" 而应该切换？
格式信号：输出可稳定解析（JSON、工具调用），解析失败率降到可让奖励可靠计算的水平（超 20% 则 RL 必败）。收益信号：再增加示范数据，新场景表现仍不上去——说明瓶颈已在 SFT 的记忆目标本身，到了临界点。过拟合信号：验证集性能开始恶化就应停——V-IRL 实验表明 SFT 过度训练塌缩到训练分布后，RL 也无法恢复 OOD 性能。
12. (★★★) ReTool 的训练动态显示（见实验 7-15），少数超长响应会显著拖长整个训练周期——一批 rollout 里绝大多数已经生成完毕，却要等那几条最长的响应收尾，其间集群的 GPU 利用率很低。如何提升这种长尾响应场景下训练集群的资源利用率？
从源头压长尾：DAPO 的 Overlong Reward Shaping 软惩罚超长响应；AdaptThink 式训练让简单题不展开长思考。调度层：解耦 rollout 与训练、异步流水；超长响应截断、留到下批续生成（partial rollout）；空闲 GPU 用连续批处理填入新请求。采样层：Dynamic Sampling 把算力集中在可学习区间，减少无效长 rollout。
第八章 Agent 的自我进化¶
1. (★★) Agent 自主搜索和集成开源库（自我进化）的能力极其强大，但也带来供应链安全风险。一个恶意的 PyPI 包可能被 Agent 自动安装和执行。你将如何缓解这个风险？
呼应本章"供应链攻击"一节：①沙盒环境中安装与运行，隔离文件/网络权限；②对新工具做自动安全扫描与"存前验证"测试；③设允许安装的库类型白名单，参考下载量、维护活跃度等信誉信号；④来源标记与追溯，高风险操作留人工审核；⑤定期审计工具库，防能力漂移与带毒工具复用扩散。
2. (★★) Voyager 式经验学习让 Agent 将成功的工具使用模式编码为可复用的 Skill。但 Skill 库不断增长后，检索正确的 Skill 本身变成了新的挑战。这是否构成了一个递归问题——Agent 是否需要一个"Skill 检索 Agent"来管理自己的 Skill？
不必递归：①渐进式披露把入口压成薄目录（仅 name+description 数百 token），模型按需逐层查阅，靠 grep/读文件的通用能力即可，无需专门检索 Agent；②层次化组织（如 MCP 服务器级→工具级两层匹配）收敛搜索空间；③"睡眠整合"式定期合并去重、修剪过时条目，控制库规模——递归止于一份足够薄的索引。
3. (★★★) 外部化学习将成功经验编码为策略摘要或工作流脚本。但"成功"的定义可能随时间变化（比如业务规则更新）。过时的经验不仅无用，还可能有害。你会设计怎样的"知识保鲜"机制来检测和淘汰过时经验？
①每条经验带元数据：来源任务、时间戳、命中/成功统计；②使用即检验：如实验8-2，回放失败即标记"可能过时"，回退重学并替换旧条目；③睡眠整合式定期离线整理——合并冲突、删除已证伪事实、相对日期转绝对；④淘汰策略：长期未命中或连续失败的条目降权、归档；⑤与投毒防御共用来源追溯与淘汰机制。
4. (★★★) 工作流录制将成功操作序列转化为可重放的自动化工具。但 API 会更新、UI 会改版，录制的工作流可能随时失效。如何让工作流能在环境变化时自动修复，或者至少不在出错的情况下幻觉认为任务已经完成？
用本章 PreAct 式两道闸门：①"先看清再动手"——把轨迹编译为带验证谓词的状态机，每步动作前核对实时界面（预期元素、URL 变化），谓词不成立即中止回放，回退完整 Agent 重做并重新编译；②"存前验证"——新工作流入库前重置环境完整回放一遍，用评判器确认真做成才准入库，防"流程走完、字段却是空的"假成功。
5. (★★★) 三种学习范式（后训练、上下文学习、外部化学习）分别对应模型参数、上下文窗口和外部存储三种知识载体。如果有一个急需上线的业务规则，应该用哪种方式？如果客服机器人回复用户的语言过于啰嗦，应该用哪种方式？如果希望让生成的 PPT 风格与公司现有 PPT 风格尽量相符，应该用哪种方式？这些技术选型与目前使用的模型能力是否有关？
①急上线规则：外部化学习——直接改系统提示词/Skill，即时生效、可审查；②回复啰嗦：稳定的行为与格式交给后训练固化（短期可先加提示词约束应急）；③PPT 风格：上下文学习——把现有 PPT 作范例/模板注入，或沉淀为 Skill 模板资产。选型与模型能力相关：强模型指令遵循好，提示词即可；弱模型规则易失效，需后训练固化。
6. (★★) Agent 从网络上搜索工具时，如何判断一个开源库是否"好用"？Agent 能否学会自己评估开源项目的质量？
判断维度（见实验8-4）：易用性、是否需注册 API key、文档完整性、依赖复杂度、数据完整性；关键是别只看文档——用代码解释器实际试跑验证，失败则切换备选而非幻觉。能学会：三层积累中的"知识层面"（哪些库适用哪类任务、免 key、兼容性坑）沉淀为启发式规则，"策略层面"元学习让评估本身越练越准。
7. (★★) 本章将 Agent 自我进化定位为"不改参数也能变强"的路径。但第七章指出，策略层面的改进最终还是需要强化学习来固化。这两种路径的边界在哪里——什么样的能力提升适合外部化，什么样的适合写入参数？
分工原则：事实性、易变、非公开的知识（业务规则、API 用法）适合外部化——更新快、可解释、可从单个边界案例学习（系统提示学习数据效率高，GEPA 少一两个数量级采样超 GRPO）；稳定的行为、格式与"肌肉记忆"适合 RL 写入参数——成功率高、延迟低。接力关系：先用外部载体快速迭代，策略稳定后再固化到权重。
第九章 多模态与实时交互¶
1. (★★) 语音 Agent 的端到端模型将 ASR-LLM-TTS 合并为单一模型，降低了延迟却失去了模块化。如果端到端模型在某个环节（如语音识别）出错，调试和修复比串行管道困难得多。你会如何设计端到端语音 Agent 的可观测性（observability）系统？
让模型伴随输出可读中间表示：如 Moshi 的"内心独白"文本流、声学事件标记（
<emotion>、<noise>），作为运行日志；用"自级联"定位错误层：同一模型先转录再推理，对照端到端结果判断错在感知还是思考；记录快慢解耦通道的状态栏文本与委派内容；离线按副语言理解、轮次判断等维度分项回归测试（如 StepEval-Audio-Paralinguistic）。
2. (★) Step-Audio R1 通过 MPS 双脑架构实现"边想边说"。但人类在"边想边说"时经常会说出未经深思熟虑的话、自我纠正、或使用填充词。Agent 的"边想边说"应该模仿人类的这些特征吗？
该模仿有信号价值的"不完美"：停顿、填充词是思考的外化，能掩盖延迟（
[THINKING]"嗯……"），由 LLM 决定插入位置；不该模仿破坏信任的自我纠正：方案一中快慢矛盾（"到底买不买？!"）会让信任崩塌；MPS 实验显示 CoT 开头多是复述问题，Speak-First 几乎不损准确率——早开口说铺垫是安全的，无需说错再改。
3. (★★) SoM（Set-of-Mark）及其结构化变体（DOM 元素索引）将 Computer Use 的视觉定位从开放坐标预测转为封闭 ID 选择，但都需要先检测和标注界面元素——无论靠分割模型还是靠 DOM。如果界面包含非标准控件或动态变化的元素，标注就可能不完整或不准确。这种情况下应该回退到坐标预测吗？
应保留坐标预测兜底：它是唯一不依赖标注的路线（SeeClick、Claude computer use），非标准控件、动态元素均适用；更实用的是混合：标注可得的元素仍用 ID 选择（选择题比填空题易答对），漏检元素回退坐标；回退须做分辨率匹配与等比缩放，否则坐标系统性偏移；章中结论：感知方案没有银弹，按界面与模型能力选。
4. (★★) XLeRobot 等千美元级机器人平台让遥操作数据收集变得廉价。但遥操作数据的质量高度依赖操作者的技能。一个不熟练的操作者提供的数据会如何影响 VLA 模型的训练？如何在数据收集阶段自动筛选低质量数据？
VLA 主要靠模仿学习（行为克隆）"看到什么学什么"，低质演示会把抖动、绕路、犹豫与失败动作当成正确策略学进去。自动筛选：以任务成败、轨迹平滑度、耗时与停顿统计过滤，辅以仿真回放验证；可借鉴 MGRD"先筛出高质量过程、再训练、再迭代"的思路。呼应第七章的判断：数据比架构更关键。
5. (★★★) 本章覆盖了语音、Computer Use 和机器人三种交互形态。这三种形态的共同趋势是从串行管道向端到端模型演进。如果这种趋势继续，五年后的 Agent 交互层会是什么样的？
按 TML 主张，交互性将内建于模型而非外挂 harness，"随智能一同扩展"；micro-turn 式连续多模态流推广到三场景：语音全双工已成，Computer Use 从逐帧截图走向连续观察（AOI 是过渡），机器人"边看边动"；快慢解耦不会消失：前沿推理模型是"移动靶子"，可换大脑的解耦与端到端长期并存；快慢接口或从文本升级为潜空间桥。
6. (★★★) 当前 Computer Use 以"截图 → 动作 → 截图"的离散循环运作，每次观察都是一张静态帧。但人类对屏幕的感知是连续的——我们能看到动画播放、观察加载进度、理解视频内容。这意味着今天的 Computer Use 根本无法处理需要时序视觉理解的任务。如何重新设计感知层以支持连续的视觉流理解？
重设计的是"观察接口"而非动作接口：把观察从动作中解耦，做成无需重训的感知中间件（AOI）；三个按需开闸的部件：像素门+小模型的帧间关键帧捕获、音量门控的语音转写（长出耳朵）、把帧叙述成持久文字；关键发现：起作用的是"叙述成能长期留存的文字"（八个模型 +17~48 个百分点）；部件须按模型逐个挑选，不一股脑全开。
7. (★★) DOM/Accessibility Tree 元素索引在标准 Web 应用上效果显著，但越来越多的软件界面（Canvas/WebGL 渲染、跨平台自绘控件）不提供可访问的结构化信息，只能依靠视觉标注或坐标预测。你认为 Computer Use 应该押注纯视觉路线，还是同时维护结构化和视觉两条路径？维护两条路径的成本和收益分别是什么？
短期双路径并存：结构化索引可得时定位最准稳、免分割误检；纯视觉是原生软件、Canvas、游戏的唯一选择。成本：维护 CDP/无障碍适配与视觉定位模型两套栈，外加路由判断逻辑。收益：各取所长，即章中"结构化可得优先，不可得回视觉"的选择逻辑。纯视觉在小元素、密集界面精度仍有差距，现在全押为时过早。
8. (★★) VLA 模型采用动作分块（action chunking）——如正文所述，π₀ 的典型配置是一次生成 50Hz 频率下 25-50 个未来动作——将推理延迟隐藏在执行时间里。但如果执行过程中环境突变（如物体被移走），预生成的动作序列就会失效。如何在动作分块的效率优势和环境变化的响应速度之间取得平衡？
分块本质是拿反应性换平滑性，块越长越迟钝；块长只需满足"推理时间＜块执行时间"的下限，不盲目加长；后台异步生成下一批并平滑拼接；执行中让感知持续运行，检测到环境突变即丢弃剩余动作、立刻重推理——相当于语音场景的"打断"；可动态调块长：静态场景长块省算力，动态场景短块保反应。
9. (★★★) 本章的三个场景（语音、Computer Use、机器人）都面临"感知-思考-行动"循环的延迟问题，都朝着快慢思考并行化的方向演进。在语音场景中，这表现为"说错了再纠正"；在 Computer Use 场景中，这表现为"先点再看"；在机器人场景中，这表现为"走一步看一步"。如何保证这些基于快思考的行动不会导致无法挽回的后果？
按可逆性给动作分级：说错可纠正但损耗信任（方案一"到底买不买"案例），点击多可撤销，机器人碰撞不可逆——快思考只许执行可逆动作；不可逆操作交"慢军师"把关，且仅当瓶颈在"想不想得到"而非"来不来得及"时才值得请（Latent Bridge 的边界结论）；用硬性契约约束快模型：如"状态摘要未确认完成前不许说办好了"。
第十章 多 Agent 协作¶
1. (★★) 共享上下文的多 Agent 协作中，后续 Agent 继承了前序 Agent 的完整上下文。但前一个 Agent 积累的"思维惯性"可能影响后续 Agent 的判断——比如继承了"需求分析师"上下文的"代码审查员"，可能还是倾向于从需求角度思考而非代码质量角度。如何检测和消除这种角色间的干扰？
检测：按实验 10-1 记录各阶段行为日志，对比"继承上下文"与"干净上下文"下审查结论的差异。消除：切换阶段时同时更换系统提示词与工具集（移除提问工具、换上 linter/测试工具）强化新身份；到信息饱和点改用"阶段切换式"方案——不共享上下文加显式移交包，审查员只看产物与需求，不看前序思考过程，即交叉验证的独立视角。
2. (★★) 管理者模式中，Manager Agent 负责任务分解和结果整合。但 Manager 本身的能力上限决定了整个系统的能力上限——如果 Manager 无法正确分解任务，子 Agent 再强也无用。如何确保 Manager 的分解质量？
依据 Plan-and-Act 的结论"弱规划者是系统瓶颈"，把最强模型与最精心的提示词分配给 Manager，而非平均分配。工程手段：分解产物先经审核者/交叉验证再执行（质量门控）；子任务定义明确验收标准与依赖关系；子 Agent 返回结构化摘要，Manager 据此重试或重新规划；按子任务复杂度动态分配步骤预算；控制 Manager 上下文（只存文件索引，不存全量内容）。
3. (★★) 去中心化模式借鉴了人类组织的最佳实践。但人类组织也有大量失败模式——沟通不畅、责任推诿、目标冲突。你认为 Agent 社会中最可能出现哪些"组织病"？如何预防？
对照 MAST 三大类：接口不清、职责重叠（系统设计缺陷）；目标理解不一致、信息被下游误解（对齐失败）；谎称"已完成"（验证缺失）。还有错误级联放大（传话游戏）、角色间循环移交、group chat 发散不收敛。预防：契约式接口与统一消息信封、任务状态机与验收验证、独立视角交叉验证、用测试/编译器等确定性外部反馈做"断链器"、精心设计终止条件。
4. (★★★) 在管理者模式中，当多个子 Agent 并行执行时，一个子 Agent 的发现可能使其他子 Agent 的工作变得毫无意义（比如搜索任务中一个 Agent 已经找到了答案）。设计一种高效的级联终止机制，实现"一个成功，全员停止"。
按实验 10-6：消息总线支撑双向通信；子 Agent 发
target_found，Manager 首个报告到达即加锁结算，后续重复报告幂等忽略（防竞态）；随后仅广播一轮terminate；子 Agent 在 ReAct 循环安全点定期检查终止信号，优雅清理（关浏览器会话、释放锁、写完文件）后回 ack；Manager 等全部 ack 或超时，无响应者强制终止兜底，辅以心跳/超时检测。
5. (★★★) 本章介绍的乐观锁机制解决了单文件的并发写入冲突，但实际的多 Agent 系统中，共享文件系统还面临跨文件的语义冲突、命名空间污染（Agent 随意创建文件导致目录混乱）和单点故障（一个 Agent 错误地删除了所有文件）等问题。你会如何设计更完善的文件系统治理机制？
分区治理：按表 10-3 四类区域划权限——私有 scratchpad 隔离试错、共享空间才需并发控制、外部挂载与内置资源只读。写冲突：乐观锁加 worktree 工作副本隔离，冲突推迟到合并点。语义冲突：编排层禁止有依赖的文件并行修改，写后跑全局一致性检查。污染：目录规范、命名约定与配额。单点故障：版本历史/快照可回滚，删除等高危操作需确认，权限最小化。
6. (★★★) 基于市场机制的 Agent 协作（Pinchwork、RentAHuman）引入了交易关系：一个 Agent 花钱雇佣另一个 Agent（或人类）完成任务。那么，雇主 Agent 如何自动衡量执行者交付的结果质量？如果执行者声称已完成但雇主认为质量不达标，争议由谁仲裁？如何防止劣币驱逐良币？
质量衡量套用"新信息"判据：验收不能只"再读一遍"，要用确定性外部验证——测试执行、渲染截图、工具核验；利用生成-验证难度不对称降低验收成本。契约层用 A2A：Agent Card 声明能力，任务状态机加 Artifact 交付，验收标准写进任务描述。争议由独立第三方审核 Agent 仲裁，配合资金托管。防劣币：基于历史交付的声誉体系，让价格信号与质量挂钩。
7. (★★) RentAHuman 让 Agent 通过加密货币雇佣人类，反转了传统的人机关系。如果这种模式普及，人类在 Agent 经济中扮演什么角色？仅仅是执行 Agent 无法完成的物理任务吗？
不止"肉身层"（签包裹、闻霉味）。人类还提供 Agent 生成时无法获得的新信息：现场感知与真实世界反馈；充当最终验收者与争议仲裁者；作为法律与责任主体承担授权、问责（Agent 无法担责）；设定目标与价值判断，在信息不对称和道德边界（如 Vending-Bench 中的价格合谋）处充当制衡。长期看人类从执行者转为 Agent 经济的委托方、监督方与信任锚点。
8. (★★) 人类社会需要多人分工协作，是因为每个人的能力有限——做前端的不一定懂后端，懂设计的不一定会运维。但大模型更像一个"全才"。相关研究表明，在纯文本推理任务上，多 Agent 辩论在等量计算资源下并不优于单 Agent。那么，使用多个 Agent 而非单个 Agent 的真正优势到底在哪里？提示：思考"新信息"这个关键词——什么样的协作步骤能引入生成阶段不存在的新信息？
核心判据：协作是否引入生成时不存在的新信息。辩论只是重看同一段文本，受数据处理不等式约束，串行传递只会丢信息，故无增益。有效的协作引入外部反馈：执行结果（RLEF）、视觉截图（WebGen-Agent 26.4%→51.9%）、工具验证（CRITIC）。另有工程价值：上下文隔离突破窗口限制、真正并行、信息隔离；多次独立采样聚合与生成-验证不对称也不受该定理限制。
9. (★★★) 本章将"共享上下文"与"不共享上下文"作为多 Agent 系统的核心设计维度。共享上下文让所有 Agent 看到相同信息，似乎更利于协调。但《三体》中的三体人思维完全透明，技术发展却陷入停滞；回形针思想实验也表明，当群体趋向同一目标时，多样性随之丧失。在多 Agent 系统中，如何在效率与多样性之间找到平衡？
完全共享会放大思维惯性与错误级联——错误因"一致性"获得更高可信度；隔离才有认知多样性。手段：用不同提示词/模型制造思维偏好（brainstorm、debate）；交叉验证者不看前序思考过程只看原始证据。并记住：多样性须配合外部反馈引入新信息，否则只是浪费计算。
10. (★★★) 给一个 Coding Agent 分配 30 步预算和 300 步预算，它的工作策略应该如何不同？研究表明，单纯增加步骤预算并不能保证性能提升——Agent 会在浅层搜索后过早"饱和"。设计一种"预算感知"机制，让 Agent 在小预算下快速实现核心功能，在大预算下增加规划、测试和审查环节，充分利用额外的计算资源。
机制：每步向提示词注入总预算与剩余预算，按剩余比例动态调整探索/利用权重（BAVT 思路）——前期广撒网，后期深挖掘。小预算（30 步）：跳过规划审查，直奔核心功能加基本验证。大预算（300 步）：走实验 10-1 式多阶段——先规划、再实现、再测试、再审查改进，按里程碑设检查点评估进展，防止浅层饱和。管理者模式下由 Manager 按子任务复杂度分配预算并引导用法。
11. (★★) 本章将“过早终止”分为偷懒式假完成、过早放弃、假成功三类。为什么三类问题的解法殊途同归，都指向验证？一个验证器要同时兜住这三类问题，需要满足哪些条件？
共同根源：任务是否结束由模型的自我宣称决定，而宣称不携带新信息——验证之前，“完成”只是宣称，不是证明。验证器的条件：①扎根真实观测而非模型自评（跑测试、渲染截图、查退款是否实际到账），否则循环空转（第二章：交互注入模型想不出的新信息）；②对照显式的完成定义逐项核查，兜住偷懒式假完成（测试跑了吗）与假成功（用户侧动作闭环了吗）；③对失败结论同样要验证——宣布“办不了”前核查是否穷尽备选途径（换渠道重试），兜住过早放弃；④配显式终止条件（轮数/预算上限），防止从过早终止滑向另一个极端——循环失控。