1. AI 系统为什么更难调试

传统应用的调试线索通常比较明确。因为往往是单个请求节点发生故障，所以很容易找到问题所在。这类问题往往：较容易复现、能够追溯、便于验证。当然，有的场景下，我们也会遇到竞态、网络抖动等不稳定因素，但只要拿到错误堆栈、请求参数和依赖状态，通常就能沿着调用链缩小范围

AI Agent 的情况就不同。假设我们收到一条用户反馈：“AI 回复不对，我明明告诉过它我养了一只猫，它却说我没有养宠物。”

表面看是回复内容错了，问题却可能出在整条处理管线的任何一环：

• 记忆写入失败：用户说了“我养了一只猫”，但异步后处理没有把这条事实真正写入数据库
• 记忆召回失败：事实已经写入了，但向量检索的时候没有把它召回来
• 查询理解错误：查询计划解析偏了，导致检索方向不对，根本没有搜索“宠物”相关的记忆
• Prompt 组装遗漏：记忆检索到了，但在拼 Prompt 时因为 token 预算不足被截断了
• 情绪路由偏差：当前使用的回复模板更强调情绪表达，弱化了事实引用
• LLM 幻觉：上下文里明明有“养了一只猫”，但模型生成回复时还是忽略了这个事实

同一个“回复不对”，背后可能对应 6 种完全不同的根因，而且它们分布在处理管线的不同阶段。只看最终回复，很难判断问题究竟发生在哪里。

LLM 的输出还会受到采样参数、模型版本、供应商实现和上下文细节影响，同样的输入再次执行，得到的结果可能并不相同。即使降低 temperature，也不能把整个远程模型调用视为严格确定的函数。用同一条消息重新测试时，AI 这次答对了，并不代表上次答错的原因已经消失。

因此，我们不能把定位问题完全寄托在事后复现上