Как устроен Accounting AI Agent: один агент, 80+ инструментов и реальные данные из wFirma

В нашей продуктовой статье мы уже рассказывали, что умеет Accounting AI Agent: он отвечает на вопросы о VAT, PIT и CIT, работает с реальными счетами в wFirma и автоматизирует рутину. Это был взгляд со стороны пользователя. Теперь зайдём с другой стороны — со стороны реализации — и разберём, как всё это устроено внутри.

Бухгалтерия в Польше — это постоянно меняющиеся ставки, сроки и требования, и цена ошибки здесь измеряется реальными деньгами и штрафами. Обычный чат-бот в такой теме опасен: он уверенно назовёт несуществующий срок, придумает номер счёта или «вспомнит» ставку прошлого года — и всё это звучит убедительно. Мы построили систему так, чтобы у неё было как можно меньше поводов фантазировать: агент не гадает по памяти, а обращается к живым данным — вашим счетам в wFirma, польским государственным реестрам, официальному календарю налоговых сроков. В этой статье мы пройдём весь путь: от общей карты системы до того, какая модель за какую задачу отвечает. По дороге — все ключевые схемы, «причёсанные» для читателя, а не для инженера.

Одна идея проходит через весь текст: сила этого продукта не в размере модели, а в дисциплине вокруг неё — в инструментах, проверках и привязке к реальным данным. С неё и начнём.

Как устроена система целиком

Прежде чем нырять в детали, полезно увидеть карту. Accounting AI Agent — это полноценное веб-приложение (не «обёртка над ChatGPT»): у него есть кабинет в браузере, Telegram-бот, сервер с правами доступа и проверками, слой интеграций с внешним миром и базы данных.

flowchart TB
  subgraph Clients["Как обращаются к агенту"]
    WEB["Веб-кабинет<br/>(Next.js)"]
    TG["Telegram-бот"]
  end
  subgraph Core["Сервер и ИИ"]
    API["Сервер (API)<br/>вход · права · проверки"]
    AGENT["ИИ-агент<br/>(один, на LangGraph)"]
    OCR["Распознавание чеков<br/>(GPT-4o vision)"]
  end
  subgraph Integrations["Интеграции с внешним миром"]
    WF["wFirma<br/>счета · компания · платежи"]
    KSEF["KSeF<br/>гос. э-счета — FA(3)"]
    REG["Польские реестры<br/>Biała Lista MF · KRS"]
  end
  subgraph Data["Хранение"]
    PG["PostgreSQL<br/>данные · память ИИ"]
    RED["Redis<br/>сессии · лимиты"]
  end
  WEB --> API
  TG --> API
  TG --> OCR
  API --> AGENT
  AGENT --> WF
  AGENT --> KSEF
  AGENT --> REG
  API --> PG
  API --> RED
  WF --> PG

Слева — способы обращения: браузерный кабинет и Telegram-бот. В центре — сервер, который отвечает за вход, права и проверку данных, и сам ИИ-агент. Справа — внешний мир: wFirma (бухгалтерская платформа), KSeF (государственная система электронных счетов) и польские публичные реестры. Внизу — хранилища: PostgreSQL для данных и долгой памяти агента, Redis для сессий и ограничения нагрузки. Дальше разберём каждый крупный блок по очереди.

Один агент, а не «рой»

Сейчас модно строить «команды» из множества ИИ-агентов, которые передают задачи друг другу. Мы сознательно пошли другим путём: у нас один агент. Он получает сообщение, сам решает, какие инструменты вызвать, при необходимости вызывает их по очереди или сразу несколько, а затем составляет итоговый ответ. Никакого «диспетчера», распределяющего запросы между под-агентами, — это проще, предсказуемее и дешевле в отладке.

Работает он по классическому циклу «рассуждение → действие»: модель смотрит на сообщение и историю, решает, нужен ли инструмент, вызывает его, получает результат — и цикл повторяется, пока не будет готов финальный ответ.

stateDiagram-v2
  state "ИИ-агент (модель)" as A
  state "Инструменты" as T
  state C <<choice>>
  [*] --> A: сообщение пользователя
  A --> C: ответ модели
  C --> T: есть вызовы инструментов
  C --> [*]: готовый ответ (без вызовов)
  T --> A: результаты добавлены в диалог
  note right of A
    Модель с привязанными
    инструментами
  end note
  note right of T
    Инструменты выполняются и
    возвращают данные из wFirma,
    KSeF и реестров
  end note

Чтобы агент не «закружился» в бесконечных вызовах инструментов, стоит жёсткий предохранитель — не больше 25 шагов на один запрос. На практике этого с запасом хватает даже для сложных сценариев вроде «найди контрагента и выстави ему счёт», а от зацикливания защищает надёжно.

Путь одного сообщения

Что именно происходит между «пользователь нажал отправить» и «пришёл ответ»? Порядок шагов важен, поэтому покажем его целиком.

flowchart TB
  A["Пользователь отправил сообщение"] --> B["Взять ключ модели<br/>пользователя"]
  B --> C["Создать модель<br/>(OpenAI или Google Gemini)"]
  C --> D["Определить язык<br/>по тексту (ru / pl / en)"]
  D --> E["Подгрузить долгую память<br/>о бизнесе пользователя"]
  E --> F["Собрать системный промпт<br/>роль + язык + правила + налоги + память"]
  F --> G["Подключить инструменты<br/>58, а с HR и KSeF — до 82"]
  G --> H["Запустить агента<br/>(цикл рассуждение — инструменты)"]
  H --> I["Сохранить переписку"]
  I --> J["Обновить память<br/>(в фоне)"]
  I --> K["Озвучить ответ<br/>(в фоне, по желанию)"]

Обратите внимание на два «фоновых» шага в конце. После того как ответ отправлен пользователю, система, не задерживая его, обновляет долгую память и при необходимости готовит озвучку. То есть пользователь не ждёт, пока отработает вся служебная механика, — ответ он получает сразу.

58 инструментов, а с HR и KSeF — до 82

Вся «сила» агента — в инструментах. Инструмент — это конкретное умение: «получить список счетов», «создать контрагента», «посчитать зарплату», «отправить счёт в KSeF». Модель не выполняет эти действия сама — она лишь решает, какой инструмент и с какими параметрами вызвать, а выполняет их проверенный код.

flowchart LR
  AGENT(["ИИ-агент выбирает нужные инструменты"])
  subgraph BASE["Всегда доступно — 58 инструментов"]
    direction TB
    T1["Компания и контрагенты<br/>поиск по NIP, реестры"]
    T2["Счета и продажи<br/>создать · отправить · PDF"]
    T3["Платежи и расходы"]
    T4["Налоги: KPiR · JPK_VAT · PIT"]
    T5["Календарь налоговых сроков"]
    T6["Белый список счетов (Biała Lista)"]
    T7["Документы · книги · авто · сроки"]
  end
  subgraph OPT["Подключается при наличии"]
    direction TB
    HR["HR и зарплата — 15"]
    KS["KSeF — 9"]
  end
  AGENT --> BASE
  AGENT -.-> OPT

Базовые 58 инструментов есть у каждого пользователя. Ещё два набора — по 15 для кадров и зарплаты и 9 для KSeF — подключаются автоматически, если соответствующие возможности настроены. Итого — до 82 инструментов в руках одного агента. Важно, что часть инструментов вообще не зависит от wFirma и доступна всем и всегда: например, календарь налоговых сроков и проверка контрагента по «Белому списку».

Ответы на реальных данных, а не из головы

Это ключевое отличие от «умного, но фантазирующего» чат-бота. Когда вопрос касается конкретики — вашей компании, контрагента, суммы, — агент идёт за данными в надёжные источники, а не сочиняет их.

flowchart LR
  Q["Вопрос или действие<br/>пользователя"] --> AGENT["ИИ-агент"]
  AGENT --> WF["wFirma<br/>реальные счета, компания,<br/>платежи, расходы"]
  AGENT --> REG["Публичные реестры<br/>Biała Lista MF · KRS"]
  REG --> AF["Автозаполнение по NIP<br/>название · REGON · адрес"]
  AGENT --> WL{"Платёж ≥ 15 000 zł?"}
  WL -->|да| CHK["Проверить счёт по Белому<br/>списку МФ (обязательно)"]
  WL -->|нет| SKIP["Обычная запись"]
  WF --> ANS["Ответ на реальных данных<br/>+ официальные ссылки"]
  CHK --> ANS
  AF --> ANS

Пара деталей, которые экономят время и нервы:

Автозаполнение по NIP. Достаточно указать один налоговый номер контрагента — недостающие название, REGON и адрес система сама подтянет из публичных реестров (Biała Lista Министерства финансов и KRS) и покажет, какие поля заполнила автоматически.

Проверка по «Белому списку». Для любого платежа от 15 000 zł польский закон (ст. 117ba Ordynacji podatkowej) требует убедиться, что счёт контрагента есть в официальном «Белом списке» МФ. Агенту прямо предписано выполнять эту проверку автоматически, когда вы проводите крупный платёж, — чтобы вы не потеряли право отнести расход на затраты из-за формальности.

KSeF: электронные счета по-государственному

С переходом Польши на обязательную систему электронных счетов KSeF у бизнеса появилась новая рутина. Агент берёт её на себя: умеет сформировать структурированный счёт нужного формата (FA(3)), отправить его в KSeF, дождаться официального подтверждения и подобрать входящие счета к вашим записям.

flowchart LR
  A["Счёт из чата<br/>или из wFirma"] --> GEN["Сформировать<br/>FA(3) XML"]
  GEN --> SEND["Отправить в KSeF"]
  SEND --> POLL["Проверка статуса<br/>в фоне (раз в минуту)"]
  POLL --> UPO["UPO — официальное<br/>подтверждение"]
  subgraph Incoming["Входящие"]
    IN["Э-счета из KSeF"] --> MATCH["Сопоставить<br/>с записями wFirma"]
  end

Отдельные фоновые службы следят за статусами уже отправленных счетов и, если настроено, сами отправляют в KSeF новые счета, созданные в wFirma. А при создании счёта прямо в чате достаточно назвать компанию — недостающие NIP и адрес система подставит из локальной базы контрагентов.

Чек с фотографии

Ещё один способ убрать ручной ввод — просто сфотографировать чек. Пользователь присылает фото в Telegram, и система распознаёт его до того, как в дело вступит ИИ-агент.

flowchart LR
  P["Фото чека<br/>в Telegram"] --> OCR["Распознавание<br/>(GPT-4o vision)"]
  OCR --> CARD["Структурированная карточка:<br/>продавец · сумма · дата · NIP"]
  CARD --> EXP["Создать расход в wFirma<br/>(контрагент — по NIP автоматически)"]
  N["Отдельный шаг в обработчике фото,<br/>ещё до ИИ-агента"] -.-> OCR

Распознаванием занимается модель GPT-4o с поддержкой изображений. Язык ответа она подбирает по языку вашего Telegram-аккаунта, а результат отдаёт аккуратной карточкой, из которой расход одним шагом заводится в wFirma.

Долгая память о вашем бизнесе

Хороший помощник не переспрашивает одно и то же. Поэтому у агента есть долгая память: он запоминает факты о вашей фирме, частых контрагентов и ваши предпочтения — и учитывает их в следующих разговорах. При этом память устроена аккуратно и предсказуемо.

flowchart TB
  subgraph Extract["Извлечение (в фоне, после ответа)"]
    R["Ответ сформирован"] --> RULES["Разбор по правилам и шаблонам<br/>без LLM: «моя фирма…», «всегда…»"]
    RULES --> USE["Учёт частых инструментов<br/>и контрагентов"]
  end
  subgraph Store["Хранение (PostgreSQL)"]
    M[("Память: факты о фирме ·<br/>частые контакты · предпочтения ·<br/>рабочие шаблоны")]
  end
  subgraph Decay["Угасание (лениво, раз в сутки)"]
    DEC["Не вспоминали 30 дней →<br/>снижаем уверенность"] --> HIDE["Уверенность мала →<br/>факт скрывается"]
  end
  subgraph Inject["Вложение в промпт"]
    TOP["Взять до 20 самых важных<br/>(бюджет ~6000 знаков)"] --> SP["Добавить в системный промпт<br/>следующего разговора"]
  end
  USE --> M
  RULES --> M
  M --> DEC
  M --> TOP

Тут есть неочевидная, но принципиальная деталь: память наполняется не отдельной ИИ-моделью, а детерминированными правилами. Система ищет в переписке явные маркеры («моя фирма на линейном налоге 19%», «всегда выставляй в PLN») и отмечает часто используемых контрагентов и операции. Это дёшево, быстро и не добавляет ещё одного повода для галлюцинаций.

Память разложена по понятным категориям — факты о бизнесе, частые контакты, предпочтения и рабочие шаблоны — и не растёт бесконтрольно: то, что давно не пригождалось, постепенно «угасает» и скрывается, а в промпт подставляется только два десятка самых важных записей в пределах строгого бюджета символов. Так контекст остаётся релевантным, а расходы на модель — под контролем.

Системный промпт и язык

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

Язык система определяет автоматически по самому сообщению: кириллица — отвечаем по-русски, польские диакритические буквы — по-польски, в остальных случаях — по-английски. Дальше все инструменты возвращают результат уже на нужном языке — с правильным форматированием чисел, дат и сумм, привычным для конкретной страны.

Ваши ключи, ваш выбор модели

Важная особенность архитектуры: ключи к языковым моделям принадлежат пользователю. Каждый подключает свой ключ (он хранится в базе в зашифрованном виде), а система работает поверх него. Поддерживаются два провайдера — OpenAI и Google Gemini. Более новые модели OpenAI (семейства gpt-5, o1, o3) система обслуживает по их особым правилам — например, не навязывает им параметр «температуры».

Кстати, поддержки Anthropic здесь больше нет: весной 2026 года мы убрали её — она оставалась лишь как наследие старого мультиагентного кода и лишний повод держать ещё один платный ключ. Меньше зависимостей — чище архитектура.

Сам проект открыт на GitHub, и весь стек можно поднять у себя: собственный сервер, собственные ключи, полный контроль над данными. А тем, кому нужен готовый управляемый хостинг, доступна подписка на eKsiegowyAi.pl. Про безопасность тоже не забыли: вход по токенам, хеширование паролей, ограничение частоты запросов, валидация всех входных данных и защита от инъекций в базу, а все изменяющие операции пишутся в журнал аудита.

Заключение

Если собрать всё вместе, вырисовывается простая мысль: надёжный бухгалтерский ассистент получается не из «модели побольше», а из аккуратной инженерии вокруг неё. Один понятный агент вместо запутанного роя. Десятки проверенных инструментов вместо догадок. Живые данные из wFirma и государственных реестров вместо «знаний из головы». Обязательные проверки там, где их требует закон. Предсказуемая память на правилах. И ключи, которые остаются у пользователя.

Именно эта дисциплина превращает разговорчивую модель в инструмент, которому можно доверить рутину — и при этом спокойно спать, зная, что он не выдумает вам номер счёта. Попробовать Accounting AI Agent можно на eKsiegowyAi.pl или собрать самому из исходников на GitHub. А если вам нужен похожий агент, встроенный в ваши системы и данные, — напишите нам: development@mi-code.pl.

Какая модель за что отвечает

Напоследок — сводка: какая модель решает какую задачу. Отдельно подчеркнём: наполнение долгой памяти работает без языковой модели, на детерминированных правилах, поэтому в таблице его нет.