Tracely
面向 AI Agent 的 trace 原生 CI/CD:把生产失败冻结成可回放的回归测试,并拦下会导致退化的 PR。
- Star 数
- ★ 1.2k
- 最近更新
- 2 天前
- License
- MIT
- 主语言
- Python
- FA 评分
- 66/100 · 存在缺口
30 秒速览
- 可在哪里用
- 通用 · 跨平台Claude Code · OpenAI API · Claude API
- 开始前需要
- 典型场景
- 生产环境的客服 Agent 偶发答错订单查询:用 Tracely 接收 OTLP trace,让 judge 在会话级别打分,把失败聚类成一个 issue,再提升成回归用例防止复发。
- 主要局限
- 本地/自托管栈需要 ClickHouse、Postgres(pgvector)、Redis、MinIO 四套基础设施,运维面明显大于单进程工具
- 源码审查
- 66/100 · 存在缺口
这个 Agent 能做什么,适合哪些场景?
Tracely 是一个可自托管的 AI Agent 可观测与回归测试平台。它通过 OTLP/HTTP 接收任何语言产生的 trace,把 agent.id、conversation.id、turn、step 等语义提升为 ClickHouse 中的一级索引列,从而按会话线程而非扁平 span 展示运行。在线评测器会在 trace 落地时打分,失败再按结构与语义聚类成 issue,而非几百行待读记录。一键即可把失败 trace 冻结为 hermetic 回归用例,附带 fail-to-pass 契约,并在 CI 中以录制好的工具与 LLM fixture 回放——离线、无需 API Key、无模型花费。tracely gate 命令会以非零退出码、提交状态和 PR 评论拦截回归;整个栈由 FastAPI 后端、Celery/Redis worker、Next.js 前端、Postgres、ClickHouse 与 MinIO 组成,可用 Docker Compose、Railway、Coolify 或 EKS 部署。
数据从 SDK 或任意 OTLP/HTTP exporter 进入 POST /v1/traces,先写入 S3/MinIO 保证持久化,再进 Redis/Celery;worker 完成 OTel 映射、注册表 upsert 并写入 ClickHouse 事件表,随后执行 evaluate_run_task 生成分数与结构聚类,触发告警流。评测器是 trace 表上的列,支持无需模型的结构化检查和会话/运行/span 三级的 LLM-as-judge,分数通过 SSE 实时回填。失败聚类后可用一次点击把 trace 提升为回归用例(录制输入、工具与 LLM 输出作为 fixture),并附加 fail-to-pass 契约;多轮行为则用 scenarios(脚本化对话或红队模型追求对抗目标)表达。CI 侧提供 tracely simulate / replay / gate 三个命令与 GitHub Action:gate 失败时非零退出、写入 commit status、更新 PR 评论。告警以触发器加可视化流程表达,步骤包括 condition、Slack、email、webhook、LLM prompt 与 Python 表达式。
- 生产环境的客服 Agent 偶发答错订单查询:用 Tracely 接收 OTLP trace,让 judge 在会话级别打分,把失败聚类成一个 issue,再提升成回归用例防止复发。
- 多 Agent 系统的排障:需要按会话线程查看 agent → thinking → skill → generation → hand-off 的瀑布图,并借助 Fleet 像素视图向非工程同事解释 handoff。
- 把 CI 门禁接进 GitHub Actions:用 tracely gate 在 PR 上拦截会重新引入已知失败模式的改动,并以 commit status 和 PR 评论呈现结果。
- 无法在 CI 中调用真实模型的团队:用 hermetic replay 以录制的 fixture 复现失败输入,做到零 API 成本且完全确定。
- 评测器校准:把 judge 判定与人工复核结果对齐,看每个评测器的一致率,避免过度告警的 judge 进入门禁。
- 自托管合规场景:通过 docker compose --profile demo 或 Railway/Coolify/EKS 部署整套 API、worker、UI 与数据库,数据不出内网。
- 让编码代理直接操作工作区:通过 /mcp 端点让 Claude Code 等客户端读取 trace、创建评测器与告警。
如何安装或部署这个 Agent?
整体栈最快的方式是 Docker Compose,会把 ClickHouse、Postgres、Redis、MinIO、API、worker 和前端一起拉起,并灌入演示数据:
git clone https://github.com/jwuthri-cloud/Tracely-ai && cd Tracely
docker compose --profile demo up -d --build --wait
open http://localhost:3001本地开发需要 uv 与 Node 20+/pnpm:
cp .env.example .env
make infra-up # clickhouse, postgres, redis, minio
make install # uv sync + pnpm install
make migrate # ClickHouse DDL + Alembic (Postgres)
make seed # default project + ingest key → tracely_dev_key采集 SDK:
pip install "tracelyai-sdk[openai]" # 或 [anthropic], [langchain], [all]托管部署可一键上 Railway;Coolify 用户可用 python3 deploy/coolify/setup.py --coolify-url … --app-domain … --api-domain …;Kubernetes 见 deploy/eks/README.md。部署时需设置 SESSION_SECRET 与 SECRETS_ENCRYPTION_KEY(各自 openssl rand -hex 32),AUTH_MODE 默认为 dev(免登录)。
如何使用这个 Agent?
初始化 SDK 后包裹一次运行,provider 调用会被自动捕获:
import tracely_sdk as tracely
tracely.init(
endpoint="http://localhost:8000",
api_key="tracely_dev_key",
service_name="support-agent",
env="prod",
instrument="auto",
)
with tracely.trace(agent="support-agent", conversation="conv-1", user="u_42"):
client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Where is order ORD-4471?"}],
)也可以让任意 OTLP/HTTP exporter 指向 POST {endpoint}/v1/traces,鉴权用 Authorization: Bearer tracely_dev_key。CI 门禁有三种方式,其中让 Tracely 主动调用你的 agent:
- uses: jwuthri-cloud/Tracely-ai/.github/actions/tracely-gate@master
with:
api: https://tracely.your-co.dev
key: ${{ secrets.TRACELY_KEY }}或者对录制的用例做 hermetic 回放:
pip install tracelyai-sdk
tracely replay planner --entrypoint my_pkg.agent:run接入 MCP 让编码代理直接读工作区:
claude mcp add --transport http tracely http://localhost:8000/mcp \
--header "Authorization: Bearer tracely_dev_key"这个 Agent 有哪些优点和局限?
- 测试来源是真生产失败 trace,而非人工编造的数据集,回放保真度是逐字节的原始失败运行
- hermetic replay 使用录制的工具/LLM fixture,CI 中零 API Key、零模型花费且结果确定
- CI 门禁不是仪表盘数字,而是非零退出码、commit status 与 PR 评论,直接阻塞退化 PR
- agent 语义(agent.id、conversation.id、turn、step)在 ClickHouse 中是一级索引列,瀑布图与线程视图开箱可用
- 整套栈可自托管,提供 Docker Compose、Railway、Coolify、EKS 多条部署路径,数据留在自有基础设施
- 后端即 MCP 端点(/mcp),编码代理可用普通 ingest key 创建评测器、用例与告警
- judge 校准页把 judge 判定与人工复核对齐,可在启用门禁前发现过度告警的评测器
- 本地/自托管栈需要 ClickHouse、Postgres(pgvector)、Redis、MinIO 四套基础设施,运维面明显大于单进程工具
- hermetic replay 要求 agent 的工具与模型调用走 SDK 的 call_tool / call_llm 接缝,非 Python 服务回放成本更高
- LLM judge、失败聚类与元分析依赖 OPENROUTER_API_KEY 或工作区自带的 OpenRouter 密钥,缺省时能力降级
- Celery worker 在 Docker 开发模式下不热重载,修改后必须重启容器
- 默认 AUTH_MODE=dev 是免登录状态,正式使用必须切换 local 或 clerk 并配置 SESSION_SECRET
- 告警的 Python 表达式步骤与 webhook 出站存在可信边界问题,README 用 ALLOW_PRIVATE_URLS 控制私网访问,需要自行评估风险
这个 Agent 与同类方案有什么区别?
README 明确把自己与两类方案对比:一是只停在仪表盘的可观测工具(能看到 agent 坏了,但没有下一步);二是 dataset-first 的评测工具(要求人工编写问题与理想答案,天然是对可能失败的猜测)。README 还说明写入路径参照 Langfuse 的成熟设计并用 Python 重写,但把 agent 语义从读时字符串提升为一级索引列。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Tracely 当前 | 66 · 存在缺口 | — | ★ 1.2k | 2 天前 | Python | Claude Code · OpenAI API · Claude API |
| Kitaru | 56 · 缺口较多 | 命令行工具免费版 + 付费版 | ★ 316 | 1 天前 | Python | Codex · Claude Code |
| LangWatch | 78 · 表现良好 | 命令行工具免费版 + 付费版 | ★ 5k | 1 天前 | TypeScript | OpenAI API · Claude API |
| Coder Eval | 86 · 表现良好 | 命令行工具免费 + 模型费 | ★ 156 | 5 天前 | Python | Codex · Claude Code · OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent?
查看各维度的扣分理由
证据显示:CI 工作流权限最小化(contents: read,发布用 OIDC Trusted Publishing 无长期令牌);告警 webhook 在请求前再次校验 assert_public_url 阻断内网/元数据地址;Python 表达式步骤用 simpleeval 拒绝 __import__;测试 conftest 硬关真实密钥、Stripe、PostHog、OpenRouter 等外部副作用,体现敏感数据与外部效应意识;SECURITY.md 明确跨租户、注入、密钥泄露范围。扣分:用户确认机制薄弱(告警/助手/门禁可自动产生外部副作用,未见显式确认流程);回滚仅提及 docker compose down -v 与 purge,缺少数据/配置回滚细节;依赖审计为 continue-on-error 仅提示不阻断。
证据显示:CI 用 uv sync --frozen 锁定依赖并跑 ruff+pytest、前端 build、双镜像构建;发布前校验 tag 与 pyproject 版本一致并冒烟测试构建产物;告警引擎对环、孤儿节点、模板错误给出可读错误而非崩溃。扣分:依赖可用性依赖外部服务(ClickHouse/Postgres/Redis/MinIO/OpenRouter/字体 CDN),next build 需重试规避网络抖动;失败信息虽清晰但多为测试断言层面,未见运行时统一错误契约。
证据显示:README 覆盖多语言 OTLP、三种门禁接入方式(Tracely 调 agent / 门禁 CI 轨迹 / 离线回放)、多部署目标(Railway/Coolify/EKS/自建)、多认证模式;场景与能力边界描述较全。扣分:触发精度依赖 env=ci 与 agent 命名约定,存在误配空间;环境适配虽广但多为文档声明,缺少对边界条件的系统化说明。
证据显示:README 信息架构清晰(Why/loop/box/quickstart/gate/alerts/MCP),安装步骤详尽含端口与 make 目标,MIT LICENSE 完整,SECURITY.md 规范。扣分:无 CHANGELOG/版本历史(仅 sdk-v* tag 约定);已知限制分散在正文而非集中章节;维护责任仅指向单一作者与 master 最新版,无治理/维护者说明;命名稳定性有 tenant/agent 语义区分但存在历史漂移迹象(测试注释提到曾有两种形状)。
证据显示:输出可用性强(门禁非零退出、commit status、PR 评论、告警多通道),离线回放零成本是明确卖点,边际价值(生产轨迹转回归测试)有说服力。扣分:成本收益多为 README 自述,缺少量化基准;离线回放要求 agent 走 SDK 的 call_tool/call_llm 接缝,适用面受限。
证据显示:测试文件对告警 DAG、模板命名空间、webhook 头/体渲染、SSRF 校验、Python 表达式沙箱等有具体断言,claim 与代码可对应;ingest 派生来源打 tracely.io_source 标记,事实与推断有区分。扣分:README 大量产品能力(聚类、校准、趋势、助手)仅链接外部文档,仓库内缺少对应实现证据;跨源佐证有限,多为单一 README 声明。
- 告警、助手与门禁可自动触发外部副作用(Slack/邮件/webhook/LLM 调用),未见显式用户确认流程,建议在生产启用前人工复核规则。
- 依赖审计(pip-audit/pnpm audit)为 continue-on-error,不阻断 PR,已知漏洞可能被合入。
- 离线回放要求 agent 走 SDK 的 call_tool/call_llm 接缝,未改造的 agent 无法获得零成本确定性回放。
- 发布者身份未经 FollowAgents 企业注册表验证,维护责任集中于单一作者,长期维护与更新路径不确定。
- 无 CHANGELOG,版本演进与破坏性变更缺乏集中记录。
常见问题
使用 Tracely 会不会产生模型调用费用?
我的 agent 不是 Python 写的,还能接入吗?
tracely replay planner --cmd "node run.js" 走任意语言入口,但 hermetic 回放要求工具/模型调用经过 SDK 的 call_tool / call_llm 接缝。