客户在一次对话中提出三个问题。没有结构化跟踪时，28% 的问题被提及但从未解决或跟进。代理平均解决 2.1 个问题。有了结构化的 Issue Tracker，遗漏率降到 3%，解决吞吐量升到每次对话 3.8 个问题。
跨问题混淆
20 轮对话覆盖两个订单后，代理告诉客户：“订单 #456 的退款已处理。“客户要求的是订单 #123 退款和订单 #456 的物流查询。代理把一个问题的订单号和另一个问题的操作搞混了。
没有结构化跟踪，不同问题的细节作为非结构化文本存在于不断增长的对话中。随着上下文增长，模型会交叉关联不同问题的细节——订单号和操作从不同问题中混在一起。
Issue Tracker 模式
=== ISSUE TRACKER ===
#1: Damaged item refund (order #123) — IN_PROGRESS, awaiting photo
#2: Shipping delay (order #456) — RESOLVED, $20 credit applied
#3: Email update — WAITING, verification email sent
#4: Warranty question — PENDING
=====================每个问题包含：编号、描述、关联标识符、状态和下一步操作。Tracker 的特点：
- 立即初始化 — 客户列出问题时就创建
- 每次操作后更新 — 状态变更反映实时进展
- 与客户确认 — “我看到四个问题。对吗？“
状态生命周期
PENDING → IN_PROGRESS → WAITING（异步）→ RESOLVED
显式状态让问题间的上下文切换变得安全。等待问题 1 的照片上传时，代理可以去处理问题 2 和 3。Tracker 显示哪些问题需要关注，哪些被阻塞。
对暂停/恢复场景，Tracker 随对话状态持久化。客户几小时后回来时，代理准确知道每个问题的进展。
2 个问题的对话也需要跟踪
一位组长提议对 2 个问题的对话跳过 Tracker 以节省 50-100 token。数据不同意：没有跟踪的 2 个问题对话遗漏率为 15%。也就是每 7 次对话就有 1 次遗漏问题。
50-100 token 和遗漏问题的客户影响相比可以忽略不计。结构化跟踪应该应用于所有多问题对话——不只是复杂的那些。
结束对话前的总结
关闭对话前，代理应该总结所有问题的解决情况：
“以下是目前的进展：
- 损坏商品退款 — $49.99 退款已处理，预计 3-5 个工作日到账
- 物流延迟 — $20 积分已加到您的账户
- 邮箱更新 — 验证邮件已发送，请查收
- 保修问题 — 保修到 2026 年 12 月，无需操作”
这个兜底确认确保在对话结束前没有遗漏。
一句话总结： 客户列出问题时立即初始化结构化 Issue Tracker，每次操作后更新，关闭前确认——这把问题遗漏率从 28% 降到 3%，解决吞吐量从 2.1 提升到 3.8 个/次对话。