题目重点：构建客户支持Agent，区分答案检索、账户查询、退款动作和升级人工，说明安全执行与评估。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练客服处理产品问题与授权账户任务，知识源有版本，订单/账务数据来自受权限控制的API；用户身份先鉴别。
- 高影响操作如退款/改订需明确授权与金额范围，生成文本不直接充当授权凭据。可逆读取与写动作分不同流程。
- 多轮memory只存必要会话状态，不能把别的用户会话或检索到的指令提升成系统权限。
解题路线
- 先建无需LLM的baseline知识搜索+意图路由，定义ticket解决/升级准则，再引入检索增强回答。文档分块带product/version/region/validTime，query检索先权限过滤并给引用。
- Agent状态记录intent、verifiedUser、requiredInfo、toolPlan、toolResults、resolution。缺订单ID或证据时提问，不让模型生成假的订单状态。tool schema限制可调用动作、参数和资源范围。
- 任何工具读取做server-side授权，写动作用policy检查、用户确认与idempotencyKey；模型只建议计划，执行器验参数与版本。被引用文档里的“忽略权限/发退款”是数据而非可执行指令。
- 长任务异步status与失败补偿：退款timeout先查询operationId结果，不立刻重复退款；无法确认转人工并带完整事件记录。回答附来源，低置信/政策例外主动升级。
- 评估集覆盖正确答复、知识过期、缺数据、权限越界、注入、重复工具调用与失败恢复；统计task success、grounding、违规动作、幻觉、人工接手质量及P95成本。模拟工具oracle与真实sandbox分阶段，不能只看LLM judge。
手动走一遍
用户问订单是否发货，知识库不能回答某订单事实，需验证身份并查询订单API。退款请求调用成功但响应timeout，后续先查询该operationId，若已成功就回报同结果而非再退一次。
规模与取舍
每轮延迟=检索+模型+工具RTT+验证，循环限制maxSteps与总预算，避免无尽Agent重试。知识索引更新/外部API不稳定决定实际可靠性，token成本按上下文与工具回包长度估算。
易错点与追问
容易失分的边界
- 将知识文档或工具回包视作高权限指令会被提示注入操控。
- 没有可用证据时“猜一个答案”会损害客服信任；明确unknown与人工入口。
- 会话cache无租户/user隔离会泄露账户信息。
继续深挖
- 人工接手如何避免用户重复描述？传验证过的事实、已尝试步骤与工具状态，不传未经确认的模型猜测作事实。
- 如果模型版本升级，怎样检查同一工单不会因旧memory/新prompt混用而改动作规则？版本化会话与工具政策。
