Agent 设计模式与人在回路

• ReAct 循环结构：Thought-Action-Observation 三要素
• 循环终止条件与工具结果回填
• 无效反复的证据：重复动作、无进展、振荡

ReAct 循环的实现：模型每次迭代输出 Thought（对当前情况的推理）、Action（选择工具与参数，或直接给出 Final Answer），系统执行 Action 得到 Observation（工具结果），把 Observation 追加到上下文后进入下一轮迭代，直到模型输出 Final Answer 或触发终止条件。实现要点：工具调用用结构化格式（function calling 或 JSON），结果截断后回填（长结果摘要化），上下文只保留最近 N 轮防止膨胀；循环必须配最大迭代数与停滞检测，不能依赖模型自觉停止。

无效反复的证据：一是重复动作——同一工具、同一参数被反复调用，结果相同（如反复查询同一订单却不下结论）；二是无进展——多轮后状态变量、产物、累计信息都没有实质变化，Thought 内容高度雷同；三是振荡——在两个动作之间来回切换（查询→重试→再查询），或不断要求澄清但用户已给全信息；四是循环越转越偏——动作序列与最初目标逐渐脱节。检测方法：记录动作指纹（工具+参数哈希），连续相同或周期性重复即告警；发现无效反复后应中断循环、注入"回顾目标"提示或回退到人工，而不是放任模型继续空转。

本题考察 ReAct 模式的实现与故障识别。回答要讲清三要素循环结构与终止条件，再用四类证据（重复、无进展、振荡、偏离）说明如何识别无效反复。能提到动作指纹检测是工程细节加分项。

• 两阶段结构：规划器生成计划，执行器逐步执行
• 计划-执行校验循环与重新规划触发
• 已完成状态的保留与副作用去重

Plan-and-Execute 将规划与执行分离为两个角色：规划器（Planner）在任务开始时（或重新规划时）一次性生成结构化计划——目标、步骤列表、每步的输入输出与依赖；执行器（Executor）按计划逐步执行，每步结果写回共享状态；两者之间还有校验环节——每步完成后检查结果与计划预期是否一致，环境是否发生变化。分离的好处：规划开销只发生一次或几次（而非每步都规划），执行步骤可并行，计划的稳定性让执行可预测、可审计。

计划变化时的重新规划：当校验发现步骤失败、上下文变化（数据库被修改、权限变更、用户改需求）或步骤间出现新依赖时，触发 replan——重新调用规划器，输入是"原计划 + 已完成步骤及结果 + 变化原因"，输出新计划。关键是不丢失已完成状态：已完成步骤的结果、副作用登记、产物引用全部保留在新计划的"已完成集合"中，重新规划只生成"剩余步骤"，执行器跳过已完成步骤直接续跑；若新计划依赖已完成的某个步骤，直接引用其结果而非重做。副作用去重由幂等键兜底，确保即使个别步骤被重新纳入计划也不会重复生效。

本题考察 Plan-and-Execute 的动态性设计。回答要讲清规划器/执行器/校验三角色的分离结构，再给出"原计划+已完成集合+变化原因"驱动的重规划机制。核心是重规划不重跑，已完成状态被显式继承。

• Reflexion 机制：失败后生成反思，反思注入后续尝试
• 反思记忆的写入时机与内容结构
• 反思的校验、淘汰与污染防护

Reflexion 的写入时机：任务失败（或某步结果与预期严重不符）后，模型对"为什么失败"生成结构化反思——失败原因（信息不足/工具用错/推理错误/环境变化）、应该采取的正确做法、应避免的陷阱；反思以文本或结构化记录写入"反思记忆"，在下一次尝试（或同类任务）时作为上下文注入，让模型带着教训重来。写入要求：反思要具体可执行（"下次先查订单状态再退款"优于"我粗心了"），绑定任务类型与失败上下文，便于检索复用。

避免污染的关键是"反思也要被校验与淘汰"：反思本身可能是错的——模型归因错误会把错误经验固化。防护措施：对高影响反思做外部校验（与规则、日志对账，或人工抽查）；给反思打置信度与验证状态（未验证/已验证/已证伪），未验证反思只作参考、权重低；反思记忆设容量与淘汰策略——按时间、使用频率与"验证效果"淘汰（被后续成功验证的反思保留并升级，被证伪的删除）；同类型反思去重合并，避免互相矛盾的经验并存。注入时限制反思条数与相关性，只注入与当前任务类型匹配且验证过的高质量反思，防止错误反思污染新任务。

本题考察反思机制的可靠性。回答要讲清反思的写入时机与结构，再重点展开"反思也需要校验、验证、淘汰"的防污染设计。核心观点：反思记忆是带状态的资产，不是照单全收的文本。

• 三类暂停点的语义：规划后确认、执行前审批、执行后复核
• 暂停点的成本与收益权衡
• 按风险与可逆性选择暂停点位置

三类暂停点各有适用场景：规划后暂停（Plan Approval）——Agent 生成完整计划后先给用户确认再执行，适合任务步骤多、执行成本高或计划本身有业务含义的场景（如深度研究大纲、退款方案），此时拦截成本最低、可修正空间最大，但会增加一轮交互延迟；执行前暂停（Pre-Action Approval）——针对单个高影响动作（写操作、付款、删除、外发消息），动作参数确定后、副作用发生前审批，是最常用的安全闸门，适合不可逆或高风险的副作用；执行后暂停（Post-Action Review）——动作已执行但结果未对外发布前复核（如草稿生成后人工润色再发送），适合"执行本身低风险、对外发布高风险"的场景。

选择依据是风险与可逆性：不可逆且高影响→执行前审批（必要时前置到规划审批）；可逆且低影响→不暂停，靠事后审计；执行后复核用于"需要人工把关内容质量"的场景。设计原则：暂停点要少而准——每个暂停点都有明确的审批内容、审批人与超时策略，避免"处处暂停"把 HITL 变成负体验；暂停点位置应能被用户看到和解释（"这一步需要你确认，因为涉及付款"）。三个位置可组合：规划后确认方案、执行前审批关键动作、执行后复核对外输出。

本题考察 HITL 暂停点设计。回答要讲清三类暂停点的位置、语义与适用场景，并按风险可逆性给出选择依据。核心原则是"暂停点少而准、每个都可解释"，避免过度审批。

• owner 机制的职责：授权范围、审批、责任归属
• 独立 owner 与统一审批的取舍
• 多级审批与审计链设计

原则上每个"有写权限或有自主决策权"的 Agent 都应有明确 owner——owner 是该 Agent 的行为责任人：负责定义其权限边界（能做什么、不能做什么）、审批其关键动作、为其失败与越权承担后果。独立 owner 的价值：职责清晰、审批粒度贴合业务（财务 Agent 的 owner 是财务主管、销售 Agent 的 owner 是销售负责人）、出现问题时能快速找到责任人与追溯链。只读或低风险 Agent 可以共享 owner，不必一人一 Agent，但每个 Agent 都必须有一个可指认的 owner。

实现上：owner 通过审批配置绑定——Agent 定义中声明审批策略（哪些动作需要 owner 审批、审批人角色、超时升级路径）；审批与执行强关联（审批记录含审批人、时间、授权范围）；多 Agent 协作时审批可以分级——低风险动作由子 Agent 的 owner 审批，高风险动作升级到协调者或更高层 owner；当子 Agent 的写操作由上级 Agent 触发时，也要明确责任链（谁发起、谁批准、谁执行），避免"下级 Agent 的越权无人负责"。owner 不只是在事故时背锅，更要在日常定义并维护 Agent 的权限边界与行为规范。

本题考察多 Agent 系统的治理结构。回答要明确"每个有决策权的 Agent 都应有 owner"的原则，讲清 owner 的职责（权限定义、审批、责任），并设计分级审批与责任链。核心是治理可追溯、责任可指认。

• 上下文变化检测：环境快照、前置校验、结果异常
• 重新规划的触发时机与条件
• 变化处理的差异化：重规划 vs 修正单步

检测上下文变化有三条路径：主动探测——执行关键步骤前，对计划依赖的外部条件做校验（如查订单状态字段、权限校验接口、版本号比对），发现与计划前提不符即标记计划失效；被动发现——步骤执行结果与预期异常（查到的数据为空、接口返回权限错误、外呼被拒），异常信息本身就是变化信号；定时重检——长任务定期对计划依赖的"关键事实"重查一遍（如每 N 分钟校验一次数据库快照指纹），捕捉执行过程中静默发生的变化。检测到变化后先评估影响面：只影响某个单步（如数据值变化）→修正该步参数继续执行；影响后续多步或目标本身（权限变更、需求变化）→触发重新规划。

重新规划的触发要避免两个极端：过度敏感（任何微小变化都重规划，造成抖动与成本浪费）与迟钝（环境大变仍按旧计划执行）。实践做法是"变化分级"——把检测到的变化按"对计划的影响"分级：无影响（继续）、单步修正（局部重算）、计划重排（重新规划剩余步骤）、目标重议（上报用户重新定义目标）。重新规划时继承已完成状态与副作用登记，只重生成受影响的部分。

本题考察计划失效的检测与响应。回答要给出主动探测、被动发现、定时重检三条检测路径，以及"分级响应"（继续/修正/重排/重议）的机制。核心是变化检测与影响分级联动，避免抖动或迟钝。

• ToT 的成本结构：多分支生成 + 评估投票
• 值得使用的判据：问题可分解、单步可评估、高价值
• 分支爆炸控制：宽度/深度限制、剪枝、束搜索

ToT 的额外成本来自三处：每个节点生成多个候选分支（生成成本倍增）、每层对候选做评估投票（评估也要调用模型）、以及多轮搜索（深度累积）。值得使用的判据：问题可分解为若干可独立评估的中间步骤（如数学解题的每一步、代码生成的中间方案）；单步质量可评估（能写出评估标准或让模型打分）；问题本身高价值且容错低（一次失败代价大）——如数学证明、复杂规划、代码生成；反之，简单问答、单步任务、低价值任务用 ToT 是纯浪费。

控制分支爆炸的手段：限制宽度（每层候选数，如 3-5 个）与深度（最大搜索深度）；剪枝——按评估分数保留 Top-K，其余分支直接丢弃；束搜索（Beam Search）——每层只保留得分最高的 K 个路径继续扩展；预算约束——总模型调用数上限，达到上限取当前最优；评估校准——评估模型与生成模型分工，评估 prompt 稳定，避免投票噪声。实践上 ToT 常被"单分支 + 反思重试"替代以降低成本，只有问题确实需要多路径探索时才启用完整 ToT。

本题考察 ToT 的成本收益分析。回答要拆解成本结构、给出启用判据（可分解、可评估、高价值），并系统给出宽度深度限制、剪枝与束搜索等分支控制手段。核心是"ToT 是重武器，只在高价值可评估问题上启用"。

• 审批信息的四要素：动作、参数、影响、回滚
• 审批界面的可决策性设计
• 审批后的恢复执行与幂等保护

审批信息四要素：动作——Agent 准备做什么（"向客户 A 发起退款 ¥500"），用业务语言描述而非工具名；参数——完整参数（金额、对象、渠道、时间），关键参数高亮并可展开原始数据；影响——执行后的预期后果（资金流出、库存变化、通知触达对象）与影响范围（涉及多少订单/用户）；回滚方式——如果审批后发现问题如何撤销（支持自动撤销/需人工介入/不可回滚），不可回滚的动作要显著警示。四要素齐备才能让审批人做"知情决策"，否则审批退化为无法审查的"同意全部"。

审批后的可靠恢复：审批动作本身要记录为事件（谁、何时、同意/拒绝、授权范围）；同意后，执行引擎从暂停点恢复——从 checkpoint 载入该动作的原始参数，重新校验参数与当前状态是否仍有效（审批期间数据可能变化，如库存已变），校验通过再执行真实副作用；执行必须带幂等键（审批单 ID），防止审批被重复提交或执行重放导致双重副作用；拒绝则记录原因、终止该分支或返回 Agent 重新规划。整个"暂停-审批-恢复"闭环要有审计链路：审批意见、恢复后的执行结果、以及审批与执行的对应关系都可查询。

本题考察 HITL 的信息设计与恢复可靠性。回答要给出四要素信息结构，再讲审批后"参数重校验 + 幂等执行 + 审计闭环"的恢复机制。核心是让审批可决策、让恢复无重复。

• 问题规模与搜索收益的关系
• 小问题上搜索的负收益：成本与延迟
• 规模判据：步骤数、候选空间、评估成本

ToT 的搜索与投票应在"中等以上复杂度、可分解、单步可评估"的问题上启动：问题包含多个可独立评估的中间步骤（通常 3 步以上）、每步候选空间有意义（存在多个合理选择）、单步评估能有效区分好坏（否则投票是噪声）。此时搜索的价值是避免"一条路走到黑"——单分支思维链一旦早期选错就全错，ToT 通过多路径+评估纠正早期错误。规模判据可以是：预估步骤数、每步候选多样性、单步错误代价——三者都高才值得 ToT。

小问题用搜索确实降低效率：简单问题（1-2 步、单步答案确定）单分支思维链正确率已足够高，ToT 的额外成本（分支生成 × 评估投票 × 多轮）纯属浪费——同样的预算能解决更多任务；而且小问题上评估模型难以区分候选优劣，投票近似随机，多路径不会带来质量增益，只增加延迟与成本。工程结论：按任务复杂度路由——简单任务用直接推理，中等任务用单分支+反思重试，复杂任务才启用 ToT；并把 ToT 深度、宽度、是否启用做成可配置参数，用离线评测找到"收益拐点"再上线。

本题考察 ToT 的启用规模判据。回答要先说明中等以上复杂度才值得，再分析小问题的负收益（评估无区分度、成本纯浪费），最后给出复杂度路由与收益拐点评测的实践。核心是"搜索的边际收益随问题规模递减"。

• 辩论有效的任务特征：答案可论证、有客观判据
• 轮次、裁判、终止条件设计
• 共识错误的成因与成本控制

Multi-Agent Debate 有效的任务特征：答案"可论证"且存在可检验的判据——事实核查（对错可验证）、数学推理（结果可验算）、代码审查（可运行测试）、决策评审（可列出正反论据）；这类任务上多 Agent 的立场碰撞能暴露单 Agent 的盲点与幻觉。反之，纯主观偏好、缺乏客观判据的任务（如"这句话风格好不好"）辩论只是立场重复，容易形成虚假共识。辩论形式：多个 Agent 独立给出立场与论据，然后互相质询、修正或辩护，最后由裁判综合。

设计要点：轮次控制——通常 2-3 轮，第一轮独立立场、第二轮交叉质询、第三轮收敛；轮次过多边际收益递减且成本翻倍。裁判设计——裁判 Agent（或规则）接收辩论记录，按预定义标准（事实正确性、论据充分性、与证据一致性）裁决，裁判要能看到证据源而非只信辩论内容；终止条件——达到约定轮次、各方论据收敛（立场变化小于阈值）、或任一方案被事实证伪即提前终止。避免共识错误：防止"从众"——各 Agent 若共享相同上下文与提示，辩论会趋同，要保证初始立场独立生成；防止"虚假共识"——裁判以外部证据为准，而非辩论气势。成本控制：限制 Agent 数量（3 个足矣）、轮次上限、每轮 Token 预算，并设定"辩论价值路由"——只有单 Agent 低置信度时才启用辩论。

本题考察多 Agent 辩论的工程化。回答要给出有效任务判据（可论证、可检验）、轮次/裁判/终止三要素设计，以及从众与虚假共识的防护。核心是"辩论要有外部证据锚点，成本要设上限"。

• 反思出错的场景：归因错误、经验固化
• 反思的外部校验机制
• 反思可信度管理与闭环修正

反思本身可能出错：归因错误——模型把失败归因于"工具不好用"而实际是自身推理错误，错误归因会被固化进反思记忆，后续任务被错误经验带偏；过度自责——把环境随机因素归因于自身，导致无谓的自我修正；反思幻觉——反思中编造了实际未发生的原因或步骤。这些失败案例不处理，反思机制就从"改进器"变成"污染源"。

处理方式是引入外部校验，分三个层次：规则校验——反思中涉及的事实（"第 2 步调用了 X"）与执行日志对账，事实性错误直接纠正；结果校验——反思沉淀的经验在下一次任务中若被采纳，检验其是否带来改进，未被验证或导致失败的经验降权；人工抽查——对高风险任务的反思按比例人工审核，审核结论回流。可信度管理：反思记录带状态（未验证/已验证/已证伪）与来源，注入上下文时按可信度加权，证伪的反思自动淘汰并标记原因。闭环上，反思的采纳与效果要可追踪——每条经验记录"采纳次数、成功次数"，用数据决定保留还是删除，而不是靠模型自我感觉。

本题考察反思机制的自我纠错能力。回答要列举反思出错的类型，给出规则对账、结果验证、人工抽查三层外部校验，以及可信度管理闭环。核心观点：反思是待验证假设，不是既成事实。

• 两种模式的语义：横向互审 vs 纵向分工
• 任务特征匹配：质量敏感 vs 效率敏感
• 风险与成本评估维度

协作模式（互相 review）适合质量敏感、错误代价高的任务——代码审查、方案评审、事实核查、文案质检：多个 Agent 从不同视角审查同一产出，能发现单 Agent 盲点，但 Token 消耗按"产出数 × 审查轮次"增长，延迟也随轮次叠加，且可能形成"互相附和"的假审查（提示词趋同导致 review 无区分度）。分工模式（独立子任务）适合可分解、接口清晰的任务——数据清洗、分块总结、批量检索：每个 Agent 只做一块，成本近似线性、可并行缩短延迟，但接口处的错误（上游产出不合下游预期）需要额外的契约校验兜底，且无法发现"整件事方向错了"的问题——各自局部正确、整体失败。

选型逻辑：先问"错误的分布在哪"——错误主要来自"单点能力不足"（漏检、偏见）→ 协作审查；错误来自"接口与组合"（拼装、传递）→ 分工 + 强契约。再评估成本：协作模式成本随审查轮次与 Agent 数线性增长，要设审查轮次上限与"分歧时才加轮"的策略；分工模式成本主要在接口适配与结果合并，要评估契约设计与合并不良的返工率。实践中常用混合：分工完成子任务，对关键产出（对外发布、代码合入）做一次协作审查。

本题考察多 Agent 模式选型。回答要讲清两种模式的语义与适配任务，重点给出风险（假审查 vs 接口失败）与成本（轮次 vs 返工）的评估维度。核心是"按错误分布选模式，按轮次与返工控成本"。

• 多 Agent 优于单 Agent 的判据：上下文隔离、并发、角色专业化
• 角色对话空转的表现与成因
• 防空转机制：目标约束、轮次限制、产出导向

多 Agent 协作优于"单 Agent + 多工具"的判据：上下文隔离需求——子任务需要互不干扰的独立上下文（如同时处理两个客户，或研发与法务的上下文不能混）；并发需求——子任务可并行且需要真实并行（单 Agent 只能串行切换工具）；角色专业化——不同子任务需要差异化的提示词、工具集与知识（审阅者角色、执行者角色），混在一个 Agent 里提示冲突；故障隔离——子 Agent 失败可独立重启。反之，任务线性、上下文共享无冲突、工具调用简单时，单 Agent 更省 Token 且避免编排开销。

角色对话空转的表现：Agent 之间互相客套（"感谢你的观点""同意你的看法"）、重复已说内容、围绕同一问题来回打转而不推进产出；成因是缺少产出目标与终止约束。防空转机制：目标约束——协作任务必须声明最终产出物（如"评审结论 + 修改清单"），每轮消息都要向产出靠近，偏离目标的发言被过滤；轮次与预算——限制对话轮数/Token 总量，超限强制收敛（由协调者总结产出）；角色分工明确——谁产出、谁评审、谁决策，消息带类型标签（事实/观点/决策），避免闲聊；产出导向的终止条件——任一 Agent 声明"产出完成"即进入验收，验收通过立即结束对话，而不是聊到自然停止。

本题考察多 Agent 协作的边界与收敛。回答要给出多 Agent 优于单 Agent 的三条判据，再讲清空转的成因与"产出导向 + 轮次预算 + 消息标签"的防空转设计。核心是"多 Agent 是为隔离与并发，不是为对话本身"。

• 验证的对象与粒度：每步验证 + 里程碑验证
• 验证的方式：规则校验、执行测试、模型自检、人工抽查
• 错误累积的拦截：发现即止损，不让错误进入下一步

防止错误累积的关键是"小步验证、及时止损"：验证粒度要小——每个计划步骤执行后立即验证（单步验证），而不是等所有步骤完成后再整体检查；因为错误在早期被拦截时修复成本低，累积到后期会传染给依赖它的所有后续步骤。验证点分级：单步验证（本步骤产出符合预期格式与约束）、里程碑验证（阶段性成果与整体目标一致，如研究中途检查"收集的资料能否支撑结论"）、最终验收（整体产出通过验收标准）。验证前置才能切断"错误-放大-再错误"的链条。

验证方式组合：规则校验（schema、值域、数量约束，零成本高确定性）；执行验证（能运行的产出直接跑——代码执行单测、SQL 跑通、API 冒烟，最客观）；模型自检（让模型对照目标检查产出，识别逻辑不一致）；人工抽查（高风险节点抽查）。设计要点：验证本身要"可证伪"——验证标准可执行（"包含必填字段且金额为正"好于"看起来合理"）；验证失败的处理要分层——小错就地修正（把验证错误回传给模型重做），结构性错误回退到上一步骤重新规划，验证通不过绝不进入下一步；同时记录验证日志，让"错误在哪一步产生、在哪一步被拦下"可追溯。

本题考察验证闭环设计。回答要强调"小步验证 + 前置拦截"防止累积，给出分级验证点与四类验证方式的组合，以及失败处理的分层策略。核心是"验证前置、错误就地拦截、通不过不流转"。

• 用户的四类控制能力：修改、拒绝、撤销、接管
• 控制能力的界面与交互设计
• 用户干预与 Agent 执行的衔接

四类控制能力的设计：修改——用户可直接编辑计划或步骤参数（改金额、换接收人、调整步骤顺序），Agent 按修改后的参数继续执行，修改要触发"变更校验"（修改是否合法、是否影响后续步骤）；拒绝——用户可拒绝单个步骤或整个计划，拒绝后 Agent 不得再次提交同类动作（除非用户主动改变主意），拒绝原因可回传给 Agent 作为学习信号；撤销——已完成但未对外发布的动作可撤销（如撤回草稿、取消待发送），已生效的副作用走补偿流程；接管——用户可随时"抢过键盘"：暂停 Agent、亲自完成某步骤，再把结果交回 Agent 继续。这些能力要在界面上显式可见（每个计划步骤都带"编辑/拒绝/撤销"入口），而不是藏在设置里。

实现衔接：用户干预动作作为"事件"写入执行状态（干预记录含对象、类型、时间、操作者），Agent 恢复执行前必须感知干预——修改后的参数重新校验、被拒绝的动作从计划中移除、接管后的结果作为已完成步骤登记；干预与 Agent 执行之间要有版本控制（Agent 在执行期间计划被用户修改时，要么中止当前步、要么在步边界应用修改），避免"用户改了 A，Agent 还在按旧 A 执行"。原则是用户拥有最终控制权，Agent 的自主性建立在"可随时被用户介入"之上。

本题考察用户对 Agent 的控制权设计。回答要给出四类能力的语义与界面呈现，再讲干预事件与执行状态的衔接机制。核心是"控制权可见、干预可感知、执行不冲突"。

• 工具数量与选择准确率的关系（选择熵）
• 工具描述质量与冲突管理
• 分层工具集与按需挂载

经验结论是"少而精"更好：工具选择本质是分类问题，工具越多、描述越相似，模型的区分难度越大，选择准确率下降——模型在 5 个清晰工具中选对的概率远高于 50 个相似工具；工具过多还会消耗上下文（每个工具的 schema 与描述都占 Token）、增加幻觉调用的可能性（模型"猜到"一个不存在的工具或误用参数）。但"少"不是绝对数量小，而是"与任务匹配的最小必要集"：把工具按任务/阶段分层，每个 Agent 只挂当前任务必需的少数工具。

提升选择准确率的手段：工具描述规范——动词开头 + 明确输入输出 + 副作用说明（"send_notification(user_id, content)：向用户发送站内信，会触发推送"）；工具间区分度——避免两个工具做重叠的事（有重叠就合并或明确边界）；按状态挂载——状态机中每个状态只暴露该状态的合法工具；冲突消解——模型选了不可用工具时返回"工具不可用原因"而非静默失败。工程实践：先按业务功能枚举工具，再按 Agent 职责裁剪，能合并的合并、能删的删，用离线评测比较不同工具集下的选择准确率，找到准确率与覆盖率的平衡点。

本题考察工具集设计。回答要论证"少而精"的机理（选择熵、上下文开销、幻觉风险），再给出分层挂载、描述规范与评测裁剪的实践。核心是"工具集是设计出来的最小必要集，不是堆出来的大全集"。

• 两种模式在工具选择上的决策结构差异
• 工具增多对每步选择准确率的影响
• 性能差距的放大机制

工具数量增多时，ReAct 的性能劣化比 Plan-and-Execute 更明显：ReAct 每一步都要在全部工具集中做一次选择（每步都面对完整工具列表），工具增多直接推高每步的选择熵，选择错误概率上升，而 ReAct 又是长链（一步错可能带偏后续），错误被链式放大——单步准确率 90% 的 10 步链整体成功率只有 35%；同时每步都要把全部工具 schema 塞进上下文，Token 开销与工具数线性增长。Plan-and-Execute 的决策结构不同：规划阶段先确定"每个步骤用什么工具/什么类别"，执行阶段按计划调用指定工具，大部分步骤不需要在全局工具集里重新选择，工具增多的影响集中在规划器一次性的选择压力上，执行步骤的选择空间被计划收窄了。

差距放大的机制：一是选择频率——ReAct 每步都全量选择，P&E 只在规划时选择；二是上下文重复——ReAct 每步重复携带全部工具定义，P&E 可把工具说明放在规划阶段，执行阶段只带必要工具；三是错误传播——ReAct 的选错直接进入执行链，P&E 的规划错误可在执行校验中被拦截并局部重规划。工程含义：工具规模大（几十个以上）时优先 P&E 或分层路由（先路由到工具类别，再在类别内选具体工具），把"大选择空间"拆成"小选择空间"；ReAct 适合工具少（个位数）、交互开放的场景。

本题考察工具规模对两种模式的影响。回答要从决策结构差异入手，分析选择熵、上下文开销与错误传播三方面的放大机制，得出"工具多时 P&E 或分层路由更优"的结论。核心是选择空间的压缩策略。

• 完整展示思考过程的风险：注入、误导、信息泄露
• 用户侧展示的原则：结论 + 依据 + 可解释摘要
• 审计日志的内容与访问控制

思考过程不应全部展示，因为它是"未经校验的内部推理"：可能包含错误的中间假设、被否定的候选方案、与最终结论矛盾的想法，原样展示会误导用户（用户看到模型"想错"的过程反而更困惑）；思考文本还可能泄露内部指令、工具细节、检索策略与评估 prompt 等敏感信息；且"可见的思考"会放大提示注入风险——用户如果能看到模型如何解读指令，就能针对性构造输入操纵推理。展示的原则是"结果导向 + 依据透明"：展示最终结论、关键依据（引用的数据、调用的工具）、决策要点与置信度，思考过程折叠成可选的"过程摘要"，语言用陈述而非内心独白。

保留完整日志供审计则是另一层需求：生产问题定位、合规审查、安全事件调查都需要还原"模型当时看到了什么、为什么这么做"。实现上：思考过程、完整上下文、工具调用原始记录、时间戳与版本号写入审计存储（只追加、不可篡改），按角色授权访问（工程师排障、合规审计、安全调查各自权限不同），敏感信息在日志中脱敏（密钥、个人信息打码），日志保留期按合规要求配置。展示与审计分离：用户界面只呈现加工过的解释，审计后端保留原始真相。

本题考察透明度与安全的边界。回答要先论证不完整展示的三类风险（误导、泄露、注入），再给出结果导向的展示原则与审计日志的完整留存，最后强调"展示与审计分离"。核心是"面向用户可解释，面向审计可还原"。

• 三层恢复机制：重试 / 重规划 / 人工
• 各层的触发条件与升级路径
• 恢复决策的信息依据

三层恢复由轻到重：第一层单步重试——触发条件是"瞬时、局部、可自我修正"的错误：工具调用超时与限流（重试可成功）、模型输出格式错误（带错误信息回传重试）、单步结果与校验标准不符但可修正（补充信息重新生成）。重试要限次数与退避（通常 2-3 次），不改变任务结构。第二层重新规划——触发条件是"结构性"的错误：连续重试仍失败、关键工具不可用（需换路径）、计划前提失效（数据变化、权限变更）、步骤依赖被打破（上游产出不合格导致后续步骤无法执行）；重规划修改的是"怎么做"，不改变"做什么"。第三层回退人工——触发条件是重规划也无法恢复的情况：目标本身不可达成、需要业务决策（无法判定对错的场景）、高风险操作反复失败、用户明确要求人工处理；回退人工要带上完整现场（失败历史、已尝试的方案、当前状态），让人能直接接手。

触发判定的依据是"错误类型 × 影响面 × 重试收益"：瞬时小错→重试；结构性影响→重规划；目标性问题→人工。升级路径要显式：重试 N 次失败→重规划，重规划 M 次失败→人工，防止在同一层无限打转；每层升级都要记录原因供审计，并让用户感知层级变化（"已自动重试 2 次，正在重新规划"）。

本题考察恢复分层设计。回答要给出三层的触发条件矩阵与升级路径，强调"错误类型 × 影响面 × 重试收益"的判定依据。核心是显式分层、有限升级、杜绝原地打转。

• 消息安全威胁：伪造、篡改、重放、越权读取
• 签名与加密的适用场景
• 身份认证与消息级安全设计

应该做消息级的安全防护，具体看消息的敏感度与系统边界：系统内部、同一可信进程内的 Agent 消息可依赖传输层安全（内网 TLS + 网络隔离），但跨进程、跨服务、跨组织（A2A 场景）的 Agent 消息必须签名与加密。威胁模型包括：伪造——攻击者冒充某 Agent 发送指令（如冒充审批 Agent 放行操作）；篡改——中间人修改消息参数（改金额、改接收人）；重放——截获合法消息重复发送（重复扣款）；窃听——敏感内容泄露。防护手段：签名——发送方用私钥对消息摘要签名，接收方验签，保证来源真实与内容完整（防伪造与篡改）；加密——敏感消息用接收方公钥或会话密钥加密（防窃听）；防重放——消息带时间戳 + 随机数 + 序号，接收方缓存校验。

工程实现：每个 Agent 有身份证书或密钥对，消息头带 Agent ID、签名与时间戳；跨系统用标准协议（如 JWT 签名、TLS mTLS、SigV4 风格签名）；审批、支付类消息强制验签后才执行。关键点：验签不能只在入口做——多 Agent 转发消息时，中间 Agent 转发要保留原始签名（签名目标包含原始内容），防止"入口验了、内部被改"；同时密钥管理要规范（轮换、吊销、权限最小化）。安全级别按消息类型分级：只读查询可仅验签，写操作与审批必须验签 + 防重放 + 审计。

本题考察多 Agent 消息安全设计。回答要给出四类威胁与对应防护（签名防伪造篡改、加密防窃听、序号防重放），并强调验签在转发链路中的保持与密钥管理。核心是"消息级安全随边界与敏感度分级"。

• 写操作暂停点的挂载位置与触发条件
• 审批恢复后的双重校验：原始参数 vs 当前状态
• 审批期间状态变化的处理

写操作暂停点设计：把"写类工具"统一封装在审批网关后面——Agent 调用写工具时，工具层不直接执行，而是生成"写操作提案"（动作类型、完整参数、目标对象、预期影响、来源 Agent 与上下文引用），进入审批队列并暂停该任务分支；只有审批通过后，审批网关才真正调用底层写工具。触发条件可分级：全部写操作都暂停（高安全环境）、按风险规则暂停（金额阈值、对象类型、权限等级）、按模型置信度暂停（低置信度的写操作强制审批）。

审批恢复后的双重校验是防"审批期间世界已变"的关键：原始参数校验——审批通过的参数与当前请求绑定（审批单 ID → 参数快照），执行时用快照参数而非"恢复时重新生成的参数"，防止 Agent 在等待期间自行改动了参数；当前状态校验——执行前重新读取目标对象的最新状态（订单还处于可退款状态吗、库存够吗、权限还有效吗），与审批时的状态比对，状态已变则拒绝执行并通知审批人"条件已变化，是否重新审批"。两个校验都通过才执行，执行带幂等键（审批单 ID），杜绝重复生效；审批-执行-结果三段全部落审计。

本题考察 HITL 写操作的安全设计。回答要讲清审批网关与提案机制，重点展开"参数快照绑定 + 当前状态重校验"的双重校验，以及幂等执行。核心是"审批通过不意味着永远有效，执行前世界可能已变"。

• 三种协作架构的拓扑与决策结构
• 任务分解方式与通信模式差异
• 各自的适用场景与边界

三种架构的本质差异在"决策如何组织、信息如何流动"：Supervisor 模式（主管-下属）——一个主管 Agent 负责理解任务、分解、分配与汇总，下属 Agent 各自执行并回报，决策集中、分工明确，适合任务可清晰分解为独立子任务且需要统一调度的场景（客服工单处理、内容生产流水线），边界是下属间不直接通信、一切经主管，主管成为瓶颈与单点。Hierarchical Teams（层级团队）——多级主管层层分解（如总监 Agent 管项目经理 Agent，经理再管执行 Agent），适合大型复杂任务（企业级项目、跨部门协作），优势是控制粒度可伸缩，代价是层级通信延迟与信息逐层衰减。

黑板式（Blackboard）——多个 Agent 共享一块"黑板"（共享状态空间），各自读写感兴趣的区域、按贡献协作，没有中央调度，适合解耦性强、专业异构、问题结构松散的场景（多源情报分析、综合规划），优势是灵活、无单点，代价是需要定义清晰的黑板协议（区域权限、冲突仲裁、收敛判定），否则 Agent 各写各的、难以收敛。选型要点：任务分工明确、依赖简单→Supervisor；规模大、需要分级治理→层级；问题异构、专业 Agent 群协同、难以预定义流程→黑板式；实际系统常混合（层级主管 + 局部黑板共享）。

本题考察多 Agent 拓扑选型。回答要对比三种架构的决策结构、信息流与适用任务，指出各自的单点/衰减/收敛问题。核心是"协作架构要与任务分解结构匹配"。

• 计划与执行结果不一致的场景
• 状态机对非法转移的拦截机制
• 拦截后的处理路径

不一致的场景：模型计划"下一步查 A"，但实际执行结果是 B 类型数据；模型声称某步已完成而状态机显示该步未执行；模型根据过期假设规划，执行结果证明前提已变。设计原则是"状态转移以事实为准"：状态机维护权威状态（哪些步骤完成、产生了什么结果），Agent 的每个"计划/声称"都必须映射为对状态机的一次合法转移申请——转移合法性由守卫条件（guard）校验：目标状态是否存在、前置条件是否满足（依赖步骤是否真完成）、携带的数据是否与执行记录一致（模型声称的完成标记要能对上工具执行日志）。

拦截机制：非法转移直接被状态机拒绝并返回拒绝原因（"无法从状态 B 转移到状态 D，因为前置 C 未完成"），拒绝信息回传给模型修正其计划；模型被引导回到"基于状态机事实说话"——它只能从状态机读取当前事实来规划下一步，不能凭空声明。拦截后处理路径：模型重新规划（按拒绝原因调整步骤）、或触发对账（模型声称与实际不一致时，以执行记录为准纠正模型认知）、或升级人工（反复产生非法转移说明模型与系统状态脱节）。同时状态机拒绝要可观测——记录每次拒绝的原因与次数，作为模型漂移的告警信号。

本题考察状态机对 Agent 的约束。回答要讲清"状态机是权威事实、模型是提议者"的原则，给出守卫条件校验与拒绝回传机制。核心是"模型不能凭计划改写事实，转移必须对得上执行记录"。

• 资源消耗控制：Token 预算、时间预算、成本上限
• 并发控制：子 Agent 数量与并发上限
• 权限控制：工具白名单与授权边界

资源消耗控制的三类预算：Token 预算——每个子 Agent 设独立的 Token 上限（总消耗与单次调用），超限强制终止并返回部分结果；成本预算——按子任务设定货币成本上限（模型单价 × Token + 外部 API 费用），财务上与任务级成本归集联动；时间预算——子 Agent 的最大墙钟时间，超时按"超时策略"处理（终止或降级）。预算要继承与分摊——父任务的总预算分配到子任务，子 Agent 用完自己的份额不能透支父任务的，防止某个子 Agent 烧穿全局预算。

并发与权限控制：并发上限——限制同时运行的子 Agent 数量（全局并发池 + 每任务上限），防止子 Agent 互相争抢资源或对下游系统造成突发压力，超出的任务排队；工具白名单——每个子 Agent 声明式地获得工具集（最小权限），白名单由创建者或治理层审批，子 Agent 只能调用白名单内的工具，无权访问其他工具与数据；权限扩散防护——子 Agent 再创建孙 Agent 时权限只能收缩不能扩张（子集传递），且继承审批约束（父级需要审批的操作，子级同样需要）。监控上按子 Agent 维度展示预算消耗与权限使用，异常（预算突增、越权尝试）告警。

本题考察子 Agent 的资源与权限治理。回答要覆盖三类预算（Token/成本/时间）与分摊机制、并发上限，以及工具白名单与权限收缩传递。核心是"子 Agent 的消耗与权限都受父级约束，不能自我膨胀"。

• 审批信息三要素：证据、参数、副作用
• 可审查性的设计：可追溯、可展开、可验证
• 避免"同意全部"式假确认

审批界面要展示三要素且可验证：证据——Agent 得出该动作的依据（检索到的数据、对话上下文引用、规则命中说明），证据要能点击溯源（跳转到原始文档、原始消息）；参数——动作的完整参数（对象、金额、时间、接收方等）用结构化方式展示，关键参数（金额、数量）高亮并做格式校验提示（如"金额 ¥5000 超出常规范围"）；预期副作用——执行后会真实发生什么（资金流出、数据修改、通知触达、外部系统变更），以及影响范围（影响多少用户/订单）、可逆性（能否撤销、如何撤销）。三者齐备，审批人才能判断"这个动作该不该做"。

避免"同意全部"的设计：信息分层——默认展示摘要（动作+关键参数+副作用一句话），可展开查看完整证据链与原始参数，但不允许"只看到摘要就点同意"的高风险动作；引导检查——高风险动作强制展示"请确认：金额、接收方、影响范围"三项核对清单；留痕——审批界面截图级审计（审批人看到什么就记录什么），事后可复现"审批人当时看到的信息"，防止"审批人以为同意 A，实际执行了 B"；预演——展示执行前状态与执行后预期状态对比，让审批人"看到未来"再决定。原则是让审批人做"看得懂、查得到、想清楚"的知情确认。

本题考察审批界面的可审查性。回答要给出证据、参数、副作用三要素及溯源能力，再讲信息分层、核对清单与"所见即所批"的留痕设计。核心是"审批不是点头，而是基于完整信息的决策"。

• 共享上下文中三类信息的隔离需求：草稿 / 事实 / 机密
• 分区隔离与访问控制设计
• 协作传递时的权限边界

共享上下文要按信息类型分区隔离：临时草稿（Agent 正在生成的中间内容）——只在所属 Agent 的私有区，其他 Agent 不可见，需要共享时显式发布；可信事实（用户确认过的事实、系统权威数据）——放在公共事实区，带来源与版本，所有 Agent 可读但只有授权者可写，防止某个 Agent 的推测污染公共事实；用户机密（个人信息、密钥、敏感业务数据）——独立加密区，只有按需获得授权的 Agent 可读，且读取要记录审计（谁在什么时候读了什么）。分区的实现：上下文按"区"组织（私有区/公共区/机密区），Agent 的 prompt 与工具权限绑定区域可见性，模型只能看到自己被授权注入的区。

避免越权的协作机制：传递最小化——Agent 间传递信息时只传任务需要的字段，不整段转发上下文（用结构化消息带字段级权限）；机密降级——需要把机密用于协作时，先脱敏或摘要化（"客户 A"而非全名+联系方式）再进公共区；写权限控制——公共事实区更新需校验来源可信度（来自工具结果>来自模型断言），机密区写入需授权；越权检测——记录每个 Agent 读取的区域与字段，异常访问（与任务无关的机密读取）告警。设计原则：默认不共享，按需授权，最小化传递，全程审计。

本题考察多 Agent 共享上下文的安全隔离。回答要给出草稿/事实/机密三区的隔离设计与读写权限，以及最小化传递、脱敏与越权检测机制。核心是"共享不等于全量可见，权限按需授予"。

• 审批点的位置选择：工具调用前、写操作前、对外输出前
• 各环节的审批粒度与风险差异
• 审批点设置的实践原则

审批点的设置按"副作用发生的位置"分层：工具调用审批——在 Agent 发起工具调用前拦截，适合"工具调用本身有风险"的场景（调用外部付费 API、启动批处理、触发外部系统操作）；写操作审批——在数据写入/修改前拦截（创建、更新、删除、转账、发消息），是最核心的安全闸门，适合不可逆或影响面大的写动作；对外输出审批——在内容对外发布前拦截（发邮件、发公告、提交工单、发布到外部渠道），适合"执行动作本身低风险但对外影响不可控"的场景（内容质量、合规风险）。三者对应"调用-写入-发布"三个副作用关口。

设置原则：审批点放在"副作用将要发生的那一刻"之前，而不是放在"模型输出之后、执行之前"的笼统位置——审批对象必须是确定的动作与参数，而不是抽象意图；按风险分级配置——高风险动作（删除、付款、对外发布）强制审批，中风险（更新数据）按阈值触发，低风险（查询、草稿）不审批；审批点要与取消点、补偿机制配套——审批拒绝后的终止、审批通过后的幂等执行都要在同一套机制里。实践上"写操作审批"是必选项，"工具调用审批"用在外部副作用工具上，"对外输出审批"用在发布类动作上，三者可叠加（发布动作同时经过写操作与对外输出两道审批）。

本题考察 HITL 审批点的布点。回答要讲清三个环节的审批对象与适用场景，给出"审批点贴近副作用发生时刻 + 风险分级配置"的原则。核心是审批点要精确卡在副作用关口，而非笼统拦截。

• 中断类型：崩溃、超时、用户暂停、系统维护
• 恢复时的上下文重建与续接
• 续接的内容完整性：目标、已完成步骤、未完成步骤

多步任务中断恢复的核心是"恢复信息足够重建现场"：恢复信息包含四部分——任务目标（原始目标与当前目标，防止恢复后模型跑偏）、已完成步骤及结果（步骤 ID、产出、副作用登记，恢复时跳过）、未完成步骤（剩余计划与顺序，从断点继续）、上下文（对话历史、关键状态变量、检索内容，重建模型"记忆"）。这些信息在每次节点完成后持久化（checkpoint），恢复时加载最近检查点，按"目标-进度-剩余"三层重建上下文，模型重新"意识到"自己进行到哪了。

实现要点：上下文重建要防"续接漂移"——恢复时把"已完成摘要"注入上下文（让模型知道前面做了什么），而不是只给剩余步骤（否则模型不知道前置结果）；对已完成的副作用做对账，防止恢复后重复执行；恢复触发方式区分：崩溃自动恢复（加载 checkpoint 直接续跑）、用户暂停后恢复（用户确认后从暂停点继续，暂停期间的上下文变化要处理）、超时中断恢复（按剩余步骤继续或重规划）；恢复后做一次"当前状态 vs 计划前提"的校验，环境已变则重规划再续接。长任务的上下文本身可能超限，续接时用"摘要 + 关键事实"压缩旧上下文，保证模型聚焦未完成部分。

本题考察多步任务的续接实现。回答要给出恢复信息四要素（目标、已完成、未完成、上下文）与 checkpoint 机制，再讲续接防漂移、对账与压缩。核心是"续接不是重跑也不是盲目继续，而是带着完整现场从断点前进"。

• Computer Use Agent 的风险动作分类：删除、付款、提交、登录
• 强制审批与禁止自动化的判定
• 高风险动作的默认安全策略

Computer Use Agent（操作 GUI 的 Agent）的风险动作按"不可逆性 × 影响面"分级：删除类——文件删除、记录删除、回收站清空等一律禁止自动化（默认只允许移入回收站/软删除，硬删除必须人工确认）；付款类——支付、转账、下单付款完全禁止自动化（即使金额小，也应设计为"Agent 填写但支付动作由人工在受控环境完成"）；提交类——提交表单、发布内容、提交工单需审批（先展示将提交的完整内容与目标，人工确认后提交）；登录类——输入密码、修改凭据禁止自动化（凭据输入由人工或专用凭据库完成，Agent 不接触明文密码）；此外还包括发送消息、修改设置、批量操作等，按影响面设审批阈值。

设计原则是"默认拒绝、白名单放行"：Agent 的操作能力以白名单形式授予（哪些应用、哪些操作可自动执行），不在白名单的高风险动作直接禁止；高风险动作即使白名单内也需人工审批（审批点强制卡在动作执行前）；对"看似安全但组合起来危险"的操作要警惕——多个低风险动作的组合（如删除多个文件、批量发送）也可能造成大影响，需要聚合审批；所有动作记录（截图、坐标、参数、结果）留痕，支持事后回溯。这是安全底线问题：宁可让 Agent 少做，不可让它乱做。

本题考察 Computer Use Agent 的安全策略。回答要按动作类型给出分级策略（删除禁止、付款禁止、提交审批、登录禁止），并强调"默认拒绝、白名单放行"与动作留痕。核心是高风险操作的安全底线不因自动化而放宽。

• 绝对禁止与沙箱执行的权衡
• 沙箱的技术实现与边界
• 分层防护策略

正确的做法是"分层防护"而非简单的二选一：对生产环境与用户数据，删除操作绝对禁止自动化（Agent 只能移到回收站/软删除/标记删除）；对隔离的沙箱环境（测试目录、临时工作区、专用容器），允许删除但受强约束。理由：删除的不可逆性决定了对真实数据必须零风险；但沙箱内的删除是任务能力的一部分（清理临时文件、重置测试环境），完全禁止会降低 Agent 的实用性，也影响测试效率。分层策略让"风险随环境隔离度递减"。

沙箱的实现要点：环境隔离——Agent 只在一个受控工作区（容器、虚拟机、专用目录树）内有权限，路径校验严格（禁止越出工作区，符号链接、绝对路径、父目录访问都要拦截）；操作审计——每次删除记录完整上下文（文件路径、大小、发起任务、时间戳），支持恢复（删除前快照/回收站机制）；策略引擎——在文件系统层挂删除拦截钩子，按"路径白名单 × 操作类型 × 任务授权"判定，不满足直接拒绝；双确认——沙箱内删除也可配置人工确认。生产与沙箱的边界由权限体系保证：Agent 的凭据只对沙箱有写权限，即使提示词被注入也无法删除生产文件。最终原则：真实数据绝对禁止，沙箱数据强约束执行。

本题考察删除操作的安全分层。回答要给出"生产绝对禁止 + 沙箱强约束允许"的分层结论，并讲清沙箱的路径隔离、审计与策略引擎实现。核心是"风险随环境隔离度递减，权限边界靠凭据而非提示词"。

• LangGraph checkpoint 的机制：每节点保存完整状态
• 恢复流程：加载 checkpoint 从断点继续
• 节点重放的副作用防护：幂等 + 副作用登记

LangGraph 的 checkpoint 机制：每次节点执行结束后，框架把完整图状态（所有节点共享的 State 对象、节点输出、通道内容）序列化保存到 CheckpointSaver（内存、SQLite、Postgres、Redis 等后端），形成状态历史；恢复时通过 get_state/update_state 加载指定 checkpoint，用"中断/恢复"（interrupt/resume）机制从断点继续——例如 HITL 中断后，用户批准时从该节点恢复执行，而不用重跑整图。checkpoint 按"线程 ID（thread_id）"隔离任务，长任务可用一个线程持续运行并跨进程恢复。

节点重放触发外部副作用的处理：LangGraph 提供了显式控制重放的手段——interrupt() 在节点内中断并保存状态，恢复时不重放已执行部分；重试（update_state + 重新执行）时若节点有外部副作用，需要业务侧配合：工具调用带幂等键（框架不自动去重，业务要自行实现"先查后写"或"执行登记"），副作用节点将"调用记录"写入图状态（执行前登记意图、执行后登记结果），重放时先检查登记表，已生效的直接复用结果、跳过执行。实践中结合 LangGraph 的 store 与自定义副作用表（写 Redis/DB）实现幂等，关键副作用用外部事务（数据库行锁、消息幂等）兜底，保证"图可以重放，副作用只发生一次"。

本题考察 LangGraph 的持久化与副作用防护。回答要讲清 checkpoint 的保存内容、恢复与中断机制，再说明框架重放与业务幂等的关系（框架管状态重放、业务管副作用去重）。核心是"框架的重放能力要与业务幂等键配合使用"。

• 漂移的度量：目标相关性、产出对账、行为偏离
• 漂移检测的机制：定期校验、轨迹分析
• 护栏设计：约束、告警、回正

漂移的度量三方面：目标相关性——当前步骤/产出的主题与原始目标的重合度（可用模型打分或关键词/意图比对，如"任务是要分析 A 客户，当前在查 B 客户的资料"）；产出对账——已完成步骤的产出是否都服务于最终目标，产出与目标无关的步骤占比即漂移度；行为偏离——动作序列是否超出任务范围（调用无关工具、读取无关数据、目标收敛后仍继续）。量化指标如"漂移率 = 无关步骤数 / 总步骤数"，配合每步的"目标相关性评分"形成趋势曲线，评分持续下降即漂移预警。

护栏设计分三层：预防——任务开始时明确"目标 + 范围 + 边界"（哪些话题/工具/数据可触及），写入系统提示与状态约束，Agent 触碰边界即被工具层拦截（非模型自觉）；检测——每 N 步做一次目标对齐校验（让模型对照原始目标给当前进度打分，或用规则比对），设置漂移阈值（如相关性低于 0.6 或连续 2 步无关）触发回正；回正——轻度漂移时注入"回到目标"的提示并要求重述目标与下一步的关联；重度漂移（方向性偏离）触发重规划（以原始目标重新规划剩余步骤）或人工确认（让用户确认继续原目标还是改目标）。护栏要有审计记录：漂移事件、回正动作、最终是否回到目标，用于持续优化护栏阈值。

本题考察长任务漂移的度量与防护。回答要给出三方面度量与量化指标，再讲"预防-检测-回正"三层护栏。核心是"漂移可量化、护栏有层级、回正留记录"。