如果用户连续追问「为什么选这家酒店?「,Agent如何回溯决策链并给出可解释理由
P1 · agent_architecture
🏷 标签：explainability, decision-chain, traceability, user-interaction
1️⃣ 考察意图
面试官想考察你能否在Agent系统中落地可解释性（Explainability），而非仅背概念。核心是：当用户连续追问时，Agent如何从黑盒决策转向透明回溯，并支持交互式调整。刁钻点在于：决策链的持久化粒度——是记录最终分数，还是每一步的候选集、权重、约束？答好了能展示你对Traceability（可追溯性）、交互式调试和LLM生成可解释性的工程落地能力，这是P1级Agent架构师的核心硬实力。
2️⃣ 标准答
核心思路：将决策链设计为可序列化的“推理日志”，支持按需回溯和自然语言解释。
1. 决策链记录：结构化日志
- 记录粒度：每一步保存
(step_id, 候选集, 评分模型输出, 权重, 约束条件, 最终选择)。例如酒店推荐：候选集（酒店A/B/C），评分模型（价格权重0.3、评分0.5、距离0.2），约束（预算≤500元）。 - 实现工具：使用LangChain的
CallbackHandler或自定义DecisionLogger，在每次调用LLM或工具时写入JSON日志。关键字段：timestamp、action、input、output、confidence。 - 为什么这么做：记录完整候选集而非仅最终结果，是为了支持“对比展示”——用户问“为什么不是B？”时，能直接回溯B被淘汰的原因（如评分低0.2分）。
2. 回溯机制：按时间线检索
- 存储：日志存入内存字典或轻量级DB（如SQLite），按
session_id索引。 - 检索：当用户追问“为什么选这家？”时，Agent解析意图（意图分类器判断为“explain”），从日志中提取最近N步（如最近3步）的决策链。
- 坑与解法：连续追问可能涉及多步决策（如先选城市、再选酒店）。实际落地的坑：用户问“为什么选这家酒店？”时，Agent可能只回溯最后一步，忽略前置决策（如城市选择）。解法：在日志中维护
parent_step_id，形成决策树，回溯时沿路径向上展开。
3. 可解释性生成：LLM + 模板
- 模板化解释：先填充结构化模板：“我推荐{酒店名}，因为{评分最高}（评分4.8 vs 其他4.2），且{距离景点步行5分钟}（优于B的15分钟车程）。”
- LLM润色：当用户连续追问时（如“为什么评分更重要？”），用LLM将日志中的权重对比转化为自然语言：“在您的偏好中，评分权重设为0.5，而价格仅0.3，因此评分高的酒店胜出。”
- Trade-off：模板化解释快且可控，但缺乏灵活性；LLM解释自然但可能幻觉。工程取舍：先用模板覆盖80%场景，对复杂追问（如“为什么权重这样设？”）才调用LLM，成本与准确性平衡。
4. 交互优化：支持用户调整
- 修改权重：用户说“我更看重价格”，Agent解析后更新日志中的权重字段，重新运行评分模型，输出新推荐。
- 对比展示：展示新旧决策链差异：“之前推荐A（价格高），现在推荐B（价格低，但评分降0.3）。”
- 实际落地的坑：用户修改后，Agent可能忘记前置约束（如预算）。解法：在日志中固化约束条件，修改权重时自动校验一致性。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，决策链记录，用结构化日志保存每一步的候选集、权重和评分，粒度要细到能回溯对比；第二，回溯与生成，按时间线检索日志，先用模板生成解释，复杂追问再调LLM润色；第三，交互调整，允许用户修改权重并重新计算，同时展示新旧差异。总结一句：可解释性不是事后补丁，而是从设计之初就嵌入决策链的每个节点。”
4️⃣ 高频追问 & 应对
追问 1：如果用户问“为什么不是B酒店，它评分更高？”但日志显示B评分确实低，怎么处理？
首先检查日志中B的评分是否被错误记录（如数据源错误）。若日志正确，则解释：“B评分高但价格超预算（约束条件），因此被过滤。” 若用户仍质疑，提供对比视图：展示B的评分4.9 vs A的4.8，但价格B为600元（超预算500元），A为450元。关键：日志必须记录约束条件，否则无法解释过滤逻辑。
追问 2：连续追问10次后，日志量太大怎么办？
采用滑动窗口：只保留最近N步（如20步）的完整日志，更早的日志压缩为摘要（如“前5步决策：城市选北京，预算定500元”）。同时，对高频追问（如“为什么选这家？”）做缓存，相同决策链直接返回缓存解释。工程取舍：压缩会丢失细节，但可接受——用户很少回溯10步以上。
追问 3：如果Agent的决策依赖LLM的随机输出（如“感觉这家不错”），怎么解释？
这种情况说明决策链设计有缺陷。正确做法：LLM只用于生成解释，决策必须基于结构化评分模型（如加权和）。如果确实需要LLM参与决策（如情感分析），则记录LLM的输入、输出和置信度，解释时说明：“LLM根据用户评论情感分析，认为这家酒店更符合您的偏好（置信度0.85）。” 同时提供备选方案，降低用户对黑盒的依赖。
5️⃣ 避坑 · 常见错误答法
- ❌ “记录每一步的LLM输出，然后直接返回给用户看。” → ✅ “LLM输出不可直接作为解释，需结构化日志（权重、评分、约束）并模板化生成，避免幻觉。”
- ❌ “只记录最终结果，用户问时再让LLM编一个理由。” → ✅ “必须记录决策过程（候选集、评分、过滤条件），否则LLM会编造不存在的理由，导致信任崩塌。”
- ❌ “用向量数据库存日志，用户问时检索相似历史。” → ✅ “决策链是时序的，用向量检索会丢失顺序和因果关系，应使用时间线索引（如SQLite按step_id排序）。”
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索日志”角度切入，强调用向量存储决策链的候选集，但需结合时间线索引。可展示你如何用LangChain的CallbackHandler记录每一步的检索结果。
- 如果你只做过传统NLP：用“对话状态追踪（DST）”类比，将决策链视为状态槽位（如酒店、价格、评分），回溯就是按时间线填充槽位。强调结构化日志与DST的相似性。
- 如果你是校招无项目：聚焦论文复现，如Google的“Explainable Recommendation via Decision Chains”，用Python实现一个迷你Agent，记录酒店推荐的决策日志并生成解释。GitHub上可找到类似demo。
7️⃣ 延伸阅读
- 《Explainable Recommendation: A Survey and New Perspectives》（论文）
- LangChain CallbackHandler 官方文档（工具）
- 《Building Trustworthy AI Agents: Traceability and Debugging》（博客）
- SQLite 时序数据存储最佳实践（博客）
- Google’s “Decision Transformer” for Explainable Agents（论文）