【AI Agent面试系列】AI Agent实战设计

本文继续介绍AI Agent实战设计中的知识点。

1、什么样的场景适合用 Agent？什么样的不适合？

适合 Agent 的场景要同时满足"路径不确定 + 需要工具 + 多步依赖"，且容错可兜底；

流程确定、单步可解、延迟敏感、要求强确定性、错误不可承受的场景都不适合；

实践中优先考虑最简方案，常见形态是"确定性工作流 + 有限自主 Agent"的混合架构。

判断要不要用 Agent，分两步：

• 第一步看"需不需要"
  路径不确定、需要外部交互、多步有依赖，三条同时满足才说明 Agent 这种形态有价值；缺一条就该用工作流、单次调用或批处理。
• 第二步看"允不允许"
  容错空间是否足够（错了能改能重试）、是否有可靠的人工兜底。这两条不满足，即使需要 Agent 也不能上，要么加人工确认点、要么缩小自主范围、要么干脆不上。

两步都过，才真正适合。

1.1、适合的场景

• 开放式信息检索与整合：多源搜索、交叉验证、生成报告（如竞品调研、尽调）
• 多步操作类任务：订票、报销、工单处理、跨系统数据搬运
• 代码类任务：修 bug、写测试、重构------有明确反馈信号（编译/测试通过），天然适合自我纠错
• 客服/售后：意图不确定、需要查订单查物流、需要多轮澄清
• 数据分析：自然语言 → 查库 → 分析 → 出图，路径随数据变化
• 运维排障：看日志、查指标、定位、执行修复，步骤依赖现场情况
• 长尾、低频、规则难穷举的业务流程

共同点：输入开放、路径开放、有工具、有反馈。

注意：

• 能上 Agent 不等于该上 Agent：先问"最简方案是什么"，Agent 是最后手段不是首选。
• 任务越重要越不该全自主：高价值任务要缩小自主范围，加人工确认点。
• 有明确反馈信号的任务最适合 Agent：代码（测试）、SQL（能否执行）、数学（能否验算），因为能自我纠错；反之无反馈的任务 Agent 容易自信地跑偏。
• Agent 的适用性会随模型能力变化：今天不适合的（如长流程规划），模型变强后可能就适合了，判断要动态看。
• 成本结构决定可行性：单任务多步推理成本是单次调用的 5~20 倍，量大的场景要算单位成功成本。

1.2、不适合的场景

• 流程完全确定：审批流、固定表单校验------用工作流引擎，更便宜更可靠
• 单次问答就能解决：分类、抽取、翻译、摘要------一次模型调用足够，上 Agent 是浪费
• 对延迟极敏感：实时风控、广告竞价、在线推荐------多步推理的延迟不可接受
• 对确定性要求极高：计费、清算、合规判定------必须可审计可复现，规则/代码更合适
• 错误代价不可承受且不可回滚：直接转账、删除生产数据、医疗用药建议------除非有强人工确认
• 数据不可外发/强合规：涉密场景，工具调用和外部检索受限
• 高频大规模且任务同质：单次成本再低也扛不住量，应该蒸馏成小模型或规则
• 没有可靠工具或反馈信号：Agent 无法验证自己做得对不对，就会瞎跑

1.3、中间地带：更该考虑的替代方案

方案	适用
单次 LLM 调用	任务一步可完成
工作流 / 状态机 + LLM 节点	流程确定，但个别节点需要理解自然语言
RAG	只是需要知识，不需要行动
固定 pipeline + 规则	高确定性、高吞吐
Agent	路径开放、需工具、多步依赖

实践中最常见的是混合：主干走确定性工作流，把"需要判断"的节点做成有限自主的 Agent。这比"全自主 Agent"可靠得多。

1.4、问题

• 为什么不用工作流？
  分支无法穷举、或分支数量爆炸时，工作流维护成本高于 Agent。
• Agent 一定比工作流效果好吗？
  不一定。确定流程上工作流更稳更便宜；Agent 的优势在开放路径。
• 怎么判断该不该上？
  做小规模对照实验：同一批真实样本，比较 Agent 与最简方案的成功率、成本、时延，用数据决策。

2、 如何设计 Agent 的"人机协作（Human-in-the-loop）"？

HITL 的设计 = 显式触发条件（风险/置信度/规则）+ 与风险匹配的介入粒度 + 让人能判断的完整信息（dry-run 预览）+ 分级授权与留痕 + 断点恢复与异步闭环；核心是"少而准"，避免确认疲劳，并用介入率、修改率、漏放率来度量，把人工当作系统组件而非事后补丁。

HITL 不是"加个确认弹窗"，而是在正确的时机、把正确的信息、交给正确的人、做最小必要的决策。

注意：

• **HITL 做过头会降低整体安全性：确认疲劳导致人机械点同意，反而让护栏失效。要少而准。
• 人工不是兜底，是系统组件：要像设计 API 一样设计人机接口：输入输出明确、有超时、有重试、有幂等。
• 最好的 HITL 是让人做判断，不让人做操作：人负责"该不该"，机器负责"怎么做"。

四个设计维度：何时介入（触发）→ 介入什么（粒度）→ 谁来介入（角色）→ 介入后怎么继续（流程）。

2.1、何时介入：触发条件要显式定义

不要靠"感觉该问了"，要写成规则：

• 风险触发：高危操作（删除、支付、外发、批量修改）、不可逆动作
• 置信度触发：模型自评置信度低于阈值、多候选投票不一致
• 规则触发：金额/数量/影响面超过阈值
• 异常触发：工具连续失败、检测到注入、结果自相矛盾
• 合规触发：涉及敏感数据、法务/医疗/金融场景
• 用户主动：用户随时可打断、可接管

关键：触发条件要可配置、可审计，而不是埋在 prompt 里。

2.2、介入什么：粒度决定体验

粒度	说明	适用
计划级	先出完整计划，人批准后再执行	长任务、高成本、方向易错
步骤级	每个关键步骤前确认	高危操作、不可逆动作
结果级	执行完给人审，可改可撤	内容生成、报告输出
异常级	只在出问题时才找人	低风险高频任务

原则：介入粒度与风险成正比，与频率成反比。 高频低风险任务如果每步都问，人会被烦死，最后无脑点"同意"------这比不设 HITL 更危险（确认疲劳）。

2.3、给什么信息：决定人能不能做出正确判断

这是最容易被做烂的一环。只弹一句"是否继续？"等于没设计。

必须提供：

• 要做什么：具体动作、参数、影响对象
• 为什么：Agent 的推理依据（可折叠，不干扰主视图）
• 影响面：影响多少条数据、涉及谁、能否回滚
• 风险提示：命中了哪条规则、有什么不确定性
• 可选项：同意 / 修改后执行 / 拒绝 / 转他人
• dry-run 预览是标配：先展示"将要发生什么"，而不是事后告知。

2.4、谁来介入：角色与权限

• 按风险分级授权：低风险自动执行、中风险一线人员确认、高风险主管审批
• 权限与工具权限对齐：能批准删除的人，本身要有删除权限
• 值班与超时：无人响应时怎么办？超时自动拒绝（安全默认）还是升级？
• 责任可追溯：谁批的、什么时候批的、批的依据是什么，全部留痕

2.5、介入后怎么继续：流程闭环

• 状态可恢复：人工介入后，Agent 从断点继续，不从头再来（检查点机制）
• 修改可回灌：人改的参数/内容要作为反馈写回，用于后续优化（数据飞轮）
• 拒绝要优雅：人拒绝后 Agent 应停止或改道，而不是反复重试同一动作
• 异步支持：人不可能实时在线，要支持"挂起 → 通知 → 处理 → 恢复"的异步流
• 超时策略：明确超时后的默认行为，且默认值必须是安全侧

2.6、体验层：别让人成为瓶颈

• 批量确认：同类低风险操作合并成一次确认
• 默认值合理：把最可能的选项设为默认，减少操作成本
• 渐进式信任：同一类操作人连续批准 N 次后，可提升自动执行等级（带审计）
• 可解释：人能看懂 Agent 在干什么，否则无法判断
• 可打断：任何时候能中止，且中止是干净的（不留半成品状态）

2.7、度量：HITL 也要被评估

• 介入率：多少任务需要人工（太高说明 Agent 不行，太低可能风险敞口大）
• 批准率 / 修改率 / 拒绝率：修改率高说明 Agent 输出质量差
• 人工耗时：每次介入花多久，是否成为瓶颈
• 确认疲劳指标：无脑批准的比例、平均决策时间过短的比例
• 介入后成功率：人工介入是否真的挽救了任务
• 漏放率：本该介入却没介入的比例（最危险的指标）

2.8、问题

• 怎么防止人无脑点同意？
  减少介入频次、只在高风险时问、展示关键差异而非全量信息、抽样复核、记录决策时间做异常检测。
• 人不在线怎么办？
  异步挂起 + 通知 + 超时安全默认（拒绝或降级），不能无限等待。
• 人工改了之后 Agent 怎么学？
  修改记录进评测集和偏好数据，用于 prompt 优化或微调。

3、 一个 Agent 产品上线后，你会关注哪些指标？

关注四层指标：业务（价值加权完成率、留存、人力节省）、体验（P95 时延、干预次数、放弃率）、质量（关键错误率、接管率、漏放率）、成本（单位成功成本、每任务 token）；所有指标必须能按模型/prompt 版本和任务类型分组，且成对看------完成率配成本、接管率配漏放率，避免单指标误导。

3.1、四层指标，缺一层就是盲区

层	回答什么问题	典型指标
业务层	有没有价值	任务完成率、留存、转化、节省人力
体验层	用户爽不爽	时延、干预次数、放弃率、满意度
质量层	做得对不对	准确率、关键错误率、幻觉率、人工接管率
成本层	划不划算	单位成功成本、token/任务、P95 时延

只看业务层会掩盖质量问题，只看技术层会脱离价值。 面试时先给这张表，格局就出来了。

3.1、业务层：证明它有用

• 任务完成率（端到端成功率）------最核心，但要按任务类型和价值分层看
• 任务价值加权完成率：高价值任务权重更高，避免"简单任务刷高成功率"
• 用户留存 / 复用率：第二周还在用吗？这是产品是否真有用的硬指标
• 渗透率：目标用户里有多少人真的在用
• 转化 / GMV / 工单解决率等业务结果指标
• 人力节省：替代了多少人工工时（对内部工具尤其关键）
• NPS / 满意度

3.2、体验层：用户体感

• 首响应时延（TTFT） 与 端到端 P50/P95 时延------P95 才是体感
• 人工干预次数 / 任务：干预越多体验越差
• 放弃率 / 中途退出率：用户等不下去或失去信心
• 重问率 / 追问率：一次没说清，说明理解或表达有问题
• 会话轮次：轮次暴涨可能是 Agent 在打转
• 用户反馈：点赞点踩、显式评价

3.3、质量层：做得对不对

• 分步准确率：工具选择、参数填充、结果解读
• 关键错误率：会造成实际损失的错误（误删、误发、金额错）------这个比总体准确率重要得多
• 幻觉率 / 事实错误率（有校验机制时）
• 人工接管率：Agent 搞不定转人的比例
• 漏放率：该拦没拦、该转人没转人的比例（安全侧最危险）
• 失败模式分布：失败归因到具体环节，指导优化
• 多次运行一致性：同输入多次跑的成功率方差

3.4、成本层：划不划算

• 单位成功成本 = 总成本 / 成功任务数（把失败浪费也算进去）
• 每任务工具调用次数（次数暴涨=规划打转）
• 重试率 / 无效步数占比
• 缓存命中率
• 成本按任务类型分布：找出"烧钱但不产出"的任务

3.5、系统健康层：别忽略

• 工具错误率 / 超时率（按工具维度）
• 模型调用失败率、限流率
• 护栏命中率（注入拦截、越权拦截）
• 异常 trace 占比（超预算、超步数、循环检测触发）
• 可用性 / SLA

3.6、关键：指标要能"分组看"

同一堆指标，不分组就是废数据。必须能按这些维度切：

• 模型版本 / prompt 版本（否则改了什么都不知道）
• 任务类型 / 场景
• 用户分层（新老、重度轻度）
• 渠道 / 入口
• 时间（版本发布前后对比）

注意：

• 指标要成对看：完成率 × 成本、接管率 × 漏放率、时延 × 放弃率，单看任何一个都会被误导
• 不同阶段关注点不同：上线初期看质量，稳定期看成本，规模化看体验
• 成本要看单位成功成本：单 token 便宜但重试多，实际更贵

3.7、问题

• 只能看三个指标，你选哪三个？
  任务完成率（价值加权）、关键错误率、单位成功成本。分别对应"有没有用、安不安全、划不划算"。
• 指标掉了怎么定位？
  按模型版本/prompt 版本/任务类型分组对比，再看 trace 的 span 分解，定位到步数、工具还是模型。
• 怎么知道是模型问题还是产品问题？
  看分步准确率（模型侧）与放弃率/重问率（产品侧）是否同步恶化。
• 上线前怎么预估这些指标？
  离线评测集 + 影子流量 + 小流量灰度。

4、 设计一个"能自动处理用户工单"的 Agent，你会怎么设计？

先澄清需求，然后按照分层架构 + 按类型分流（确定性走工作流、开放路径走有限自主 Agent、高风险直接转人工）；Agent 侧靠最小权限工具网关、幂等与检查点、错误分类重试、高危 dry-run 审批保证可靠与安全；用 trace 和"自动解决率 × 关键错误率"成对指标驱动迭代，并分阶段渐进放权。

4.1、先问清需求（面试必做，别直接画图）

• 工单类型：咨询类（查订单/查政策）、操作类（改地址/退款/补发）、投诉类、技术故障类
• 量级与分布：日均多少、Top 场景占比、长尾多长
• 可执行权限：只读查询，还是能真正执行退款/改单
• SLA：响应时长、解决时长要求
• 合规：涉及金额上限、隐私数据、是否需要留痕审计
• 现有系统：工单系统、订单系统、知识库、CRM 的接口形态
• 假设（明确说出来）：日均 1 万单，60% 是查询类，30% 是标准操作类（退款/改地址），10% 是复杂投诉；允许执行操作但金额超阈值需人工审批。

4.2、整体架构：分层 + 有限自主

接入层：工单系统 webhook / 轮询 → 统一任务队列
  ↓
理解层：意图分类 + 实体抽取 + 情绪识别 + 风险分级
  ↓
路由层：按类型分流（见下）
  ├─ 确定性流程（60% 查询类）→ 工作流 + 工具调用，不走 Agent
  ├─ 有限自主 Agent（30% 操作类）→ 规划 + 工具 + 校验 + 审批
  └─ 直接转人工（10% 投诉/高风险）→ 带上下文交接
  ↓
执行层：工具网关（权限、校验、幂等、审计）
  ↓
输出层：回复生成 + 护栏 + 发送
  ↓
反馈层：trace、指标、badcase 回流

核心设计判断：不要做一个"全自主 Agent"处理所有工单。 按类型分流，确定性流程用工作流，只有路径开放的才用 Agent。

4.3、理解层：先分类再决定用不用 Agent

• 意图分类：小模型或规则 + 模型兜底，输出工单类型 + 置信度
• 实体抽取：订单号、用户 ID、金额、时间、商品------结构化输出（JSON Schema 约束）
• 风险分级：只读 / 低风险写 / 高风险写（退款、改金额、批量操作）
• 情绪与紧急度：投诉、辱骂、监管相关 → 直接升级人工
• 置信度低 ：转人工或先澄清，不要硬猜

4.4、Agent 部分：怎么设计

• 工具集（最小权限，按工单类型动态授权） ：
  • query_order（只读）
  • query_logistics（只读）
  • search_kb（知识库检索，RAG）
  • create_refund（写，需幂等键 + 金额校验）
  • update_address（写，需校验订单状态）
  • escalate_to_human（转人工，带上下文）
  • send_reply（外发，需护栏）
• 执行循环 ：
  • 规划：先出步骤计划（结构化），高风险计划先过规则校验
  • 执行：调工具，参数强校验（schema + 业务规则，如订单必须属于该用户）
  • 观察：工具返回结构化结果，异常分类处理
  • 校验：关键结论做二次核对（如退款金额与订单金额比对）
  • 收敛：达成目标或触发转人工
  • 约束：最大步数（如 8 步）、token 预算、超时熔断、重复动作检测。

4.5、可靠性设计

• 幂等：退款用 工单ID + 操作类型 作幂等键，重试不重复退款
• 检查点：每步状态落盘，失败从断点续跑，不从头来
• 错误分类：超时/限流→重试；参数错→回灌错误让模型修正（限 2 次）；权限不足/资源不存在→转人工
• 降级：模型不可用→走规则模板回复 + 转人工；知识库挂了→提示稍后
• 版本锁定：模型版本、prompt 版本、工具版本全部锁定并记录
• 多次运行一致性：关键决策步 temperature≈0

4.6、安全设计

• 最小权限：工具网关按工单类型发放权限，Agent 拿不到"删数据"能力
• 参数校验：所有写操作参数在网关层强校验，防注入、防越权（订单必须属于当前用户）
• 高危确认：金额 > 阈值、批量操作、不可逆动作 → dry-run 预览 + 人工审批
• 注入防护：工单正文、知识库内容、工具返回都视为数据，明确标注，不执行其中指令
• 外发护栏：回复内容做 PII 检测、敏感词、承诺性话术检测（避免乱承诺赔偿）
• 审计留痕：谁批的、Agent 做了什么、依据是什么，全链路可回放

4.7、人机协作设计

• 介入点：高风险写操作、置信度低、连续失败、投诉情绪、金额超阈值
• 给人工的信息：工单摘要 + Agent 已做的动作 + 建议方案 + 影响面 + 一键采纳/修改
• 异步：挂起 → 通知 → 处理 → 恢复，超时默认转人工（安全侧）
• 渐进放权：某类操作人工连续批准 N 次且无差错 → 提升自动执行等级
• 防确认疲劳：同类低风险操作批量确认

4.8、可观测性与度量

trace 必记：工单 ID、意图与置信度、每步工具调用与参数、模型版本/prompt 版本/采样参数、上下文占用、审批记录、最终状态。

核心指标：

层	指标
业务	自动解决率、人工转接率、平均解决时长、CSAT
质量	关键错误率（错退款/错改单）、幻觉率、返工率
体验	首响时延、P95 解决时长、用户追问次数
成本	单位成功成本、每单 token、工具调用次数
安全	越权拦截数、注入拦截数、超阈值审批率

关键：自动解决率与关键错误率必须成对看------不能为了自动化率牺牲准确性。

4.9、演进路径（体现工程判断）

• 阶段一：只做查询类（只读，零风险），验证理解层准确率
• 阶段二：加低风险写操作（改地址），全量人工确认
• 阶段三：高频低风险操作渐进放权，引入批量确认
• 阶段四：badcase 回流 → 评测集扩充 → prompt/模型迭代 → 部分场景蒸馏小模型降本

4.10、问题

• 为什么不全用 Agent？
  60% 是确定性查询，工作流更稳更便宜；Agent 只用在路径开放的部分。
• 退款退错了怎么办？
  幂等键防重复、金额二次校验、超阈值人工审批、软删除/冲正可回滚、全链路留痕可追责。
• 怎么防止工单正文里的注入？
  正文当数据处理、工具返回净化、高危操作必须人工确认、最小权限限制爆炸半径。
• 自动解决率上不去怎么办？
  看失败模式分布：是理解错、工具缺、还是知识库覆盖不足，分别补。
• 怎么保证不越权查别人订单？
  工具网关强制注入当前用户身份做数据隔离，不信任模型传的 user_id。

5、 如果 Agent 在生产环境表现比测试环境差很多，你怎么排查？

先对齐度量口径排除假问题 → 用"环境差异清单"逐项比对 → 拿线上 trace 重放一刀切开数据问题与环境问题 → 用 span 分解定位到理解/规划/工具/模型哪一层 → 高频根因是数据分布偏移和工具真实行为差异；修复靠真实分布评测集、故障注入、影子流量和灰度回滚。

5.1、先确认"差"是不是真的

别急着改代码，先排除度量口径问题：

• 指标定义是否一致：测试环境算"成功"的标准和线上一样吗？线上可能把用户中断也算失败
• 样本分布是否可比：测试集是人工挑的典型样本，线上是真实长尾分布------这是最常见的原因
• 统计口径：线上是 P95 还是平均？样本量够不够？是否受个别极端 case 拉低
• 时间窗口：是否赶上流量高峰、某次发布、模型静默升级

先做这一步，能排掉 30% 的"假问题"。

5.2、定位差异来源（按"环境差异清单"逐项比对）

这是核心方法------把测试与生产的所有差异列成清单，逐项排除：

差异维度	具体检查点
数据分布	输入长度、语言、噪声、错别字、多意图混杂、长尾场景占比
工具真实行为	线上接口慢/限流/返回脏数据/字段缺失/权限不足；测试用 mock 掩盖了这些
上下文	线上有历史会话、多轮累积、记忆污染；测试是干净单轮
并发与资源	线上并发高导致排队、超时、上下文被截断
模型	版本是否一致、是否被静默升级、限流降级到小模型
配置	prompt 版本、采样参数、超时阈值、步数上限是否一致
权限与数据	线上权限更严、数据更脏、跨租户隔离导致查不到
用户行为	线上用户会打断、追问、乱输入、恶意输入

方法：拿同一批线上真实 trace，在测试环境重放。如果重放也差 → 是数据/模型问题；如果重放正常 → 是环境/并发/工具问题。这一步能一刀切开两类原因。

5.3、按层收敛（用 trace 定位到具体环节）

用 span 分解看差异落在哪：

• 理解层：意图分类准确率是否下降？实体抽取是否漏？→ 数据分布问题
• 规划层：步数是否变多？是否出现循环？→ 上下文或工具反馈问题
• 工具层：错误率、超时率、返回空率是否上升？→ 工具真实行为差异（最高频原因）
• 模型层：TTFT、输出 token、截断率是否变化？→ 限流/降级/上下文超限
• 输出层：护栏拦截率是否上升？→ 线上更严的合规策略
• 关键指标对比：把测试与线上的"分步准确率、工具错误率、平均步数、上下文占用、重试率"并排放，差异最大的那一项就是主因。

5.4、高频根因排序（面试可以直接报这个）

按我经验，概率从高到低：

• 数据分布偏移：测试集太干净，线上长尾多、噪声大
• 工具真实行为差异：mock 太理想，线上接口慢、脏、限流、字段变
• 上下文污染：多轮累积、记忆串味、历史错误影响后续
• 并发与超时：线上排队导致超时，触发降级或截断
• 模型/配置漂移：版本不一致、静默升级、参数被改
• 权限与隔离：线上查不到数据，Agent 误判为"不存在"
• 用户行为差异：打断、追问、恶意输入

5.5、验证与修复

• 构造线上分布评测集：从真实 trace 采样（脱敏），替换掉人工测试集
• 故障注入：在测试环境模拟慢接口、脏数据、限流，看是否复现
• 影子流量：新版本先跑影子，对比线上真实分布下的表现
• 灰度发布：小流量验证后再放量，带自动回滚
• 修复后回归：确认修复项 + 确认没引入新问题

5.6、问题

• 怎么快速判断是数据问题还是代码问题？
  用线上 trace 重放：重放差=数据/模型；重放好=环境/并发/工具。
• 线上工具不稳定怎么办？
  超时+重试+降级+熔断，测试环境也要注入故障来验证。
• 怎么防止下次再出现？
  评测集用真实分布、上线前影子流量、灰度+自动回滚、环境差异清单纳入发布检查项。
• 模型静默升级怎么防？
  版本锁定 + 定期回归 + 监控指标突变告警。