AI Agent 线上失败却没有告警？Tessary 用全量 Trace 做可靠性排查
AI Agent 上线后，最危险的故障往往不是服务直接崩溃，而是它“看起来能跑”：请求返回了 200，日志也没有明显异常，但回答没有根据、工具调用走偏，或者用户已经开始反复追问。只抽样一小部分会话，很容易把这些问题漏掉。Tessary 是一个面向生产 Agent 的开源可靠性平台，思路是接收每一次执行的 trace，用低成本分类器持续发现问题，再把相关发现归并成 case，最后结合 trace 和代码做根因分析。
从全量观察开始，而不是先做排行榜
Tessary 的 README 把它定位为“停止让 Agent 在生产环境中静默失败”。它通过 OpenTelemetry OTLP HTTP/gRPC 和 SDK 接收 trace，并在入口处按 gen_ai.* 约定做规范化。个人信息会在写入存储前进行脱敏，这一点对真实用户会话尤其重要。
它不是给模型打一个总分的 leaderboard。工作流更接近线上故障处理：先看已有证据，再筛选异常，接着把相关异常聚合起来，最后交给人处理。系统默认用较便宜的分类器扫描每条 trace，使“看全量”成为可行目标，而不是只看随机样本。
Finding、Case 与 RCA 各自负责什么
一条 trace 命中分类器后会产生 finding，但 finding 不一定就是故障。Tessary 会把相关 finding 合并到 Triage 页面中的 case，并通过一次模型辅助的 triage 判断它究竟是真偏差还是合法变化。只有被判断为真实偏差的 finding 才会进入 case。
随后，RCA 会围绕失败 trace 启动 Agent 会话。如果连接了 GitHub 仓库，它还会读取相关代码，把原因和证据关联起来，返回一句话摘要、每个原因背后的 trace，以及已经排除的检查项。最后由告警把 case 交给负责人；它负责解释和交接，不会替你直接修改代码。
这个分层很适合排查 Agent 的特殊问题：模型调用错误、工具结果不符合预期、检索内容不足、用户情绪恶化，处理方式并不相同。平台文档还列出了 frustration 和 groundedness 等可选分类器；它们需要额外的模型或本地推理资源，不能把这些能力误解成所有部署都自动启用。
快速自托管：先把链路跑通
项目采用 Apache-2.0 许可证，README 提供了 Docker Compose 的一条命令启动方式：
docker compose -f oci://docker.io/tessaryai/tessary:compose up -d -y
官方说明要求 Docker Engine 26 或更高版本，以及 Docker Compose v2.34 或更高版本。启动后，当 docker compose -p tessary ps 显示服务健康，可以打开 http://localhost。这比先读完整部署手册更适合做一次隔离实验，但生产环境仍应按官方 setup 文档检查持久化存储、网络和凭据。
接下来要让 Agent 真正产生可观察数据：把应用的 OTLP trace 发到安装时显示的端点，并在调用模型的 span 上添加 tessary.call_site.id。如果还要做代码级根因分析，再在 Tessary 的 Settings 中连接 GitHub 仓库。
一个值得先做的实验
不要一开始就接入所有会话。可以准备一个简单的问答或工具调用服务，先发送一条正常 trace，再制造三类可重复样本：模型回答与检索文档不一致、工具返回错误、用户连续表达不满。观察它们是否进入 finding，相关 finding 是否被合并为同一个 case，以及 RCA 是否能引用对应 trace。
还要特别核对隐私边界。自托管实例默认会向 home.tessary.ai 发送匿名 heartbeat；README 明确说明其中不包含 trace、prompt、邮箱、组织名、主机名或保留的 IP。如果团队政策不允许外连，可以在 .env 中设置：
TESSARY_TELEMETRY_ENABLED=false
这个设置会让实例不再调用该主机，并且不影响功能或许可证检查。上线前应把这项配置和 OTLP 端点、GitHub 权限一起纳入审计。
我的判断
Tessary 的价值不只是多一个 Agent 仪表盘，而是把“线上偶发失败”变成一条可追踪的证据链：全量 trace 负责留下事实，分类器负责低成本筛选，case 负责减少重复调查，RCA 再把运行证据连接到代码。它不会替团队定义什么是好回答，也不会自动修复问题；真正可靠的评估仍需要领域专家和可复现的回归检查。
如果你的 Agent 已经进入生产、但目前只能依赖抽样日志和用户投诉，Tessary 值得用一个小服务做试点。先验证 trace 是否完整、脱敏是否符合要求、分类器是否能抓到真实失败，再决定是否把它扩展到更多项目。