Tracely

嗨，Product Hunt 👋

我是 Julien，我构建 Tracely 是因为每一个 agent 构建者都深陷其中的一个循环：你的 agent 在生产环境中出问题，你在仪表盘上看到了，你点点头……然后坐下来手动编写一个评估数据集，试图复现生产环境已经免费提供给你的东西。

Tracely 颠覆了这一点。追踪即测试：

🔍 观察 — 一行配置：`tracely.init(instrument="auto")` 自动捕获你的 OpenAI / Anthropic / LangChain / Gemini / Mistral 调用，无需编写 span 代码；手动 API（@observe，以及 agent/tool/llm/retriever/guardrail span）覆盖你自己的逻辑；原始 OTLP 也支持任何语言。其价值在于可读性：追踪以对话形式呈现 —— 轮次 → 步骤 → span 瀑布流，每个节点都带有完整的 I/O。我执着于让它成为该类别中可读性最强的追踪视图。

⚖️ 检测 — 这是 Tracely 钻研最深的部分。评估器是追踪表上的列，而非独立的标签页，它们在每次运行时落地即评分：

• 三个层级：对话级、消息级或步骤级 —— 步骤级 judge 可以精确定位你关心的 span 类型（仅工具调用、仅生成、链、思考）。

• 类型化输出，不仅仅是分数：定义 judge 的输出 schema —— 布尔值、数字、字符串、严格枚举，judge 无法逃逸。像 sycophancy_type: excessive_validation · severity: moderate 这样的判定是可查询的数据，而非散文。

• 串行或批量执行：批量 judge 独立运行；串行 judge 接收前序评估指标的结果作为上下文注入，从而可以串联"工具调用是否成功？"→"答案是否忠实于工具返回内容？"。消息级串行 judge 还能看到对话的滚动摘要（@HISTORY），它随着轮次落地实时构建。

• 内置成本控制：按 agent/env 的逐评估器定位，加上确定性采样，确保同一条追踪始终获得相同的 judge —— 同时建议性评估器记录判定但不翻转 PASS/FAIL 总评，让你在调优期间不影响总体结果。

🧩 分诊 — 失败会聚类为 issue。31 次失败运行 = 一个带有计数的 issue，而非 31 行数据。

🧊 测试 — 一键将失败运行冻结为密封用例：录制的输入、录制的工具/LLM 输出作为 fixture，以及一个 fail-to-pass 契约。

🚫 发布 — `tracely gate` 在每个 PR 上重放测试套件，并拦截重新引入失败的那个 PR。重放基于 fixture 运行，因此模型成本为 $0。还有一种对抗模式：一个红队模型在 CI 中针对你的 agent 在线端点即兴攻防。

它是开源的（MIT 协议） —— 上线数月即收获 370+ GitHub stars —— 一条 `docker compose up` 即可自托管所有功能（SDK 通过 `pip install tracely-ai` 安装）。不想运维基础设施？tracely-studio.xyz 提供带免费计划的托管云服务：多工作空间并支持团队邀请，LLM judge 使用你自己的 OpenRouter API key —— 按工作空间作用域隔离，绝不是共享的服务端 key（更多 provider 接入中）。未配置 key？一切照常运行：结构化检查继续评分，LLM judge 则优雅地自动关闭。

我特别希望听到反馈的两点：judge 校准流程（将 judge 判定与人工审核打标对比，在过度标记的 judge 影响发布前将其捕获）和对抗场景的设计。