Debug и трейсинг

Детальный debug-вид — каждый промпт, вызов тула, MCP-фрейм, параметр модели, счётчик токенов и латентность турна. Это телеметрия, а не источник правды: append-only, write-heavy, высокий объём, читается в основном для отладки и eval'а, с более коротким сроком хранения, чем у чатов.

Правило: трейсы не идут в транзакционный Postgres. Сырые промпты/трейсы раздули бы чат-БД и смешали бы телеметрию с правдой. У них своя система.

То, что есть сегодня, — это не оно

Langfuse не развёрнут, и ничто здесь под него не инструментировано. Промпт хода сегодня можно прочитать в журнале промптов — это таблица, выключенная по умолчанию, включаемая по агенту его владельцем, хранимая семь дней и доступная только администратору платформы в панели. Короткая, всегда включённая запись о том, что агент делал, — это ещё одна, третья вещь. Обе описаны на странице Что агент делал. Всё остальное на этой странице — план.

Рекомендуется: self-hosted Langfuse

Langfuse создан ровно для этого — и даёт debug-UI из коробки:

• Трейсы и сессии — полное дерево турна: промпты, вызовы LLM, вызовы тулов / MCP-трафик, промежуточные шаги, вложенные саб-агенты.
• Промпты, токены, стоимость, латентность на вызов; поиск и фильтр; сравнение прогонов.
• Eval — датасеты, оценки, regression-проверки позже.
• Self-hosted в кластере (Postgres + ClickHouse под высокообъёмное хранилище трейсов).

Мозг (api) инструментирован, чтобы эмитить трейс на турн; tools/call worker'а и результаты прикрепляются как spans. Ничего из этого не живёт в таблице чатов.

Альтернатива (своими руками): писать события трейсов в ClickHouse (или JSONL в объектное хранилище) — дешёвое колоночное хранилище под append-only логи — но тогда UI ты строишь сам. Langfuse выигрывает по debug-опыту.

Хранение и тиры

• Hot в ClickHouse для свежей отладки (дни–недели).
• Cold скатывается в объектное хранилище (или дропается) по retention-политике — трейсы одноразовы в том смысле, в каком чаты — нет.

Что где всплывает

• Эта плоскость трейсов внутренняя (debug/eval), та же control-plane-data, которая никогда не доходит до пользовательского чата — см. Worker → Use про разделение chat-vs-control-plane.
• Турн несёт trace id; Message в чате может хранить этот id, чтобы прыгнуть от сообщения прямо к его полному трейсу.

См. также

• Хранилище — чат как источник записи (свободный от блобов трейсов).
• Worker → Use — MCP-трафик тулов, который становится spans.
• Реализация — подключение инструментирования.