在 LLM 应用进入生产环境后，调试与维护成为工程师的核心负担。行业调研显示，工程师平均每周有约 30% 的时间用于手动翻阅 traces、猜测失败原因并尝试修复。这种 “滚动 thousands of traces” 的模式不仅效率低下，更难以在复杂的多轮对话或多 Agent 协作场景中定位真正的故障根源。Kelet 作为新近发布的自动化根因分析工具，试图将这一过程从人工猜测转变为系统化的机器调查，其架构设计思路值得深入探讨。

Signal 机制：引导自动化调查的概率线索

Kelet 的核心设计理念是将调试过程抽象为 “侦探调查” 模式。与传统 observability 工具仅展示症状（temperature）不同，Kelet 扮演的是医生角色 —— 不仅报告数据，更主动诊断根因并生成修复方案。在这一过程中，Signal（信号）扮演了关键的引导角色。

Signal 是概率性的线索，而非确定性的判定。它们包括：用户给出的 thumbs-down 评分、用户手动编辑 AI 输出的行为、用户放弃对话的时机、以及通过 LLM-as-judge 合成分数检测到的异常。这些信号本身并不宣判失败，但它们提供了调查方向的起点。Kelet 读取这些线索后，会顺藤摸瓜地追踪对应 session 的完整 trace，交叉比对数千个会话中的模式相似性，从而构建出有证据支撑的根因假设。这种设计避免了传统 RCA 工具 “给出大量数据但缺乏解释” 的通病，让工程师拿到的是 “带着证据的结论” 而非 “一堆待排查的日志”。

错误传播链追踪：从单点到全局的因果推理

多轮对话中的失败往往不是单点故障，而是错误沿对话链传播的结果。一个典型的例子是：RAG 检索阶段返回了低质量上下文，导致 LLM 生成了一开始就错误的回答，后续轮次基于这个错误输出继续推理，最终导致整个对话失控。传统调试工具只能看到每一跳的输入输出，却无法自动串联起这条因果链。

Kelet 在架构层面解决了这一问题。它读取每个 session 的完整 trace—— 包括 LLM 调用、工具执行、检索步骤、以及每一次 Agent 跳转 —— 并在这些数据之上构建因果推理模型。当检测到 Signal 触发的异常时，Kelet 不仅分析当前步骤的问题，还会向前回溯，识别哪一环的输出成为了后续步骤的错误输入。这种自动化追踪能力在多 Agent 协作场景中尤为关键，因为 Chain 中的每个 Agent 可能来自不同团队、使用不同框架，错误传播的路径往往跨越了多个代码仓库和调用边界。

信用分配：多 Agent 架构下的故障归属

现代 LLM 应用越来越多地采用多 Agent 架构 —— 例如 ReAct Agent 搭配多个工具调用 Agent、或者 CrewAI 式的工作流编排。这意味着一次失败可能涉及多个 Agent 的协作，任何一个环节都有可能是根因所在。传统的调试方法要求工程师手动识别 “哪个 Agent 出了问题”，这在复杂工作流中几乎是不可能完成的任务。

Kelet 提供了 Credit Assignment（信用分配）机制来解决这一问题。当检测到失败模式时，系统会分析整个调用链路，量化每个 Agent 对最终失败的贡献度，最终给出 “哪个 Agent 导致了这次失败” 的明确结论。这一机制的实现依赖于两个前提：完整的 trace 捕获（精确到每一次工具调用和中间输出）、以及跨会话的统计模式分析（识别特定 Agent 在类似上下文中反复出现问题的规律）。工程师拿到的不再是 “某处有问题” 的模糊提示，而是精确到 “第几个 Agent 的哪个工具调用是罪魁祸首” 的定位结果。

集成参数与工程化要点

将 Kelet 接入现有 LLM 应用需要关注以下工程化参数。首先是集成方式：Kelet 提供两种接入路径 —— 通过安装包（pip install kelet 或 npm install kelet）在代码中手动添加两行初始化代码，或者使用 Installer Skill 完成零代码接入。两种方式均依赖 OpenTelemetry 标准，任何已完成 OTEL instrument 的 Agent 均可开箱即用，无需改造底层基础设施。官方宣称的接入时间窗口为 5 分钟。

其次是 Signal 配置策略。Kelet 官方建议至少配置 200+ 个有效 session 和 3+ 个 Signal 来源以观察到有统计意义的失败模式。对于早期产品或低流量场景，可以使用预设的 LLM-as-judge 评估器作为合成 Signal，在真实用户反馈积累之前启动自动化调查。Signal 的配置不必一步到位，Kelet 的 AI 会引导用户完成初始设置，并根据实际流量情况建议调整方向。

最后是数据安全与合规。Kelet 运行于自有基础设施之上，采用 SOC 2 认证，数据在数据库层面按组织严格隔离，支持行级安全策略，不会发生跨组织数据泄露。Kelet 明确承诺不会使用用户数据训练公开模型，仅会在用户账户内自动微调一组私有模型（约每个 Agent 对应十几个子模型）用于根因分析，这些模型仅服务于该特定 Agent 的调试需求。

面向生产可靠性的架构选择

Kelet 的出现反映了一个趋势：LLM 应用的可靠性工程正在从 “基础设施监控” 向 “应用层智能诊断” 演进。传统 APM 工具擅长报告延迟、错误率等宏观指标，但在理解 “Agent 为什么在这一轮给出了错误回答” 这类语义层面问题上无能为力。Kelet 的价值在于填补了这一空白 —— 它不替代 observability 工具，而是向上构建了一层智能解释层。

对于正在构建或维护复杂 LLM 应用的团队而言，评估 Kelet 这样的专用 RCA 工具时，应重点关注三个维度：trace 捕获的完整性（是否覆盖了所有 Agent 跳转和工具调用）、Signal 与根因之间的推理透明度（给出的结论是否可追溯、可验证）、以及与现有开发工作流的集成便利性（能否在 CI/CD 流程中嵌入自动化调查能力）。根因分析的本质是将 “未知” 转化为 “已知”，而自动化 RCA Agent 的目标是将这一转化过程本身变为可规模化的工程实践。

资料来源