TGViewer
Channel Public Channel
annFlow

annFlow

@annsflow

Automation • LLM agents • second brain • integrations • pipelines • bots • chat funnels • lead generation • CRM • ops/operations • websites •SEO•VPS• VPN • time tracking/timing•logging•metrics @arsenynn

Portfolio: https://portfolio.arsenynn.quest/it-ai/
Subscribers
33
Photos
30
Videos
10
Links
89
Recent Posts 20 shown
Post #189 16
LiveContext в реальном разговоре.

На видео я разбираюсь с претензией по недоставленному заказу.

LiveContext анализирует разговор в реальном времени и сразу передает его в модель вместе с актуальным контекстом проекта из Obsidian.

Поэтому модель уже знает номер заказа, претензии, сроки и историю обращений, пока разговор еще идет

#LiveContext@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
Post #188 20
Как LiveContext разделяет мой голос и голос собеседника

Чтобы LiveContext мог понимать разговор, сначала нужно решить довольно базовую проблему: кто именно сейчас говорит?

Можно было бы записывать весь звонок одним аудиопотоком, а потом пытаться программно определять, где мой голос, а где собеседник.

В LiveContext я пошёл другим путем: разделяю голоса ещё до транскрибации.

Получается два независимых источника:

мой микрофон → YOU

звук звонка → REMOTE


YOU приходит напрямую с физического микрофона: AirPods или USB-микрофона.

С REMOTE интереснее. Звук приложения, например Телемоста или браузера, попадает в отдельное виртуальное аудиоустройство LiveContext Remote, которое я собрал через Loopback.

То есть компьютер фактически получает две разные аудиодорожки:


микрофон ─────────────→ YOU

→ LiveContext
/
Телемост / браузер ─────→ REMOTE


У каждого потока своя обработка, свои параметры определения речи и своя очередь. И только после этого звук отправляется в локальную транскрибацию.

В результате LiveContext не приходится угадывать, кому принадлежит очередная фраза.

Он знает это из самого источника звука.

Это небольшое архитектурное решение оказалось важным для всего, что строится дальше. Потому что для системы есть большая разница между:

«клиент сказал, что цена высокая»

и

«я сказал клиенту, что цена высокая».

Текст почти одинаковый. Состояние разговора совершенно разное.

А дальше начинается более сложная часть: как превратить эти два непрерывных потока звука в достаточно быструю и точную локальную транскрибацию, не положив при этом весь компьютер.

#LiveContext@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
Telegram annFlow Как я построил LiveContext, или Как связать живой разговор с памятью проекта ● Почему мне оказалось недостаточно просто сохранять разговоры ● Как LiveContext разделяет мой голос и голос собеседника ● Почему Whisper оказался далеко не самой сложной частью…
  • 👍 2
Post #187 24
Почему мне оказалось недостаточно просто сохранять разговоры

В VoxBase я решал проблему того, что происходит после разговора.

Запись превращается в текст, текст сохраняется в Markdown, важная информация остаётся в памяти проекта. К разговору можно вернуться через день или месяц и не пытаться восстановить его по памяти.

Но довольно быстро обнаружилась другая проблема.

Иногда контекст нужен не после звонка. Он нужен прямо сейчас.

Во время разговора человек может спросить о том, что обсуждалось неделю назад. Может появиться новое возражение, измениться тема или понадобиться конкретный факт из проекта.

И нужная информация при этом уже существует: лежит в Obsidian, документах, правилах проекта, прошлых разговорах.

Проблема только в том, что искать её вручную, пока собеседник ждёт ответа, почти бессмысленно.

Так появился LiveContext.

Его задача шире обычной транскрибации. Система должна получать разговор практически в реальном времени, понимать, что происходит сейчас, и связывать происходящее с контекстом конкретного проекта.

Условно:


разговор
↓
транскрибация
↓
текущее состояние разговора
↓
контекст проекта
↓
нужная информация


То есть VoxBase сохраняет разговор в память.

А LiveContext пытается сделать так, чтобы эта память могла работать еще до того, как разговор закончился

В следующих постах разберу, как я это собираю: от двух независимых аудиопотоков и локальной транскрибации до Obsidian и поиска нужного контекста во время звонка.

#LiveContext@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
  • 🔥 1
Post #186 28
Как я построил LiveContext, или Как связать живой разговор с памятью проекта

● Почему мне оказалось недостаточно просто сохранять разговоры
● Как LiveContext разделяет мой голос и голос собеседника
● LiveContext в реальном разговоре 📺
●
Почему Whisper оказался далеко не самой сложной частью
● Разговор — это не transcript. Это состояние
● Как LiveContext понимает, какой контекст нужен прямо сейчас
● Как я превратил Obsidian из архива в оперативную память
● Почему я не даю LLM искать по всей базе знаний
● Как одна реплика превращается в нужную информацию из Obsidian
● Почему память не должна автоматически переписывать саму себя

#LiveContext@annsFlow

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
Post #184 33
Самая неожиданная вакансия, которую нашел мой бот

Моя система постоянно сама ищет вакансии, сопоставляет их с моим профилем и откликается.

В этот раз она откликнулась на вакансию, где нужно предлагать людям контракт на военную службу. Оплата менеджеру 20–50 т.р. за каждый подписанный контракт.

На видео - звонок после этого автоотклика.

А о том, как система вообще дошла до этого звонка, рассказываю в серии про мой проект автоматизации поиска работы ◀️

#HHApply@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
  • 👀 1
Post #181 25
Without Streaming перестал быть плеером и стал радиостанцией

Когда я писал первые посты про Without Streaming, слово «радио» было скорее формой описания.

Тогда каждый человек фактически запускал свой собственный плеер. Браузер получал плейлист из Telegram, сам выбирал последовательность треков, управлял переходами, а две ручки Jazz ⇄ Hip-hop и Drifting ⇄ Driving позволяли каждому собирать собственную версию потока.

Это работало, но у настоящего радио есть одно фундаментальное свойство: в каждый момент времени существует один эфир для всех.

Именно это я в итоге полностью перестроил.

Теперь человек, который открывает Without Streaming, не получает собственную очередь и не начинает трек сначала. Он подключается к тому месту, которое прямо сейчас звучит в эфире.

Внутри архитектура теперь выглядит примерно так:

Telegram
↓
локальная медиатека
↓
Python
↓
Liquidsoap
↓
AAC-LC
↓
HLS
↓
Caddy
↓
один общий live-эфир

Если совсем простыми словами:

Liquidsoap — это радиодвижок. Он непрерывно воспроизводит выбранные треки, делает переходы между ними и формирует тот самый сигнал, который в этот момент действительно находится в эфире.

AAC-LC — аудиокодек: он сжимает этот сигнал в формат, который можно достаточно экономно передавать слушателям через интернет.

HLS — способ доставки live-потока. Вместо одного бесконечного соединения эфир постоянно нарезается на короткие сегменты, а браузер последовательно забирает их и поэтому может подключиться к текущему моменту трансляции.

Caddy — веб-сервер на выходе этой цепочки. Он раздаёт слушателям HLS, сайт и остальные публичные файлы.

Самое важное изменение здесь связано даже не с Liquidsoap или HLS, а с разделением ответственности.

Python решает, что должно прозвучать дальше.

Liquidsoap является фактической точкой эфира.

Браузер больше ничего не программирует, он только слушает.

Раньше трек во время Play запрашивался непосредственно из Telegram и потоково отдавался браузеру. Сейчас вся пригодная медиатека зеркалируется локально и может продолжать играть независимо от доступности Telegram.

То есть Telegram постепенно превратился из:

CMS + файлового сервера + runtime-зависимости

в:

CMS + источник публикации и происхождения материала.

Изменился и сам клиент.

Вместо браузерного аудиодвижка сейчас используется один постоянный <audio>, подключённый к HLS.

Play теперь после паузы возвращает слушателя не к старой позиции, а обратно в текущий эфир.

Визуалы существуют отдельно от музыкальной программы. Они локально подготовлены, раздаются как статические MP4 и вращаются независимо у каждого слушателя.

Старые Jazz / Hip-hop и Drifting / Driving ручки поэтому исчезли из интерфейса не случайно. Их идея не отброшена, но управление музыкальной логикой постепенно переезжает туда, где ему теперь правильнее находиться: в серверное программирование общего эфира, а не в персональный плеер каждого слушателя.

Параллельно у радио появился отдельный operational layer. Теперь я вижу, сколько людей находится на сайте, сколько реально слушает HLS, дневное количество listening sessions и peak.

Сейчас следующий этап для меня уже не про новые кнопки. Я довожу систему до состояния, где она самостоятельно восстанавливается после падений процессов, потери сети и reboot, затем измерю реальную пропускную способность домашнего сервера и только после этого продолжу строить Programming Engine.

И дальше начинается, пожалуй, самая интересная часть развития Without Streaming. Музыкальная программа постепенно станет намного сложнее, а в самом эфире появятся вещи, которых раньше в проекте вообще не было. Но про это уже отдельно.

Получился немного парадоксальный результат: чем сложнее Without Streaming становится внутри, тем меньше действий остаётся у слушателя снаружи :)

😎 Запустить Without Streaming 👈👈

#WithoutStreaming@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
Telegram annFlow Without Streaming: Telegram-канал как радиостанция ● Радио из Telegram в один клик ● Две ручки настроения: стиль и энергия ● Как это работает внутри: индексатор → плейлист → стрим ● Инженерная реальность: плеер, фон и PWA ● Without Streaming перестал…
Post #179 18
Post #178 20
Где заканчивается MCP и что будет дальше

Сейчас Obsidian MCP является рабочей частью моей системы.

Через него языковая модель может искать информацию в Obsidian, открывать заметки, собирать контекст проекта и работать с файлами.

Именно эту задачу я изначально хотел решить.


Но по мере использования стала видна следующая граница.

MCP хорошо решает задачу доступа.

Модель получает набор инструментов и сама решает, что искать, какие заметки открывать и какой контекст собирать.

Но если смотреть дальше, мне нужна уже не просто возможность обратиться к файлам.

Мне нужна отдельная система, которая сама понимает устройство моей проектной памяти.

Поэтому следующим этапом стал Obsidian Knowledge Agent.

Сейчас этот проект находится в активной разработке.

Если очень сильно упростить разницу, то MCP выглядит примерно так:

LLM обращается к Obsidian через инструменты и сама собирает нужный контекст.

Knowledge Agent должен работать иначе.

У него появляется собственный слой поиска и индексации, понимание структуры проектов, связей между файлами и Canvas, правил источников и границ проекта.

То есть перед моделью будет находиться отдельная система, которая сначала определяет, где искать, что относится к вопросу и какой контекст действительно нужно передать дальше.

Меняется и работа с изменениями.

В MCP доступ к заметке и возможность её изменить находятся довольно близко друг к другу.

В Knowledge Agent чтение, рассуждение и изменение состояния разделяются.

Найти информацию можно одним контуром.

Предложить изменение другим.

А реально изменить проект только через отдельный контролируемый механизм с правилами безопасности.

В результате меняется сама роль MCP.

Он не исчезает.

Но из центра архитектуры превращается в один из способов подключения к системе.

Если текущую архитектуру можно описать так:

LLM → MCP → Obsidian

то следующая постепенно становится такой:

LLM → Knowledge Agent → проектная память

Где под проектной памятью находятся уже не только Markdown-файлы, но структура проектов, Canvas, связанные источники, собственный индекс и правила работы со всем этим.

Часть этой архитектуры уже реализована, часть ещё строится.

Поэтому подробно расскажу про Obsidian Knowledge Agent позже.

А эту серию на этом можно закончить.

MCP стал первым рабочим мостом между LLM и моей памятью.

Следующий этап заключается уже не в том, чтобы дать модели доступ к знаниям.

А в том, чтобы построить систему, которая умеет с этими знаниями работать.

#ObsidianMCP@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
Telegram annFlow Как я построил MCP-сервер для своей рабочей системы ● Почему я разделил память и выполнение ● Как LLM получила доступ к моему Obsidian ● Что на самом деле происходит, когда LLM ищет что-то в моей памяти ● Как LLM добирается до локального Obsidian на…
  • 🔥 1
Post #176 21
Как LLM добирается до локального Obsidian на моём Mac

Obsidian, vault и MCP-сервер работают локально на моём Mac.

Чтобы внешняя LLM могла обращаться к этой памяти, нужен отдельный транспортный слой.

Текущая схема выглядит так:

LLM / MCP-клиент

Cloudflare

VPS

reverse SSH

MCP server на Mac

Obsidian Local REST API

Obsidian vault

Публичной точкой входа служит отдельный MCP endpoint.

Cloudflare принимает запрос и передаёт его на VPS, где cloudflared направляет трафик на:

127.0.0.1:3011

Но самого MCP-сервера на VPS нет.

Порт 3011 создаётся reverse SSH-туннелем, который мой Mac поднимает самостоятельно.

Ключевой фрагмент:

-R 127.0.0.1:3011:127.0.0.1:3010

То есть всё, что приходит на 3011 внутри VPS, через SSH отправляется на локальный MCP-порт 3010 моего Mac.

Дальше запрос уже идёт внутри локальной системы:

MCP server

Obsidian Local REST API

vault

В этой архитектуре VPS остаётся только транспортным слоем.

Он не хранит vault, не индексирует заметки и не становится второй копией проектной памяти.

Даже порт 3011 доступен только внутри VPS.

Сам Obsidian остаётся локальным.

Для устойчивой работы MCP server и reverse SSH запускаются через отдельные LaunchAgent, а autossh автоматически восстанавливает туннель после обрывов.

В результате внешняя модель получает доступ к проектной памяти без переноса самой памяти в облако.

#ObsidianMCP@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все каналы 🎶

💻 annFlow
Telegram annFlow Как я построил MCP-сервер для своей рабочей системы ● Почему я разделил память и выполнение ● Как LLM получила доступ к моему Obsidian ● Что на самом деле происходит, когда LLM ищет что-то в моей памяти ● Как LLM добирается до локального Obsidian на…
  • 👍 1
  • 🐳 1
Post #175 24
Что происходит, когда LLM ищет что-то в моей памяти

В прошлом посте я рассказал, что MCP даёт языковой модели доступ к Obsidian.

Но сам доступ ещё не означает, что модель получает весь vault целиком.

Когда я задаю вопрос о проекте, система работает иначе.

Сначала LLM решает, какой инструмент ей нужен.

Например, если нужно понять текущее состояние проекта, она может сначала выполнить поиск по нужной области Obsidian.

После этого MCP возвращает не весь проект, а список подходящих файлов и фрагментов.

И только затем модель открывает те документы, которые действительно нужны для ответа.

Упрощённо получается такая цепочка:

вопрос

поиск по проекту

найденные файлы

чтение нужных документов

сбор контекста

ответ

Для меня это принципиальная часть архитектуры.

Если в vault находятся сотни проектов и тысячи файлов, передавать их модели целиком бессмысленно.

Большая часть информации не относится к текущему вопросу и только увеличивает шум.

Поэтому модель перемещается по памяти постепенно.

Например, реальный search-first протокол внутри моего MCP-контура выглядит примерно так:

searchInPath: Projects/Systems/PRJ-002 Network

query: internet OR VPN OR DNS OR MacStudio OR "Mac Studio" OR "MacBook Air" OR route OR routing OR split

Сначала задаётся область поиска.

Затем одним запросом система пытается получить достаточно широкий набор кандидатов.

После этого читаются только наиболее релевантные файлы.

Такой подход появился не только ради экономии контекста.

В какой-то момент я столкнулся с rate limit Obsidian MCP.

Если модель начинает перебирать предполагаемые названия файлов и делать много последовательных запросов, сервер может вернуть 429 и временно остановить дальнейший доступ.

Поэтому внутри проекта появился отдельный принцип:

сначала поиск, потом чтение.

Не угадывать файлы один за другим.

Не читать весь проект заранее.

Не продолжать запросы после 429.

Найти область, сделать один широкий поиск и уже из результата выбирать источники.

Технически сам MCP-клиент тоже работает через последовательность отдельных операций.

Сначала создаётся MCP-сессия.

Затем клиент получает список доступных инструментов.

После этого модель может вызывать конкретный инструмент и передавать ему параметры.

Упрощённо:

initialize

mcp-session-id

tools/list

tools/call

То есть MCP не является каналом, через который в LLM постоянно течёт весь Obsidian.

Это скорее набор дверей в проектную память.

Модель сама решает, какую дверь открыть, получает небольшой участок информации и при необходимости идёт дальше.

Именно поэтому для меня этот подход оказался удобнее ручной загрузки документов в диалог.

Я могу спросить о проекте, которым не занимался несколько недель, а модель сама найти его текущее состояние, прочитать нужные источники и восстановить контекст из реальных файлов.

Но пока мы говорили только о логике доступа.

Есть ещё один вопрос: как удалённая LLM вообще вызывает MCP-сервер, который физически работает на моём Mac?

В следующем посте разберу весь путь запроса от внешней модели до локального Obsidian.

#ObsidianMCP@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все проекты 🎶

💻 annFlow
Telegram annFlow Как я построил MCP-сервер для своей рабочей системы ● Почему я разделил память и выполнение ● Как LLM получила доступ к моему Obsidian ● Что на самом деле происходит, когда LLM ищет что-то в моей памяти ● Как LLM добирается до локального Obsidian на…
  • ❤ 3
  • 👀 1
Post #174 24
Как LLM получила доступ к моему Obsidian

После того как я разделил проектную память и выполнение, появилась следующая проблема.

В Obsidian уже находилась вся нужная информация о проектах: архитектура, планы реализации, технические паспорта, история решений, Canvas и связанные документы.

Но языковая модель эту память не видела.

Пока я сам не вставил нужный файл в диалог, для модели его фактически не существовало.

Можно было каждый раз вручную искать implementation_plan.md, копировать нужные заметки, добавлять связанные документы и объяснять, где сейчас находится проект.

Но тогда сама идея проектной памяти теряет значительную часть смысла.

Мне нужен был доступ к реальному Obsidian, а не очередная копия его содержимого внутри чата.

Так в системе появился MCP.

В моём случае MCP-сервер работает как интерфейс между языковой моделью и Obsidian.

Он даёт модели набор конкретных инструментов: посмотреть структуру проекта, найти заметку, выполнить поиск по vault, прочитать файл или изменить обычную заметку по прямому запросу.

При этом весь Obsidian не загружается в модель целиком.

LLM получает только инструменты, через которые может сама добраться до нужной информации.

Например, если я спрашиваю, что сейчас происходит в конкретном проекте, модели не нужно заранее передавать весь проект.

Она может найти его, открыть implementation_plan.md, при необходимости обратиться к decisions_log.md или другим связанным документам и только после этого сформировать ответ.

Технически между моделью и файлами находится ещё один слой.

MCP-сервер обращается к Obsidian через Local REST API, а уже Obsidian работает с реальным vault на моём Mac.

Получается такая цепочка:

LLM

MCP server

Obsidian Local REST API

Obsidian vault

Для меня здесь важен сам принцип.

Проектная память остаётся в файлах и продолжает быть source of truth.

LLM не хранит отдельную копию состояния проекта и не требует, чтобы я каждый раз вручную собирал для неё контекст.

Она получает возможность обратиться к памяти тогда, когда эта память действительно нужна.

Именно после этого Obsidian для меня окончательно перестал быть просто местом, где лежат заметки.

Он стал рабочей памятью, к которой можно подключать языковые модели и другие инструменты через формальный интерфейс.

Сейчас этот MCP-контур остаётся моим основным способом доступа LLM к Obsidian.

Но сам вызов инструмента скрывает довольно много интересной механики.

В следующем посте разберу, что на самом деле происходит, когда LLM ищет что-то в моей памяти: как она выбирает инструмент, как запрос проходит через MCP и почему модель не получает весь vault одним большим контекстом.

#ObsidianMCP@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все проекты 🎶

💻 annFlow
Telegram annFlow Как я построил MCP-сервер для своей рабочей системы ● Почему я разделил память и выполнение ● Как LLM получила доступ к моему Obsidian ● Что на самом деле происходит, когда LLM ищет что-то в моей памяти ● Как LLM добирается до локального Obsidian на…
  • ❤ 1
  • 🐳 1
Post #173 24
Почему я разделил память и выполнение

В какой-то момент количество информации, с которой я работаю, стало слишком большим.

Проекты, технические решения, задачи, схемы, заметки, промежуточные выводы.

Пока проект активен, кажется, что вся его логика находится в голове. Но стоит переключиться на другую работу и вернуться через несколько недель, часть контекста приходится восстанавливать заново.

Мне нужна была система, которая хранит не просто заметки, а состояние проекта.

Одним из первых подходов был Apple Freeform. Мне сразу подошла сама идея Canvas: раскладывать информацию пространственно, видеть связи и собирать проект не только линейным текстом.

Но довольно быстро стало понятно, что одного холста недостаточно.

Мне нужны были обычные файлы, Markdown, понятная структура каталогов, Canvas, API и возможность строить поверх всего этого собственные правила.

Так основной памятью стал Obsidian.

Но почти сразу появилась другая проблема.

В Obsidian удобно хранить архитектуру проекта, технические решения, документацию, причины изменений, планы и историю.

Но ежедневное выполнение задач удобнее держать отдельно.

Для этого у меня остался Todoist.

Сначала естественной казалась идея максимально связать две системы между собой: изменения в Obsidian отражаются в Todoist, изменения в Todoist возвращаются обратно.

На практике такая симметрия быстро создаёт новые проблемы.

Кто главный, если данные расходятся?

Что считать актуальным состоянием проекта?

Нужно ли изменение задачи переписывать обратно в документацию?

В итоге я пришёл к более простой архитектуре.

Obsidian хранит память.

Todoist управляет выполнением.

Подробное состояние проекта живёт в файлах. Например, текущий план находится в implementation_plan.md, а история важных решений сохраняется в decisions_log.md.

Todoist не пытается стать второй копией этой памяти. Он показывает то, что нужно сделать сейчас.

Из этого постепенно появилось одно из главных правил всей моей системы.

Один факт = один владелец.

Если это проектное решение, оно принадлежит проектной памяти.

Если это действие, которое нужно выполнить, оно принадлежит execution-слою.

Связь между ними остаётся, но они больше не пытаются быть зеркалами друг друга.

И здесь появился следующий вопрос.

Если реальная память проекта находится в Obsidian, как дать языковой модели доступ именно к ней, а не каждый раз вручную переносить документы в диалог?

Первым рабочим ответом на этот вопрос стал мой Obsidian MCP-сервер.

В следующем посте разберу, как через него LLM получила доступ к моему Obsidian.

#ObsidianMCP@annsFlow

Оглавление темы 📌

Навигация по проектам канала 📍

Все проекты 🎶

💻 annFlow
Telegram annFlow Как я построил MCP-сервер для своей рабочей системы ● Почему я разделил память и выполнение ● Как LLM получила доступ к моему Obsidian ● Что на самом деле происходит, когда LLM ищет что-то в моей памяти ● Как LLM добирается до локального Obsidian на…
  • ❤ 1
Post #171 31
Post #170 50
Older posts →

About this channel

How can I read @annsflow without a Telegram account?
TGViewer shows the public web preview Telegram publishes for annFlow: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does annFlow have?
annFlow (@annsflow) has 33 subscribers on Telegram, refreshed roughly every 30 minutes.
Does annFlow know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →