原站网页截图，页面可能随时间更新。
Tracely-ai 面向需要持续监控和测试 AI Agent 的开发团队。它以生产运行产生的 trace 为起点，对结果进行评估，定位重复出现的问题，并把问题运行转化为 CI 中可执行的回归用例，从而让线上故障能够参与后续代码变更的质量检查。
用途与工作方式
Tracely-ai 的核心用途是把 AI Agent 的生产观测与持续集成连接起来。每次 Agent 运行产生的 trace 可以进入系统，随后接受结构化评估或 LLM-as-judge 评估。评估失败的运行会被归入问题集群，用户可以将其中的失败 trace 冻结为测试案例，再由 CI 在每次 Pull Request 中重放这些案例。
这种流程覆盖追踪、检测、冻结和门禁四个阶段。评估结果、故障集群、测试案例和 PR 门禁都从同一条 trace 推导，因此生产运行中的问题可以转化为后续发布时可检查的回归条件。
适用场景
它适合已经运行 AI Agent、需要观察多轮对话、工具调用、检索过程或 Agent 协作过程的团队。支持的接入对象包括 OpenAI、Anthropic、Google Gemini、LangChain、LangGraph、LiteLLM、CrewAI、Mistral，以及其他可提供 OTLP 数据的来源。
当线上出现工具超时、回答未引用依据、内容不符合规则或其他可重复问题时，可以从相关 trace 中查看失败位置，将其聚类为问题，并建立针对该问题的评估。对于需要在代码合并前检查 Agent 行为的项目，CI gate 可以在回归发生时返回失败状态，并在提交状态和 Pull Request 评论中给出结果。
准备与上手
使用前需要准备一个 Agent 运行环境，以及 Tracely 的部署端点和访问密钥。项目支持自托管，也提供托管方式。自托管产品采用 MIT 许可证，可在自己的基础设施上运行；官网列出了 Railway 一键部署和 Docker Compose 方式。
接入 SDK 后，通过初始化配置端点、密钥、服务名称和环境，即可启用自动埋点。自动埋点可以记录 Agent、conversation 和 turn 等信息，并覆盖模型调用、工具、检索、思考 span 以及多轮对话；需要更细控制时仍可使用手动上下文管理器。
开始 CI 检查时，需要在已有的工作流中运行 Agent，并加入 Tracely gate。被提升为测试案例的运行会使用已记录的工具和 LLM fixture 进行离线重放，因此不需要在重放阶段调用真实模型。
主要功能
系统可在 trace 到达时执行评估，并把每个评估器作为 trace 表中的一列展示。评估可以在对话、运行或 span 层级进行；结构化评估可直接运行，LLM 评估则使用配置的模型密钥。失败 trace 支持结构化和语义聚类，形成带有描述、建议修复方向和建议评估器的问题集群。
冻结案例时，系统会打包记录的输入、工具 fixture 和 LLM fixture，并附带从失败到通过的契约。CI 重放这些案例后，门禁会以非零状态结束失败任务，并发布提交状态和 PR 评论。系统还提供失败率与门禁通过率趋势、Agent 间的交叉指标分析，以及将人工评审结果用于评估器校准的能力。
Tracely 部署还可作为 MCP 服务器使用。连接 Claude Code 或 Cursor 后，可以读取失败 trace、查看问题集群、创建评估器并查看趋势与成本。官网同时提供一个技能包，用于帮助编码代理了解自动或手动追踪、评估器设计和 CI 门禁等使用约定。
限制与注意事项
离线 hermetic replay 依赖已记录的工具和 LLM fixture；它的特点是无需 API key、模型调用费用和不稳定的实时调用。如果需要真实调用，系统支持使用 live 模式，但这不再是完全离线的重放。
LLM 评估需要配置自己的 OpenRouter 模型密钥，密钥按工作区使用并加密保存。未配置该密钥时，结构化评估仍可运行，LLM 评估会关闭。自托管需要自行承担基础设施和 ClickHouse 的运行工作；托管方案则按官网所列的追踪数量、保留期限、Agent、工作区和席位范围提供服务。
项目的 GitHub Releases 页面当前没有发布版本记录，因此使用时主要依赖仓库和文档中的安装、部署与接入方式。
未配置 LLM 模型密钥还能进行评估吗？
可以。结构化评估仍会对每次运行进行评估，但依赖 LLM 的评估器会关闭。
冻结的测试案例会在 CI 中调用真实模型吗？
默认不会。案例使用记录的工具和 LLM fixture 进行离线、确定性的重放；需要真实调用时可以使用 live 模式。