Agent 与确定性工作流边界

• 单次 Tool Calling 决策权在模型单步选择，固定工作流决策权在代码拓扑，动态 Agent 决策权在循环中的模型
• 从 trace 中识别循环结构、条件路由的决策者与下一步选择的来源
• 决策权位置与可控性、可审计性、可恢复性的关系

单次 Tool Calling 的决策权最小：模型只在"当前这一步"决定调用哪个工具、传什么参数，调用完即终止，后续路径由代码接管。固定工作流（Workflow）的决策权完全在代码拓扑中：分支、循环、顺序都由开发者预先写死，模型只填充节点内部的局部输出。动态 Agent 的决策权最大：模型在每个迭代中既决定"要不要继续"，也决定"下一步做什么"，循环终止与否由模型结合终止条件自行判断。

从执行轨迹识别模式的核心是看"下一步是谁决定的"：若 trace 中每个节点之后都回到同一个模型循环入口，且节点顺序在多次运行中高度可变，是 Agent 模式；若节点顺序固定、分支条件来自结构化字段而非模型自由文本，是工作流模式；若整个 trace 只有一个模型调用加一个工具调用、随后直接结束，是单次 Tool Calling。还可以看终止信号的来源：由代码显式 return 结束的是工作流，由模型输出 stop 或达到预算阈值结束的是 Agent。

这道题考察对三种抽象本质的理解：决策权从"单步"到"拓扑"再到"循环自主"是递进的，识别方式应抓住"下一步由谁决定"这个不变判据，而不是看是否调用了模型——因为三种模式都会调用模型。回答时从决策权定位和 trace 判据两方面展开，可以体现工程判断力。

• "步骤序列不可预先枚举"是引入 Agent 的核心判据
• 分支条件依赖模型语义理解而非结构化字段
• 引入 Agent 前应先穷尽规则方案，避免用 Agent 掩盖设计缺失

引入 Agent 的充分条件是"步骤无法在编写代码时预先确定"：执行路径依赖非结构化的自然语言输入、开放领域的推理或动态环境反馈，开发者无法枚举所有分支组合。更精确的判据有三个：一是目标可描述但达成路径不可预写；二是中间步骤的选择需要语义理解（如从用户一句话判断该查哪个系统）；三是每步结果会影响后续步骤的选择，形成无法静态展开的依赖图。

反之，如果步骤可以枚举、条件可以写成结构化判断、输出格式固定，就应继续使用代码控制流。引入 Agent 不是"更先进"，而是为不可枚举空间付出的可控性代价；实践中应先画流程图，若流程图能画完整，就用工作流，只有画不完整（存在"此处无法预先确定"的节点）才把该节点交给 Agent。

这道题的核心是"步骤可枚举性"这一工程判据，而不是"模型能力是否够强"。回答时应强调：能用规则就不用 Agent，Agent 只负责无法枚举的语义决策节点，这既是边界问题也是成本问题。举出具体可枚举与不可枚举的对比能显著提升说服力。

• Agent 状态的定义粒度与类型化（显式状态模式）
• 允许工具集与任务最小匹配原则
• 终止条件与步数、时间、成本三类预算的联合兜底

Agent 状态应是显式的、类型化的数据结构，包含任务目标、已完成步骤、中间产物和约束字段，而不是隐式的全局变量；状态必须可序列化，因为它是断点恢复与审计的基础。允许工具集应按任务最小化：只暴露当前任务必需的少量工具，工具描述用动词+对象+副作用说明的格式，减少模型误选。终止条件分为成功终止（目标达成）与异常终止（failed、stalled、budget_exceeded），并定义最大步数、最大墙钟时间与最大成本三个预算。

三个预算必须联合设置并取"先到者"生效：最大步数防止死循环，时间预算防止对端系统长期占用，成本预算防止 Token 失控。单一上限的缺陷是：只限步数时，单步可能因超长上下文消耗巨额 Token；只限时间时，可能产生大量小步导致成本超支；只限成本时，模型可能陷入无限低质量重试。预算耗尽后应进入收尾流程：保存现场、记录失败原因、提示用户可恢复点。

本题考察 Agent 运行时四要素的系统设计能力。回答要强调"显式状态 + 最小工具 + 三类预算联合兜底"这一完整闭环，并解释单类预算为何失效，这比罗列概念更能体现工程经验。预算与终止条件的关系（先到者生效）是关键得分点。

• 混合系统的边界图：确定性节点为主干，模型决策点嵌入其中
• 模型决策点只放在语义理解、开放式生成等不可枚举位置
• 比例设计原则：确定性优先，模型节点越少越可控

边界图的做法是：把整个系统画成一张有向图，节点分两类——确定性代码节点（校验、计算、存储、权限、事务）与模型决策点（意图理解、方案生成、自由文本理解）。确定性节点构成主干骨架，模型决策点是嵌入骨架中的"开关"，每个模型节点都要标注输入输出契约、候选输出集合与兜底分支（模型输出非法时走哪个确定性分支）。图的边就是数据流，模型节点之间不直接相连，中间必有确定性节点做校验与转换。

比例设计应遵循"确定性优先"原则：能用代码写死的判定全部写死，模型只保留无法预写的少数节点。典型混合系统的模型节点占比通常远低于节点总数，一条流水线 80%-90% 是确定性逻辑、10%-20% 是模型决策点。判断某个节点要不要放模型的依据是：能否枚举其输出？能枚举就写规则，不能枚举且出错可逆才交给模型；模型节点的输出必须经过确定性校验节点再进入下游。

本题考察把模糊的"人机分工"落成可画的图的能力。回答重点：边界图以确定性节点为主干、模型决策点嵌入其中且不相连、每个模型点有契约与兜底。比例问题不要给死数字，而是给出"确定性优先 + 可枚举性判据"的设计原则，并说明模型节点必须被确定性节点包裹。

• 三个上限分别防御哪类失控（循环、上下文膨胀、外部系统占用）
• 联合设置"先到者生效"的机制
• 单一上限失效的具体场景分析

三个上限各防一类风险：最大步数防止模型陷入无限循环与无效重试；最大 Token 防止单次或累计上下文爆炸导致成本失控；最大墙钟时间防止 Agent 长时间占用用户、下游系统与计算资源。正确做法是同时设置三个上限，运行时任何一项先触达即触发终止，并进入收尾流程（保存 checkpoint、记录终止原因、生成可恢复摘要）。

仅设单一上限的典型风险：只设步数，单步可能因工具返回超大内容或模型输出超长而消耗巨额 Token 与时间；只设 Token 上限，模型可能在有限 Token 内无限小步空转，永远不产出结果；只设墙钟时间，Agent 可能在时限内密集调用高成本模型，预算完全失控。此外，上限数值应结合任务复杂度分层设置：简单任务步数 5-10、复杂研究任务 30-50，Token 上限要与工具返回体量联动，而不是拍脑袋。

本题考察对三类资源（步数、Token、时间）正交性的理解。回答应先说清各自防御对象，再讲联合生效机制，最后用具体反例说明单一上限为何失效。能给出"上限按任务复杂度分层"的实践建议是加分项。

• 四类终止条件的语义与判定标准
• stalled 检测的具体信号（状态无变化、工具往返震荡）
• 各类终止后的收尾与恢复策略

Agent 的终止条件分为四类：completed 表示目标达成，判定标准是产出通过了验收规则（如校验函数、用户确认）；failed 表示明确失败，即某个不可重试的节点返回错误或模型声明无法完成；stalled 表示无进展停滞，判定依据是连续 N 步状态没有实质变化、重复调用同一工具返回相同结果、或在两个工具间往返震荡；budget_exceeded 表示资源耗尽，步数、Token 或时间任一预算触顶。

处理策略各不相同：completed 后应固化产物并写审计日志；failed 应保留失败现场（最后状态、错误栈、已执行副作用清单）供诊断，必要时触发人工接管；stalled 应先尝试一次轻量干预（如更换提示、重置上下文窗口）再终止，避免把"模型正在思考的长停顿"误判为停滞，停滞阈值要与模型响应时间分布匹配；budget_exceeded 应保存 checkpoint 并向用户返回部分结果与恢复入口，而不是直接丢弃。

本题考察终止条件的完整分类与工程处理。回答要给出四类条件的判定信号与差异化收尾策略，stalled 的误判防护是重要细节：需要"状态实质性变化"作为判据而非单纯步数。区分"长思考停顿"与"真停滞"体现了对模型行为特征的认知。

• 可预测性：输出是否可枚举、是否允许概率性
• 可逆性：出错后能否无损回滚决定是否可以交给模型
• 可解释性与责任：审计要求与问责主体决定规则优先级

四个判定维度：可预测性指该决策的输出空间是否有限且可枚举——可枚举的判定（如权限校验、格式校验、金额计算）必须留给规则，模型只处理不可枚举的语义决策。可逆性指出错代价：删除、付款、合同签署等不可逆副作用必须由代码加人工审批控制，可逆的操作（草稿生成、查询、建议）才允许模型自主执行。可解释性要求决策可被审计复述，规则天然可解释，模型决策需要强制记录推理依据。责任则回答"出事谁负责"：涉及法律与财务责任的决策必须保留人工与规则兜底。

综合使用的方法是先画决策清单，逐项打四个维度的分：任一维度判"否"（不可预测、不可逆、不可解释、责任重大）就留给规则或人工，只有四项都通过才交给模型。这四个维度不是并列投票，而是"一票否决"的关系，其中可逆性最硬——即使模型预测质量再高，也不改变不可逆操作的底线要求。

本题考察人机分工的系统化判据。回答要讲清四个维度的含义与"一票否决"的组合方式，并强调可逆性是最硬约束。举不可逆操作的例子（付款、删除）说明"模型再强也不接管"能直接命中考察意图。

• 质量、延迟、成本、可控性四维权衡框架
• 质量优先场景（准确率敏感）与延迟优先场景（实时交互）的取舍
• 高风险业务的分类与人工兜底策略

四个指标天然存在张力：追求高质量需要更多模型调用与验证循环，推高延迟与成本；追求低延迟则要减少推理轮次，可能牺牲质量；可控性要求更多确定性校验与审批点，同样增加延迟。权衡的基本原则是"按场景定优先级"：后台批量任务可接受分钟级延迟，优先质量与成本；实时对话优先延迟，通过轻量模型加精简工具集控制成本；财务、合规类任务优先可控性，牺牲部分自动化率。

不适合全自动决策的高风险业务包括：资金支付与转账、合同签署、批量删除或修改数据、医疗诊断结论、法律意见、安全策略变更等。这类业务的共同特征是不可逆或责任重大，处理方式不是完全禁止 Agent，而是"Agent 提议、规则校验、人工审批"：Agent 完成收集与建议，确定性规则做风险拦截（金额阈值、权限校验、黑名单），最终由有权限的人审批执行，全程留痕。

本题考察多目标权衡与风险边界意识。回答先建立四维框架并说明张力关系，再按场景给出优先级策略，最后用"提议-校验-审批"三段式覆盖高风险业务，避免"直接禁止 Agent"的极端答案。

• 四类确定逻辑（校验、权限、计算、事务）的识别与代码化
• 模型输出先经确定性校验再进入副作用执行
• 模糊决策与确定逻辑的分层架构

落地方式是分层架构：底层是确定性服务层，包含参数校验（类型、范围、枚举合法性）、权限校验（RBAC/ABAC 判定）、数值计算（金额、税额、时间换算）与事务控制（数据库事务、消息事务、补偿事务），这些全部用代码实现并单测覆盖；上层是模型决策层，只接收"需要语义理解"的输入，输出结构化结果。模型输出的结果不能直接执行副作用，必须先经过确定性服务层的校验——例如 Agent 建议退款，代码层校验订单状态、退款金额上限、用户权限之后才允许发起。

模糊决策的边界要显式声明：每个模型决策点定义输入 schema、输出 schema、可接受值域与失败兜底（输出非法时返回错误码而非静默继续）。关键原则是"模型只产生提议，代码产生事实"：任何写入型副作用都必须由代码按模型提议 + 规则校验结果执行，模型永远没有直接执行权限。这样即使模型幻觉，也被确定性层拦截。

本题考察混合架构的落地形态。回答应给出分层模型（确定性服务层 + 模型决策层）、模型输出必经校验的管线，以及"模型提议、代码执行"的原则。能点出"模型没有直接执行权限"是回答的核心得分点。

• 四类组件的能力边界：检索、推理、规则判定、人工兜底
• 组合架构：RAG 供给事实、规则引擎拦截、Agent 编排决策、人工处理异常
• 任务分配顺序与降级路径

四类组件的分工：RAG 负责供给事实与知识——从文档库检索相关内容拼入上下文，解决模型知识过时与幻觉，但不做决策；规则引擎负责确定性判定——命中预定义规则（合规要求、风控条件、阈值判断）时直接给出结论并拦截，不消耗模型调用；Agent 负责编排与模糊决策——理解意图、规划步骤、调用 RAG 与规则引擎、汇总结果；人工队列承接规则与 Agent 都无法处理的低置信度、高风险或新类型请求，由人审核后给出结论并沉淀为新规则。

组合顺序应是"漏斗式"：请求先过规则引擎做快速拦截与路由，需要知识的再查 RAG，仍不确定的由 Agent 综合分析，最后低置信度或高风险的进入人工队列。每个环节都应有明确的置信度阈值与移交条件，人工处理的结果应回流到规则库与知识库形成闭环。这样 RAG 提升事实准确性、规则引擎保证底线合规、Agent 提供灵活性、人工兜底质量，四者各司其职。

本题考察多组件协同架构。回答要给出漏斗式任务流与各组件职责边界，强调"规则先行、知识增强、Agent 编排、人工兜底"的顺序，以及人工结论回流形成闭环。避免把四者混为一谈或让 Agent 大包大揽。

• 成本-质量曲线的测绘方法（横轴复杂度、纵轴质量/成本）
• 曲线交叉点：任务复杂到规则维护成本超过 Agent 成本时切换
• 子 Agent 拆分时机：单一上下文无法容纳、责任面过大

测绘方法：取同一类任务的一批真实样本，分别用纯 if-else 工作流、混合工作流与 Agent 实现，记录三个指标——成功率/质量分（自动化标注或人工抽检）、单次执行成本（Token + 计算 + 维护折合）、以及规则版本迭代的人工成本。横轴是任务复杂度（分支数、输入变体数），纵轴是综合成本与质量；随着复杂度上升，if-else 的质量曲线因分支遗漏而下降、维护成本指数上升，Agent 的质量曲线相对平稳但单次 Token 成本恒定偏高，两条曲线会有一个交叉点，交叉点之后 Agent 综合成本更低。

拆分 Agent 的依据不是"规则写不完了"而是上下文与职责边界：当单一 Agent 的上下文无法容纳全部约束、或一个 Agent 承担多种职责导致提示词冲突、或需要不同权限与工具集时，就应拆分子 Agent。继续堆 if-else 的代价是分支组合爆炸与不可维护；正确路径是确定性逻辑继续用代码，把"无法枚举的判定"整体迁入 Agent，再按职责边界拆分子 Agent，每个子 Agent 保持单一职责与小上下文。

本题考察量化权衡与架构演进。回答要给出曲线测绘的三指标方法并解释交叉点逻辑，再给出拆分子 Agent 的两个真实信号（上下文超限、职责冲突）。核心观点是"规则与 Agent 不是二选一，而是随复杂度演进的混用"。

• 中间产物分类：草稿（生成内容）、引用（检索来源）、计算（工具结果）
• 持久化位置：状态存储（结构化字段）与对象存储（大对象）分离
• 审计链与恢复所需的元数据（版本、来源、时间戳）

中间产物按类型分存：草稿类（模型生成的长文本）放入对象存储或内容库，保存每个版本与生成时所用的 prompt 与模型版本；引用类（RAG 检索到的文档片段）保存文档 ID、检索时间与相关性得分，保证结论可回溯到源；计算类（工具返回值、SQL 查询结果）保存原始输入输出对与调用链。小结构字段（状态、任务 ID、步骤索引）放入事务数据库，与业务状态一起持久化，大对象在存储中引用其 ID，避免数据库膨胀。

持久化必须带完整元数据：步骤序号、产物类型、来源（哪个节点/工具产生）、时间戳、所用模型与版本、关联的业务关联 ID。这样事后审计能还原"每一步看到了什么、基于什么做出了决策"；故障恢复时，从最后成功 checkpoint 载入状态，未完成的产物按来源决定是否重算——可重算的丢弃重来，不可重算的（如第三方副作用结果）保留并记录。中间产物还应设置保留期与清理策略，避免存储无限增长。

本题考察持久化设计。回答要按类型分存、强调元数据完整性与审计还原能力，并区分可重算与不可重算产物决定恢复策略。把"审计还原"与"故障恢复"两个目的统一到同一套持久化设计中是关键。

• 显式状态 vs 隐式全局变量的差异（可序列化、可审计、可隔离）
• 跨会话传递的内容与授权边界
• 显式传递的工程实现（状态对象、存储、恢复）

应该通过显式字段传递。隐式全局变量的问题在于：状态不透明、无法序列化、多实例部署下内存隔离导致状态丢失，且无法审计"状态从哪来、被谁修改"。显式状态把记忆与上下文建模为结构化的状态对象——包含用户 ID、会话 ID、事实字段、偏好字段、任务上下文与版本号，随请求显式传递、随 checkpoint 持久化，任何节点都能看到完整的状态来源。这样既支持多副本水平扩展，也让状态变化可追踪。

跨会话复用还要处理授权与时效：状态对象中区分用户明确提供的事实、系统推断的偏好与敏感信息，按来源打标签；跨会话注入记忆时只注入当前任务需要的字段并附加时间戳与置信度，避免上下文被陈旧或无关记忆污染。工程实现上，状态对象序列化存入数据库或 Redis，会话开始时按用户与任务组装，结束时合并更新；禁止在模块外另设"全局记忆"副本，避免状态分裂。

本题考察状态管理的基本功。回答要先否定隐式全局变量（不可序列化、不可审计、多实例失效），再给出显式状态对象的建模与跨会话注入策略，并点出授权与时效问题。显式优于隐式的核心理由是"可序列化 + 可审计 + 可隔离"。

• 四类关键节点：思考（模型输出）、工具调用、错误、回退/重规划
• 每个节点的展示内容与关联信息（输入输出、耗时、成本）
• 可视化与可观测性数据的对应关系

trace 可视化应展示四类关键节点：思考节点展示模型的推理内容（可选展示完整推理或摘要）与置信度；工具节点展示工具名称、入参、出参摘要、耗时与返回状态，敏感参数应脱敏；错误节点展示错误类型、错误消息、发生位置与重试次数；回退节点展示回退原因（重试耗尽、校验失败）、回退目标与现场快照。每个节点都要挂上统一的 trace ID 与步骤序号，形成可展开的时间线。

设计要点：时间线以步骤为横轴，每步显示"模型思考 → 工具调用 → 结果校验"的完整链，任意节点可点开查看原始输入输出与 Token 消耗；回退节点用显眼的视觉标记（如不同颜色）区分"正常分支"与"异常路径"；最终呈现"成功路径 + 所有失败尝试"的全景，而不是只显示最终结果。这些信息应直接来源于可观测性数据（OpenTelemetry span、日志、状态快照），可视化只是查询层，不要另建数据源。

本题考察可观测性设计。回答要枚举四类节点及各自的展示内容，强调"成功路径 + 失败尝试"的全景呈现与 trace ID 串联，并说明可视化数据来自统一的可观测性管线而非独立埋点。能提到脱敏与成本展示是加分项。

• 强制审批与礼貌询问的本质区别：是否真正阻塞执行
• 审批的工程实现：暂停执行、权限校验、审批后恢复
• 审批界面的信息充分性（动作、参数、影响、回滚）

强制审批的本质是"执行被硬阻塞"：Agent 在关键决策点暂停，工具调用不真正发出，必须等到审批人明确授权后才继续，任何绕过路径都不存在。实现上，关键工具封装在审批层后面——Agent 只能生成"审批请求"，请求进入审批队列，执行引擎只有收到授权信号才调用真实工具；同时做权限校验，审批人必须在授权名单内，且审批记录与执行记录强关联，形成不可抵赖的审计链。

与之对比，"礼貌询问"只是让 Agent 在对话里问一句"确认吗"，用户回"确认"后 Agent 继续自主执行，本质上仍由模型掌控执行权。强制审批还要配合超时与降级策略：审批超时则任务进入挂起状态并通知相关人；审批拒绝则记录拒绝原因并终止该分支。审批界面应展示动作对象、完整参数、预期影响范围、回滚方案与涉及金额/数据量，让审批人做真正的知情决策。

本题考察高风险操作的安全设计。回答要抓住"硬阻塞 + 审批队列 + 授权校验 + 审计链"这条主线，明确区分"礼貌询问"（模型仍可执行）与"强制审批"（执行被物理阻断）。补充审批超时与界面信息完整性是加分项。

• 上下文隔离：micro-agent 上下文小且聚焦 vs 通用 Agent 上下文大且混杂
• 复用性：micro-agent 可组合复用 vs 通用 Agent 承担全流程
• 故障面：单点故障 vs 局部故障的差异

上下文隔离方面，micro-agent 每次只携带自身职责所需的最小上下文（任务说明 + 专属工具 + 必要数据），上下文窗口占用小、注意力聚焦、幻觉与无关干扰少；大型通用 Agent 把整个任务背景、所有工具和长历史塞进一个上下文，模型需要在大信息量中筛选，容易出现上下文混乱与相关度稀释。复用方面，micro-agent 像函数一样可组合——按职责封装、跨任务复用，通过接口传递结构化数据；通用 Agent 与具体业务流程强耦合，复用时需要整体改造。

故障面方面，micro-agent 是"局部故障"：单个子 Agent 出错只影响其职责范围，可单独重试、替换或降级，其他部分不受牵连；大型通用 Agent 是"单点故障"：任一环节出错可能导致整个上下文状态损坏，重试成本高（整个流程重跑）。代价是 micro-agent 需要编排层处理通信、汇总与错误传播，编排复杂度上升；通用 Agent 实现简单但难维护。工程上通常采用"通用 Agent 做协调者 + micro-agent 做专业执行者"的混合结构，兼顾灵活与可控。

本题考察 Agent 粒度设计的权衡。回答按"上下文隔离、复用、故障面"三个维度对比，并给出混合结构的工程结论。强调 micro-agent 的局部故障面与通用 Agent 的单点故障面是关键得分点。

• 基线对比实验的设计（同一数据集、同一指标）
• 指标维度：成功率、端到端延迟、成本、维护复杂度
• 统计显著性要求与消融验证

证明增益必须做对照实验：先在相同评测集上跑"基线工作流"（规则、if-else 或人工流程），再跑 Agent 方案，评测集要有代表性且固定，指标至少包括成功率、端到端延迟、单次成本、错误率与边界样本覆盖率。评测集要覆盖正常路径、边界路径与失败路径，避免只测成功样本；用同一批真实请求离线回放，保证两个方案面对完全相同的输入。一次成功 Demo 只证明"可能成功"，不证明"持续可靠"，也不说明失败成本。

实验设计要点：成功率要统计置信区间并做显著性检验，防止小样本偶然差异；成本比较要包含推理成本、重试成本与维护成本（规则增加分支的人工成本 vs Agent 提示词调优成本）；对 Agent 方案还要做消融——去掉记忆、去掉反思、减少工具，确认增益来自哪个组件。若 Agent 相对基线在关键指标上没有显著提升，就应如实保留基线，而不是为了"用上 Agent"而替换。

本题考察 Agent 上线的实证方法。回答核心是"对照实验 + 多指标 + 显著性 + 消融"，并承认"没有显著增益就保留基线"的工程理性。能点出失败样本覆盖与成本口径是加分项。

• 完全暴露推理的风险：prompt 注入、内部策略泄露、幻觉暴露
• 心理影响：过度信任或过度怀疑、认知负担
• 分级展示策略：摘要化呈现 + 完整日志审计

不应完全暴露。安全上，推理文本中可能包含内部指令、工具细节、检索策略与未被校验的中间判断，展示给用户等于把攻击面暴露给恶意输入——用户可以通过精心构造的输入诱导 Agent 在"可见推理"中输出敏感策略；同时模型推理中的幻觉与犹豫未经验证，原样展示会误导用户。心理上，完整推理会造成信息过载，用户难以分辨哪些是已确认事实；推理展示还会塑造信任——展示得"很自信"可能引发过度信任，展示大量试错可能让用户怀疑系统能力。

正确策略是分级展示：UI 中只展示结论摘要与关键步骤（做了什么、用了什么依据、结果是什么），把内部推理折叠成可展开的"过程说明"；完整推理日志写入审计存储，仅对开发者与合规角色开放。展示语言应是"结果导向的事实陈述"而非"内心独白"，并明确标注置信度与不确定项。这样既保留透明度（用户知道 Agent 做了什么），又控制风险（内部策略不泄露、错误推理不直接呈现）。

本题考察透明度的边界设计。回答要同时覆盖安全（注入与泄露）与心理（信任塑造、认知负担）两个维度，给出"摘要化呈现 + 完整日志审计"的分级方案。核心观点是透明度不等于暴露原始推理。

• 三类错误的定位：生成层、执行层、目标层
• 格式错误的修复：schema 校验 + 重试 + 结构化输出
• 工具失败与目标未达成的不同处理（重试 vs 重规划 vs 失败声明）

三类错误分层定义：模型输出格式错是"生成层错误"——模型返回了无法解析的 JSON、缺少必填字段或枚举值非法，属于模型输出不满足契约；工具调用失败是"执行层错误"——参数合法但工具抛出异常、超时或返回业务错误；目标未达成是"目标层错误"——所有步骤都执行了但最终产出不满足任务目标或验收标准。三者的修复策略完全不同，不能混用。

格式错误的修复最轻：用 schema 校验器（如 JSON Schema、Pydantic）拦截，失败后把校验错误信息回传给模型要求修正，通常 1-2 次重试即可恢复，配合强制结构化输出（function calling、JSON mode）可大幅降低发生率。工具失败的修复要看错误类型：瞬时错误（超时、限流）做指数退避重试；参数或状态类错误（权限不足、数据不存在）重试无意义，应检查工具返回错误并调整参数或更换工具；持续失败则标记该工具不可用并重规划。目标未达成无法靠重试修复，需要反思失败原因、调整计划重新执行，或声明失败并提交人工。关键原则是：先分类定层，再按层选择重试、降级、重规划或人工接管。

本题考察错误分类与差异化修复。回答要给出三层分类及其修复策略的对应表：格式错→校验重试，工具错→按瞬时/状态分类处理，目标未达成→反思重规划或人工。强调"先分类再修复、不同层不同策略"是得分关键。

• "走神"的机理：多职责导致上下文混杂、注意力稀释、目标漂移
• 任务边界：单一职责、显式目标、受限工具集
• 边界化的工程手段：子 Agent、步骤化 prompt、约束收敛

单一 Agent 处理多任务时"走神"的机理：一是上下文混杂——多个任务的背景、工具与中间产物挤在同一上下文，模型注意力被无关信息稀释，重要约束被淹没；二是目标漂移——多任务长链路中，模型逐步偏离原始目标，开始执行"看起来相关"的次目标；三是角色冲突——不同任务需要不同决策风格与工具偏好，同一套指令难以同时满足。模型本质是概率生成器，约束越多越模糊，越容易产生与主目标不一致的输出。

用任务边界收敛的方法：把大任务拆成职责单一的子 Agent 或子步骤，每个边界内只含一个明确目标、一套最小工具集与受限上下文；在 prompt 中显式声明"你的唯一目标是 X，禁止处理 X 之外的事务"，并在状态机中限制每步可调用的工具范围；每完成一个子任务输出结构化结果，再进入下一边界，边界之间通过结构化数据传递而非共享全量上下文。还可以加"聚焦校验"——每 N 步检查当前行为是否仍服务于主目标，偏离则提示回正。任务边界把"一个模糊的大模型"变成"一串清晰的约束"，显著降低漂移概率。

本题考察 Agent 聚焦性工程。回答要解释"走神"的上下文混杂与目标漂移机理，再给出单一职责、最小工具、显式目标与聚焦校验等边界手段。能联系子 Agent 拆分与状态机约束是加分项。

• 可恢复性：checkpoint、重试、回滚的能力
• 可解释性：决策依据可还原的能力
• 耦合方式：恢复动作依赖解释信息，解释信息提升恢复质量

二者本质是互相促进的。可解释性提供"发生了什么、为什么"的信息，可恢复性提供"从哪继续、怎么补救"的能力；恢复决策依赖解释：只有知道失败发生在哪个节点、基于什么依据做了决策，才能决定是重试该节点还是回退重规划。反过来，恢复过程本身（重试记录、回退原因、补偿动作）又产生新的解释数据，让后续审计更完整。好的系统设计把两者建在同一套状态与轨迹数据之上：状态快照负责可恢复，决策日志负责可解释，二者共享 trace ID。

也存在表面制约：为增强可解释性而强制记录大量决策详情，会增加存储与序列化负担，轻微影响恢复速度；为快速恢复而只保存精简快照，则丢失决策依据。化解方式是把信息分级——恢复路径只依赖精简的可序列化状态（任务 ID、步骤索引、产物引用），解释信息作为旁路日志异步写入，恢复时按需加载。这样恢复流程不背解释负担，解释能力不拖累恢复速度，实现互相促进而非制约。

本题考察两个质量属性的耦合关系。回答要明确"互相促进"，用"恢复依赖解释、解释依赖恢复数据"论证，再说明分级存储化解表面冲突。能区分"恢复必需的精简状态"与"旁路解释日志"是工程深度的体现。

• 显式状态机设计：状态集合、转移规则、终态定义
• 工具最小化与调用约束
• 终止条件的结构化与自由循环的识别

三要素设定：状态方面，把业务流程建模为显式状态机——预定义状态集合（如待解析、解析完成、校验中、已批准、已完成）、状态转移表（什么条件下允许从 A 到 B）与终态集合，Agent 的每一步输出必须映射到合法状态转移，非法转移被拒绝并触发修正；工具方面，按状态最小化暴露——每个状态只挂当前步骤必需的工具，未挂载的工具模型根本看不到，从机制上杜绝越权调用；终止条件方面，把"目标达成"写成可执行的结构化判定（字段齐全、校验通过、用户确认），配合步数上限与停滞检测，任何循环都在有限步内收敛。

避免自由循环的关键是"模型在状态机内自由，而不是在流程上自由"：状态转移由代码验证，模型只在当前状态内选择合法动作；对简单业务流程（如表单处理、订单查询），预定义状态数少且转移明确，Agent 只负责语义理解（解析输入、匹配意图），所有流程推进由状态机驱动。当模型连续 N 步产生非法转移或重复动作时，触发降级——停止循环、保留现场、请求人工或回退到固定流程。这样简单业务得到确定性保障，模型的不确定性被限制在受控区域。

本题考察用状态机约束 Agent 的实践。回答要给出状态集合、转移表、按状态暴露工具、结构化终止条件四要素，并强调"模型在状态机内自由"的原则与非法转移拦截。这是"确定性优先"思想在编排层的落地。

• 模型能力提升不改变不可逆性与责任约束
• 关键分支（金额校验、权限、支付）必须确定性执行
• 能力提升的收益放在哪：更好的建议与边界处理，而非接管执行

即使模型规划能力再强，高风险流程的关键分支仍必须由代码掌控，因为问题不在"能不能规划"，而在"不可逆与责任"：退款涉及资金流转，一旦执行错误无法无损撤回，且存在合规与审计责任，这些约束不随模型能力变化。模型是概率系统，任何正确率都不是 100%，而关键分支的错误容忍度是 0——金额计算、订单状态校验、支付幂等、权限判定必须由确定性代码保证可证明正确，并承担审计责任。

模型能力提升的正确用法是增强"辅助智能"而不是接管"执行权"：让模型理解用户诉求、生成退款建议与理由、判断异常场景、草拟话术，而代码工作流负责校验建议是否合规、拦截超阈值操作、执行支付并记录审计日志。能力提升带来的收益体现在边界处理（模型能更好处理规则没有覆盖的异常）、错误率下降与更少的规则分支，但结构上仍是"模型提议、代码决策、人工兜底"。高风险流程的关键分支由代码掌控，是对不可逆性与责任的尊重，与模型能力无关。

本题考察对"模型能力与风险架构关系"的正确认知。回答要抓住不可逆性与零容忍约束不随能力变化这条主线，并说明能力收益应放在建议层而非执行层。这是对抗"模型变强就全面接管"叙事的核心论点。

• 计划的数据结构：计划项、执行状态、副作用记录
• 失败原因的分类记录与重规划输入
• 已完成副作用的幂等标记与跳过机制

把计划建模为可追踪的数据结构：计划包含若干计划项，每项记录目标、执行状态（未执行/执行中/已完成/失败）、依赖关系、产出物引用与副作用标记。失败发生时，保留完整原计划不删除，附加失败节点信息（哪个计划项失败、错误类型、错误详情、当时上下文摘要），作为重规划的依据输入——新计划由"原计划 + 失败原因 + 剩余目标"共同生成，避免模型凭空重新理解任务。

避免重复执行的核心是副作用记账：每个产生外部影响的动作（发消息、写数据、调第三方）执行前生成幂等键，执行成功后标记"副作用已完成"并持久化；重规划后的新计划复用原计划中已完成项的结果，未完成项重新执行前先查幂等表，若该副作用已发生则跳过执行只取结果。还要保存每步的输入输出快照，重试时优先复用。这样即使重规划多次，外部副作用也只发生一次，符合"at-least-once 语义 + 幂等去重"的分布式可靠性原则。

本题考察重规划与副作用管理。回答要给出计划数据结构（状态 + 依赖 + 副作用标记）、失败原因作为重规划输入，以及幂等键驱动的副作用去重机制。核心是"计划可演进、副作用只发生一次"。

• 三种模式的执行结构差异：单循环 / 两阶段 / 预定义图
• 延迟差异：ReAct 逐步、P&E 计划一次执行多次、状态图并行与确定性
• 可观测性与错误恢复的差异

三种模式的工程差异源于执行结构：ReAct 是单循环——每步"思考+行动"交替，结构最灵活但步骤串行、延迟随步数线性增长，且每步都走模型导致延迟与成本最高；Plan-and-Execute 分两阶段——先生成完整计划，再逐步执行并校验，规划开销一次、执行步骤仍可并行化，整体延迟低于 ReAct，但计划可能过时，需要重规划机制；状态图编排（如 LangGraph）把节点与边预先定义，支持并行分支、确定性路由与预编译优化，延迟最低且可预测，但灵活性受图结构限制。

可观测性方面，ReAct 的轨迹是自由文本链，解析困难，只能按轮次记录；P&E 可分别观测计划与执行，但计划与执行的关联需要额外维护；状态图每个节点、边、状态转移都是结构化对象，天然适合打点，可观测性最好。错误恢复方面，ReAct 只能整链重试或重跑，定位问题成本高；P&E 可定位到失败的执行步骤并局部重规划；状态图可按节点重试、条件边回退、checkpoint 恢复，恢复粒度最细。选型结论：追求低延迟与可控性选状态图，追求开放任务灵活性选 ReAct，任务可预分解但环境动态选 P&E。

本题考察编排模式选型的工程对比。回答要按"执行结构→延迟→可观测性→错误恢复"四个维度逐一对比，最后给出选型结论。用"结构化程度"作为贯穿主线能提升回答的条理性。

• 置信度阈值驱动的行为分档（自主执行/降级/人工）
• 规则节点的硬性收敛
• 人工确认的触发条件与收敛闭环

收敛行为的三级机制：置信度收敛——每个模型决策附带置信度估计（分数或自评），低于阈值 A 时自主执行，介于 A、B 之间时降级（简化动作、加校验、问澄清问题），低于阈值 B 时转人工；规则节点收敛——在流程中插入确定性规则节点，对模型输出做硬校验（格式、值域、权限、风险规则），命中禁止规则直接拦截，不依赖模型自我修正；人工确认收敛——对高风险动作、低置信度决策或规则无法判定的情况，暂停并提交人工审批，审批结果成为最终决策依据。

三者是递进组合而非互斥：置信度是软信号，规则节点是硬闸门，人工确认是最终裁决。设计要点是阈值要基于真实数据校准（收集历史决策的置信度与实际正确率的分布），避免拍脑袋；规则节点要有完备的拒绝原因输出，让下游与用户知道为什么被拦截；人工确认要记录输入证据，结果回流用于校准置信度与补充规则。这样系统行为在任何输入下都收敛到三条路径之一——执行、降级、人工，不存在"模型无限自主"的盲区。

本题考察行为收敛的三级机制。回答要讲清置信度软分档、规则硬闸门、人工最终裁决的递进关系，并强调阈值校准与结果回流。核心观点是任何决策最终都收敛到受控路径。

• 三类变化的信号差异：用户陈述 / 环境数据 / 模型无依据断言
• 变化检测机制：意图比对、状态校验、事实核查
• 计划失效时的重规划触发与旧计划处置

三类变化要从信号来源区分：用户目标变化有明确的用户陈述信号——新一轮输入中出现了目标变更词（"改成""换一种""重新按 X 做"）或与既定目标矛盾的要求，属于最高优先级变化，应直接终止旧计划并按新目标重规划；环境状态变化表现为可验证的数据变化——数据库记录被修改、第三方 API 返回状态码变化、前置任务结果与预期不符，通过比对环境快照发现；模型幻觉则是无外部依据的断言——模型声称"已完成"但副作用记录中没有对应动作，或声称"用户之前要求过 X"但对话历史中无记录，需要通过事实核查（检索历史、核对状态）识别。

避免错误继承旧计划的机制：每轮开始先做"计划有效性检查"——比对当前目标与用户最新意图、校验环境关键字段、核查上轮声称的产出；任一检查不通过则标记旧计划失效，重规划时只继承"已完成的、经核实的副作用与产出"，未核实的计划项全部废弃。执行中还应对模型的新增断言做来源标注（来自用户/来自工具/来自模型推断），只有来源可靠的断言才能修改计划。这样目标变化快速响应、环境变化增量修正、幻觉被核查拦截，三层防线防止旧计划被错误延续。

本题考察多轮交互中的计划失效管理。回答要按信号来源区分三类变化，给出计划有效性检查机制与"已核实副作用才可继承"的原则。能引入"断言来源标注"是高级加分点。

• A/B 实验设计：分流、同一任务集、双盲评估
• 多指标对比：成功率提升 vs 成本与延迟代价
• 边际收益判定：净收益公式与决策阈值

A/B 测试的规范做法：同一批真实任务随机分流到控制组（旧方案，如规则或简单 LLM 调用）与实验组（Agent 方案），两组输入分布一致；效果评估由不了解分组的评估者（或自动化指标）评定，避免主观偏差；观测周期要覆盖业务波动（如不同时段、不同用户类型），样本量满足显著性要求。指标分为收益指标与代价指标：收益看任务成功率、完成质量、人工介入率下降；代价看平均 Token 成本、端到端延迟、失败重试率、运维复杂度。

边际收益的判定是"净收益"问题：净收益 = 成功率提升带来的业务价值 − 成本增加 − 延迟恶化带来的用户体验损失。例如成功率从 80% 提到 92% 但单次成本翻倍、P95 延迟从 2s 升到 8s，需要折算业务价值与流失损失后判断是否值得。决策前还应做敏感性分析——把延迟与成本恶化到什么程度时收益被抵消，得到切换阈值；上线后持续监控三个指标，若边际收益被侵蚀（如 Agent 在长尾任务上成功率骤降）则灰度回退。A/B 结论要落到"可回退的灰度决策"而不是"永久二选一"。

本题考察 Agent 收益的实证评估。回答要覆盖实验设计（分流、盲评、显著性）、收益-代价双维指标与净收益判定三个层次。强调"收益必须减去成本与延迟代价"是本题核心，灰度回退是工程落地关键。

• 确定性节点适用场景：可枚举、可校验、副作用关键
• 自主规划适用场景：开放目标、路径不可预写
• 判断依据：可枚举性、可逆性、失败代价、可解释要求

应使用 LangGraph 确定性节点的任务特征：步骤可预先枚举、条件可写成结构化判断、对正确性有硬要求且不可逆——如输入校验、权限检查、金额计算、数据写入、状态机转移、固定顺序的合规流程。这些节点用 Python 代码实现（普通函数、工具节点），不经过模型，保证正确性、速度与成本可控；LangGraph 的 StateGraph 支持用条件边（add_conditional_edges）把这类分支写成确定性路由。

适合 LLM Agent 自主规划的任务特征：目标开放、路径不可预写、需要理解非结构化输入并动态决策——如根据用户一句话拆解研究任务、生成多步方案、在未知场景中探索。判断依据三条：输出空间可否枚举（可枚举→确定性节点）、失败是否可逆（不可逆→确定性+审批）、可解释与责任要求（合规场景→确定性为主）。工程结论是大多数任务落在混合区：主干用确定性状态图保证可靠，个别"无法预写"的节点用 LLM 节点并配 schema 校验与兜底分支。LangGraph 的价值正是同时支持两类节点在同一图中组合。

本题考察 LangGraph 中的确定性/自主性分工。回答要给出两类任务的典型特征与三条判断依据（可枚举性、可逆性、责任），并落到"混合状态图"的工程结论。避免"全部交给模型"或"全部写死"的极端。

• 升级前评估：破坏性变更清单与影响面分析
• 升级流程：兼容层、灰度、回归验证
• 升级风险：序列化、checkpoint、工具语义变更

框架版本升级必须当作正式迁移项目而非"改个依赖版本"。第一步是读升级指南与 changelog，梳理破坏性变更清单：状态序列化格式是否变化、checkpoint 存储结构是否变化、节点/边 API 是否改名、工具调用语义是否变化、持久化数据是否兼容旧版本。评估影响面要盘点所有用到该 API 的代码与线上存量数据——LangGraph 0.x 到 1.x 这类大版本往往改变状态定义与持久化格式，已存 checkpoint 可能无法直接读取。

升级实施分三步：建立兼容层（新版本下实现旧的序列化适配，或写迁移脚本转换存量 checkpoint）；灰度发布（先在测试环境跑全量回归与历史任务回放，再按流量百分比灰度，观察成功率、延迟与恢复功能）；保留回滚通道（新旧版本并行部署，新版本异常时一键切回，回滚后旧版本能继续处理新任务）。特别要验证升级后的断点恢复、时间旅行、重放类功能，因为这类功能对序列化与状态语义最敏感。升级完成后运行一段观察期，确认指标稳定再清理旧版本。

本题考察框架升级的工程化。回答要覆盖变更清单梳理、存量数据兼容、灰度与回滚三条主线，并点出序列化与 checkpoint 是 LangGraph 类框架升级的最大风险点。把升级当作"可回退的迁移项目"是核心态度。