错误恢复与容错
Q：Agent 如何减少幻觉？在工业场景下怎么做？
来源：字节后端开发 Agent 一面 【字节实习Agent开发一面追问：任务幻觉（Agent编造未请求的执行步骤）】
新手答：“用 RAG 给模型提供事实依据。”
高手答：
RAG 是一层，但远远不够。工业场景下减少幻觉要多层防线：
生成前——约束输入：
- Prompt 约束：在 System Prompt 里明确要求“只基于提供的信息回答，不确定时说不知道”。这是最弱但成本最低的防线
- RAG 注入事实：检索相关文档作为上下文，让模型“有据可依”而不是凭空生成
- 上下文精简：注入的信息要精准，噪声太多反而会诱发幻觉——模型会从不相关的上下文里“编”出看似合理的内容
生成中——约束输出： 4. Structured Output：用 JSON Schema 或 function calling 约束输出格式，减少自由发挥的空间 5. 引用溯源：要求模型在回答中标注信息来源（“根据文档 A 第 3 段”），强制它把生成和证据绑定
生成后——校验结果： 6. 事实校验链路：用另一个模型或规则引擎校验生成内容的事实性——关键数字、日期、实体名称是否和源数据一致 7. 一致性检测：对同一问题多次生成，如果答案不一致，说明模型不确定，标记为低置信度 8. 人工兜底：高风险场景（金融、医疗、法律）不管模型多自信，关键结论都要人工审核
防线层级：Prompt 约束 → RAG 注入 → 格式约束 → 引用溯源 → 事实校验 → 一致性检测 → 人工审核差距在哪：新手只有“用 RAG”一句话。高手按生成前、生成中、生成后三个阶段构建了七层防线——和后端系统的“防御性编程”是同一个逻辑。面试官不想听单一手段，想看你有没有多层防线的工程化治理思维。
Q：你怎么设计 Agent 的失败恢复机制？
来源：腾讯大模型应用开发二面
新手答：“报错后重试。”
高手答：
失败恢复不能只理解成“报错后重试”。Agent 的失败通常分成好几类，不同类型的恢复方式不一样：
| 失败类型 | 恢复策略 |
|---|---|
| 临时性错误（接口超时、网络抖动） | 限次重试，指数退避 |
| 参数缺失 | 回退到追问用户节点 |
| 模型连续选错工具 | 触发降级策略，改成规则路由或人工兜底 |
| 外部系统不可用 | 及时终止并返回清晰失败原因 |
| 依赖数据缺失 | 走备选数据源或降级到有限回答 |
关键原则：恢复机制一定要和状态绑定，不能让模型自己“觉得应该再试一下”，不然很容易进入无穷重试。每种失败类型对应一个明确的恢复路径，由编排层控制，而不是靠模型自主判断。
差距在哪：新手的”重试”是一种恢复策略，但只适用于临时性错误。高手先对失败做了五类划分，每类有不同的恢复路径，且强调恢复机制要和状态机绑定。面试官考的是你能不能做系统性的错误处理设计，而不是一刀切的重试。
追问：工具报错时，怎么用提示词引导模型利用报错信息自主重试，而不是直接把错误返回给用户？
来源：阿里淘天 AI应用开发一面
关键在于把错误信息结构化后回喂给模型，让模型基于错误原因调整参数重试：
System Prompt 中的重试引导：
当工具返回错误时，你必须：
1. 分析错误类型（参数错误/权限不足/超时/数据不存在）
2. 如果是参数错误，根据错误提示修正参数后重试
3. 如果是超时，等待后用相同参数重试（最多 2 次）
4. 如果是权限不足或数据不存在，向用户说明原因
5. 绝不将原始错误堆栈返回给用户工程实现的三个要点：
- 错误信息脱敏：把原始 stack trace 转成模型可理解的结构化描述（
\{error_type: “invalid_param”, field: “date”, hint: “格式应为 YYYY-MM-DD”\}） - 重试预算：在编排层设硬性上限（如同一工具最多重试 3 次），不依赖 Prompt 约束
- 错误模式学习：记录高频错误模式，反向优化工具描述和参数 schema，从根源减少错误
Q：执行到一半，比如调支付接口超时了，Agent 怎么处理？
来源：腾讯 Agent 岗终面
新手答：“重试，或者报错给用户。”
高手答：
我们有标准的错误处理工作流：
- 错误分类：网络超时 / 5xx 错误，走指数退避重试，最多 2 次。4xx 错误（如参数错），触发“参数诊断”子流程——用小模型分析错误信息，调整参数后重试。
- 备选方案：如果还不行，且这个工具是核心路径（如支付），就启动备选方案。比如主支付通道挂了，自动切换到备用通道。
- 完整记录：所有状态和决策日志完整记录，方便事后复盘。
目标是任务尽可能完成，而非一遇错就崩。
差距在哪：新手只有两个选项：重试或报错。高手的回答是一个分层的错误处理策略——先分类、再分别处理、有降级方案、有日志记录。面试官考的是“你有没有做过需要高可用的系统”，Agent 的容错设计和传统后端系统是相通的。
Q：如果 Agent 的决策出错了，比如错误删除了数据，系统设计上怎么防范？
来源：腾讯 Agent 岗终面
新手答：“重要操作前让用户确认。”
高手答：
这是系统设计题。核心原则是**“可审计、可回滚、最小权限”**：
- Dry-run 模式：所有写操作工具必须支持 dry-run，先返回预览，确认后再执行
- 操作分级 + 多人确认：高风险操作（删、改、支付）不仅需要用户确认，还会强制同步通知第二责任人（如主管）
- 完整溯源日志：每个决策的完整思维链、调用的工具、参数、结果都必须打入日志，且能一键重现
- 权限隔离：Agent 的操作账号权限必须是最小集，且通过内部审批流程申请
永远不要相信模型的“保证”，要用系统锁死它的操作范围。
差距在哪：新手只想到了“用户确认”——这是防范手段之一，但远远不够。高手的回答是一套完整的安全体系：预览 → 确认 → 日志 → 权限隔离。面试官考的是“你有没有系统设计的思维”，这道题和 Agent 的关系不大，和“如何设计一个安全的操作系统”的思路完全一样。